16a Usage of Diameter on Gi/Sgi interface
29.0613GPPInterworking between the Public Land Mobile Network (PLMN) supporting packet based services and Packet Data Networks (PDN)Release 17TS
As an operator option, it is also possible to use the Diameter protocol in order to provide Authentication, Authorization and Accounting services.
A GGSN/P-GW may, on a per APN basis, use Diameter authentication to authenticate a user and Diameter accounting to provide information to a Diameter server.
16a.1 Diameter Authentication and Authorization
Diameter Authentication and Authorization shall be used according to RFC 7155 [120].
The GGSN/P-GW and the Diameter server shall advertise the support of the Diameter NASREQ Application by including the value of the appropriate application identifier in the Capability-Exchange-Request and Capability-Exchange-Answer commands as specified in IETF RFC 6733 [111].
The Diameter client function may reside in a GGSN/P-GW. When the GGSN/P-GW receives an initial attach (e.g. Create PDP Context) request message the Diameter client function may send the authentication information to an authentication server, which is identified during the APN provisioning.
The authentication server checks that the user can be accepted. The response (when positive) may contain network information, such as an IPv4 address and/or IPv6 prefix for the user when the GGSN/P-GW is interworking with the AAA server.
The information delivered during the Diameter authentication can be used to automatically correlate the users identity (the MSISDN or IMSI) to the IPv4 address and/or IPv6 prefix, if applicable, assigned/confirmed by the GGSN/P-GW or the authentication server respectively. The same procedure applies, in case of sending the authentication to a ‘proxy’ authentication server.
Diameter Authentication is applicable to the initial access (e.g. primary PDP context or the default bearer). When the GGSN/P-GW receives a positive response from the authentication server it shall complete the initial access (e.g. PDP context activation) procedure. If a failure or no response is received, the GGSN/P-GW shall reject the initial access (e.g. PDP Context Activation) attempt with a suitable cause code, e.g. User Authentication failed.
The GGSN may also use the Diameter re-authorization procedure for the purpose of IPv4 address allocation to the UE for PDP type of IPv4v6 after establishment of a PDN connection.
For EPS, the P-GW may also use the Diameter re-authorization procedure for the purpose of IPv4 address allocation to the UE for PDN type of IPv4v6 after establishment of a PDN connection. The use cases that may lead this procedure are:
– Deferred IPv4 address allocation via DHCPv4 procedure after successful attach on 3GPP accesses.
– Deferred IPv4 address allocation after successful attach in trusted non-3GPP IP access on S2a.
– Deferred IPv4 home address allocation via DSMIPv6 Re-Registration procedure via S2c.
16a.2 Diameter Accounting
Diameter Accounting shall be used according to RFC 7155 [120].
The Diameter accounting client function may reside in a GGSN/P-GW. The Diameter accounting client may send information to an accounting server, which is identified during the APN provisioning. The accounting server may store this information and use it to automatically identify the user. This information can be trusted because the PS access network has authenticated the subscriber (i.e. SIM card and possibly other authentication methods).
Diameter Accounting messages may be used during both primary and secondary PDP context activation for non-EPC based packet domain (both the default bearer and dedicated bearer for the EPC based packet domain) and deactivation procedures respectively.
If the AAA server is used for IPv4 address and/or IPv6 prefix assignment, then, upon reception of a Diameter Accounting-Request STOP message for all IP-CAN bearers associated to an IP-CAN session defined by APN and IMSI or MSISDN, the AAA server may make the associated IPv4 address and/or IPv6 prefix available for assignment.
For PDN/PDP type IPv4v6 and deferred IPv4 address allocation, 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 Framed-IP-Address AVP and its value field containing the allocated IPv4 address. Similarly, the release of IPv4 address shall be indicated to the accounting server by sending Diameter Accounting-Request Interim-Update without the Framed-IP-Address AVP.
16a.3 Authentication and accounting message flows on Gi interface
16a.3.1 IP PDP type
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.
16a.3.2 PPP PDP type
Figure 25b describes the Diameter message flows between a GGSN and a Diameter server for the case where PPP is terminated at the GGSN. The case where PPP is relayed to an LNS is beyond the scope of the present document.
NOTE 1: Separate accounting and Authentication servers may be used.
NOTE 2: Actual messages depend on the used authentication protocol (e.g. PAP, CHAP).
NOTE 3: 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 AAA server. The GGSN may delete the PDP context if the Accounting Response (START) is not received.
NOTE 4: An LCP termination procedure may be performed. Either the MS or the GGSN may initiate the context deactivation.
NOTE 5: The AA-Request message shall be used for primary PDP context only.
NOTE 6: Network Initiated deactivation.
NOTE 7: User Initiated deactivation.
Figure 25b: Diameter message flow for PDP type PPP (successful user authentication case)
When a GGSN receives a Create PDP Context Request message for a given APN, the GGSN shall immediately send a Create PDP context response back to the SGSN. After PPP link setup, the authentication phase may take place. During Authentication phase, the GGSN sends a Diameter AA-Request to a Diameter server. The Diameter server authenticates and authorizes the user. If Diameter is also responsible for IP address allocation the Diameter server shall return the allocated IP address or IPv6 prefix in the AA-answer message (if the user was authenticated).
If the user is not authenticated, the GGSN shall send a Delete PDP context request to the SGSN. The AA-Request and AA-Answer messages are only used for the primary PDP context.
Even if the GGSN was not involved in user authentication (e.g. for PPP no authentication may be selected), 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, and the QoS parameters associated to the session. This message contains parameters, e.g. a tuple which includes the user-id, IP address 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 delete the PDP context if the Accounting Answer (START) is not received. The Authentication and Accounting servers may be separately configured for each APN.
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 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.
16a.3.3 Accounting Update
During the life of a PDP context some information related to this PDP context may change (i.e. SGSN address if an Inter-SGSN RA update occurs). Upon reception of an UpdatePDPContextRequest from the SGSN, the GGSN may send an Accounting Request (Interim) to the Diameter server to update the necessary information related to this PDP context (see figure 25c). Interim updates are also used when the IPv4 address is allocated/released/re-allocated for deferred IPv4 addressing for the PDP type IPv4v6.
If the GGSN receives an UpdatePDPContextRequest from the SGSN that specifically indicates a direct tunnel establishment or a direct tunnel teardown (switching the user plane tunnel end back to the SGSN), and only the GTP user plane address or the GTP-U TEID have changed, then the GGSN should not send the Accounting Request (Interim) message to the Diameter server. In such cases, the GGSN need not wait for the Diameter Accounting Answer from the Diameter server message before sending the UpdatePDPContextResponse to the SGSN. The GGSN may delete the PDP context if the Accounting Answer is not received from the Diameter server.
NOTE: As shown the GGSN need not wait for the Diameter Accounting Answer message from the Diameter server to send the UpdatePDPContextResponse to the SGSN. The GGSN may delete the PDP context if the Accounting Answer is not received from the Diameter server.
Figure 25c: Diameter for PDP context Update
16a.3.4 Server-Initiated PDP context termination
Diameter is used as the protocol between the GGSN and a Diameter server or proxy for applications (e.g. MMS) to deliver information related to GPRS user session. However some IP applications could need to interwork with the GGSN to terminate a particular PDP context. For this purpose, the Diameter server or proxy may send a Diameter ASR to the GGSN along with the NSAPI necessary to identify the particular PDP context to be terminated. As depicted in figure 25d, the GGSN should react by deleting the corresponding PDP context. If the GGSN deletes the corresponding PDP context, it need not wait for the DeletePDPContextResponse from the SGSN before sending the ASA to the server.
The absence of the NSAPI in the Diameter ASR message indicates to the GGSN that all PDP contexts for this particular user and sharing the same user session shall be deleted. The PDP contexts belonging to the same IP-CAN session are identified by the Diameter Session-Id. If a user has the same user IP address for different sets of PDP contexts towards different networks, only the PDP contexts linked to the one identified by the Diameter Session-Id shall be deleted.
NOTE: As showed on figure 25d, the GGSN need not wait for the DeletePDPContextResponse from the SGSN to send the ASA to the Diameter server.
Figure 25d: PDP Context deletion with Diameter
16a.3a Authentication and accounting message flows on Sgi interface
16a.3a.1 Authentication, Authorization and Accounting procedures
When a P-GW receives an initial access request (e.g.Create Session Request or Proxy Binding Update) message for a given APN, the P-GW 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 the Diameter server 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.
When PDN type is IPv4v6 and deferred IPv4 addressing via IPv4 address pool in the AAA server is used, the P-GW 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 P-GW 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 P-GW is using DHCPv4 signalling towards the UE and the Diameter server includes the Session-Timeout attribute in the Access-Accept, the P-GW may use the Session-Timeout value as the DHCP lease time. The P-GW shall not set the DHCPv4 lease time value higher than the Session-Timeout value. The P-GW may renew the DHCP lease to the UE without re-authorization towards the AAA server providing that the new lease expiry is no later than the Session-Timeout timer expiry. If the P-GW wishes to extend the lease time beyond the current Session-Timeout expiry, it shall initiate a new AAA re-authorization.
Even if the P-GW was not involved in user authentication, it may send a Diameter Accounting-Request (START) message to a Diameter server. If no Diameter session is already open for the same PDN connection a Diameter session needs to be activated, otherwise the existing Diameter session is used to send the Accounting-Request (START). For GTP-based S5/S8/S2a/S2b, if accounting is used per IP-CAN bearer, the EPS bearer ID will identify the particular bearer this accounting message 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 and IPv4 address and/or IPv6 prefix, to be used by application servers (e.g. WAP gateway) in order to identify the user. This message also indicates to the Diameter server that the user session has started.
If some external applications require Diameter Accounting Request (START) information before they can process user packets, then the selected APN (P-GW) may be configured in such a way that the P-GW drops user data until an Accounting-Answer (START) indicating success is received from the Diameter server. The P-GW may wait for the Accounting-Answer (START) before sending the initial access response (e.g. Create Session Response or Proxy Binding Acknowledgement). The P-GW may reject the initial access request if the Accounting-Answer (START) is not received. The authentication and accounting servers may be separately configured for each APN.
For PDN type IPv4, at IPv4 address allocation via DHCPv4 signalling between the UE and the PDN, no IPv4 address is available at initial access. In that case the P-GW may wait to send the Accounting-Request START message until the UE receives its IPv4 address in a DHCPACK.
For PDN 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 P-GW receives a message indicating a bearer deactivation request or PDN disconnection request or detach request (e.g. Delete Bearer Command or Proxy Binding Update with lifetime equal 0) and providing a Diameter Accounting-Request START message was sent previously, the P-GW shall send a Diameter Accounting-Request (STOP) message to the Diameter server, which indicates the termination of this particular bearer or user session. The P-GW shall immediately send the corresponding response (e.g. Delete Bearer Request or Proxy Binding Ack with lifetime equal 0) to the peer node (e.g. S-GW) in the Packet Domain, without waiting for an Accounting-Answer (STOP) message from the Diameter server.
If the last bearer of an IP-CAN session is deactivated, the P-GW shall additionally send an STR message to the Diameter server. The Diameter server shall reply with an STA and shall deallocate the IPv4 address and/or IPv6 prefix (if any) initially allocated to the subscriber.
For PDN type IPv4v6 and deferred IPv4 addressing, when the P-GW receives a message from the UE 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 P-GW assigned IPv4 address), the P-GW 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.
The following Figure 25d.1 is an example message flow to show the procedure of Diameter Authentication and Accounting, which is applicable for GTP based S5/S8:
NOTE 1: If some external applications require Diameter Accounting request (Start) information before they can process user packets, then the selected APN (P-GW) may be configured in such a way that the P-GW drops user data until the Accounting Answer (START) is received from the Diameter server. The P-GW may wait for the Accounting Answer (START) before sending the Create Session Response. The P-GW may reject the bearer if the Accounting Answer (START) is not received.
NOTE 2: Separate accounting and authentication servers may be used.
Figure 25d.1: An example of Diameter Authentication and Accounting on Sgi for GTP-based S5/S8
16a.3a.2 Accounting Update
During the life of a bearer some information related to this bearer may change. Upon occurrence of the following events the P-GW may send an Accounting Request (Interim) to the Diameter server: RAT change, S-GW address change and QoS change. Interim updates are also used when the IPv4 address is allocated/released/re-allocated for deferred IPv4 addressing for the PDN type IPv4v6.
When the P-GW receives a signalling request (e.g. Modify Bearer Request in case of GTP-based S5/S8) that indicates the occurrence of one of these chargeable events, the P-GW may send an Accounting Request (Interim) to the Diameter server to update the necessary information related to this bearer. The P-GW need not wait for the Diameter Accounting Answer message from the Diameter server before sending the response for the triggering signalling message (e.g. Modify Bearer Response). The P-GW may delete the bearer if the Accounting Answer is not received from the Diameter server.
The P-GW may also send interim updates at the expiry of an operator configured time limit.
The message flow in figure 25d.2 provides an example for Diameter Accounting Update procedure on Sgi interface, which is applicable for GTP based S5/S8:
Figure 25d.2: Diameter accounting update for bearer modification
16a.3a.3 Server-Initiated Bearer termination
Diameter is used as the protocol between the P-GW and a Diameter server or proxy for applications (e.g. MMS) to deliver information related to the user session. However some IP applications could need to interwork with the P-GW to release the corresponding resource (e.g. terminate a particular bearer or Resource Allocation Deactivation procedures as defined in TS 23.402 [78]). For this purpose, the Diameter server or proxy may send a Diameter ASR along with the EPS bearer ID, if available, to identify the particular bearer to be terminated to the P-GW. The P-GW should react by deleting the corresponding bearer. If the P-GW deletes the corresponding bearer, it need not wait for the response from the S-GW or trusted non-3GPP IP access or ePDG before sending the ASA to the server.
The absence of the EPS bearer ID in the Diameter ASR message indicates to the P-GW that all bearers/resources for this particular user and sharing the same user session shall be deleted. The bearer(s)/resources belonging to the same IP-CAN session are identified by the Diameter Session-Id. If a user has the same user IP address(es) for different sets of bearers towards different networks, only the bearers linked to the one identified by the Diameter Session-Id shall be deleted.
The message flow in figure 25d.3 provides an example for Server-initiated Bearer Termination procedure on Sgi interface, which is applicable for GTP based S5/S8:
Figure 25d.3: Server-initiated Bearer Termination with Diameter
16a.4 Gi/Sgi Diameter messages
This clause describes the Gi and the Sgi interface Diameter messages.
The relevant AVPs that are of use for the Gi/Sgi interface are detailed in this clause. Other Diameter NASREQ (IETF RFC 7155 [120]) AVPs, even if their AVP flag rules is marked with "M", are not required for being compliant with the current specification.
16a.4.1 AAR Command
The AAR command, defined in Diameter NASREQ (IETF RFC 7155 [120]), is indicated by the Command-Code field set to 265 and the ‘R’ bit set in the Command Flags field. It may be sent by the GGSN to a Diameter server, during Primary PDP Context activation only, in order to request user authentication and authorization. In the case of P-GW, the AAR may be sent upon reception of an initial access request (e.g. Create Session Request or Proxy Binding Update) message for a given APN to request user authentication and authorization.
The relevant AVPs that are of use for the Gi/Sgi interface are detailed in the ABNF description below. Other valid AVPs for this command are not used for Gi/Sgi purposes and should be ignored by the receiver or processed according to the relevant specifications.
The bold marked AVPs in the message format indicate optional AVPs for Gi/Sgi, or modified existing AVPs. For Sgi, some of the optional 3GPP vendor-specific AVPs listed in the message format below are not applicable. See table 9a in subclause 16a.5 to see the list of vendor-specific AVPs that are applicable to the GGSN and the P-GW.
Message Format:
<AA-Request> ::= < Diameter Header: 265, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Request-Type }
[ Destination-Host ]
[ NAS-Port ]
[ NAS-Port-Id ]
[ NAS-Port-Type ]
[ Origin-State-Id ]
[ Port-Limit ]
[ User-Name ]
[ User-Password ]
[ Service-Type ]
[ Authorization-Lifetime ]
[ Auth-Grace-Period ]
[ Auth-Session-State ]
[ Callback-Number ]
[ Called-Station-Id ]
[ Calling-Station-Id ]
[ Originating-Line-Info ]
[ Connect-Info ]
[ CHAP-Auth ]
[ CHAP-Challenge ]
* [ Framed-Compression ]
[ Framed-Interface-Id ]
[ Framed-IP-Address ]
* [ Framed-IPv6-Prefix ]
* [ Delegated-IPv6-Prefix ]
[ Framed-IP-Netmask ]
[ Framed-MTU ]
[ Framed-Protocol ]
* [ Login-IP-Host ]
* [ Login-IPv6-Host ]
[ Login-LAT-Group ]
[ Login-LAT-Node ]
[ Login-LAT-Port ]
[ Login-LAT-Service ]
* [ Tunneling ]
* [ Proxy-Info ]
* [ Route-Record ]
[ 3GPP-IMSI]
[ External-Identifier]
[ 3GPP-Charging-ID ]
[ 3GPP-PDP-Type ]
[ 3GPP-CG-Address ]
[ 3GPP-GPRS-Negotiated-QoS-Profile ]
[ 3GPP-SGSN-Address ]
[ 3GPP-GGSN-Address ]
[ 3GPP-IMSI-MCC-MNC ]
[ 3GPP-GGSN-MCC-MNC ]
[ 3GPP-NSAPI ]
[ 3GPP-Selection-Mode ]
[ 3GPP-Charging-Characteristics ]
[ 3GPP-CG-IPv6-Address ]
[ 3GPP-SGSN-IPv6-Address ]
[ 3GPP-GGSN-IPv6-Address ]
[ 3GPP-SGSN-MCC-MNC ]
[ 3GPP-User-Location-Info ]
[ 3GPP-RAT-Type ]
[ 3GPP-CAMEL-Charging-Info ]
[ 3GPP-Negotiated-DSCP ]
[ 3GPP-Allocate-IP-Type ]
[ TWAN-Identifier ]
[ 3GPP-UE-Local-IP-Address ]
[ 3GPP-UE-Source-Port ]
* [ AVP ]
16a.4.2 AAA Command
The AAA command, defined in Diameter NASREQ (IETF RFC 7155 [120]), is indicated by the Command-Code field set to 265 and the ‘R’ bit cleared in the Command Flags field., It is sent by the Diameter server to the GGSN/P-GW in response to the AAR command.
The relevant AVPs that are of use for the Gi/Sgi interface are detailed in the ABNF description below. Other valid AVPs for this command are not used for Gi/Sgi purposes and should be ignored by the receiver or processed according to the relevant specifications.
The "Tunneling" AVP may include the "Tunnel-Type" with value 3 to represent L2TP tunnel type, "Tunnel-Medium-Type" and "Tunnel-Server-Endpoint" AVPs. If more than one set of these "Tunneling" AVPs are provided, the optional "Tunnel-Preference" AVP may be provided in each set to identify the relative preference. The Tunnel-Password AVP may be used to authenticate to a remote server.
NOTE: The other optional AVPs within the "Tunneling" AVPs not listed in the above description, can be referred to the IETF RFC 7155 [120] with implementation specific.
The bold marked AVPs in the message format indicate optional AVPs for Gi/Sgi, or modified existing AVPs.
Message Format:
<AA-Answer> ::= < Diameter Header: 265, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Request-Type }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
[ Service-Type ]
* [ Class ]
[ Acct-Interim-Interval ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Failed-AVP ]
[ Idle-Timeout ]
[ Authorization-Lifetime ]
[ Auth-Grace-Period ]
[ Auth-Session-State ]
[ Re-Auth-Request-Type ]
[ Multi-Round-Time-Out ]
[ Session-Timeout ]
* [ Reply-Message ]
[ Origin-State-Id ]
* [ Filter-Id ]
[ Port-Limit ]
[ Prompt ]
[ Callback-Id ]
[ Callback-Number ]
* [ Framed-Compression ]
[ Framed-Interface-Id ]
[ Framed-IP-Address ]
* [ Framed-IPv6-Prefix ]
[ Framed-IPv6-Pool ]
* [ Framed-IPv6-Route ]
* [ Delegated-IPv6-Prefix ]
[ Framed-IP-Netmask ]
* [ Framed-Route ]
[ Framed-Pool ]
[ Framed-IPX-Network ]
[ Framed-MTU ]
[ Framed-Protocol ]
[ Framed-Routing ]
* [ Login-IP-Host ]
* [ Login-IPv6-Host ]
[ Login-LAT-Group ]
[ Login-LAT-Node ]
[ Login-LAT-Port ]
[ Login-LAT-Service ]
[ Login-Service ]
[ Login-TCP-Port ]
* [ NAS-Filter-Rule ]
* [ QoS-Filter-Rule ]
* [ Tunneling ]
* [ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
[ 3GPP-IPv6-DNS-Servers ]
* [ External-Identifier]
* [ AVP ]
16a.4.3 ACR Command
The ACR command, defined in IETF RFC 6733 (Diameter Base) [111], is indicated by the Command-Code field set to 271 and the ‘R’ bit set in the Command Flags field. It is sent by the GGSN/P-GW to the Diameter server to report accounting information for a certain IP-CAN bearer (e.g. PDP context) or an IP-CAN session of a certain user.
The relevant AVPs that are of use for the Gi/Sgi interface are detailed in the ABNF description below. Other valid AVPs for this command are not used for Gi/Sgi purposes and should be ignored by the receiver or processed according to the relevant specifications.
The bold marked AVPs in the message format indicate optional AVPs for Gi/Sgi, or modified existing AVPs. For Sgi, some of the optional 3GPP vendor-specific AVPs listed in the message format below are not applicable. See table 9a in subclause 16a.5 to see the ones that are applicable.
Message Format:
<AC-Request> ::= < Diameter Header: 271, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Accounting-Record-Type }
{ Accounting-Record-Number }
[ Acct-Application-Id ]
[ User-Name ]
[ Origin-State-Id ]
[ Destination-Host ]
[ Event-Timestamp ]
[ Acct-Delay-Time ]
[ NAS-Identifier ]
[ NAS-IP-Address ]
[ NAS-IPv6-Address ]
[ NAS-Port ]
[ NAS-Port-Id ]
[ NAS-Port-Type ]
* [ Class ]
[ Service-Type ]
[ Accounting-Input-Octets ]
[ Accounting-Input-Packets ]
[ Accounting-Output-Octets ]
[ Accounting-Output-Packets ]
[ Acct-Authentic ]
[ Accounting-Auth-Method ]
[ Acct-Session-Time ]
[ Acct-Tunnel-Connection ]
[ Acct-Tunnel-Packets-Lost ]
[ Callback-Id ]
[ Callback-Number ]
[ Called-Station-Id ]
[ Calling-Station-Id ]
* [ Connection-Info ]
[ Originating-Line-Info ]
[ Authorization-Lifetime ]
[ Session-Timeout ]
[ Idle-Timeout ]
[ Port-Limit ]
[ Accounting-Realtime-Required ]
[ Acct-Interim-Interval ]
* [ Filter-Id ]
* [ NAS-Filter-Rule ]
* [ Qos-Filter-Rule ]
[ Framed-Compression ]
[ Framed-Interface-Id ]
[ Framed-IP-Address ]
[ Framed-IP-Netmask ]
* [ Framed-IPv6-Prefix ]
[ Framed-IPv6-Pool ]
* [ Framed-IPv6-Route ]
* [ Delegated-IPv6-Prefix ]
[ Framed-IPX-Network ]
[ Framed-MTU ]
[ Framed-Pool ]
[ Framed-Protocol ]
* [ Framed-Route ]
[ Framed-Routing ]
* [ Login-IP-Host ]
* [ Login-IPv6-Host ]
[ Login-LAT-Group ]
[ Login-LAT-Node ]
[ Login-LAT-Port ]
[ Login-LAT-Service ]
[ Login-Service ]
[ Login-TCP-Port ]
* [ Tunneling ]
* [ Proxy-Info ]
* [ Route-Record ]
[ 3GPP-IMSI]
[ External-Identifier]
[ 3GPP-Charging-ID ]
[ 3GPP-PDP-Type ]
[ 3GPP-CG-Address ]
[ 3GPP-GPRS-Negotiated-QoS-Profile ]
[ 3GPP-SGSN-Address ]
[ 3GPP-GGSN-Address ]
[ 3GPP-IMSI-MCC-MNC ]
[ 3GPP-GGSN-MCC-MNC ]
[ 3GPP-NSAPI ]
[ 3GPP-Selection-Mode ]
[ 3GPP-Charging-Characteristics ]
[ 3GPP-CG-IPv6-Address ]
[ 3GPP-SGSN-IPv6-Address ]
[ 3GPP-GGSN-IPv6-Address ]
[ 3GPP-SGSN-MCC-MNC ]
[ 3GPP-IMEISV ]
[ 3GPP-RAT-Type ]
[ 3GPP-User-Location-Info ]
[ 3GPP-MS-Time-Zone ]
[ 3GPP-CAMEL-Charging-Info ]
[ 3GPP-Packet-Filter ]
[ 3GPP-Negotiated-DSCP ]
[ TWAN-Identifier ]
[ 3GPP-User-Location-Info-Time ]
* [ 3GPP-Secondary-RAT-Usage ]
[ 3GPP-UE-Local-IP-Address ]
[ 3GPP-UE-Source-Port ]
* [ AVP ]
16a.4.4 ACA Command
The ACA command, defined in Diameter Base (IETF RFC 6733 [111]), is indicated by the Command-Code field set to 271 and the ‘R’ bit cleared in the Command Flags field., It is sent by the Diameter server to the GGSN/P-GW in response to the ACR command.
The relevant AVPs that are of use for the Gi/Sgi interface are detailed in the ABNF description below. Other valid AVPs for this command are not used for Gi/Sgi purposes and should be ignored by the receiver or processed according to the relevant specifications.
Message Format:
<AC-Answer> ::= < Diameter Header: 271, PXY >
< Session-Id >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
{ Accounting-Record-Type }
{ Accounting-Record-Number }
[ Acct-Application-Id ]
[ User-Name ]
[ Event-Timestamp ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Failed-AVP ]
[ Origin-State-Id ]
[ NAS-Identifier ]
[ NAS-IP-Address ]
[ NAS-IPv6-Address ]
[ NAS-Port ]
[ NAS-Port-Id ]
[ NAS-Port-Type ]
[ Service-Type ]
[ Accounting-Realtime-Required ]
[ Acct-Interim-Interval ]
* [ Class ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
16a.4.5 STR Command
The STR command, defined in IETF RFC 6733 (Diameter Base) [111], is indicated by the Command-Code field set to 275 and the ‘R’ bit set in the Command Flags field. It is sent by the GGSN/P-GW to the Diameter server to terminate a DIAMETER session corresponding to an IP-CAN session of a certain user.
The relevant AVPs that are of use for the Gi/Sgi interface are detailed in the ABNF description below. Other valid AVPs for this command are not used for Gi/Sgi purposes and should be ignored by the receiver or processed according to the relevant specifications.
Message Format:
<ST-Request> ::= < Diameter Header: 275, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Application-Id }
{ Termination-Cause }
[ User-Name ]
[ Destination-Host ]
* [ Class ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
16a.4.6 STA Command
The STA command, defined in IETF RFC 6733 (Diameter Base) [111], is indicated by the Command-Code field set to 275 and the ‘R’ bit cleared in the Command Flags field. It is sent by the Diameter server to the GGSN/P-GW in response to an STR command.
The relevant AVPs that are of use for the Gi/Sgi interface are detailed in the ABNF description below. Other valid AVPs for this command are not used for Gi/Sgi purposes and should be ignored by the receiver or processed according to the relevant specifications.
Message Format:
<ST-Answer> ::= < Diameter Header: 275, PXY >
< Session-Id >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
* [ Class ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Failed-AVP ]
[ Origin-State-Id ]
* [ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
* [ AVP ]
16a.4.7 ASR Command
The Abort-Session-Request (ASR) command, defined in IETF RFC 6733 (Diameter Base) [111], is indicated by the Command-Code set to 274 and the message flags’ ‘R’ bit set, is sent by the Diameter server to the GGSN to request that the PDP Context identified by the 3GPP-NSAPI AVP is to be terminated. The absence of the 3GPP-NSAPI AVP will indicate to the GGSN that all the PDP contexts for this particular user and sharing the same user session need to be deleted. Similarly, for P-GW, the ASR command is sent by the Diamater server to the P-GW to request that the EPS bearer identified by the 3GPP-NSAPI AVP is to be terminated. In the absence of the 3GPP-NSAPI AVP or if the value of 3GPP-NSAPI AVP points to the default EPS bearer, the P-GW shall terminate the IP-CAN session associated with the same user session.
The relevant AVPs that are of use for the Gi/Sgi interface are detailed in the ABNF description below. Other valid AVPs for this command are not used for Gi/Sgi purposes and should be ignored by the receiver or processed according to the relevant specifications.
The bold marked AVPs in the message format indicate optional AVPs for Gi/Sgi, or modified existing AVPs.
Message Format:
<ASR> ::= < Diameter Header: 274, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Destination-Host }
{ Auth-Application-Id }
[ Origin-State-Id ]
* [ Proxy-Info ]
[ 3GPP-NSAPI ]
* [ Route-Record ]
* [ AVP ]
16a.4.8 ASA Command
The Abort-Session-Answer (ASA) command, defined in IETF RFC 6733 (Diameter Base) [111], is indicated by the Command-Code set to 274 and the message flags’ ‘R’ bit clear, is sent in response to the ASR.
The relevant AVPs that are of use for the Gi/Sgi interface are detailed in the ABNF description below. Other valid AVPs for this command are not used for Gi/Sgi purposes and should be ignored by the receiver or processed according to the relevant specifications.
The bold marked AVPs in the message format indicate optional AVPs for Gi/Sgi or modified existing AVPs.
Message Format:
<ASA> ::= < Diameter Header: 274, PXY >
< Session-Id >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
[ Origin-State-Id ]
[ Experimental-Result ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Failed-AVP ]
* [ Redirected-Host ]
[ Redirected-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
* [ AVP ]
The Experimental-Result AVP contains an Experimental-Result-Code AVP and will signal to the Diameter server that the IP-CAN bearer (e.g. PDP context) has been succesfully terminated as requested. See subclause 16a.6 for the description of the Experimental-Result-Code AVP.
16a.5 Gi/Sgi specific AVPs
The following table lists the Gi/Sgi specific Diameter AVPs. The Vendor-Id header of all Gi/Sgi specific AVPs defined in the present specification shall be set to 3GPP (10415).
Table 9a: Gi/Sgi specific AVPs
|
AVP Flag rules |
|||||||||
|
Attribute Name |
AVP Code |
Section defined |
Value Type |
Must |
May |
Should not |
Must not |
May Encr. |
Applicable Reference Points |
|
3GPP-IMSI |
1 |
16.4.7 (see Note) |
UTF8String |
V |
P |
M |
Y |
Gi, Sgi |
|
|
3GPP-Charging-Id |
2 |
16.4.7 (see Note) |
OctetString |
V |
P |
M |
Y |
Gi, Sgi |
|
|
3GPP-PDP-Type |
3 |
16.4.7 (see Note) |
Enumerated |
V |
P |
M |
Y |
Gi, Sgi |
|
|
3GPP-CG-Address |
4 |
16.4.7 (see Note) |
OctetString |
V |
P |
M |
Y |
Gi, Sgi |
|
|
3GPP-GPRS-Negotiated-QoS-Profile |
5 |
16.4.7 (see Note) |
UTF8String |
V |
P |
M |
Y |
Gi, Sgi |
|
|
3GPP-SGSN-Address |
6 |
16.4.7 (see note) |
OctetString |
V |
P |
M |
Y |
Gi, Sgi |
|
|
3GPP-GGSN-Address |
7 |
16.4.7 (see note) |
OctetString |
V |
P |
M |
Y |
Gi, Sgi |
|
|
3GPP-IMSI-MCC-MNC |
8 |
16.4.7 (see note) |
UTF8String |
V |
P |
M |
Y |
Gi, Sgi |
|
|
3GPP-GGSN-MCC-MNC |
9 |
16.4.7 (see note) |
UTF8String |
V |
P |
M |
Y |
Gi, Sgi |
|
|
3GPP-NSAPI |
10 |
16.4.7 (see note) |
OctetString |
V |
P |
M |
Y |
Gi, Sgi |
|
|
3GPP-Selection-Mode |
12 |
16.4.7 (see note) |
UTF8String |
V |
P |
M |
Y |
Gi, Sgi |
|
|
3GPP-Charging-Characteristics |
13 |
16.4.7 (see note) |
UTF8String |
V |
P |
M |
Y |
Gi, Sgi |
|
|
3GPP-CG-IPv6-Address |
14 |
16.4.7 (see note) |
OctetString |
V |
P |
M |
Y |
Gi, Sgi |
|
|
3GPP-SGSN-IPv6-Address |
15 |
16.4.7 (see note) |
OctetString |
V |
P |
M |
Y |
Gi, Sgi |
|
|
3GPP-GGSN-IPv6-Address |
16 |
16.4.7 (see note) |
OctetString |
V |
P |
M |
Y |
Gi, Sgi |
|
|
3GPP-IPv6-DNS-Servers |
17 |
16.4.7 (see note) |
OctetString |
V |
P |
M |
Y |
Gi, Sgi |
|
|
3GPP-SGSN-MCC-MNC |
18 |
16.4.7 (see note) |
UTF8String |
V |
P |
M |
Y |
Gi, Sgi |
|
|
3GPP-IMEISV |
20 |
16.4.7 (see Note) |
OctetString |
V |
P |
M |
Y |
Gi, Sgi |
|
|
3GPP-RAT-Type |
21 |
16.4.7 (see Note) |
OctetString |
V |
P |
M |
Y |
Gi, Sgi |
|
|
3GPP-User-Location-Info |
22 |
16.4.7 (see Note) |
OctetString |
V |
P |
M |
Y |
Gi, Sgi |
|
|
3GPP-MS-TimeZone |
23 |
16.4.7 (see Note) |
OctetString |
V |
P |
M |
Y |
Gi, Sgi |
|
|
3GPP-CAMEL-Charging-Info |
24 |
16.4.7 (see Note) |
OctetString |
V |
P |
M |
Y |
Gi |
|
|
3GPP-Packet-Filter |
25 |
16.4.7 (see Note) |
OctetString |
V |
P |
M |
Y |
Gi, Sgi |
|
|
3GPP-Negotiated-DSCP |
26 |
16.4.7 (see Note) |
OctetString |
V |
P |
M |
Y |
Gi, Sgi |
|
|
3GPP-Allocate-IP-Type |
27 |
16.4.7 (see Note) |
OctetString |
V |
P |
M |
Y |
Gi, Sgi |
|
|
TWAN-Identifier |
29 |
16.4.7 (see Note) |
OctetString |
V |
P |
M |
Y |
Sgi |
|
|
3GPP-User-Location-Info-Time |
30 |
16.4.7 (see Note) |
OctetString |
V |
P |
M |
Y |
Gi, Sgi |
|
|
3GPP-Secondary-RAT-Usage |
31 |
16.4.7 (see Note) |
OctetString |
V |
P |
M |
Y |
Sgi |
|
|
3GPP-UE-Local-IP-Address |
32 |
16.4.7 (see Note) |
OctetString |
V |
P |
M |
Y |
Sgi |
|
|
3GPP-UE-Source-Port |
33 |
16.4.7 (see Note) |
OctetString |
V |
P |
M |
Y |
Sgi |
|
|
NOTE: The use of Radius VSA as a Diameter vendor AVP is described in Diameter NASREQ (IETF RFC 7155 [m]) and the P flag may be set. |
|||||||||
The information represented by some of the Sgi AVPs may not be available to the P-GW depending on the UE’s radio access and the S5/S8 protocol type (GTP or PMIP). For example, the P-GW will be aware of the User Location Info (e.g. TAI) if the user is in LTE access and GTP based S5/S8 is used. However, such information is not passed to the P-GW when PMIP based S5/S8 is utilised. In such scenarios, if an Sgi specific AVP is configured in the P-GW to be transferred to the Diameter AAA server, but the information in the P-GW is not up to date or not available; the P-GW shall not send the corresponding AVP, unless otherwise stated in the AVP definitions in subclause 16.4.7.2.
16a.6 Gi/Sgi specific Experimental-Result-Code AVP
Diameter Base IETF RFC 6733 [111] defines a number of Result-Code AVP values that are used to report protocol errors and how those are used. Those procedures and values apply for the present specification.
Due to the Gi/Sgi specific AVPs, new application results can occur and the Experimental-Result AVP is used to transfer the 3GPP-specific result codes. The Experimental-Result AVP is a grouped AVP containing the Vendor-Id AVP set to the value of 3GPP’s vendor identifier (10415) and an Experimental-Result-Code AVP.
The following Gi/Sgi specific Experimental-Result-Code value is defined:
DIAMETER_PDP_CONTEXT_DELETION_INDICATION (2021)
For GGSN this is an indication to the server that the requested PDP Context or IP-CAN session has been deleted.
For P-GW this is an indication to the server that the requested bearer or IP-CAN session has been deleted.
16a.7 Gi/Sgi re-used AVPs
Table 9b lists the Diameter AVPs re-used by the Gi/Sgi reference point from existing Diameter Applications, reference to the respective specifications and a short description of the usage within the Gi/Sgi reference point.
Table 9b: Gi/Sgi re-used Diameter AVPs
|
Attribute Name |
Reference |
Description |
|---|---|---|
|
External-Identifier |
3GPP TS 29.336 [101] |
A globally unique identifier of a UE used towards external servers instead of IMSI and MSISDN, refer to 3GPP TS 23.682 [100] and 3GPP TS 23.003 [40]. |