12 Interworking with DN-AAA (Diameter)
29.5613GPP5G SystemInterworking between 5G Network and external Data NetworksRelease 17Stage 3TS
12.1 Diameter Procedures
12.1.1 Diameter Authentication and Authorization
The SMF also represents the H-SMF in the home routed scenario in this clause unless specified otherwise.
Diameter Authentication and Authorization shall be used according to IETF RFC 7155 [23]. In 5G, multiple authentication methods using Extensible Authentication Protocol (EAP) may be used such as EAP-TLS (see IETF RFC 5216 [11]), EAP-TTLS (see IETF RFC 5281 [37]). The SMF shall support Diameter EAP application as specified in IETF RFC 4072 [25].
The SMF and the DN-AAA shall advertise the support of the Diameter NASREQ and EAP applications by including the value (1 and 5) of the application identifier in the Auth-Application-Id AVP (as specified in IETF RFC 4072 [25]) and the value of the 3GPP (10415) in the Vendor-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands as specified in IETF RFC 6733 [24], i.e. as part of the Vendor-Specific-Application-Id AVP.
The Diameter client function may reside in an SMF. When the SMF receives an initial access request (i.e. the SMF receives the Nsmf_PDUSession_CreateSMContext request with type "Initial request" for non-roaming case or local breakout case, or the H-SMF receives the Nsmf_PDUSession_Create Request with type "Initial request" for home routed case), the Diameter client function may send the authentication information to a DN-AAA server, which is identified during the DNN provisioning.
When the legacy applications require PAP/CHAP authentication with the UE accessing to the 5GS or to the 5GC and EPC interworking scenario and the legacy DN-AAA server does not support EAP, PAP/CHAP may be used as the authentication protocol, with the external network performing the risk assessment.
The DN-AAA server performs authentication and authorization. The response (when positive) may contain network information, such as an IPv4 address and/or IPv6 prefix for the user when the SMF is interworking with the DN-AAA server.
The information delivered during the Diameter authentication can be used to automatically correlate the user identity (e.g. SUPI) to the IPv4 address and/or IPv6 prefix, if applicable, assigned/confirmed by the SMF or the DN-AAA server respectively. The same procedure applies, in case of sending the authentication to a ‘proxy’ DN-AAA server.
For 5G, Diameter Authentication is applicable to the initial access request. When the SMF receives a positive response from the DN-AAA server it shall complete the initial access procedure. If Access-Reject or no response is received, the SMF shall reject the initial access procedure with a suitable cause code.
When DN-AAA server authorizes the PDU Session Establishment, it may send DN authorization data for the established PDU Session to the SMF. The DN authorization data for the established PDU Session may include one or more of the following:
– a reference to authorization data for policy and charging control locally configured in the SMF;
– a list of allowed MAC addresses (maximum 16) for the Ethernet PDU Session;
– a list of allowed VLAN Ids (maximum 16) for the Ethernet PDU Session;
– Session-AMBR for the PDU Session;
– L2TP information, such as LNS IP address and/or LNS host name; and
– Framed Route information for the PDU Session.
NOTE 1: If the DN-AAA server send L2TP information to SMF, the L2PT information can e.g. be provisioned per DNN/S-NSSAI or per SUPI or GPSI by configuration which is out of the scope of 3GPP specifications.
SMF policies may require DN authorization without DN authentication. In that case, when contacting the DN-AAA server for authorization, the SMF shall provide the GPSI of the UE if available.
The SMF may also use the Diameter re-authorization procedure for the purpose of IPv4 address and/or IPv6 prefix allocation to the UE. The use cases that may lead this procedure are:
– IPv4 address and/or IPv6 prefix allocation after UPF selection during PDU session establishment procedure.
– IPv6 prefix allocation during adding additional PDU Session Anchor procedure for IPv6 multi-homing.
– IPv4 address allocation via DHCPv4 procedure after successful PDU session establishment procedure.
The SMF may also trigger request for DN authentication/authorization and/or IP address/prefix allocation based on UE subscription data retrieve from the UDM as defined in clause 5.2.2.2.5 of 3GPP TS 29.503.
When an IPv4 address and/or IPv6 prefix (including any additional IPv6 prefix of IPv6 multi-homing) is (re-)allocated or de-allocated (not causing the PDU session to be released) by using a method not via the DN-AAA server and if the SMF was required by the DN-AAA server to report such change during authentication procedure or by local configuration, the SMF shall, if applicable, use the authentication session that was established before to inform the DN-AAA server by sending Diameter DER or AAR with the latest list of IPv4 address and/or IPv6 prefix(es).
When the SMF is notified by the UPF regarding the UE MAC address change (a new one is detected or a used one is inactive), if the SMF was required by the DN-AAA server to report such change during authentication procedure or by local configuration, the SMF shall, if applicable, use the authentication session that was established before to inform the DN-AAA server by sending Diameter DER or AAR with the latest list of UE MAC addresses in use.
DN-AAA may initiate QoS flow termination, see details in clause 12.2.3. DN-AAA may initiate re-authorization and optional re-authentication, see details in clause 12.2.4 and 12.2.5.
For the 5GS interworking with EPS scenario, EAP based secondary authentication and re-authentication is not applicable to the PDN connection when the UE is in EPS in this release.
In case EAP based authentication and authorization has been performed for the PDU Session while the UE was in 5GS, and if SMF+PGW-C determines that the UE has moved to the EPS (i.e. the SMF+PGW-C receives the modify bearer request or create session request from the S-GW), the following applies:
– the SMF+PGW-C may initiate Diameter re-authorization procedure without re-authentication with the DN-AAA server based on local policy.
– DN-AAA initiated re-authorization without re-authentication may be performed.
– when the SMF+PGW-C receives a re-authentication request from the DN-AAA server, the SMF+PGW-C shall execute the procedure as described in clause 12.2.5.
NOTE 2: The DN-AAA server decided actions to take (e.g. to request another re-authorization without the association with EAP based re-authentication or release the session) are out of 3GPP scope.
12.1.2 Diameter Accounting
Diameter Accounting shall be used according to IETF RFC 7155 [23].
The SMF and the DN-AAA may advertise the support of the Diameter base accounting application by including the value (3) of the application identifier in the Acct-Application-Id AVP and the value of the 3GPP (10415) in the Vendor-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands as specified in IETF RFC 6733 [24], i.e. as part of the Vendor-Specific-Application-Id AVP.
The Diameter accounting client function may reside in an SMF. The Diameter accounting client may send information to a DN-AAA server, which is identified during the DNN provisioning. The DN-AAA server may store this information and use it to automatically identify the user. This information can be trusted because the 3GPP network has authenticated the subscriber (i.e. USIM card and possibly other authentication methods).
The SMF may use the Diameter Accounting messages during QoS flow (e.g. QoS flow associated with the default QoS rule) establishment and termination procedures, respectively.
If the DN-AAA server is used for IPv4 address and/or IPv6 prefix assignment, then, upon reception of a Diameter Accounting-Request STOP message for all QoS flows associated to a PDU session defined by DNN and SUPI or GPSI, the DN-AAA server may make the associated IPv4 address and/or IPv6 prefix available for assignment.
When an IPv4 address and/or IPv6 prefix (including any additional IPv6 prefix of IPv6 multi-homing) is (re-)allocated or de-allocated (not causing the PDU session to be released) by using a method not via the DN-AAA server and if the SMF was required by the DN-AAA server to report such change during authentication procedure or by local configuration, the SMF shall, if applicable, use the accounting session that was established before to inform the DN-AAA server by sending Diameter Accounting-Request Interim-Update with the latest list of IPv4 address and/or IPv6 prefix(es).
When the SMF is notified by the UPF regarding the UE MAC address change (a new one is detected or a used one is inactive), if the SMF was required by the DN-AAA server to report such change during authentication procedure or by local configuration, the SMF shall, if applicable, use the accounting session that was established before to inform the DN-AAA server by sending Diameter Accounting-Request Interim-Update with the latest list of UE MAC addresses in use.
12.2 Message flows on N6 interface
12.2.1 Authentication, Authorization and Accounting procedures
The SMF also represents the H-SMF in the home routed scenario in this clause unless specified otherwise.
When an SMF receives an initial access request (i.e. the SMF receives the Nsmf_PDUSession_CreateSMContext request with type "Initial request" for non-roaming case or local breakout case, or the H-SMF receives the Nsmf_PDUSession_Create Request with type "Initial request" for home routed case) message for a given DNN, the SMF may (depending on the configuration for this DNN) send a Diameter DER message to a DN-AAA server. The SMF may also (depending on the configuration for this DNN) send the S-NSSAI and the PDU Session ID that are associated with the PDU Session, respectively in the 3GPP-Session-S-NSSAI AVP and the 3GPP-Session-Id AVP, to a DN-AAA server. Upon receipt of the DER message, the DN-AAA server shall respond with an DEA message. Multi-round authentication using the DEA and DER messages may be used. The DN-AAA server finally authenticates and authorizes the user by replying with the DEA message. If the DN-AAA server is also responsible for IPv4 address and/or IPv6 prefix allocation, the DN-AAA server shall return the allocated IPv4 address and/or IPv6 prefix in the DEA message.
For re-authentication and re-authorization, the SMF shall send a DER message to the DN-AAA server and the DN-AAA server shall respond with a DEA message. Multi-round authentication using the DEA and DER messages may be used. The DN-AAA server finally authenticates and authorizes the user by replying with the DEA message.
The SMF may initiate Diameter re-authorization procedures for the purpose of IPv4 address and/or IPv6 prefix allocation (or renew the lease). In this case, the SMF shall set the Session-Id to the value used in the initial 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. If the SMF is using DHCP signalling towards the UE and the DN-AAA server includes the Session-Timeout attribute in the Access-Accept, the SMF may use the Session-Timeout value as the DHCP lease time. The SMF shall not set the DHCPv4 lease time value higher than the Session-Timeout value. The SMF may renew the DHCP lease to the UE without re-authorization towards the DN-AAA server providing that the new lease expiry is no later than the Session-Timeout timer expiry. If the SMF wishes to extend the lease time beyond the current Session-Timeout expiry, it shall initiate a new AAA re-authorization.
Even if the SMF was not involved in user authentication, it may send a Diameter Accounting-Request (START) message to a DN-AAA server. If no Diameter session is already open for the same PDU session a Diameter session needs to be activated, otherwise the existing Diameter session is used to send the Accounting-Request (START). If accounting is used per QoS flow, the QFI will identify the particular bearer this accounting message refers to. 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, the 3GPP-Charging-Id AVP or 3GPP-Charging-Id-v2 AVP according to the length of the Charging Id for the user session. This message may also (depending on the configuration for the DNN) contains the S-NSSAI and the PDU Session ID that are associated with the PDU Session, respectively in the 3GPP-Session-S-NSSAI AVP and the 3GPP-Session-Id AVP, and/or AF traffic influence PCC rule provisioned and then SMF used DNAI in the 3GPP-DNAI AVP, to a DN-AAA server. This message also indicates to the DN-AAA 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 DNN (SMF) may be configured in such a way that the SMF drops user data until an Accounting-Answer (START) indicating success is received from the DN-AAA server. The SMF may wait for the Accounting-Answer (START) before sending the final authentication response message in Namf_Communication_N1N2MessageTransfer service operation. The SMF 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 DNN.
For IPv4 PDU type, if IPv4 address is allocated via DHCPv4 signalling between the UE and the DN-AAA after PDU session establishment, the SMF may wait to send the Accounting-Request START message until the UE receives its IPv4 address in a DHCPACK.
When the SMF receives a message indicating a QoS flow or PDU session release request and providing a Diameter Accounting-Request START message was sent previously, the SMF shall send a Diameter Accounting-Request (STOP) message to the DN-AAA server, which indicates the termination of this particular QoS flow or PDU session. The SMF shall immediately send the corresponding response (e.g. Nsmf_PDUSession_UpdateSMContext response) to the AMF, without waiting for an Accounting-Answer (STOP) message from the DN-AAA server.
If the last QoS flow of a PDU session is deactivated, the SMF shall additionally send an STR message to the DN-AAA server. The DN-AAA server shall reply with an STA message and shall deallocate the IPv4 address and/or IPv6 prefix initially allocated to the subscriber.
The following figure 12.2.1-1 is an example message flow to show the procedure of Diameter Authentication and Accounting between an SMF and a DN-AAA server:
1. UE initiates the PDU Session Establishment procedure, including authentication/authorization information.
2. The AMF sends Nsmf_PDUSession_CreateSMContext Request including the authentication/authorization information to the SMF and the SMF responds to the service operation.
According to the configuration in the SMF, step 6 to step 9 are executed before step 3 if the SMF needs to send an EAP-Request message to the UE.
In the case of home routed, the AMF sends Nsmf_PDUSession_CreateSMContext Request including the authentication/authorization information to the V-SMF and the V-SMF sends Nsmf_PDUSession_Create Request including the authentication/authorization information to the H-SMF.
3. If the N4 session has not been established before, the SMF triggers the N4 Session Establishment procedure to the UPF.
In the case of home routed, the V-SMF triggers the N4 Session Establishment procedure to the V-UPF and the H-SMF triggers the N4 Session Establishment procedure to the H-UPF.
4. The SMF sends the DER message to the DN-AAA via the UPF, the message is forwarded from the SMF to the DN-AAA by the UPF in N4 user plane message.
In the case of home routed, the H-SMF sends the Access-Request message to the DN-AAA via the H-UPF, the message is forwarded from the H-SMF to the DN-AAA by the H-UPF in N4 user plane message.
5-10. The DN-AAA responds with the DEA message to the SMF via the UPF, the message is forwarded from the DN-AAA to the SMF by the UPF in N4 user plane message. The authentication/authorization information is further transferred to UE via Namf_Communication_N1N2MessageTransfer service and NAS SM Transport message. UE responds to the received authentication/authorization data and such information is transferred in NAS SM Transport message and Nsmf_PDUSession_UpdateSMContext service, then finally sent to the DN-AAA by the SMF, via the UPF, in the DER message.
In the case of home routed, the DN-AAA responds with the Access-Challenge message to the H-SMF via the H-UPF, the message is forwarded from the DN-AAA to the H-SMF by the H-UPF in N4 user plane message. The authentication/authorization information is transferred to V-SMF via Nsmf_PDUSession_Update service and is further transferred to UE via Namf_Communication_N1N2MessageTransfer service and NAS SM Transport message. UE responds to the received authentication/authorization data and such information is transferred in NAS SM Transport message, Nsmf_PDUSession_UpdateSMContext service and Nsmf_PDUSession_Update servic, then finally sent to the DN-AAA by the H-SMF, via the H-UPF, in the Access-Request message.
NOTE: Step 5 to step 10 can be repeated depending on the authentication/authorization mechanism used (e.g. EAP-TLS).
11. The SMF receives final result of authentication/authorization from the DN-AAA in the DEA message, via the UPF.
12. The SMF requests to start accounting by sending the Accounting-Request (START) message to the DN-AAA via the UPF.
13. The SMF proceeds with the PDU session establishment procedure and includes the authentication/authorization information in Namf_Communication_N1N2MessageTransfer service.
In the case of home routed, the H-SMF proceeds with the PDU session establishment procedure and includes the authentication/authorization information is transferred to V-SMF via Nsmf_PDUSession_Update service and is further transferred to the AMF via Namf_Communication_N1N2MessageTransfer service.
14. The DN-AAA responds with the Accounting-Response (START) message. The SMF may wait for the Accounting-Response (START) before sending the Namf_Communication_N1N2MessageTransfer request in step 13.
In the case of home routed, the H-SMF may wait for the Accounting-Response (START) before sending the Nsmf_PDUSession_Update service in step 13.
15. The AMF sends the NAS PDU Session Establishment Request with the authentication/authorization information to the UE.
16. The UE sends a NAS message Deregistration Request to the AMF.
17. The AMF sends Nsmf_PDUSession_ReleaseSMContext Request to the SMF and the SMF responds to the service operation.
In the case of home routed, the AMF sends Nsmf_PDUSession_ReleaseSMContext Request to the V-SMF and the V-SMF sends the Nsmf_PDUSession_Release Request to the H-SMF.
18-19. The SMF requests to stop accounting by sending the Accounting-Request (STOP) message to the DN-AAA via the UPF and the DN-AAA responds with the Accounting-Response (STOP) message.
Figure 12.2.1-1: Diameter Authentication and Accounting example (successful case)
When PAP/CHAP is used as the authentication protocol with the external DN-AAA server which does not support EAP for the 5GS or for the 5GC and EPC interworking scenarios, the Diameter Authentication procedures refer to the non transparent access procedures in clause 11.2.1 and related Diameter Authentication descriptions in clause 16a.3a.1 in 3GPP TS 29.061 [5] are reused with the following differences:
– the SMF SMF+PGW-C performs the actions specified for the P-GW;
– the external DN-AAA server performs the actions specified for AAA;
– PDU Session Establishment request is sent from the UE to the SMF or SMF+PGW-C instead of or the Activate PDN connection request being sent from the UE to the S-GW and the Create Session request being sent from S-GW to P-GW;
– PDU Session Establishment accept is sent from the SMF or SMF+PGW-C to the UE instead of the Create Session Response message being sent from the P-GW to S-GW and the Activate PDN Connection Accept being sent from S-GW to the UE; and
– PDU Session Establishment reject is sent from the SMF or SMF+PGW-C to the UE instead of the Create Session Response message being sent from the P-GW to the S-GW and the Activate PDN Connection Reject being sent from S-GW to the UE.
12.2.2 Accounting Update
During the life of a QoS flow some information related to this QoS flow may change. The SMF may send an Accounting Request (Interim) to the DN-AAA server upon occurrence of a chargeable event, e.g. RAT change, DNAI change or QoS change. Interim updates are also used when the IPv4 address and/or IPv6 prefix is allocated/released/re-allocated.
NOTE: DNAI change is only applicable when application relocation possible indicated in the AF traffic influenced PCC rule as described in clause 5.6.7 of TS 23.501 [2], align with the DNAI change in UP path management events as described in clause 4.3.6.3 of TS 23.502 [3]. Only the target DNAI is provided in the ACR message. The change from the UP path status where a DNAI applies to a status where no DNAI applies indicating the de-activation of the AF request for AF influence on traffic routing is not supported in this release.
When the SMF receives a signalling request (i.e. Nsmf_PDUSession_UpdateSMContext) that indicates the occurrence of one of these chargeable events, the SMF may send an Accounting Request Interim-Update to the DN-AAA server to update the necessary information related to this QoS flow. It is not necessary for the SMF to wait for the Diameter Accounting Answer message from the DN-AAA server before sending the response for the triggering signalling message (i.e. Namf_Communication_N1N2MessageTransfer). The SMF may delete the QoS flow if the Accounting Answer is not received from the DN-AAA server.
The SMF may also send interim updates at the expiry of an operator configured time limit.
Figure 12.2.2-1 is an example message flow to show the procedure of Diameter accounting update, messages between the SMF and DN-AAA are forwarded by the UPF in N4 user plane message.
Figure 12.2.2-1: Diameter accounting update
For the 5GC and EPC interworking scenario without authentication, authorization, re-authentication and/or re-authorization impacts, if the UE establishes the PDU session through the 5GC and initiates the accounting session, when the SMF+PGW-C determines that the UE has moved to the EPS (i.e. the SMF+PGW-C receives the modify bearer request or create session request from the S-GW), the SMF+PGW-C may perform the accounting session update with the following modifications:
– for the case that the accounting session is initiated per PDU session, the SMF+PGW-C may update the accounting session by including the identifier of the accounting session within the Session-Id AVP, the "EUTRA" within the 3GPP-RAT-Type AVP, the IPv4 address of S-GW within the 3GPP-SGSN-Address AVP or IPv6 address of S-GW within the 3GPP-SGSN-IPv6-Address AVP, the default EPS bearer id within the 3GPP-NSAPI AVP, the user location in the EPC within the 3GPP-User-Location-Info AVP if available and the new QoS profile within the 3GPP-GPRS-Negotiated-QoS-Profile AVP if changed.
– for the case that the accounting session is initiated per QoS flow:
– if the SMF+PGW-C mapped a QoS flow to an EPS bearer, the SMF may update the accounting session corresponding to the QoS flow with the information of the EPS bearer by including the identifier of the accounting session within the Session-Id AVP, the "EUTRA" within the 3GPP-RAT-Type AVP, the IPv4 address of S-GW within the 3GPP-SGSN-Address AVP or IPv6 address of S-GW within the 3GPP-SGSN-IPv6-Address AVP, the default EPS bearer id within the 3GPP-NSAPI AVP, the user location in the EPC within the 3GPP-User-Location-Info AVP if available and the new QoS profile within the 3GPP-GPRS-Negotiated-QoS-Profile AVP if changed, the new charging id within the 3GPP-Charging-Id AVP or 3GPP-Charging-Id-v2 AVP according to the length of the Charging Id if allocated and the new packet filters within the 3GPP-Packet-Filter AVP if changed;
– if the SMF+PGW-C mapped multiple QoS flows to one EPS bearer, the SMF shall select one of the accounting sessions corresponding to these QoS flows to update it as above and terminate the accounting session(s) corresponding to the other QoS flow(s).
– if the SMF+PGW-C did not map a QoS flow to any EPS bearer, the SMF may decide to associate the corresponding account session to the default EPS bearer or terminate the corresponding accounting session.
12.2.3 DN-AAA initiated QoS flow termination
Diameter is used as the protocol between the SMF and the DN-AAA server or proxy for applications (e.g. MMS) to deliver information related to user session. However some IP applications could need to interwork with the SMF to release the corresponding resource (e.g. terminate a particular QoS flow). For this purpose, the DN-AAA server or proxy may send a Diameter ASR along with the QoS flow Identifier in 3GPP-NSAPI, if available, to identify the particular QoS flow to be terminated to the SMF. The SMF should react by deleting the corresponding QoS flow and reply with ASA. If the SMF deletes the corresponding QoS flow, it is not necessary for the SMF to wait for the response (i.e. Nsmf_PDUSession_UpdateSMContext) from the AMF before sending the ASA to the DN-AAA server.
The absence of the QoS flow Identifier in the Diameter ASR message indicates to the SMF that all QoS flows for this particular user and sharing the same user session shall be deleted. The QoS flows belonging to the same PDU session are identified by the Diameter Session-Id. If a user has the same user IP address for different sets of QoS flows towards different networks, only the QoS flows linked to the one identified by the Diameter Session-Id shall be deleted.
Figure 12.2.3-1 is an example message flow to show the procedure of DN-AAA initiated QoS flow termination, messages between the SMF and DN-AAA are forwarded by the UPF in N4 user plane message.
Figure 12.2.3-1: DN-AAA initiated QoS flow termination with Diameter
For the 5GC and EPC interworking scenario, when the DN-AAA initiates the QoS flow termination, the SMF+PGW-C shall send the delete bearer request to the S-GW as defined in clause 5.4.4.1 of 3GPP TS 23.401 [53] to delete the EPS bearer corresponding to the if the UE has moved to the EPS.
12.2.4 DN-AAA initiated re-authorization
Some IP applications could need to interwork with the SMF to update the PDU session authorization attributes. For this purpose, the DN-AAA server or proxy may send a Diameter RAR with Re-Auth-Request-Type value "AUTHORIZE_ONLY" to the SMF. On receipt of the RAR from the DN-AAA server, the SMF shall update the corresponding PDU session authorization attributes and reply with RAA. DN-AAA may also use such procedure to revoke the authorization of a PDU session, or to update the authorization data (e.g. allowed UE MAC addresses).
If the SMF updates/deletes the corresponding PDU session, it is not necessary for the SMF to wait for Nsmf_PDUSession_UpdateSMContext from the AMF before sending the RAA to the DN-AAA server.
Figure 12.2.4-1 is an example message flow to show the procedure of DN-AAA initiated re-authorization, messages between the SMF and DN-AAA are forwarded by the UPF in N4 user plane message.
Figure 12.2.4-1: DN-AAA initiated re-authorization with Diameter
NOTE: The DN-AAA initiated re-authorization procedure is not applicable for legacy DN-AAA supporting the Diameter procedures over SGi interface as specified in 3GPP TS 29.061 [5].
12.2.5 DN-AAA initiated re-authentication and re-authorization
Some IP applications could need to interwork with the SMF to request re-authentication and re-authorization for the PDU session. For this purpose, the DN-AAA server or proxy may send a Diameter RAR with Re-Auth-Request-Type value "AUTHORIZE_AUTHENTICATE" to the SMF. The RAR should not include any authorization attribute.
NOTE: Since the SMF will initiate authentication procedure upon receipt of the RAR and in the end the DN-AAA will authorize the session, the DN-AAA does not have to apply authorization change immediately.
On receipt of the RAR from the DN-AAA server, the SMF shall reply with RAA and start authentication and authorization procedure as described in figure 12.2.1-1, from step 4 to step 11, step 13 and with PDU SESSION AUTHENTICATION RESULT message (successful case) sent from the AMF to the UE. The Auth-Request-Type in the DER is set to "AUTHORIZE_AUTHENTICATE".
Figure 12.2.5-1 is an example message flow to show the procedure of DN-AAA initiated re-authentication and re-authorization, messages between the SMF and DN-AAA are forwarded by the UPF in N4 user plane message.
When the SMF+PGW-C receives a re-authentication request from the DN-AAA server, the SMF+PGW-C shall inform the DN-AAA server that the re-authentication is not supported with error code 3002 and optionaly the "EUTRA" within the 3GPP-RAT-Type to indicated the UE is in EPS not available for re-authentication. The SMF+PGW-C should not initiate PDN connection release. Based on the result from the SMF, the DN-AAA server may decide to keep the PDU session or request to release the PDU session.
NOTE: As an implementation option, when the UE becomes unreachable, the SMF can mark the re-authentication result as pending and initiate re-authentication at the next uplink activity.
When the SMF receives a re-authentication request from the DN-AAA server, the SMF shall inform the DN-AAA server that the re-authentication is not possible with error code 3002 and optionaly the "NR" within the 3GPP-RAT-Type to indicated the UE is in 5GS not reachable for re-authentication. The SMF should not initiate PDU session release.
Figure 12.2.5-1: DN-AAA initiated re-authentication and re-authorization with Diameter
When PAP/CHAP is used as the authentication protocol with the external DN-AAA server which does not support EAP, the Diameter DN-AAA initiated re-authentication and re-authorization procedures are not applicable.
12.3 N6 specific AVPs
There is no specific AVP defined in the present release.
12.4 N6 re-used AVPs
12.4.0 General
Table 12.4-1 lists the Diameter AVPs re-used by the N6 reference point from existing Diameter Applications, reference to the respective specifications and a short description of the usage within the N6 reference point.
Table 12.4-1: N6 re-used Diameter AVPs
|
Attribute Name |
AVP Code |
Section defined |
Value Type (NOTE 2) |
AVP Flag rules |
May Encr. |
Applicability |
|||
|
Must |
May |
Should not |
Must not |
||||||
|
3GPP-IMSI |
1 |
3GPP TS 29.061 [5] (NOTE 3) |
UTF8String |
V |
P |
M |
Y |
||
|
3GPP-Charging-Id |
2 |
3GPP TS 29.061 [5] (NOTE 3) |
OctetString |
V |
P |
M |
Y |
||
|
3GPP-PDP-Type |
3 |
3GPP TS 29.061 [5] (NOTE 3) |
Enumerated |
V |
P |
M |
Y |
||
|
3GPP-CG-Address |
4 |
3GPP TS 29.061 [5] (NOTE 3) |
OctetString |
V |
P |
M |
Y |
||
|
3GPP-GPRS-Negotiated-QoS-Profile |
5 |
3GPP TS 29.061 [5] (NOTE 3) |
UTF8String |
V |
P |
M |
Y |
||
|
3GPP-SGSN-Address |
6 |
3GPP TS 29.061 [5] (NOTE 3) |
OctetString |
V |
P |
M |
Y |
||
|
3GPP-GGSN-Address |
7 |
3GPP TS 29.061 [5] (NOTE 3) |
OctetString |
V |
P |
M |
Y |
||
|
3GPP-IMSI-MCC-MNC |
8 |
3GPP TS 29.061 [5] (NOTE 3) |
UTF8String |
V |
P |
M |
Y |
||
|
3GPP-GGSN-MCC-MNC |
9 |
3GPP TS 29.061 [5] (NOTE 3) |
UTF8String |
V |
P |
M |
Y |
||
|
3GPP-NSAPI |
10 |
3GPP TS 29.061 [5] (NOTE 3) |
OctetString |
V |
P |
M |
Y |
||
|
3GPP-Selection-Mode |
12 |
3GPP TS 29.061 [5] (NOTE 3) |
UTF8String |
V |
P |
M |
Y |
||
|
3GPP-Charging-Characteristics |
13 |
3GPP TS 29.061 [5] (NOTE 3) |
UTF8String |
V |
P |
M |
Y |
||
|
3GPP-CG-IPv6-Address |
14 |
3GPP TS 29.061 [5] (NOTE 3) |
OctetString |
V |
P |
M |
Y |
||
|
3GPP-SGSN-IPv6-Address |
15 |
3GPP TS 29.061 [5] (NOTE 3) |
OctetString |
V |
P |
M |
Y |
||
|
3GPP-GGSN-IPv6-Address |
16 |
3GPP TS 29.061 [5] (NOTE 3) |
OctetString |
V |
P |
M |
Y |
||
|
3GPP-IPv6-DNS-Servers |
17 |
3GPP TS 29.061 [5] (NOTE 3) |
OctetString |
V |
P |
M |
Y |
||
|
3GPP-SGSN-MCC-MNC |
18 |
3GPP TS 29.061 [5] (NOTE 3) |
UTF8String |
V |
P |
M |
Y |
||
|
3GPP-IMEISV |
20 |
3GPP TS 29.061 [5] (NOTE 3) |
OctetString |
V |
P |
M |
Y |
||
|
3GPP-RAT-Type |
21 |
3GPP TS 29.061 [5] (NOTE 3) |
OctetString |
V |
P |
M |
Y |
||
|
3GPP-User-Location-Info |
22 |
3GPP TS 29.061 [5] (NOTE 3) |
OctetString |
V |
P |
M |
Y |
||
|
3GPP-MS-TimeZone |
23 |
3GPP TS 29.061 [5] (NOTE 3) |
OctetString |
V |
P |
M |
Y |
||
|
3GPP-Packet-Filter |
25 |
3GPP TS 29.061 [5] (NOTE 3) |
OctetString |
V |
P |
M |
Y |
||
|
3GPP-Negotiated-DSCP |
26 |
3GPP TS 29.061 [5] (NOTE 3) |
OctetString |
V |
P |
M |
Y |
||
|
3GPP-Allocate-IP-Type |
27 |
3GPP TS 29.061 [5] (NOTE 3) |
OctetString |
V |
P |
M |
Y |
||
|
External-Identifier |
28 |
3GPP TS 29.061 [5] (NOTE 3) |
OctetString |
V |
P |
M |
Y |
||
|
TWAN-Identifier |
29 |
3GPP TS 29.061 [5] (NOTE 3) |
OctetString |
V |
P |
M |
Y |
||
|
3GPP-User-Location-Info-Time |
30 |
3GPP TS 29.061 [5] (NOTE 3) |
OctetString |
V |
P |
M |
Y |
||
|
3GPP-Secondary-RAT-Usage |
31 |
3GPP TS 29.061 [5] (NOTE 3) |
OctetString |
V |
P |
M |
Y |
||
|
3GPP-UE-Local-IP-Address |
32 |
3GPP TS 29.061 [5] (NOTE 3) |
OctetString |
V |
P |
M |
Y |
||
|
3GPP-UE-Source-Port |
33 |
3GPP TS 29.061 [5] (NOTE 3) |
OctetString |
V |
P |
M |
Y |
||
|
3GPP-Notification |
110 |
11.3.1 |
OctetString |
V |
P |
M |
Y |
||
|
3GPP-UE-MAC-Address |
111 |
11.3.1 |
OctetString |
V |
P |
M |
Y |
||
|
3GPP-Authorization-Reference |
112 |
11.3.1 |
OctetString |
V |
P |
M |
Y |
||
|
3GPP-Policy-Reference |
113 |
11.3.1 |
OctetString |
V |
P |
M |
Y |
NOTE 4 |
|
|
3GPP-Session-AMBR |
114 |
11.3.1 |
OctetString |
V |
P |
M |
Y |
||
|
3GPP-NAI |
115 |
11.3.1 |
OctetString |
V |
P |
M |
Y |
||
|
3GPP-Session-AMBR-v2 |
116 |
11.3.1 |
OctetString |
V |
P |
M |
Y |
eSessionAMBR |
|
|
3GPP-IP-Address-Pool-Info |
118 |
11.3.1 |
OctetString |
V |
P |
M |
Y |
||
|
3GPP-VLAN-Id |
119 |
11.3.1 |
OctetString |
V |
P |
M |
Y |
||
|
3GPP-TNAP-Identifier |
120 |
11.3.1 |
OctetString |
V |
P |
M |
Y |
||
|
3GPP-HFC-NodeId |
121 |
11.3.1 |
OctetString |
V |
P |
M |
Y |
||
|
3GPP-GLI |
122 |
11.3.1 |
OctetString |
V |
P |
M |
Y |
||
|
3GPP-Line-Type |
123 |
11.3.1 |
OctetString |
V |
P |
M |
Y |
||
|
3GPP-NID |
124 |
11.3.1 |
OctetString |
V |
P |
M |
Y |
||
|
3GPP-Session-S-NSSAI |
125 |
11.3.1 |
OctetString |
V |
P |
M |
Y |
||
|
3GPP-CHF-FQDN |
126 |
11.3.1 |
OctetString |
V |
P |
M |
Y |
||
|
3GPP-Serving-NF-FQDN |
127 |
11.3.1 |
OctetString |
V |
P |
M |
Y |
||
|
3GPP-Session-Id |
128 |
11.3.1 |
OctetString |
V |
P |
M |
Y |
||
|
3GPP-GCI |
129 |
11.3.1 |
OctetString |
V |
P |
M |
Y |
||
|
3GPP-DNAI |
130 |
11.3.1 |
OctetString |
V |
P |
M |
Y |
||
|
3GPP-RSN |
131 |
11.3.1 |
OctetString |
V |
P |
M |
Y |
||
|
3GPP-Session-Pair-Id |
132 |
11.3.1 |
OctetString |
V |
P |
M |
Y |
||
|
3GPP-Charging-Id-v2 |
133 |
11.3.1 |
OctetString |
V |
P |
M |
Y |
||
|
Supported-Features |
628 |
3GPP TS 29.229 [41] |
Grouped |
V |
M |
N |
|||
|
NOTE 1: The AVP header bit denoted as ‘M’, indicates whether support of the AVP is required. The AVP header bit denoted as ‘V’, indicates whether the optional Vendor-ID field is present in the AVP header. For further details, see IETF RFC 6733 [24]. NOTE 2: The value types are defined in IETF RFC 6733 [24]. NOTE 3: The use of Radius VSA as a Diameter vendor AVP is described in Diameter NASREQ (IETF RFC 7155 [23]) and the P flag may be set. NOTE 4: It is not used in this release. |
|||||||||
NOTE 1: Attribute 3GPP-CAMEL-Charging-Info (24) is not applicable for 5G in the present specification.
NOTE 2: Table 11.3-2 lists the differences between the RADIUS VSAs used in 5G and the VSAs defined in clause 16.4.7 of 3GPP TS 29.061 [5].
12.4.1 Use of the Supported-Features AVP on the N6 reference point
The Supported-Features AVP is used during session establishment to inform the destination host about the required and optional features that the origin host supports. The client shall, in the first request in a Diameter session indicate the set of supported features. The server shall, in the first answer within the Diameter session indicate the set of features that it has in common with the client and that the server shall support within the same Diameter session. Any further command messages shall always be compliant with the list of supported features indicated in the Supported-Features AVPs during session establishment. Features that are not advertised as supported shall not be used to construct the command messages for that Diameter session. Unless otherwise stated, the use of the Supported-Features AVP on the N6 reference point shall be compliant with the requirements for dynamic discovery of supported features and associated error handling on the Cx reference point as defined in clause 7.2.1 of 3GPP TS 29.229 [41].
The base functionality for the N6 reference point is the 3GPP Rel-15 standard and a feature is an extension to that functionality. If the origin host does not support any features beyond the base functionality, the Supported-Features AVP may be absent from the N6 commands. As defined in clause 7.1.1 of 3GPP TS 29.229 [41], when extending the application by adding new AVPs for a feature, the new AVPs shall have the M bit cleared and the AVP shall not be defined mandatory in the command ABNF.
As defined in 3GPP TS 29.229 [41], the Supported-Features AVP is of type grouped and contains the Vendor-Id, Feature-List-ID and Feature-List AVPs. On the N6 reference point, the Supported-Features AVP is used to identify features that have been defined by 3GPP and hence, for features defined in this document, the Vendor-Id AVP shall contain the vendor ID of 3GPP (10415). If there are multiple feature lists defined for the N6 reference point, the Feature-List-ID AVP shall differentiate those lists from one another.
On receiving an initial request application message, the destination host shall act as defined in clause 7.2.1 of 3GPP TS 29.229 [41].
Once the SMF and DN-AAA have negotiated the set of supported features during session establishment, the set of common features shall be used during the lifetime of the Diameter session.
The table below defines the features applicable to the N6 interfaces for the feature lists with a Feature-List-ID of 1.
Table 12.4.1-1: Features of Feature-List-ID 1 used in N6
|
Feature bit |
Feature |
M/O |
Description |
|
0 |
eSessionAMBR |
M |
This feature indicates the support of enhanced Session AMBR function. If supported, the DN-AAA authorizes DL and/or UL Session AMBR separately. |
|
Feature bit: The order number of the bit within the Feature-List AVP where the least significant bit is assigned number "0". Feature: A short name that can be used to refer to the bit and to the feature, e.g. "5GC". M/O: Defines if the implementation of the feature is mandatory ("M") or optional ("O") in this 3GPP Release. Description: A clear textual description of the feature. |
|||
12.5 N6 specific Experimental-Result-Code AVP
Diameter Base IETF RFC 6733 [24] 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 N6 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 N6 specific Experimental-Result-Code value is defined:
DIAMETER_QOS_FLOW_DELETION_INDICATION (2421)
For SMF this is an indication to the server that the requested 5G QoS flow or PDU session has been deleted.
12.6 N6 Diameter messages
12.6.1 General
This clause describes the N6 Diameter messages.
The relevant AVPs that are of use for the N6 interface are detailed in this clause. Other Diameter AVPs as defined in IETF RFC 4072 [25] and IETF RFC 7155 [23], even if their AVP flag rules are marked with "M", are not required for being compliant with the current specification.
Diameter messages as defined in clause 16a.4 of 3GPP TS 29.061 [5] are re-used in 5G with the following differences:
– SMF or SMF+PGW-C replaces P-GW, and GGSN related description are not applicable for 5G.
– 5G QoS flow replaces IP-CAN/EPS bearer and PDU session replaces IP-CAN session.
– N6 replaces Gi/Sgi.
NOTE: N6 re-used and specific AVPs are specified in clause 12.3 and clause 12.4.
– 3GPP-NAI AVP may be included in the AAR and ACR command.
– 3GPP-NID AVP may be included together with 3GPP-SGSN-MCC-MNC AVP in the AAR and ACR command.
– 3GPP-Session-S-NSSAI AVP and/or 3GPP-Session-Id AVP may be included in the AAR and ACR command.
– 3GPP-DNAI AVP, 3GPP-RSN AVP and/or 3GPP-Session-Pair-Id AVP may be included in the ACR command.
– Multiple 3GPP-IP-Address-Pool-Info AVPs may be included in the AAR command and one or two 3GPP-IP-Address-Pool-Info AVPs may be included in the AAA and ACR command.
– Multiple 3GPP-UE-MAC-Address AVPs may be included in the AAR and ACR command.
– For indicating user location, TWAN-Identifier AVP, 3GPP-TNAP-Identifier AVP, 3GPP-HFC-NodeId AVP, 3GPP-GLI AVP, 3GPP-Line-Type AVP, 3GPP-UE-Local-IP-Address and optionally UDP or TCP source port number (if NAT is detected) may be included in the AAR and ACR command.
– Acct-Application-Id AVP shall be included in the ACR and ACA command as specified in IETF RFC 7155 [23].
– Additional Diameter messages needed for 5G compared to the 3GPP TS 29.061 [5] are described in the following clauses.
– Multiple Supported-Features AVPs may be included in the ACR and ACA command.
12.6.2 DER Command
The DER command, defined in IETF RFC 4072 [25], is indicated by the Command-Code field set to 268 and the ‘R’ bit set in the Command Flags field. It is sent by the SMF to the DN-AAA server upon reception of an initial access request (e.g. Nsmf_PDUSession_CreateSMContext) message for a given DNN to request user authentication and authorization.
The relevant AVPs that are of use for the N6 interface are detailed in the ABNF description below. Other valid AVPs for this command are not used for N6 purposes and should be ignored by the receiver or processed according to the relevant specifications.
The bold marked AVPs in the message format indicate new optional AVPs for N6, or modified existing AVPs.
Message Format:
<Diameter-EAP-Request> ::= < Diameter Header: 268, 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 ]
{ EAP-Payload }
[ EAP-Key-Name ]
[ Service-Type ]
[ Authorization-Lifetime ]
[ Auth-Grace-Period ]
[ Auth-Session-State ]
[ Callback-Number ]
[ Called-Station-Id ]
[ Calling-Station-Id ]
[ Originating-Line-Info ]
[ Connect-Info ]
* [ Framed-Compression ]
[ Framed-Interface-Id ]
[ Framed-IP-Address ]
* [ Framed-IPv6-Prefix ]
* [ Delegated-IPv6-Prefix ]
[ Framed-IP-Netmask ]
[ Framed-MTU ]
[ Framed-Protocol ]
* [ Tunneling ]
* [ Proxy-Info ]
* [ Route-Record ]
[ External-Identifier ]
[ 3GPP-IMSI ]
[ 3GPP-NAI ]
* [ 3GPP-UE-MAC-Address ]
[ 3GPP-Charging-ID ]
[ 3GPP-Charging-ID-v2 ]
[ 3GPP-PDP-Type ]
[ 3GPP-CG-Address ]
[ 3GPP-CHF-FQDN ]
[ 3GPP-GPRS-Negotiated-QoS-Profile ]
[ 3GPP-SGSN-Address ]
[ 3GPP-GGSN-Address ]
[ 3GPP-Session-S-NSSAI ]
[ 3GPP-Session-Id ]
[ 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-Serving-NF-FQDN ]
[ 3GPP-GGSN-IPv6-Address ]
[ 3GPP-SGSN-MCC-MNC ]
[ 3GPP-NID ]
[ 3GPP-User-Location-Info ]
[ 3GPP-RAT-Type ]
[ 3GPP-Negotiated-DSCP ]
[ 3GPP-Allocate-IP-Type ]
[ TWAN-Identifier ]
[ 3GPP-TNAP-Identifier ]
[ 3GPP-HFC-NodeId ]
[ 3GPP-GCI ]
[ 3GPP-GLI ]
[ 3GPP-Line-Type ]
[ 3GPP-UE-Local-IP-Address ]
[ 3GPP-UE-Source-Port ]
* [ 3GPP-IP-Address-Pool-Info]
* [ Supported-Features ]
* [ AVP ]
12.6.3 DEA Command
The DEA command, defined in IETF RFC 4072 [25], is indicated by the Command-Code field set to 268 and the ‘R’ bit cleared in the Command Flags field. It is sent by the DN-AAA server to the SMF in response to the DER command.
The relevant AVPs that are of use for the N6 interface are detailed in the ABNF description below. Other valid AVPs for this command are not used for N6 purposes and should be ignored by the receiver or processed according to the relevant specifications.
The bold marked AVPs in the message format indicate new optional AVPs for N6, or modified existing AVPs.
Message Format:
<Diameter-EAP-Answer> ::= < Diameter Header: 268, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Request-Type }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
[ EAP-Payload ]
[ EAP-Reissued-Payload ]
[ EAP-Master-Session-Key ]
[ EAP-Key-Name ]
[ Multi-Round-Time-Out ]
[ Accounting-EAP-Auth-Method ]
[ 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 ]
[ Session-Timeout ]
* [ Reply-Message ]
[ Origin-State-Id ]
* [ Filter-Id ]
[ Port-Limit ]
[ 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 ]
* [ NAS-Filter-Rule ]
* [ QoS-Filter-Rule ]
* [ Tunneling ]
* [ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
* [ External-Identifier ]
[ 3GPP-IPv6-DNS-Servers ]
[ 3GPP-Notification ]
0*16 [ 3GPP-UE-MAC-Address ]
0*16 [ 3GPP-VLAN-Id ]
[ 3GPP-Authorization-Reference ]
[ 3GPP-Policy-Reference ]
[ 3GPP-Session-AMBR ]
[ 3GPP-Session-AMBR-v2 ]
0*2 [ 3GPP-IP-Address-Pool-Info]
* [ Supported-Features ]
* [ AVP ]
12.6.4 RAR Command
The RAR command, defined in IETF RFC 7155 [23], is indicated by the Command-Code field set to 258 and the ‘R’ bit set in the Command Flags field. It is sent by the DN-AAA server to the SMF to initiate re-authorization and optional re-authentication service.
The relevant AVPs that are of use for the N6 interface are detailed in the ABNF description below. Other valid AVPs for this command are not used for N6 purposes and should be ignored by the receiver or processed according to the relevant specifications.
The bold marked AVPs in the message format indicate new optional AVPs for N6, or modified existing AVPs.
Message Format:
<RA-Request> ::= < Diameter Header: 258, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
[ Destination-Host ]
{ Auth-Application-Id }
{ Re-Auth-Request-Type }
[ User-Name ]
[ Origin-State-Id ]
[ NAS-Port ]
[ NAS-Port-Id ]
[ NAS-Port-Type ]
[ Service-Type ]
[ Framed-IP-Address ]
[ Framed-IPv6-Prefix ]
[ Framed-Interface-Id ]
[ Called-Station-Id ]
[ Calling-Station-Id ]
[ Originating-Line-Info ]
[ Acct-Session-Id ]
* [ Class ]
[ Reply-Message ]
* [ Proxy-Info ]
* [ Route-Record ]
0*16 [ 3GPP-UE-MAC-Address ]
0*16 [ 3GPP-VLAN-Id ]
[ 3GPP-Authorization-Reference ]
[ 3GPP-Policy-Reference ]
[ 3GPP-Session-AMBR ]
[ 3GPP-Session-AMBR-v2 ]
* [ AVP ]
12.6.5 RAA Command
The RAA command, defined in IETF RFC 7155 [23], is indicated by the Command-Code field set to 258 and the ‘R’ bit set in the Command Flags field. It is sent by the SMF to the DN-AAA server in response to the RAR command.
The relevant AVPs that are of use for the N6 interface are detailed in the ABNF description below. Other valid AVPs for this command are not used for N6 purposes and should be ignored by the receiver or processed according to the relevant specifications.
The bold marked AVPs in the message format indicate new optional AVPs for N6, or modified existing AVPs.
Message Format:
<RA-Answer> ::= < Diameter Header: 258, PXY >
< Session-Id >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
[ Origin-State-Id ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Failed-AVP ]
* [ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
[ Service-Type ]
[ Idle-Timeout ]
[ Authorization-Lifetime ]
[ Auth-Grace-Period ]
[ Re-Auth-Request-Type ]
* [ Class ]
* [ Reply-Message ]
* [ Proxy-Info ]
[ 3GPP-RAT-Type ]
* [ AVP ]