Section: 12.2.1.1 Procedural description
Content: In this case: - the MS is given an address belonging to the Intranet/ISP addressing space. The address is given either at subscription in which case it is a static address or at PDP context activation in which case it is a dynamic address. This address is used for packet forwarding within the GGSN and for packet forwarding on the Intranet/ISP. This requires a link between the GGSN and an address allocation server, such as AAA, or DHCP, belonging to the Intranet/ISP; - the communication between the Packet Domain and the Intranet/ISP may be performed over any network, even an insecure e.g. the Internet. In case of an insecure connection between the GGSN and the Intranet/ISP there may be a specific security protocol in between. This security protocol is defined by mutual agreement between PLMN operator and Intranet/ISP administrator. The following description bullet items describe the signal flow. 1) The TE sends an AT-command to the MT to set up parameters. 2) The MT sends the Activate PDP context request message to the SGSN which sends the Create PDP context request message to the chosen GGSN. 3) The GGSN deduces from the APN: - the server(s) to be used for address allocation and authentication; - the protocol such as RADIUS, DHCP or L2TP to be used with this / those server(s); - the communication and security feature needed to dialogue with this / those server(s) e.g. tunnel ,IPSec security association, dial-up connection (using possibly PPP). As an example the GGSN may use one of the following options: - RADIUS for authentication and IP-address allocation. The AAA server responds with either an Access-Accept or an Access-Reject to the RADIUS client in the GGSN; - RADIUS for authentication and DHCP for host configuration and address allocation. The AAA server responds with either an Access-Accept or an Access-Reject to the RADIUS client in the GGSN. After a successful authentication, the DHCP client discovers the DHCP server(s) in the ISP/Intranet and receives host configuration data; - L2TP for forwarding PPP frames to a L2TP Network Server. 4) The GGSN sends back to the SGSN a Create PDP Context Response message. 5) Depending on the cause value received in the Create PDP Context Response the SGSN may either send the Activate PDP Context Accept message or send the Activate PDP Context Reject message to the MS. 6) The MT responds with an AT-response that may indicate whether the context activation was successful or not. In the case of a non-successful context activation the response may also indicate the cause. In case of a successful context activation, the TE will start its PPP protocol after the LLC link has been established. The LCP, Authentication and NCP negotiations are then carried out. During these negotiations the GGSN may acknowledge values, for any LCP options related to ‘L2’ framing (e.g. ‘ACCM’, ‘ACFC’ and ‘FCS-Alternatives’), as proposed by the MT, which itself is forwarding these negotiations from the TE. NOTE: With the <PDP Type>"PPP" the MT may provide a PPP relay (or proxy) function between the TE and GGSN. This gives the opportunity for the MT to intercept the ‘L2’ framing end to end negotiations. EXAMPLE: In the following example the successful PDP context activation is shown. Figure 16a