Session Continuity

Session management

Stefan Rommer , ... Catherine Mulligan , in 5G Core Networks, 2020

6.4.2.4 SSC mode 3

SSC mode 3 is similar to SSC mode 2 in the sense that it allows the PSA UPF to change, but with SSC mode 3 the network ensures that the UE suffers no loss of connectivity during the time that the PSA UPF change takes place. SSC mode 3 can therefore be described as "make-before-break". SSC mode 3 can be supported in two ways:

-

Multiple PDU Sessions: In this case the SMF instructs the UE to request establishment of a new PDU Session to the same DN before the old PDU Session is released. This means that the User Plane connectivity via a new PDU Session Anchor is available to the UE for a while before the old PDU Session and its User Plane connection is released.

-

IPv6 multi-homing: In this case a single PDU Session (of PDU Session type IPv6) is used and a new UPF PSA (with a new IPv6 prefix) is allocated in that PDU Session, before the old PSA UPF (and old IPv6 prefix) is released. In the same way as when multiple PDU Sessions are used, the new PDU Session Anchor can be used for a while before the old PDU Session Anchor is released.

In both cases above, the IP address/prefix is not preserved. The new PDU Session Anchor will be associated with a different UE IP address/prefix than the old PDU Session Anchor. This SSC mode is thus suitable for applications that need continuous User Plane connectivity but can handle IP address/prefix changes. SSC mode 3 only applies to IP-based PDU Session types.

Fig. 6.7 illustrates the principles of the different SSC modes.

Fig. 6.7

Fig. 6.7. Principles of the SSC modes.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780081030097000065

EPS Deployment Scenarios and Operator Cases

Magnus Olsson , ... Catherine Mulligan , in EPC and 4G Packet Networks (Second Edition), 2013

3.1.2.1 Inter-System Mobility

The next step to improve the service offering is to provide "session continuity", which ensures that end-user IP sessions established over any access networks will survive movements to and from LTE. This is done by interconnecting the Packet Core network used to serve GSM and WCDMA with the EPC network used to serve LTE. This allows LTE-capable devices to move in and out of LTE coverage while retaining the IP session and corresponding IP address. This support is provided without affecting the end-user services of non-LTE-capable devices, which at this point is quite likely still used by the vast majority of subscribers.

Session continuity is realized by retaining a stable "IP anchor point" in the network, which means it is not necessary to change the IP address of the device at all irrespective of any moves between radio access networks. In theory, applications and services will not be dependent on the access network that is in use or on any possible movements between them. This is, of course, only partly true. Some services may rely on very high data speeds or very low network delay, criteria that may not possibly be met for all of the networks due to limited radio coverage or by limitations in the access technologies themselves. Remember that the wireless data performance and capabilities offered by LTE may be superior to HSPA, which in turn is vastly superior to GPRS, the IP connectivity service offered on GSM networks.

In practice, inter-system mobility is added to the deployed network by interconnecting the SGSNs serving GSM and WCDMA with the MME and the PGW in the EPC part of the network (see Figure 3.4).

Figure 3.4. Interconnecting EPC and the Packet Core Network for GSM/WCDMA.

In this step, the existing SGSNs and GGSNs keep serving non-LTE users as before, but the SGSNs are also utilized by LTE devices when they are out of LTE coverage. As described in Chapter 2, there are two methods of interconnecting the legacy SGSN with the EPC network. In this phase of network deployment, we assume the Gn interface is used in order to minimize the impact on the legacy network.

This solution assumes that there is no change in the way GSM and WCDMA radio networks attach to the SGSNs, but in parallel with the GGSNs serving GSM/GPRS and WCDMA/HSPA services, the new PGWs incorporate GGSN functions and are connected to the SGSNs over the Gn interface. For control signaling, the MMEs connect to the SGSN as well.

This means that the MMEs and the PDN GWs act towards the SGSN as SGSNs and GGSNs respectively. In this case the EPC system (MMEs and PGWs) adapts to the GSM/WCDMA Packet Core system, which is not affected.

In order to support session continuity, the SGSNs in the network must be able to distinguish between a terminal that attaches over GSM/GPRS or WCDMA/HSPA but is not capable of moving to LTE, from a terminal that in fact can connect to LTE but is currently attaching to GSM/GPRS or WCDMA/HSPA due to lack of LTE radio coverage. In order to achieve session continuity, the latter terminal must always be using a PDN GW as the anchor point and never a GGSN, since there is no logical connection between the LTE radio network and a GGSN. If an incorrect choice of IP anchor point were to be made by the SGSN, IP sessions would be dropped when changing access network to LTE.

Consider the example in Figure 3.5; terminal A has GSM/WCDMA support but is not capable of utilizing LTE access, while terminal B can use all three radio access networks. The simplest case is when terminal B attaches to the LTE radio network. It is then served by the MME, which will select a PDN GW and Serving GW (shown in the figure as a combined PGW/SGW node).

Figure 3.5. SGSN Selection of Gateways.

When either of the terminals attach over GSM or WCDMA radio it is served by an SGSN. For terminal B this may happen when there is no LTE coverage, while terminal A does not have LTE support so an SGSN is always serving this terminal.

There are various ways to make sure the SGSNs select the correct GW nodes (GGSN or PGWs). Note that the existing subscriber base, which so far has been served by GGSNs, can equally well be served by PGWs – the functionality for these users is identical in practice. A PGW can serve users over all access technologies.

The simplest way to provide session continuity for LTE users is hence to either make sure that all GGSNs in the network are upgraded to also support PGW functionality, or to replace the GGSNs with new PGW nodes. Either of these options makes the selection by the SGSN irrelevant – it will always select a correct IP anchor point since they are all PGWs. It should be noted that any upgrade of GGSNs to PDN GWs (including GGSN functionality) may affect charging and policy control systems, which may need to be updated to support Release 8 functionality.

If this method is not possible, another option is to make the SGSN distinguish between GGSNs that are still deployed in the network to serve terminals with GSM/WCDMA capabilities and the PGWs that can serve users over any access.

The SGSN may use different ways of achieving this. The most obvious way is to utilize the "APN" (Access Point Name), which is a part of the configuration data related to a user's subscription, and ensure it is pointing at the preferred external network. Since only terminals that include LTE radio access support (terminal B in the example) may ever move and attach to an LTE RAN, the simplest solution is to make sure that only these subscriptions are configured with an APN that is associated with a PDN GW. This helps the SGSN in taking a correct decision and ensuring that terminal B is using the PDN GW and not the GGSN as the IP anchor point. This solution is completely transparent to the SGSNs; in fact the SGSNs act as if selecting between two GGSNs with different APNs, it does, however, affect the configuration of the operator's DNS system.

Another solution is to base the selection on knowledge about the terminal capabilities. This is information signaled from the terminal to the SGSN during network attachment, and can be used by the SGSN to select GGSNs for all non-LTE-capable terminals (terminal A in the example) and PDN GWs to all LTE-capable terminals (terminal B in the example). This allows for the usage of the same APN for all terminals (something that is often preferred by operators), but requires the SGSN to have support for this selection mechanism that was defined in 3GPP Release 8. It means that the SGSN is no longer fully transparent to the introduction of LTE/EPC in the network.

Deployment of inter-system mobility support also requires upgrade of the GSM or WCDMA network that the terminals fall back on when losing LTE coverage. The required support is to broadcast system information on neighboring LTE cells in order for the terminals to find their way back to LTE when in coverage again.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780123945952000037

Selected call flows

Stefan Rommer , ... Catherine Mulligan , in 5G Core Networks, 2020

15.7.1 Introduction

As described in Chapters 3 and 7 3 7 , the 5GS supports interworking with EPS and session continuity for a UE moving between EPC and 5GC. In this section we describe handover and mobility procedures for the case where N26 interface is supported between AMF and MME. The N26 interface allows the UE context to be transferred between the systems and ensures that a handover can be prepared also in case the UE only supports single-registration, i.e., the UE is only connected to either EPC or 5GC at each instant. The N26 interface enables seamless mobility for single-registered UEs, e.g., fulfilling requirements for real-time services like voice.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780081030097000156

Procedures

Magnus Olsson , ... Catherine Mulligan , in SAE and the Evolved Packet Core, 2010

12.4.1 Basic handover

If we consider radio access and packet core network level handover without worrying about the service continuity and session continuity aspects, the following possible handover combinations can be found:

1.

Intra and Inter 3GPP access handover

a.

Intra E-UTRAN.

b.

E-UTRAN to/from UTRAN (GTP or PMIP).

c.

E-UTRAN to/from GERAN (GTP or PMIP).

d.

Intra GERAN, Intra UTRAN and GERAN to/from GERAN. (These handover cases are not covered in this book.)

2.

3GPP and non-3GPP handover

a.

Optimized handover E-UTRAN to/from HRPD (for GTP and PMIP).

b.

Basic non-optimized handover: trusted non-3GPP access (including HRPD) to/from GERAN/UTRAN/E-UTRAN (with GTP/PMIP on 3GPP access and PMIP/MIPv4FA/DSMIPv6 on non-3GPP access).

c.

Basic non-optimized handover: untrusted non-3GPP access (including HRPD) to/from GERAN/UTRAN/E-UTRAN (with GTP/PMIP on 3GPP access and PMIP/DSMIPv6 on non-3GPP access).

Note that all these scenarios can be Intra or Inter PLMN handover as described below in more detail. In case of handover, we have chosen to focus on trusted non-3GPP access via S2a interface, which implies a network-based mobility using PMIP protocol for non-3GPP accesses and either GTP or PMIP protocol for 3GPP accesses.

12.4.1.1 3GPP radio access

Within 3GPP (as well as in most other cellular technologies) a handover is defined as follows in a very narrow term (as per TS 22.129 [22.129]):

Handover is the process in which the radio access network changes the radio transmitters or radio access mode or radio system used to provide the bearer services, while maintaining a defined bearer service QoS.

Handover is a key mobility mechanism for any cellular systems, whether moving within an access technology or between different access technologies. Core networks play a crucial role in the handover mobility process but in a majority of the cases, the decision to handover is based on the radio conditions.

The UE assists the network by radio measurements about the serving as well as neighbouring cells in the same or different access technologies that may be candidates for handover. The details of how and when the UE and E-UTRAN decides to trigger a handover is far beyond the scope of this book but the interested reader can find more details in Dahlman (2008).

Handover can be of many different types and forms and if we exclude the ­process of selecting the target access technology by the UE being handed over to, hand­over may cause the core network to be involved in the most simplest form of getting the target access network information the UE is connecting to and to a more complex form where one or more core network entities needs to be relocated to better serve the user. In addition to the process of actually changing the radio and/or core network entities, the handover process also needs to ensure the service continuity, that is maintaining the bearer characteristics for active services as far as possible. A system may use handover/cell-reselection mechanism to achieve service continuity for a UE actively involved in a session (transmitting and receiving data). Note that other mechanisms, such as SRVCC, also enable certain specific service continuity for specific type of service(s) which is addressed in a separate section of the book (see Section 12.6).

So what are the different kinds of handovers possible from an overall network perspective? Let us take the example diagram illustrated in Figure 12.4.1.1.1, where it depicts a simple scenario where Operator X and Operator Y have some of their radio networks connected to each other and their core network (here EPC) connected via a GRX/IPX interconnect. Operator X has two EPC networks connected to the RANs OPx1, OPx2, …, OPxn, whereas Operator X has one EPC network connected to RANs OPy1 and OPy2. The first level of handover we can define may be whether the user is moving within Operator X networks thus causing Intra PLMN handover. If the user moves between RANs OPx1 and OPy2, then we have just encountered Inter PLMN handover. During Inter PLMN handover, when the user crosses radio access technology also, such as E-UTRAN to/from UTRAN, the network has also performed Inter System Handover by changing the radio access technology. Note that a UE will only be instructed to measure on neighbour cells to which handover is allowed.

Figure 12.4.1.1.1. Multi-operator simplified 3GPP network diagram.

In case of Inter PLMN handover, a number of aspects need to be understood/established before handover may be accomplished. First of all, in Inter PLMN handover, a session may not only cross an operator's boundary, but it may also cross country boundary. A call in the United States may, for example, arise in the upstate New York bordering Canada and continue inside Canada if Inter PLMN handover is supported between the two involved operators. As such, Inter PLMN handover is very much up to individual operator's discretion to support or not. An operator may choose to drop the session and then require the UE to register in the new PLMN instead and in this case, the service continuity is not maintained. Before proceeding with Inter PLMN handover, certain criteria need to be met as specified in 3GPP TS22.129 [22.129]:

•

The ability to check with the home network whether the user is permitted to handover from the visited network to a target network.

•

Invocation of the handover procedure only occurs if the target network provides the radio channel type required for the respective call.

•

The avoidance of 'network hopping', that is, successive handover procedures between neighbouring networks for the same call.

•

The possibility of user notification of Inter PLMN HO (e.g. possible tariff change) when it occurs.

During handover procedures, a network may operate in one of the three roles: Home PLMN, Serving PLMN and Visited PLMN. Home PLMN is where the subscriber has his/her subscription. Visited PLMN is the visited network for a roaming user where the user has performed successful registration process (i.e. HSS is aware of where the user is located and has performed all the procedures needed for updating the user's location). Serving PLMN/network is where the user may have been handed over to (e.g. the cell the user is being served by belongs to the Serving network operator) and has not yet performed the registration process. Most likely scenario is that the Serving PLMN becomes the Visited PLMN after registration unless the user moves out of the serving area/cell.

Shared networks have also support handover of all types, mentioned above, between shared and non-shared networks but some additional aspects, such as the core network it is connected to and the home network where the user has subscription, are also important to take into account.

Even though the most frequent cause of handover is the movement of the user (i.e. the UE), there are other additional triggers that can cause a handover to occur. Some examples of these reasons may be:

•

Triggered due to a service requirement that may be met by a different RAT than the one the UE is being served by and core network may trigger such process.

•

Various radio conditions such as change of radio access mode, capacity of a cell to be able to serve the user's current services.

Even though, in principle, handover shall not cause any significant loss/change of service or interruption of service, when multiple radio bearers are being handed over from one type of radio access to another, there may be need to drop certain bearers and maintain others based on, for example, priority and relevant QoS information, data rate, delay constraints, error rate, etc. Also, sometimes, certain QoS may be degraded to accommodate the handover of all PS bearers. Overall, instead of failing to handover at all, it would be preferable to be able to handover at least one bearer that is suited for the target radio access. Usually when moving from a higher bit rate to a lower one (e.g. UTRAN to GERAN), then decisions have to be made that suits the serving network operator (HPLMN when not roaming) and an operator may choose to drop all active bearers or based on certain pre-defined criteria choose to handover specific bearers.

So what has changed for EPS compared to what existing handover concepts did not already cover? For example, there is no longer a central entity controlling the RAN like an RNC for UTRAN and a BSC for GERAN. Instead, the eNodeBs in E-UTRAN connects directly to the EPC core network entities, MME for the control plane for signalling and Serving GW for user plane traffic transferring data to/from a terminal for the user. In addition to EUTRAN, the EPS must also support handover to/from non-3GPP accesses such as HRPD network, WiMAX and Interworking WLAN (or I-WLAN as referred to in 3GPP). Thus it is expected that EPS must be able to support handover between heterogeneous access systems, where the non-3GPP access networks are not developed in 3GPP. These handovers also need to support service continuity, thus the ability to maintain IP connectivity within the EPC when moving between these heterogeneous access networks has taken a lot of efforts to accomplish. Even though Inter system handover is usually used in conjunction with 3GPP accesses, this term can easily be expanded to also cover Intra PLMN handover between 3GPP and non-3GPP access. For 3GPP accesses, both Inter PLMN and Intra PLMN handovers as well as Inter System handovers are supported with special emphasis on service continuity between UTRAN and E-UTRAN radio access. In addition, EPS also supports handover from E-UTRAN to pre-Release 8 3GPP networks, but note that the opposite direction is not supported. In this case, the source network (i.e. EPS) has to adopt the target network requirements due to the fact that the target network can not understand/interpret the EPS information due to that pre-Release 8 networks are not upgraded.

Another special aspect of E-UTRAN radio access is that it is a packet-only system and thus there is no support for circuit-switched bearers and CS Domain in the evolved system. So a handover from IMS voice on E-UTRAN EPS to CS voice on 2G/3G has been developed in 3GPP and it is known as Single Radio Voice Call Continuity (SRVCC). It is also possible to provide dual radio-based service continuity between 3GPP and other non-3GPP accesses with IMS, when the non-3GPP access is connected via EPS.

HRPD and 3GPP access

For HRPD, the UE can provide its capabilities regarding other radio accesses and systems it can support and relevant details such as single/dual radio, dual receiver, frequency, etc. via same mechanism as it would do for E-UTRAN access. E-UTRAN is able to configure which other access technology information the UE may be able to provide to the EPS system. Also for handover to/from non-3GPP access, the access technologies must be connected via EPS.

In case of HRPD networks, the requirements on E-UTRAN are very similar to existing 2G/3G 3GPP access networks. The following need to be supported by E-UTRAN and HRPD access network in order to facilitate smoother performance compared to other non-3GPP accesses. As stated previously, the operator requirements are directly linked to the existing networks and subscriber base for CDMA systems. E-UTRAN controls the trigger for UE to measure the HRPD information for preparation of handover, when handover is performed from E-UTRAN to HRPD direction. The HRPD system information block (SIB) has to be sent on the E-UTRAN broadcast channel. The UE monitors the broadcast channel in order to retrieve the HRPD system information for the preparation of cell reselection or handover from the E-UTRAN to HRPD system. HRPD system information may also be provided to the UE by means of dedicated signalling. The HRPD system information contains HRPD neighbouring cell information, CDMA timing information, as well as information controlling the HRPD pre-registration. Note that pre-registration is used only when optimized handover is supported in the EPS, for more details see later sections below.

General non-3GPP and 3GPP access

In case of general non-optimized handover, the UE needs to perform access attach procedure with target access. For handing over to a non-3GPP access, both network-based and host-based IP mobility management solutions are supported (see Section 11.3). For handovers from a non-3GPP access to a 3GPP access, only network-based mobility is supported in target non-3GPP access.

For handover using network-based mobility in target access, the terminal performs access attach with an indication that the attach is of type 'handover' in order for the target network (i.e. radio access, MME, Serving GW) to establish the necessary resources for the handover and also where possible, maintain the IP connectivity by maintaining the PDN GW and the terminal's IP address(es). For host-based mobility in target non-3GPP access, the terminal establishes a local IP connectivity in target access and the handover and IP address preservation is then executed using the host-based IP mobility mechanism. Depending on the number of PDN the UE was connected to before handover, and depending on what the target system can support, the PDN connectivity may be ­re-established in the target access by the network or by the UE itself or some of them are dropped during handover. So the handover, in this case, has very little interactions with access networks and is performed by the UE and the core network. For more details on these handover procedures, see sections below.

So what we can conclude is that the basic handover requirements remain the same as we move towards E-UTRAN and EPS, but we also continue to enhance the system to accommodate non-3GPP accesses as well as IMS service continuity as we evolve the systems. In the sections below, we will elaborate how the EPS level handovers are supported by the radio and evolved core networks.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780123748263000126

Procedures

Magnus Olsson , ... Catherine Mulligan , in EPC and 4G Packet Networks (Second Edition), 2013

17.7.1 Overview

If we consider radio access and packet core network-level handover without worrying about the service continuity and session continuity aspects, the following possible handover combinations can be found within and between 3GPP accesses and non-3GPP accesses:

a.

Optimized handover E-UTRAN to/from HRPD (for GTP and PMIP).

b.

Basic non-optimized handover – trusted non-3GPP access (including HRPD) to/from GERAN/UTRAN/E-UTRAN (with GTP/PMIP on 3GPP access and PMIP/MIPv4FA/DSMIPv6 on non-3GPP access).

c.

Basic non-optimized handover – untrusted non-3GPP access (including HRPD) to/from GERAN/UTRAN/E-UTRAN (with GTP/PMIP on 3GPP access and PMIP/DSMIPv6 on non-3GPP access).

Note that all these scenarios can be Intra- or Inter-PLMN handover, as described in more detail below. In the case of handover, we have chosen to focus on trusted non-3GPP access via the S2a interface, which implies network-based mobility using the PMIP protocol for non-3GPP accesses and either the GTP or PMIP protocol for 3GPP accesses.

17.7.1.1 HRPD and 3GPP Access

For HRPD, the UE can provide its capabilities regarding other radio accesses and systems it can support and relevant details such as single/dual radio, dual receiver, and frequency via the same mechanism as it would use for E-UTRAN access. E-UTRAN is able to configure which other access technology information the UE may be able to provide to the EPS system. Also, for handover to/from non-3GPP access, the access technologies must be connected via EPS.

In the case of HRPD networks, the requirements on E-UTRAN are very similar to those for the existing 2G/3G 3GPP access networks. The following need to be supported by E-UTRAN and HRPD access network in order to facilitate smoother performance compared to other non-3GPP accesses. As stated previously, the operator requirements are directly linked to the existing networks and subscriber base for CDMA systems. E-UTRAN controls the trigger for the UE to measure the HRPD information for preparation of handover, when handover is performed in the E-UTRAN to HRPD direction. The HRPD System Information Block (SIB) has to be sent on the E-UTRAN broadcast channel. The UE monitors the broadcast channel in order to retrieve the HRPD system information for the preparation of cell reselection or handover from the E-UTRAN to the HRPD system. HRPD system information may also be provided to the UE by means of dedicated signaling. HRPD system information contains HRPD neighboring cell information and CDMA timing information, as well as information controlling HRPD pre-registration. Note that pre-registration is used only when optimized handover is supported in the EPS (for more details see later sections below).

17.7.1.2 General Non-3GPP and 3GPP Access

In the case of general non-optimized handover, the UE needs to perform an access attachment procedure with target access. For handing over to a non-3GPP access, both network-based and host-based IP mobility management solutions are supported (see Section 6.4). For handovers from a non-3GPP access to a 3GPP access, only network-based mobility is supported in target non-3GPP access.

For handover using network-based mobility in target access, the terminal performs access attachment with an indication that the attachment is of "handover" type in order for the target network (i.e. radio access, MME, Serving GW) to establish the necessary resources for the handover and also, where possible, maintain the IP connectivity by maintaining the PDN GW and the terminal's IP address(es). For host-based mobility in target non-3GPP access, the terminal establishes a local IP connectivity in target access, and the handover and IP address preservation are then executed using the host-based IP mobility mechanism. Depending on the number of PDNs the UE was connected to before handover, and depending on what the target system can support, the PDN connectivity may be re-established in the target access by the network or by the UE itself, or some of them are dropped during handover. So the handover, in this case, has very few interactions with access networks and is performed by the UE and the core network. For more details on these handover procedures, see the sections below.

We therefore conclude that the basic handover requirements remain the same as we move towards E-UTRAN and EPS, but we also continue to enhance the system to accommodate non-3GPP accesses as well as IMS service continuity as we evolve the systems. In the sections below, we will show how EPS-level handovers are supported by the radio and evolved core networks.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780123945952000177

EPS deployment scenarios and operator cases

Magnus Olsson , ... Catherine Mulligan , in SAE and the Evolved Packet Core, 2010

4.4 Scenario 4: WiMAX and WLAN Operators

Even though it might be questioned whether operators operating exclusively in these access technologies would see any motivation to migrate towards EPC (without LTE), the benefits can be seen from a common core network as well as handover/session continuity perspective with existing and well-established access technologies with huge number of subscribers (over 3 billion and counting…). The EPS could also open up the possibility to get into roaming relationship that exists, for example, via GRX with international community. One may consider the scenario that an LTE operator establishes partnership with, for example, a WLAN access provider, connected via the EPC networks and providing indoor coverage in certain local network environment. Since hand­over/session continuity with IP and session preservation is supported, users can easily move in and out of such coverage while maintaining their sessions via EPC. Depending on the scenario, such non-3GPP access network providers may desire to establish a full EPC network using AAA infrastructure, Access Gateways and PDN Gateways (and optionally Serving GWs in a very specific situations). Alternatively, an operator may choose to deploy AAA infrastructure and Access Gateways to connect via an existing operator's EPS networks, where special business relationship may be established with such access providers. This type of symbiotic relationship may benefit both operators business, depending on the market environment they are operating on (e.g. wide usage of WLAN in a certain city centre).

An additional key question is of course the availability of dual/multi mode handsets, providing support for both LTE (and/or other 3GPP accesses) and the non-3GPP access that the operator is using. In the case of WLAN this combination can be expected to be very common in terminals.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780123748263000047

5G network slicing

Haorui Yang , ... Yang Xu , in 5G NR and Enhancements, 2022

12.2.2.2 Service data path establishment

When the UE initiates its application service activation, as described in the section above, it determines the attributes of the PDU session corresponding to the service according to the URSP, such as DNN, S–NSSAI, and Session and Service Continuity mode. In addition, the URSP rule may also indicate the type of access technology that needs to be preferentially used for the PDU session (e.g., 3GPP access or Non-3GPP access). 3GPP access includes LTE and NR while Non-3GPP access includes the Wireless Local Area Network. The 5G system supports Network Slicing over both 3GPP access and Non-3GPP access. The UE includes the PDU session attributes when initiating the PDU session establishment procedure. The simplified procedure is as follows and can be seen in Fig. 12.6, and the detailed procedure can be found in TS 23.502 [6].

Figure 12.6. PDU Session Establishment in a network slice.

1.When initiating the establishment of a PDU session, the UE includes the DNN, the S–NSSAI, other PDU session parameters, and the PDU Session Establishment Request in the UL NAS Transport message. The UE will then send the UL NAS Transport message to the AMF.

2.Based on the received DNN, S–NSSAI, and other PDU session parameters, the AMF selects an SMF belonging to the network slice identified by the S–NSSAI. After the successful SMF selection, the AMF forwards the DNN, S–NSSAI, PDU Session Establishment Request message, and other parameters to the selected SMF. Then the SMF selects a UPF to serve the PDU session.

3 and 4. If the SMF accepts the PDU session establishment, it sends the PDU Session Establishment Accept message to the UE. In the message, the allocated PDU address and QoS flow parameters are included so the UE can use the PDU address to satisfy the data transmission protocol.

When the UE subscription or the network deployment changes, the network can update the new Allowed NSSAI to the UE. After receiving the Allowed NSSAI, the UE will compare it with the S–NSSAIs of the established PDU sessions. If one S–NSSAI of the established PDU session is no longer in the Allowed NSSAI, the UE will locally release this PDU session.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B978032391060600012X

Session Management and Mobility

Magnus Olsson , ... Catherine Mulligan , in EPC and 4G Packet Networks (Second Edition), 2013

6.4.6.3 IP Mobility Mode Selection

The EPS specifications allow both host- and network-based mobility; different operators may make different choices about which of the two to deploy in their networks. An operator may also choose to deploy both. In 3GPP accesses, there is only a choice between two network-based mobility protocols (PMIPv6 or GTP) and the selection of one protocol over the other has no impact on the terminal, since the network choice of protocol is transparent to the UE. It should be noted that even if multiple mobility protocols are supported in a network deployment, only a single protocol is used at a time for a given UE and access type.

Terminals may support different mobility mechanisms. Some terminals may support host-based mobility and thus have a Mobile IP client installed (Dual-Stack Mobile IPv6 and/or Mobile IPv4 client). Other terminals may support IP-level session continuity where network-based mobility protocols are used. There may also be terminals that support both mechanisms. In addition, some terminals may have neither a Mobile IP client nor support IP session continuity using network-based mechanisms. These terminals will not support IP-level session continuity but could still attach to EPC using different access technologies.

There is thus a need for selecting the right mobility mechanism when a terminal attaches to the network or is making a handover. If network-based mobility protocols are selected, there also needs to be a decision whether session continuity (i.e. IP address preservation between the accesses) shall take place.

EPS has defined different means for how this selection can be done. The rules and mechanism for selecting the appropriate mobility protocol is referred to as IP Mobility Mode Selection (IPMS).

One option with IPMS is to statically configure the mobility mechanism to use in the network and the terminal. This is possible, for example, if the operator is only supporting a single mobility mechanism and if the operator can assume that the terminals used in its network support the deployed mobility mechanism. If a user switches to another terminal not supporting the mobility protocol deployed by the operator, IP-level session continuity may not be possible.

The other option is to have a more dynamic selection where the decision to use either network- or host-based mobility is made as part of attachment or HO procedures. It should be noted that over 3GPP accesses only network-based mobility is supported using either PMIPv6 or GTP. Therefore, mobility mode selection is only needed when the terminal is using a non-3GPP access.

IPMS is performed when the user attaches in a non-3GPP access or sets up an IPSec tunnel towards an ePDG, before an IP address is provided to the terminal. The terminal may provide an indication about its supported mobility schemes during network access authentication, by using an attribute in the EAP-AKA and EAP-AKA' protocols. The indication from the UE informs the network if the terminal supports host-based mobility (DSMIPv6 or MIPv4) and/or if it supports IP session continuity using network-based mobility (using GTP or PMIPv6 in the network). The network may also learn about the terminal capabilities using other mechanisms. For example, if a terminal has attached in 3GPP access and performed bootstrapping for DSMIPv6, the network implicitly understands based on the already performed bootstrapping procedure that the terminal is capable of using DSMIPv6. Based on its knowledge about the terminal and the capabilities of the network, the network decides which mobility mechanism to use for the particular terminal. If the network has no knowledge about a terminal's capabilities, the default is to use network-based mobility protocols. Host-based mobility can only be selected by the network if it knows that the terminal supports the appropriate mobility protocol (DSMIPv6 or MIPv4).

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780123945952000062

IP Mobility Management for Future Public Safety Networks

Tien-Thinh Nguyen , Christian Bonnet , in Wireless Public Safety Networks 2, 2016

5.3.1 DMM requirements for public safety networks

As mentioned in the previous section, DMM concepts have been introduced to address the limitations of current mobility management, including both the (network-layer) centralized approaches and SIP. In [CHA 14], the main requirements for DMM solutions are defined including distributed deployment, transparency to upper layers when needed, IPv6 deployment, reusability of mechanisms in the existing mobility protocols if possible, co-existence with deployed networks/hosts, security considerations, and multicast considerations.

In the context of public safety, we define some additional requirements/metrics that are crucial to access the effectiveness of a DMM solution. These requirements/metrics come from the general ones as well as the requirements/metrics for a specified application such as GCS and MCPTT [GPP 14a], [GPP 15g].

–

requirement/metric 1 (REQ1)-interworking: a DMM solution for PSN should support roaming/mobility between different networks including LTE-based and non-LTE legacy systems such as TETRA, P25, and Land Mobile Radio (LMR);

–

REQ2-session continuity : a DMM solution needs to consider the performance requirement in terms of session continuity (service interruption time for an on-going session and the time needed to start a new communication after handover). The service interruption time, similarly to the group call setup and the group joining time, should be less than or equal to 300ms as specified in [GPP 14a];

–

REQ3 – end-to-end delay: similarly, a DMM solution needs to take the end-to-end media transport delay requirement into account. Accordingly, the end-to-end delay should be less than or equal to 150   ms as specified in [GPP 14a];

–

REQ4 – scalability: in a major disaster, accident or terrorist attack, a large amount of users may use the service at the same time. As a consequence, a DMM solution should scale well with the number of users and the corresponding traffic demand;

–

REQ5 – flexibility: since different types of operations are required in PSN such as day-to-day operations and disaster situations, the DMM solution should cope with these types of operation. This metric shows how powerful the solution should be in terms of configurability, flexibility, extensibility, and adaptability.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781785480522500050

Protocols

Magnus Olsson , ... Catherine Mulligan , in SAE and the Evolved Packet Core, 2010

11.4.1 General

As explained in Section 11.3 , mobility schemes can often be classified as either being host-based or network-based. MIPv6, described in the previous section, is a host-based mobility management solution where the UE has functionality to detect movement and to exchange IP mobility signalling with the network in order to maintain IP-level session continuity.

PMIPv6, defined in RFC 5213 [5213], on the other hand is network-based mobility management protocol that has a similar purpose as MIPv6, that is, to facilitate IP-level session continuity. PMIPv6 reuses much of the concepts and packet formats that have been defined for MIPv6. A key difference between MIPv6 and PMIPv6 is however that with PMIPv6 the UE does not have Mobile IP software and does not participate in the IP mobility signalling. A key intent of PMIPv6 is in fact to enable IP-level mobility also for those UEs that do not have Mobile IP client functionality. Instead it is mobility agents in the network that track the UE's movement and perform IP mobility signalling on behalf of the UE. A mobility agent in the network acts as a proxy for the UE when it comes to IP mobility signalling, hence the name Proxy Mobile IPv6.

Since PMIPv6 reuses many parts of MIPv6 such as packet format, the description of PMIPv6 in this section will to a large extent build on the description of Mobile IP in Section 11.3.

PMIPv6 is used on the S2a, S2b interfaces and as a protocol alternative on the S5/S8 interface. Specific aspects related to PMIPv6 usages in EPS are described in previous chapters, for example, regarding EPS bearers [Section 6.3], mobility [Section 6.4], PCC [Section 8.2], and so on. For more details on the PMIP-based interfaces, see Section 10.4. Below we describe the PMIPv6 protocol as such.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780123748263000114