Section: 16a.3.1 IP PDP type
Content: Figure 25a represents the Diameter message flows between a GGSN and a Diameter server. NOTE 1: If some external applications require Diameter Accounting request (Start) information before they can process user packets, then the selected APN (GGSN) may be configured in such a way that the GGSN drops user data until the Accounting Answer (START) is received from the Diameter server. The GGSN may wait for the Accounting Answer (START) before sending the CreatePDPContextResponse. The GGSN may reject the PDP context if the Accounting Answer (START) is not received. NOTE 2: Separate accounting and authentication servers may be used. NOTE 3: The AA-Request message shall be used for primary PDP context only. NOTE 4: The Accounting-Request (Start) message may be sent at a later stage, e.g. after IPv4 address has been assigned and PDP Context updated, in case of IP address allocation via DHCPv4 after successful PDP context activation signalling. Figure 25a: Diameter message flow for PDP type IP (successful user authentication case) When a GGSN receives a Create PDP Context Request message for a given APN, the GGSN may (depending on the configuration for this APN) send a Diameter AA-Request to a Diameter server. The Diameter server authenticates and authorizes the user. If Diameter is also responsible for IPv4 address and/or IPv6 prefix allocation the Diameter server shall return the allocated IPv4 address and/or IPv6 prefix in the AA-Answer message. The AA-Request and AA-Answer messages are only used for the primary PDP context. When PDP type is IPv4v6 and deferred IPv4 addressing via IPv4 address pool in the AAA server is used, the GGSN may intiate Diameter re-authorization procedures after successful initial attach for the purpose of IPv4 address allocation or to renew the lease for a previously allocated IPv4 address. In this case, the GGSN shall set the Session-Id to the value used in the initial access request, the Auth-Request-Type AVP to "AUTHORIZE_ONLY" and the 3GPP-Allocate-IP-Type AVP to the type of IP address to be allocated in the AA-Request message sent to the AAA server. See subclause 16.4.7.2 for the conditions to use 3GPP-Allocate-IP-Type AVP in AA-Request messages. If the GGSN is using DHCPv4 signalling towards the MS and the Diameter server includes the Session-Timeout attribute in the Access-Accept, the GGSN may use the Session-Timeout value as the DHCP lease time. The GGSN shall not set the DHCPv4 lease time value higher than the Session-Timeout value. The GGSN may renew the DHCP lease to the MS without re-authorization towards the AAA server providing that the new lease expiry is no later than the Session-Timeout timer expiry. If the GGSN wishes to extend the lease time beyond the current Session-Timeout expiry, it shall initiate a new AAA re-authorization. Even if the GGSN was not involved in user authentication (e.g. transparent network access mode), it may send a Diameter Accounting-Request (START) message to a Diameter server. If no Diameter session is already open for the user a Diameter session needs to be activated, otherwise the existing Diameter session is used to send the Accounting-Request (START). The NSAPI will identify the particular PDP context this accounting refers to. The Accounting-Request message also indicates to the Diameter server that the user session has started. This message contains parameters, e.g. the tuple which includes the user-id, IPv4 address and/or IPv6 prefix, and the MSISDN to be used by application servers (e.g. WAP gateway) in order to identify the user. If some external applications require Diameter Accounting request (Start) information before they can process user packets, then the selected APN (GGSN) may be configured in such a way that the GGSN drops user data until the Accounting Answer (START) is received from the Diameter server. The GGSN may wait for the Accounting Answer (START) before sending the CreatePDPContextResponse. The GGSN may reject the PDP context if the Accounting Answer (START) is not received. The authentication and accounting servers may be separately configured for each APN. For PDP type IPv4, at IPv4 address allocation via DHCP4 signalling between the TE and the PDN, no IPv4 address is available at PDP context activation. In that case the GGSN may wait to send the Accounting-Request (START) message until the TE receives its IP address in a DHCPACK. For PDP type IPv4v6 and deferred IPv4 addressing, when the IPv4 address is allocated or re-allocated, the accounting session that was established for the IPv6 prefix allocation shall be used to inform the accounting server about the allocated IPv4 address by sending Diameter Accounting-Request Interim-Update with the Framed-IP-Address AVP and its value field containing the allocated IPv4 address. When the GGSN receives a Delete PDP Context Request message and providing a Diameter Accounting-Request (START) message was sent previously, the GGSN shall send a Diameter Accounting-Request (STOP) message to the Diameter server, which indicates the termination of this particular user accounting session. The NSAPI will identify the particular PDP context this accounting refers to. The GGSN shall immediately send a Delete PDP context response, without waiting for an Accounting-Answer (STOP) message from the Diameter server. If this was the last PDP context for that PDP address, the GGSN shall additionally send an STR message to the Diameter server. The Diameter server shall reply with an STA and shall deallocate the IP address or IPv6 prefix (if any) initially allocated to the subscriber. For PDP type IPv4v6 and deferred IPv4 addressing, when the GGSN receives a message from the MS or the network indicating the release of the IPv4 address (e.g. receiving DHCPRELEASE) or decides to release the IPv4 address on its own (e.g. due to DHCP lease timer expiry for GGSN assigned IPv4 address), the GGSN shall inform the accounting server about the deallocation of the IPv4 address by sending Diameter Accounting-Request Interim-Update without the Framed-IP-Address AVP.