Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 23.502  Word version:  16.5.1

Top   Top   Up   Prev   Next
1…   4.2.2.2.2   4.2.2.2.3…   4.2.3…   4.2.3.3   4.2.4…   4.2.6   4.2.7…   4.2.9…   4.3…   4.3.2.2…   4.3.2.2.2   4.3.2.2.3…   4.3.3   4.3.4   4.3.5…   4.3.5.2…   4.3.5.4…   4.3.5.6…   4.3.6…   4.4…   4.5…   4.9…   4.9.1.3…   4.9.2…   4.11…   4.11.1.2.2…   4.11.1.3…   4.11.1.4…   4.11.1.5…   4.11.2   4.11.3…   4.12…   4.12.6…   4.12a   4.12b   4.13…   4.13.4…   4.13.6…   4.14…   4.15…   4.15.4…   4.16…   4.16.4…   4.16.8…   4.17…   4.17.9…   4.18…   4.19…   4.23…   4.23.7…   4.23.9…   4.23.11…   4.24   4.25   4.26…   5…   5.2.3…   5.2.5…   5.2.6…   5.2.7…   5.2.8…   5.2.9…   5.2.12…   A…   E…   F…

 

4.12  Procedures for Untrusted non-3GPP accessWord‑p. 245

4.12.1  General

Clause 4.12 defines the procedures to support Untrusted non-3GPP access by describing the differences compared to the defined procedures in other clauses. The procedures for Untrusted non-3GPP access are also used by a UE that accesses SNPN services via a PLMN over 3GPP access.

4.12.2  Registration via Untrusted non-3GPP Access

4.12.2.1  General

Clause 4.12.2 specifies how a UE can register to 5GC via an untrusted non-3GPP access network. It is based on the Registration procedure specified in clause 4.2.2.2.2 and it uses a vendor-specific EAP method called "EAP-5G". The EAP-5G packets utilize the "Expanded" EAP type and the existing 3GPP Vendor-Id registered with IANA under the SMI Private Enterprise Code registry. The "EAP-5G" method is used between the UE and the N3IWF and is utilized only for encapsulating NAS messages (not for authentication). If the UE needs to be authenticated, mutual authentication is executed between the UE and AUSF. The details of the authentication procedure are specified in TS 33.501.
In Registration and subsequent Registration procedures via untrusted non-3GPP access, the NAS messages are always exchanged between the UE and the AMF. When possible, the UE can be authenticated by reusing the existing UE security context in AMF.
Up

4.12.2.2  Registration procedure for untrusted non-3GPP access

The signalling flow in Figure 4.12.2.2-1 does not show all the details of a registration procedure via untrusted non-3GPP access. It shows primarily the steps executed between the UE and N3IWF. All the details of a registration procedure, including interactions with PCF, UDM, etc. are specified in clause 4.2.2.2.2.
Reproduction of 3GPP TS 23.502, Figure 4.12.2.2-1: Registration via untrusted non-3GPP access
Up
Step 1.
The UE connects to an untrusted non-3GPP access network with any appropriate authentication procedure and it is assigned an IP address. For example, a non-3GPP authentication method can be used, e.g. no authentication (in the case of a free WLAN), EAP with pre-shared key, username/password, etc. When the UE decides to attach to 5GC network, the UE selects an N3IWF in a 5G PLMN, as described in TS 23.501, clause 6.3.6.
Up

Step 2.
The UE proceeds with the establishment of an IPsec Security Association (SA) with the selected N3IWF by initiating an IKE initial exchange according to RFC 7296 [3]. After step 2, all subsequent IKE messages are encrypted and integrity protected by using the IKE SA established in this step.
Up

Step 3.
The UE shall initiate an IKE_AUTH exchange by sending an IKE_AUTH request message. The AUTH payload is not included in the IKE_AUTH request message, which indicates that the IKE_AUTH exchange shall use EAP signalling (in this case EAP-5G signalling). If the UE supports MOBIKE, it shall include a Notify payload in the IKE_AUTH request, as specified in RFC 4555 [40], indicating that MOBIKE is supported. In addition, as specified in TS 33.501, if the UE is provisioned with the N3IWF root certificate, it shall include the CERTREQ payload within the IKE_AUTH request message to request the N3IWF's certificate.
Up

Step 4.
The N3IWF responds with an IKE_AUTH response message, which includes an EAP-Request/5G-Start packet. The EAP-Request/5G-Start packet informs the UE to initiate an EAP-5G session, i.e. to start sending NAS messages encapsulated within EAP-5G packets. If the N3IWF has received a CERTREQ payload from the UE, the N3IWF shall include the CERT payload in the IKE_AUTH response message conaining the N3IWF's certificate. How the UE uses the N3IWF's certificate is specified in TS 33.501.
Up

Step 5.
The UE shall send an IKE_AUTH request, which includes an EAP-Response/5G-NAS packet that contains the Access Network parameters (AN parameters) and a Registration Request message. The AN parameters contain information that is used by the N3IWF for selecting an AMF in the 5G core network. This information includes e.g. the GUAMI, the Selected PLMN ID (or PLMN ID and NID, see TS 23.501, clause 5.30), the Requested NSSAI and the Establishment cause. The Establishment cause provides the reason for requesting a signalling connection with 5GC. Whether and how the UE includes the Requested NSSAI as part of the AN parameters is dependent on the value of the Access Stratum Connection Establishment NSSAI Inclusion Mode parameter, as specified in clause 5.15.9 of TS 23.501.
Up

Step 6.
The N3IWF shall select an AMF based on the received AN parameters and local policy, as specified in TS 23.501, clause 6.3.5. The N3IWF shall then forward the Registration Request received from the UE to the selected AMF within an N2 message. This message contains N2 parameters that include the Selected PLMN ID and the Establishment cause.
Up

Step 7.
The selected AMF may decide to request the SUCI by sending a NAS Identity Request message to UE. This NAS message and all subsequent NAS messages are sent to UE encapsulated within EAP/5G-NAS packets.
Up

Step 8.
The AMF may decide to authenticate the UE by invoking an AUSF. In this case, the AMF shall select an AUSF as specified in TS 23.501, clause 6.3.4 based on SUPI or SUCI.
The AUSF executes the authentication of the UE as specified in TS 33.501. The AUSF selects a UDM as described in TS 23.501, clause 6.3.8 and gets the authentication data from UDM. The authentication packets are encapsulated within NAS authentication messages and the NAS authentication messages are encapsulated within EAP/5G-NAS packets. After the successful authentication:
  • In step 8h, the AUSF shall send the anchor key (SEAF key) to AMF which is used by AMF to derive NAS security keys and a security key for N3IWF (N3IWF key). The UE also derives the anchor key (SEAF key) and from that key it derives the NAS security keys and the security key for N3IWF (N3IWF key). The N3IWF key is used by the UE and N3IWF for establishing the IPsec Security Association (in step 11).
  • In step 8h, the AUSF shall also include the SUPI, if in step 8a the AMF provided to AUSF a SUCI.
Up

Step 9a.
The AMF shall send a NAS Security Mode Command to UE in order to activate NAS security. If an EAP-AKA' authentication was successfully executed in step 8, the AMF shall encapsulate the EAP-Success received from AUSF within the NAS Security Mode Command message.
Up

Step 9b.
The N3IWF shall forward the NAS Security Mode Command message to UE within an EAP/5G-NAS packet.
Up

Step 9c.
The UE completes the EAP-AKA' authentication (if initiated in step 8), creates a NAS security context and an N3IWF key and sends the NAS Security Mode Complete message within an EAP/5G-NAS packet.
Up

Step 9d.
The N3IWF relays the NAS Security Mode Complete message to the AMF.
Up

Step 10a.
Upon receiving NAS Security Mode Complete, the AMF shall send an NGAP Initial Context Setup Request message that includes the N3IWF key.
Up

Step 10b.
This triggers the N3IWF to send an EAP-Success to UE, which completes the EAP-5G session. No further EAP-5G packets are exchanged.
Up

Step 11.
The IPsec SA is established between the UE and N3IWF by using the common N3IWF key that was created in the UE in step 9c and received by the N3IWF in step 10a. This IPsec SA is referred to as the "signalling IPsec SA". After the establishment of the signalling IPsec SA, the N3IWF notifies the AMF that the UE context (including AN security) was created by sending a NGAP Initial Context Setup Response. The signalling IPsec SA shall be configured to operate in tunnel mode and the N3IWF shall assign to UE an "inner" IP address. If the N3IWF has received an indication that the UE supports MOBIKE (see step 3), then the N3IWF shall include a Notify payload in the IKE_AUTH response message sent in step 11a, indicating that MOBIKE shall be supported, as specified in RFC 4555 [40].
All subsequent NAS messages exchanged between the UE and N3IWF shall be sent via the signalling IPsec SA and shall be carried over TCP/IP. The UE shall send NAS messages within TCP/IP packets with source address the "inner" IP address of the UE and destination address the NAS_IP_ADDRESS that is received in step 11a. The N3IWF shall send NAS messages within TCP/IP packets with source address the NAS_IP_ADDRESS and destination address the "inner" IP address of the UE. The TCP connection used for reliable NAS transport between the UE and N3IWF shall be initiated by the UE right after the signalling IPsec SA is established in step 11a. The UE shall send the TCP connection request to the NAS_IP_ADDRESS and to the TCP port number specified in TS 24.502.
Up

Step 12.
The AMF sends the NAS Registration Accept message to the N3IWF. The N2 Message includes the Allowed NSSAI for the access type for the UE.
Up

Step 13.
The N3IWF forwards the NAS Registration Accept to UE via the established signalling IPsec SA. If the NAS Registration Request message is received by the N3IWF before the IPsec SA is established, the N3IWF shall store it and forward it to the UE only after the establishment of the signalling IPsec SA.
The AMF provides the Access Type set to "Non-3GPP access" to the UDM when it registers with the UDM.
Up

Up

4.12.2.3  Emergency Registration for untrusted non-3GPP AccessWord‑p. 248
Emergency Registration procedure is used by UEs requiring to perform emergency services but cannot gain normal services from the network. These UEs are in limited service state as defined in TS 23.122.
The regular registration procedure described in clause 4.12.2 applies with the following differences:
  • If the UE has no SUPI and no valid 5G-GUTI, PEI shall be included instead of its encrypted Permanent User ID (SUCI) in the Access Network parameters.
  • NSSAI shall not be included by the UE. The AMF shall not send the Allowed S-NSSAIs in the Registration Accept message.
  • If the AMF is not configured to support Emergency Registration, the AMF shall reject any Registration Request that indicates Registration type "Emergency Registration".
  • If the AMF is configured to support Emergency Registration for unauthenticated UEs and the UE indicated Registration Type "Emergency Registration", the AMF skips the authentication and security setup or the AMF accepts that the authentication may fail and continues the Emergency Registration procedure.
  • If the authentication is performed successfully, the NAS messages will be protected by the NAS security functions (integrity and ciphering). The AMF shall derive the N3IWF key, per TS 33.501, and shall provide it to the N3IWF after the authentication completion using an NGAP Initial Context Setup Request message as in the regular registration procedure.
  • If the authentication is skipped or authentication fails, the NAS messages will not be protected by the NAS security functions (integrity and ciphering). However, the AMF shall create an N3IWF key and shall provide it to the N3IWF after the authentication completion (whenever authentication has failed or has been skipped) using an NGAP Initial Context Setup Request message. The N3IWF shall use it to complete IKE SA establishment, and shall acknowledge the AMF by sending an NGAP Initial Context Setup Response message.
  • As in step 14 of Figure 4.2.2.2.2-1 for Emergency Registration, if the UE was not successfully authenticated, the AMF shall not update the UDM. Also for an Emergency Registration, the AMF shall not check for access restrictions, regional restrictions or subscription restrictions.
  • Steps 16 and 22b of Figure 4.2.2.2.2-1 are not performed since AM and UE policy for the UE are not required for Emergency Registration.
Up

4.12.3  Deregistration procedure for untrusted non-3gpp accessWord‑p. 249
Reproduction of 3GPP TS 23.502, Figure 4.12.3-1: Deregistration procedure for untrusted non-3gpp access
Up
Step 1.
The Deregistration procedure is triggered by one of the events:
Step 1a.
For UE-initiated Deregistration as in steps from 1 to 7 of Figures 4.2.2.3.2-1.
Step 1b.
For network initiated deregistration as in steps from 1 to 6 of Figure 4.2.2.3.3-1.
If the UE is in CM-CONNECTED state either in 3GPP access, non-3GPP access or both,
  • the AMF may explicitly deregister the UE by sending a Deregistration request message ( Deregistration type, access type set to non-3GPP) to the UE as in step 2 of Figure 4.2.2.3.3-1.
  • the UDM may want to request the deletion of the subscribers RM contexts and PDU Sessions with the reason for removal set to subscription withdrawn to the registered AMF as in step 1 of Figure 4.2.2.3.3-1.
Step 2.
AMF to N3IWF: The AMF sends a N2 Context UE Release Command message to the N3IWF with the cause set to Deregistration to release N2 signalling as defined in step 4 of clause 4.12.4.2.
Step 3.
N3IWF to UE: The N3IWF sends INFORMATIONAL Request (Delete payload) message to the UE. The Delete payload is included to indicate the release of the IKE SA.
Step 4.
UE to N3IWF: The UE sends an empty INFORMATIONAL Response message to acknowledge the release of the IKE SA as described in RFC 7296 [3]. Non-3GPP access specific resources are released including the IKEv2 tunnel (and the associated IPSec resources) and the local UE contexts in N3IWF (N3 tunnel Id).
Step 5.
N3IWF to AMF: The N3IWF acknowledges the N2 UE Context Release Command message by sending N2 UE Context Release Complete message to the AMF as defined in step 7 of clause 4.12.4.2.
Up

4.12.4  N2 procedures via Untrusted non-3GPP AccessWord‑p. 250

4.12.4.1  Service Request procedures via Untrusted non-3GPP Access

The Service Request procedure via Untrusted non-3GPP Access shall be used by a UE in CM-IDLE state over non-3GPP access to request the re-establishment of the NAS signalling connection and the re-establishment of the user plane for all or some of the PDU Sessions which are associated to non-3GPP access.
The Service Request procedure via Untrusted non-3GPP Access shall be used by a UE in CM-CONNECTED state over non-3GPP access to request the re-establishment of the user plane for one or more PDU Sessions which are associated to non-3GPP access.
When the UE is in CM-IDLE state over non-3GPP access, the Service Request procedure via Untrusted non-3GPP Access is as described in clause 4.2.3.2 (UE Triggered Service Request) with the following exceptions:
  • The Service Request procedure is never a response to a Paging, i.e. there is no Network Triggered Service Request procedure via Untrusted non-3GPP Access.
  • The (R)AN corresponds to an N3IWF.
  • The UE establishes a "signalling IPsec SA" with the N3IWF by using the procedure specified in clause 4.12.2 for the registration via untrusted non-3GPP access. In particular, the UE includes the Service Request and the AN parameters in an EAP-5G packet, which is further encapsulated in an IKE_AUTH request.
  • The AN parameters include the Selected PLMN ID (or PLMN ID and NID, see TS 23.501, clause 5.30) and Establishment cause. The Establishment cause provides the reason for requesting a signalling connection with the 5GC. The UE includes GUAMI information in the AN parameters. The N3IWF selects the AMF according to GUAMI information.
  • The N2 parameters sent from N3IWF to AMF include the Establishment cause.
  • The user plane between the UE and N3IWF is established not with RRC signalling but with IKEv2 signalling, as specified in clause 4.12.5 (i.e. by using an IKEv2 Create_Child_SA exchange). The user plane of each PDU Session consists of one or more Child SAs.
When the UE is in CM-CONNECTED state over non-3GPP access, the Service Request procedure via Untrusted non-3GPP Access is as described in clause 4.2.3.2 (UE Triggered Service Request) with the following exceptions:
  • All NAS signalling exchanged between the UE and network is transferred within the established "signalling IPsec SA".
  • The (R)AN corresponds to an N3IWF.
  • The user plane between the UE and N3IWF is established not with RRC signalling but with IKEv2 signalling, as specified in clause 4.12.5 (i.e. by using an IKEv2 Create_Child_SA exchange). The user plane of each PDU Session consists of one or more Child SAs.
When the UE is in CM-CONNECTED state over non-3GPP access and the network receives downlink data for a PDU Session over non-3GPP access that has no user plane, the steps 1-4a in clause 4.2.3.3 (Network Triggered Service Request) shall be performed with the following exceptions:
  • The (R)AN corresponds to an N3IWF.
  • The user plane between the UE and N3IWF is established (in step 4a) with IKEv2 signalling, as specified in clause 4.12.5 (i.e. by using an IKEv2 Create_Child_SA exchange). The user plane of each PDU Session consists of one or more Child SAs.
Up

4.12.4.2  Procedure for the UE context release in the N3IWF

This procedure is used to release the N2 signalling connection and the N3 User Plane connection. If the procedure is initiated by the AMF the IKEv2 SA for a UE is being released. The procedure will move the UE from CM-CONNECTED to CM-IDLE in AMF, and all UE related context information is deleted in the N3IWF.
Both N3IWF-initiated and AMF-initiated UE context release in the N3IWF procedures are shown in Figure 4.12.4.2-1.
Reproduction of 3GPP TS 23.502, Figure 4.12.4.2-1: Procedure for the UE context release in the N3IWF
Up
Step 1.
The UE has already registered in the 5GC and may have established one or multiple PDU Sessions.
Step 2.
The N3IWF detects that the UE is not reachable.
Step 3.
The N3IWF sends a N2 UE Context Release Request message to the AMF This step is equivalent to step 1b of Figure 4.2.6-1.
Step 4.
AMF to N3IWF: If the AMF receives the N2 UE Context Release Request from N3IWF or if due to an internal AMF event the AMF wants to release N2 signalling, the AMF sends an N2 UE Context Release Command (Cause) to the N3IWF. The cause indicated is cause from step 3 or a cause due to internal AMF event. This step is equivalent to step 2 of Figure 4.2.6-1.
Step 5.
If the IKEv2 tunnel has not been released yet, the N3IWF performs the release of the IPsec tunnel as defined in RFC 7296 [3] indicating to release the IKE SA and any Child IPSec SA if existing. The N3IWF sends to the UE the indication of the release reason if received in step 4.
Step 6.
The UE sends an empty INFORMATIONAL Response message to acknowledge the release of the IKE SA as described in RFC 7296 [3]. The N3IWF deletes the UE's context after receiving the empty INFORMATIONAL Response message.
Step 7.
N3IWF to AMF: The N3IWF confirms the release of the UE-associated N2-logical connection by returning N2 UE Release Complete (list of PDU Session ID(s) with active N3 user plane) to the AMF as in step 4 defined in clause 4.2.6. The AMF marks the UE as CM-IDLE state in untrusted non-3GPP access.
Step 8.
For each of the PDU Sessions in the N2 UE Context Release Complete, the steps 5 to 7 in clause 4.2.6 are performed (PDU Session Update SM Context). After the AMF receives the Nsmf_PDUSession_UpdateSMContext Response as in step 7 of clause 4.2.6, the AMF considers the N3 connection as released. If list of PDU Session ID(s) with active N3 user plane is included in step 3, then this step is performed before step 4.
Up

4.12.4.3  CN-initiated selective deactivation of UP connection of an existing PDU Session associated with Untrusted non-3GPP AccessWord‑p. 252
The procedure described in clause 4.3.7 (CN-initiated selective deactivation of UP connection of an existing PDU Session) is used for CN-initiated selective deactivation of UP connection for an established PDU Session associated with non-3GPP Access of a UE in CM-CONNECTED state, with the following exceptions:
  • The NG-RAN corresponds to an N3IWF.
  • The user plane between the UE and N3IWF, i.e. Child SA(s) for the PDU Session, is released not with RRC signalling but with IKEv2 signalling, as specified in clause 4.12.7.
Up

4.12.5  UE Requested PDU Session Establishment via Untrusted non-3GPP Access

Clause 4.12.5 specifies how a UE can establish a PDU Session via an untrusted non-3GPP access network as well as to hand over an existing PDU Session between 3GPP access and non-3GPP access. The procedure applies in non-roaming, roaming with LBO as well as in home-routed roaming scenarios.
For non-roaming and LBO scenarios, if the UE is simultaneously registered to a 3GPP access in a PLMN different from the PLMN of the N3IWF, the functional entities in the following procedures are located in the PLMN of the N3IWF. For home-routed roaming scenarios, the AMF, V-SMF and associated UPF in VPLMN in the following procedure is located in the PLMN of the N3IWF.
The procedure below is based on the PDU Session Establishment procedure specified in clause 4.3.2.2.1 (for non-roaming and roaming with LBO) and the PDU Session Establishment procedure specified in clause 4.3.2.2.2 (for home-routed roaming).
Reproduction of 3GPP TS 23.502, Figure 4.12.5-1: PDU Session establishment via untrusted non-3GPP access
Up
Step 1.
The UE shall send a PDU Session Establishment Request message to AMF as specified in step 1 of clause 4.3.2.2.1. This message shall be sent to N3IWF via the IPsec SA for NAS signalling (established as specified in clause 4.12.2) and the N3IWF shall transparently forward it to AMF in the 5GC.
Step 2a.
In the case of non-roaming or roaming with Local Breakout, steps 2-11 specified in clause 4.3.2.2.1 are executed according to the PDU Session Establishment procedure over 3GPP access. In the case of home-routed roaming, steps 2-14 specified in clause 4.3.2.2.2 are executed according to the PDU Session Establishment procedure over 3GPP access.
Step 2b.
As described in step 12 of clause 4.3.2.2.1, the AMF shall send a N2 PDU Session Request message to N3IWF to establish the access resources for this PDU Session.
Step 3.
Based on its own policies and configuration, and based on the QoS profiles received in the previous step, the N3IWF shall determine the number of IPsec Child SAs to establish and the QoS profiles associated with each IPsec Child SA. For example, the N3IWF may decide to establish one IPsec Child SA and associate all QoS profiles with this IPsec Child SA. In this case, all QoS Flows of the PDU Session would be transferred over one IPsec Child SA.
Step 4a.
The N3IWF shall send to UE an IKE Create_Child_SA request according to the IKEv2 specification in RFC 7296 [3] to establish the first IPsec Child SA for the PDU Session. The IKE Create_Child_SA request indicates that the requested IPsec Child SA shall operate in tunnel mode. This request shall include a 3GPP-specific Notify payload which contains (a) the QFI(s) associated with the Child SA, (b) the identity of the PDU Session associated with this Child SA, (c) optionally, a DSCP value associated with the Child SA, (d) optionally a Default Child SA indication, and (e) optionally, the Additional QoS Information specified in clause 4.12a.5
The IKE Create_Child_SA request shall also include another 3GPP-specific Notify payload, which contains the UP_IP_ADDRESS that is specified in step 8 below.
If a DSCP value is included, then the UE and the N3IWF shall mark all IP packets sent over this Child SA with this DSCP value. There shall be one and only one Default Child SA per PDU session. The UE shall send all QoS Flows to this Child SA for which there is no mapping information to a specific Child SA. The IKE Create_Child_SA request also contains other information (according to RFC 7296 [3]) such as the SA payload, the Traffic Selectors (TS) for the N3IWF and the UE, etc.
After receiving the IKE Create_Child_SA request, if the Additional QoS Information is received, the UE may reserve non-3GPP access network resources according to the Additional QoS Information.
Step 4b.
If the UE accepts the new IPsec Child SA, the UE shall send an IKE Create_Child_SA response according to the IKEv2 specification in RFC 7296 [3]. During the IPsec Child SA establishment the UE shall not be assigned an IP address.
Step 4c-4d.
If in step 3 the N3IWF determined to establish multiple IPsec Child SAs for the PDU Session, then additional IPsec Child SAs shall be established, each one associated with one or more QFI(s), optionally with a DSCP value, with a UP_IP_ADDRESS and optionally with the Additional QoS Information specified in clause 4.12a.5. For each IPsec Child SA, if the Additional QoS Information is received, the UE may reserve non-3GPP access network resources according to the Additional QoS Information for the IPsec Child SA.
Step 5.
After all IPsec Child SAs are established, the N3IWF shall forward to UE via the signalling IPsec SA (see clause 4.12.2.2) the PDU Session Establishment Accept message received in step 2b.
Step 6.
The N3IWF shall send to AMF an N2 PDU Session Response.
Step 7.
In the case of non-roaming or roaming with Local Breakout, all steps specified in clause 4.3.2.2.1 after step 14 are executed according to the PDU Session Establishment procedure over 3GPP access. In the case of home-routed roaming, all steps specified in clause 4.3.2.2.2 after step 18 are executed according to the PDU Session Establishment procedure over 3GPP access.
Step 8.
On the user-plane:
  • When the UE has to transmit an UL PDU, the UE shall determine the QFI associated with the UL PDU (by using the QoS rules of the PDU Session), it shall encapsulate the UL PDU inside a GRE packet and shall forward the GRE packet to N3IWF via the IPsec Child SA associated with this QFI. The header of the GRE packet carries the QFI associated with the UL PDU. The UE shall encapsulate the GRE packet into an IP packet with source address the "inner" IP address of the UE and destination address the UP_IP_ADDRESS associated with the Child SA.
  • When the N3IWF receives a DL PDU via N3, the N3IWF uses the QFI and the identity of the PDU Session in order to determine the IPsec Child SA to use for sending the DL PDU over NWu. The N3IWK encapsulates the DL PDU inside a GRE packet and copies the QFI in the header of the GRE packet. The N3IWF may include also in the GRE header a Reflective QoS Indicator (RQI), which shall be used by the UE to enable reflective QoS. The N3IWF shall encapsulate the GRE packet into an IP packet with source address the UP_IP_ADDRESS associated with the Child SA and destination address the "inner" IP address of the UE.
Up


Up   Top   ToC