7 Multi-access and seamless mobility

22.2783GPPService requirements for the Evolved Packet System (EPS)TS

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

7.1 Mobility management

7.1.1 Heterogeneous access systems mobility

Internet

and

E-UTRAN

Evolved

Packet

Core

AAA

Policy

Access

System

PSTN

. . .

Evolved

Packet

System

. . .

E-UTRA

on 3GPP

3GPP

Legacy

System

. . .

Figure 3: Heterogeneous access system mobility between 3GPP Legacy Systems or E-UTRAN and non 3GPP Access Systems including Fixed Access systems

The Evolved Packet System shall support mobility between heterogeneous access systems.

The Evolved Packet System shall provide mobility mechanisms to support frequent handovers within and across 3GPP legacy systems or E-UTRAN and non 3GPP access systems in order to avoid service degradation.

The Evolved Packet System shall support mobility mechanisms that accommodates access systems within Rel-7 and earlier.

7.1.2 Local breakout

The Evolved Packet System shall allow for local breakout. Local breakout means that for a user which makes mobility within and across one operator-defined network region, routing is optimized such that user plane traffic does not need to leave the current region. An operator may define network regions e.g., according to administrative domains. Local breakout is applicable for user-to-user traffic as well as for 3GPP-operator provided services (including internet access).

Local breakout shall be allowed independently from the access system being used.

Local breakout shall be allowed in both the non-roaming and the roaming case.

The use of local breakout shall be authorised by the HPLMN. If local breakout is not authorised, the user plane traffic shall be handled in the home routed mode.

7.1.3 Fixed Access Systems

The Evolved Packet System shall be able to support fixed access systems with very limited or no mobility functionality.

The Evolved Packet System shall be able to support mobility within and across 3GPP and non-3GPP access systems including fixed access systems

7.1.4 Service continuity

7.1.4.1 General

Service shall be maintained during and following changes of 3GPP access systems and non 3GPP systems.

Service shall be maintained during and following a change of network in either direction between a Rel-7 and earlier network and an Evolved Packet System.

It shall be possible to support Inter-PLMN handover with seamless service continuity within a 3GPP specified access system (UTRAN, E-UTRAN).

When the access system changes, Multicast and Broadcast services shall be able to continue with their corresponding Multicast and Broadcast services, if the corresponding services are provided in the target access system.

NOTE: Corresponding Multicast and Broadcast services are the Multicast and Broadcast services in the target access system which is associated to the Multicast and Broadcast services in the source access system, providing similar service experience, e. g. with same content but different bit-rate.

The 3GPP system shall minimise packet loss during inter- and/or intra- access technology changes for some or all connections associated with a UE.

Figure 4: Inter-PLMN handover with seamless service continuity within a 3GPP specified access system

7.1.4.2 Service continuity at domain and RAT change for TS 11, TS 12 and equivalent PS service

It shall be possible to support continuity of an established voice call, i.e. between a TS11, TS12 and an equivalent PS service, when the UE moves between two different domains and RATs. The user experience shall be as far as possible unaffected by the change of domain and RAT. The RAT change procedure executed to enable service continuity for an established voice call shall target an interruption time not higher than 300 ms.

RAT change and domain selection shall be under the control of the registered PLMN. When the UE is roaming, it shall be possible for the VPLMN to take into account any user’s HPLMN operator policy.

To support service continuity of an established voice call a UE shall not be required to support simultaneous radio transmission via different 3GPP defined RATs

NOTE: In the case of CS emergency calls (TS12) the service continuity at domain and RAT change can only be performed if IMS emergency calls are supported by the target system.

7.1.4.2A Voice Call Service continuity between 3GPP defined RATs and non 3GPP defined RATs

Continuity of an established voice call, i.e. between a TS11 and an equivalent PS service, when the UE moves between 3GPP defined RATs and non 3GPP defined RATs, shall be supported provided that the non-3GPP defined RATs is connected to the 3GPP system via the Evolved Packet Core.

The user experience shall be as far as possible unaffected by the change of RAT.

7.1.4.3 Service continuity between E-UTRAN and 3GPP2 accesses on Evolved Packet Core

The Evolved Packet System shall support bidirectional service continuity between cdma2000 1xRTT Revision A [8], [9], [10], [11], [12], [13], [14], [15] and E-UTRAN.

Note 1: if bi-directional support is not practical, service continuity from E-UTRAN to cdma2000 1xRTT Revision A should have the higher priority.

Note 2: The CS component of cdma2000 1xRTT Revision A is not expected to be connected to the Evolved Packet Core.

The Evolved Packet System shall support bidirectional service continuity between cdma2000 HRPD (1xEV-DO) Revision A [17], [14], [15], [16] and E-UTRAN for best effort and real-time applications.

The Evolved Packet System shall support bidirectional service continuity between cdma2000 HRPD (1xEV-DO) Revision 0 [18], [14], [15], [16] and E-UTRAN for best effort applications.

7.1.4.4 Service continuity between 3GPP and WiMAX access on Evolved Packet Core

The Evolved Packet System shall support bidirectional service continuity between Mobile WiMAX [20], [22], [23], [24] and GERAN PS.

The Evolved Packet System shall support bidirectional service continuity between Mobile WiMAX [20], [22], [23], [24] and UTRAN PS.

The Evolved Packet System shall support bidirectional service continuity between Mobile WiMAX [20], [22], [23], [24] and E-UTRAN.

NOTE: The above requirements assume that the service continuity takes place through the Evolved Packet Core.

7.1.5 Access network discovery

To avoid unnecessary background scan by the UE and to facilitate service continuity by the UE it shall be possible for the VPLMN and the HPLMN to provide the UE with access network information pertaining to locally supported non-3GPP access technologies, in a resource efficient and secure manner. This mechanism is meant to facilitate changes, including service continuity, between 3GPP access systems and non 3GPP access systems and vice versa. The information may be restricted to the access technologies the UE can use. To reduce battery drain, a UE should minimise the frequency of scanning for different access technologies.

When discovering non-3GPP accesses a UE shall be able to receive information from a non-3GPP access network concerning to which PLMN, or PLMNs, the non-3GPP access network provides access.

NOTE: The capability to provide such information by a non-3GPP access network is out of scope of 3GPP.

When a UE receives service via a non-3GPP access it shall be possible for the PLMN that provides the non-3GPP access to indicate local availability of 3GPP access to the UE,, in a secure manner, subject to capabilities of the non-3GPP access network.

7.1.6 Steering of access

When a UE is accessing the Evolved Packet Core via E-UTRA, the operator of the PLMN that provides the access (registered PLMN or RPLMN for short) may request the UE to use – any or a specific – non-3GPP RAT. Similarly, if a UE is accessing the Evolved Packet Core via a non-3GPP RAT then the RPLMN may want to request the UE to use E-UTRA. The reason for such steering may be load balancing (for camped- and traffic load balancing), operator policy, private networks/home cells, service based mobility control etc.

The RPLMN shall be able to download on the UE a list of preferred access technologies in priority order. If, while the UE is registered on that PLMN, an access technology with higher priority than the one currently used is detected, the UE shall attempt to use the higher priority access network to access the RPLMN.

The UE shall only perform access technology selection within the RPLMN.

In case the UE is connected to the PLMN via a non-3GPP access, then the PLMN reselection procedures specified for that access technology may be executed.

Note 1: The PLMN operator may provide access to the Evolved Packet Core either through an own access network (E-UTRA or non-3GPP access) or in collaboration with an access network operator that operates a non-3GPP access network.

Note 2: A specific non-3GPP RAT may e.g. be identified by RAT type and the access network name (as advertized by the access network), or a list of access network names.

The HPLMN may also provide the UE with a list of preferred access technologies in priority order for use in the RPLMN. Only one list of preferred access technologies can be active at a time and the list provided by the RPLMN takes precedence over the list provided by the HPLMN. The list of preferred access technologies received from the VPLMN is specific to that VPLMN and PLMNs equivalent to it.

7.1.7 CS fallback

7.1.7.1 General

For those services delivered via the HPLMN that the HPLMN only supports in the CS domain (e.g. voice services), when such services are invoked while the UE is configured to use CS Fallback and registered in the E-UTRAN (either in the HPLMN or in a VPLMN), it shall be possible for the EPS to request the UE to perform a change of radio access technology in order to deliver the service over UTRAN or GERAN or 1xRTT.

In the case of an incoming CS service to a UE that is registered for CS services and active in E-UTRAN, the EPS shall transfer the CLI to the UE if available and the calling party has not restricted the presentation, prior to triggering CS fallback. Depending on UE configuration and when the UE is in connected mode, the user or an application on behalf of the user may request to accept or reject CS fallback before performing a change of radio access technology. The default behaviour of the UE is to accept the CS fallback.

CS fallback shall not be applicable to an Indirect 3GPP Communication.

NOTE: An Evolved ProSe UE-to-Network Relay that is also in a Direct 3GPP Communication with the network may be subject to CS fallback in the Direct 3GPP Communication. In this case, any Indirect 3GPP Communication supported by the Evolved ProSe UE-to-Network Relay would have to be discontinued.

7.1.7.2 Roaming in a VPLMN not supporting CS fallback

When a UE that is configured to use CS fallback registers over E-UTRAN in a VPLMN not supporting CS fallback the default behaviour of the UE is to attempt to select a GERAN/UTRAN/1xRTT CS radio access technology in the VPLMN or in a PLMN equivalent to the VPLMN. The default behaviour of the UE is not to autonomously attempt to (re-)select the E-UTRAN for the duration of the time the UE stays in a VPLMN and PLMNs equivalent to the VPLMN.

The default behaviour may be changed based on user preference settings.

The UE may offer the user to perform a PLMN scan and display the list of available PLMNs. The selection of a different PLMN is performed using the manual mode.

7.1.8 Service Reachability

The Evolved Packet System may provide functionality to enable user access to PLMN IP-based services from outside of the PLMN’s domain via non-3GPP access technologies under conditions where there are IP traffic-flow restrictions (e.g. allow only HTTP traffic). Such functionality is known as Service Reachability.

When the Evolved Packet System provides Service Reachability, the following requirements apply:

– pre-existing EPS security shall be maintained; and

– the third party that placed the IP traffic-flow restriction shall be able to prohibit Service Reachability by blocking PLMN IP-based services intentionally.

Note 1: Examples of a third party include enterprises and internet service providers whose traffic restriction lie outside the operator’s domain.

Note 2: Service Reachability can also be achieved by the network operator remotely configuring the elements with firewall function, provided there is a trust relationship between the network operator and the operator of the elements with firewall function.

7.2 IFOM Service requirements

Simultaneous active mode of operation is an optional capability for multimode UEs, which support 3GPP and WLAN access. UE supporting simultaneous active mode of operation between one set of technologies may not be capable to support simultaneous active mode of operation between a different technology set (e.g. due to radio interference limitations).

The following requirements apply to the case of UEs with multiple interfaces which will simultaneously connect to 3GPP access and one single WLAN access.

– It shall be possible to provide service continuity when the UE moves from the 3GPP access to WLAN access and vice versa.

– If the UE is under the coverage of more than one access, including 3GPP and WLAN accesses and communicates using multiple accesses simultaneously, it shall be possible to select one access when a flow is started and re-distribute the flows to/from a UE between accesses while connected.

– It shall be possible for the operator to enable and control via policies the simultaneous usage of multiple accesses.

– It shall be possible to distribute IP flows to/from a UE between available accesses based on the characteristics of the flows and the capabilities of the available accesses, subjected to user’s preferences and operator’s policies.

– It shall be possible for the operator to define policies for the control of the distribution of IP flows between available accesses. Each policy shall include a list of preferred accesses and whether the policy may be overridden by the user’s preferences.

NOTE: The possibility of manual selection or user override is not precluded.

These policies may be defined per APN, per IP flow class under any APN or per IP flow class under a specific APN. The IP flow class identifies a type of service (e.g. IMS voice) or an operator defined aggregation of services.

The policies apply with the following priority order:

Policies per IP flow class under a specific APN.
Policies per IP flow class under any APN.
Policies per APN.

– Distribution of flows to/from a UE between available accesses based on the characteristics of the flows and/or the capabilities of the available accesses shall be possible for flows exchanged by both operator controlled (e.g. IMS) and non operator controlled (e.g. web and mail access) applications/services.

– It shall be possible to move all the flows to/from a UE out of a certain access in case the UE loses connectivity with that access (e.g. UE moves out of coverage of a WLAN access while maintaining connectivity through the 3GPP access).

– Re-distribution of flows to/from a UE between accesses may be triggered by changes to the characteristics of the flows (e.g. QoS requirements) or the capabilities of the available accesses (e.g. due to network congestion, mobility event, or UE discovers a new access) during the connection.