Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 22.278  Word version:  18.0.1

Top   Top   Up   Prev   Next
0…   5…   6…   7…   7A…   7B…   9…   A…   B1…   B2…

 

7  Multi-access and seamless mobilityp. 18

7.1  Mobility managementp. 18

7.1.1  Heterogeneous access systems mobilityp. 18

Reproduction of 3GPP TS 22.278, Fig. 7.1.1-1: Heterogeneous access system mobility between 3GPP Legacy Systems or E-UTRAN and non 3GPP Access Systems including Fixed Access systems
Up
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 breakoutp. 19

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.
Up

7.1.3  Fixed Access Systemsp. 19

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 continuityp. 19

7.1.4.1  Generalp. 19

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.
The 3GPP system shall minimise packet loss during inter- and/or intra- access technology changes for some or all connections associated with a UE.
Reproduction of 3GPP TS 22.278, Fig. 7.1.4.1-1: Inter-PLMN handover with seamless service continuity within a 3GPP specified access system
Up

7.1.4.2  Service continuity at domain and RAT change for TS 11, TS 12 and equivalent PS servicep. 20

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
Up

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

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 Corep. 20

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.
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.
Up

7.1.4.4  Service continuity between 3GPP and WiMAX access on Evolved Packet Corep. 21

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.

7.1.5  Access network discoveryp. 21

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.
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.
Up

7.1.6  Steering of accessp. 21

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.
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.
Up

7.1.7  CS fallbackp. 22

7.1.7.1  Generalp. 22

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.
Up

7.1.7.2  Roaming in a VPLMN not supporting CS fallbackp. 22

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.
Up

7.1.8  Service Reachability |R12|p. 22

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.
Up

7.2  IFOM Service requirements |R10|p. 22

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.
    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:
    1. Policies per IP flow class under a specific APN.
    2. Policies per IP flow class under any APN.
    3. 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.
Up

Up   Top   ToC