Innovating Telecoms Training

Interworking with LTE and Wi-Fi

Reference Document

www.mpirical.com
Interworking with LTE and Wi-Fi

Interworking with LTE and Wi-Fi

Reference Document

MPI0146-010-070 © Mpirical Limited, 2019 i

 Interworking with LTE and Wi-Fi

This course has been independently assessed and accredited by both the ITP (Institute of
Telecommunications Professionals) and the CPD Standards Office (Continuing Professional
Development). Their marks of excellence awarded to Mpirical provides you with the
recognition that the learning you have completed conforms to best practice and is
appropriate for inclusion in a formal training record.
Our certified courses mean you can be certain you’re receiving the highest quality
training. Both the ITP and the CPD use independent specialists to regularly assess all our
products and services. Including our Learning.

The ITP is the UK’s leading independent institution for people who work in
telecommunications. It is dedicated to promoting the professional development of members
through Professional Registration, training, mentoring and qualifications. The ITP
collaborates with regulators, government associations and other leading bodies on projects
that are important to the future of the industry. It has worked with businesses including; BT,
Cable & Wireless Worldwide, Alcatel-Lucent, Huawei and Vodafone.

By providing independent accreditation, the CPD improve the quality of continuing

professional development. Their marks of excellence for training providers demonstrate to
individual professionals that the learning activity conforms to best practice and is appropriate
for inclusion in a formal record.

Find out more about your certification at:

www.mpirical.com/certified-telecoms-training

Mpirical classes have been developed in accordance with the technical specifications
published by the 3GPP. As such the 3GPP have granted Mpirical Limited the right to use the
3GPP logo to identify specifications, compliant products and services.

First published by Mpirical Limited in 2019

© Mpirical Limited, 2019
All rights reserved. No part of this book or accompanying software may be reproduced or
transmitted in any form by any means, electronic, mechanical, photocopying, recording, or
otherwise without the prior written consent of the publisher. Although every precaution has
been taken in the preparation of this book the publisher assumes no responsibility for errors
and omissions. Nor is any liability assumed for damages resulting from the use of the
information contained within.

ii © Mpirical Limited, 2019 MPI0146-010-070

Interworking with LTE and Wi-Fi

Contents

Interworking with LTE ............................................................................................ 1

1.1 Single and Dual Registration Mode .............................................................. 2
1.2 Basic Mobility Scenarios (with N26) .............................................................. 3
1.3 Basic Mobility Scenarios (without N26) ......................................................... 4
Connected Mode Mobility Procedures (with N26) ................................................. 6
2.1 5GS to EPS Handover .................................................................................. 6
2.2 EPS to 5GS Handover .................................................................................. 9
Fallback Mechanisms .......................................................................................... 13
Interworking with Non-3GPP Networks ............................................................... 14
4.1 Architecture for Non-3GPP Accesses ......................................................... 14
4.2 Non-3GPP Access Registration .................................................................. 15
4.3 Establishing PDU Sessions......................................................................... 18
4.4 Modifying a PDU Session ........................................................................... 21
4.5 Utilizing PDU Sessions ............................................................................... 21
4.6 5G WLAN Aggregation ................................................................................ 22

Glossary ............................................................................................ 25

MPI0146-010-070 © Mpirical Limited, 2019 iii

 Interworking with LTE and Wi-Fi

iv © Mpirical Limited, 2019 MPI0146-010-070

Interworking with LTE and Wi-Fi

Figures

Figure 1 Hybrid 4G/5G Networks .................................................................................. 1

Figure 2 Core Network Interworking Architecture ......................................................... 2

Figure 3 User Equipment Registration Modes .............................................................. 2

Figure 4 Basic EPC to 5GC Mobility (Single Registration, Idle Mode) .......................... 3

Figure 5 Basic 5GC to EPC Mobility (Single Registration, Idle Mode) .......................... 4

Figure 6 Advertising Support for Dual Registration Mode ............................................. 4

Figure 7 Key Considerations when N26 is not Supported ............................................ 4

Figure 8 Dual Registration Mode with no Support for N26............................................ 5

Figure 9 Single Registration Mode with no Support for N26 ......................................... 6

Figure 10 5GS to EPS Handover with N26 (Part 1) ...................................................... 7

Figure 11 5GS to EPS Handover with N26 (Part 2) ...................................................... 7

Figure 12 Indirect Forwarding Tunnel............................................................................ 8

Figure 13 5GS to EPS Handover with N26 (Part 3) ...................................................... 9

Figure 14 EPS to 5GS Handover Preparation with N26 (Part 1) ................................ 10

Figure 15 EPS to 5GS Handover Preparation with N26 (Part 2) ................................ 11

Figure 16 PDU Forwarding .......................................................................................... 11

Figure 17 EPS to 5GS Handover Execution with N26 (Part 1) ................................... 12

Figure 18 EPS to 5GS Handover Execution with N26 (Part 2) ................................... 13

Figure 19 Fallback Mechanisms.................................................................................. 13

Figure 20 Advertising Support for Fallback ................................................................. 13

Figure 21 Fallback Procedure ..................................................................................... 14

Figure 22 Non-3GPP Access to 5GC .......................................................................... 15

Figure 23 RM Context Information Stored at the AMF ................................................ 15

Figure 24 Registration via Untrusted non-3GPP Access – Part 1 ............................... 17

Figure 25 Registration via Untrusted non-3GPP Access – Part 2 ............................... 17

Figure 26 Establishing PDU Sessions over Untrusted non-3GPP Access (Part 1) .... 18

Figure 27 Establishing PDU Sessions over Untrusted non-3GPP Access (Part 2) .... 19

Figure 28 Establishing PDU Sessions over Untrusted non-3GPP Access (Part 3) .... 20

Figure 29 Establishing PDU Sessions over Untrusted non-3GPP Access (Part 4) .... 20

Figure 30 Data Forwarding over Untrusted non-3GPP Access................................... 20

MPI0146-010-070 © Mpirical Limited, 2019 v

 Interworking with LTE and Wi-Fi

Figure 31 Modifying a PDU Session ........................................................................... 21

Figure 32 Utilizing PDU Sessions ............................................................................... 22

Figure 33 LTE WLAN Aggregation .............................................................................. 22

Figure 34 5G WLAN Aggregation ................................................................................ 22

Figure 35 Coverage Augmentation Utilizing WLAN Aggregation ................................ 23

vi © Mpirical Limited, 2019 MPI0146-010-070

Interworking with LTE and Wi-Fi

Interworking with LTE

As the migration towards 5G continues, a period of interworking between 5G
and the LTE EPC (Evolved Packet Core) will take place. The magnitude of
this interworking is dependent on both the architecture the service providers
choose to deploy and the 5G capabilities of the handset market. Indeed, for a
given PLMN (Public Land Mobile Network), there will potentially by a mixture
of solutions in operation to meet the requirements of the subscriber base.
This concept is illustrated in Figure 1, which shows the different network
connectivity options which may be deployed. Note that to facilitate smooth
migration to 5G, the EPC and the 5GC (5G Core) will require access to a
common master database.

S6a
HSS UDM N8/N10
EPC 5GC

3
N2/N
S1

3
N2/N
S1

E-UTRAN E-UTRAN Xn X2 5G NR

EPC UE EPC UE (DC Capable) N1 UE N1 UE

E-UTRA and 4G E-UTRA Master, 5G NR E-UTRA and 4G NR and 5G NAS
NAS Only Secondary,4G NAS Only NAS/5G NAS

Figure 1 Hybrid 4G/5G Networks

In Figure 1, N1 devices are devices that are capable of supporting 5G NAS

(Non Access Stratum) signalling and hence the N1 reference point between
the UE and the AMF (Access and Mobility Management Function). These
devices can typically also support 4G NAS and will choose between 4G or 5G
NAS based on the available access network connectivity. Although Figure 1
shows only one DC (Dual Connectivity) handset, it is likely that the N1 devices
will also be capable of dual connectivity with the E-UTRAN (Evolved –
Universal Terrestrial Radio Access Network).
In order to facilitate the interworking approach outlined in Figure 1, the device
must be aware of which connectivity options are available. As such, the 4G
ng-eNB will broadcast a capability indication that will inform devices that it can
connect to the 5GC. Moreover, devices which are capable of using 5G NAS
will inform the network of this capability when they initiate RAN access.
Figure 2 shows the interworking architecture for the RAN and core network,
as defined by the 3GPP. Note that some of the terminology such as PGW-C
(PDN Gateway – Control Plane) and PGW-U (PDN Gateway – User Plane) is
adopted from the 3GPP’s architecture for separation of the control plane and
user plane of EPC nodes 1.
Network elements such as the HSS/UDM (Home Subscriber Server/User
Data Management), SMF/PGW-C (Session Management Function/PDN

1
TS 23.214 - Architecture enhancements for control and user plane separation of EPC nodes

MPI0146-010-070 © Mpirical Limited, 2019 1

 Interworking with LTE and Wi-Fi

Gateway – Control) and UPF/PGW-U (User Plane Function/PDN GW – User

plane) are dedicated for interworking between the 5GC and the EPC.

MME
HSS +
a
S6
UDM
S1
ME 1
S1
-M
PCF Data
S-GW
N2
6 N1
0 Network
N6
S5 N7
-C SMF
PGW-C
N8
S1
-U UPF
S5
PGW-U N4
N1
5
-U

E-UTRAN
N1
1

N3 AMF
5G-NR
N2

UE

Figure 2 Core Network Interworking Architecture

1.1 Single and Dual Registration Mode

In order to support interworking with the EPC, a device that supports both
5GC and EPC NAS operates in either Single or Dual Registration Mode. The
difference between the two is outlined in Figure 3.

Single Registration Device has one active Mobile Management state (RM or EMM) and
Mode will be operating either 5GC NAS or EPC NAS

Dual Registration Device can manage independent registrations for both 5GC and EPC
Mode (device can be EPC Only, 5GC Only or Both)

Figure 3 User Equipment Registration Modes

If the optional N26 reference point between the MME (Mobility Management
Entity) and the AMF is deployed, devices will only operate in Single
Registration Mode. This is due to the fact that N26 allows the service provider
to perform interworking procedures between the EPC and the 5GC such as
handover. Therefore, there is no requirement for the device to be in Dual
Registration Mode; instead, when necessary, N26 can be utilized to facilitate a
handover between the two core networks. With this approach, the network will
hold only one Mobility Management state for the device; either at the AMF or
MME, based on current connectivity.
Although optional, N26 is required to support session continuity between the
EPC and 5GC. One particular example of when session continuity is essential
is in the support of voice services. During an inter-system change, N26 can be
used to ensure the subscriber does not experience a service disruption within
an ongoing voice call. By this rationale, it is likely that the service provider has
the N26 reference point available.

2 © Mpirical Limited, 2019 MPI0146-010-070

Interworking with LTE and Wi-Fi

1.2 Basic Mobility Scenarios (with N26)

Basic EPC to 5GC Mobility (Single Registration Mode)
Figure 4 shows the high level steps associated with Single Registration, idle
mode mobility as the mobile moves from EPC to 5GC (with N26 supported).
In step 1, the device has entered 5G coverage and attempts a Registration
procedure, sending its 4G GUTI (Globally Unique Temporary Identity) within
the Registration Request message. This allows the AMF to identify the MME
that is holding the device’s Mobility and Session Management information in
the EPC. Accordingly, in Step 2, the AMF will acquire this information from the
MME via N26. The AMF is then able to complete the Registration procedure,
establishing security and setting up the appropriate PDU sessions based on
the information supplied by the MME. This process includes informing the
UDM/HSS that the device is now registered in the 5GC (Step 3). In turn, the
UDM/HSS will cancel the subscriber’s registration at the MME (Step 4).

MME 4
HSS +
a
S6
UDM
S1
-M
ME 1 PCF Data
S1
S-GW PCRF
N2
6 N1
0 Network
N6
S5 N7
-C SMF
PGW-C
N8
S1
-U UPF 3
S5
PGW-U N4
N1
5
-U
2

E-UTRAN
N1
1

N3 AMF
5G-NR 1
N2

UE

Figure 4 Basic EPC to 5GC Mobility (Single Registration, Idle Mode)

With respect to connected mode mobility, transition between the EPC and
5GC will take place as a coordinated handover procedure facilitated by the
N26 reference point (see Figure 10 onwards for further details).
Basic 5GC to EPC Mobility (Single Registration Mode)
There is a slight difference when you consider idle mode mobility when
moving between the 5GC and EPC. This is due to the fact that in 5G, the
device can be registered but not have a PDU Session active. The high level
5GC to EPC transition is outlined in Figure 5.
In step 1, when the device loses 5G coverage and enters 4G coverage, it will
send a Tracking Area Update message to the MME. This message will include
the 5G GUTI of the device, which allows the MME to identify the AMF at which
the device is registered. As such, the MME can acquire the subscriber’s
Mobility Management and Session Management information from the AMF
(Step 2).
At Step 3, if the device did not have a PDU Session active in 5G, it may need
to conduct an Attach Procedure with PDN Connectivity Establishment with the
MME. There is an exception to this, if the device and MME support “attach
without PDN connectivity”; in this instance, the device will not need to
establish a PDN connection on 4G.

MPI0146-010-070 © Mpirical Limited, 2019 3

 Interworking with LTE and Wi-Fi

As part of the 4G Attach procedure, the MME will inform the HSS/UDM that
the subscriber is currently registered within the EPC (Step 4). Consequently,
the HSS/UDM will ensure that the registration state held at the AMF for this
subscriber is cancelled (Step 5).
With respect to connected mode mobility, transition between the 5GC and
EPC will take place as a coordinated handover procedure facilitated by the
N26 reference point (see Figure 10 onwards for further details).

MME 4
HSS +
3 S6
a
UDM
ME
S1
1 2 PCF
S1
-M
PCRF Data
S-GW
N2
6 N1
0 Network
N6
S5 N7
-C SMF
PGW-C
1 N8
S1
-U UPF
S5
PGW-U N4
N1
5
-U

5
E-UTRAN
N1
1

N3 AMF
5G-NR
N2

UE

Figure 5 Basic 5GC to EPC Mobility (Single Registration, Idle Mode)

1.3 Basic Mobility Scenarios (without N26)

When N26 is not available, the device can operate in either Single or Dual
Registration Mode. As such, the operation of the network must differ
accordingly based on the selected mode of operation. Where appropriate, the
network will advertise to the device that Dual Registration Mode is permitted.

Indication to the device

that Dual Registration is
supported

5G Network

UE

Figure 6 Advertising Support for Dual Registration Mode

If the network does not support N26, the HSS/UDM acts as a focal point for
subscriber information when transitioning to the 5GC from EPC or vice versa.
For this to work, the SMF/PGW-C must keep the HSS/UDM informed as to
the current IP addressing and Data Network connectivity that the device has
in place. Moreover, the source network will not provide the mapped QoS
parameters to the device, due to the fact that in both EPC to 5GC and 5GC to
EPC mobility, the device will have to re-establish PDN Connections/PDU
Sessions with the target network, during which process the network will
provide the QoS parameters directly to the device.

HSS/UDM acts as a SMF/PGW-C provides Mapped QoS

focal point for IP address and DN Parameters are not
subscriber info info to HSS/UDM provided

Figure 7 Key Considerations when N26 is not Supported

4 © Mpirical Limited, 2019 MPI0146-010-070

Interworking with LTE and Wi-Fi

Dual Registration Mode with no Support for N26

Devices operating in Dual Registration mode, during a mobility scenario, can
potentially “pre-register” with the target network before they transition to it.
With respect to each mobility scenario:
 5GC to EPC Mobility – the device can pre-register using the EPS
Attach without PDN Connectivity procedure (which must be supported
if the network supports Dual Registration Mode). When the device
moves to the EPC, individual PDN Connections can then be moved
across using the PDN Connectivity Establishment procedure, with the
handover flag set. Note that the device can be selective about which
bearers it chooses to bring across to the EPC and which should remain
in the 5GC.
 EPC to 5GC Mobility – once again, the device is able to pre-register in
the 5GC before moving across. This is achieved using the Registration
procedure. Once the device has moved across to the 5G Core, the
device can use the UE Initiated PDU Session Establishment procedure
to establish the appropriate Data Network connections. This can be
achieved as part of one procedure, whereby the device sets the
“Existing PDU Sessions” flag in the PDU Session Establishment
Request. As long as the UDM/HSS has provided the AMF with the
appropriate Data Network configuration(s) within the subscriber
context, the AMF will establish the appropriate PDU Sessions.
Alternatively, the device may use individual PDU Session
Establishment Requests to individually select which data bearers will
come across to 5G and which will remain in the EPC.

5GC to EPC Mobility EPC to 5GC Mobility

- Network Attach without PDN - Registration
Connectivity Establishment - UE Requested PDU
- Selective PDN Connectivity Session Establishment
Establishment (handover indication) - Existing PDU Session flag

4G Network 5G Network
Evolved Packet Core 5G Core

UE
Dual Registration Mode
Device may pre-register before moving to the target
network
Device can choose which data bearers are brought
across and which can remain in the source network

Figure 8 Dual Registration Mode with no Support for N26

Single Registration Mode with no Support for N26

For Single Registration Mode, the device will essentially have to conduct a
Network Attach or Registration procedure with the target network, depending
on the direction of travel.
 For 5GC to EPC mobility, the device will conduct the Attach procedure
with the EPC and establish a PDN Connection. If the device had more
than one PDU Session active in the 5G network, it can use the UE
Requested PDN Connectivity Request procedure to establish the
equivalent PDN connections across the LTE network.

MPI0146-010-070 © Mpirical Limited, 2019 5

 Interworking with LTE and Wi-Fi

 For EPC to 5G mobility, the device will first conduct the Registration
procedure with the 5GC. Following this, the device can use the UE
Initiated PDU Session Establishment procedure to establish the
appropriate Data Network connections. This can be achieved as part of
one procedure, whereby the device sets the “Existing PDU Sessions”
flag in the PDU Session Establishment Request. Failing this, the device
can simply re-establish all of the PDU Sessions that it requires on an
individual basis (although IP address preservation in this case will not
occur).

5GC to EPC Mobility EPC to 5GC Mobility

- Network Attach and PDN - Registration
Connectivity Establishment - UE Requested PDU
- PDN Connectivity Session Establishment
Establishment - Existing PDU Session flag

4G Network 5G Network
Evolved Packet Core 5G Core

UE
Single Registration Mode

Figure 9 Single Registration Mode with no Support for N26

Connected Mode Mobility Procedures (with N26)

2.1 5GS to EPS Handover
Figure 10 shows the initial part of the 5GS to EPS handover process, which
begins with the gNB determining that a handover is required. As such, the
NGAP Handover Required message is sent to the AMF, identifying the Target
eNB and also providing radio related information. On receipt of this message,
the AMF will determine that a Handover to E-UTRAN is required.
Prior to contacting the MME within the LTE network, the AMF will contact the
SMF+PGW-C in order to acquire information related to the currently active
PDU sessions. The Nsmf_PDUSession_ContextRequest call is used to
facilitate this. The SMF+PGW-C will provide this Session Management
Context information, along with mapped EPS Bearer Context information.
Note that there may be several PDU Sessions in operation for the subscriber,
spread across different SMF+PGW-Cs. Therefore, each SMF+PGW-C must
be contacted and subsequently share their SM Context information.
The AMF will then select an MME within the LTE network and send the
GTPv2-C Forward Relocation Request message. This message will identify
the Target eNB, as well as catalogue all the PDU Sessions the device has
currently active (PDU Sessions and GBR QoS Flows within them will be
mapped to Default and Dedicated EPS Bearers as appropriate).

6 © Mpirical Limited, 2019 MPI0146-010-070

Interworking with LTE and Wi-Fi

UPF
S-GW PGW-U
SMF
eNB gNB AMF MME PGW-C

PDU Session(s) and QoS Flows established in the 5G System

Handover
Nsmf_PDUSession_ContextRequest
Required
Nsmf_PDUSession_ContextResponse
Forward Create
Relocation Session
Request Request
Create
Handover Request Session
Response
Handover Request Ack

Figure 10 5GS to EPS Handover with N26 (Part 1)

Figure 10 then shows the MME choosing a new S-GW (Serving Gateway) and
subsequently sending the Create Session Request message towards it. This
message will be sent for each PDN connection that must be established and
will detail the QoS profile required for the Default EPS bearer and any
associated GBR (Guaranteed Bit Rate) Dedicated EPS bearers (non GBR
Dedicated EPS Bearers will be moved at the final stages of the handover). At
this point the S-GW will allocate local resources, such as IP address and
TEID (Tunnel Endpoint Identifier) for S1-U and S5 user plane connections.
The S-GW will return the Creation Session Response message to the MME,
confirming the acceptance of the EPS bearers.
At this stage, the MME can contact the E-UTRAN, specifically the Target eNB.
The Handover Request message will define the EPS bearers that must be
established for the subscriber, as well as their respective EPS Bearer ID(s). In
response, the eNB will send the Handover Request Acknowledge message
which will confirm the EPS bearers that have and have not been established.
As part of this, successfully established EPS bearers will have a suitable eNB
and TEID allocation. The Handover Request Ack message will also contain
radio related information that is destined to the device to be used to facilitate
the handover process.

UPF
S-GW PGW-U
SMF
eNB gNB AMF MME PGW-C

Create Indirect Data

Forwarding Tunnel
Indirect Forwarding Tunnel
Relocation
Response
Nsmf_PDUSession_
UpdateSMContext Request
PFCP Session
Nsmf_PDUSession_ Modification
Handover UpdateSMContext Response
Handover Command Indirect Forwarding
Command Tunnel
Indirect Forwarding Tunnel

Figure 11 5GS to EPS Handover with N26 (Part 2)

In Figure 11, the procedure continues with the establishment of an Indirect

Forwarding Tunnel. Although optional, establishment of a forwarding tunnel

MPI0146-010-070 © Mpirical Limited, 2019 7

 Interworking with LTE and Wi-Fi

ensures that no data is lost during the handover process (in the very short
period of time in which the device has conducted the handover but the
network has yet to redirect the user plane path). Figure 12 illustrates the path
that the forwarding tunnel will eventually take, once it is established.

AMF MME

Indirect Forwarding tunnel established under

Source the control of the AMF/MME Target
UPF
PGW-U S-GW

3 UPF+PGW-U Indirect Forwarding S-GW 2

Forwarding Forwarding
Tunnel Endpoint Tunnel Endpoint

Source Target
gNB eNB

Figure 12 Indirect Forwarding Tunnel

In the initial stages of the forwarding tunnel establishment, the MME will
supply the S-GW with the eNB TEID and IP address for each EPS Bearer
subject to forwarding (labelled as 1 in Figure 12). The MME will also request
from the S-GW a suitable set of TEIDs and IP addresses that can be used by
the UPF+PGW-U as the target for forwarded data (labelled as 2 in Figure 12).
This information is supplied back to the MME and at this stage, one leg of the
forwarding tunnel is established (S-GW to eNB).
The procedure continues with the Relocation Response being sent from the
MME to the AMF. This message will confirm exactly which EPS bearers have
been successfully established and for those bearers subject to data
forwarding, the S-GW TEIDs and IP addresses required by the UPF+PGW-U.
The message will also contain information destined to the device, initially
supplied by the eNB in relation to the handover.
At this stage, the AMF will pass the S-GW TEID and IP addressing
information to the SMF+PGW-C, which in turn will pass the same information
to the UPF+PGW-U, utilizing the PFCP (Packet Forwarding Control Protocol)
Session Modification procedure. As such, the next leg of the forwarding tunnel
is established (UPF+PGW-U to S-GW). The UPF-PGW-U will also return the
appropriate TEID and IP addressing information which will be supplied to the
gNB, in order to complete the final leg of the indirect forwarding tunnel
(labelled as 3 in Figure 12).
This forwarding tunnel information will be sent by the AMF in the Handover
Command to the gNB, triggering the handover process. Critical information
included in this message will also be the handover related information initially
supplied by the eNB (essentially a series of LTE radio related parameters).
This information is relayed to the device as part of the RRC (Radio Resource
Control) Handover Command message, which instructs the device to
handover to 4G.

8 © Mpirical Limited, 2019 MPI0146-010-070

Interworking with LTE and Wi-Fi

UPF
S-GW PGW-U
SMF
eNB gNB AMF MME PGW-C

Downlink Data Forwarding Path

Handover
Handover Notify
Complete
Uplink Data

Relocation Complete Modify

Modify
Bearer
Bearer
Request Sx Session
Request
Modify Modification
Modify
Bearer Bearer
Response Response
Downlink Data
P-GW initiated Dedicated EPS Bearer establishment (as necessary)

Figure 13 5GS to EPS Handover with N26 (Part 3)

With reference to Figure 13, when the device arrives at the LTE eNB, it will
generate the Handover Complete message. At this stage, the uplink data path
is now complete. In turn, the Handover Notify message is sent by the eNB to
the MME, informing the MME that the device is now under the control of the
eNB. This triggers the MME into sending the Forward Relocation Complete
message back to the AMF.
All that remains is for the downlink user plane data path to be adjusted
accordingly. Namely, the UPF+PGW-U must begin sending all appropriate
downlink data to the S-GW, which must then send that data on to the eNB. To
achieve this, the Modify Bearer Request message is first sent to the S-GW to
supply the IP Address and TEID(s) of the eNB. The second Modify Bearer
Request is sent to the SMF+PGW-C in order to supply the S-GW TEID(s) and
IP address. Finally, an Sx Session Modification procedure will take place,
which will be based on the use of PFCP (Packet Forwarding Control Plane
Protocol) between the SMF+PGW-C and the UPF+PGW-U. In response, the
Modify Bearer Response will be sent to confirm successful bearer
modification.
Where appropriate, any Indirect Data Forwarding that is taking place will now
cease. The tunnels associated with this process will be torn down as
necessary (not shown in Figure 13).
Finally, if additional Non-GBR dedicated bearers are required for the
subscriber, the PGW-U may trigger the establishment of these bearers.

2.2 EPS to 5GS Handover

The handover process from EPS to 5GS will follow similar concepts to the
5GS to EPS handover. The general concept is that before the handover takes
place, the target network will establish the appropriate resources, with EPS
bearers mapped to PDU Session/QoS Flows as necessary. The process itself
is broken down into two phases; the Preparation Phase and the Execution
Phase.
Handover Preparation
The first part of the Handover Preparation process is outlined in Figure 14,
which starts with the Source eNB detecting that an Inter RAT handover is
required. Specifically, the eNB will supply the Target gNB ID to the MME as
part of the Handover Required message.

MPI0146-010-070 © Mpirical Limited, 2019 9

 Interworking with LTE and Wi-Fi

On receipt of the Handover Required message the MME will choose a

suitable AMF. In the Forward Relocation Request message which follows, the
MME will identify the Target gNB and provide details on the EPS bearers
which must be supported on 5G (including their Access Point Name, QoS
profile, SMF+PGW-C address and UPF+PGW-U uplink tunnel endpoint
information). Additional information supplied to the AMF includes the
subscriber’s IMSI, IMEI, UE Security Context and UE Network Capability
information (all part of the UE’s general Mobility Management context).
The AMF will then invoke the Nsmf_PDUSession_UpdateSMContext
operation which will identify the relevant PDU connection(s) subject to
handover. At this stage, the SMF+PGW-C may instigate a policy check with
the PCF (Policy Control Function), ensuring that the requested bearer
resources are acceptable. If any modification to the bearers is required, the
SMF+PGW-C will conduct a session modification procedure with the
UPF+PGW-U (ensuring that the new PDU Sessions are mapped appropriately
to the EPS Bearers on LTE).
The SMF+PGW-C will respond to the AMF with the
Nsmf_PDUSession_UpdateSMContext Response, outlining which EPS
bearers have been accepted as PDU Sessions or QoS Flows. Where
necessary, the SMF+PGW-C will also provide the new QoS rules to the PCF,
along with tunnel information related to the UPF+PFW-U (this tunnel
information is required by the gNB to create the Uplink user plane).
The AMF will now contact the 5G RAN, sending the Handover Request
message to the Target gNB. This message will contain information on the
required PDU Sessions and QoS Flows, including their allocated QoS and
associated UPF+PGW-U tunnel endpoint information.
In the Handover Request Acknowledgement response, the gNB will determine
which QoS flows have been accepted and supply to the AMF the appropriate
IP addressing and TEID(s) for the downlink user plane direction (required by
the UPF+PGW-U for downlink N3 traffic). If indirect forwarding is in operation
(termed PDU Forwarding), at this stage the gNB will also supply tunnel
endpoint information for any traffic which is subject to forwarding (to be used
by the UPF+PGW-U in the downlink direction). The gNB will also supply
handover related information which will eventually be supplied to the device.

UPF
S-GW PGW-U
SMF
eNB gNB MME AMF PGW-C

Default and Dedicated EPS Bearers established within the EPS

Handover Required Forward
Nsmf_PDUSession_Update
Relocation SMContext Request
Request
PFCP Session
Nsmf_PDUSession_
Modification
UpdateSMContext
Handover Request
Response
Handover
Request Ack

Figure 14 EPS to 5GS Handover Preparation with N26 (Part 1)

Figure 15 shows the procedure continuing with the Modify PDU Session
request message being sent between the AMF and the SMF+PGW-C. This
message will essentially update the N3 tunnel information stored at the
UPF+PGW-U with all the tunnel information supplied by the gNB in the
Handover Request Ack message. This includes tunnel information for the

10 © Mpirical Limited, 2019 MPI0146-010-070

Interworking with LTE and Wi-Fi

Figure 24 Registration via Untrusted non-3GPP Access – Part 1

The procedure begins with establishment of a Security Association between

the device and the N3IWF which is designed to protect future IKE (Internet
Key Exchange) signalling. This is important because it is IKE signalling that
will be used to support the EAP-AKA (Extensible Authentication Protocol –
Authentication and Key Agreement) process. EAP-AKA is the mechanism by
which the device is authenticated when a non-3GPP access network is used.
As part of the regular registration procedure, the device will send to the AMF
the NAS Registration Request, via the N3IWF. Note that messages
exchanged between the device and the N3IWF are carried within IKE AUTH
Request or Response messages, including EAP (which in turn carry NAS).
In turn, the AMF will acquire an Authentication Vector from the AUSF. During
this process, the AMF will report that the device is on non-3GPP access,
causing the UDM to select EAP-AKA as the authentication mechanism. As
such, the AMF is supplied with the Authentication Vector that it requires and
subsequently begins the EAP-AKA process. Fundamentally, this process is
similar to 5G-AKA in that largely the same security information is used eg
RAND, AUTN, XRES, CK, IK etc. However, EAP is used as the mechanism by
which this information is relayed to the device (EAP is carried in IKE
messages as part of this).

Figure 25 Registration via Untrusted non-3GPP Access – Part 2

Once the EAP-AKA procedure is complete and the device is authenticated,

the remainder of the registration procedure can take place. This includes
activation of NAS signalling security using the Security Mode Command

MPI0146-010-070 © Mpirical Limited, 2019 17

 Interworking with LTE and Wi-Fi

Handover Execution
Figure 17 shows the EPS based data path which exists before the handover
takes place. During the Execution phase, PDU Forwarding may have been
established, which will ensure that any data forwarded to the eNB in the short
space of time that occurs between the handover and the user plane path
redirection will not be lost.
The Handover Execution phase begins with the MME sending the Handover
Command to the eNB, providing the eNB with the PDU Forwarding address of
the S-GW. In addition, handover related information which was originally
supplied by the gNB is finally handed to the eNB. As such, the eNB is able to
send the Handover Command message to the device, allowing the device to
conduct the handover process.
As instructed, the device will enter the 5G RAN, confirming with the gNB that
it is now in control of the device. At this point, PDU Forwarding is now in
operation, whereby the eNB will send downlink data back to the S-GW, which
in turn will forward this data to the 5GS, specifically the UPF+PGW-U. In turn,
the UPF+PGW-C will forward the data to the gNB for onward delivery to the
device.
At this stage, the gNB will send the Handover Notify message to the AMF,
informing the AMF that this device is now under its control.

UPF
S-GW PGW-U
SMF
eNB gNB MME AMF PGW-C

Uplink Data and Downlink Data

Handover Command
Handover
Command
Handover to 5G
RAN Confirm
Downlink Data Forwarding Path
Handover Notify

Figure 17 EPS to 5GS Handover Execution with N26 (Part 1)

In part 2 of the Handover Execution procedure (Figure 18), the AMF will
inform the MME that the handover has successfully taken place. This is
achieved with the Forward Relocation Complete Notification, which the MME
will acknowledge. In addition, the AMF will also send the Handover Complete
message to the SMF+PGW-C, indicating that the handover has successfully
taken place. If necessary, additional tunnel information relative to the 5G RAN
may be provided at this stage and supplied to the UPF+PGW-U as part of the
PFCP Session Modification procedure.
Any PDU forwarding that was taking place will now cease as the UPF+PGW-
U begins sending downlink data directly to the 5G RAN.
The handover execution concludes with the device conducting a 5G
Registration Update procedure, with a cause set to Mobility. Any resources in
the EPS, including PDU Forwarding, will now be torn down as appropriate.

12 © Mpirical Limited, 2019 MPI0146-010-070

Interworking with LTE and Wi-Fi

UPF
S-GW PGW-U
SMF
eNB gNB MME AMF PGW-C

Forward Relocation
Complete Notification
Nsmf_PDUSession_
UpdateSMContext Request
PFCP Session
Nsmf_PDUSession_ Modification
UpdateSMContext
Response
Uplink Data and Downlink PDUs

5GS Mobility Registration Update Procedure

Release Resources in LTE, including PDU Forwarding

Figure 18 EPS to 5GS Handover Execution with N26 (Part 2)

Fallback Mechanisms
Fallback is an example of a specific interworking scenario which sees the
device ultimately leaving the 5G network and moving to an alternate access
network (and potentially core network). For 5G, two fallback mechanisms
exist, which are outlined in Figure 19. Both cases are designed to support
voice scenarios in which the device requires access to the IMS voice service
(in LTE, the IMS voice service is VoLTE). In each case, the device is initially
connected to the 5G Core via 5G New Radio.

RAT Fallback Device is directed/redirected to E-UTRA connected to 5GC

EPS Fallback Device is directed/redirected to E-UTRAN connected to EPC

Figure 19 Fallback Mechanisms

For these fallback scenarios to be viable, the device must be aware that IMS
based voice services are available. As such, support for “IMS Voice over PS
Session” is advertised to the device during registration, which in turn can
trigger IMS registration. Note that in Figure 20, the AMF also updates the
device as to the availability of N26.

NAS Registration Accept AMF

IMS Voice over PS Session available

UE N26 Supported / Not Supported

Figure 20 Advertising Support for Fallback

Figure 21 illustrates the decision making process that the NG-RAN will go
through to determine whether fallback procedures should occur. In essence,
upon receipt of a request to establish a QoS Flow for IMS voice, the gNB will
factor in conditions such as UE capabilities, N26 availability (see Figure 2),
network configuration and radio conditions. Based on these factors, one of the
following mechanisms will then be triggered:

MPI0146-010-070 © Mpirical Limited, 2019 13

 Interworking with LTE and Wi-Fi

 Redirect the device to the EPS.

 Handover to the EPS (if N26 is available).
 Redirection to E-UTRA connected to 5GC.
 Handover to E-UTRA connected to 5GC.
5 gNB will:
- Redirect to EPS AMF signals gNB to AMF
- Handover to EPS (N26 rqd.) initiate establishment
- Redirection to E-UTRAN connected to 5GC of a QoS Flow for
- Handover to E-UTRA connected to 5GC IMS voice 2

4 Reject PDU Session

5 Modification due to
fallback initiation

UE
1 Device registered in
IMS initiates/receives gNB 3 gNB determines that fallback
an MO/MT call to EPS is required

Figure 21 Fallback Procedure

In Step 1 of Figure 21, the device has registered in the IMS after being made
aware that IMS Voice over PS Session is supported. After this point, if a MO
or MT call is initiated, a network triggered PDU Session modification is
generated by the 5GC and sent to the gNB (Step 2). Based on configuration,
the gNB will decide that fallback is required (Step 3) and will determine which
fallback mechanism is suitable. The gNB will reject the PDU Session
Modification due to fallback being triggered (Step 4). In addition, the gNB will
trigger the appropriate fallback mechanism with the device (Step 5).

Interworking with Non-3GPP Networks

4.1 Architecture for Non-3GPP Accesses
The 5G core network supports connectivity to the device via non-3GPP
access networks, with Wi-Fi being the prevalent technology choice. The focus
for 5G is to initially support untrusted non-3GPP access. Figure 22 illustrates
the architecture required for non-3GPP access and introduces the N3IWF
(Non-3GPP Inter Working Function) which performs a similar role to the
ePDG (Evolved Packet Data Gateway) in an LTE network. In addition, the
N3IWF selection process also follows the ePDG guidelines.
It is worth noting that when a device is connected via both 5G-RAN and non-
3GPP, multiple N1 instances will exist. Both N1 instances use the same AMF,
assuming the selected N3IWF is in the same PLMN (Public Land Mobile
Network). If the selected N3IWF is in a different PLMN, then multiple AMF’s
would need to be used.

14 © Mpirical Limited, 2019 MPI0146-010-070

Interworking with LTE and Wi-Fi

Data
UPF Network
N6

N3
N4
SMF
N3IWF
3
B/N
N1
1 DR Y2
AMF
u
NW
N2

N1
Y1 Untrusted
Non-3GPP
Access

Figure 22 Non-3GPP Access to 5GC

The additional non-3GPP reference points include:

 Y1 reference point - exists between the UE and the non-3GPP access.
 Y2 reference point - exists between the untrusted non-3GPP access
and the N3IWF for the transport of NWu traffic.
 NWu reference point - exists between the UE and N3IWF for
establishing secure tunnel(s). This enables control plane and user
plane to be securely exchanged between the UE and the 5G core
network, via the N3IWF.

4.2 Non-3GPP Access Registration

It is possible for 5G devices to be registered to the 5G System via 3GPP and
non-3GPP access simultaneously. As such, the network will hold an individual
RM (Registration Management) Context for each access network type and the
UDM will manage separate UE registration procedures for each access
network. At the AMF, RM Context specific information is stored following
successful registration. Figure 23 outlines a selection of key points associated
with simultaneous 3GPP and non-3GPP registration states held at the AMF.

5G-GUTI common to both

access types

3GPP 5G Access Network Registration state per access

type
N1
AMF
Separate 3GPP and non-
3GPP Registration Areas

UE N1
Periodic Registration Timer
Wi-Fi Based Non-3GPP Access for 3GPP Access
Network

Non-3GPP Implicit
Deregistration Timer

Figure 23 RM Context Information Stored at the AMF

 5G-GUTI common to both access types – the 5G-GUTI can be
assigned over 3GPP or non-3GPP access during that access network’s
respective registration process. Once the device has conducted a

MPI0146-010-070 © Mpirical Limited, 2019 15

 Interworking with LTE and Wi-Fi

registration procedure on for example the 5G access network, it will

use the 5G-GUTI assigned during this process when it then attempts
registration via non-3GPP access. Due to this fact, the network can
ensure the same AMF is allocated to the subscriber. Note that the
same principle applies if the first registration was via non-3GPP
access; in this case, the 5G-GUTI assigned would then be used when
the device conducts a registration over 3GPP access.
 Registration state per access type – the AMF will hold an RM state for
each access type. Once RM Registered, the device can then transition
between CM Idle and CM Connected as and when N1 connections are
established or released. Like Registration Management, these
Connection Management states are independent of one another.
 Separate 3GPP and non-3GPP Registration Areas – although the 5G
access network is comprised of a series of Tracking Areas (which may
be grouped in a Tracking Area Identity List), all non-3GPP access
networks share the same unique Tracking Area Identity, termed the
N3GPP TAI (Tracking Area Identity).
 Periodic Registration Timer for 3GPP Access – this requires the device
to conduct a Registration Update before the timer expires, otherwise
the device will be implicitly detached from the network.
 Network non-3GPP Implicit Deregistration Timer – devices on Wi-Fi will
not be required to conduct Registration Updates on the basis of a timer.
Instead, the network will provide an Implicit Deregistration Timer which
will start when the device enters a CM Idle state. Should the timer
expire, the device will be implicitly detached from non-3GPP access
and will enter the RM Deregistered state.
Note that in order to hold a separate registration state for non-3GPP access,
the device will need to exchange NAS signalling with the AMF. Whilst
registering on non-3GPP access, this is achieved by utilizing EAP-5G, which
is a mechanism by which NAS can be carried in EAP messages (which in turn
are encapsulated within IPSec). Once registration is complete, a separate
IPSec security association is established for NAS signalling exchange.
Registration via Untrusted non-3GPP Access
The procedure associated with network registration via Untrusted non-3GPP
Access in outlined in Figure 24. In order to communicate with the 5G Core
Network, the device must first establish an IPSec SA (Security Association)
between itself and the N3IWF. It is during the establishment of this Security
Association that the device will be authenticated and also registered with the
network. Fundamentally, the procedure is based on a regular registration
procedure, with largely the same message set involved. However, the
authentication mechanism differs due to the involvement of IPSec SA
(Security Association) establishment.

16 © Mpirical Limited, 2019 MPI0146-010-070

Interworking with LTE and Wi-Fi

N3IWF AMF
AUSF UDM

IKE SA Establishment
IKE AUTH Messages
NAS Registration Request
NAS Identity Request
NAS Identity Response Nausf_UEAuthentication
_authenticate POST Nudm_UE
Authentication_GET

UDM selects EAP

AKA due to non-
3GPP Access
201 Created
200 OK
(Nausf_UEAuthentication
(Nudm_UE
_authenticate)
Authentication_Get)

Figure 24 Registration via Untrusted non-3GPP Access – Part 1

The procedure begins with establishment of a Security Association between

the device and the N3IWF which is designed to protect future IKE (Internet
Key Exchange) signalling. This is important because it is IKE signalling that
will be used to support the EAP-AKA (Extensible Authentication Protocol –
Authentication and Key Agreement) process. EAP-AKA is the mechanism by
which the device is authenticated when a non-3GPP access network is used.
As part of the regular registration procedure, the device will send to the AMF
the NAS Registration Request, via the N3IWF. Note that messages
exchanged between the device and the N3IWF are carried within IKE AUTH
Request or Response messages, including EAP (which in turn carry NAS).
In turn, the AMF will acquire an Authentication Vector from the AUSF. During
this process, the AMF will report that the device is on non-3GPP access,
causing the UDM to select EAP-AKA as the authentication mechanism. As
such, the AMF is supplied with the Authentication Vector that it requires and
subsequently begins the EAP-AKA process. Fundamentally, this process is
similar to 5G-AKA in that largely the same security information is used eg
RAND, AUTN, XRES, CK, IK etc. However, EAP is used as the mechanism by
which this information is relayed to the device (EAP is carried in IKE
messages as part of this).

N3IWF AMF
AUSF UDM

IKE SA Establishment
IKE AUTH Messages

EAP AKA Based Authentication

Activate NAS signalling security

Signalling IPSec SA established

Remainder of Registration Procedure

Figure 25 Registration via Untrusted non-3GPP Access – Part 2

Once the EAP-AKA procedure is complete and the device is authenticated,

the remainder of the registration procedure can take place. This includes
activation of NAS signalling security using the Security Mode Command

MPI0146-010-070 © Mpirical Limited, 2019 17

 Interworking with LTE and Wi-Fi

message, in addition to the establishment of an IPSec Security Association

specifically designed to carry NAS signalling (EAP-5G is only used up to the
NAS Security Mode Command). This signalling IPSec SA will carry all future
NAS messages and from here, PDU Sessions can be established as and
when necessary.

4.3 Establishing PDU Sessions

Once registered over untrusted non-3GPP access, the device can begin to
establish PDU Sessions as required. Figure 26 outlines the first part of the
PDU Session establishment process, which begins with the device sending
the NAS PDU Session Establishment Request to the AMF (via the IPSec
tunnel to the N3IWF). Notice that the core network elements of the procedure
are largely identical to the PDU Session Establishment procedure for 5G
based access.

UPF
N3IWF AMF SMF PCF

IPSec SA for NAS

NGAP Initial UE
PDU Session
Message
Establishment
PDU Session
Request
Establishment
Request
SMF Selection
Nsmf_PDUSession_CreateSM
Context Request
PDU Session Establishment Request
Retrieve SM related
subscription data from UDM

Figure 26 Establishing PDU Sessions over Untrusted non-3GPP Access (Part 1)

Following receipt of the PDU Session Establishment Request, the AMF will
choose an appropriate SMF. The AMF will then send a request to establish an
SM Context, which triggers the SMF into acquiring the subscriber’s data from
the UDM (if it does not have it already). Once the subscriber profile is
acquired and assuming the PDU Session request is accepted, the SMF will
allocate an appropriate IP address to the device.
In Figure 27, the procedure continues with the SMF interacting with the PCF
in order to acquire PCC (Policy and Charging Control) rules. At this stage, the
SMF can then choose an appropriate UPF and establish the user plane
session, including acquiring the appropriate TEID and IP addressing which
will be used by the N3IWF on the N3 (for uplink data). This information is
passed to the AMF, along with the PDU Session Establishment Accept (which
also contains the IP address assigned to the device). In turn, the AMF passes
the uplink tunnel information to the N3IWF, also requesting tunnel resources
for the downlink direction (to be used by the UPF). This information is carried
in the NGAP PDU Session Resource Setup Request, along with the NAS
PDU Session Establishment Accept.

18 © Mpirical Limited, 2019 MPI0146-010-070

Interworking with LTE and Wi-Fi

UPF
N3IWF AMF SMF PCF

PDU-CAN Session
Establishment
UPF Selection
PFCP Session
Establishment

Request /
NGAP PDU
Response
Session
Nsmf_PDUSession_CreateSM
Resource Setup
Context Response
Request
PDU Session PDU Session Establishment Accept
Establishment
Accept

Figure 27 Establishing PDU Sessions over Untrusted non-3GPP Access (Part 2)

It is possible that multiple QoS Flows are being established for this PDU
Session and as such, the N3IWF must now determine how many Child
Security Associations are required. Depending on the configuration of the
N3IWF, it is possible that all QoS Flows will utilize the same IPSec Security
Association. Alternatively, an individual Child SA may be established for each
QoS Flow. This concept is illustrated in Figure 28.
To establish each Child SA, the N3IWF and the device will use an IKE
(Internet Key Exchange) signalling exchange. This begins with the N3IWF
sending the IKE_Create_Child_SA Request message, which will define the
parameters of the Security Association such as traffic selectors, SPI (Security
Parameters Index) and mode of operation (in this case, the mode of operation
will be Transport Mode). In addition, the request will also provide a PDU
Session ID, as well as the QoS profile for the Child SA. It is also possible to
send a DSCP (Differentiated Service Code Point) allocation to support QoS in
the IP transport network (and possibly at the Wi-Fi Data Link layer).
In response, the device will return the IKE_Create_Child_SA Response, which
confirms the establishment of the Child SA. The N3IWF will now have a
mapping between the PDU or QoS Flow active on N3 against the appropriate
Child SA.
Once all required Child SAs are established, the N3IWF will forward the PDU
Session Establishment Accept message to the device, utilizing the NAS
Security Association. This will confirm establishment of the PDU Session and
supply the device with its designated IP address. The N3IWF will also make
one or more tunnel endpoint assignments for the N3 user plane. These will be
sent to the AMF as part of the NGAP PDU Session Resource Setup
Response.

MPI0146-010-070 © Mpirical Limited, 2019 19

 Interworking with LTE and Wi-Fi

UPF
N3IWF AMF SMF PCF

Determine number
of Child SAs
Create_Child_SA
Request
Create_Child_SA
Response
Additional Child SA
Establishment
PDU Session NGAP PDU
Establishment Session
Accept Resource Setup
Response

Figure 28 Establishing PDU Sessions over Untrusted non-3GPP Access (Part 3)

Figure 29 shows the final stages of the procedure, which initially shows the
AMF providing the SMF with the N3IWF tunnel information for downlink data.
The Nsmf_PDUSession_UpdateSMContext Request will then carry this
information to the SMF, which in turn will use an PFCP Session Modification
Request to update the UPF with the tunnel endpoint information.

UPF
N3IWF AMF SMF PCF

Nsmf_PDUSession_UpdateSM
Context Request
N4 Session
Modification
Request/
Response
Nsmf_PDUSession_UpdateSM
Context Response

Figure 29 Establishing PDU Sessions over Untrusted non-3GPP Access (Part 4)

Data Forwarding
Figure 30 shows how data is forwarded when the device is using Untrusted
non-3GPP access. Across the Child SA, user plane data is encapsulated
within a GRE (Generic Route Encapsulation) packet. The header of the GRE
packet will contain the QoS profile specific to the downlink or uplink PDU.
Between the N3IWF and the UPF, data is transferred as regular N3 traffic
using GTPv1-U (GPRS Tunnelling Protocol version 1 – User plane).

Generic Route Encapsulation

User plane data is encapsulated in GRE,
with the GRE header carrying QoS profile
information UPF
N3IWF

UE Child SA GTPv1-U Tunnel

Figure 30 Data Forwarding over Untrusted non-3GPP Access

20 © Mpirical Limited, 2019 MPI0146-010-070

Interworking with LTE and Wi-Fi

4.4 Modifying a PDU Session

PDU Session Modification takes place to either alter the current parameters of
the PDU Session or alternatively, add or remove QoS Flows within the
session. Figure 31 outlines the high level process, which from the perspective
of the 5GC is identical to a PDU Session Modification when the device is on
5G access.

UPF
N3IWF AMF SMF PCF

PDU-CAN Session
NGAP PDU Modification
Session
PDU Session Resource Namf_Communication_N1N2Message
Transfer
Modification Modify Request
Command PDU Session Modification Command
PDU Session
Modification
Create or Delete Command
Child SA

Session Modification within the 5GC

Figure 31 Modifying a PDU Session

As can be seen in Figure 31, on receipt of the NGAP PDU Session Resource
Modify Request message, the N3IWF will need to engage with the device.
First of all, the N3IWF relays the PDU Session Modification Command, which
will detail to the device the nature of the session modification. In turn and as
appropriate (depending on the nature of the modification), IKE can be used to
add or delete a Child SA.

4.5 Utilizing PDU Sessions

Devices which have registered via non-3GPP access and then subsequently
established PDU Sessions can use these sessions for data transfer. As with
5G based access to the 5G Core, the device will be required to use the
Service Request procedure to transition from a CM Idle to a CM Connected
state when data transfer is required. From a signalling perspective, the
process is similar to the 5G UE triggered Service Request and the outcome is
the same, in that an NGAP signalling connection will be re-established
(between the N3IWF and the AMF) and N3 User Plane connections will be re-
established. There are however two main differences:
 Paging – for non-3GPP based access, paging is not possible. All
Service Request procedures are UE triggered.
 PDU Sessions – the device cannot be selective over which PDU
Sessions are activated; all previously established PDU sessions will be
reactivated during the Service Request procedure.

MPI0146-010-070 © Mpirical Limited, 2019 21

 Interworking with LTE and Wi-Fi

Service Request
- always UE triggered
- all previously established PDU sessions will be activated

AMF
Wi-Fi Based Non-3GPP Access
Network
UE

Figure 32 Utilizing PDU Sessions

4.6 5G WLAN Aggregation

LWA (LTE WLAN Aggregation) was introduced in Release 13 of the 3GPP
specifications as a means by which the 4G network can be augmented
through direct interoperation with Wi-Fi based access points or access
controllers. This means that the device is utilizing both the LTE network and
Wi-Fi network simultaneously in order to improve data rate and overall QoS.
In essence, LWA is based on the Dual Connectivity model introduced in
Release 12 of the 3GPP specifications. The Wi-Fi access point will essentially
operate as the secondary RAN node, with interconnectivity to the master
based on the Xw reference point. This is outlined in Figure 33.

Evolved Packet
Core
LTE WLAN
Aggregation
eNB
(Master)

WLAN AP
(Secondary)

UE

Figure 33 LTE WLAN Aggregation

Utilization of the Dual Connectivity approach means that the eNB can split the
traffic on the basis of an individual IP flow. This is an important concept
because it will allow the eNB to change the flow according to current radio
channel conditions, hence optimizing data rate and improving QoS. Figure 34
applies the WLAN Aggregation concept to 5G.

5G Core
5G WLAN
Aggregation
gNB
(Master)

WLAN AP
(Secondary)

UE

Figure 34 5G WLAN Aggregation

22 © Mpirical Limited, 2019 MPI0146-010-070

Interworking with LTE and Wi-Fi

Although yet to be standardized, it is anticipated that WLAN Aggregation will

form a key part of the service provider’s 5G RAN infrastructure. Figure 35
outlines how the presence of WLAN aggregation can potentially augment the
overall data rate a 5G device can receive.
Secondary WLAN nodes
providing localized boosts
Macro
Access Master RAN
Controller node providing
macro coverage

Data
Rate

Add Secondary Node Remove Master Node

secondary Change secondary Handover
Mobility

Figure 35 Coverage Augmentation Utilizing WLAN Aggregation

MPI0146-010-070 © Mpirical Limited, 2019 23

 Interworking with LTE and Wi-Fi

24 © Mpirical Limited, 2019 MPI0146-010-070

Interworking with LTE and Wi-Fi
5G NAS (Non Access Stratum)
AMF (Access and Mobility Management
Function)
EAP-AKA (Extensible Authentication
Protocol – Authentication and Key
Agreement)
EPC (Evolved Packet Core)
ePDG (Evolved Packet Data Gateway)
GBR (Guaranteed Bit Rate)
GRE (Generic Route Encapsulation)
GTPv1-U (GPRS Tunnelling Protocol
version 1 – User plane)
GUTI (Globally Unique Temporary
Identity)
HSS/UDM (Home Subscriber Server/User
Data Management)
MPI0146-010-070 © Mpirical Limited, 2019
Glossary
N3IWF (Non-3GPP Inter Working
Function)
PCC (Policy and Charging Control)
PFCP (Packet Forwarding Control Plane
Protocol)
PGW-C (PDN Gateway – Control Plane)
PGW-U (PDN Gateway – User Plane)
PLMN (Public Land Mobile Network)
RRC (Radio Resource Control)
SA (Security Association)
S-GW (Serving Gateway)
SMF/PGW-C (Session Management
Function/PDN Gateway – Control)
TAI (Tracking Area Identity)
TEID (Tunnel Endpoint Identifier)
UPF/PGW-U (User Plane Function/PDN
GW – User plane)
25
 Interworking with LTE and Wi-Fi

26 © Mpirical Limited, 2019 MPI0146-010-070

Innovating Telecoms Training

Contact Us
Tel: +44 (0) 1524 844669
Email: enquiries@mpirical.com

www.mpirical.com