Puzzled about PPP, LCP and IPCP in GPRS....

Is it necessary to use LCP with PPP while dialing in a stand alone mode? I ask this because I have been working with a developer using a wavecom modem, who indicated that during the PDP context activation, the modem was set for auto-connect mode by setting either AT$AREG=2 (or manually activate by sending AT+CGACT=1,1 commands) - you don't have to send the dial string (*99#). This is done automatically inside the modem and it tries to negotiate the PDP context activation with the network. In this case the client would still allow user to enter AT commands even after the PDP context activation is established - unless the modem is setup for PAD mode (which was not the case with the client).
In anycase, the resolve to this situation was for the developers to create a PPP connection by only sending CHAP and IPCP, omitting LCP. Can anyone provide a reason why this would work? In fact does anyone have any information detailing how PPP, LCP, IPCP works in the GPRS environment. I have a feeling I and my colleagues are not understanding the actual procedures.

Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

I'm afraid that when you do that you're only attaching the device to the GPRS network and receiving the mobile IP that id's your device to the same GPRS network (and it may change if you move around, but that's of no concern to you: it should be transparent)...
But now you need to log into some remote network USING the GPRS network: that's why you need to start the LCP, PAP/CHAP and IPCP negotiations with the remote server/network (just like a dial-up with your most current modem, forget about the GPRS network) and this should work.
To summarize, when you use a mobile GPRS enabled in fact you have two IP address's: the one from the GPRS network and your machine's IP over the remote network you need to access. The IP over the GPRS network it's just to overcome the TCP/IP drawback of rigid hierarchy (it assumes you don´t move or if you do, you reboot and you another IP address) and for subsequent routing between your mobile and the remote network: this GPRS IP should be of no concerne to you.

José Sousa
GPRS is just a network to forward IP packets between the terminal and an external IP network defined as an APN (Access Point Name) connected to the GPRS node GGSN. Unlike CSD, where the terminal dials a number and then starts the PPP negotiation, the GGSN expects the PPP negotiation to have been concluded prior to setting up a pdp-context.

The way this is solved is that the MT, holding the GSM and GPRS stack, negotiates the PPP connection with the TE (Terminal Equipment) before it sends an activate-pdp-context request message to the SGSN. All the PPP results are put in a field which is called 'Protocol Configuration Options' in the activate-pdp-context request message. The SGSN then forwards the request as an create-pdp-context request to the GGSN.

Dependent on the configuration the GGSN may now look into the Protocol Configuration Options information element and extract and optionally validate the IPCP fields to reject or grant the terminal access to the external IP network (the APN). The GGSN can also be set up to forward the authentication information to an external RADIUS server or set up an L2TP tunnel to make the external IP network take care of the authentication. Then the GGSN, RADIUS server, or potentially an external DHCP server will assign an IP address to the terminal, unless the HLR subscription of the subscriber allows static IP addresses to be used. The newly IP address to be used by the terminal is then returned in the create-pdp-context accept message, which in turn is translated by the SGSN to a activate-pdp-context accept message.

The MT then gets the accept message from the GPRS network, and signallises to the TE that the PPP negotiation is finished, ready to send payload.

There is only one IP address involved. When an IP packet is sent from the external IP network, the GGSN will then forward those packets to the correct mobile terminal via the GPRS network. The GSM stack in the MT will then decode all the GPRS protocol layers, and forward the IP packet to the TE on the PPP connection between the TE and the MT.

In the case where no PPP negotiation takes place between the MT and TE it is still possible to send IP packets to the TE. However, the TE will simply silently discard the packets as there is no receiver for them.

In essence, the main difference between CSD and GPRS is that the PPP session must be established PRIOR to contacting the GSM network, where the PPP parameters are forwarded to the GSM network in the protocol configuration options field, whereas CSD negotiates PPP after a connection between a dial in server and the terminal is established.

I hope this clarifies your issue.
I believe that a PPP session only exists if you want it to exists: whem the mobile attaches to the GPRS network (through SGSN node) and activates the PDP context, it gets a mobile IP that id's the MT in the GPRS network... Then it can dial-up the remote network (there'll be a dial string and the subsequent CONNECT, PPP session, etc.). But before you can dial a remote network using the GPRS backbone you must activate a PDP (it's the routing mechanism that supports the very GPRS network model). Hear this: whwn you dial-up using GPRS, the mobile will AUTOMATTICALLY attach to the GPRS network and activate the PDP (if any), and only then dial the network...

So, resuming:

1. attach to the GPRS network
2. activate a PDP context (it routes the IP traffic to the APN that supports your SIM card)
3. dial and establishe a PPP tunnel

José Sousa

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
I am sorry, but from a GPRS Session Management signalling perspective there is no action after the creation of the pdp-context.

Once the pdp-context is established the network only provides a transparent IP connection layer between the TE and the external IP network identified by the APN.

You can not dial anywhere through a pdp-context, only send IP packets.

It may be you have access to a terminal that supports establishment of a PPP connection between the TE and the MT, which is what I guess is meant by step 3 above. The only signalling towards the GSM network caused by step 3 is either IP packets sent through an activated pdp-context, or a traditional CSD call.

If you claim the terminal gets a new IP address in addition to the one for the pdp-context the terminal must somehow tunnel the PPP connection over the IP network offered by the GPRS network. Then you need a server in the external IP network which terminates these IP packets, and negotiates the PPP connection, but this is not something that is triggered with the dial command.

In GPRS there is still only one IP address per pdp-context.

I agree with you 'einaraune' and I mean exactly that: you get a mobile IP when you attach and activate the PDP (GPRS routing). I'm only stating that to get registered in a remote network you must perform a PPP session negotiation with either the mobile network backbone (that will, for example, address the TE with a private IP address of the remote pool available or for what means there are). And to do that (and that's the issue here) you MUST comply with the 3 points I've named.

José Sousa
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Wireless Networking

From novice to tech pro — start learning today.