N3IWF for Non-3GPP Access
Feature Description
- Architecture
UE Idle Mode Entry in N3IWF
How it Works
- Call Flows
N3GA Location Parameters
Voice or Video Call Over Wi-Fi with N3IWF and HO Support with Active Bearer
Handling of RAT Type for N3IWF Sessions
Standard Compliance
OAM Support

N3IWF for Non-3GPP Access

Table 1. Feature History
Feature Name	Release Information	Description
N3IWF for Untrusted Non-3GPP Access Network	2024.01	SMF supports the N3IWF interface for interworking between 5G core and untrusted non-3GPP networks. N3IWF facilitates seamless handover and uninterrupted connectivity for users when they transition between different network types. Default Setting: Disabled – Configuration Required

Feature Description

Table 2. Feature History
Feature Name	Release Information	Description
Enhancements to N3IWF: Network-Initiated Service Requests, Inter-PLMN Handover, and Core-Agnostic Location Parameters	2024.04.1	Following are the additional enhancement to the N3IWF for the seamless communication between the Wi-Fi network and the cellular network. Network initiated service request through N3IWF Inter PLMN Wi-Fi to NR handover Inter PLMN NR to Wi-Fi handover Wi-Fi (N3IWF) to Evolved Universal Terrestrial Radio Access (EUTRA) HO EUTRA to Wi-Fi (N3IWF) HO Next Generation Core-Agnostic (N3GA) location parameters
Enhancements to N3IWF: Service Requests, Handover Procedures, Idle Mode Management, and Voice/Video Call Support	2024.03.0	Following are the additional enhancement to the N3IWF for the seamless communication between the Wi-Fi network and the cellular network. UE Initiated Service Request through N3IWF Wi-Fi to NR Hand Over (HO) through N3IWF NR to N3IWF Wi-Fi HO UE initiated idle mode entry and exit procedure Voice or Video Call Over Wi-Fi with N3IWF and HO Support with Active Bearer, SMF also supports Evolved Packet System (EPS) fallback during hand over. Handling of RAT Type for N3IWF Sessions

The Non-3GPP Interworking Function (N3IWF) in the 5G SBA (Service Based Architecture) is responsible for interworking between untrusted non-3GPP networks and the 5G core. As such, the N3IWF supports both N2 and N3 based connectivity to the core, whilst supporting IPSec connectivity towards the device. The N3IWF provides the access and authentication protocols from the non-3GPP Wi-Fi network to seamlessly interface with the 5G Core Network by enabling the N2 and N3 interfaces.

This interface establishes an end-to-end security association between the User Equipment (UE) and N3IWF, irrespective of the security measures implemented at the layer 2 access level (WPA2).

SMF supports the following procedures:

PDU session establishment over N3IWF
PDU session release over N3IWF
UE initiated service request through N3IWF
Intra PLMN Wi-Fi to NR HO through N3IWF
Intra PLMN NR to N3IWF Wi-Fi HO
Network initiated service request through N3IWF
Inter PLMN Wi-Fi to NR handover
Inter PLMN NR to Wi-Fi handover
Wi-Fi (N3IWF) to Evolved Universal Terrestrial Radio Access (EUTRA) HO
EUTRA to Wi-Fi (N3IWF) HO
Next Generation Core-Agnostic (N3GA) location parameters

Architecture

The following figure represents the non-roaming architecture of 5G core network with untrusted non-3GPP access network.

UE Idle Mode Entry in N3IWF

SMF supports the UE/Access-initiated idle mode entry procedure to deactivate the UP connection. Deactivation of the UP connection includes the data radio bearer and N3 tunnel for an established PDU session of a UE in the CM-CONNECTED state.

Note

During the 5G PDU IM entry procedure, the IPSEC connection between the UE and N3IWF is released. This may result in future paging attempts from the SMF to fail.

Service Request handling during Idle Mode

Following are the two types of service request when UE is in idle mode:

UE initiated service request:

UE in idle mode uses the service request procedure through untrusted non-3GPP access over the 3GPP access. This service request is for the re-establishment of the NAS signalling connection and the re-establishment of the user plane for all or some of the PDU sessions associated to non-3GPP access.

UE in connected mode uses the service request procedure through untrusted non-3GPP access over the 3GPP access. This service request is for re-establishment of the user plane for one or more PDU Sessions which are associated to non-3GPP access.

A UE in the CM-IDLE state on non-3GPP access uses the UE-triggered service request procedure to reactivate the UP connection for existing PDU sessions and may also independently activate the UP connection for an existing PDU session.
Network initiated service request:

The SMF sends paging signals for N3IWF sessions that are in an idle state, where the connection between the UE and N3IWF has been released. In such cases, the N2 setup request might not be successful.

How it Works

N3IWF is deployed as a network function within the service provider's infrastructure. It interacts with various components of the 5G network architecture, such as the Access and Mobility Management Function (AMF), Session Management Function (SMF), and User Plane Function (UPF).

Call Flows

This section describes the call flows related to the N3IWF.

PDU Session Establishment Over N3IWF

UE performs initial registration and authentication with 5G core network using N3IWF. The 5G PDU session create over N3IWF remains the same as that of 5G NR PDU create except that the 5G PDU Create Request message includes these additional attributes:

ratType
anType
n3gaLocation

Note

5G PDU session create over N3IWF does not require EBI assignment to be performed.
The n3gaLocation attribute carrying N3GPP TAI information is included in 3GPP-User-Location-Info AVP and sent to RADIUS server if the anType attribute is Non-3GPP Access.
N3GaLocation information is shared only with PCF and CHF.

The following call flow describes the initiation of PDU establishment over N3IWF:

PDU Session Release over N3IWF

The PDU session release procedure over N3IWF remains the same as with the following 5G NR PDU session release procedures.

Access triggered release
Network triggered release
- PCF initiated
- Admin initiated
- CHF triggered
- IDLE timeout-based
- Release due to N4 path failure

UE Initiated Service Request through N3IWF

The SMF now handles PDU Idle Mode entry/exit procedures for Wi-Fi sessions attached through N3IWF.

Table 3. UE Initiated Service Request through N3IWF Call Flow Description
Step	Description
1	The UE sends a service request to the N3IWF with a list of PDU sessions to be activated and the current PDU session status.
2	The N3IWF forwards the N2 message service request to the AMF.
3	The AMF sends an Nsmf_PDUSession_UpdateSMContextRequest to the SMF (Session Management Function), including parameters such as anType, ratType, n3gaLocation, and upCnxState.
4	The SMF checks if the PDUSessionStatus indicates that the UE does not have an active session. If so, it triggers a session release.
5	If necessary, the SMF sends an N7 SmPolicyUpdateRequest to the PCF with ratType and n3gaLocation.
6	The PCF responds with a successful N7 SmPolicyUpdateResponse.
7	The SMF sends an N1N2TransferRequest to AMF.
8	AMF forwards the N1N2TransferRequest to N3IWF.
9	N3IWF responds with N2 PDU resource setup response to AMF.
10	The AMF responds with an N2 PDU resource setup response to the N3IWF.
11	The AMF sends another Nsmf_PDUSession_UpdateSMContextRequest to the SMF, indicating the UPF N3 Tunnel setup.
12	The SMF sends an N4 session modification request to the UPF to update the forwarding action rule.
13	The UPF responds with an N4 session modification response.
14	The SMF sends an Nsmf_PDUSession_UpdateSMContextResponse to the AMF.
15	If the charging trigger is enabled, the SMF sends an N4 modification request to the UPF to query the Usage Reporting Rule (URR).
16	The UPF responds with an N4 modification response, including the usage report.
17	The SMF sends an N40 ChargingDataRequest to the CHF.
18	The CHF responds with a successful N40 ChargingDataRequest.

Wi-Fi to NR HO through N3IWF

The following call flow describes about the intra-plmn Wi-Fi to NR HO for same AMF or old and new AMF in same PLMN. The call flow diagram illustrates the sequence of steps involved in transitioning a session from Wi-Fi (through N3IWF) to New Radio (NR) coverage in a 5G network.

Table 4. Wi-Fi to NR HO for N3IWF Call Flow Description
Step	Description
1	A Wi-Fi session is established with data tunneled to N3IWF.
2	The UE moves into NR coverage area.
3	The UE sends a PDU Session Establishment Request to the AMF with Existing-PDU-Session.
4	The AMF sends an Nsmf_PDUSession_UpdateSMContextRequest to the SMF with parameters such as anType=3GPP-ACCESS, ratType=NR and NR Location.
5	The SMF sends an N7 smPolicyControlUpdateRequest to the PCF with information SmPolicyContextData having userLocationInfo=NRLocation, ratType=NR.
6	The PCF responds with a 200 OK and SmPolicyDecision if any.
7	Optionally, The SMF sends an N40 ChargingDataRequest based on the information received from PCF in Step 6.
8	If N40 ChargingDataRequest is sent, The CHF responds with an N40 ChargingDataResponse.
9	On step 6, If PCF tries to install any new rules, then SMF sends a N4SessionModificationRequest towards UPF for flow creation (Creates PDR, FAR, URR for newly installed flows).
10	If Step 9 is sent, The UPF responds with N4SessionModificationResponse.
11	If epsInterworking is enabled, The SMF initiates the Namf_Commn_EbiAssignmentRequest to assign the EBI and the AMF responds with the assigned list of EBI(s) in Namf_Commn_EbiAssignmentResponse.
12	The SMF sends an Nsmf_PDUSession_UpdateSMContextResponse carrying both N1PDUSessionEstablishmentAccept to the UE and N2PDUResourceSetupRequestTransfer to the gNB (UPF-TEID same as the one used towards N3IWF).
13	The AMF forwards the N2PDUResourceSetupRequestTransfer and NAS PDU (N1PDUSessionEstablishmentAccept) towards gNB.
14	The gNB forwards the N1PDUSessionEstablishmentAccept to UE.
15	The gNB responds with N2PDUResourceSetupTransferResponse having the TEID.
16	The AMF sends an Nsmf_PDUSession_UpdateSMContextRequest to the SMF having the N2PDUResourceSetupTransferResponse.
17	The SMF sends an N4SessionModificationRequest with Update FAR to update the forwarding parameters and QueryURR to retrieve the usage report if any.
18	The UPF responds with N4SessionModificationResponse. The tunnel between UPF and gNB becomes active.
19	The SMF responds to the AMF with an Nsmf_PDUSession_UpdateSMContextResponse.
20	If any usage report received from UPF in Step 18, The SMF sends N40ChargingDataRequest to the CHF with the usage information and CHF responds with N40ChargingDataResponse.
21	In case of different AMF, The SMF initiates N1N2TransferRequest to source AMF (old) with the N2ResourceReleaseTransferRequest and AMF responds with N1N2TransferAck.
22	The Source AMF forwards the N2ResourceReleaseTransferRequest towards N3IWF.
23	The N3IWF responds with the N2ResourceReleaseTransferResponse to source AMF.
24	The AMF sends Nsmf_PDUSession_UpdateSMContextRequest to the SMF indicating N2Release success.
25	The SMF responds with an Nsmf_PDUSession_UpdateSMContextResponse to source AMF.
26	The SMF sends an Nsmf_PDUSession_SMContextStatusNotify to the source AMF to indicate the status of Handover. This step is applicable only when 3GPP 23 502 version spec is set to 15.6.0 under compliance profile.
27	If PCF requested for rule-reports of successful installation in step 6, SMF sends a N7smPolicyControlUpdateRequest to the PCF.
28	If step 25 is sent, PCF responds with N7 smPolicyControlUpdateResponse to SMF.

NR to N3IWF Wi-Fi HO

The following call flow describes about the intra-plmn NR to Wi-Fi HO for same AMF or old and new AMF in same PLMN. The call flow diagram illustrates the sequence of steps involved in transitioning a session from New Radio (NR) coverage to Wi-Fi coverage through N3IWF in a 5G network.

Table 5. NR to Wi-Fi HO for N3IWF Call Flow Description
Step	Description
1	A session is established over NR with data tunneled to the gNB.
2	The UE moves to an area with Wi-Fi coverage.
3	The UE sends a N1PDUSessionEstablishmentRequest to the N3IWF with Existing-PDU-Session.
4	The N3IWF forwards the N1PDUSessionEstablishmentRequest to the AMF with Existing-PDU-Session.
5	The AMF sends an Nsmf_PDUSession_UpdateSMContextRequest to the SMF with parameters such as anType=NON-3GPP-ACCESS, ratType=WLAN and N3GA Location.
6	The SMF sends an N7 smPolicyControlUpdateRequest to the PCF with information SmPolicyContextData having userLocationInfo=N3GA-Location, ratType=WLAN.
7	The PCF responds with a 200 OK and SmPolicyDecision if any.
8	Optionally, The SMF sends an N40ChargingDataRequest based on the information received from PCF in Step 6.
9	If Step 7 is sent, The CHF responds with an N40 ChargingDataResponse.
10	On step 7, If PCF tries to install any new rules, then SMF sends a N4SessionModificationRequest towards UPF for flow creation (Creates QER, PDR, FAR, URR for newly installed flows).
11	If Step 10 is sent, The UPF responds with N4SessionModificationResponse.
12	The SMF sends an Nsmf_PDUSession_UpdateSMContextResponse carrying both N1PDUSessionEstablishmentAccept to the UE and N2PDUResourceSetupRequestTransfer to the N3IWF (UPF-TEID same as the one used towards gNB).
13	The AMF forwards the N2PDUResourceSetupRequestTransfer and NAS PDU (N1PDUSessionEstablishmentAccept) to N3IWF.
14	The N3IWF forwards the N1PDUSessionEstablishmentAccept to UE.
15	The N3IWF responds with N2PDUResourceSetupTransferResponse having the TEID.
16	The AMF sends an Nsmf_PDUSession_UpdateSMContextRequest to the SMF having the N2PDUResourceSetupTransferResponse.
17	The SMF sends an N4SessionModificationRequest with Update FAR to update the forwarding parameters and QueryURR to retrieve the usage report if any.
18	The UPF responds with N4SessionModificationResponse. The tunnel between UPF and N3IWF becomes active.
19	If EPS Interworking is enabled in NR, the Nsmf_PDUSession_UpdateSMContextResponse message from SMF contains the releaseEbiList containing the list of EBIs to be released towards the AMF.
20	If any usage report received from UPF in Step 18, The SMF sends N40ChargingDataRequest to the CHF with the usage information and CHF responds with N40ChargingDataResponse.
21	In case of different AMF, The SMF initiates N1N2TransferRequest to source AMF (old) with the N2ResourceReleaseTransferRequest and AMF responds with N1N2TransferAck.
22	The Source AMF forwards the N2ResourceReleaseTransferRequest towards gNB.
23	The gNB responds with the N2ResourceReleaseTransferResponse to source AMF.
24	The AMF sends Nsmf_PDUSession_UpdateSMContextRequest to the SMF indicating N2Release success.
25	The SMF responds with an Nsmf_PDUSession_UpdateSMContextResponse to source AMF.
26	The SMF sends an Nsmf_PDUSession_SMContextStatusNotify to the source AMF to indicate the status of Handover. This step is applicable only when 3GPP 23502 version spec is set to 15.6.0 under compliance profile.
27	If PCF requested for rule-reports of successful installation in step 6, SMF sends a N7smPolicyControlUpdateRequest to the PCF.
28	If step 25 is sent, PCF responds with N7 smPolicyControlUpdateResponse to SMF.

Inter PLMN Wi-Fi to NR Handover

Following call flow describes the various steps related to the inter PLMN Wi-Fi to NR handover

Table 6. Inter PLMN Wi-Fi to NR Handover
Step	Description
1	A Wi-Fi session is established with data tunnel to N3IWF.
2	The UE moves into NR coverage area.
3	The UE sends a PDU session establishment request to the AMF with existing-PDU-session.
4	The AMF sends an Nsmf_PDUSession_CreateSMContextRequest to the SMF with parameters such as anType=3GPP-ACCESS, ratType=NR and NR Location.
5	The SMF sends an Nsmf_PDUSession_CreateSMContextResponse.
6	The SMF sends an N7 smPolicyControlUpdateRequest to the PCF with information SmPolicyContextData having userLocationInfo=NRLocation, ratType=NR.
7	The PCF responds with a 200 OK and SmPolicyDecision if any.
8	Optionally, The SMF sends an N40ChargingDataRequest based on the information received from PCF in Step 6.
9	If Step 8 is sent, The CHF responds with an N40 ChargingDataResponse.
10	On step 7, If PCF tries to install any new rules, then SMF sends a N4SessionModificationRequest towards UPF for flow creation (Creates QER, PDR, FAR, URR for newly installed flows).
11	If Step 10 is sent, The UPF responds with N4SessionModificationResponse.
12	If epsInterworking is enabled, The SMF initiates the Namf_Commn_EbiAssignmentRequest to assign the EBI and the AMF responds with the assigned list of EBI(s) in Namf_Commn_EbiAssignmentResponse.
13	The SMF sends an N1N2TransferRequest carrying both N1PDUSessionEstablishmentAccept to the UE and N2PDUResourceSetupRequestTransfer to the gNB (UPF-TEID same as the one used towards N3IWF).
14	The AMF responds with N1N2TransferACK to SMF.
15	The AMF forwards the N2PDUResourceSetupRequestTransfer and NAS PDU (N1PDUSessionEstablishmentAccept) towards gNB.
16	The gNB forwards the N1PDUSessionEstablishmentAccept to UE.
17	The gNB responds with N2PDUResourceSetupTransferResponse having the TEID.
18	The AMF sends an Nsmf_PDUSession_UpdateSMContextRequest to the SMF having the N2PDUResourceSetupTransferResponse.
19	The SMF sends an N4SessionModificationRequest with Update FAR to update the forwarding parameters and QueryURR to retrieve the usage report if any.
20	The UPF responds with N4SessionModificationResponse. The tunnel between UPF and gNB becomes active.
21	The SMF responds to the AMF with an Nsmf_PDUSession_UpdateSMContextResponse.
22	If any usage report received from UPF in Step 20, The SMF sends N40ChargingDataRequest to the CHF with the usage information and CHF responds with N40ChargingDataResponse.
23	In case of different AMF, The SMF initiates N1N2TransferRequest to source AMF (old) with the N2ResourceReleaseTransferRequest and AMF responds with N1N2TransferAck.
24	The Source AMF forwards the N2ResourceReleaseTransferRequest towards N3IWF.
25	The N3IWF responds with the N2ResourceReleaseTransferResponse to source AMF.
26	The AMF sends Nsmf_PDUSession_UpdateSMContextRequest to the SMF indicating N2Release success.
27	The SMF responds with an Nsmf_PDUSession_UpdateSMContextResponse to source AMF.
28	The SMF sends an Nsmf_PDUSession_SMContextStatusNotify to the source AMF to indicate the status of Handover. This step is applicable only when 3GPP 23502 version spec is set to 15.6.0 under compliance profile.
29	If PCF requested for rule-reports of successful installation or resource release in step 7, SMF sends a N7smPolicyControlUpdateRequest to the PCF.
30	If step 29 is sent, PCF responds with N7 smPolicyControlUpdateResponse to SMF.

The SMF supports handover with an active bearer to 5G and can initiate EPS-FB if any flow fails with the cause indication "EPS-FB required."

Inter PLMN NR to Wi-Fi Handover

Following call flow describes the various steps related to the inter PLMN NR to Wi-Fi handover

Table 7. Inter PLMN NR to Wi-Fi Handover
Step	Description
1	A session is established over NR with data tunneled to the gNB.
2	The UE moves to an area with Wi-Fi coverage.
3	The UE sends a N1PDUSessionEstablishmentRequest to the N3IWF with existing-PDU-session.
4	The N3IWF forwards the N1PDUSessionEstablishmentRequest to the AMF with existing-PDU-session.
5	The AMF sends an Nsmf_PDUSession_CreateSMContextRequest to the SMF with parameters such as anType=NON-3GPP-ACCESS, ratType=WLAN and N3GA Location.
6	The SMF sends an Nsmf_PDUSession_UpdateSMContextResponse to AMF.
7	The SMF sends an N7 smPolicyControlUpdateRequest to the PCF with information SmPolicyContextData having userLocationInfo=N3GA-Location, ratType=WLAN.
8	The PCF responds with a 200 OK and SmPolicyDecision if any.
9	Optionally, The SMF sends an N40ChargingDataRequest based on the information received from PCF in Step 8.
10	If Step 9 is sent, The CHF responds with an N40 ChargingDataResponse.
11	On step 8 If PCF tries to install any new rules, then SMF sends a N4SessionModificationRequest towards UPF for flow creation (Creates PDR, FAR, URR for newly installed flows).
12	If Step 11 is sent, The UPF responds with N4SessionModificationResponse.
13	The SMF sends an N1N2TransferRequest carrying both N1PDUSessionEstablishmentAccept to the UE and N2PDUResourceSetupRequestTransfer to the N3IWF (UPF-TEID same as the one used towards gNB).
14	The AMF responds with N1N2TransferACK to SMF.
15	The AMF forwards the N2PDUResourceSetupRequestTransfer and NAS PDU (N1PDUSessionEstablishmentAccept) to N3IWF.
16	The N3IWF forwards the N1PDUSessionEstablishmentAccept to UE.
17	The N3IWF responds with N2PDUResourceSetupTransferResponse having the TEID.
18	The AMF sends an Nsmf_PDUSession_UpdateSMContextRequest to the SMF having the N2PDUResourceSetupTransferResponse.
19	The SMF sends an N4SessionModificationRequest with Update FAR to update the forwarding parameters and QueryURR to retrieve the usage report if any.
20	The UPF responds with N4SessionModificationResponse. The tunnel between UPF and N3IWF becomes active.
21	The SMF responds to the AMF with an Nsmf_PDUSession_UpdateSMContextResponse.
22	If any usage report received from UPF in Step 20, The SMF sends N40ChargingDataRequest to the CHF with the usage information and CHF responds with N40ChargingDataResponse.
23	In case of different AMF, The SMF initiates N1N2TransferRequest to source AMF (old) with the N2ResourceReleaseTransferRequest and AMF responds with N1N2TransferAck.
24	The Source AMF forwards the N2ResourceReleaseTransferRequest towards gNB.
25	The gNB responds with the N2ResourceReleaseTransferResponse to source AMF.
26	The AMF sends Nsmf_PDUSession_UpdateSMContextRequest to the SMF indicating N2Release success.
27	The SMF responds with an Nsmf_PDUSession_UpdateSMContextResponse to source AMF.
28	The SMF sends an Nsmf_PDUSession_SMContextStatusNotify to the source AMF to indicate the status of handover. This step is applicable only when 3 GPP 23502 version spec is set to 15.6.0 under compliance profile.
29	If PCF requested for rule-reports of successful installation in step 8, SMF sends a N7smPolicyControlUpdateRequest to the PCF.
30	If step 29 is sent, PCF responds with N7 smPolicyControlUpdateResponse to SMF.

Wi-Fi to EUTRA Handover

Following call flow describes the various steps related to Wi-Fi to EUTRA handover.

Table 8. Wi-Fi to EUTRA Handover
Step	Description
1	A Wi-Fi session is established with data tunnel to N3IWF.
2	The UE moves into 4G/LTE coverage area.
3	The MME sends a GTPv2CreateSessionRequest to the S-GW.
4	The S-GW sends a GTPv2CreateSessionRequest with handover indication set along with the default bearer F-TEID information.
5	The SMF sends an N7 smPolicyControlUpdateRequest to the PCF with information SmPolicyContextData having userLocationInfo=EutraLocation, ratType=EUTRA.
6	The PCF responds with a 200 OK and SmPolicyDecision if any.
7	Optionally, The SMF sends an N40 ChargingDataRequest based on the information received from PCF in Step 6.
8	If Step 7 is sent, The CHF responds with an N40 ChargingDataResponse.
9	On step 6, If PCF tries to install any new rules or rulebase change, then SMF sends a N4SessionModificationRequest towards UPF for flow creation (Creates PDR, FAR, URR for newly installed flows).
10	If Step 9 is sent, The UPF responds with N4SessionModificationResponse.
11	The SMF sends GTPv2CreateSessionResponse to SGW. Here, still the uplink and downlink data for both default and dedicated bearer flows through Wi-Fi.
12	The S-GW forwards the GTpv2CreateSessionResponse to MME.
13	The MME sends a GTPv2ModifyBearerRequest to the S-GW.
14	The S-GW sends a GTPv2ModifyBearerRequest with Handover Indication set.
15	The SMF sends a N4SessionModificationRequest with Update FAR to update the forwarding parameters for the default bearer, QueryURR to retrieve the usage report if any, Update PDR for any of the modified rules if any and Remove PDR for any of the deleted rules.
16	The UPF responds with N4SessionModificationResponse. The tunnel between UPF and SGW becomes active for the default bearer. Here, the uplink and downlink data for default bearer flows through EUTRA and data for dedicated bearers still flows through Wi-Fi.
17	The SMF sends GTPv2ModifyBearerResponse to S-GW.
18	The S-GW forwards the GTpv2ModifyBearerResponse to MME.
19	The SMF sends GTPv2CreateBearerRequest to S-GW having the list of bearer contexts for dedicated bearers.
20	The S-GW sends GTPv2CreateBearerRequest to MME.
21	The MME sends GTPv2CreateBearerResponse to S-GW.
22	The S-GW sends GTPv2CreateBearerResponse to SMF with the list of accepted bearer context along with EBIs and DlTunnelInformation (TEID and so on).
23	The SMF sends a N4SessionModificationRequest with Update FAR to update the forwarding parameters for the dedicated bearer.
24	The UPF responds with N4SessionModificationResponse. The tunnel between UPF and S-GW becomes active for the dedicated bearers. Here, the uplink and downlink data for both default and dedicated bearer flows through EUTRA.
25	The SMF initiates N1N2TransferRequest to source AMF with the N2ResourceReleaseTransferRequest and AMF responds with N1N2TransferAck.
26	The AMF forwards the N2ResourceReleaseTransferRequest towards N3IWF.
27	The N3IWF responds with the N2ResourceReleaseTransferResponse to AMF.
28	The AMF sends Nsmf_PDUSession_UpdateSMContextRequest to the SMF indicating N2Release success.
29	The SMF responds with an Nsmf_PDUSession_UpdateSMContextResponse to AMF.
30	The SMF sends an Nsmf_PDUSession_SMContextStatusNotify to the AMF to indicate the status of handover. This step is applicable only when 3GPP 23502 version spec is set to 15.6.0 under compliance profile.
31	If any usage report received from UPF in Step 16, The SMF sends N40ChargingDataRequest to the CHF with the usage information and CHF responds with N40ChargingDataResponse.
32	If PCF requested for rule-reports of successful installation in step 6, SMF sends a N7smPolicyControlUpdateRequest to the PCF.
33	If step 32 is sent, PCF responds with N7 smPolicyControlUpdateResponse to SMF.

EUTRA to Wi-Fi Handover

Following call flow describes the various steps related to EUTRA to Wi-Fi handover.

Table 9. EUTRA to Wi-Fi Handover
Step	Description
1	A session is established over EUTRA with data tunneled to eNB through SGW.
2	The UE moves to an area with Wi-Fi coverage.
3	The UE sends a N1PDUSessionEstablishmentRequest to the N3IWF.
4	The N3IWF forwards the N1PDUSessionEstablishmentRequest to the AMF.
5	The AMF sends an Nsmf_PDUSession_CreateSMContextRequest to the SMF with parameters such as anType=NON-3GPP-ACCESS, ratType=WLAN and N3GA Location.
6	The SMF sends an Nsmf_PDUSession_CreateSMContextResponse to AMF.
7	The SMF sends an N7 smPolicyControlUpdateRequest to the PCF with information SmPolicyContextData having userLocationInfo=N3GA-Location, ratType=WLAN.
8	The PCF responds with a 200 OK and SmPolicyDecision if any.
9	Optionally, The SMF sends an N40ChargingDataRequest based on the information received from PCF in Step 8.
10	If Step 9 is sent, The CHF responds with an N40 ChargingDataResponse.
11	On step 8 If PCF tries to install any new rules, then SMF sends a N4SessionModificationRequest towards UPF for flow creation (Creates PDR, FAR, URR for newly installed flows).
12	If Step 11 is sent, The UPF responds with N4SessionModificationResponse.
13	The SMF sends an N1N2TransferRequest carrying both N1PDUSessionEstablishmentAccept to the UE and N2PDUResourceSetupRequestTransfer to the N3IWF (UPF-TEID same as the one used towards EUTRA).
14	The AMF responds with N1N2TransferACK to SMF.
15	The AMF forwards the N2PDUResourceSetupRequestTransfer and NAS PDU (N1PDUSessionEstablishmentAccept) to N3IWF.
16	The N3IWF forwards the N1PDUSessionEstablishmentAccept to UE.
17	The N3IWF responds with N2PDUResourceSetupTransferResponse having the TEID.
18	The AMF sends an Nsmf_PDUSession_UpdateSMContextRequest to the SMF having the N2PDUResourceSetupTransferResponse.
19	The SMF sends an N4SessionModificationRequest with Update FAR to update the forwarding parameters and QueryURR to retrieve the usage report if any.
20	The UPF responds with N4SessionModificationResponse. The tunnel between UPF and N3IWF becomes active.
21	The SMF responds to the AMF with an Nsmf_PDUSession_UpdateSMContextResponse.
22	If any usage report received from UPF in Step#20, The SMF sends N40ChargingDataRequest to the CHF with the usage information and CHF responds with N40ChargingDataResponse.
23	The SMF initiates GTPv2DeleteBearerRequest to SGW for cleaning up the resources.
24	The SGW forwards the GTPv2DeleteBearerRequest towards MME.
25	The MME responds with the GTPv2DeleteBearerResponse to SGW.
26	The SGW sends GTPv2DeleteBearerResponse to the SMF indicating Delete Bearer success.
27	If PCF requested for rule-reports of successful installation or resource release in step 8, SMF sends a N7smPolicyControlUpdateRequest to the PCF.
28	If step 27 is sent, PCF responds with N7 smPolicyControlUpdateResponse to SMF.

N3GA Location Parameters

SMF supports N3GALocation parameters according to 3GPP TS 29.571 release 16.4.0. When the AMF sends N3GA location, SMF includes the following attributes in the N3GALocation sent to peer interfaces like N7 (PCF) and N40 (CHF), after configuring the proper compliance version."


Attribute name	Description
n3gppTai	The unique non 3GPP TAI used in the PLMN. It is present in the 3GPP PLMN internal interfaces, but is not present in the N5 interface.
n3IwfId	This IE contains the N3IWF identifier received over NGAP and is encoded as a string of hexadecimal characters. Each character in the string takes a value of "0" to "9" or "A" to "F" and represent 4 bits. The most significant character representing the 4 most significant bits of the N3IWF ID appears first in the string, and the character representing the 4 least significant bit of the N3IWF ID appears last in the string. Pattern: '^[A-Fa-f0-9]+$' Example: The N3IWF Id 0x5BD6 is encoded as "5BD6". It is present in the 3GPP PLMN internal interfaces if the UE is accessing the 5GC through an untrusted non-3GPP access, but is not present in the N5 interface.
ueIpv4Addr	UE/N5CW device local IPv4 address (used to reach the N3IWF, TNGF or TWIF). The ueIPv4Addr or the ueIPv6Addr is present if the UE is accessing the 5GC through a trusted or untrusted non-3GPP access and the information is available.
ueIpv6Addr	UE/N5CW device local IPv6 address (used to reach the N3IWF, TNGF or TWIF). The ueIPv4Addr or the ueIPv6Addr is present if the UE is accessing the 5GC through a trusted or untrusted non-3GPP access and the information is available.
portNumber	UDP or TCP source port number. It is present if the UE is accessing the 5GC through a trusted or untrusted non-3GPP access and NAT is detected.
tnapId	This IE contains the Trusted Non-3GPP Access Point (TNAP) Identifier.
hfcNodeId	This IE contains the HFC Node Identifier received over NGAP. It is present for a 5G- CRG/FN-CRG accessing the 5GC through wireline access network.
gli	This IE contains the Global Line Identifier. It is present for a 5G-BRG/FN-BRG accessing the 5GC through wireline access network.
w5gbanLineType	This IE may be present for a 5G-BRG/FN-BRG accessing the 5GC through wireline access network. When present, it indicates the type of the wireline (DSL or PON).
twapId	This IE contains the Trusted WLAN Access Point (TWAP) Identifier.

Note

In the case of an attach through ePDG, the system populates only the IP address, port, and protocol if they are available. The SMF does not populate any optional parameters if they are not available.
SMF sends the N3GPPTAI alone as part of ULI under SUB_PARAMS IE in all the N4 messages.
SMF supports the following parameters in the N3GA location as per 3GPP TS 29.571 Release 16.4.0.
- tnapId
- hfcNodeId
- gli
- w5gbanLineType
- twapId

Voice or Video Call Over Wi-Fi with N3IWF and HO Support with Active Bearer

This feature is crucial for maintaining call continuity when a user moves from one network to another (example, from Wi-Fi to cellular or vice versa). "Active Bearer" refers to an ongoing data session or call. So, "HO Support for Active Bearer" means that the system can handle the transition of an ongoing call or data session from one network to another without dropping the connection.

Handling of RAT Type for N3IWF Sessions

Prior to Release 2024.03, The SMF used to processes the PDU session establishment request received for N3IWF-based sessions with RAT-type set to NR.

From Release 2024.03 onwards, The SMF now rejects PDU session establishment requests for N3IWF-based sessions with RAT-type set to NR and only processes requests if the RAT-type is set to WLAN (According to release 16.4.0 of 3GPP spec 23.501).

Standard Compliance

The N3IWF feature complies with the following standards:

3GPP 23.501 release 15 version

OAM Support

Bulk Statistics Support

This feature supports a new label "anType" as part of the smf service stats. This label defines the access network type as 3GPP access or non-3GPP access.

For more information on bulk statistics support, see the UCC 5G SMF Metrics Reference document applicable for this release.

SMF supports the following set of new values for procedure-type in smf_service_stats:

pduim_ran_req_active_to_idle_non3gpp - RAN initiated Idle Mode entry
pduim_nw_req_active_to_idle_non3gpp - NW initiated Idle Mode entry
pduim_ue_req_idle_to_active_non3gpp - UE initiated Idle Mode Exit

SMF uses the existing procedure type labels along with ‘an-type” label to differentiate between the NR and N3IWF sessions.

nr_to_untrusted_wifi_handover - NR to N3IWF Handover
utn3gpp_to_5g_handover - N3IWF to NR Handover
ue_req_pdu_sess_mod - UE initiated PDU Modification
amf_req_pdu_sess_mod - AMF initiated PDU Modification
smf_req_pdu_sess_mod - SMF initiated PDU Modification
pcf_req_pdu_sess_mod - PCF initiated PDU Modification
udm_req_pdu_sess_mod - UDM initiated PDU Modification
gnb_req_pdu_sess_mod - GNB initiated PDU Modification
pcscf_restoration_init_mod - PCSCF restoration initiated PDU Modification

enb_to_n3iwf_handover - enodeB to N3IWF Handover
n3iwf_wifi_to_enb_handover - N3IWF to enodeB Handover
pduim_ran_req_active_to_idle_non3gpp - UE active to idle in non-3GPP access

Monitoring Support

The existing show subscriber and clear subscriber commands include a new filter option "an-type" to indicate the access type of subscribers. The show subscriber command output also displays information on N3Ga location.

If the UE connects to the Wi-Fi access point and attempts to attach through ePDG, the access type is categorized as non-3GPP access. In the case of N3IWF sessions attaching through AMF, the access type is 3GPP access and the an-type is non-3gpp access.

Logging Support

This feature provides support for access network type information in the procedure failure logs.

UCC 5G SMF Configuration and Administration Guide, Release 2025.01

Bias-Free Language

Book Title

UCC 5G SMF Configuration and Administration Guide, Release 2025.01

Chapter Title