11 Interworking with DN-AAA (RADIUS)

29.5613GPP5G SystemInterworking between 5G Network and external Data NetworksRelease 17Stage 3TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

11.1 RADIUS procedures

11.1.1 RADIUS Authentication and Authorization

The SMF also represents the H-SMF in the home routed scenario in this clause unless specified otherwise.

RADIUS Authentication and Authorization shall be used according to IETF RFC 2865 [8], IETF RFC 3162 [9] and IETF RFC 4818 [10]. 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 implement the RADIUS extension to support EAP as specified in IETF RFC 3579 [7].

The RADIUS 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 RADIUS 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 RADIUS 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, RADIUS Authentication is applicable to the initial access request. When the SMF receives an Access-Accept message 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 or PCF;

– 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: 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 RADIUS 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 RADIUS Access-Request 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 RADIUS Access-Request with the latest list of UE MAC addresses in use.

DN-AAA may initiate QoS flow termination and re-authorization, see details in clause 11.2.3 and clause 11.2.4. In the present release, the DN-AAA initiated re-authentication is not supported.

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 RADIUS 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.

11.1.2 RADIUS Accounting

RADIUS Accounting shall be used according to IETF RFC 2866 [26], IETF RFC 3162 [9] and IETF RFC 4818 [10].

The RADIUS accounting client function may reside in an SMF. The RADIUS 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 RADIUS Accounting-Request Start and Stop messages during QoS flow (e.g. QoS flow associated with the default QoS rule) establishment and termination procedures, respectively.

The use of Accounting-Request STOP and in addition the Accounting ON and Accounting OFF messages may be used to ensure that information stored in the DN-AAA server is synchronised with the SMF information.

If the DN-AAA server is used for IPv4 address and/or IPv6 prefix assignment, then, upon reception of a RADIUS 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 RADIUS 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 RADIUS Accounting-Request Interim-Update with the latest list of UE MAC addresses in use.

In order to avoid race conditions, the SMF shall include a 3GPP Vendor-Specific sub-attribute "Session Stop indicator" when it sends the Accounting-Request STOP for the last QoS flow of a PDU session and the PDU session is terminated (i.e. the IPv4 address and/or IPv6 prefix and any associated GTP tunnel can be released). The DN-AAA server shall not assume the PDU session terminated until an Accounting-Request STOP with the Session Stop indicator is received.

11.2 Message flows on N6 interface

11.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 RADIUS Access-Request message with EAP extension 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 VSA and the 3GPP-Session-Id VSA, to a DN-AAA server. Upon receipt of the Access-Request message, the DN-AAA server shall respond with an Access-Challenge message. Multi-round authentication using the Access-Challenge (sent by DN-AAA) and Access-Request messages may be used. The DN-AAA server finally authenticates and authorizes the user by replying with an Access Accept 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 Access-Accept message.

For re-authentication and re-authorization, the SMF shall send a RADIUS Access-Request message with EAP extension and the DN-AAA shall respond with an Access-Challenge message. Multi-round authentication using the Access-Challenge (sent by DN-AAA) and Access-Request messages may be used. The DN-AAA server finally authenticates and authorizes the user by replying with an Access Accept message.

The SMF may initiate RADIUS 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 Service-Type attribute to "Authorize Only" and the 3GPP-Allocate-IP-Type subattribute to the type of IP address to be allocated in the Access-Request message sent to the DN-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 DHCP 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 RADIUS Accounting-Request (START) message to a DN-AAA server. This message may contain 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 VSA or 3GPP-Charging-Id-v2 VSA 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 VSA and the 3GPP-Session-Id VSA, and/or AF traffic influence PCC rule provisioned and then SMF used DNAI in the 3GPP-DNAI VSA, to a DN-AAA server. This message also indicates to the AAA server that the user session has started. The user session is uniquely identified by the Acct-Session-Id that is composed of the Charging ID and the SMF IP address.

NOTE: If the accounting session is required by the DN-AAA server to be created per QoS flow, how to identify the different accounting sessions is implementation specific. The SMF can include the Acct-Session-Id which is extended to include the QFI of the QoS flow or the Acct-Session-Id without QFI extension and with 3GPP-NSAPI combination in the RADIUS Accounting-Request (START).

If some external applications require RADIUS Accounting-Request (START) information before they can process user packets, then the selected DNN (SMF) may be configured in such a way that the UPF is instructed to drop user data until the Accounting-Response (START) is received from the AAA server. The SMF may wait for the Accounting-Response (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-Response (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 RADIUS Accounting-Request (START) message was sent previously, the SMF shall send a RADIUS 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-Response (STOP) message from the DN-AAA server.

The DN-AAA server shall deallocate the IPv4 address and/or IPv6 prefix initially allocated to the subscriber, if there is no session for the subscriber.

Accounting-Request (ON) and Accounting-Request (OFF) messages may be sent from the SMF to the DN-AAA server to ensure the correct synchronization of the session information in the SMF and the DN-AAA server.

The SMF may send an Accounting-Request (ON) message to the DN-AAA server to indicate that a restart has occurred. The DN-AAA server may then release the associated resources.

Prior to a scheduled restart, the SMF may send Accounting-Request (OFF) message to the DN-AAA server. The DN-AAA server may then release the associated resources.

The following figure 11.2.1-1 is an example message flow to show the procedure of RADIUS 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 Access-Request 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 Access-Challenge 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 Access-Request 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 the final result of authentication/authorization from the DN-AAA in the Access-Accept 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 11.2.1-1: RADIUS 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 RADIUS Authentication procedures refer to the non transparent access procedures in clause 11.2.1 and the related RADIUS Authentication description in clause 16.3a.1 in 3GPP TS 29.061 [5] are reused with the following differences:

– the SMF or 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 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.

11.2.2 Accounting Update

During the life of a QoS flow some information related to this QoS flow may change. The SMF may send RADIUS Accounting Request Interim-Update 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 RADIUS AccountingResponse 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 AccountingResponse 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 11.2.2-1 is an example message flow to show the procedure of RADIUS accounting update, messages between the SMF and DN-AAA are forwarded by the UPF in N4 user plane message.

Figure 11.2.2-1: RADIUS 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 Acct-Session-Id, the "EUTRA" within the 3GPP-RAT-Type, the IPv4 address of S-GW within the 3GPP-SGSN-Address, the default EPS bearer id within the 3GPP-NSAPI, the user location in the EPC within the 3GPP-User-Location-Info if available and the new QoS profile within the 3GPP-GPRS-Negotiated-QoS-Profile 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 Acct-Session-Id, the "EUTRA" within the 3GPP-RAT-Type, the IPv4 address of S-GW within the 3GPP-SGSN-Address, the EPS bearer id within the 3GPP-NSAPI, the user location in the EPC within the 3GPP-User-Location-Info if available, the new QoS profile within the 3GPP-GPRS-Negotiated-QoS-Profile if changed, the new charging id within the 3GPP-Charging-Id VSA or 3GPP-Charging-Id-v2 VSA according to the length of the Charging Id if allocated and the new packet filters within the 3GPP-Packet-Filter if changed;

– if the SMF+PGW-C mapped multiple QoS flows to one EPS bearer, the SMF shall select one of the accouting 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.

11.2.3 DN-AAA initiated QoS flow termination

RADIUS 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 RADIUS Disconnect-Request to the SMF. On receipt of the Disconnect-Request from the DN-AAA server, the SMF shall release the corresponding resources and reply with a Disconnect-ACK. If the SMF is unable to release the corresponding resources, it shall reply to the DN-AAA server with a Disconnect-NAK. For more information on RADIUS Disconnect, see IETF RFC 5176 [27]. 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 RADIUS Disconnect-ACK to the DN-AAA server. The DN-AAA shall include the identification of the QoS flow to be disconnected within the Disconnect-Request. How to identify the QoS flow to be deleted is implementation specific.

NOTE: The QoS flow can be identified by the Acct-Session-Id which is extended to include QFI or by the Acct-Session-Id and 3GPP-NSAPI combination if provided by the SMF.

The Teardown-Indicator in the RADIUS Disconnect Request 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 that belong to the same PDU session can be are identified by the Acct-Session-Id. The SMF is able to find out all the related QoS flows sharing the same user session once it has found the exact QoS flow from the Acct-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 Acct-Session-Id shall be deleted. If the value of Teardown-Indicator is set to "0" or if TI is missing, and if the Acct-Session-Id and 3GPP-NSAPI if provided identifies the QoS flow associated with the default QoS rule, the SMF shall tear down all the QoS flows that share the same user session identified by the Acct-Session-Id.

Figure 11.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 11.2.3-1: DN-AAA initiated QoS flow termination with RADIUS

For the 5GC and EPC interworking scenario, when the DN-AAA server 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 accounting session if the UE has moved to the EPS.

11.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 RADIUS CoA-Request to the SMF. On receipt of the CoA-Request from the DN-AAA server, if the service-type value of "Authorize Only" is not included, the SMF shall update the corresponding PDU session authorization attributes and reply with a CoA-ACK; otherwise it shall follow the procedure described in IETF RFC 5176 [27]. DN-AAA may also use CoA 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 RADIUS CoA-ACK to the DN-AAA server.

Figure 11.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 11.2.4-1: DN-AAA initiated re-authorization with RADIUS

NOTE: The DN-AAA initiated re-authorization procedure is not applicable for legacy DN-AAA supporting the RADIUS procedures over SGi interface as specified in 3GPP TS 29.061 [5].

11.3 List of RADIUS attributes

11.3.1 General

RADIUS attributes as defined in clause 16.4 of 3GPP TS 29.061 [5] are re-used in 5G with the following differences:

– SMF or SMF+PGW-C replaces P-GW. GGSN and PPP PDP type related description are not applicable for 5G.

– 5G QoS flow replaces IP-CAN bearer and PDU session replaces IP-CAN session.

– N6 replaces Gi/Sgi and UE replaces MS.

– DNN replaces APN.

– Detailed information needed for 5G compared to 3GPP TS 29.061 [5] is described below.

Table 11.3-1: Additional information needed for 5G compared to the RADIUS attributes defined in 3GPP TS 29.061 [5]

Attr #	Attribute Name	Description	Content	Presence Requirement	Applicable message
79	EAP-Message	This attribute encapsulates EAP message (as defined in IETF RFC 3748 [6]) exchanged between the SMF and DN-AAA, see IETF RFC 3579 [7] for details.	String	Conditional NOTE	Access-Request, Access-Accept, Access-Reject, CoA-Request, CoA-ACK, Disconnect-Request, Disconnect-ACK
79	EAP-Message		String	Mandatory	Access-Challenge
80	Message-Authenticator	This attribute includes the message authenticator, see IETF RFC 3579 [7] for details.	String	Conditional NOTE	Access-Request, Access-Accept, Access-Reject, CoA-Request, CoA-ACK, CoA-NAK Disconnect-Request, Disconnect-ACK, Disconnect-NAK
80	Message-Authenticator		String	Mandatory	Access-Challenge
NOTE: Shall be present if EAP is used.

Table 11.3-2: Different information needed for 5G compared to the RADIUS VSA defined in clause 16.4.7 of 3GPP TS 29.061 [5]

Sub-attr #	Sub-attribute Name	Differences
1	3GPP-IMSI	Re-used.
2	3GPP-Charging-Id	Charging ID for this PDU Session.
3	3GPP-PDP-Type	Re-used. For SMF, this sub-attribute represents PDU session type and only the values "0", "2", "3", "5" and "6" are applicable.
4	3GPP-CG-Address	Re-used. IPv4 address of CHF.
5	3GPP-GPRS-Negotiated-QoS-Profile	Re-used. For SMF, it uses the format for Release indicator value "15" as defined in 3GPP TS 29.061 [5].
6	3GPP-SGSN-Address	Re-used. It includes AMF, I-SMF or V-SMF control plane IPv4 address.
7	3GPP-GGSN-Address	Re-used. It includes (home) SMF control plane IPv4 address providing the Nsmf_PDUSession service.
8	3GPP-IMSI-MCC-MNC	Re-used.
9	3GPP-GGSN-MCC-MNC	Re-used. MCC and MNC of the network the (home) SMF belongs to.
10	3GPP-NSAPI	Re-used. It identifies QFI with value range 0-255.
11	3GPP-Session-Stop-Indicator	Re-used.
12	3GPP-Selection-Mode	Re-used. SMF maps the selection mode value from the enumeration value of DnnSelectionMode in 3GPP TS 29.502 [40].
13	3GPP-Charging-Characteristics	Re-used.
14	3GPP-CG-IPv6-Address	Re-used. IPv6 address of CHF.
15	3GPP-SGSN-IPv6-Address	Re-used. It includes AMF, I-SMF or V-SMF control plane IPv6 address.
16	3GPP-GGSN-IPv6-Address	Re-used. It includes (home) SMF control plane IPv6 address providing the Nsmf_PDUSession service.
17	3GPP-IPv6-DNS-Servers	Re-used.
18	3GPP-SGSN-MCC-MNC	Re-used. MCC and MNC of the network the AMF belongs to
19	3GPP-Teardown-Indicator	Re-used.
20	3GPP-IMEISV	Re-used.
21	3GPP-RAT-Type	Re-used. For SMF, it uses the sub-attribute definition for P-GW and only the values "3", "6" – "9", and "51" – "58" are applicable.
22	3GPP-User-Location-Info	Re-used. For SMF, only the values "128", "129", "130", "135" and "136" of Geographic Location Type are applicable.
23	3GPP-MS-TimeZone	Re-used.
24	3GPP-CAMEL-Charging-Info	Not applicable.
25	3GPP-Packet-Filter	Re-used.
26	3GPP-Negotiated-DSCP	Re-used.
27	3GPP-Allocate-IP-Type	Re-used.
28	External-Identifier	Re-used.
29	TWAN-Identifier	Re-used by TWAP Identifier field, supporting ssid, bssid and/or civicAddress.
30	3GPP-User-Location-Info-Time	Re-used.
31	3GPP-Secondary-RAT-Usage	Re-used. For SMF, the RAT values "0", "1", "2" and "3" are applicable, and the SESS field is used to indicate secondary RAT usage of the PDU session.
32	3GPP-UE-Local-IP-Address	Re-used. Extended with TWAN applicability.
33	3GPP-UE-Source-Port	Re-used. Extended with TWAN applicability.
110	3GPP-Notification	Added.
111	3GPP-UE-MAC-Address	Added.
112	3GPP-Authorization-Reference	Added.
113	3GPP-Policy-Reference	Added. It is not used in this release.
114	3GPP-Session-AMBR	Added.
115	3GPP-NAI	Added.
116	3GPP-Session-AMBR-v2	Added.
117	3GPP-Supported-Features	Added.
118	3GPP-IP-Address-Pool-Info	Added.
119	3GPP-VLAN-Id	Added.
120	3GPP-TNAP-Identifier	Added.
121	3GPP-HFC-NodeId	Added.
122	3GPP-GLI	Added.
123	3GPP-Line-Type	Added.
124	3GPP-NID	Added.
125	3GPP-Session-S-NSSAI	Added.
126	3GPP-CHF-FQDN	Added. FQDN of CHF.
127	3GPP-Serving-NF-FQDN	Added. It includes AMF, I-SMF or V-SMF FQDN address.
128	3GPP-Session-Id	Added.
129	3GPP-GCI	Added.
130	3GPP-DNAI	Added.
131	3GPP-RSN	Added.
132	3GPP-Session-Pair-Id	Added.
133	3GPP-Charging-Id-v2	Added. Charging ID for this PDU Session, supporting charging Id length longer than unsiged integer 32 bit.
NOTE: 5G specific RADIUS VSAs are numbered from 110.

110 – 3GPP–Notification

		Bits
Octets	8		7	6	5	4	3		2	1
1	3GPP type = 110
2	3GPP Length= 3
3	Spare							ACC		AUTH

3GPP Type: 110

Length: 3

Octet 3 is Octet String type.

For bit 1 AUTH,

– if the value of AUTH is set to "1", and there is IPv4 address and/or IPv6 prefix change (not allocated/de-allocated by the DN-AAA itself) and the PDU session is not terminated, the SMF shall send Access-Request message to the DN-AAA with GPSI in Calling-Station-Id or External-Identifier attribute and IP address in:

1) Framed-IP-Address and Framed-IPv6-Prefix, if both IPv4 address and IPv6 prefix(es) exist for the PDU session; or

2) Framed-IP-Address, if only IPv4 address exists for the PDU session; or

3) Framed-IPv6-Prefix, if only IPv6 prefix(es) exists for the PDU session.

For Ethernet PDU session, if there is UE MAC address change, the SMF shall send Access-Request message to the DN-AAA with GPSI in Calling-Station-Id or External-Identifier attribute and the complete list of used UE MAC addresses in the 3GPP-UE-MAC-Address attribute.

– if the value is set to "0", the SMF may notify authentication DN-AAA with the UE address and GPSI based on local configuration.

For bit 2 ACC,

– if the value is set to "1", and there is IPv4 address and/or IPv6 prefix change (not allocated/de-allocated by the DN-AAA itself) and the PDU session is not terminated, the SMF shall send Accounting-Request Interim-Update message to the DN-AAA with GPSI in Calling-Station-Id or External-Identifier attribute and IP address in:

1) Framed-IP-Address and Framed-IPv6-Prefix, if both IPv4 address and IPv6 prefix(es) exist for the PDU session; or

2) Framed-IP-Address, if only IPv4 address exists for the PDU session; or

3) Framed-IPv6-Prefix, if only IPv6 prefix(es) exists for the PDU session.

For Ethernet PDU session, if there is UE MAC address change, the SMF shall send Accounting-Request Interim-Update message to the DN-AAA with GPSI in Calling-Station-Id or External-Identifier attribute and the complete list of used UE MAC addresses in the 3GPP-UE-MAC-Address attribute.

– if the value is set to "0", the SMF may notify accounting DN-AAA with the UE address and GPSI based on local configuration.

111 – 3GPP-UE-MAC-Address

	Bits
Octets	8	7	6	5	4	3	2	1
1	3GPP type = 111
2	3GPP Length= 8
3-8	MAC Address (octet string)

3GPP Type: 111

Length: 8

It is sent from the DN-AAA to authorize UE MAC addresses. Multiple 3GPP- UE-MAC-Address sub-attributes (maximum 16) may be sent in one RADIUS CoA or Access-Accept message. The DN-AAA shall always provide the full list of allowed MAC addresses, and SMF shall replace the existing list with the newly received one. When omitted, there is no restriction and all UE MAC addresses are permitted for the Ethernet PDU session.

When sending from the SMF to the DN-AAA, it indicates UE MAC addresses in use. Multiple 3GPP- UE-MAC-Address sub-attributes may be sent in one RADIUS Access-Request or Accounting-Request Interim-Update message.

MAC address is Octet String type. The encoding is defined as MacAddr48 in 3GPP TS 29.571 [39] without dashes as delimiter, encoded as 12-digit hexadecimal numbers.

112 – 3GPP-Authorization-Reference

	Bits
Octets	8	7	6	5	4	3	2	1
1	3GPP type = 112
2	3GPP Length= m
3-m	Authorization Data Reference (octet string)

3GPP Type: 112

Length: m

Authorization Data Reference: Octet String. It is sent from the DN-AAA to refer to the local authorization data in the SMF or PCF.

113 – 3GPP-Policy-Reference

	Bits
Octets	8	7	6	5	4	3	2	1
1	3GPP type = 113
2	3GPP Length= m
3-m	Policy Data Reference (octet string)

3GPP Type: 113

Length: m

Policy Data Reference: Octet String. It is sent from the DN-AAA and used by the SMF to retrieve the SM or QoS policy data from the PCF. It is not used in this release.

114 – 3GPP-Session-AMBR

	Bits
Octets	8	7	6	5	4	3	2	1
1	3GPP type = 114
2	3GPP Length= m
3-m	Session AMBR (octet string)

3GPP Type: 114

Length: m

Session AMBR: Octet String. It is sent from the DN-AAA to authorize the PDU Session AMBR in the downlink and uplink direction. The encoding is defined as BitRate in 3GPP TS 29.571 [39]. Same value is applied to downlink and uplink via this VSA.

115 – 3GPP-NAI

	Bits
Octets	8	7	6	5	4	3	2	1
1	3GPP type = 115
2	3GPP Length= m
3-m	NAI (octet string)

3GPP Type: 115

Length: m

NAI: Octet String. It shall be formatted according to clause 14.3 of 3GPP TS 23.003 [28] that describes an NAI.

116 – 3GPP-Session-AMBR-v2

		Bits
Octets	8		7	6	5	4	3		2	1
1	3GPP type = 116
2	3GPP Length= m
3	Spare							DL		UL
4-5	UL Session-AMBR length (octet string)
6-m	UL Session-AMBR (octet string)
(m+1)-(m+2)	DL Session-AMBR length (octet string)
(m+3)-n	DL Session-AMBR (octet string)

3GPP Type: 116

Length: m

Octet 3 is Octet String type.

Bit 1 UL and bit 2 DL indicate if the corresponding UL and DL Session-AMBR shall be present in a respective field or not. If one of these bits is set to "0", the corresponding field shall not be present at all.

UL/DL Session AMBR: Octet String. It is sent from the DN-AAA to authorize the PDU Session AMBR. The encoding is defined as BitRate in 3GPP TS 29.571 [39].

If the feature eSessionAMBR is supported and if applicable, the DN-AAA shall send this VSA; otherwise, the DN-AAA shall send the VSA 3GPP-Session-AMBR.

117 – 3GPP-Supported-Features

		Bits
Octets	8		7	6	5	4	3	2	1
1	3GPP type = 117
2	3GPP Length= m
3-6	Vendor ID (octet string)
7-10	Feature List ID (octet string)
11-14	Feature List (octet string)

3GPP Type: 117

Length: m

This VSA may be present in the Access-Request (initial one) message and either the Access-Challenge (initial one) or the Access-Accept message. If present, this VSA informs the destination entity about the features that the origin entity requires to successfully complete the message exchange. The Vendor ID, Feature List ID and Feature List are encoded according to 3GPP TS 29.229 [41]. See clause 12.4.1 for more detailed information regarding the general principle of the feature negotiation with the difference that RADIUS terms replace Diameter terms. The table 12.4.1-1 defines the features applicable to the RADIUS N6 interfaces for the feature lists with a Feature-List-ID of 1.

118 – 3GPP-IP-Address-Pool-Info

		Bits
Octets	8		7	6	5	4	3		2	1
1	3GPP type = 118
2	3GPP Length= m
3	Spare							IP version
4-5	IP address pool id length (octet string)
6-m	IP address pool id (octet string)

3GPP Type: 118

Length: m

Octet 3 is Octet String type.

For bit 1 and bit 2 IP version:- if the value is set to "0", it indicates the IP address pool id is applicable for both IPv4 and IPv6;

– if the value is set to "1", it indicates the IP address pool id is applicable for IPv4;

– if the value is set to "2", it indicates the IP address pool id is applicable for IPv6; and

– value "3" is reserved.

The SMF may determine an IP address pool ID based on UPF ID, S-NSSAI, DNN, and IP version as described in clause 5.8.2.2.1 in 3GPP TS 23.501 [2] and includes the IP address pool ID within 3GPP-IP-Address-Pool-Info and send it to the DN-AAA. The DN-AAA assigns IPv6 prefix or IPv4 address from the requested IP address pool. Multiple 3GPP-IP-Address-Pool-Info sub-attributes may be sent in the RADIUS Access-Request message. The DN-AAA shall include the selected IP address pool in the 3GPP-IP-Address-Pool-Info sub-attribute of the RADIUS Access-Accept message. For accounting, if Framed-IP-Address or Framed-IPv6-Prefix attribute is included in RADIUS Accounting-Request (START/Interim-Update/STOP), the SMF shall also include the 3GPP-IP-Address-Pool-Info sub-attribute.

119 – 3GPP-VLAN-Id

		Bits
Octets	8		7	6	5	4		3	2	1
1	3GPP type = 119
2	3GPP Length= 4
3	VID value						Spare
4	VID value

3GPP Type: 119

Length: 4

VLAN Id: Octet String. Octet 3/ Bit 1 to Bit 4 shall be zero, Octet 3 / Bit 8 shall be the most significant bit of the VLAN Id and Octet 4 / Bit 1 shall be the least significant bit.

It is sent from the DN-AAA to authorize the allowed VLAN Ids for the Ethernet PDU session. Multiple 3GPP-VLAN-Id sub-attributes (maximum 16) may be sent in one RADIUS CoA or Access-Accept message. The DN-AAA shall always provide the full list of allowed VLAN Ids, and SMF shall replace the existing list with the newly received one. When omitted, there is no restriction and all VLAN Ids are permitted for the Ethernet PDU session.

120 – 3GPP-TNAP-Identifier

	Bits
Octets	8	7	6	5	4	3	2	1
1	3GPP type = 120
2	3GPP Length= m
3-m	TNAP Identifier (octet string)

3GPP Type: 120

Length: m, where m depends on the type of location that is present as described in 3GPP TS 29.274 [50].

TNAP Identifier field is used to convey the location information in a Trusted Non-3GPP Access Network. The coding of this field shall be the same as for the GTP TWAN Identifier starting with Octet 5, till Octet (q+r) +2 as per clause 8.100 in 3GPP TS 29.274 [50], with LAII flag, OPNAI flag and PLMNI flag in Octet 5 shall be set as zero.

TNAP Identifier field is Octet String type.

The SMF may indicate the UE location in a Trusted Non-3GPP Access Network, in Access-Request, Accounting-Request START, Accounting-Request STOP, or Accounting-Request Interim-Update messages.

121 – 3GPP-HFC-NodeId

	Bits
Octets	8	7	6	5	4	3	2	1
1	3GPP type = 121
2	3GPP Length= n
3-n	HFCNodeId (octet string)

3GPP Type: 121

Length: n≤6+2

HFCNodeId field is the identifier of the HFC node Id as specified in CableLabs WR-TR-5WWC-ARCH [51]. It is provisioned by the wireline operator as part of wireline operations and may contain up to six characters.

HFCNodeId field is Octet String type.

The SMF may indicate the HFC Node Identifier received over NGAP. Present for a 5G-CRG accessing the 5GC via wireline access network, in Access-Request, Accounting-Request START, Accounting-Request STOP, or Accounting-Request Interim-Update messages. Present for a FN-CRG accessing the 5GC via wireline access network, in Accounting-Request START, Accounting-Request STOP, or Accounting-Request Interim-Update messages.

122 – 3GPP-GLI

	Bits
Octets	8	7	6	5	4	3	2	1
1	3GPP type = 122
2	3GPP Length= n
3-n	GLI (octet string)

3GPP Type: 122

Length: n≤150+2

GLI field is the Global Line Identifier uniquely identifying the line connecting the 5G-BRG or FN-BRG to the 5GS. See clause 28.16.3 of 3GPP TS 23.003 [28]. Shall be encoded as a string with format "byte", i.e. base64-encoded characters, representing the GLI value (up to 150 bytes) encoded as specified in BBF WT-470 [52].

GLI field is Octet String type.

The SMF may indicate the Global Line Identifier. Present for a 5G-BRG accessing the 5GC via wireline access network, in Access-Request, Accounting-Request START, Accounting-Request STOP, or Accounting-Request Interim-Update messages. Present for a 5G-BRG accessing the 5GC via wireline access network, in Accounting-Request START, Accounting-Request STOP, or Accounting-Request Interim-Update messages.

123 – 3GPP-Line-Type

	Bits
Octets	8	7	6	5	4	3	2	1
1	3GPP type = 123
2	3GPP Length= 3
3	Line-Type (octet string)

3GPP Type: 123

The Line-Type sub-attribute may be present for a 5G-BRG/FN-BRG accessing the 5GC via wireline access network.

When present, it shall indicate the type of the wireline (DSL or PON).

Line-Type field is Octet String type. It shall be coded as follows:

0 (DSL):

This value shall be used to indicate DSL line.

1 (PON):

This value shall be used to indicate PON line.

The SMF may indicate the type of the wireline (DLS or PON). Present for a 5G-BRG accessing the 5GC via wireline access network, in Access-Request, Accounting-Request START, Accounting-Request STOP, or Accounting-Request Interim-Update messages. Present for a FN-BRG accessing the 5GC via wireline access network, in Accounting-Request START, Accounting-Request STOP, or Accounting-Request Interim-Update messages.

124 – 3GPP-NID

	Bits
Octets	8	7	6	5	4	3	2	1
1	3GPP type = 124
2	3GPP Length= 13
3-13	Network ID (octet string)

3GPP Type: 124

Length: 13

The Network ID field is Octet String type. The encoding is defined as Nid in 3GPP TS 29.571 [39].

Table 11.3-3 describes the sub-attributes of the 3GPP Vendor-Specific attribute described above in different RADIUS messages.

125 – 3GPP-Session-S-NSSAI

	Bits
Octets	8	7	6	5	4	3	2	1
1	3GPP type = 125
2	3GPP Length= m
3	SST
4-6	SD (octet string)

3GPP Type: 125

Length: 3 or 6

SST: the Slice/Service Type with value range 0 to 255.

SD: 3-octet string, representing the Slice Differentiator, the encoding follows sd attribute specified in clause 5.4.4.2 of 3GPP TS 29.571 [46]. Its presence depends on the Length field.

It is sent from the SMF to the DN-AAA server to indicate the S-NSSAI that is associated with the PDU Session.

126 – 3GPP-CHF-FQDN

	Bits
Octets	8	7	6	5	4	3	2	1
1	3GPP type = 126
2	3GPP Length= m
3-m	CHF FQDN

3GPP Type: 126

Length: m

CHF FQDN: string, indicates the FQDN of the CHF.

It is sent from the SMF to the DN-AAA server to indicate the FQDN of the CHF.

127 – 3GPP-Serving-NF-FQDN

	Bits
Octets	8	7	6	5	4	3	2	1
1	3GPP type = 127
2	3GPP Length= m
3-m	Serving NF FQDN

3GPP Type: 127

Length: m

Serving NF FQDN: string, indicates the FQDN of the Serving NF (including AMF, I-SMF or V-SMF).

It is sent from the SMF to the DN-AAA server to indicate the Serving NF FQDN address.

128 – 3GPP-Session-Id

	Bits
Octets	8	7	6	5	4	3	2	1
1	3GPP type = 128
2	3GPP Length= 3
3	PduSessionId

3GPP Type: 128

Length: 3

PduSessionId: 1-octet unsigned integer identifying a PDU session, within the range 0 to 255, as specified in clause 5.4.2 of 3GPP TS 29.571 [46].

It is sent from the SMF to the DN-AAA server to indicate the PDU Session Identifier.

129 – 3GPP-GCI

	Bits
Octets	8	7	6	5	4	3	2	1
1	3GPP type = 129
2	3GPP Length= m
3-m	GCI (octet string)

3GPP Type: 129

Length: m

GCI field is Octet String type.

The GCI is the Global Cable Identifier uniquely identifies the line connecting the 5G-CRG or FN-CRG to the 5GS. See clause 28.15.4 of 3GPP TS 23.003 [28].

The GCI is a variable length opaque identifier, shall be encoded as specified in CableLabs WR‑TR‑5WWC‑ARCH [51] and CableLabs DOCSIS MULPI [55]. It shall comply with the syntax specified in clause 2.2 of IETF RFC 7542 [56] for the username part of a NAI.

The SMF may indicate the Global Cable Identifier. Present for a 5G-CRG accessing the 5GC via wireline access network, in Access-Request, Accounting-Request START, Accounting-Request STOP, or Accounting-Request Interim-Update messages. Present for a FN-CRG accessing the 5GC via wireline access network, in Accounting-Request START, Accounting-Request STOP, or Accounting-Request Interim-Update messages.

130 – 3GPP-DNAI

	Bits
Octets	8	7	6	5	4	3	2	1
1	3GPP type = 130
2	3GPP Length= m
3-m	DNAI (string)

3GPP Type: 130

Length: m

DNAI: string, indicates the Data Network Access Identifier.

It is sent from SMF to DN-AAA server to indicate the SMF selected or used DNAI interworking with the external DN.

131 – 3GPP-RSN

	Bits
Octets	8	7	6	5	4	3	2	1
1	3GPP type = 131
2	3GPP Length= 3
3	RSN

3GPP Type: 131

Length: 3

RSN: 1-octet unsigned integer identifying a RSN (see 3GPP TS 24.501 [42] for encoding).

It is sent from the SMF to the DN-AAA accounting server to indicate the RSN.

132 – 3GPP-Session-Pair-Id

	Bits
Octets	8	7	6	5	4	3	2	1
1	3GPP type = 132
2	3GPP Length= 3
3	PDU Session Pair Id

3GPP Type: 132

Length: 3

PDU Session Pair Id: 1-octet unsigned integer identifying a PDU session pair information (see 3GPP TS 24.501 [42] for encoding).

It is sent from the SMF to the DN-AAA accounting server to indicate the PDU Session Pair Identifier. Two redundant PDU sessions share the same PDU Session Pair Identifier.

133 – 3GPP-Charging ID-v2

	Bits
Octets	8	7	6	5	4	3	2	1
1	3GPP type = 133
2	3GPP Length= m
3-m	Charging ID (string)

3GPP Type: 133

Length: m

Charging ID value: string, indicates the Charging Identifier.

Table 11.3-3: List of the 3GPP Vendor-Specific sub-attributes for N6

Sub-attr #	Sub-attribute Name	Description	Presence Requirement	Associated attribute (Location of Sub-attr)	Applicability
110	3GPP-Notification	It includes all notifications that the DN-AAA wants to receive from the SMF.	Optional	Access-Accept
111	3GPP-UE-MAC-Address	It is sent from the DN-AAA to authorize UE MAC addresses, or it indicates UE MAC addresses in use when sending from the SMF to the DN-AAA.	Optional	Access-Request, Access-Accept, Accounting-Request Interim-Update, Change-of-Authorization
112	3GPP-Authorization-Reference	It is sent from the DN-AAA to refer to the local authorization data in the SMF.	Optional	Access-Accept, Change-of-Authorization
113	3GPP-Policy-Reference	It is sent from the DN-AAA and used by the SMF to retrieve the SM or QoS policy data from the PCF. It is not used in this release.	Optional	Access-Accept, Change-of-Authorization
114	3GPP-Session-AMBR	It is sent from the DN-AAA to authorize the PDU Session AMBR in the downlink and uplink.	Optional	Access-Accept, Change-of-Authorization
115	3GPP-NAI	The Network Access Identifier identifying the UE.	Optional	Access-Request, Accounting-Request START, Accounting-Request STOP, Accounting-Request Interim-Update
116	3GPP-Session-AMBR-v2	It is sent from the DN-AAA to authorize the PDU Session AMBR, it includes separate session AMBR for UL and DL.	Optional	Access-Accept, Change-of-Authorization	eSessionAMBR
117	3GPP-Supported-Features	It indicates the supported features as specified in clause 12.4.1.	Optional	Access-Request, Access-Accept, Access-Challenge, Accounting-Request START, Accounting-Response START
118	3GPP-IP-Address-Pool-Info	It indicates the IP address pool identifier.	Optional	Access-Request, Access-Accept, Accounting-Request START, Accounting-Request STOP, Accounting-Request Interim-Update
119	3GPP-VLAN-Id	It is sent from the DN-AAA to authorize the allowed VLAN Id for the Ethernet PDU session.	Optional	Access-Accept, Change-of-Authorization
120	3GPP-TNAP-Identifier	Indicates the UE location in a Trusted Non-3GPP Access Network.	Optional	Access-Request, Accounting-Request START, Accounting-Request STOP, Accounting-Request Interim-Update
121	3GPP-HFC-NodeId	Indicates the HFC Node Identifier received over NGAP. Present for a 5G-CRG/FN-CRG accessing the 5GC via wireline access network	Optional	Access-Request (NOTE 1), Accounting-Request START, Accounting-Request STOP, Accounting-Request Interim-Update
122	3GPP-GLI	Indicates the Global Line Identifier. Present for a 5G-BRG/FN-BRG accessing the 5GC via wireline access network.	Optional	Access-Request (NOTE 1), Accounting-Request START, Accounting-Request STOP, Accounting-Request Interim-Update
123	3GPP-Line-Type	Indicates the type of the wireline (DLS or PON). Present for a 5G-BRG/FN-BRG accessing the 5GC via wireline access network.	Optional	Access-Request (NOTE 1), Accounting-Request START, Accounting-Request STOP, Accounting-Request Interim-Update
124	3GPP-NID	Indicates the network identifier. It shall only be present together with 3GPP-SGSN-MCC-MNC to identify an SNPN.	Optional	Access-Request, Accounting-Request START, Accounting-Request STOP, Accounting-Request Interim-Update
125	3GPP-Session-S-NSSAI	Indicates the S-NSSAI that is associated with the PDU Session.	Optional	Access-Request Accounting-Request START, Accounting-Request STOP, Accounting-Request Interim-Update (NOTE 2)
126	3GPP-CHF-FQDN	Indicates the FQDN of the CHF.	Optional	Access-Request Accounting-Request START, Accounting-Request STOP, Accounting-Request Interim-Update
127	3GPP-Serving NF-FQDN	Indicates the FQDN of the Serving NF (includes AMF, I-SMF or V-SMF).	Optional	Access-Request Accounting-Request START, Accounting-Request STOP, Accounting-Request Interim-Update
128	3GPP-Session-Id	Indicates the PDU Session Identifier.	Optional	Access-Request Accounting-Request START, Accounting-Request STOP, Accounting-Request Interim-Update (NOTE 2)
129	3GPP-GCI	Indicates the line connecting the 5G-CRG or FN-CRG to the 5GS	Optional	Access-Request (NOTE 1), Accounting-Request START, Accounting-Request STOP, Accounting-Request Interim-Update
130	3GPP-DNAI	Indicates the SMF selected or used DN Access Identifier interworking with the external DN.	Optional	Accounting-Request START, Accounting-Request STOP, Accounting-Request Interim-Update
131	3GPP-RSN	Indicates the RSN.	Optional	Accounting-Request START, Accounting-Request STOP, Accounting-Request Interim-Update
132	3GPP-Session-Pair-Id	Indicates the PDU Session Pair Identifier	Optional	Accounting-Request START, Accounting-Request STOP, Accounting-Request Interim-Update
133	3GPP-Charging-Id-v2	Charging ID for this PDU Session, supporting charging Id length longer than unsiged integer 32 bit.	Optional	Access-Request (NOTE 1), Accounting-Request START, Accounting-Request STOP, Accounting-Request Interim-Update
NOTE 1: Access-Request is not applicable for FN-CRG or FN-BRG. NOTE 2: This VSA is optional in the Accounting-Request Interim-Update message.

RADIUS attributes related to the DN-AAA initiated re-authorization and authentication challenge are described in the following clauses.

11.3.2 Change-of-Authorization Request (optionally sent from DN-AAA server to SMF)

Table 11.3.2-1 describes the attributes of the Change-of-Authorization Request message. Other RADIUS attributes may be used as defined in IETF RFC 5176 [27].

Table 11.3.2-1: The attributes of the Change-of-Authorization Request message

Attr #	Attribute Name	Description	Content	Presence Requirement
1	User-Name	Username provided by the user (extracted from the PCO field received during PDN connection establishment). If no username is available a generic username, configurable on a per DNN basis, shall be present. If the User-Name has been sent in the Access-Accept message, this user-name shall be used in preference to the above	String	Optional
6	Service-Type	Indicates the type of service for this user.	17 (Authorize Only)	Optional
8	Framed-IP-Address	User IPv4 address	Ipv4	Conditional NOTE 2
10	3GPP-NSAPI	identifies QFI with value range 0-255 in this user session.	UTF-8 encoded character	Optional
30	Called-Station-Id	Identifier for the target network	DNN (UTF-8 encoded characters)	Optional
31	Calling-Station-Id	This attribute is the identifier for the UE, and it shall be configurable on a per DNN basis.	MSISDN in international format according to 3GPP TS 23.003 [28], UTF-8 encoded decimal character. (NOTE 5)	Optional
96	Framed-Interface-Id	User IPv6 Interface Identifier	IPv6	Conditional NOTE 1 NOTE 2
44	Acct-Session-Id	User session identifier.	SMF IP address (IPv4 or IPv6) and Charging-ID concatenated in a UTF-8 encoded hexadecimal characters. (NOTE 6)	Mandatory
79	EAP-Message	This attribute encapsulates EAP message (as defined in IETF RFC 3748 [6]) exchanged between the SMF and DN-AAA, see IETF RFC 3579 [7] for details.	String	Conditional NOTE 3
80	Message-Authenticator	This attribute includes the message authenticator, see IETF RFC 3579 [7] for details.	String	Conditional NOTE 3
97	Framed-IPv6-Prefix	User IPv6 prefix	IPv6	Conditional NOTE 2
123	Delegated-IPv6-Prefix	Delegated IPv6 prefix to the user.	IPv6	Conditional NOTE 4
26/10415	3GPP Vendor-Specific	Sub-attributes according clause 11.3, the encoding of this attribute is specified in 3GPP TS 29.061 [5].	See clause 11.3	Optional
NOTE 1: Included if the prefix alone is not unique for the user. This may be the case, for example, if a static IPv6 address is assigned. NOTE 2: If the 3GPP-PDP-Type is IPv4, IPv6 or IPv4v6, either IPv4 or IPv6 address/prefix attribute shall be present. The IP protocol version for end-user and network may be different. NOTE 3: Shall be present if EAP is used. NOTE 4: The delegated IPv6 prefix shall be present if IPv6 prefix delegation is required from the external DN-AAA server. NOTE 5: There are no leading characters in front of the country code. NOTE 6: If the accounting session is created per QoS flow, Acct-Session-Id may be extended to include the QFI of the QoS flow.

11.3.3 Access-Challenge (sent from DN-AAA server to SMF)

Table 11.3.3-1 describes the attributes of the Access-Challenge Request message. Other RADIUS attributes may be used as defined in IETF RFC 2865 [8].

Table 11.3.3-1: The attributes of the Access-Challenge message

Attr #	Attribute Name	Description	Content	Presence Requirement
27	Session-Timeout	Indicates the timeout value (in seconds) for the user session	32 bit unsigned Integer	Optional
79	EAP-Message	This attribute encapsulates EAP message (as defined in IETF RFC 3748 [6]) exchanged between the SMF and DN-AAA, see IETF RFC 3579 [7] for details.	String	Mandatory
80	Message-Authenticator	This attribute includes the message authenticator, see IETF RFC 3579 [7] for details.	String	Mandatory
NOTE: Included if the prefix alone is not unique for the user. This may be the case, for example, if a static IPv6 address is assigned.