GPRS PUSH

[Murray Foxcroft]

Hi there,

We're writing a compact framework application to do some field service
automation. I need to implement PUSH technology to send updates to the
device. How do I get a server to identify, wake up and connect to a mobile
device and send information, say, via sockets.

Thanks in advance

 

[Chris Tacke, eMVP]

The device needs to have a listening "client" that is reachable, so it would
have to be on the network and listening for a call through the socket, which
would have to exist through the connection. Through GPRS this is going to
be challenging at the least.

-Chris

 

[Murray Foxcroft]

This I understand. I can write the socket listener etc, no worries, its
identifying the device on the GPRS network. What information on the server
do I need to uniquely identify the device and then talk to it - can I get an
IP from device ID?

No idea where to start on this myself.

 

[Alex Yakhnin [MVP]]

The unique identifier for you would be Ip address of the device. The easiest
way to let the server know that this client is listening is registering this
client with the server.

 

[Chris Tacke, eMVP]

As Alex says, when a device connects to the network, it should call the
server once and register. The server then can use the device IP to push
down data. You may want a keep-alive ping as well so the server can keep
it's active device registrations up to date.

So it would look like this:

- Client makes a connection to the network
- Client calls server and provides it's IP
- Periodically the server calls all registered IPs with a simple ping
- When data needs to be pushed, all registered IPs can be contacted

-Chris

 

[Murray Foxcroft]

Excellent - this is a lot of help!

Can a device be assigned a fixed IP? or do they all use DHCP? Can the DHCP
IP's be made relatively permanent?

If the device changes cells / reception areas - will the IP potentially
change?

What happens if the device is napping (sleeping) ?

Sorry for all these questions - but I am struggling and prssure from above
(the business) is mountin.

Thanks in advance for any more help.

 

[Valentin Iliescu]

One thing to remember:

Most of the GPRS networks have some sort of a gateway - it
is impossible to make connections from the outside
internet to the GPRS network. So the server cannot access
the devices without using a wireless card which is
registered in that GPRS network.

 

[Murray Foxcroft]

Hi Valentin,

I believe we will have our own Access Point Node (or is that Name), which
should make the network more private to us...
Dont know if that helps any. We are meeting with the service provider
(GPRS) - what sort of questions to I need to pose to their technical people
in order to get the right answers so that the GPRS push can be implemented ?

Thanks in advance

 

[Kevin Hutchison]

I am going to jump in for a couple of comments.

1. Since you don't really have a "WAKE" capability, you need to implement
lower level PULL capability and build any application capability on that.

Chris's list of steps suggests this, but I think you need to explicitly put
this in any design given to management. They will mis-understand the
capabilities.

2. For your addressing issues, are you working with a single provider? or
are you considering a general market offering? If the first, they can tell
you what the n/w admin options are. If the second, then you have no
guarantee of the IP addresses lifespan. (The IP address shouldn't change
between between cells. )

3. Building on #1, I would make it incumbent on the device to time the
pull/push. Since you don't know what the user is doing at any given time,
having the server blindly shove updates could be "bad". Depends on the
products usage. If the user is uploading a report to meet a deadline ...

Tx,

- K.

Excellent - this is a lot of help!

Can a device be assigned a fixed IP? or do they all use DHCP? Can the DHCP
IP's be made relatively permanent?

If the device changes cells / reception areas - will the IP potentially
change?

What happens if the device is napping (sleeping) ?

Sorry for all these questions - but I am struggling and prssure from above
(the business) is mountin.

Thanks in advance for any more help.

As Alex says, when a device connects to the network, it should call the
server once and register. The server then can use the device IP to push
down data. You may want a keep-alive ping as well so the server can keep
it's active device registrations up to date.

So it would look like this:

- Client makes a connection to the network
- Client calls server and provides it's IP
- Periodically the server calls all registered IPs with a simple ping
- When data needs to be pushed, all registered IPs can be contacted

-Chris

This I understand. I can write the socket listener etc, no worries, its
identifying the device on the GPRS network. What information on the server
do I need to uniquely identify the device and then talk to it - can I

get

an
IP from device ID?

No idea where to start on this myself.


"Chris Tacke, eMVP" <ctacke[at]Open_NET_CF[dot]org> wrote in message
The device needs to have a listening "client" that is reachable, so it
would
have to be on the network and listening for a call through the socket,
which
would have to exist through the connection. Through GPRS this is

going

to
be challenging at the least.

-Chris



Hi there,

We're writing a compact framework application to do some field service
automation. I need to implement PUSH technology to send updates to the
device. How do I get a server to identify, wake up and connect to a
mobile
device and send information, say, via sockets.

Thanks in advance

 

[Guest]

Yes, I think this is the best solution: implement some
sort of PULL capability instead of PUSH. This way you
don't have to worry about IP addresses or GPRS gateway.

1. Client queries the server every n seconds to see if
there are any updates.
2. If there is, download the update.

You have to handle the case when the device shuts down
because of inactivity. The Pocket PC doesn't close
applications when it shuts down, they stay in RAM, but the
GPRS connection closes. So before each query, check the
status of the GPRS connection and if it's closed, try to
reopen it.

There will be extra traffic generated by the queries but I
think it's OK.

-----Original Message-----
I am going to jump in for a couple of comments.

1. Since you don't really have a "WAKE" capability, you need to implement
lower level PULL capability and build any application capability on that.

Chris's list of steps suggests this, but I think you need to explicitly put
this in any design given to management. They will mis- understand the
capabilities.

2. For your addressing issues, are you working with a single provider? or
are you considering a general market offering? If the first, they can tell
you what the n/w admin options are. If the second, then you have no
guarantee of the IP addresses lifespan. (The IP address shouldn't change
between between cells. )

3. Building on #1, I would make it incumbent on the device to time the
pull/push. Since you don't know what the user is doing at any given time,
having the server blindly shove updates could be "bad". Depends on the
products usage. If the user is uploading a report to meet a deadline ...

Tx,

- K.

Excellent - this is a lot of help!

Can a device be assigned a fixed IP? or do they all use DHCP? Can the DHCP
IP's be made relatively permanent?

If the device changes cells / reception areas - will the IP potentially
change?

What happens if the device is napping (sleeping) ?

Sorry for all these questions - but I am struggling and prssure from above
(the business) is mountin.

Thanks in advance for any more help.



"Chris Tacke, eMVP" <ctacke[at]Open_NET_CF[dot]org> wrote in message

As Alex says, when a device connects to the network, it should call the
server once and register. The server then can use the device IP to push
down data. You may want a keep-alive ping as well so

the server can
keep etc, no worries,
its

identifying the device on the GPRS network. What

information on the
server

do I need to uniquely identify the device and then

talk to it - can I
get

an
IP from device ID?

No idea where to start on this myself.


"Chris Tacke, eMVP" <ctacke[at]Open_NET_CF[dot]org> wrote in message
The device needs to have a listening "client"

that is reachable, so
it call through the
socket,

Through GPRS this is
going to do some field
service to send updates to
the

up and connect to
a

.

 

[Valentin Iliescu]

I forgot to put my name

-----Original Message-----
Yes, I think this is the best solution: implement some
sort of PULL capability instead of PUSH. This way you
don't have to worry about IP addresses or GPRS gateway.

1. Client queries the server every n seconds to see if
there are any updates.
2. If there is, download the update.

You have to handle the case when the device shuts down
because of inactivity. The Pocket PC doesn't close
applications when it shuts down, they stay in RAM, but the
GPRS connection closes. So before each query, check the
status of the GPRS connection and if it's closed, try to
reopen it.

There will be extra traffic generated by the queries but I
think it's OK.

-----Original Message-----
I am going to jump in for a couple of comments.

1. Since you don't really have a "WAKE" capability, you need to implement
lower level PULL capability and build any application capability on that.

Chris's list of steps suggests this, but I think you

need
to explicitly put

this in any design given to management. They will mis- understand the
capabilities.

2. For your addressing issues, are you working with a single provider? or
are you considering a general market offering? If the first, they can tell
you what the n/w admin options are. If the second,

then
you have no

guarantee of the IP addresses lifespan. (The IP address shouldn't change
between between cells. )

3. Building on #1, I would make it incumbent on the device to time the
pull/push. Since you don't know what the user is doing at any given time,
having the server blindly shove updates could be "bad". Depends on the
products usage. If the user is uploading a report to meet a deadline ...

Tx,

- K.

use
DHCP? Can the DHCP and
prssure from above

(the business) is mountin.

Thanks in advance for any more help.



"Chris Tacke, eMVP" <ctacke[at]Open_NET_CF[dot]org> wrote in message
As Alex says, when a device connects to the network, it should call the
server once and register. The server then can use the device IP to push
down data. You may want a keep-alive ping as well

so
the server can

keep

it's active device registrations up to date.

So it would look like this:

- Client makes a connection to the network
- Client calls server and provides it's IP
- Periodically the server calls all registered IPs with a simple ping
- When data needs to be pushed, all registered IPs can be contacted

-Chris


This I understand. I can write the socket listener

etc, no worries,
its

identifying the device on the GPRS network. What information on the
server
do I need to uniquely identify the device and then talk to it - can I
get
an
IP from device ID?

No idea where to start on this myself.


"Chris Tacke, eMVP" <ctacke[at]Open_NET_CF[dot]

org>
wrote in message

that is reachable, so
it call through the
socket,

technology
to send updates to wake
up and connect to

a


.

.

 

[Valentin Iliescu]

Hi

A gateway provides the point of attachment between the
GPRS domain and external data networks, such as the
Internet and intranets. Each external network is given a
unique Access Point Name (APN) which is used by the mobile
client to establish the connection to the required
destination network.
So I think the service provider will allow you to initiate
connections from your intranet to the wireless network,
but ask them anyway.

 

[Chris Stephens]

Hows about sending an SMS message to the device to trigger it to act?

 

[Jeffrey Paul [MS]]

You did not specify what kind of device you are writing to. If this is PPC /
Smartphone, depending on the version you have a few options:

2002 Devices (SP and PPC Phone Edition):
You can send a WAP WDP message to the device (see WapOpen in the SDK) to
wake your device to have it initiate a connection to your server.

2003 Devices (SP and PPC Phone Edition):
You can send a SMS message and capture it programmatically via
IMailRuleClient (see the 2003 SDK) to wake you device.

Note: Both of these mechanisms will require you to write a native dll
calling the CE Win32 functions, or interop the functions.

--
Jeffrey Paul
Development Lead - Mobile Device Services
Microsoft Corporation

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[doug]

Be aware that the network provider can change the IP address of the device
at will, making push that much harder. My company is developing a product
called Telemore that overcomes this network instability and provides for an
inbox/outbox transfer metaphor as well as a socket type metaphor. We also
use if for IPC. MS products are currently supported with Linux next. We
are very close to release and are thinking about using a $299 developer
edition license with a $199 per remote device license production royalty.

Let me know if you are interested.

doug@codago_dot_com

 

[Guest]

What is this Codago company?

1. The web page (www.codago.com) gives no information
2. There is no reference of Codago in the Microsoft case
study

 

[Murray Foxcroft]

Thanks Jeffrey - I think I will go this route - sounds good - We'll be using
a Pocket PC GPRS enabled device - PPC2002 or possibly 2003.

The WAP WDP message - would I catch that from a running application?
Would it have to continually be polling for new messages?
Could you point me to any resources to help do this?
When u say interop - could this be accomplished using PInvoke?
Is there such a thing as a PPC service? Like a windows service?

Please excuse all the questions - this ramp up in to the mobile space is not
as simple as my boss thinks... lol

Thanks in advance

 

[Chris Tacke, eMVP]

Pull is all well and good, but not if you have an app paradigm where the
server pushes data to multiple devices. In that case, push really is the
only one that makes sense (well queueing would work as well). Using a
fairly short "ping" period helps ensure device availability and a push
architecture works well (I've done it).

-Chris

I am going to jump in for a couple of comments.

1. Since you don't really have a "WAKE" capability, you need to implement
lower level PULL capability and build any application capability on that.

Chris's list of steps suggests this, but I think you need to explicitly put
this in any design given to management. They will mis-understand the
capabilities.

2. For your addressing issues, are you working with a single provider? or
are you considering a general market offering? If the first, they can tell
you what the n/w admin options are. If the second, then you have no
guarantee of the IP addresses lifespan. (The IP address shouldn't change
between between cells. )

3. Building on #1, I would make it incumbent on the device to time the
pull/push. Since you don't know what the user is doing at any given time,
having the server blindly shove updates could be "bad". Depends on the
products usage. If the user is uploading a report to meet a deadline ...

Tx,

- K.

Excellent - this is a lot of help!

Can a device be assigned a fixed IP? or do they all use DHCP? Can the DHCP
IP's be made relatively permanent?

If the device changes cells / reception areas - will the IP potentially
change?

What happens if the device is napping (sleeping) ?

Sorry for all these questions - but I am struggling and prssure from above
(the business) is mountin.

Thanks in advance for any more help.

As Alex says, when a device connects to the network, it should call the
server once and register. The server then can use the device IP to push
down data. You may want a keep-alive ping as well so the server can keep
it's active device registrations up to date.

So it would look like this:

- Client makes a connection to the network
- Client calls server and provides it's IP
- Periodically the server calls all registered IPs with a simple ping
- When data needs to be pushed, all registered IPs can be contacted

-Chris


This I understand. I can write the socket listener etc, no worries, its
identifying the device on the GPRS network. What information on the server
do I need to uniquely identify the device and then talk to it - can

I
get

an
IP from device ID?

No idea where to start on this myself.


"Chris Tacke, eMVP" <ctacke[at]Open_NET_CF[dot]org> wrote in message
The device needs to have a listening "client" that is reachable,

so

it to
the

to

a

 

[Murray Foxcroft]

Obviously the "ping", however you implement it, incurs a bandwidth cost over
GPRS over WLAN you could constantly chat, but GPRS needs to be used
sparingly (well, over here in Sout Africa it does - its quite costly). What
do you mean by relatively short periods - seconds / minutes / hours? Would
the ping keep the device "alive" on the network, thus adversely affecting
battery life?

Pull is all well and good, but not if you have an app paradigm where the
server pushes data to multiple devices. In that case, push really is the
only one that makes sense (well queueing would work as well). Using a
fairly short "ping" period helps ensure device availability and a push
architecture works well (I've done it).

-Chris

I am going to jump in for a couple of comments.

1. Since you don't really have a "WAKE" capability, you need to implement
lower level PULL capability and build any application capability on that.

Chris's list of steps suggests this, but I think you need to explicitly put
this in any design given to management. They will mis-understand the
capabilities.

2. For your addressing issues, are you working with a single provider? or
are you considering a general market offering? If the first, they can tell
you what the n/w admin options are. If the second, then you have no
guarantee of the IP addresses lifespan. (The IP address shouldn't change
between between cells. )

3. Building on #1, I would make it incumbent on the device to time the
pull/push. Since you don't know what the user is doing at any given time,
having the server blindly shove updates could be "bad". Depends on the
products usage. If the user is uploading a report to meet a deadline ....

Tx,

- K.

Excellent - this is a lot of help!

Can a device be assigned a fixed IP? or do they all use DHCP? Can the DHCP
IP's be made relatively permanent?

If the device changes cells / reception areas - will the IP potentially
change?

What happens if the device is napping (sleeping) ?

Sorry for all these questions - but I am struggling and prssure from above
(the business) is mountin.

Thanks in advance for any more help.



"Chris Tacke, eMVP" <ctacke[at]Open_NET_CF[dot]org> wrote in message
As Alex says, when a device connects to the network, it should call the
server once and register. The server then can use the device IP to push
down data. You may want a keep-alive ping as well so the server can keep
it's active device registrations up to date.

So it would look like this:

- Client makes a connection to the network
- Client calls server and provides it's IP
- Periodically the server calls all registered IPs with a simple ping
- When data needs to be pushed, all registered IPs can be contacted

-Chris


This I understand. I can write the socket listener etc, no

worries,
its

identifying the device on the GPRS network. What information on the
server
do I need to uniquely identify the device and then talk to it -

can

I

get
an
IP from device ID?

No idea where to start on this myself.


"Chris Tacke, eMVP" <ctacke[at]Open_NET_CF[dot]org> wrote in message
The device needs to have a listening "client" that is reachable,

so

it
would
have to be on the network and listening for a call through the socket,
which
would have to exist through the connection. Through GPRS this is
going
to
be challenging at the least.

-Chris



Hi there,

We're writing a compact framework application to do some field
service
automation. I need to implement PUSH technology to send

updates

to to

 

[Kevin Hutchison]

Using a fairly short "ping" period helps ensure device availability and a
push architecture works well (I've done it).

Well, then -- very good!!! If the client has the ability not to respond to
the ping when he is busy, that solves the problem and ... is less
complicated.

- K.

Pull is all well and good, but not if you have an app paradigm where the
server pushes data to multiple devices. In that case, push really is the
only one that makes sense (well queueing would work as well). Using a
fairly short "ping" period helps ensure device availability and a push
architecture works well (I've done it).

-Chris

I am going to jump in for a couple of comments.

1. Since you don't really have a "WAKE" capability, you need to implement
lower level PULL capability and build any application capability on that.

Chris's list of steps suggests this, but I think you need to explicitly put
this in any design given to management. They will mis-understand the
capabilities.

2. For your addressing issues, are you working with a single provider? or
are you considering a general market offering? If the first, they can tell
you what the n/w admin options are. If the second, then you have no
guarantee of the IP addresses lifespan. (The IP address shouldn't change
between between cells. )

3. Building on #1, I would make it incumbent on the device to time the
pull/push. Since you don't know what the user is doing at any given time,
having the server blindly shove updates could be "bad". Depends on the
products usage. If the user is uploading a report to meet a deadline ....

Tx,

- K.

Excellent - this is a lot of help!

Can a device be assigned a fixed IP? or do they all use DHCP? Can the DHCP
IP's be made relatively permanent?

If the device changes cells / reception areas - will the IP potentially
change?

What happens if the device is napping (sleeping) ?

Sorry for all these questions - but I am struggling and prssure from above
(the business) is mountin.

Thanks in advance for any more help.



"Chris Tacke, eMVP" <ctacke[at]Open_NET_CF[dot]org> wrote in message
As Alex says, when a device connects to the network, it should call the
server once and register. The server then can use the device IP to push
down data. You may want a keep-alive ping as well so the server can keep
it's active device registrations up to date.

So it would look like this:

- Client makes a connection to the network
- Client calls server and provides it's IP
- Periodically the server calls all registered IPs with a simple ping
- When data needs to be pushed, all registered IPs can be contacted

-Chris


This I understand. I can write the socket listener etc, no

worries,
its

identifying the device on the GPRS network. What information on the
server
do I need to uniquely identify the device and then talk to it -

can

I

get
an
IP from device ID?

No idea where to start on this myself.


"Chris Tacke, eMVP" <ctacke[at]Open_NET_CF[dot]org> wrote in message
The device needs to have a listening "client" that is reachable,

so

it
would
have to be on the network and listening for a call through the socket,
which
would have to exist through the connection. Through GPRS this is
going
to
be challenging at the least.

-Chris



Hi there,

We're writing a compact framework application to do some field
service
automation. I need to implement PUSH technology to send

updates

to to