alyxander
asked on
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.
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.
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.
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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.
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
José Sousa
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