3rd Generation Partnership Project;

Technical Specification Group Services and System Aspects;

3GPP TS 22.101
Service (2017-09)
V15.2.0 aspects;
Service principles
Technical Specification
(Release 15)

The present document has been developed within the 3 rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP.

The present document has not been subject to any approval process by the 3GPP Organisational Partners and shall not be implemented.
This Specification is provided for future development work within 3GPP only. The Organisational Partners accept no liability for any use of this
Specification.
Specifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organisational Partners' Publications Offices.
Release 15 2 3GPP TS 22.101 V15.2.0 (2017-09)

Keywords
UMTS, LTE, service

3GPP

Postal address

3GPP support office address

650 Route des Lucioles - Sophia Antipolis
Valbonne - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16

Internet
http://www.3gpp.org

Copyright Notification

No part may be reproduced except as authorized by written permission.

The copyright and the foregoing restriction extend to reproduction in all media.

© 2017, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC).
All rights reserved.

UMTS™ is a Trade Mark of ETSI registered for the benefit of its members
3GPP™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners
LTE™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners
GSM® and the GSM logo are registered and owned by the GSM Association

3GPP
Release 15 3 3GPP TS 22.101 V15.2.0 (2017-09)

Contents
Foreword.............................................................................................................................................. 8
1 Scope......................................................................................................................................... 9
2 References..................................................................................................................................9
2.1 Normative references........................................................................................................................ 10
2.2 Informative references....................................................................................................................... 12
3 Definitions and abbreviations....................................................................................................13
3.1 Definitions........................................................................................................................................ 13
3.2 Abbreviations.................................................................................................................................... 14
4 General.....................................................................................................................................15
4.1 Aims of 3GPP specifications............................................................................................................. 15
4.2 Standardisation of Service Capabilities..............................................................................................15
4.2.1 Provision of service capabilities in shared networks.....................................................................15
4.3 Efficient Use of Network Resources.................................................................................................. 15
4.3.1 Network Traffic Patterns.............................................................................................................. 15
4.3.2 Mass Simultaneous Registration................................................................................................... 16
4.3.3 Radio Interface............................................................................................................................ 16
4.3.4 Real-time Resource Usage........................................................................................................... 16
4.3.5 Selected IP Traffic Offload (SIPTO) for PS Domain only............................................................16
4.3.5.1 Common Requirements for SIPTO in the Mobile Operator Network and SIPTO at the Local
Network................................................................................................................................. 16
4.3.5.2 Requirements for SIPTO in the Mobile Operator Network......................................................17
4.3.6 Paging policy selection for LTE................................................................................................... 18
4.4 Compatibility with Global Standards................................................................................................. 18
4.5 Void.................................................................................................................................................. 18
4.6 Functionality of Serving Network and Home Environment................................................................18
4.7 PLMN Architecture........................................................................................................................... 19
4.8 Interworking Between PLMN and Wireless LANs............................................................................19
4.9 Network Sharing............................................................................................................................... 19
4.10 The Evolved Packet System.............................................................................................................. 19
4.11 User Data Convergence..................................................................................................................... 19
4.11.1 Introduction................................................................................................................................. 19
4.11.2 Management of user data............................................................................................................. 20
4.11.3 User Data Modelling.................................................................................................................... 20
5 Evolution..................................................................................................................................22
5.1 Support of 2G services...................................................................................................................... 22
5.2 Provision and evolution of services................................................................................................... 22
6 Classification of services...........................................................................................................23
7 Principles for new service capabilities.......................................................................................24
7.1 General............................................................................................................................................. 24
7.2 Multimedia........................................................................................................................................ 24
7.2.1 Circuit Switched (CS) multimedia calls.......................................................................................24
7.2.2 IP multimedia (IM) sessions......................................................................................................... 25
7.2.3 Multimedia Messaging Service (MMS)........................................................................................25
7.2.4 Real-Time Text Conversation...................................................................................................... 26
7.2.5 Packet Switched Streaming Service............................................................................................. 26
7.3 Service Management Requirements................................................................................................... 26
7.4 Automatic Device Detection............................................................................................................. 26

3GPP
Release 15 4 3GPP TS 22.101 V15.2.0 (2017-09)

8 Service architecture...................................................................................................................27
9 Quality of Service (QoS)...........................................................................................................28
10 Emergency Calls.......................................................................................................................29
10.1 General requirements........................................................................................................................ 29
10.1.1 Identification of emergency numbers...........................................................................................30
10.1.2 Domains priority and selection for UE attempts to emergency call...............................................31
10.1.2.1 Voice and GTT only............................................................................................................... 31
10.1.2.2 Other media............................................................................................................................ 31
10.1.3 Call-Back Requirements.............................................................................................................. 31
10.2 Emergency calls in the CS CN Domain............................................................................................. 31
10.3 Emergency Calls in the PS CN Domain.............................................................................................32
10.4 Emergency calls in the IM CN subsystem..........................................................................................32
10.4.1 General........................................................................................................................................ 32
10.4.2 IMS Multimedia Emergency Sessions..........................................................................................32
10.4.2.1 General................................................................................................................................... 32
10.4.2.2 UE Requirements................................................................................................................... 33
10.4.2.3 Originating Network Requirements.........................................................................................34
10.5 Void.................................................................................................................................................. 35
10.6 Location Availability for Emergency Calls........................................................................................35
10.7 Transfer of data during emergency calls............................................................................................ 35
10.8 Supplementary service interaction during emergency calls................................................................36
11 Numbering principles...............................................................................................................37
11.1 Number portability............................................................................................................................ 37
11.1.1 Requirements for CS CN domain................................................................................................. 37
11.1.2 Requirements for PS CN domain.................................................................................................. 37
11.1.3 Requirements for IM CN subsystem.............................................................................................37
11.2 Evolution path................................................................................................................................... 37
11.3 Void.................................................................................................................................................. 38
11.4 Void.................................................................................................................................................. 38
11.5 Void.................................................................................................................................................. 38
11.6 Private numbering............................................................................................................................. 38
11.7 Numbering schemes.......................................................................................................................... 38
11.7.1 Multiple numbering scheme......................................................................................................... 38
11.7.2 Single numbering scheme............................................................................................................ 38
11.7.3 Additional numbers...................................................................................................................... 38
11.8 Optimal routing................................................................................................................................. 38
11a Identification Requirements......................................................................................................39
11a.1 Subscriber Identification................................................................................................................... 39
11a.2 Terminal Identification...................................................................................................................... 39
11a.3 Home Environment / Serving Network Identification........................................................................39
11a.4 Serving Environment / Mobile Virtual Network Identification...........................................................39
12 Human Factors and user procedures..........................................................................................40
13 UICC, USIM and Terminal.......................................................................................................41
13.1 The USIM/ISIM and User Profiles.................................................................................................... 41
13.1.1 The USIM.................................................................................................................................... 41
13.1.2 User Profiles................................................................................................................................ 41
13.1.3 UICC usage in GERAN only Terminals.......................................................................................42
13.1.4 Multiple USIMs per UICC........................................................................................................... 42
13.1.5 The ISIM..................................................................................................................................... 42
13.2 The UICC......................................................................................................................................... 42
13.2.1 The UICC and Applications other than the USIM or ISIM...........................................................42
13.2.1a UICC applications and IMS....................................................................................................... 43
13.2.2 Fast Access and Retrieval of Data from UICC.............................................................................43
13.3 Terminals and Multiple UICCs.......................................................................................................... 43

3GPP
Release 15 5 3GPP TS 22.101 V15.2.0 (2017-09)

14 Types of features of UEs...........................................................................................................44

15 Relationship between subscription and service delivery.............................................................45
15.1 Subscription...................................................................................................................................... 45
15.2 Other concepts associated with services............................................................................................. 46
15.3 Requirements concerning service delivery.........................................................................................46
15.3.1 Mobile Originated Voice calls..................................................................................................... 47
15.3.2 Mobile Terminated Voice calls.................................................................................................... 47
16 Charging principles...................................................................................................................48
17 Roaming...................................................................................................................................49
17.1 Assumptions...................................................................................................................................... 49
17.2 Principle............................................................................................................................................ 49
17.3 Requirements.................................................................................................................................... 49
18 Handover Requirements............................................................................................................51
19 Network Selection....................................................................................................................52
20 Security....................................................................................................................................53
21 Voice Call Continuity...............................................................................................................54
21.1 General............................................................................................................................................. 54
21.2 Support of Supplementary Services................................................................................................... 54
21.2.1 Line Identification Services......................................................................................................... 54
21.2.2 All Call Forwardings.................................................................................................................... 54
21.2.3 Call Waiting................................................................................................................................ 55
21.2.4 Call Hold..................................................................................................................................... 55
21.2.5 Multiparty.................................................................................................................................... 55
21.2.6 All Call Barrings.......................................................................................................................... 55
21.2.7 Void............................................................................................................................................. 55
21.2.8 Void............................................................................................................................................. 55
21.2.9 All other Supplementary Services................................................................................................ 55
21.3 Quality of Service............................................................................................................................. 55
21.4 Security............................................................................................................................................. 55
21.5 Emergency calls................................................................................................................................ 55
21.6 Charging........................................................................................................................................... 56
21.7 VCC Activation................................................................................................................................ 56
22 IMS Centralized Services..........................................................................................................57
22.1 General............................................................................................................................................. 57
22.2 Service Consistency.......................................................................................................................... 57
22.3 Service Continuity............................................................................................................................. 57
22.4 IMS Services..................................................................................................................................... 57
22.5 Roaming Support.............................................................................................................................. 57
23 CS IP interconnection requirements..........................................................................................59
23.1 Introduction....................................................................................................................................... 59
23.2 IP interconnect.................................................................................................................................. 59
23.3 MSC server interconnect................................................................................................................... 59
24 Service Alignment & Migration................................................................................................60
24.1 Introduction....................................................................................................................................... 60
24.2 Alignment of supplementary services settings...................................................................................60
25 System optimisation for communication with specific characteristics........................................62
25.1 Void.................................................................................................................................................. 62
25.2 Numbering Resource Efficiency........................................................................................................ 62
25.3 Network provided destination for uplink data....................................................................................62
25.4 PS only subscriptions........................................................................................................................ 62
26 Single Sign-On (SSO) Service..................................................................................................63
26.1 Requirements.................................................................................................................................... 63
26.1.1 Requirements for the UE.............................................................................................................. 63
26.1.2 Requirements for a 3GPP SSO Service.........................................................................................63

3GPP
Release 15 6 3GPP TS 22.101 V15.2.0 (2017-09)

27 User plane congestion management...........................................................................................64

27.1 Introduction....................................................................................................................................... 64
27.2 General............................................................................................................................................. 64
27.3 Prioritizing traffic.............................................................................................................................. 64
27.4 Reducing traffic................................................................................................................................ 64
27.5 Void.................................................................................................................................................. 65
28 RAN Sharing Enhancements.....................................................................................................65
28.1 General............................................................................................................................................. 65
28.2 Specific E-UTRAN and NG-RAN Sharing requirements...................................................................65
28.2.1 Allocation of Shared E-UTRAN and NG-RAN resources.............................................................65
28.2.2 OA&M Access to the Shared E-UTRAN/NG-RAN......................................................................66
28.2.3 Generation and retrieval of usage and accounting information.....................................................66
28.2.4 MDT Collection........................................................................................................................... 66
28.2.5 PWS support of Shared E-UTRAN/NG-RAN...............................................................................66
28.2.6 Support for load balancing........................................................................................................... 67
28.2.7 Dynamic capacity negotiation...................................................................................................... 67
28.3 Specific GERAN & UTRAN Sharing Requirements..........................................................................67
28.3.1 Allocation of Shared GERAN or UTRAN Resources...................................................................67
28.3.2 OA&M Access to the Shared GERAN or UTRAN.......................................................................68
28.3.3 Generation and retrieval of usage and accounting information.....................................................68
28.3.4 MDT Collection........................................................................................................................... 69
28.3.5 PWS support of Shared GERAN or UTRAN................................................................................69
28.3.6 Support for load balancing........................................................................................................... 69
28.3.7 Dynamic capacity negotiation...................................................................................................... 69
29 Service exposure with 3rd party service providers.......................................................................70
29.1 General............................................................................................................................................. 70
29.2 Exposed Services and capabilities..................................................................................................... 70
30 Flexible Mobile Service Steering..............................................................................................72
30.1 Introduction....................................................................................................................................... 72
30.2 General Requirements....................................................................................................................... 73
31 Control of traffic from UE-based applications toward associated server.....................................74
31.1 Description........................................................................................................................................ 74
31.2 Requirements.................................................................................................................................... 74
31.2.1 Control requirements................................................................................................................... 74
31.2.2 Requirements on awareness of third party server issue.................................................................74
32 3GPP enhancement for TV application support.........................................................................74
32.1 Feature description............................................................................................................................ 74
32.2 Requirements.................................................................................................................................... 75
32.2.1 General requirements................................................................................................................... 75
32.2.2 Requirement for transmission performance enhancement.............................................................75
32.2.3 Requirement for network flexibility.............................................................................................76
32.2.4 Requirement for TV application support......................................................................................76
32.2.5 Requirement for RAN sharing...................................................................................................... 77
32.2.6 Requirement for wide area support............................................................................................... 77
32.2.7 Requirement for capability exposure............................................................................................ 77
32.2.8 Fixed reception for TV services................................................................................................... 77
33 Usage over unlicensed access....................................................................................................78
33.1 Description........................................................................................................................................ 78
33.2 Requirements.................................................................................................................................... 78
34 Restricted local operator services..............................................................................................78
34.1 Description........................................................................................................................................ 78
34.2 Requirements.................................................................................................................................... 78

Annex A (normative): Description of optional user equipment features..............................79

A.1 Display of called number................................................................................................................... 79
A.2 Indication of call progress signals...................................................................................................... 79
A.3 Country/PLMN indication................................................................................................................. 79

3GPP
Release 15 7 3GPP TS 22.101 V15.2.0 (2017-09)

A.4 Service Provider Name indication..................................................................................................... 79

A.4a Core Network Operator Name indication...........................................................................................80
A.5 Keypad.............................................................................................................................................. 80
A.6 Short message indication and acknowledgement...............................................................................80
A.7 Short message overflow indication.................................................................................................... 80
A.8 International access function............................................................................................................. 80
A.9 Service Indicator (SI)........................................................................................................................ 81
A.10 Dual Tone Multi Frequency (DTMF)................................................................................................. 81
A.11 On/Off switch.................................................................................................................................... 81
A.12 Sub-Address...................................................................................................................................... 81
A.13 Short Message Service Cell Broadcast...............................................................................................81
A.14 Short Message Service Cell Broadcast DRX......................................................................................81
A.15 Support of the extended Short message cell broadcast channel..........................................................81
A.16 Network Identity and Timezone........................................................................................................ 82
A.17 Network's indication of alerting in the UE.........................................................................................82
A.18 Network initiated Mobile Originated (MO) connection......................................................................83
A.19 Abbreviated dialling.......................................................................................................................... 83
A.20 Barring of Dialled Numbers.............................................................................................................. 84
A.21 DTMF control digits separator........................................................................................................... 84
A.22 Selection of directory number in messages........................................................................................85
A.23 Last Numbers Dialled (LND)............................................................................................................ 85
A.24 Service Dialling Numbers................................................................................................................. 85
A.25 Fixed number dialling....................................................................................................................... 85
A.26 Message Waiting Indication.............................................................................................................. 86
A.27 Transfer of eCall Minimum Set of Data (MSD).................................................................................86
A.27.1 General Requirements....................................................................................................................... 86
A.27.2 Requirements for the transfer of eCall MSD in a TS12 call...............................................................87
A.27.3 Requirements for the transfer of eCall data in an IMS emergency call...............................................87
A.27.4 Interworking requirements................................................................................................................. 88
A.27.5 Domain selection.............................................................................................................................. 88
A.28 Requirements for "In Case of Emergency" (ICE) information............................................................88

Annex B (informative): Additional number use case...............................................................91

Annex C (informative): Change history....................................................................................92

3GPP
Release 15 8 3GPP TS 22.101 V15.2.0 (2017-09)

Foreword
This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP).

The contents of the present document are subject to continuing work within the TSG and may change following
formal TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG
with an identifying change of release date and an increase in version number as follows:

Version x.y.z

where:

x the first digit:

1 presented to TSG for information;

2 presented to TSG for approval;

3 or greater indicates TSG approved document under change control.

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.

z the third digit is incremented when editorial only changes have been incorporated in the document.

3GPP
Release 15 9 3GPP TS 22.101 V15.2.0 (2017-09)

1 Scope
This Technical Specification (TS) describes the Service Principles for PLMNs specified by 3GPP. Principles and
requirements for interworking with WLAN are covered in TS 22.234 [35].

3GPP specifications provide integrated personal communications services. The system will support different
applications ranging from narrow-band to wide-band communications capability with integrated personal and
terminal mobility to meet the user and service requirements of the 21 st century.

3GPP specifications allow the realisation of a new generation of mobile communications technology for a world in
which personal communications services should allow person-to-person calling, independent of location, the terminal
used, the means of transmission (wired or wireless) and the choice of technology. Personal communication services
should be based on a combination of fixed and wireless/mobile services to form a seamless end-to-end service for the
user.

3GPP specifications should be in compliance with the following objectives:

a) to provide a single integrated system in which the user can access services in an easy to use and uniform way
in all environments;

b) to allow differentiation between service offerings of various serving networks and home environments;

c) to provide a wide range of telecommunications services including those provided by fixed networks and
requiring user bit rates of up to 100 Mbit/s as well as services special to mobile communications. These
services should be supported in residential, public and office environments and in areas of diverse population
densities. These services are provided with a quality comparable with that provided by fixed networks such as
ISDN and fixed broadband Internet access;

d) to provide services via hand held, portable, vehicular mounted, movable and fixed terminals (including those
which normally operate connected to fixed networks), in all environments (in different service environments -
residential, private domestic and different radio environments) provided that the terminal has the necessary
capabilities;

e) to provide support of roaming users by enabling users to access services provided by their home environment
in the same way even when roaming.

f) to provide audio, data, video and particularly multimedia services;

g) to provide for the flexible introduction of telecommunication services;

h) to provide within the residential environment the capability to enable a pedestrian user to access all services
normally provided by fixed networks;

i) to provide within the office environment the capability to enable a pedestrian user to access all services
normally provided by PBXs and LANs;

j) to provide a substitute for fixed networks in areas of diverse population densities, under conditions approved
by the appropriate national or regional regulatory authority.

k) to provide support for interfaces which allow the use of terminals normally connected to fixed networks.

2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.

 References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.

 For a specific reference, subsequent revisions do not apply.

3GPP
Release 15 10 3GPP TS 22.101 V15.2.0 (2017-09)

 For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document
(including a GSM document), a non-specific reference implicitly refers to the latest version of that document
in the same Release as the present document.

2.1 Normative references

[1] 3GPP TS 22.105 "Services and Service Capabilities"

[2] Void

[3] 3GPP TS 22.038: "(U)SIM Application Toolkit (USAT); Service description; Stage 1".

[4] 3GPP TS 22.001: "Principles of Circuit telecommunication services supported by a Public Land
Mobile Network (PLMN)".

[5] 3GPP TS 22.004: "General on supplementary services"

[6] 3GPP TS 22.030: "Man-Machine Interface (MMI) of the User Equipment (UE)"

[7] 3GPP TS 22.066: "Support of Mobile Number Portability (MNP); Service description; Stage 1"

[8] 3GPP TS 22.079: " Support of Optimal Routeing (SOR); Service definition; Stage 1".

[9] 3GPP TS 22.129: "Handover Requirements between UTRAN and GERAN or other Radio
Systems".

[10] 3GPP TS 33.102: "Security Architecture".

[11] 3GPP TS 22.011: "Service Accessibility".

[12] 3GPP TS 22.016: "International mobile Station Equipment Identities (IMEI)".

[13] 3GPP TS 24.008: "Mobile Radio Interface Layer 3 Specification".

[14] 3GPP TS 22.003: "Circuit Teleservices supported by a Public Land Mobile Network (PLMN)".

[15] 3GPP TS 21.133: "Security Threats and Requirements".

[16] 3GPP TS 33.120: "Security Principles".

[17] 3GPP TS 22.042: "Network Identity and Time Zone, Service Description, Stage 1".

[18] 3GPP TS 42.009: "Security Aspects".

[19] 3GPP TS 31.102: "USIM Application Characteristics".

[20] 3GPP TS 23.221 "Architectural Requirements".

[21] 3GPP TS 22.002: "Circuit Bearer Services (BS) supported by a Public Land Mobile Network
(PLMN)".

[22] 3GPP TS 22.060: "General Packet Radio Service (GPRS) ; Service description; Stage 1".

[23] 3GPP TS 29.002: "Mobile Application Part (MAP) specification".

[24] 3GPP TR 23.972: "Circuit switched multimedia telephony".

[25] 3GPP TS 22.140: " Multimedia Messaging Service (MMS); Stage 1".

[26] 3GPP TS 22.226: "Global Text Telephony, Stage 1".

[27] 3GPP TS 22.228: " Service requirements for the Internet Protocol (IP) multimedia core network
subsystem (IMS); Stage 1".

[28] RFC 3261: "SIP: Session Initiation Protocol".

[29] 3GPP TR 21.905: " Vocabulary for 3GPP Specifications".

3GPP
Release 15 11 3GPP TS 22.101 V15.2.0 (2017-09)

[30] 3GPP TS 26.233: "Packet Switched Streaming Service (PSS) ; General Description".

[31] 3GPP TS 26.234: "Packet Switched Streaming Service (PSS) ; Protocols and Codecs".

[32] 3GPP TR 22.934: "Feasibility study on 3GPP system to Wireless LAN (WLAN) interworking".

[33] RFC 2486: "The Network Access Identifier".

[34] 3GPP TS 51.011: "Specification of the Subscriber Identity Module - Mobile Equipment (SIM-
ME) interface Release 4)".

[35] 3GPP TS 22.234: "Requirements on 3GPP system to wireless local area network (WLAN)
interworking".

[36] 3GPP TS 31.101: "UICC-terminal interface; Physical and logical characteristics".

[37] OMA Device Management V1.2 specifications

[38] OMA Client Provisioning V1.1 specifications

[39] void

[40] 3GPP TS 22.173: " IP Multimedia Core Network Subsystem (IMS) Multimedia Telephony
Service and supplementary services; Stage 1".

[41] 3GPP TS 22.082: "Call Forwarding (CF) supplementary services - Stage 1".

[42] 3GPP TS 22.278: "Service Requirements for the Evolved Packet System (EPS)".

[44] 3GPP TS 22.071: "Location Services (LCS); Service description; Stage 1".

[45] 3GPP TR 22.985: "Service requirement for the 3GPP User Data Convergence (UDC), Release
9".

[46] EN 15722:2015 "Intelligent transport systems - eSafety - eCall minimum set of data (MSD)"

[47] 3GPP TS 23.226: "Global text telephony (GTT); Stage 2"

[48] 3GPP TS 22.220: " Service requirements for Home Node B (HNB) and Home eNode B (HeNB)
".

[49] ETSI TS 181 019 V2.0.0 (2007-11): "Telecommunications and Internet converged Services and
Protocols for Advanced Networking (TISPAN); Business Communication Requirements".

[50] 3GPP TS 23.335: "User Data Convergence (UDC); Technical realization and information flows;
stage 2".

[51] OpenID Foundation: "OpenID Authentication 2.0", http://openid.net/specs/openid-

authentication-2_0.html.

[52] 3GPP TS 22.368: "Service requirements for Machine-Type Communications (MTC); Stage 1".

[53] OMA Presence API: "OMA-TS-REST_NetAPI_Presence-V1_0-20130212-C".

[54] IETF RFC-5491: "GEOPRIV Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations".

[55] IETF RFC-5139: "Revised Civic Location Format for Presence Information Data Format
Location Object (PIDF-LO)".

[56] 3GPP TS 23.032: "Universal Geographical Area Description (GAD)".

[57] 3GPP TS 23.402: "Architecture enhancements for non-3GPP accesses".

3GPP
Release 15 12 3GPP TS 22.101 V15.2.0 (2017-09)

2.2 Informative references

[43] GSMA PRD IR.34: "Inter-Service Provider IP Backbone Guidelines"

[58] ETSI TR 103.140 V1.1.1 (2014-04): "eCall for VoIP"

[59] Code of Federal Regulations (CFR) Title 47; https://www.fcc.gov/general/rules-regulations-title-

47

3GPP
Release 15 13 3GPP TS 22.101 V15.2.0 (2017-09)

3 Definitions and abbreviations

3.1 Definitions
For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply.
A term defined in the present document takes precedence over the definition of the same term, if any, in
TR 21.905 [1].

3GPP SSO Authentication: Authentication performed between an SSO-capable UE and 3GPP SSO Identity Provider
using Operator-controlled credentials and without requiring user involvement.

3GPP SSO Identity Provider: An entity that maintains Operator-controlled identity and credential information for a
user, performs 3GPP SSO Authentication, and asserts the user's identity to a Data Application Provider.

3rd Party SSO Identity Provider: An entity that maintains identity and credential information (that is not Operator-
controlled) for a user, performs authentication, and asserts the user's identity to a Data Application Provider.

Attended Data Traffic: Data traffic of which the user is aware he/she initiated, e.g. based on the screen/keypad lock
being deactivated, length of time since the UE last received any input from the user, known type of application (e.g.
an application monitoring a user's health – "mHealth" – which may need its data always treated as Attended Data
Traffic.)

eCall: A manually or automatically initiated emergency call (TS12 or IMS emergency call), from a vehicle,
supplemented with a minimum set of emergency related data (MSD).

Data Application Provider: An entity that offers data application services to users (e.g., over the public Internet).
The data applications can be browser or non-browser based services.

E-UTRAN Sharing: The sharing of E-UTRAN among a number of operators.

Free-to-air (FTA) TV: A TV service characterised by no content encryption and being made available at no
additional cost to the end user.

Free-to-view (FTV) TV: A TV service characterised by optional content encryption and being made available at no
additional cost to the end user.

GERAN or UTRAN Sharing: The sharing of GERAN or UTRAN among a number of operators.

Hosting E-UTRAN Operator: The Operator that has operational control of a Shared E-UTRAN.With regard to
management of the Shared E-UTRAN the Hosting E-UTRAN Operator is a Master Operator [29].

Hosting RAN: The Shared RAN that is owned or controlled by the Hosting RAN Operator.

Hosting RAN Operator: The Operator that has operational control of a Shared E-UTRAN, UTRAN or GERAN

IMS Centralized Services: The provision of communication services wherein services and service control are based
on IMS mechanisms and enablers, and support is provided for a diversity of access networks (including CS domain
and IP based, wireless and wireline), and for service continuity between access networks.

MSD: The Minimum Set of Data [46] forming the data component of an eCall sent from a vehicle to a Public Safety
Answering Point or other designated emergency call centre. The MSD has a maximum size of 140 bytes and includes,
for example, vehicle identity, location information and time-stamp.

NG-RAN: A radio access network connecting to the 5G core network which uses NR, E-UTRA, or both.

Participating Operator: Authorized operator that is sharing E-UTRAN, UTRAN or GERAN resources provided by a
Hosting RAN Operator
RAN user plane congestion: The situation where the demand for RAN resources to transfer user data exceeds the
available RAN capacity to deliver the user data for a significant period of time in the order of few seconds or longer.
(S)Gi-LAN: The network infrastructure connecting to 3GPP network over the SGi or Gi reference point that provides
various IP-based services (e.g. NAT, antimalware, parental control, DDoS protection, video optimization).

3GPP
Release 15 14 3GPP TS 22.101 V15.2.0 (2017-09)

Shared E-UTRAN: E-UTRAN that is shared among a number of operators.

Shared RAN: GERAN, UTRAN or E-UTRAN that is shared among a number of operators.

Shared GERAN or UTRAN: GERAN or UTRAN that is shared among a number of operators.

SSO Provider: An entity that provides SSO Service. The SSO Provider enables a user to authenticate to an IdP and
thereby to have their identity asserted to a DAP. Each data application, whether provided by different DAPs or the
same DAP, may have its own policy regarding authentication. In the 3GPP SSO Service, the SSO Provider is the
3GPP Operator.

SSO Service: A service in which the user of a data application is authenticated once, and as a result of that
authentication is provided with seamless and transparent access to multiple data applications offered by one or more
Data Application Providers.

SSO Local User Authentication: Authentication performed by the UE that establishes the presence of the registered
user of the data application by requiring input which only the registered user would be able to provide.

Subscribed TV service: A TV service which is characterised by requiring a subscription (to content owner, content
provider, or MNO) in order to access the service.

Unattended Data Traffic: Data traffic of which the user is unaware he/she initiated, e.g. based on the screen/keypad
lock being activated, length of time since the UE last received any input from the user, known type of app (e.g. an
application monitoring a user's health – "mHealth" – may need its data never treated as Unattended Data Traffic.)

Further definitions are given in 3GPP TR 21.905 [29].

3.2 Abbreviations
For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply.
An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if
any, in TR 21.905 [1].

DAP Data Application Provider

IdP Identity Provider
IVS In Vehicle System (eCall terminal and associated sub-systems in vehicle)
ME Mobile Equipment
OTT Over The Top
PC Personal Computer
SSO Single Sign-On

3GPP
Release 15 15 3GPP TS 22.101 V15.2.0 (2017-09)

4 General

4.1 Aims of 3GPP specifications

It shall be capable of delivering audio, text, video and graphics direct to people and provide them with access to the
next generation of information based services. It moves mobile and personal communications forward from existing
systems, delivering mass market low-cost digital telecommunication and IP-based multimedia services.

The aims are:

- to enable users to access a wide range of telecommunications services, including many that are today
undefined as well as multi-media and high data rates.

- to facilitate the provision of a high quality of service (particularly speech quality) similar to that provided by
fixed networks;

- to facilitate the provision of small, easy to use, low cost terminals with long talk time and long standby
operation;

- to provide an efficient means of using network resources (particularly radio spectrum).

4.2 Standardisation of Service Capabilities

Existing systems have traditionally standardised the complete sets of teleservices, applications and supplementary
services which they provide. As a consequence, substantial efforts are often required to introduce new services or
simply to modify the existing one (customisation). This makes it more difficult for operators to differentiate their
services. At the same time however, this may reduce the complexity of providing a service across different operators'
networks.

3GPP shall therefore preferentially standardise service capabilities. In circumstances where the service is meant to be
used across different operators' networks, hence a common specification set is of paramount importance, the service
should be standardised to a level of detail sufficient to ensure interoperability and interworking across different
operators' networks. Service capabilities consist of bearers defined by QoS parameters and the mechanisms needed to
realise services. These mechanisms include the functionality provided by various network elements, the
communication between them and the storage of associated data. This TS provides a conceptual description of a
service architecture and architecture requirements which aim to provide service capabilities. It is intended that these
standardised capabilities should provide a defined platform which will enable the support of speech, video, multi-
media, messaging, data, teleservices, user applications and supplementary services and enable the market for services
to be determined by users and home environments.

4.2.1 Provision of service capabilities in shared networks

The provision of services and service capabilities that is possible to offer in a network shall not be restricted by the
existence of the network sharing It shall be possible for a core network operator to differentiate its service offering
from other core network operators within the shared network.

It shall be possible to control the access to service capabilities offered by a shared network according to the core
network operator the user is subscribed to.

4.3 Efficient Use of Network Resources

4.3.1 Network Traffic Patterns
Service capabilities shall take account of the discontinuous and asymmetric nature of most teleservices, multimedia
services and user applications and consider the overheads and signalling surge caused by frequent transmissions of
small amount of data by mobile data application, in order to make efficient use of network resources (particularly
radio resources).

3GPP
Release 15 16 3GPP TS 22.101 V15.2.0 (2017-09)

4.3.2 Mass Simultaneous Registration

When a large number of subscribers enter in a registration area in which they have not registered, the core and radio
access network shall be able to provide a capability to optimize the mass simultaneous registration traffic at a given
instance of time. The core and radio access network shall be able to keep providing the service (e.g. mobile
originated and mobile terminated services) without interruption for those subscribers who are originally in the cell
which receive the mass simultaneous registration traffic.

4.3.3 Radio Interface

Service capabilities shall be provided in a wide range of radio operating environments (where a radio environment is
characterised in terms of propagation environment, mobile equipment relative speeds and traffic characteristics).
Although 3GPP aims to minimise the number of radio interfaces and to maximise commonality between them, it may
utilise several radio interfaces, each optimised for different environments. Each radio interface may provide differing
service capabilities. 3GPP specifications include UTRA(N) radio interface supporting two modes (TDD and FDD), an
Evolved UTRA(N) radio interface and GERAN radio interface. Additionally, it may be possible to connect to the
3GPP system using radio interfaces and fixed access technologies specified outside of 3GPP.

3GPP specifications shall provide a mechanism which will enable a piece of user equipment (UE) to adapt to
different radio interfaces as necessary and to determine the service capabilities available. The specifications shall also
provide a mechanism which will enable a UE to select radio interfaces capable of providing appropriate service
capabilities and support mobility between multiple radio interfaces.

4.3.4 Real-time Resource Usage

To enable network operators to render services efficiently, dimension their networks and set tariffs that more
accurately reflect radio resource usage, real time information on resource usage is needed. When requested, it shall be
possible for the serving cell type (e.g. RAT), cell ID / UTRAN Service Area Identity and cell / Service Area
capability usage (e.g. HSDPA, E-DCH) information to be made available to the core network. Cell / Service Area
capability usage information may include, for example, user(s) identity, start and finish time of data transfer, up-link
and down-link data rates, volumes of data and other statistical information.

4.3.5 Selected IP Traffic Offload (SIPTO) for PS Domain only

4.3.5.1 Common Requirements for SIPTO in the Mobile Operator Network and
SIPTO at the Local Network
The 3GPP system shall be able to offload selected traffic (e.g. internet) towards a defined IP network close to the
UE's point of attachment to the access network.

The following requirements apply to Selected IP Traffic Offload:

- The mobile operator may enable/disable Selected IP Traffic Offload on a per UE per defined IP network basis
(e.g. based on tariff, subscription type etc.).

- It shall be possible for IP traffic of a UE associated with a particular defined IP network to be offloaded while
IP traffic of that same UE associated with other defined IP network(s) is not offloaded.

- It shall be possible to perform Selected IP Traffic Offload for pre-Release 10 UEs.

- Offloading selected IP traffic for a UE shall not affect services running in parallel for the same UE.

- The mobile operator shall be able to collect signalling performance measurements (e.g. session
connection/disconnection, etc) related to Selected IP Traffic Offload for each user.

- Selected IP Traffic Offload shall not compromise the security of the mobile operator's network.

- Service Continuity of IP data session(s) for Selected IP Traffic Offload may be supported during the following
mobility events:

- mobility between the macro network and H(e)NBs; and

3GPP
Release 15 17 3GPP TS 22.101 V15.2.0 (2017-09)

- mobility between H(e)NBs.

During both these mobility events, based on home mobile operator policies, the impact of mobility events
as perceived by the user shall be reduced by minimising any interruption to the data flow.

- It shall be possible for the HPLMN to provide the VPLMN with the following information for a particular
user:

- An indication of whether the user's IP traffic is permitted to be subjected to Selected IP Traffic Offload
in the visited network;

- The defined IP network(s) for which Selected IP Traffic Offload is permitted.

Requirements specific to SIPTO at the local residential/enterprise IP network can be found in section 5.9 in [48].

Some types of services (e.g. streaming services, VOIP, VPN, HTTPS-Based Services) cannot tolerate a change of IP
address of the UE without disruption of the service.

SIPTO can be performed with or without coordination between the UE and the network. The following requirements
apply to coordinated SIPTO:

- The 3GPP system shall be able to support multiple connections that are associated with the same defined IP
network where each connection may or may not support IP address preservation.

- The 3GPP system shall be able to determine if an IP flow requires IP address preservation or not. Based on this
determination, the 3GPP network shall be able to offload selected IP traffic in coordinated manner between
UE and the network, in order to minimize service disruption.

- The 3GPP system shall be able to detect when a connection becomes suboptimal and decide when to establish
a new optimal connection to the same defined IP network or use an existing connection.

Note 1: The definition of optimal and suboptimal can be based on a number of implementation criteria like
geography, topology and load balancing etc.

- The 3GPP system shall minimize the number of connections of a UE without disrupting the UE’s services, e.g.
to ensure economical use of network resources.

- The 3GPP system shall be able to ensure that the actual average aggregate bit rate for IP flows of packet data
network connections associated with the same packet data network does not significantly exceed the
subscribed aggregate maximum bit rate for this packet data network when two connections are used with the
same defined IP network.

Note 2: Requirements for Coordinated SIPTO do not apply to IMS.

4.3.5.2 Requirements for SIPTO in the Mobile Operator Network

The following requirements apply to Selected IP Traffic Offload in the mobile operator network:

- The mobile operator shall be able to enable/disable Selected IP Traffic Offload for certain parts of the
network.

- Selected IP Traffic Offload shall not compromise integrity and confidentiality of offloaded traffic.

- The mobile operator shall be able to collect statistics for the offloaded traffic for each user.

- The network shall be able to perform Selected IP Traffic Offload without any user interaction based on mobile
operator policies.

- Service Continuity of IP data session(s) within the mobile operator network shall be supported for Selected IP
Traffic Offload. Based on home mobile operator policies, the impact of mobility events within the macro
network as perceived by the user shall be reduced by either:

- minimising any interruption to the data flow; or

- preventing interruption to the data flow e.g. for voice services.

3GPP
Release 15 18 3GPP TS 22.101 V15.2.0 (2017-09)

- Service Continuity of IP data session(s) for Selected IP Traffic Offload may be supported during the following
mobility events:

- mobility between the macro network and H(e)NBs; and

- mobility between H(e)NBs.

During both these mobility events, based on home mobile operator policies, the impact of mobility events as
perceived by the user shall be reduced by preventing interruption to the data flow e.g. for voice services.

4.3.6 Paging policy selection for LTE

The 3GPP core network shall be able to use these additional criteria for selecting a paging policy:

- mobility information on the UE (e.g. the UE is stationary, or moving only in a specified area)

- application characteristics that are known and trusted at the serving network (e.g. communication pattern,
expected QoS (e.g. latency, reliability), and priority)

- likely location of the UE within the paging area

4.4 Compatibility with Global Standards

3GPP specifications aim to be compatible with IMT-2000 and to provide global terminal mobility (roaming),
enabling the user to take his/her terminal to different regions of the world and to be provided with services. It is
probable that different regions of the world will adopt different radio interface technologies. IMT-2000, as a global
standard, should therefore enable a IMT-2000 terminal to determine the radio interface technology and the radio
interface standard used in a region. Global terminal roaming also requires the global standardisation of service
capabilities. As far as possible the method of indication of the radio interface standard and available service
capabilities shall be aligned with IMT-2000.

3GPP specifications shall enable users to access the services provided by their home environment in the same way via
any serving network provided the necessary service capabilities are available in the serving network.

The 3GPP specifications will be available for the partner organisations to adopt as their regional standards. For
example in Europe, ETSI may adopt them as standards for both GSM and UMTS.

4.5 Void

4.6 Functionality of Serving Network and Home Environment

The following functionality shall be the responsibility of the home environment:

- User Authentication.

- SIM/USIM Issue.

- Billing.

- User Profile/VHE Management.

The following functionality shall be the responsibility of the serving network:

- Radio or other means of access.

- Transport and signalling.

The following functionality may be the responsibility of either the serving network, the home environment or an
appropriate combination of both

- Service Control.

3GPP
Release 15 19 3GPP TS 22.101 V15.2.0 (2017-09)

- QoS negotiation.

- Mobility management, including roaming.

- Automatic establishment of roaming agreements.

4.7 PLMN Architecture

The network is logically divided into a radio access network and a core network, connected via an open interface.
From a functional point of view the core network is divided into a Packet Switched CN Domain, IP Multimedia (IM)
CN subsystem [27] and a Circuit Switched CN Domain. IM CN subsystem utilises PS CN domain bearer services.

CS CN domain supports bearer independent transport. There is no difference in service offering or UE functionality
due to different transport.

A PS only 3GPP core network is possible as defined within the specification for the Evolved Packet System (EPS)
[42].

For further information see 3GPP TS 23.221 [20].

4.8 Interworking Between PLMN and Wireless LANs

Aspects related to interworking between PLMN and WLAN are captured in TS 22.234 [35].

4.9 Network Sharing

Network sharing shall be transparent to the user.

The specifications shall support both the sharing of:

(i) radio access network only;

(ii) radio access network and core network entities connected to radio access network

Note: In a normal deployment scenario only one or the other option will be implemented.

It shall be possible to support different mobility management rules, service capabilities and access rights as a function
of the home PLMN of the subscribers.

4.10 The Evolved Packet System

Evolved Packet System is an evolution of the 3G UMTS characterized by higher-data-rate, lower-latency, packet-
optimized system that supports multiple RATs. The Evolved Packet System comprises the Evolved Packet Core
together with the evolved radio access network (E-UTRA and E-UTRAN).The service requirements for the Evolved
Packet System are specified in TS22.278 [42].

4.11 User Data Convergence

4.11.1 Introduction
The UDC concept [45] supports a layered architecture, separating the data from the application logic in the 3GPP
system, so that user data is stored in a logically unique repository allowing access from core and service layer
entities, named application front-ends. And such unique repository shall be possible to be shared among different
PLMNs that have trusted relationships.

Network elements and functionalities should be designed to access profile data remotely and without storing them
permanently locally, i.e. the front-ends shall work in a subscriber dataless configuration.

In some cases, services may depend on user data scattered over UDC and other network elements. UDC may support

3GPP
Release 15 20 3GPP TS 22.101 V15.2.0 (2017-09)

the ability to access necessary network elements to fetch user data on behalf of these services, while minimizing
impacts on existing Network Elements in which the data is located.

Applications can subscribe to specific events which will likely occur on specific user data, and those should be
notified when those events do appear. The events can be changes on existing user data, addition of user data, and so
on.

Third party applications and non trusted network elements should only be able to access the user data after proper
authentication and authorization taking into account security and privacy requirements, i.e. it should be possible to
present different views on the data to the parties which require access, dependent on the authorization. UDC concept
is backwards compatible with 3GPP systems, i.e. it does not have an impact on traffic mechanisms, reference points
and protocols of existing network elements.

The UDC concept preserves user authentication and authorization of services across domains, ensuring secured users'
access to network.

4.11.2 Management of user data

Due to the logical centralization of user data, it is necessary for UDC to support the provisioning of the user data, that
is, user data manipulation like creation, deletion, reading, modification and other operations. Provisioning shall be
possible via an external system, self care or dynamically via applications offering e.g. user service configuration
facilities.

Operations carried out in the framework of UDC shall support the ACID (Atomicity, Consistency, Isolation, and
Durability) characteristics.

4.11.3 User Data Modelling

User Data Modelling refers to the different models that apply to user data convergence: Information Models and Data
Models.

An Information Model denotes an abstract, formal representation of entity types, including their properties and
relationships, the operations (e.g. read, write…) that can be performed on them, and related rules and constraints. In
the information model, entities might have network topology relationship with each other.

In order to accommodate multiple applications and services, existing and new ones, a common baseline information
model shall be developed and shall, at minimum, clearly distinguish a number of concepts as entity types:

- Subscriber with relation to several users (e.g. a company and its employees),

- A user attached to different subscriptions (e.g. for a private and a professional service usage)

- A user using multiple devices (e.g. mobiles or fixed)

- Grouping of users to certain categories

- A particular user as member of a certain group

- Service providers' services provided by network operators

- Enterprise services provided by network operators

The baseline information model shall be future proof. It shall not be tied to any specific implementation of the data
base or its interfaces. It shall provide flexibility (in its data structure and content), extensibility and multi-application
approach.

By extensible, it shall be understood that new applications and/or new service profiles can be added by the operator,
if necessary. The flexibility shall permit new data for existing applications to be introduced, or modified.

Data Models are practical implementations of the information model, e.g. Tree-like modelling. The common
information model shall allow deriving one or more data models. A reference data model shall be standardized for the
message exchange over Ud interface [50], in order to enable multivendor interoperability.

Each application shall only interface the UDC for the data it is dealing with, and not be impacted by other data that
UDC stores for other applications. It corresponds to the concept of a data view specific to a given application.

3GPP
Release 15 21 3GPP TS 22.101 V15.2.0 (2017-09)

An application can allow access by other applications to data for which it is responsible. This can be done under
certain constraint customized by operators.

Access to the UDC data shall be independent of the structure of the data models, i.e. the changes in the data models
shall not affect the interface.

3GPP
Release 15 22 3GPP TS 22.101 V15.2.0 (2017-09)

5 Evolution

5.1 Support of 2G services

The 3GPP specifications shall be capable of supporting existing 2G services in a manner which is transparent to the
users of these services.

5.2 Provision and evolution of services

Since a phased approach has been adopted, the same general service principles shall apply to each phase. Support of
services from an end user perspective is understood to be an important driver for established mobile users to stay with
their existing operator while taking the new services into use. It is therefore important to enable operators to offer
continued support of legacy services in future releases. Previous release services shall as a principle also be supported
in the following releases.

Networks shall be capable of providing a specified core set of capabilities.

The core set of capabilities should permit home environment to offer a range of distinctive services including those
which cannot be implemented on systems based on previous release specifications.

It shall be possible for the home environment to develop services with full roaming capability.

The radio interface should not unnecessarily restrict the development of new services (within physical limitations).

The standard shall provide a mechanism which allows a terminal to be easily upgraded so that it can access new
services which are within the physical limitations of the terminal.

3GPP
Release 15 23 3GPP TS 22.101 V15.2.0 (2017-09)

6 Classification of services
In the CS CN domain, the basic services are divided into circuit teleservices (3GPP TS 22.003 [14]) and bearer
services (3GPP TS 22.002 [21]) and they can utilise standardised supplementary services (3GPP TS 22.004 [5]).

The PS CN Domain provides IP bearer services. SMS, USSD and UUS can also be considered as bearer services for
some applications.

IP multimedia services are the IP based session related services, including voice communications. IP multimedia
sessions use IP bearer services provided by the PS CN Domain.

Value added non-call related services include a large variety of different operator specific services/applications. They
are usually not specified by 3GPP. The services can be based on fully proprietary protocols or standardised protocols
outside 3GPP.

In order to create or modify the above services (both call and non-call related services) operators may utilise toolkits
standardised by 3GPP (such as CAMEL or LCS) or external solutions (e.g. Internet mechanisms). Pre-paid is an
example of an application created with toolkits that may apply to all of the above services categories.

Figure 1: Service classification

3GPP
Release 15 24 3GPP TS 22.101 V15.2.0 (2017-09)

7 Principles for new service capabilities

7.1 General
3GPP specifications shall enable the user of a single terminal to establish and maintain several connections
simultaneously. It shall efficiently cater for applications which have variable requirements relating to specific QoS
parameters (e.g. throughput) whilst meeting other QoS targets. It shall also cater for applications which are able to
take adapt to a range of variations in QoS.

7.2 Multimedia
3GPP specifications shall support development of multimedia services and provide the necessary capabilities.

Multimedia services combine two or more media components (e.g. voice, audio, data, video, pictures, text) within
one call. A multimedia service may involve several parties and connections (different parties may provide different
media components) and therefore flexibility is required in order to add and delete both resources and parties.

Multimedia services are typically classified as interactive or distribution services.

Interactive services are typically subdivided into conversational, messaging and retrieval services:

Conversational services are real time (no store and forward), usually bi-directional where low end to end delays (<
100 ms) and a high degree of synchronisation between media components (implying low delay variation) are
required. Video telephony and video conferencing are typical conversational services."

Messaging services offer user to user communication via store and forward units (mailbox or message handling
devices). Messaging services might typically provide combined voice and text, audio and high-resolution images.

Retrieval services enable a user to retrieve information stored in one or many information centres. The start at which
an information sequence is sent by an information centre to the user is under control of the user. Each information
centre accessed may provide a different media component, e.g. high resolution images, audio and general archival
information.

Distribution services are typically subdivided into those providing user presentation control and those without user
presentation control.

Distribution services without user control are broadcast services where information is supplied by a central source and
where the user can access the flow of information without any ability to control the start or order of presentation e.g.
television or audio broadcast services.

Distribution services with user control are broadcast services where information is broadcast as a repetitive sequence
and the ability to access sequence numbering allocated to frames of information enables the user (or the user's
terminal) to control the start and order of presentation of information.

7.2.1 Circuit Switched (CS) multimedia calls

CS multimedia call is a Bearer Service which utilises Synchronous Transparent Data service. The following basic
requirements shall be supported for CS multimedia calls [24]:

- CS multimedia call shall be based on a 3GPP specific subset of H.324M.

- All call scenarios shall be supported, i.e. Mobile Originating and Mobile Terminating call against Mobile,
ISDN and PSTN call party.

- Single and multiple numbering schemes shall be supported.

- Fallback to speech (TS 11 [14]) shall be supported from 3.1kHz Ext. PLMN multimedia bearer, i.e. if setup of
the multimedia call fails the call will be set up as a speech call.

- Service change and fallback shall be supported for UDI/RDI multimedia bearer and speech, to allow fallback

3GPP
Release 15 25 3GPP TS 22.101 V15.2.0 (2017-09)

to a less preferred service if the preferred service is unsupported, and to change the service between speech
and multimedia during the call.

- In the case where a CS multimedia call includes speech (e.g. video call) then the following requirements
apply:

- A user shall be able to change between a speech and CS multimedia call, when desired.

- When the CS multimedia call is no longer supported, for example due to degraded coverage conditions
(including UTRAN to GERAN only transitions), service change shall occur automatically from a CS
multimedia call to speech.

- When a CS multimedia call can be supported, for example due to improved coverage conditions (including
GERAN only to UTRAN or UTRAN/GERAN transitions), service change back to the CS multimedia call
may be initiated by the network.

- Other services than CS multimedia call may exist which utilise the Synchronous Transparent Data service.
Service transition to/from speech described for CS multimedia call in this clause shall only apply to CS
multimedia call and not Synchronous Transparent Data services in general.

- Different bitrates as specified at 3GPP TS 22.002 [21] shall be supported.

- Supplementary services apply to multimedia calls as for Synchronous Transparent Data service according to
3GPP TS 22.004[5].

- When accepting a multimedia call, the user shall be able to request a service change to speech before the call
is answered, such that the multimedia path is never actually connected through to the user's phone.

- The user shall be able to deny a service change to multimedia during the call.

7.2.2 IP multimedia (IM) sessions

IP multimedia services are not the evolution of the circuit switched services but represent a new category of services,
mobile terminals, services capabilities, and user expectations. Any new multimedia service, which may have a similar
name or functionality to a comparable standardised service, does not necessarily have to have the same look and feel
from the user's perspective of the standardised service. Voice communications (IP telephony) is one example of real-
time service that would be provided as an IP multimedia application.

The following basic requirements are be supported for IP multimedia [27]:

- IP multimedia session control shall be based on SIP [28].

- All session scenarios shall be supported; i.e. Mobile Originating and Mobile Terminating sessions against
Internet/Intranet, CS or IM Mobile, ISDN, PSTN call party.

- MSISDN and SIP URL numbering and addressing schemes shall be supported.

- IP multimedia applications shall as a principle, not be standardised, allowing service provider specific
variations.

7.2.3 Multimedia Messaging Service (MMS)

The following basic requirements are be supported for MMS:

- Store-and-forward multimedia messaging service with mobile and non-mobile users [25].

- MMS shall be capable of supporting integration of different types of messaging (e.g. fax, SMS, Multimedia,
voicemail, e-mail etc.) in a consistent manner.

- Streamed and batch delivery for both message download from the network to the terminal, and messages
upload from the terminal to the network.

3GPP
Release 15 26 3GPP TS 22.101 V15.2.0 (2017-09)

7.2.4 Real-Time Text Conversation

Real-Time Text (RTT) conversation is a service enabled in 3GPP networks by the Global Text Telephony ( GTT )
[26].

- GTT enables real time, character by character, text conversation to be included in any conversational service,
Circuit Switched as well as IP based.

- It is possible to use the text component in a session together with other media components, especially video
and voice.

- Interworking with existing text telephony in PSTN as well as emerging forms of standardised text conversation
in all networks is within the scope of this feature.

- The text media component can be included initially in the session, or added at any stage during the session.

- The text component is intended for human input and reading, and therefore supports human capabilities in text
input speed. The character set support is suitable for the languages the users communicate in.

- GTT specifies limited interoperation with Multimedia Messaging Services including a possibility to divert to
messaging in case of call failure and sharing user interface equipment and external UE interfaces.

7.2.5 Packet Switched Streaming Service

The following basic requirements are to be supported for streaming :

- The streaming service uses a client / server model which is transparent to the PLMN. The client controls the
initiation and execution of the service.

- The streaming service [30] shall use existing standards (codecs and protocols [31]) where these are available.

- The streaming service utilises the PS Domain with the QoS requirements as specified in 3GPP TS 22.105 [1].

7.3 Service Management Requirements

3GPP specifications shall include standardised protocols enabling service management. It shall enable control,
creation and subscription of service capabilities and services, and the management of user profiles.

7.4 Automatic Device Detection

The home environment should be automatically notified when a user, identified by a SIM/USIM, has changed ME
and should be informed of the identity of the new ME. This should be applicable to any ME. It should also be
possible to achieve Automatic Device Detection for users using any SIM/USIM.

Note: The purpose of this is to enable an automatic configuration of terminals by the operator for specific
applications/services if so needed. The procedure for such an automatic configuration need not to be
standardized by 3GPP.

The notification that a user has changed ME shall be given as early as possible.

3GPP
Release 15 27 3GPP TS 22.101 V15.2.0 (2017-09)

8 Service architecture
In order to provide standardisation of service capabilities a service architecture shown by Figure 2 is envisaged

Figure 2: Service Architecture

A number of bearers shall be provided that can differ in flexibility and offer different capabilities. Bearers may be
characterised by parameters such as "throughput", "delay tolerance", "maximum bit error rate", "symmetry" etc.
These bearers enable information to be transferred appropriate to the provision of teleservices, multimedia services
and end user applications generally, via subnetworks which typically provide different specified qualities of service.

The assignment and release of bearers is provided by the bearer control function. Provision should be made for
several bearers to be associated with a call and for bearers to be added to a call and/or to be released from a call
following call establishment. The bearers should be independent of radio environments, radio interface technology
and fixed wire transmission systems.

Adaptation/Interworking functions are required in order to take account of the differences between the bearers used
for the provision of a teleservice/multimedia service/application in the fixed network and the bearers.
Adaptation/Interworking functions are required which take account of the discontinuous and/or asymmetrical nature
of most teleservices/multimedia services/applications.

The service platform shall provide interfaces (to serving networks and home environments) appropriate to the
support, creation and control of supplementary services, teleservices, multimedia services and user applications. The
service platform will also provide interfaces enabling subscribers to control supplementary services, teleservices,
multimedia services and user applications.

Supplementary service provision and control will be independent of radio operating environment, radio interface
technology and fixed wire transmission systems.

As far as possible, the service platform is required to enable new supplementary services, teleservices, multimedia
services and/or end user applications to be supported at minimum cost, with minimum disruption of service and
within the shortest possible time.

3GPP
Release 15 28 3GPP TS 22.101 V15.2.0 (2017-09)

9 Quality of Service (QoS)

The Quality of Service (QoS) parameters should be identified together with appropriate parameter values which set
targets to be reached when designing 3GPP specifications, and which also will serve as guidelines for network design
and service provision.

The QoS for call set-up time, as an example, can be defined in terms of a mean value and as a percentage of cases
which should not exceed a certain time limit. Further information can be found in 3GPP TS 22.105 [1].

The performance requirements for the All-IP Network can be found in 3GPP TS 22.278 [42].

For UE initiated QoS control OMA device management shall be the primary method for provisioning QoS
parameters.

3GPP
Release 15 29 3GPP TS 22.101 V15.2.0 (2017-09)

10 Emergency Calls

10.1 General requirements

It shall be possible to establish an emergency speech call or GTT [26] call (subject to national requirements). The
term 'Emergency call' henceforth refers to speech calls, and GTT Emergency calls if applicable. The term "other
media" henceforth refers to media other than speech and GTT. Support of other media types during an emergency
call when the IM CN subsystem is used is referred to as 'IMS Multimedia Emergency Session' (MES) and is specified
in subclause 10.4.2. Emergency calls will be routed to the emergency services in accordance with national regulations
for where the subscriber is located. This may be based upon one or more default emergency call numbers stored in
the ME. It shall be allowed to establish an emergency call without the need to dial a dedicated number to avoid the
mis-connection in roaming case, such as menu, by use of a 'red button', or a linkage to a car air bag control.
Emergency calls shall be supported by the UE without a SIM/USIM/ISIM being present. No other type than
emergency calls shall be accepted without a SIM/USIM/ISIM.

Emergency calls shall be supported by UEs that are subject to service restrictions, e.g. for UEs camping on a cell in a
forbidden PLMN or in a forbidden LA (see 3GPP TS 22.011 [11]), or on a CSG cell without the subscriber being a
member of that CSG (see 3GPP TS 22.220 [48]). Such emergency calls shall be accepted by the network if required
by local regulation.

The Emergency service is required only if the UE supports voice.

Note 1: It will be left to the national authorities to decide whether the network accepts emergency calls without
the SIM/USIM/ISIM.

It shall be possible to initiate emergency calls to different emergency call centres, depending on the type of
emergency. The following types of emergency calls shall be possible:

- Police

- Ambulance

- Fire Brigade

- Marine Guard

- Mountain Rescue

- Manually Initiated eCall (MIeC)

- Automatically Initiated eCall (AIeC)

- Spare

When a SIM/USIM is present, subscriber specific emergency call set-up MMI shall be provided. The Home
Environment operator shall specify preferred emergency call numbers (e.g. 999 for UK citizens or 110, 118 and 119
for Japanese citizens). These emergency call numbers shall be stored in the SIM/USIM and the ME shall read this and
use any entry of these digits to set up an emergency call. It shall be possible to store more than one instance of this
field.

Note 2: Release '98 and earlier SIM cards have the capability to store additional emergency call numbers.
However in many cases this has not been used.

It shall be possible to tie any emergency call number to any single emergency call type or to any combination of
emergency call types. The association between emergency call numbers and emergency call type shall be able to be
programmed by the Home Environment operator into the SIM/USIM.

Example:

19 Police (Albania)

100 Police and Fire Brigade (Greek cities)

3GPP
Release 15 30 3GPP TS 22.101 V15.2.0 (2017-09)

100 Ambulance and Fire Brigade (Belgium)

112 Police and Ambulance (Italy)

112 General emergency call, all categories (Sweden)

115 Fire Brigade (Italy)

144 Ambulance (Austria)

If the UE does not recognise the emergency call numbers but the serving network recognises the dialled number as an
emergency call number used in the country, a normal call set up shall take place over the radio interface and after the
serving network has recognised the emergency number the call shall be routed as an emergency call.

The user friendly MMI that specifies the type of emergency call directly (e.g. menu) should be supported for use in
any (i.e. home or visited) PLMN to avoid the mis-connection in roaming case. This shall be allowed both with and
without SIM/USIM being present.

When emergency call establishment is initiated, the emergency call type shall be sent by the UE if it is available.

The serving network may download emergency call numbers to the UE in order to ensure that local emergency call
numbers are known to the UE. The UE shall regard these emergency numbers as valid in that country only (as
identified by the MCC) and shall discard them when a new country is entered.

Note 3: The UE can inform the user if the emergency call type for an emergency number received from the
serving network differs from that configured on the USIM/SIM for the same number. How this is
implemented is outside the scope of 3GPP and takes into consideration operator policy and regulatory
requirements.

If permitted by local regulation, it shall be possible for the user to prevent the sending of his public user identifiers
and the location information to the PSAP (i.e. emergency response centre).

Note 4: Operator policies (e.g. requirements for support of emergency communications) may over-ride the user
request for suppression.

Emergency calls over WLAN shall be supported as above with the following caveats:

- The UE issues an Emergency session over WLAN access to EPC only when 3GPP access for emergency call
is not possible or available (e.g. no 3GPP coverage).

- UEs shall only be able to establish an Emergency session over WLAN when the UE has been provisioned
with the WLAN access parameters.

- Service continuity for an Emergency voice call moving from 3GPP access CS domain to WLAN access IMS
domain is not supported.

- The level of security should not be less than that which is currently applied to authenticated and
unauthenticated CS or IMS emergency calls.

- - Emergency call numbers downloaded to the UE over WLAN from untrusted sources shall not be used by
the UE.

NOTE 5: TS 23.402 [57] establishes when WLAN is trusted or not.

- - Subject to local 3GPP operator policy, the UE may use additional emergency call number(s) received via
WLAN access for emergency calls via 3GPP access or WLAN access, while in the country where the
numbers were received.

10.1.1 Identification of emergency numbers

The ME shall identify an emergency number dialled by the end user as a valid emergency number and initiate
emergency call establishment if it occurs under one or more of the following conditions. If it occurs outside of the
following conditions, the ME should not initiate emergency call establishment but normal call establishment.
Emergency number identification takes place before and takes precedence over any other (e.g. supplementary service
related) number analysis.

3GPP
Release 15 31 3GPP TS 22.101 V15.2.0 (2017-09)

a) 112 and 911 shall always be available. These numbers shall be stored on the ME.

b) Any emergency call number stored on a SIM/USIM when the SIM/USIM is present.

c) 000, 08, 110, 999, 118 and 119 when a SIM/USIM is not present. These numbers shall be stored on the ME.

d) Additional emergency call numbers that may have been downloaded by the serving network when the
SIM/USIM is present.

10.1.2 Domains priority and selection for UE attempts to emergency call

10.1.2.1 Voice and GTT only

A UE that is connected to a domain in which it is possible for the UE to make non emergency calls using the
particular media requested by the user, shall use that domain to attempt an emergency call unless serving network
policy (based on regulatory requirements and operator needs) requires the UE, including an unauthenticated UE, to
attempt the emergency call on a specific domain first.

If the UE is connected to more than one domain in which it is possible for the UE to make non emergency calls using
the particular media requested by the user, the UE shall attempt an emergency call on the same domain it would use
to originate a non-emergency call using the same media unless serving network policy (based on regulatory
requirements and operator needs) requires the UE, including an unauthenticated UE, to attempt the emergency call on
a specific domain first.

In the case where an emergency call attempt by a UE fails, the UE should automatically make a second attempt on
the other domain if the UE supports it.

If the user aborts the emergency call setup during the subsequent automatic attempt and immediately tries to set up an
emergency call again, then the UE shall immediately attempt in the domain in which the user aborted the emergency
call.

10.1.2.2 Other media

The following applies in addition to 10.1.2.1.

If an emergency call attempt that includes a request for both (i) voice and/or GTT and (ii) other media cannot be
supported or fails in all connected access types in the PS CN domain, the UE shall attempt the emergency call in the
CS domain if available and shall only include the request for voice and/or GTT.

10.1.3 Call-Back Requirements

Subject to local/regional regulations the network shall support a call-back from a PSAP.

It shall be possible to supply the user's Directory Number/MSISDN/SIP URI as the CLI to the PSAP to facilitate call-
back. The CLI used on call-back shall allow the PSAP to contact the same terminal that originated the emergency
call.

If the incoming call can be identified by the core network as a call-back to an emergency call (i.e. coming from a
PSAP) then supplementary services at the terminating party shall be handled as described in TS 22.173 [40] for
Multimedia Telephony (e.g. Communication Diversion, Communication Hold, Communication Barring).

Note: There is no specific callback requirement for CS supplementary services.

A call-back may be attempted for a period of time defined by local regulations after the emergency call release. In
case of a UE in limited service state, call-back is not required.

10.2 Emergency calls in the CS CN Domain

A CS CN Domain shall support the emergency call teleservice as defined in 3GPP TS 22.003 [14] (TS12).

If a UE supports TS11(Telephony)[14], then it shall also support TS12(Emergency Calls)[14]. It shall be possible to

3GPP
Release 15 32 3GPP TS 22.101 V15.2.0 (2017-09)

set up emergency calls initiated by an emergency call number.

10.3 Emergency Calls in the PS CN Domain

Without the IM CN subsystem, emergency calls are not supported in the PS CN domain.

10.4 Emergency calls in the IM CN subsystem

10.4.1 General
The IM CN subsystem shall support IMS emergency calls. It shall be possible to set up emergency calls initiated by
an emergency call number.

If a UE supports IMS Multimedia Telephony service with speech media as specified in TS 22.173 [40] via an access
network, then it shall also support IMS emergency calls via that access network.

Subject to the regulatory requirement, the IM CN subsystem shall be able to unambiguously identify each emergency
service defined in the national numbering plan for the country in which the UE is located.

In accordance with national regulations for where the subscriber is located, if the UE does not recognise a dialled
number as an emergency call number but the IM CN where the subscriber is located does recognise the dialled
number as an emergency call number (e.g. a number used in the local emergency numbering plan) then the call shall
be routed as an emergency call indicating the type of emergency service to the correct PSAP. Subject to operator
setting the call may be prioritized.

Note 1: The above does not preclude the network rejecting the call and requesting the UE to setup a new
emergency call to the same emergency service.

Emergency calls may be initiated using a private numbering plan [49].

Note 2: There can be an overlap between the private numbering plan of a hosted enterprise and the public
numbering plan, which makes translation of emergency numbers necessary.

Emergency calls may be initiated by a service when requested by the user.

Note 3: It is not intended to enable automatic setup of emergency calls.

Note 4: Only speech and GTT-IP [47] media are supported, when required per subclause 10.1, for emergency
services towards a CS PSAP.

An emergency call shall take precedence over any other services a UE may be engaged in, if required by local
regulation.

Emergency calls from an unauthenticated UE (as far as the IM CN is concerned) shall be supported by the IM CN
subsystem, if required by local regulation.

Subject to regulatory requirements, when UEs must be authenticated, both the network and the UE shall support the
same authentication and security methods that are used for non-emergency sessions.

10.4.2 IMS Multimedia Emergency Sessions

10.4.2.1 General
For IMS emergency calls towards IP PSAPs, other media types may be supported by the UE and the IMS, subject to
regulatory requirements.

The media types that may be supported during an IMS MES include:

- Real time video (simplex, full duplex), synchronized with speech if present;

- Session mode text-based instant messaging;

3GPP
Release 15 33 3GPP TS 22.101 V15.2.0 (2017-09)

- File transfer;

- Video clip sharing, picture sharing, audio clip sharing;

- Voice; and

- Real-Time Text .

Note 1: An IMS MES need not contain voice or Real-Time Text .

To avoid interworking issues, a UE and IMS that supports text based instant messaging shall support a common
session mode text-based instant messaging protocol.

IMS MES does not include support for legacy store and forward messaging such as the Short Messaging Service
(SMS).

Calls from non-human associated devices (e.g. fire alarms) are outside the scope of this specification.

Adding, removing and modifying individual media to/from an IMS MES shall be supported.

An IMS MES is not a subscription service. A UE capable of IMS emergency calls and capable of supporting the other
media types should also be able to support initiation of an IMSMES.

An IMS MES from an unauthenticated UE (as far as the IM CN is concerned) shall be supported by the IM CN
subsystem, if required by local regulation.

IMS MES shall be supported by UEs that are subject to service restrictions, e.g. for UEs camping on a cell in a
forbidden PLMN or in a forbidden LA (see 3GPP TS 22.011 [11]), or on a CSG cell without the subscriber being a
member of that CSG (see 3GPP TS 22.220 [48]). Such IMS MES shall be accepted by the network if required by
local regulation.

An IMS MES shall support providing the location of the UE, in a manner similar to IMS emergency voice calls.

An IMS UE that supports IMS MES shall identify an emergency number dialled by the end user as a valid emergency
number utilizing the same mechanisms as used for IMS emergency voice calls as defined in subclause 10.1.1.

Note 2: This capability supports the general public, including facilitating emergency communications by
individuals with disabilities (e.g. persons who are deaf, deaf-blind, hard of hearing, or have a speech
disability).

An originating network and UE may support some or all of these other media types, and support of any specific
media by an originating network or UE may be subject to regulatory requirements.

Voice call continuity per clause 21 shall be supported when a UE with an active IMS MES with voice and other
media moves out of IMS voice coverage and voice call continuity is supported by the UE and network. The
remaining media (i.e. voice call) then becomes a CS emergency call e.g. TS12 call for 3GPP systems as defined in
3GPP TS 22.003 [14].

Other media shall be dropped when a UE with an active IMS MES moves out of IMS voice coverage, irrespective of
whether or not there is an active voice session.

10.4.2.2 UE Requirements
When IMS MES are supported by the UE, the following apply:

- An IMS UE that supports IMS MES shall also support IMS emergency voice calls.

- Once a UE is aware that an IMS MES has been initiated, the UE shall be able to (subject to user configuration)
avoid drawing unnecessary attention to the user (e.g., playing audible tones or flashing brightly) and should
confirm this to the user in as private a manner as is reasonable e.g. using text on the screen or audio if
headphones are already connected. UE behaviour in an IMS MES may need to be different relative to the
normal configuration.

- The UE should clearly differentiate IMS emergency session-mode text based instant messaging from IMS non-
emergency session-mode text based instant messaging on the user display.

3GPP
Release 15 34 3GPP TS 22.101 V15.2.0 (2017-09)

- The IMS UE supporting video transfer during an IMS MES should be able to deliver recorded media in a form
that allows progressive playback. (It is desirable that all pre-recorded media sent during an emergency session
be progressively viewable.)

- When an IP PSAP attempts to add additional media to an existing IMS MES, the user shall be made aware of
this. When additional media is requested by the PSAP, the user shall be able to permit or deny it.

- The UE shall provide an indication to the user for each requested media, whether it was successfully or
unsuccessfully established.

- Further notifications of added and removed media shall be indicated to the user while the IMS MES is active.

- If none of the media requested by the UE is successfully established, the IMS MES will fail and an IMS MES
failure indication shall be provided to the user.

- In handover of an IMS MES where other media is dropped when IMS MES is not supported, the UE shall
indicate to the end user that the other media is not supported in this area.

The following requirements for IMS emergency voice calls also apply when an IMS MES is supported by the UE:

- An IMS UE that supports IMS MES shall indicate to the network that the call is an IMS emergency call as is
done for an IMS emergency voice call.

- An IMS UE that supports IMS MES shall be able to receive an IMS call-back from a PSAP per clause 10.1.3
with voice, GTT or other media per clause 10.4.2.1.

- An IMS UE that supports MES shall utilize the same trust and security mechanisms for the other media as
utilized for an IMS emergency voice call.

- When roaming, a UE shall originate an IMS MES in the serving network in the same manner as for IMS
emergency voice calls.

10.4.2.3 Originating Network Requirements

When an IMS MES is enabled by the originating network, the following apply:

- Other media shall only be supported in packet-based networks that support IMS emergency voice calls.

- The originating network shall deliver all media to the same IP PSAP throughout the duration of the IMS MES.

- The network shall indicate to the UE, for each requested media, whether it was successfully or unsuccessfully
established.

- Further notification of added and removed media shall be provided to the UE while the IMS MES is active.

- If none of the media requested by the UE is successfully established, the IMS MES will fail and an IMS MES
failure indication will be provided to the UE.

The following requirements for IMS emergency voice calls also apply when IMS MES is supported by the network:

- Subject to regional regulatory requirements, the network shall be able to authenticate the UE using the same
procedures as for IMS emergency voice calls.

- The originating network shall provide the capability to enable an IMS UE supporting IMS MES to obtain local
emergency numbers or other emergency address(es) (e.g. destination address) utilizing the same mechanism as
used for IMS emergency voice calls.

- An IMS MES shall be provided in the local serving network.

- For an IMS MES, any kind of emergency addressing (e.g. SIP URIs, Tel URIs) and special indications for
emergency sessions shall be treated in the same manner as IMS emergency voice calls.

- The originating network should detect all IMS MESs regardless of the UE emergency call indication.
According to operator policy, the originating network may either inform the UE to enable re-origination as an
IMS MES or support origination of the initial call.

3GPP
Release 15 35 3GPP TS 22.101 V15.2.0 (2017-09)

- The originating network shall be responsible for routing the IMS MES towards the appropriate PSAP (e.g.,
based on emergency service type, location, or policy).

- The network shall be able to provide integrity protection, and/or privacy for other media similar to that
provided for IMS emergency voice calls.

- An IMS MES shall utilize the same priority mechanisms as IMS emergency voice calls.

- Detailed log records of the IMS MES shall be generated by the originating network in a similar manner to IMS
emergency voice calls and subject to regulatory requirements.

- All media content within the IMS MES shall be carried with an indication of the source, in a similar manner as
for IMS emergency voice calls.

10.5 Void

10.6 Location Availability for Emergency Calls

National regulations may require wireless networks to provide the emergency caller's location. This requirement
typically overrides the caller's right to privacy with respect to their location being revealed, but remains in effect only
as long as the authorities need to determine the caller's location. The interpretation of the duration of this privacy
override may also be different, subject to national regulation. For example, some countries require location to be
available from the wireless network only while the call is up, while others may allow PSAP's to unilaterally decide
how long the location must be made available.

Therefore, the requirement for providing location availability is to allow the network to support providing a mobile
caller's location to the authorities for as long as required by the national regulation in force for that network.

Note: See TS 22.071 [44] for location service requirements on emergency calls.

10.7 Transfer of data during emergency calls

Emergency calls may be supplemented with emergency related data [1]. Typically this data enables the accurate
geographic location of a manually or automatically activated emergency calling device e.g. an in vehicle system
(IVS), to be provided to the Public Safety Answering Point (PSAP).

The following requirements apply to UEs designed to be able to perform eCalls and to networks supporting eCall:

- The data may be sent prior to, in parallel with, or at the start of the voice component of an eCall.

- Should the PSAP request additional data then this may be possible during the established eCall.

- The realisation of the transfer of data during an eCall shall minimise changes to the originating and transit
networks.

- Both the voice and data components of the eCall shall be routed to the same PSAP or designated emergency
call centre.

- The transmission of the data shall be acknowledged and if necessary data shall be retransmitted.

- The UE shall indicate at call setup if the emergency call will carry supplementary data, i.e. is an eCall.

UEs designed to be able to perform eCalls and configured to only perform eCalls (eCall only mode) shall comply
with the following additional requirements:

- The UE shall not perform mobility management procedures, including registration on a PLMN, except when
attempting to initiate and during an eCall, or to initiate a test or reconfiguration of the terminal upon request
from the user.

- For UEs that have the ability to be called back by the PSAP, the UE shall be capable to continue mobility
management procedures for a limited duration following the termination of the eCall.

3GPP
Release 15 36 3GPP TS 22.101 V15.2.0 (2017-09)

- The UE shall contain an USIM application.

- In the case where the user subscribes to other services provided by the PLMN, it shall be possible for the
network operator to reconfigure the UE so that it can access the subscribed services.

- It shall be possible for the user of the UE to change network operator/service provider (i.e. to use a different
USIM) or for the subscriber to modify the existing subscription used with the UE.

- It shall be possible for the UE upon request from the user to initiate a call to an operator designated non-
emergency MSISDN for the purpose of accessing test and terminal reconfiguration services.

Additional national and regional requirements are as specified in Annex A.

10.8 Supplementary service interaction during emergency calls

Supplementary services that interrupt or divert the media path between a PSAP and the end device shall be handled as
specified in TS 22.173 [40] (e.g. Communication Hold) for Multimedia Telephony. No such Supplementary Services
are applicable to CS Emergency Calls (TS12) according to TS 22.004 [5].

3GPP
Release 15 37 3GPP TS 22.101 V15.2.0 (2017-09)

11 Numbering principles
The following network addressing schemes listed below shall be supported at the relevant domains:

- E.164,

- E.168,

- E.212,

- X.121

- Internet (including e.g. IP address, SIP URI).

11.1 Number portability

11.1.1 Requirements for CS CN domain
Some numbering schemes shall be fully independent of the supporting serving network and the home environment,
allowing users to transfer this number to another home environment. For further information see 3GPP TS 22.066 [7].

An MSISDN shall be allocated to each new user at the start of a subscription. This number may be allocated from one
of several numbering domains. For example:

- home / serving environment numbering scheme;

- national numbering scheme;

- regional numbering scheme;

- global numbering scheme.

A user shall be able to move subscription from one home environment to another without changing the MSISDN
provided that the new home environment offers service in the same geographic domain. It is envisaged that home
environment s will be able to allocate MSISDNs from each of these domains as required.

11.1.2 Requirements for PS CN domain

None identified.

11.1.3 Requirements for IM CN subsystem

It shall be possible to offer number portability for E.164 numbers within IM CN subsystem. For further information
see 3GPP TS 22.066 [7].

11.2 Evolution path

Since 3GPP specifications aim to be aligned with IMT-2000, a primary goal in numbering is the provision of global
user numbering in line with steps taken by the ITU - SG2.

The numbering scheme and network implementation chosen shall allow for international/global evolution.

3GPP
Release 15 38 3GPP TS 22.101 V15.2.0 (2017-09)

11.3 Void

11.4 Void

11.5 Void

11.6 Private numbering

A user may wish to use private numbers for the purposes of calling frequent numbers. Therefore there is a
requirement for the use, by the user, of Private Numbering Plans (PNPs). These schemes may belong to the user
himself, to a home environment or a third party.

11.7 Numbering schemes

11.7.1 Multiple numbering scheme
The standards shall support the possibility of allowing the bearer service associated with an MT call to be implicitly
defined by the destination MSISDN, for example to use a different MSISDN to establish voice, fax or data . It will be
possible for multiple MSISDNs to be associated with a single subscription.

11.7.2 Single numbering scheme

The standards shall support the possibility of allowing MT calls of different bearer types ( e.g. voice, fax, data) to be
routed to a single MSISDN. It is recognised that the implementation of this may depend on the availability of bearer
information associated with an incoming call from the adjoining transit network. In particular the standards will
support this possibility in the case of an adjoining ISDN transit network.

11.7.3 Additional numbers

The 3GPP system shall support the possibility to assign an additional MSISDN, in addition to the original MSISDN,
to a user with a connection to the PS CN domain. If this additional MSISDN is available it shall be used for
correlation of CS and IMS in voice call and service continuity as well as IMS Centralized Service. In this case the
original MSISDN may be used for charging and OA&M purposes and forwarded to the PS gateway to other packet
data networks.

11.8 Optimal routing

The implementation of the numbering scheme used shall allow for optimal routing; i.e. routing shall not take place
simply on the number dialled.

See 3GPP TS 22.079 [8] for some scenarios for the CS CN domain. Optimal routing for IP services is supported by
the All-IP Network [42].

3GPP
Release 15 39 3GPP TS 22.101 V15.2.0 (2017-09)

11a Identification Requirements

11a.1 Subscriber Identification

In 3GPP the identity of a subscriber is encoded in a identity module application which is contained on a UICC or on a
GSM SIM card. The UICC or GSM SIM card is a removable component of the User Equipment. Three types of
identity modules are used in the 3GPP system:
- Universal Subscriber Identity Module (USIM)

- IMS Subscriber Identity Module (ISIM)

- Subscriber Identity Module (SIM) according to GSM

General requirements:
- In the 3GPP system each subscriber shall be uniquely identifiable.

- The serving networks shall be able to authenticate any subscriber that roams onto their network

- If a UE, that is registered on the serving network, contains a GSM SIM card or a UICC containing a identity
module application, the serving network shall be able to identify the associated home PLMN.

Note 1: UE support of GSM SIM is optional.

Note 2: See the chapter (USIM, UICC and Terminal) of the present specification for a reference, which GSM
phase SIMs need to be supported by the network.

11a.2 Terminal Identification

It is a requirement that the terminal can be uniquely identified by the home environment and serving network. This
shall require a terminal identity scheme which uniquely identifies each terminal, see 3GPP TS 22.016[12].

11a.3 Home Environment / Serving Network Identification

Home / serving environments need to route communication to the current location of the user. This shall require a
identity scheme which uniquely identifies the serving environment and shall be used for routing purposes.

11a.4 Serving Environment / Mobile Virtual Network Identification

A mobile virtual network operator (MVNO) is a service provider that does not have its own radio access network, but
resells wireless services, typically under their own brand name, using the network of a host PLMN operator.

It should be possible to uniquely identify subscribers belonging to a particular MVNO.

3GPP
Release 15 40 3GPP TS 22.101 V15.2.0 (2017-09)

12 Human Factors and user procedures

The User Interface (MMI) from the end-user's point of view should be as flexible as possible while still meeting the
general service requirements. In addition it should be capable of being updated so as to meet new services which are
still to be envisaged.

In general the following principles should be encompassed:

- activation of services should be as simple as possible with minimum input expected from the user;

- feedback, to the user from the various services, should be meaningful;

- any error recovery procedures provided should be simple to understand and execute.

- input from the user and information to the user should be provided in alternative selectable modes in order to
match user capabilities, preferences and situation.

However, a detailed specification for the User Interface shall not be defined. In particular given the global nature of
the third generation systems, for different regions of the world, different criteria will determine the implementation of
the User Interface. Also it is unlikely that there will be a single common handset which will meet all the service
requirements and therefore a common User Interface would be impractical.

Given the flexibility of the services, there should be a wide range of User Interface possibilities. These possibilities
include simple terminals with a single on/off button through to complex terminals providing support to
hearing/visually impaired users.

Control of CS CN Domain supplementary services (3GPP TS 22.004 [5]), may use MMI procedures specified in
3GPP TS 22.030 [6] and existing MMI related UE features (Annex A) may also be used. In particular the following
features are highly desirable for uniform UE implementation where appropriate:

- Mapping of numeric keys to European alphabetic keys to ensure compatible mnemonic dialing as defined in
3GPP TS 22.030 [6],

- "+" key function to enable one key international access as defined in Annex A

- Structure of the MMI as described in 3GPP TS 22.030 [6]

- Presentation of IMEI (International Mobile Equipment Identity) as defined in 3GPP TS 22.030 [6].

3GPP
Release 15 41 3GPP TS 22.101 V15.2.0 (2017-09)

13 UICC, USIM and Terminal

This clause defines the functional characteristics and requirements of the User Service Identity Module (USIM) and
ISIM (IM Services Identity Module). The USIM/ISIM are applications residing on a UICC.

13.1 The USIM/ISIM and User Profiles

13.1.1 The USIM
Every USIM shall have a unique identity and shall be associated with one and only one home environment.

It shall be possible for a home environment to uniquely identify a user by the USIM.

The USIM shall be used to provide security features.

For access to services, provided by PS or CS CN domains, a valid USIM shall be required. Optionally, SIM according
to GSM phase 2, GSM phase 2+, 3GPP release 99, 3GPP release 4 specifications may be supported.

The USIM shall be able to support SIM Application Toolkit as specified in 3GPP TS 22.038 [3].

The USIM shall reside on a UICC. USIM specific information shall be protected against unauthorised access or
alteration.

It shall be possible to update USIM specific information via the air interface, in a secure manner.

Access to the IMS services shall be possible using the USIM application in the event of no ISIM being present on the
UICC. If an ISIM is present on the UICC it shall be used to access the IMS.

It shall be possible to store provisioning parameters on the USIM according to DM specifications [37].

It should be possible to store provisioning parameters on the USIM according to CP specifications [38].

It shall be possible for the network operator to configure the USIM to indicate (through personalisation and OTA)
whether provisioning parameters according to DM specifications or provisioning parameters according to CP
specifications shall be used.

Note: To avoid misoperation of the UE in a mixed provisioning environment e.g. during a transition phase
when both CP and DM clients are present in the UE, the CP parameters on the USIM can be read first.
If DMinformation is present (provisioned OTA in the CP parameters.), then use DM, otherwise use CP.

Annex A describes a number of features that may optionally be supported by the UE and thus USIM.

13.1.2 User Profiles

It shall be possible for a user to be associated with one or a number of user profiles, which the user can select and
activate on a per call basis. The user profile contains information which may be used to personalise services for the
user.

It shall be possible for one or more user profiles associated with the same user to be active simultaneously so that the
user may make or receive calls associated with different profiles simultaneously. Activation of profiles shall be done
in a secure manner, for example with the use of a PIN.

For terminating calls the correct profile shall be indicated by the user address used (e.g. MSISDN, SIP URI), each
profile will have at least one unique user address associated with it. For originating calls the user shall be able to
choose from the available profiles, the appropriate one for the call. A profile identity will need to be associated with
the call for accounting and billing purposes. User profile identities need not be standardised but a standardised means
is required for indicating that a particular profile is being used.

Simultaneous use of the same user profile on multiple terminals for the same type of service shall not be allowed.

User profiles associated with different home environments shall not share the same user address.

3GPP
Release 15 42 3GPP TS 22.101 V15.2.0 (2017-09)

13.1.3 UICC usage in GERAN only Terminals

In Release 5 and later, terminals supporting only GERAN shall support USIM.

Note: It is strongly recommended that manufacturers implement SIM support on GERAN only terminals until
the population of SIMs in the market is reduced to a low level.

13.1.4 Multiple USIMs per UICC

The standard shall support more than one USIM per UICC even when those USIMs are associated with different
home environments. Only one of the USIMs or the SIM shall be active at a given time. While the UE is in idle mode,
it shall be possible for the user to select/reselect one USIM application amongst those available on the UICC. At
switch on, the Last Active USIM shall be automatically selected. The Last Active USIM shall be stored on the UICC.
By default if there is no Last Active USIM defined in the UICC, the user shall be able to select the active USIM
amongst those available on the UICC.

The standard must not prevent the coexistence of USIM applications, each associated with different home
environments on the same UICC, so long as the security problems which arise from such a coexistence are solved.

13.1.5 The ISIM

Access to the IMS services shall be possible using an ISIM application.

The ISIM shall be sufficient for providing the necessary security features for the IMS and IMS only.

The ISIM shall reside on a UICC. ISIM specific information shall be protected against unauthorised access or
alteration.

It shall be possible to update ISIM specific information via the air interface, in a secure manner.

Note: When accessing IMS over GERAN/UTRAN/EUTRAN or I-WLAN using ISIM, a USIM needs also be
present to access the rest of the 3GPP system. Alternatively USIM could be used to access IMS.

13.2 The UICC

Characteristics including physical formats of a UICC are defined in TS 31.101[36].

Access to services via 3GPP system with a single UICC shall be possible.

13.2.1 The UICC and Applications other than the USIM or ISIM
It shall be possible for the UICC to host other applications in addition to the USIM or ISIM, see figure 3. Service
providers, subscribers or users may need to establish additional data or processes on the UICC. Each application on
an UICC shall reside in its own domain (physical or logical). It shall be possible to manage each application on the
card separately. The security and operation of an application in any domain shall not be compromised by an
application running in a different domain. Applications may need to use their own security mechanisms which are
separate to those specified by 3GPP e.g. electronic commerce applications.

Examples of UICC applications are: USIM, ISIM, off-line user applications like UPT, electronic banking, credit
service, etc.

Applications should be able to share some information such as a common address book.

It shall be possible to address applications, which reside on the UICC, via the air interface.

3GPP
Release 15 43 3GPP TS 22.101 V15.2.0 (2017-09)

Figure 3 Example of a Multifunction UICC

13.2.1a UICC applications and IMS

UICC applications may make use of IMS functionalities controlled by ME.

Note: This is to allow a UICC application to interact with an Application Server (AS) through IMS. Examples of
UICC applications include identity management, banking applications, etc.

13.2.2 Fast Access and Retrieval of Data from UICC

An optional "high speed" interface may be provided between the UICC and the ME.

If provided, this interface shall allow fast access and retrieval of data to support functionalities requiring large
amounts of data to be transferred to and from the UICC. Examples include:

- on-card web servers

- rapid access to data stored on the UICC, e.g. phone book, PLMN lists or user data

A UICC/ME interface supporting this "high speed" interface shall be backward compatible with the TS 102 221
interface specified in 3GPP TS 31.101 [36].

13.3 Terminals and Multiple UICCs

A single terminal may support the use of multiple UICC (e.g. with applications like USIM and/or banking, credit
card,...). Only one UICC shall be active at a time to access a PLMN. In case the active UICC contains more than one
USIM, the requirements of 13.1.4 shall apply.

If the UICC with the active USIM is removed from the mobile terminal during a call (except for emergency calls),
the call shall be terminated immediately. If the UICC with an active ISIM is removed during an IMS session the IMS
session shall be terminated.

3GPP
Release 15 44 3GPP TS 22.101 V15.2.0 (2017-09)

14 Types of features of UEs

3GPP specifications should support a wide variety of user equipment, i.e. setting any limitations on terminals should
be avoided as much as possible. For example user equipment like hand-portable phones, personal digital assistants
and laptop computers can clearly be seen as likely terminals.

In order not to limit the possible types of user equipment they are not standardised. The UE types could be
categorised by their service capabilities rather than by their physical characteristics. Typical examples are speech
only UE, narrowband data UE, wideband data UE, data and speech UE, etc..

In order to enhance functionality split and modularity inside the user equipment the interfaces of UE should be
identified. Interfaces like UICC-interface, PCMCIA-interface and other PC-interfaces, including software interfaces,
should be covered by references to the applicable interface standards.

UEs have to be capable of supporting a wide variety of teleservices, multimedia services and applications provided in
PLMN environment. Limitations may exist on UEs capability to support all possible teleservices, multimedia services
and information types (speech, narrowband data, wideband data, video, etc.) and therefore functionality to indicate
capabilities of a UE shall be specified.

The basic mandatory UE requirements are:

- Support for USIM. Optional support of GSM phase 2, 2+, 3GPP Release 99 and Release 4 SIM cards [34].
Phase 1, 5V SIM cards shall not be supported. Support for the SIM/ISIM is optional for the UE, however, if it
is supported, the mandatory requirements for SIM/ISIM shall be supported in the UE;

Note 1: There is no Release 5 specification for the SIM, and therefore references to "SIM" apply to earlier
releases.

Note 2: It is strongly recommended that manufacturers implement SIM support on terminals supporting
GERAN until the population of SIMs in the market is reduced to a low level.

- Home environment and serving network registration and deregistration;

- Location update;

- Originating or receiving a connection oriented or a connectionless service;

- An unalterable equipment identification; IMEI, see 3GPP TS 22.016 [12];

- Basic identification of the terminal capabilities related to services such as; the support for software
downloading, application execution environment/interface, MExE terminal class, supported bearer services.

- Terminals capable for emergency calls shall support emergency call without a SIM/USIM/ISIM.

- Support for the execution of algorithms required for encryption, for CS and PS services. Support for non
encrypted mode is required;

- Support for the method of handling automatic calling repeat attempt restrictions as specified in 3GPP TS
22.001 [4];

- At least one capability type shall be standardised for mobile terminals supporting the GERAN,UTRAN and E-
UTRAN radio interfaces.

- Under emergency situations, it may be desirable for the operator to prevent UE users from making access
attempts (including emergency call attempts) or responding to pages in specified areas of a network, see 3GPP
TS 22.011 [11];

- Ciphering Indicator for terminals with a suitable display;

- The ciphering indicator feature allows the UE to detect that the 3GPP radio interface ciphering (user plane) is
not switched on and to indicate this to the user. The ciphering indicator feature may be disabled by the home
network operator setting data in the SIM/USIM. The default terminal behaviour shall be to take into account
the operator setting data in the SIM/USIM. However, terminals with a user interface that can allow it, shall
offer the possibility for the user to configure the terminal to ignore the operator setting data in the SIM/USIM.

3GPP
Release 15 45 3GPP TS 22.101 V15.2.0 (2017-09)

If this feature is not disabled by the SIM/USIM or if the terminal has been configured to ignore the operator
setting data in the SIM/USIM, then whenever a user plane connection is in place, which is, or becomes un-
enciphered, an indication shall be given to the user. In addition, if this feature is not disabled by the
SIM/USIM or if the terminal has been configured to ignore the operator setting data in the SIM/USIM, then
additional information may also be provided about the status of the ciphering. Ciphering itself is unaffected by
this feature, and the user can choose how to proceed;

- Support for PLMN selection.

- Support for handling of interactions between toolkits concerning the access to UE MMI input/output
capabilities;

- Whenever an application (e.g. a SAT/MExE/WAP application) requires the access to the UE MMI
input/output capabilities (e.g. display, keyboard,… ), the UE shall grant this access subject to the capabilities
of the UE. This shall not cause the termination of any other applications (e.g. WAP browser or MExE/SAT
application) which were previously using these UE resources. The UE shall give the user the ability to accept
or reject the new application. In the case that the application request is rejected, the access to the UE MMI
input/output capabilities is returned to the applications which were previously using these UE resources. If the
user decides to continue with the new application, then when this new application is terminated, the access to
the UE MMI input/output capabilities shall be returned to the UE to be re-allocated to applications (e.g. the
preceding application which was interrupted). Subject to the capabilities of the UE, the user shall have the
ability to switch the MMI input/output capabilities between applications.

Note: Rejecting a request to access the UE MMI input/output capabilities by an application does not
necessarily mean that it is terminated, but only that the access to the UE MMI input/output capabilities
are not granted to this application. Handling of rejection (termination, put on hold,…) is the
responsibility of the application.

Annex A describes a number of features which may optionally be supported by the UE.

15 Relationship between subscription and service

delivery

15.1 Subscription
A subscription describes the commercial relationship between the subscriber and the service provider.

Figure 4: Subscriber, subscription and services relationship

3GPP
Release 15 46 3GPP TS 22.101 V15.2.0 (2017-09)

A subscription to a network operator may provide the user with access to one or more domains. A Subscription shall
identify the set of services, within particular domains, to which the user has access (see figure 3); each subscription
may specify a different set of services. These services may be provided by the CS CN Domain and/or a PS CN
Domain and/or an IM CN subsystem. Subscriptions relate to services such as Basic Services (e.g. Teleservices,
Bearer services), PS services and IM-Services (IP-based multimedia services), which are typically provided by
network operators, and to value added services which typically are provided by network operators and/or other
entities that provide services to a subscriber

The subscription identifies:

- the services and related services information that are made available to the subscriber by the service provider ;

In addition a subscription to a network operator may identify:

- the domains to which the user has been granted access by the network operator. In particular, the PS service
profile and information on the allowed QoS parameter ranges shall be contained in the subscription.

- the identity of the subscriber within these domains.

Note: The identity of a subscriber in the CS CN domain and PS CN domain (e.g. her IMSI) may potentially be
different to her identity in the IM CN subsystem

- the radio access systems over which the subscriber may access their services e.g. UTRAN, GERAN,
EUTRAN, I-WLAN.

15.2 Other concepts associated with services

Provision of services:
An action to make a service available to a subscriber. The provision may be:

- general: where the service is made available to all subscribers (subject to compatibility restrictions
enforced) without prior arrangements being made with the service provider;

- pre-arranged: where the service is made available to an individual subscriber only after the necessary
arrangements have been made with the service provider.

Withdrawal:
An action taken by the service provider to remove an available service from a subscriber's access. The withdrawal
may be:

- general: where the service is removed from all subscribers provided with the service;

- specific: where the service is removed on an individual basis from subscribers provided with the
service.

Note: Access to the IM subsystem requires IP connectivity provided, for example, through provision of the PS
CN domain.

15.3 Requirements concerning service delivery

In general it is a requirement to allow the use of independent services simultaneously (i.e. Basic, PS, IP multimedia
and operator specific).

1) The network usage shall be based on the services identified within the subscription, the terminal capabilities
and, where applicable, roaming agreements between operators.

2) The Home environment shall be able to decide on the service delivery in a roaming scenario. I.e. it shall
control how services are delivered in line with the subscription.

3) If an offered or required service (e.g. voice) could be provided with different technologies within the serving
network, the decision on service delivery shall be based on preferences identified in the user profile and
serving network capabilities and conditions (e.g. load).

3GPP
Release 15 47 3GPP TS 22.101 V15.2.0 (2017-09)

4) If the user profile does not allow an alternative service delivery method and the requested delivery method is
not available in the serving network the service shall not be provided to the subscriber. This applies also to
data bearer services with defined QoS parameters (or parameter ranges).

Examples:

- A terminating voice call for a subscriber with a dual/multi mode terminal (e.g. UTRAN/GERAN) could be
delivered in a hybrid network as IM service or CS voice call (TS11). The delivery decision is based on the
preferences of service delivery within the user profile and the network conditions. If there is no preference
information of the Home environment available the decision is made only on the network conditions from the
serving network.

- A terminating data service (e.g. PS with QoS for real time audio) where the network cannot provide the QoS at
call setup. Both the originating and terminating application shall be informed about the possible QoS
configuration for that call. The further handling (setup continuation, termination) depends on the decisions of
the applications.

15.3.1 Mobile Originated Voice calls

When a ME capable of offering voice service both on CS and IMS is CS attached and IMS registered MO CS Voice
calls (TS11) and MO IMS voice services shall be originated on the domain specified by the Home operator policy or
users preferences. The Home Operator policy shall have precedence to user preferences.

15.3.2 Mobile Terminated Voice calls

When a ME capable of offering voice service both on CS and IMS, MT CS Voice calls (TS11) and MT IMS voice
services shall be delivered over the domain specified by the Home operator policy or users preferences. The Home
Operator policy shall have precedence to user preferences. If the call delivery attempt fails in one domain, if specified
by operator policy, it should be possible to attempt the delivery in the other domain or the call/communication
forwarding supplementary services [41, 40] may be invoked if provisioned.

NOTE 1: The delivery decision will take into account aspects such as IMS registration and CS attachment status.

NOTE 2: When the terminating network knows that the UE is either IMS registered or CS attached in non-3GPP
access (e.g. CDMA), the delivery decision will take this into account in order to select the correct
domain.

3GPP
Release 15 48 3GPP TS 22.101 V15.2.0 (2017-09)

16 Charging principles
The cost of the call may cover the cost of sending, transporting, delivery and storage. The cost of call related
signalling may also be included. Provision shall be made for charging based on time, destination, location, volume,
bandwidth, access technology and quality. Charges may also be levied as a result of the use of value added services.

It shall be possible for information relating to chargeable events to be made available to the home environment at
short notice. The requirements shall include:

- Immediately after a chargeable event is completed;

- At regular intervals of time, volume or charge during a chargeable event.

- Delivery of the location of the terminal to the home environment, e.g. cell identification;

Standardised mechanisms of transferring charging information are required to make these requirements possible.

It should be possible for multiple leg calls (e.g. forwarded, conference or roamed) to be charged to each party as if
each leg was separately initiated. However, in certain types of call, the originating party may wish/be obliged to pay
for other legs (e.g. SMS MO may also pay for the MT leg.).

It shall be possible to charge according to the location (e.g. cell, or zone) and access technology that are being used to
access network services.

Provision shall be made for the chargeable party to be changed during the life of the call. There shall be a flexible
billing mechanism which may include the use of stored value cards, credit cards or similar devices.

The chargeable party (normally the calling party) shall be provided with an indication of the charges to be levied (e.g.
via the called number automatically or the Advice of Charge supplementary service) for the duration of the call (even
though the user may change service environment)The user shall be able to make decisions about the acceptable level
of accumulated charge dynamically or through their service profile.

If a user is to be charged for accepting a call then their consent should be obtained. This may be done dynamically or
through their service profile.

Charging and accounting solutions shall support the shared network architecture so that end users can be
appropriately charged for their usage of the shared network, and network sharing partners can be allocated their share
of the costs of the shared network resources.

3GPP
Release 15 49 3GPP TS 22.101 V15.2.0 (2017-09)

17 Roaming

17.1 Assumptions
In order to roam, the following applies:

- Mobile terminal can connect to the radio access network.

- Authentication (charging/billing network) must occur in order to get access to services (except for emergency
calls).

- The services offered to a roaming subscriber may be restricted by the capabilities of the visited network, and
the roaming agreement between the visited and the home environment.

17.2 Principle
Long term evolution of the IM CN subsystem shall not be restricted by the short/mid-term inter-domain roaming
requirements.

17.3 Requirements

Figure 5: Roaming requirements

- The personalised services & capabilities available in a visited network are dependent upon the subscription
options in the home environment. This does not preclude the visited network offering additional services, or
access to content providers.

- Roaming from this release's home environment to CS (this release or earlier) visited network is required

- Roaming from this release's home environment to IM CN subsystem visited network is required

- Roaming from this release's home environment to PS (this release or earlier) visited network is required

- Roaming from previous releases' home environment (or earlier) to this release CS visited network is required

- Roaming from previous releases' home environment (or earlier) to this release PS visited network is required

3GPP
Release 15 50 3GPP TS 22.101 V15.2.0 (2017-09)

Note: When an operator allows a subscriber to roam to different domains, the home environment needs to
provide subscription data to the visited network . The mapping between service data of the different
domains is not standardised; it is determined by the home environment and may be influenced by
roaming agreements.

3GPP
Release 15 51 3GPP TS 22.101 V15.2.0 (2017-09)

18 Handover Requirements
Any handover required to maintain an active service while a user is mobile within the coverage area of a given
network, shall be seamless from the user's perspective. However handovers that occur between different radio
environments may result in a change of the quality of service experienced by the user.

It shall be possible for users to be handed over between different networks subject to appropriate roaming/commercial
agreements.

For further information see 3GPP TS 22.129 [9].

3GPP
Release 15 52 3GPP TS 22.101 V15.2.0 (2017-09)

19 Network Selection
Network selection procedures are defined in 3GPP TS 22.011 [11].

Other procedures may be offered by the UE.

3GPP
Release 15 53 3GPP TS 22.101 V15.2.0 (2017-09)

20 Security
Security matters are considered in 3GPP TS 21.133 [15] and 3GPP TS 33.120 [16].

3GPP
Release 15 54 3GPP TS 22.101 V15.2.0 (2017-09)

21 Voice Call Continuity

21.1 General
The 3GPP system shall be able to provide continuity between CS voice services (Teleservice 11[14]) and the full
duplex speech component of IMS multimedia telephony service [40] with no negative impact upon the user's
experience of the voice service. This functionality is known as voice call continuity. Voice call continuity shall be
executed when continuation of a voice service is required based on operator policy across a change in the connection
of the UE to the 3GPP system as the user moves from using the CS domain to using IMS and vice versa.

The user experience shall be unaffected by the transition from a CS voice service to a full duplex speech component
of IMS multimedia telephony and vice versa, and the user shall experience no disruption in the voice service
provided. The voice service is continued with the same ME.

It shall be possible to support Voice call continuity between IMS and the CS domain belonging to different operators;
i.e., when the user's IMS services are under the control of the home IMS and the user is roaming in the coverage of
the visited CS network.

It shall be possible for an operator to enable or disable Voice call continuity for a given subscriber e.g. based on
roaming conditions, terminal capabilities.

21.2 Support of Supplementary Services

The voice call continuity user's experience shall be such that, to the greatest degree possible, a consistency of service
is provided regardless of the underlying communication infrastructure and technology. With regard to supplementary
services, the general principle is that CS-based supplementary services only apply whilst a VCC subscriber is in the
CS domain and equivalent services over IMS only apply whilst a VCC subscriber is in the IMS domain, although
there are exceptions listed below. It is not required to synchronise the supplementary service settings of the CS
domain with the related service settings of the IMS (e.g. different forwarding numbers may apply over CS and over
IMS).

The following supplementary services apply. The impact on the supplementary services in case the VCC is executed
for the calling party, the called party, or both is described below.

21.2.1 Line Identification Services

A user who has subscribed to the CLIP Supplementary Service and receives a call shall also receive the line identity
or appropriate IMS information of the calling party.

The identity presentation is not changed for the duration of the call regardless of whether the call undergoes VCC.

If the CLIR Supplementary Service or IMS identity restriction is applicable to the call, then at call setup time the
called user shall receive an indication that the identity is not available because of restriction.

The indication is not changed for the duration of the call regardless of whether the call undergoes VCC.

If COLP or a corresponding IMS service is applicable to a call the calling subscriber shall receive the connected line
identity or appropriate IMS information at call setup time.

The identity presentation is not changed for the duration of the call regardless of whether the call undergoes VCC.

If the COLR Supplementary Service or IMS identity restriction is applicable to the call, then the calling user shall
receive an indication at call setup time that the identity of the connected party is not available because of restriction.

The indication is not changed for the duration of the call regardless of whether the call undergoes VCC.

21.2.2 All Call Forwardings

It shall be possible to perform VCC on a call which was forwarded due to call forwarding supplementary services in

3GPP
Release 15 55 3GPP TS 22.101 V15.2.0 (2017-09)

the CS or redirecting services in the IMS.

21.2.3 Call Waiting

The functionality of call waiting supplementary service in the CS domain shall not be affected by the user's ability to
undergo VCC.

Note: Whether the user will continue to receive call waiting notifications in the case their call is continued in
the IMS will depend on whether a call waiting service is available in the IMS.

21.2.4 Call Hold

It shall be possible to re-establish a call which has been put on hold before undergoing VCC, after the VCC has been
performed.

21.2.5 Multiparty
It shall be possible for any party in a multiparty call to undergo VCC and to stay in the call. It shall be possible to
terminate the entire multiparty call when the served mobile subscriber releases even if she is connected via the IMS
after undergoing VCC.

21.2.6 All Call Barrings

If a call were to undergo VCC and that would result in the call being barred in the target domain/system, it shall be
up to the home operator policy whether the call continues in the target domain/system, the call terminates, or VCC is
not executed for the call.

21.2.7 Void

21.2.8 Void

21.2.9 All other Supplementary Services

Other supplementary services are not discussed in this section as they do not apply to calls in progress (i.e. they apply
to call set up only) or their support and/or the need for standardised implementation has not been identified as critical
for VCC in this Release.

21.3 Quality of Service

Voice call continuity shall not adversely impact the quality of the voice service experienced by the user.

21.4 Security
Voice call continuity shall not adversely impact the security of the 3GPP system.

Security mechanisms of the 3GPP system shall be reused for voice call continuity.

21.5 Emergency calls

Voice call continuity for emergency calls shall be applicable to dual radio and single radio UEs.

Voice call continuity of emergency calls shall only be performed when all the following conditions are met:

- the source network is IMS;

- the target network supports emergency calls;

3GPP
Release 15 56 3GPP TS 22.101 V15.2.0 (2017-09)

- the user is moving out of coverage;

- the source and target network belong to the same operator;

- the target network supports voice call continuity.

21.6 Charging
It shall be possible to indicate in the charging information that a VCC event has occurred (e.g., so that appropriate
ratings can be applied for the CS and IMS parts of the continued voice call).

21.7 VCC Activation

It shall be possible to activate VCC based on operator policies, taking into account any of the following:

- Radio conditions e.g. radio quality thresholds and related hysteresis

- Coverage availability e.g.: Always prefer I-WLAN, if certain SSID are available

3GPP
Release 15 57 3GPP TS 22.101 V15.2.0 (2017-09)

22 IMS Centralized Services

22.1 General
The ICS user shall receive both registered and unregistered services in a consistent manner when the user accesses
IMS either via the CS or the PS domain (both of which can be supported by 3GPP access networks or non-3GPP
access networks). Support of UEs enhanced with ICS capability as well as UEs without ICS capability shall be
possible.

Note: The impacts to support non-3GPP CS domains to support of ICS are outside the scope of 3GPP.

22.2 Service Consistency

Subscribers shall have a consistent user experience regardless of the domain used, subject to the constraints of the UE
and access network.

22.3 Service Continuity

ICS shall support service continuity between CS and PS domains (both of which can be supported by 3GPP access
networks or non-3GPP access networks), subject to the constraints of the UE and access networks.

Note : The impacts to support non 3GPP CS domains are outside the scope of 3GPP.

The service continuity shall include:

- Basic services

- Non mid-call services

- Mid-call services

The support of service continuity for fax and data (CS) media components is not required.

22.4 IMS Services

The set of IMS services supported by ICS shall include at least the following, subject to the constraints of the UE and
access networks:

- IMS Multimedia Telephony services, including:

- speech,

- video,

- fax,

- data (CS),

- Supplementary services defined within [40]; and

- Multimedia priority service.

- IMS emergency calls, including eCall.

Note: Other IMS hosted services supported by an operator or 3rd party may be supported.

3GPP
Release 15 58 3GPP TS 22.101 V15.2.0 (2017-09)

22.5 Roaming Support

An ICS user shall be able to receive full ICS support from the HPLMN while roaming in the VPLMN, subject to the
constraints of the VPLMN (e.g. roaming agreements, operator policies).

The Home operator shall be able to control if the UE enhanced with ICS capability shall act without ICS capability
while roaming.

3GPP
Release 15 59 3GPP TS 22.101 V15.2.0 (2017-09)

23 CS IP interconnection requirements

23.1 Introduction
CS IP interconnect represents the interconnection of MSC Server functionality between 2 CS networks over an
underlying IP infrastructure.

23.2 IP interconnect
The IP connection used for CS IP interconnect shall be generic such that it can support all combinations of core
network interconnection. E.g. the IP interconnection shall be shared between the IMS interconnection and the CS IP
interconnection.

It shall be possible to handle the inter-connection of all services over this generic IP interface. The handling of
security and charging shall also be generic for all IP interconnect scenarios.

23.3 MSC server interconnect

The following requirements apply at the interconnection point when two PLMNs are interconnected by means of IP
transport technology for 2G and 3G CS services.

The system shall support the capability for CS service interoperability and interworking.

It shall be possible to apply operator defined policy at the interconnection point.

The system shall support the capability to control the session resources when two different network domains are
connected that may have, for example, different IP addressing schemes.

The system shall support IP inter-connection between core networks either by direct connection or by using an
intermediate carrier (e.g. GSMA IPX [43]).

The system shall support both bilateral interconnection between two carriers and multilateral interconnection (e.g.
GSMA IPX [43]) by means of intermediate carrier.

The system shall support either

- transparent relay of the IP signalling and traffic;

- service aware interconnection

The system shall support codec negotiation across one or multiple interconnects to minimise transcoding (and
preferably eliminate it) to provide the highest quality service to the user.

3GPP
Release 15 60 3GPP TS 22.101 V15.2.0 (2017-09)

24 Service Alignment & Migration

24.1 Introduction
Services can be offered to the users via different service domains, e.g. certain teleservices and supplementary services
via CS or Multimedia Telephony and supplementary services via IMS. Especially for the supplementary services
given below a strong relationship exists from the user's point of view. Therefore means shall be provided to enable a
consistent user experience when changing from one service domain to the other.

The requirements in this clause are applicable during the migration to an ICS. The ability to synchronise the service
settings will facilitate the migration from a CS to an IMS based network and will allow network operators maximum
flexibility in their migration strategies.

24.2 Alignment of supplementary services settings

Based on user preferences and if provisioned by the home operator the network shall automatically synchronise the
parameter settings of the supplementary services listed in the following table:

CS Voice (TS11) Equivalent Multimedia Service Behaviour Required

Supplementary Services Telephony Services in
IMS domain
CLIP/CLIR OIP/OIR Consistency of presentation
CoLP/CoLR TIP/TIR Consistency of presentation
CNAP OIP/OIR Consistency of presentation
Call Forwarding CDIV Call forwarding/CDIV shall work consistently no matter
which domain the user is in. The settings (e.g. forwarding
numbers) shall remain the same across domains for all
the parts of the service for which there is an equivalent.
Call Waiting Communication Waiting The busy state of the user shall be available to both
domains so that this can be applied no matter from which
domain an incoming call/communication originates. The
activation status of Call Waiting and Communication
Waiting shall be synchronised.
Call Hold Communication HOLD Any calls held in one domain shall remain held on moving
to a different domain. It shall be possible to re-establish a
call that was put on hold in another domain.
Multiparty CONF Any conference (multiparty) calls set up in one domain
shall remain in force if any user moves to another
domain.
Closed User Group Closed User Group Consistency required across domains
CCBS CCBS Consistency required across domains
Call Deflection Defined in CDIV Consistency required across domains
Explicit Call Transfer ECommT Consistency required across domains. The UE state (i.e.
if busy or not) shall be available in both domains to
ensure that this can be applied consistently.
Call Barring Communication Barring Call/ Communication Barring shall work consistently no
matter which domain the user is in. The settings (i.e.
barred numbers) shall remain the same across domains.
AoC AoC Consistent support across domains. If the user moves
from one domain to the other during the communication,
the AoC shall indicate the correct charge for the total
duration of the communication.

The operator shall be able to provision the user with the possibility to define which of the above settings shall be
synchronised automatically and which settings can exist independently of each other. E.g. a user might decide that
the activation status of CLIP/OIP, CLIR/OIR, Call Waiting/Communication Waiting etc. is synchronised but that the
call forwarding status and forwarded-to-number is different from the communication diversion settings and the
diverted-to-party address.

If the synchronisation of supplementary services, which use the UE's busy state for invocation, is activated the busy

3GPP
Release 15 61 3GPP TS 22.101 V15.2.0 (2017-09)

state of the UE shall be available in both domains.

Note: The "user not reachable" or "user not logged in" conditions in the different domains are independent of
each other. This means, e.g. not being registered in the IMS does not affect the invocation of CFNRc in
the CS domain.

Synchronisation of settings means that the most recent changes which have been applied in one domain are
propagated to the other domain.

There are certain circumstances under which the synchronisation will fail e.g. when a user inserts a SIP URI as
diverted-to-party address in the IMS domain which has no Tel URI associated with it. In such a case there is no valid
setting for the CS domain for this particular parameter and therefore the CS domain service setting shall remain
unchanged. The user may receive a notification about the failure of the synchronisation procedure and its cause.

3GPP
Release 15 62 3GPP TS 22.101 V15.2.0 (2017-09)

25 System optimisation for communication with specific

characteristics

25.1 Void

25.2 Numbering Resource Efficiency

The following optional requirement is intended to provide better numbering resource efficiency for UEs that only
require packet switched services.

- A network operator shall be able to provide PS only subscriptions with or without assigning an MSISDN.

- Remote triggering shall be supported with or without assigning an MSISDN.

- Remote UE configuration shall be supported without the use of an MSISDN.

Note 1: Current remote UE configuration solutions (i.e. Device Management and Over-the-Air configuration)
are mainly based on SMS, which assumes the use of MSISDNs.

Note 2: The requirements in this sub-clause apply to server-to-UE communication scenarios only.

25.3 Network provided destination for uplink data

The Network Provided Destination for Uplink Data feature is intended for use when all data from a UE is to be
directed to a network provided destination address.

- For uplink data communication, the network shall be able to direct all uplink PS data traffic to a network
provided destination address.

Note: This feature may be used, for example, when all data from an electricity meter is sent to a server maintained
by the network operator.

25.4 PS only subscriptions

The system shall support subscriptions that only allow packet based services and SMS.

3GPP
Release 15 63 3GPP TS 22.101 V15.2.0 (2017-09)

26 Single Sign-On (SSO) Service

26.1 Requirements
26.1.1 Requirements for the UE
An SSO-capable UE shall support 3GPP SSO Authentication, without user intervention, based on Operator-controlled
credentials.

An SSO-capable UE shall be able to initiate the SSO Service regardless of the access network technologies supported
by the UE.

An SSO-capable UE that supports 3GPP access and non-3GPP access shall support transparency of the SSO Service
from a user perspective during transitions between 3GPP access and non-3GPP access, whether or not the transition
occurs during a data application session.

An SSO-capable UE may support a request for SSO Local User Authentication from a Data Application Provider or
an Identity Provider to confirm the presence of the registered user of the data application.

26.1.2 Requirements for a 3GPP SSO Service

The 3GPP SSO Service shall provide secure, seamless and transparent access to data applications for users of the SSO
Service independent of the access network technology.

The 3GPP SSO Service shall be able to interwork with Identity Management (IdM) specifications (e.g., OpenID
[51]).

The 3GPP SSO Service shall support 3GPP SSO Authentication based on Operator-controlled credentials and
policies.

The 3GPP SSO Service may support negotiation and use of an agreed authentication method between the UE and the
3GPP SSO Identity Provider. The negotiation of an authentication method may be repeated each time the user
accesses a DAP's service.

The 3GPP SSO Service may support mechanisms to ensure the presence of the registered user of the data application
to satisfy policies of the Data Application Provider.

The 3GPP SSO Service shall be transparent from a user perspective when transitions occur between 3GPP access and
non-3GPP access, whether or not the transition occurs during a data application session.

The 3GPP SSO Service shall be transparent from a user perspective when the user accesses a data application using
an identity created through a 3rd Party SSO Identity Provider. The user shall be able to configure which 3rd party
SSO identities are used with the 3GPP SSO Service.

3GPP
Release 15 64 3GPP TS 22.101 V15.2.0 (2017-09)

27 User plane congestion management

27.1 Introduction
RAN user plane congestion, in the context of this clause, is considered to be downlink congestion that affects the user
plane, which may last for a few seconds, a few minutes, or a few hours due to arrival of new active users, increase of
communication intensity of existing users, the radio environment changing, the mobile user changing location, and
other reasons, thus causing the capacity of RAN resources to transfer user data to be exceeded. A short-duration burst
of user plane traffic should not be identified as RAN congestion.

27.2 General
a) The network shall be able to detect RAN user plane congestion onset and abatement. Mechanisms to cope with
RAN user plane congestions should be resilient to rapid changes in the level of congestion.

b) The network shall be able to identify whether or not an active UE is in a RAN user plane congested cell.

c) The network operator shall be able to configure or provision and enforce policy rules to best deal with RAN
user plane congestion.

d) The system should react in a timely manner to manage a RAN user plane congestion situation, i.e. that the
measures taken become effective to promptly help resolve the RAN user plane congestion.

e) The signalling overhead caused by RAN user plane congestion management solutions in the system shall be
minimized.

f) The network shall be able to take into consideration the RAN user plane congestion status and the subscriber's
profile when coping with traffic congestion.

27.3 Prioritizing traffic

a) According to operator policy, during RAN user plane congestion the operator shall be able to select the
communications which require preferential treatment and allocate sufficient resources for such
communications in order to provide these services with appropriate service quality.

b) According to operator policy, the network shall be able to select specific users (e.g. heavy users, roaming
users, etc.) and adjust the QoS of existing connections/flows and apply relevant policies to new
connections/flows depending on the RAN user plane congestion status and the subscriber's profile.

Note 1: Preferably, connections/flows need to be adjusted such that the user experience is not negatively
affected.

27.4 Reducing traffic

a) Based on RAN congestion status and according to operator policy, the network shall be able to reduce the user
plane traffic load (e.g. by compressing images or by adaptation for streaming applications) taking into account
UE related information (e.g. UE capabilities, subscription).

b) The system shall be able to adjust the communication media parameters of real-time communications so that
they consume less bandwidth.

3GPP
Release 15 65 3GPP TS 22.101 V15.2.0 (2017-09)

27.5 Void

28 RAN Sharing Enhancements

28.1 General
RAN Sharing Enhancements allow multiple Participating Operators to share the resources of a single RAN according
to agreed allocation schemes. The Shared RAN is provided by a Hosting RAN Operator which can be one of the
Participating Operators.

The Shared RAN can be GERAN, UTRAN, E-UTRAN or NG-RAN as described below.

All the following requirements shall be subject to Hosting RAN Operator configuration.

28.2 Specific E-UTRAN and NG-RAN Sharing requirements

28.2.1 Allocation of Shared E-UTRAN and NG-RAN resources
When E-UTRAN and NG-RAN resources are shared they can be allocated unequally to the Participating Operators,
depending on the planned or current needs of these operators and based on service agreements with the Hosting E-
UTRAN/NG-RAN Operator.

The following requirements apply:

The Hosting E-UTRAN/NG-RAN Operator shall be able to specify the allocation of E-UTRAN/NG-RAN resources
to each of the Participating Operators by the following:

a) static allocation, i.e. guaranteeing a minimum allocation and limiting to a maximum allocation,

b) static allocation for a specified period of time and/or specific cells/sectors,

c) first UE come first UE served allocation.

d) the type and number of 5G slices

Resources include both user plane and signalling plane. The Hosting E-UTRAN/NG-RAN Operator needs to be able
to manage the sharing of the signalling traffic independently from that of the user traffic because signalling traffic
and user traffic are not always directly related. For example for MTC devices, the signalling traffic volume can be
high and the user traffic volume low whereas for downloading video, the signalling traffic is low and the user traffic
is high.

The following requirements apply:

The management and allocation of resources of signalling traffic over the Shared E-UTRAN/NG-RAN shall be
independent from the management and allocation of resources of the user traffic over the Shared E-UTRAN.

A Shared E-UTRAN/NG-RAN shall be capable of differentiating traffic associated with individual Participating
Operators.

A Shared E-UTRAN/NG-RAN shall be able to conduct admission control based on the allocated E-UTRAN/NG-
RAN resources for each Participating Operator.

A Hosting E-UTRAN/NG-RAN Operator shall be able to control resource usage taking into account the allocated E-
UTRAN/NG-RAN resources for each Participating Operator. A means of monitoring the usage of resources shall be
provided.

All shared E-UTRAN/NG-RAN capabilities offered by the Hosting E-UTRAN/NG-RAN Operator shall be
individually available for use by each Participating Operator where this is possible.

The 3GPP System shall support a Shared RAN (E-UTRAN or NG-RAN) to cover a specific coverage area (e.g. from

3GPP
Release 15 66 3GPP TS 22.101 V15.2.0 (2017-09)

a complete network to a single cell, both outdoor and indoor).

The 3GPP System shall support service continuity for UEs that are moving between different Shared RANs or
between a Shared RAN and a non-shared RAN.

28.2.2 OA&M Access to the Shared E-UTRAN/NG-RAN

Each Participating Operator can have their own OA&M capabilities, which are used for monitoring and for selected
operations in a shared E-UTRAN/NG-RAN. Information exchange involved in those operations need to be controlled
by the Hosting E-UTRAN/NG-RAN Operator as to prevent disclosing them to other Participating Operators, be it for
business, operational, or technical reasons.

The following requirements apply:

Selected OA&M capabilities for the Shared E-UTRAN/NG-RAN, under the control of the Hosting E- UTRAN
Operator, shall be accessible by the Participating Operator's OA&M functions

This would allow, for example, the Participating Operator to do the following:

- test of communication path between the Participating Operator's network elements and the Shared E-
UTRAN/NG-RAN,

- obtain fault reports,

- retrieve RAN resource usage information.

28.2.3 Generation and retrieval of usage and accounting information

To facilitate interoperator accounting between Hosting E-UTRAN/NG-RAN Operator and Participating Operator the
Hosting E-UTRAN/NG-RAN Operator needs to record E-UTRAN/NG-RAN resource usage by UEs of the
Participating Operator.

The following requirements apply:

A Hosting E-UTRAN/NG-RAN Operator shall be able to collect events supporting the accounting of network
resource usage separately for each Participating Operator. Collected events may be delivered to the subscriber's
Participating Operator. This includes:

- start of service in the Shared E-UTRAN/NG-RAN for a UE of the Participating Operator,

- end of service in the Shared E-UTRAN/NG-RAN for a UE of the Participating Operator.

28.2.4 MDT Collection

MDT data from a Participating Operator's customer UEs allow the Hosting E-UTRAN/NG-RAN Operator to be
provided with performance measurements on his Shared E-UTRAN/NG-RAN. The Participating Operator is
responsible for obtaining and retaining any required user consent related to privacy.

The following requirements apply:

When authorized by the Participating Operators, the Hosting E-UTRAN/NG-RAN Operator shall be able to collect
MDT data of the Participating Operator's UEs connected through its E-UTRAN/NG-RAN.

Note: This functionality should also allow for the case where the Hosting E-UTRAN/NG-RAN Operator does
not have an adjunct core network.

28.2.5 PWS support of Shared E-UTRAN/NG-RAN

A Participating Operator potentially has regulatory obligations to initiate the broadcast of PWS messages regardless
of E-UTRAN/NG-RAN Sharing.

The following requirements apply:

3GPP
Release 15 67 3GPP TS 22.101 V15.2.0 (2017-09)

The Shared E-UTRAN/NG-RAN shall be able to broadcast PWS messages originated from the core networks of all
Participating Operators.

Note: Rel-11 design requires a shared PWS core. However, some regulatory obligations require a solution in
which no common PWS core network entity is involved.

28.2.6 Support for load balancing

Hosting E-UTRAN/NG-RAN Operators have the need to optimize E-UTRAN/NG-RAN resource usage within the
shared E-UTRAN/NG-RAN for a particular coverage area. At the same time, the agreed shares of E-UTRAN/NG-
RAN resources based on a single cell and sector for each Participating Operator need to be respected. Likewise,
Participating Operators have the need to optimize their E-UTRAN/NG-RAN resource usage among shared and
unshared E-UTRAN/NG-RAN for a particular coverage area.

The capability to perform load balancing on an individual Participating Operator's traffic basis within a shared E-
UTRAN/NG-RAN shall be supported.

The capability to perform load balancing on the combined traffic of all the Participating Operators within a shared E-
UTRAN/NG-RAN shall be supported.

The capability to perform load balancing between an individual Participating Operator's traffic within a shared E-
UTRAN/NG-RAN and traffic in that Participating Operator's unshared E-UTRAN/NG-RAN where the shared and
unshared E-UTRAN/NG-RAN coverage overlaps shall be supported.

Note: Load balancing capabilities are expected to take into account the allocation of resources to each
Participating Operator and the load level for each Participating Operator to the extent possible, so that
the principal objective to maximize throughput is not impacted.

If load balancing in a Shared E-UTRAN/NG-RAN is supported and if a Participating Operator’s EPC indicates
overload to the Shared E-UTRAN/NG-RAN in order to mitigate the overload situation then overload mitigation
measures shall have minimal impact on the communication between the Shared E-UTRAN/NG-RAN and other
Participating Operators EPCs.

28.2.7 Dynamic capacity negotiation

In situations where a need for additional, unplanned, E-UTRAN/NG-RAN capacity by a Participating Operator arises
(e.g. in the case of big mass-events) the Shared E-UTRAN/NG-RAN can provide means to allocate available spare
capacity to the Participating Operator. Based on service level agreement between the Hosting and Participating
operator such allocation can be automated without human intervention.

The following requirements apply:

The Participating Operator shall be able to query and request spare capacity of the Shared E-UTRAN/NG-RAN,
based on policies and without human intervention.

The Shared E-UTRAN/NG-RAN shall be able to allocate spare capacity to Participating Operator, based on policies
and without human intervention.

28.3 Specific GERAN & UTRAN Sharing Requirements

28.3.1 Allocation of Shared GERAN or UTRAN Resources
When GERAN or UTRAN resources are shared they can be allocated unequally to the Participating Operators,
depending on the planned or current needs of these operators and based on service agreements with the Hosting RAN
Operator.

The following requirements apply:

The Hosting RAN Operator shall be able to specify the allocation of GERAN or UTRAN resources to each of the
Participating Operators by the following:

3GPP
Release 15 68 3GPP TS 22.101 V15.2.0 (2017-09)

a) static allocation, i.e. guaranteeing a minimum allocation and limiting to a maximum allocation,

b) static allocation for a specified period of time and/or specific cells/sectors,

c) first UE come first UE served allocation.

The management and allocation of resources of signalling traffic over the Shared GERAN or UTRAN shall be
independent from the management and allocation of resources of the user traffic over the Shared GERAN or UTRAN.

A Shared GERAN or UTRAN shall be capable of differentiating traffic associated with individual Participating
Operators and shall be able to limit QoS available for traffic of the UEs of a Participating Operator (e.g. “best effort”
if not enough resources are available).

A Shared GERAN or UTRAN shall be able to conduct admission control based on the allocated GERAN or UTRAN
resources for each Participating Operator with a margin of tolerance.

A Hosting RAN Operator shall be able to control resource usage taking into account the allocated GERAN or
UTRAN resources for each Participating Operator. A means of monitoring the usage of resources shall be provided.

All Shared GERAN or UTRAN capabilities offered by the Hosting RAN Operator shall be individually available for
use by each Participating Operator where this is possible.

A Hosting RAN shall be able to provide an indication to each Participating Operator of how much capacity they are
allocated at any one time. Signalling and User traffic shall be separately identified.

The ability to allow a single RAN (GERAN or UTRAN) to be fully shared by a number of Participating Operators
shall be provided.

28.3.2 OA&M Access to the Shared GERAN or UTRAN

Each Participating Operator can have their own OA&M capabilities, which are used for monitoring and for selected
operations in a Shared GERAN or UTRAN. Information exchange involved in those operations need to be controlled
by the Hosting RAN Operator so as to prevent disclosing them to other Participating Operators, be it for business,
operational, or technical reasons.

The following requirements apply:

Selected OA&M capabilities for the Shared GERAN or UTRAN, under the control of the Hosting RAN Operator,
shall be accessible by the Participating Operator's OA&M functions

This would allow, for example, the Participating Operator to do the following:

- test of communication path between the Participating Operator's network elements and the Shared GERAN or
UTRAN,

- obtain fault reports,

- retrieve GERAN or UTRAN resource usage information.

28.3.3 Generation and retrieval of usage and accounting information

To facilitate inter-operator accounting between the Hosting RAN Operator and the Participating Operator, the
Hosting RAN Operator needs to record GERAN or UTRAN resource usage by UEs of the Participating Operator.

The following requirements apply:

A Hosting RAN Operator shall be able to collect events supporting the accounting of network resource usage
separately for each Participating Operator. Collected events may be delivered to the subscriber's Participating
Operator. This includes:

- start of service in the Shared GERAN or UTRAN for a UE of the Participating Operator,

- end of service in the Shared GERAN or UTRAN for a UE of the Participating Operator.

3GPP
Release 15 69 3GPP TS 22.101 V15.2.0 (2017-09)

28.3.4 MDT Collection

MDT data from a Participating Operator's customer UEs allow the Hosting RAN Operator to be provided with
performance measurements on his Shared GERAN or UTRAN. The Participating Operator is responsible for
obtaining and retaining any required user consent related to privacy.

The following requirements apply:

When authorized by the Participating Operators, the Hosting RAN Operator shall be able to collect MDT data of the
Participating Operator's UEs connected through its GERAN or UTRAN.

The Participating Operators shall be able to retrieve this data for their own subscribers from the Hosting RAN
Operator.

Note: This functionality should also allow for the case where the Hosting RAN Operator does not have an
adjunct core network.

28.3.5 PWS support of Shared GERAN or UTRAN

A Participating Operator potentially has regulatory obligations to initiate the broadcast of PWS messages regardless
of GERAN or UTRAN Sharing.

The following requirements apply:

The Shared GERAN or UTRAN shall be able to broadcast PWS.

Note: The Hosting RAN Operator is responsible for the delivery of PWS messages to the UEs.

28.3.6 Support for load balancing

Hosting RAN Operators need to optimise GERAN or UTRAN resource usage within the Shared GERAN or UTRAN
for a particular coverage area while respecting the agreed resource shares for each Participating Operator. Similarly,
Participating Operators need to optimise their GERAN or UTRAN resource usage between Shared and unshared
GERAN or UTRAN for a particular coverage area.

The Hosting RAN Operator shall have the capability to balance the Signalling and User Traffic load individually for
each Participating Operator within a Shared GERAN or UTRAN.

The capability to perform load balancing on the combined traffic of all the Participating Operators within a Shared
GERAN or UTRAN shall be provided. The agreed shares of GERAN or UTRAN resources shall be maintained.
Signalling and User traffic shall be managed independently.

The capability to perform load balancing between an individual Participating Operator's traffic within a Shared
GERAN or UTRAN and traffic in that Participating Operator's unshared GERAN or UTRAN where the Shared and
unshared GERAN or UTRAN coverage overlaps shall be supported.

The Hosting RAN Operator shall be able to balance the load across all Participating Operators.

28.3.7 Dynamic capacity negotiation

The Participating Operator shall be able to request on-demand spare capacity of the Shared GERAN or UTRAN
based on policies and without human intervention.

The Hosting RAN Operator shall be able to allocate spare on-demand capacity on the Shared GERAN or UTRAN to
a Participating Operator, based on policies and without human intervention.

The Participating Operator shall be able to request the cancellation of granted on-demand capacity requests.

The Hosting RAN Operator shall be able to cancel a granted request based on a Participating Operator’s request or
based on agreed policy.

The Hosting RAN Operator shall be able to change the amount shared by each Participating Operator based on traffic
demand. A minimum capacity (that can be set) of the Hosting RAN shall be reserved for each Participating Operator

3GPP
Release 15 70 3GPP TS 22.101 V15.2.0 (2017-09)

that cannot be allocated to other Participating Operators.

29 Service exposure with 3rd party service providers

29.1 General
The intention of service exposure is that, under the assumption of a service agreement between MNO and a 3rd party,
the 3GPP Network allows a 3rd party service provider to benefit from network provided services and capabilities that
are exposed by the PLMN. For example the 3GPP Core Network can exchange information with the 3rd party to
optimize usage and management of 3GPP resources. A standardized exposure of network services/capabilities
reduces the complexity of different 3rd parties to access different 3GPP network services and capabilities.

General requirements for service exposure with 3rd party service providers:

- The operator shall be able to provide to a 3rd party service provider secure and chargeable access to the
exposed services/capabilities i.e. to authenticate, authorize and charge the 3rd party entities.

NOTE 1: This requirement can be implemented by the existing standardised API frameworks e.g. the OMA API
framework.

- It shall be ensured that the 3GPP services/capabilities are not disclosed to unauthorised parties and that user
privacy (avoid e.g. trackable and traceable identity information of the concerned UE) is maintained subject to
user agreement, operator policy, service agreement between operator and 3rd party and regulation constraints.

- The network service/capability exposure should be generic enough to support different application needs.
Exposed 3GPP services/capabilities may use functionalities from different network entities and different 3GPP
interfaces

29.2 Exposed Services and capabilities

The 3GPP Core Network shall be able provide a standardized interface to enable exposure of the following services
and capabilities to 3rd party service providers:

Support of 3rd party requested MTC Device triggering

- The 3GPP Core Network shall support a 3rd party service provider request to trigger a UE that is served by the
3rd party service provider, the request shall include:

- a trigger payload, to provide information to the application on the UE to e.g. trigger application related
actions,

- a validity period.

NOTE 1: The 3GPP Network will attempt to deliver the trigger message to the UE until the validity period
expires.

- The 3GPP Core Network shall support the 3 rd party service provider to recall or replace a trigger message that
it has previously submitted.

NOTE 2: The goal of device triggering is that the UE takes action based on the content of the trigger payload.
This response can involve initiation of communication with an MTC Server of the 3 rd party service
provider. The UE can initiate communication immediately or later within the validity period.

Support of 3rd party interaction for 3GPP resource management for background data transfer:

- The 3GPP Core Network shall support a 3rd party service provider request for background data transfer for a
set of UEs that are served by the 3rd party service provider, indicating:

- the desired time window for the data transfer,

- the volume of the data expected to be transferred in a geographic area TS 23.032 [56].

3GPP
Release 15 71 3GPP TS 22.101 V15.2.0 (2017-09)

- Additionally, the 3rd party application server shall be able to indicate to the 3GPP System when the
background data transfer (a) exceeds the agreed maximum data volume or (b) continues beyond the agreed
time window or (c) happens outside the agreed areas – e.g. due to movement of individual UEs, whether this
background data transfer:

- shall be stopped by the 3GPP Sytem or

- shall continue, possibly under a different charging regime.

- The 3GPP Core Network shall be able to inform the 3rd party service provider in one coordinated response,
based on locally available information (e.g. congestion level) over the geographic area, about:

- one or more recommended time windows for the data transfer and

- for each time window the maximum aggregated bitrate for the set of UEs in the geographical area indicated
by the 3rd party service provider.

- Additionally, the 3GPP Core Network shall be able to inform the 3rd party service provider about the charging
policy that will be applied to the 3 rd party service provider if the data are transferred within the recommended
time window and if transmission rates stay below the limits of the respective maximum aggregated bitrate .

- The goal of providing the time window is to favour transfer of more traffic during non-busy hours and reason
for providing the maximum aggregate bitrate is to spread out traffic during that time. The goal of multiple
time windows is to allow the 3rd party provider to choose one appropriate time window based on its
preference like the expected charging regime and bitrate.

Support of 3rd party interaction on information for predictable communication patterns of a UE:

- The 3GPP Core Network shall enable a 3rd party service provider to provide information about predictable
communication patterns of individual UEs or groups of UEs that are served by this 3rd party service provider.
Such communication patterns may include:

- Time and traffic volume related patterns (e.g. repeating communication initiation intervals, desired ‘keep
alive’ time of data sessions, average/maximum volume per data transmission, etc.).

- Location and Mobility related patterns (e.g. indication of stationary UEs, predictable trajectories of UEs,
etc.).

- This information may be used by the 3GPP system to optimize resource usage.

Support of 3rd party requested session QoS and priority

- The 3GPP Core Network shall enable a 3rd party service provider to request setting up data sessions with
specified QoS (e.g. low latency or jitter) and priority handling to a UE that is served by the 3rd party service
provider.

Support of 3rd party requested broadcast

- The 3GPP Core Network shall enable a 3rd party service provider to request sending a broadcast message in a
specified geographic area (as specified in TS 22.368 [52]) expecting to reach a group of devices that are served
by the 3rd party service provider.

Informing the 3rd party about potential network issues

- The 3GPP Core Network shall be able to indicate to a 3rd party service provider when data transmissions have
a risk of incapability to provide expected throughput and/or QoS in a specific area (e.g. due to forecasted high
traffic load in that area). Additionally, an estimate may be given when the high traffic load is expected to be
mitigated.

Informing the 3rd party about UE status

- The 3GPP Core Network shall be able to provide the following information about a UE that is served by the 3 rd
party service provider:

- Indication of the of the roaming status (i.e. Roaming and No Roaming) and the serving network, when the
UE starts/stops roaming,

3GPP
Release 15 72 3GPP TS 22.101 V15.2.0 (2017-09)

- Loss of connectivity of the UE,

- Change or loss of the association between the ME and the USIM,

- Communication failure events of the UE visible to the network (e.g. for troubleshooting).

- Reporting when the UE moves in/out of a geographic area that is indicated by the 3rd party,

- Reporting when the UE changes Routing Area / Tracking Area / Location Area / Cell.

- Reporting when the UE changes the status of 3GPP PS Data Off.

Note: The area indicated by a 3rd party service provider can be mapped to the area used in the 3GPP network,
i.e. a list of LAs/RAs/TAs/cells. The 3rd party service provider can define a geographical area as shapes
(e.g. polygons, circles) or civic addresses (streets, districts…) as referenced by OMA Presence API [53]
e.g. defined by shape areas of IETF RFC-5491 [54] or by civic addresses defined in IETF RFC-5139
[55].

- The 3rd party service provider shall be able to request a one time reporting or reporting at defined times (e.g.
regular intervals, certain pre-defined time points) on the number of UEs present in a certain area and the
location of each UE as for a Location Based Service.

- Subject to user consent, operator policy and regulatory constraints, the user privacy shall be maintained when
passing location information to a 3rd party service provider.

Informing the 3rd party about a UE’s connection properties

- The 3GPP Core Network shall be able to inform a 3rd party about a UE’s connection properties.

Note: Connection properties of a UE describe the average data rate range or non-absolute value (e.g. high,
medium or low) that the UE is likely to be able to obtain at the current location. The connection
properties can, for example, be generated from the UE’s RAT type the UE is currently attached to, the
load conditions at its current location and/or other parameters.

Support for non-IP small data transfer with a 3rd party

- The 3GPP Core Network shall support a 3 rd party for submiting a small amount of non-IP data for delivery to a
UE.

- The 3GPP Core Network shall support a 3 rd party application server for receiving a small amount of non-IP
data delivered from a UE.

- The 3GPP Core Network shall support a 3 rd party to configuring non-IP data delivery for a particular UE (e.g.
destination address, maximum number of messages, duration for which configuration applies).

Note: The use of the Non-IP Data Delivery feature via Service Capability Exposure Function assumes that the
UE has indicated support for ‘non-IP data transfer’ and in case the Service Capability Exposure
Function is used there will be no user plane EPS bearer established.

30 Flexible Mobile Service Steering

30.1 Introduction
In order to realize efficient and flexible mobile service steering in (S)Gi-LAN, the network operator uses information
(e.g. user profile, network operator’s policies, RAT type, application characteristics) to define traffic steering
policies. These policies are used to steer the subscriber’s traffic to appropriate enablers (e.g. NAT, antimalware,
parental control, DDoS protection) in the (S)Gi-LAN.

The term (S)Gi-LAN used in the present document represents a system which is out of 3GPP scope.

3GPP
Release 15 73 3GPP TS 22.101 V15.2.0 (2017-09)

30.2 General Requirements

The following requirements apply:

- The 3GPP Core Network shall be able to define and modify traffic steering policies that are used to steer
traffic in (S)Gi-LAN containing operator or 3rd party service functions e.g. to improve e.g. the user’s QoE,
apply the bandwidth limitation and provide valued added services.

- Traffic steering policy shall be able to distinguish between upstream and downstream traffic.

- The 3GPP Core Network shall be able to define different traffic steering policies for a user’s traffic on a per
session basis (e.g. for applying parental control, anti-malware, DDoS protection, video optimization).

- The 3GPP Core Network defines traffic steering policies based on one or more pieces of information such as:

- network operator’s policies

- user subscription (e.g. user’s priority, the status of optional subscriber services from the subscription data,
based on service provider used, subscribed QoS)

- user's current RAT

- the network (RAN and CN) load status

- application characteristics such as: application type (video, web browsing, IM, etc), application protocol (
HTTP, P2P, etc), target address name (URL) and application provider (My tube, etc)

- time

- UE location

- information (e.g. APN) of the destination network (i.e. a PDN or an internal IP network) of traffic flow

- In case of roaming, the HPLMN shall be able to apply traffic steering policies for home routed traffic.

Note: Traffic steering policies for local breakout is not specified.

3GPP
Release 15 74 3GPP TS 22.101 V15.2.0 (2017-09)

31 Control of traffic from UE-based applications toward

associated server

31.1 Description
This feature is a set of service features that allows operators to control traffic from UEs to an application on a third
party server or the third party server itself. When an application on a third party server or the third party server itself
becomes congested or fails the traffic towards that server need to be controlled to avoid/mitigate potential issues
caused by resulting unproductive use of 3GPP network resource. This will also make it possible to allow 3GPP
network to help third party servers to handle overload and recover from failures. (see [11])

31.2 Requirements
31.2.1 Control requirements
The 3GPP network shall be able to control (i.e. block and/or prioritize) traffic from UEs to an application on a third
party server or the third party server itself without affecting traffic to other applications on the third party server or to
other third party servers.

For this purpose, the 3GPP network shall be able to identify the third party server or the application on the third party
server, and the traffic towards it.

When congestion or failure of the application on the third party server or the third party server abates the 3GPP
network shall be able to apply this feature in a phased manner to gradually restore traffic according to operator
policy.

The 3GPP network shall be able to control traffic through this feature based on:

(1) the traffic load on the 3GPP network,

(2) the MNO policy,
(3) the MNO’s service subscription profiles such as access class information, and
(4) third party service subscription profiles

without impacting the traffic to other applications on the third party server or other third party servers.

31.2.2 Requirements on awareness of third party server issue

The 3GPP network shall be able to receive a status indication from the third party server when an application on it is
experiencing congestion or failure, and when normal operation resumes. Such a status indication may be sent
periodically, and/or when the status of the application changes.

The 3GPP network shall be able to detect and monitor a third party server’s operational status e.g. congestion levels,
failure and unavailability of the third party server.

32 3GPP enhancement for TV application support

32.1 Feature description

3GPP enhancement for TV service support is a feature whereby 3GPP networks can provide unicast and broadcast
transport, referred to as “TV transport services”, to support distribution of TV programs. TV transport services can
support the three types of TV services – Free-to-air (FTA), Free-to-view (FTV), and Subscribed services. Each type
of TV service has different requirements in order to meet regulatory obligations and public service and commercial
broadcaster’s requirements regarding content distribution, hence many requirements captured below are optional to
implement depending on the type of TV transport services an MNO chooses to offer.

3GPP
Release 15 75 3GPP TS 22.101 V15.2.0 (2017-09)

32.2 Requirements
32.2.1 General requirements
The 3GPP network shall be able to support on-demand network capacity assignment for TV services.

The 3GPP system shall allow the MNO to implement a network supporting downlink only broadcasting based on a set
of EPS functionalities and entities which are required to offer linear TV services.

The 3GPP network shall be able to support on-demand network broadcast service area coverage management for TV
transport services.

The 3GPP network shall support content delivery up to UHD resolution.

The 3GPP network shall allow the MNO to authenticate a subscriber before providing TV transport services via
unicast.

The 3GPP network shall allow the MNO to authenticate a subscriber before providing TV transport services via
eMBMS broadcast.

The 3GPP network shall enable an MNO to allow a UE to receive TV transport services via eMBMS broadcast
without authentication.

The 3GPP network shall be able to provide FTA TV services receivable by UEs subscribed to the MNO and roaming
UEs of other MNOs. A UE supporting enhanced TV transport services and in limited service state shall be able to
receive eMBMS broadcast TV transport services.

The 3GPP network shall provide the ability for an MNO to meet regulatory requirements for privacy and non-
identification of a receiving user by entities outside of the MNO.

NOTE: The MNO is responsible for maintaining the privacy of personal usage data collected as a result of
providing access to the TV services.

The 3GPP network shall provide mechanisms to restrict the reception of some or all Subscribed TV services to groups
of subscribers (e.g. based on the recipients of the services are subscribers of the MNO, roaming subscribers of other
MNOs, or not subscribed to any MNO).

The quality of experience of the TV service shall be independent from the size of the concurrent audience. While
receiving TV services in normal service state, subscribers of the MNO and roaming subscribers shall be able to access
other subscribed services such as voice, data or SMS.

The 3GPP network shall support combinations of SD, FHD and UHD resolution TV transport services.

The 3GPP network shall allow the MNO to provide a TV service in a resource efficient manner over a large area up
to the size of a country.

The 3GPP network shall enable the quality of experience of the TV service to be ensured throughout the coverage
area defined for the TV service.

32.2.2 Requirement for transmission performance enhancement

The 3GPP system shall be able to support 20Mbps over one logical broadcast channel.

The mechanisms in the 3GPP network shall be designed to support at least 10 high quality video channels of 12Mbps
each simultaneously via broadcast.

The 3GPP network shall support flexible change between broadcast and unicast per traffic demand over the same
carrier.

The 3GPP network shall be able to convert network unicast capacity to network broadcast capacity and vice versa so
that each can range from 0% to 100% of the capacity.

The 3GPP network shall be able to support using one carrier for both unicast and broadcast distribution of TV
services.

3GPP
Release 15 76 3GPP TS 22.101 V15.2.0 (2017-09)

If allowed by the operator and a spare carrier is available, the 3GPP network shall be able to make use of spare
carriers or free up carriers if not required anymore.

32.2.3 Requirement for network flexibility

The 3GPP network shall be able to support network broadcast capacity assignment according to operator policies to
consider the following criteria:

- OTT provider request (including TV service information(e.g., codec information, media type information,
etc))

- available network unicast/broadcast capacity of 3GPP network

Within the radio resources dedicated to TV services in a geographic area the 3GPP network shall allow the MNO to
specify the allocation of radio resource by the following:

- static allocation, i.e., pre-defined maximum percentage to be used for unicast and broadcast

- dynamic allocation, i.e., the pre-defined maximum percentage for both unicast and broadcast to be changed
at a time-resolution of [one] minute over a period of [24] hours

The 3GPP network shall be able to support network broadcast geographic area coverage management considering
following criteria:

- OTT provider request (including the potential coverage information of TV service information)

- available network unicast/broadcast capacity of 3GPP network

- number of users under broadcast network coverage

- The location information of UE

The 3GPP network shall be able to deliver media content via unicast and broadcast in an efficient manner. The 3GPP
system shall be capable of ensuring the timing sequence of different media content received by different UEs at the
same location, even via different transport path, aligning with the timing sequence of TV service of the OTT provider
in order to maintain synchronism.

A UE shall be able to receive eMBMS from one cell site while receiving other services from the same cell site or
another possibly cell site.

The 3GPP network shall allow a MNO to service all UEs in an area with eMBMS independent of which MNO
network(s) they have subscription to.

32.2.4 Requirement for TV application support

The eMBMS service layer should support audio and video formats typically supported by TV Content Providers for
SD and HD TV transport services and UHD TV transport services.

The eMBMS service layer should support codecs typically supported by TV Content Providers for HD TV services
and UHD TV services. The eMBMS service layer should support accessibility functions typically supported by TV
Content Providers (e.g. subtitling, closed captioning, audio descriptions, anonymous reception, reporting to support
ratings, reporting enforcement, etc.).

The eMBMS service layer should support regulatory mandates typically supported by TV Content Providers
(blackouts, emergency alerts, etc.).

The eMBMS service layer should support interactivity functions typically supported by TV Content Providers
(interactive services, second screen, personalization, etc.).

The eMBMS service layer should support ad insertion use cases typically supported by TV Content Providers
(targeted ad insertion, ad replacement, etc.),

The eMBMS service layer should support encryption, security and conditional access functions typically supported by
TV Content Providers.

3GPP
Release 15 77 3GPP TS 22.101 V15.2.0 (2017-09)

The eMBMS service layer should support efficient concurrent delivery of multiple application components (TV
service application signalling, statistical multiplexing, etc.).

The eMBMS service layer should support random access and channel change times comparable to existing HD TV
services.

The eMBMS service layer should support TV service content delivery over broadcast only, unicast only and
combinations of the two.

The eMBMS service layer should support delivery of real-time and non-real-time content.

The eMBMS service layer should enable extensibility and forward-compatibility to new requirements, formats,
codecs and other functions to the extent possible.

An eMBMS transport layer should be able to transport TV streams formatted not compliant to 3GPP standards.

A UE should be able to access an eMBMS transport session with the support of only transport metadata.

An eMBMS system should be able to be initiated by a UE with sufficient metadata provided by a mechanism other
than User Service Description for non 3GPP transport services.

32.2.5 Requirement for RAN sharing

A participating eMBMS-enabled RAN shall be capable of distributing the content including both free-to-air content
and subscribed content in conjunction with other participating eMBMS-enabled RANs.

The hosting eMBMS-enabled RAN network provider shall be able to manage the shared eMBMS network to each of
the participating MNOs.

Each RAN provider shall report events supporting the accounting of network resource usage separately for each
Participating MNO. This includes:

- Start of service in the shared eMBMS network for a UE of the Participating MNO

- End of service in the shared eMBMS network for a UE of the Participating MNO

32.2.6 Requirement for wide area support

The eMBMS network shall be able to support designated coverage area, for example national, regional and local
coverage areas.

32.2.7 Requirement for capability exposure

The 3GPP system shall be able to support an MNO offering on-demand broadcast availability to TV services.

Subject to MNO and 3rd OTT party agreement, to enable the MNO to evaluate the impact on distribution of data
transfer in the network, the 3rd OTT party shall be able to indicate to the MNO the desired media format information:
the volume of the data traffic expected to be broadcast in this geographic area, indication whether the streaming
content can be accessed when the mobile users moves out/in of broadcast coverage area, indication whether the
streaming content can be cached in the MNO network, association information among users i.e. user information,
expected media content information, device information and group information of TV service and the timing
relationship information of different media content.

The 3GPP network shall enable an MNO to inform a 3rd party of the result (e.g., selected media format information,
mode of content delivery (broadcast only, broadcast/unicast fall-back support, consumption-based switching between
unicast/broadcast), QoE of content delivery, cached content indication) of delivering a TV service to a user.

32.2.8 Fixed reception for TV services

The 3GPP network shall allow a UE to receive a broadcast TV content using existing TV antenna equipment.

NOTE 1: “existing TV antenna equipment” means rooftop or indoor antennas directly connected to a TV or set-
top box typically used to receive DTT signals

3GPP
Release 15 78 3GPP TS 22.101 V15.2.0 (2017-09)

The 3GPP network shall allow a UE to receive unicast TV content using existing TV antenna equipment, at least for
the downlink

NOTE 2: This might imply the uplink to take another path e.g. via a different antenna if existing TV antenna
equipment is not suitable for transmission.

33 Usage over unlicensed access

33.1 Description
It is important to document usage over unlicensed access such that an operator has the facility to determine which
type of access the traffic was transported over.

For example, LTE-WiFi Aggregation (LWA) and License Assisted Access (LAA) are two features whereby a UE is
connected to two access technologies at the same time, i.e., a primary access and a secondary access, where the
secondary access technology operates in unlicensed spectrum.

33.2 Requirements
The 3GPP network shall be able to identify traffic which was transported over unlicensed access.

34 Restricted local operator services

34.1 Description
Access to restricted local operator services by unauthenticated UEs is based on FCC regulations in the U.S. related to
manual roaming as noted in the Code of Federal Regulations (CFR) Title 47 Chapter 1 Subchapter B Part 20 Section
20.3 and the Code of Federal Regulations (CFR) Title 47 Chapter 1 Subchapter B Part 20 Section 20.12 (Resale and
Roaming) Subparagraph c [59].

The restricted local operator services offered by an operator are out of scope of 3GPP. Allowing access to restricted
local operator services is completely under the local operator’s control. The local operator can restrict
unauthenticated UEs to be able to access restricted local operator services exclusively.

Authenticated UEs may also be able to use restricted local operator services.

34.2 Requirements
Based on operator policy and national regulations, the 3GPP system shall support a mechanism to indicate to UEs
that restricted local operator services are available.

Based on operator policy and national regulations, the 3GPP system shall be able to support a mechanism to
configure a set of addresses (e.g., phone number, captive portal) in the PLMN for access to restricted local operator
services.

Based on operator policy and national regulations, the 3GPP system shall support mechanisms to allow access to
restricted local operator services by unauthenticated UEs.

The network shall be able to isolate restriced local operator services and usage from the rest of the network (e.g.,
similar to security for unauthenticated CS or IMS emergency calls).

Access to local operator services shall not affect the UICC.

When a UE recognizes an origination attempt to a restricted local operator service and has not received an indication
from the serving system that restricted local operator services are available, the UE shall block the origination
attempt.

3GPP
Release 15 79 3GPP TS 22.101 V15.2.0 (2017-09)

Annex A (normative):
Description of optional user equipment features

A.1 Display of called number

This feature enables the caller to check before call setup whether the selected number is correct.

A.2 Indication of call progress signals

Indications shall be given such as tones, recorded messages or visual display based on signalling information returned
from the PLMN. On data calls, this information may be signalled to the DTE.

Call progress indicators are described in 3GPP TS 22.001 [4].

A.3 Country/PLMN indication

The country/PLMN indicator shows in which PLMN the UE is currently registered. This indicator is necessary so that
the user knows when "roaming" is taking place and that the choice of PLMN is correct. Both the country and PLMN
will be indicated. When more than one visited PLMN is available in a given area such information will be indicated.

The PLMN name is either:

- Stored in the ME and associated with the MCC+MNC combination received on the broadcast channel;

- NITZ (see 22.042 [17]) (in which case it overrides the name stored in the UE);

- stored in the USIM in text and /or graphic format and associated with the MCC+MNC combination, and
optionally the LAI, received on the broadcast channel (in which case it overrides the name stored in the UE
and – if present – the NITZ name).

It shall be possible to store on the USIM at least 10 PLMN Identifications (MCC+MNC combination and optionally
the LAI) for which the same PLMN name shall be displayed.

The PLMN name stored in the USIM has the highest priority, followed by the PLMN name provided by NITZ. The
PLMN name stored in the ME has the lowest priority.

If the PLMN name stored in the USIM is not available in text format and the UE is unable to display the graphic
format, the PLMN name provided by NITZ has the highest priority, the PLMN name stored in the ME has the next
priority.

A.4 Service Provider Name indication

The service provider name is stored in the USIM in text and/or optionally graphic format. It shall be possible to
associate at least 10 PLMN Identifications (MCC+MNC combination) with the same SP Name.

When registered on the HPLMN, or one of the PLMN Identifications used for Service Provider Name display:

(i) The SP Name shall be displayed;

(ii) Display of the PLMN Name is an operator's option by setting the appropriate fields in the USIM (i.e. the
Service Provider name shall be displayed either in parallel to the PLMN Name or instead of the PLMN Name).

When registered on neither the HPLMN, nor one of the PLMN Identifications used for Service Provider Name
display:

(i) The PLMN name shall be displayed;

3GPP
Release 15 80 3GPP TS 22.101 V15.2.0 (2017-09)

(ii) Display of the SP Name is an operator's option by setting the appropriate fields in the USIM.

If the UE is unable to display the full name of the Service Provider the name is cut from the tail end. The storage of
Service Provider name and options, and choice of options, shall be under control of the network operator.

A.4a Core Network Operator Name indication

It shall be possible for the UE to display the name of the core network operator the user has selected.

A.5 Keypad
A physical means of entering numbers, generally, though not necessarily, in accordance with the layout shown in
figure A.1.

See also 3GPP TS 22.030 [6] (Man-Machine Interface).

Additional keys may provide the means to control the UE (e.g. to initiate and terminate calls).

1 2 3

4 5 6

7 8 9

* 0 #

Figure A.1

A.6 Short message indication and acknowledgement

This feature allows the delivery of short messages to a UE from a service centre. Such messages are submitted to the
service centre by a telecommunications network user who can also request information of the status of the message
by further interrogation of the service centre. The service centre then transmits the message to an active UE user.

The UE must therefore provide an indication to the user that a message has been received from the service centre and
must also send an acknowledgement signal to the PLMN to show that this indication has been activated. The PLMN
then returns this acknowledgement to the service centre.

The short message service teleservice is described in specification 3GPP TS 22.003 [14].

A.7 Short message overflow indication

An indication shall be given to the user of the short message service when an incoming message cannot be received
due to insufficient available memory.

A.8 International access function

Provision is made for a direct, standard method of gaining international access. For this purpose the UE may have a
key whose primary or secondary function is marked "+". This is signalled over the air interface and would have the
effect of generating the international access code in the network. It may be used directly when setting up a call, or

3GPP
Release 15 81 3GPP TS 22.101 V15.2.0 (2017-09)

entered into the memory for abbreviated dialling.

This feature is of benefit since the international access code varies between CEPT countries, which might cause
confusion to a user, and prevent the effective use of abbreviated dialling when roaming internationally. Users may
still place international calls conventionally, using the appropriate international access code.

A.9 Service Indicator (SI)

An indication is given to the user that there is adequate signal strength (as far as can be judged from the received
signal) to allow a call to be made. Additionally the network should be capable of providing, and the UE may display,
an indication of the serving cells' capabilities e.g. GPRS, HSDPA, HSUPA.

If indicated by the registered network, the UE in idle mode may display an indication of one of the radio access
technologies provided to the UE in the network on which the UE is registered with the following priority order: E-
UTRAN, UTRAN, GERAN.

Displaying the serving cell's capabilities and the access technology are mutually exclusive.

A.10 Dual Tone Multi Frequency (DTMF)

The UE shall be capable of initiating DTMF in accordance with specifications 3GPP TS 22.003 [14]. Optionally, the
UE may provide a suppress function which allows the user to switch off the DTMF function.

A.11 On/Off switch

The UE may be provided with a means of switching its power supply on and off. Switch-off shall be "soft", so that on
activation, the UE completes the following housekeeping functions: termination of a current call, detach (where
applicable) and storing required data in the SIM/USIM before actually switching off. As far as possible, this
procedure should also apply on power failure (e.g. remote switch-off or low battery).

A.12 Sub-Address
This feature allows the mobile to append and/or receive a sub-address to a Directory Number, for use in call set-up,
and in those supplementary services that use a Directory Number.

A.13 Short Message Service Cell Broadcast

The Short Message Service Cell Broadcast enables the mobile equipment to receive short messages from a message
handling system.

The short message service cell broadcast teleservice is described in specification 3GPP TS 22.003 [14]

A.14 Short Message Service Cell Broadcast DRX

This feature enables a mobile equipment to save on battery utilization, by allowing the mobile equipment to not listen
during the broadcast of messages the subscriber is not interested in.

A.15 Support of the extended Short message cell broadcast

channel
This feature allows a mobile equipment by supporting of the extended Short message cell broadcast channel to
enhance the capacity of the service. The support of the extended channel has low priority, i.e. the UE can interrupt
the reading of this channel if idle mode procedures have to be executed.

3GPP
Release 15 82 3GPP TS 22.101 V15.2.0 (2017-09)

A.16 Network Identity and Timezone

The feature provides the means for serving PLMNs to transfer current identity, universal time and the local timezone
to mobile equipments, and for the mobile equipments to store and use this information. This enhances roaming by
permitting accurate indication of PLMN identities that are either newer than the ME or have changed their name
since the ME was sold. Additionally time and timezone information can be utilized by MEs as desired.

The network name time and timezone information will normally be transferred from the network to the ME:

1) Upon registering on the network.

2) When the UE geographically relocates to a different Local Time Zone.

3) When the network changes its Local Time Zone, e.g. between summer and winter time.

4) When the network changes its identity.

5) At any time during a signalling connection with mobile equipment.

Further details of this feature are described in 3GPP TS 22.042 [15].

A.17 Network's indication of alerting in the UE

This feature provides the means for serving PLMNs to transfer to a UE an indication that may be used by the UE to
alert the user in a specific manner in the following cases:

- mobile terminating call

- network initiated USSD

- network initiated Mobile Originated (MO) connection, if the ME supports the "network initiated MO
connection " feature.

Eight different indications are defined, whether the mobile terminating traffic is a call or USSD or related to the
network initiated MO connection procedure. These indications are sent by the network and received by the UE:

- Three of these indications are used as levels, reflecting some kind of urgency: level 0 indicates that the UE
shall not alert the user for USSD and remain silent in the case of call, level 2 shall be considered by the UE as
more important than level 1 for the purpose of alerting the user.

- The five other indications are used as categories, identifying different types of terminating traffic. The UE
shall inform the user in a specific manner for each of these five categories. Nevertheless, the possible forms of
the alert (different ringing tones, displayed text, graphical symbols...) is still up to the mobile manufacturer
(some forms of alerts can be simultaneously used, e.g. ringing tones and text on the display).

The management of the feature by the UE requires for the handling of categories that :

- the SIM/USIM stores for each category an informative text (maximum 25 characters per category) describing
the type of terminating traffic associated with the category. This information could be used by the UE when
alerting the user (display on the screen). It is necessary for the network operator to be able to change the
meaning of each category.

- The user has the ability to set up his/her own association between the type of terminating traffic (identified by
each category) and the different types of alert provided by the UE. To help the user in this choice, the UE uses
the informative text associated with each category (as stored in the SIM/USIM). The UE should keep this
association when switched off.

Default settings should also be defined in the ME for the following cases :

- when the UE receives a call, USSD or a request for a network initiated MO connection with no alerting
indication,

- when the UE receives a call, USSD or a request for a network initiated MO connection with a category of

3GPP
Release 15 83 3GPP TS 22.101 V15.2.0 (2017-09)

alerting not defined in the SIM/USIM.

These default settings should be separated per type of mobile terminated traffic received (call, USSD or
request for a network initiated MO connection).

A UE supporting the feature shall act according to the following points in case of mobile terminating traffic :

- when a mobile terminating traffic is received without any indication (level or category), the ME shall act as if
it was not supporting the feature, i.e. use a default alert (e.g. associated with this type of mobile terminating
traffic).

- if a level is indicated, the UE shall use an alert enabling the user to differentiate between the three levels.

- if a category is indicated, then :

- if the SIM/USIM used in the UE does not store any information on that feature, the UE shall ignore the
category received with any mobile terminating traffic and act as if it was not supporting the feature, i.e. use
a default alert (e.g. associated with this type of mobile terminating traffic).

- if the category is not defined in the SIM/USIM, the UE shall act as if it was not supporting the feature, i.e.
use a default alert (e.g. associated with this type of mobile terminating traffic).

- if the category is defined in the SIM/USIM, the UE shall use the alert associated with this category. In
addition, it would be very useful for the user to be notified of the informative text associated with this
category (e.g. on the display).

Some interactions between this feature and other services related to alerting are described below :

- the call waiting service has priority on this feature, i.e. the call waiting tone will be played and not the alert
derived by this feature. If possible, two different indications should be given to the user (e.g. the call waiting
tone and a text on the display indicating call waiting, and in addition a text relative to the type of the new call
received).

- the presentation of the calling line identity takes priority on this feature, if it is not possible to display this
information and another information related to this feature.

- In case of interaction between this feature and UE specific features to alert the user (e.g. whole silent mode),
the user should still be able to differentiate between the different levels or different types of terminating
traffic, even if the alert itself may be changed.

A.18 Network initiated Mobile Originated (MO) connection

The "Network Initiated Mobile Originated connection" feature allows the network to ask the mobile equipment to
establish a mobile originated connection. The serving PLMN provides the mobile equipment with the necessary
information which is used by the mobile equipment to establish the connection.

Currently only the network initiated mobile originated call feature is specified. It is mandatory for a UE supporting
CCBS and is used in the case of a CCBS recall.

A.19 Abbreviated dialling

The directory number or part of it is stored in the mobile equipment together with the abbreviated address. After
retrieval the directory number may appear on the display.

Abbreviated dialling numbers stored in the UE or USIM may contain wild characters.

If wild characters are used to indicate missing digits, each wild character shall be replaced for network access or
supplementary service operation, by a single digit entered at the keypad. The completed directory number is
transmitted on the radio path.

3GPP
Release 15 84 3GPP TS 22.101 V15.2.0 (2017-09)

A.20 Barring of Dialled Numbers

This feature provides a mechanism so that by the use of an electronic lock it is possible to place a bar on calling any
numbers belonging to a pre-programmed list of numbers in the SIM/USIM.

Barred Dialling Numbers stored in the /USIM may contain wild characters.

Under control of PIN2, "Barred Dialling Mode" may be enabled or disabled. The selected mode is stored in the
SIM/USIM.

Under PIN2 control, it shall be possible to add, modify or delete a particular "Barred Dialling Number" (BDN) and to
allocate or modify its associated comparison method(s). This BDN may have the function of an abbreviated dialling
number / supplementary service control (ADN/SSC), overflow and/or sub-address.

When BDN is inactive, no special controls are specified, and the barred dialling numbers may be read (though not
modified or deleted, except under PIN2 control) as if they were normal abbreviated dialling numbers. Access to
keyboard and normal abbreviated dialling numbers (including sub-address) is also permitted.

When Barring of Dialled Numbers is active:

- Considering a number dialled by the user, if it exists a BDN for which there is a successful comparison (see
below) between that BDN and the dialled number, then the ME shall prevent the call attempt to that number.
If there is no BDN to fulfil those conditions, the call attempt is allowed by the ME.

With each BDN is associated one (or a combination of) comparison method(s) used between that BDN and the
number dialled by the user. At least three different comparison methods are possible:

- The comparison is made from the first digit of that BDN, from the first digit of the dialled number and for a
number of digits corresponding to the length of the BDN.

- The comparison is made from the first digit of that BDN, from any digit of the dialled number and for a
number of digits corresponding to the length of the BDN.

- The comparison is made backwards from the last digit of that BDN, from the last digit of the dialled number
and for a number of digits corresponding to the length of the BDN.

- If a BDN stored in the SIM/USIM contains one or more wild characters in any position, each wild character
shall be replaced by any single digit when the comparison between that BDN and the dialled number is
performed.

- If a BDN contains a sub-address, and the same number without any sub-address or with that sub-address is
dialled, the ME shall prevent the call attempt to that number.

- Numbers specified as "barred" may only be modified under PIN2 control.

- If the ME does not support barring of dialled numbers, the UE with a BDN enabled USIM shall not allow the
making of calls and the UE with BDN enabled SIM shall not allow the making or receiving of calls. However,
this feature does not affect the ability to make emergency calls.

If "Fixed Number Dialling" and "Barring of Dialled Numbers" are simultaneously active, the dialled number shall be
checked against the two features before the ME allows the call attempt. In that case, a dialled number will only be
allowed by the ME if it is in the FDN list and if the comparison between that number and any number from the BDN
list is not successful.

The UE may support other selective barrings, e.g. applying to individual services (e.g. telephony, data transmission)
or individual call types (e.g. long distance, international calls).

3GPP
Release 15 85 3GPP TS 22.101 V15.2.0 (2017-09)

A.21 DTMF control digits separator

Provision has been made to enter DTMF digits with a telephone number, and upon the called party answering the UE
shall send the DTMF digits automatically to the network after a delay of 3 seconds (± 20 %). The digits shall be sent
according to the procedures and timing specified in 3GPP TS 24.008 [13].

The first occurrence of the "DTMF Control Digits Separator" shall be used by the ME to distinguish between the
addressing digits (i.e. the phone number) and the DTMF digits. Upon subsequent occurrences of the separator, the UE
shall pause again for 3 seconds (± 20 %) before sending any further DTMF digits.

To enable the separator to be stored in the address field of an Abbreviated Dialling Number record in the SIM/USIM,
the separator shall be coded as defined in 3GPP TS 31.102 [19]. The telephone number shall always precede the
DTMF digits when stored in the SIM/USIM.

The way in which the separator is entered and display in the UE, is left to the individual manufacturer's MMI.

MEs which do not support this feature and encounter this separator in an ADN record of the SIM/USIM will treat the
character as "corrupt data" and act accordingly.

A.22 Selection of directory number in messages

The Short Message Service (SMS), Cell Broadcast Service (CBS), Multimedia Message Service (MMS), Network
Initiated USSD or Network Response to Mobile Originated USSD message strings may be used to convey a Directory
Number, which the user may wish to call.

A.23 Last Numbers Dialled (LND)

The Last "N" Numbers dialled may be stored in the SIM/USIM and/or the ME. "N" may take the value up to 10 in the
SIM/USIM. It may be any value in the ME. The method of presentation of these to the user for setting up a call is the
responsibility of the UE but if these numbers are stored in both the SIM/USIM and the UE, those from the SIM/USIM
shall take precedence.

A.24 Service Dialling Numbers

The Service Dialling Numbers feature allows for the storage of numbers related to services offered by the network
operator/service provider in the SIM/USIM (e.g. customer care). The user can use these telephone numbers to make
outgoing calls, but the access for updating of the numbers shall be under the control of the operator.

Note: No MMI is envisaged to be specified for these numbers and it is left to mobile manufacturer
implementations.

A specific example of Service Dialling Numbers is the storage of mailbox dialling numbers on the SIM/USIM for
access to mailboxes associated with Voicemail, Fax, Electronic Mail and Other messages.

A.25 Fixed number dialling

This feature provides a mechanism so that by the use of an electronic lock it is possible to place a bar on calling any
numbers other than those pre-programmed in the SIM/USIM.

Under control of PIN 2, "Fixed Dialling Mode" may be enabled or disabled. The mode selected is stored in the
SIM/USIM.

Fixed Dialling Numbers (FDNs) are stored in the SIM/USIM in the Fixed Dialling Number field. FDN entries are
composed of a destination address/Supplementary Service Control. Destination addresses may have the format
relevant to the bearer services/teleservices defined in [21] and [14]. FDN entries may take the function of an
Abbreviated Dialling Number/Supplementary Service Control (ADN/SSC), Overflow and/or sub-address. Fixed
Dialling Numbers stored in the SIM/USIM may contain wild card characters.

The Fixed Dialling feature is optional, however when Fixed Dialling Mode is enabled, an ME supporting the feature

3GPP
Release 15 86 3GPP TS 22.101 V15.2.0 (2017-09)

shall;

- Prevent the establishment of bearer services/teleservices to destination addresses which are not in FDN entries
on a per bearer service/teleservice basis. The list of bearer services/teleservices excluded from the FDN check
shall be stored in the SIM/USIM. Those bearer services/teleservices are characterised by their service code as
described in [23]. For instance if the SMS teleservices is indicated in this list, SMS can be sent to any
destination. By default, the ME shall prevent the establishment of any bearer service/teleservice to destination
addresses which are not in FDN entries.

- Only allow modification, addition or deletion of Fixed Number Dialling entries under control of PIN2.

- Allow the establishment of bearer services/teleservice to destination addresses stored in FDN entries. For
SMS, the Service Center address and the end-destination address shall be checked.

- Support the reading and substitution of wildcards in any position of an FDN entry, via the ME MMI.

- Allow the user to replace each wildcard of an FDN entry by a single digit, on a per call basis without using
PIN2. The digit replacing the wildcard may be used for network access or supplementary service operation.

- Only allow Supplementary Service (SS) Control (in Dedicated or Idle mode) if the SS control string is stored
as an FDN entry.

- Allow the extension of an FDN entry by adding digits to the Fixed Dialling number on a per call basis.

- Allow the emergency numbers (see Section 8.4) to be called, even if it is not an FDN entry.

- Allow normal access to ADN fields (i.e. allow ADN entries to be modified, added or deleted) and the
keyboard.

- Allow use of ADNs subject to the FDN filter.

When FDN is disabled, an ME supporting FDN shall;

- Allow FDN entries to be read as though they were normal ADN entries.

- Only allow modification, addition or deletion of Fixed Number Dialling entries under control of PIN2.

- Allow normal access to ADN fields and the keyboard.

If the ME does not support FDN, the UE shall not allow the making of calls when Fixed Dialling is enabled in the
USIM, and the UE shall not allow the making or receiving of calls when Fixed Dialling is enabled in the SIM.
However, emergency calls (112 and other user defined emergency numbers) shall still be possible.

Note: Wildcards are stored on the SIM/USIM. The wildcard coding is given in 3GPP TS 31.102 [19].

A.26 Message Waiting Indication

A short message may be used to provide an indication to the user about the status and number of types of messages
waiting on systems connected to the PLMN. The ME shall present this indication as an icon on the screen, or other
MMI indication, and store the indication status on the SIM/USIM to allow the status to be retained through power
off/on, SIM/USIM movement between UEs etc..

The ME shall be able to accept and acknowledge these message waiting status short messages irrespective of the
memory available in the SIM/USIM.

A.27 Transfer of eCall Minimum Set of Data (MSD)

A.27.1 General Requirements

With the exception of the following specific requirements, considered necessary for the satisfactory operation of the
eCall service, all existing emergency call requirements shall apply.

3GPP
Release 15 87 3GPP TS 22.101 V15.2.0 (2017-09)

An eCall shall consist of an emergency call supplemented by a minimum set of emergency related data (MSD). The
MSD e.g. vehicle identity, location information and other parameters, is defined by CEN [46].

- An eCall may be initiated automatically, for example due to a vehicle collision, or manually by the vehicle
occupants;

- An IVS, or other UE designed to support eCall functionality, shall include in the emergency call set-up an
indication that the present call is either a Manually Initiated eCall (MIeC) or an Automatically Initiated eCall
(AIeC).

- The Minimum Set of Data (MSD) sent by the In vehicle System (IVS) to the network shall not exceed 140
bytes;

- Should the MSD component not be included in an eCall, or is corrupted or lost for any reason, then this shall
not affect the associated emergency call speech functionality.

- To reduce the time taken to establish an eCall an IVS whilst in eCall only mode, may receive network
availability information whilst not registered on a PLMN.

- PLMNs should make use of eCall indicators, received in the emergency call set-up, to differentiate eCalls
from other emergency calls.

- The MIeC and AIeC should be used by the serving network to filter and route eCalls to dedicated, eCall
equipped, PSAPs.

- The PSAP shall be given an indication that the incoming call is an eCall.

- When an emergency call, other than an eCall, is routed to a PSAP that supports the eCall service, the eCall
equipment shall not cause audible interference to the emergency voice call.

Throughout the duration of the emergency call and following receipt of the MSD by the PSAP

- It shall be possible for the PSAP to send a confirmation to the IVS that the MSD has been acted upon.

- It shall be possible for the PSAP to request the IVS to re-send its most recent MSD.

- It shall be possible for the PSAP to instruct the IVS to terminate the eCall.

A.27.2 Requirements for the transfer of eCall MSD in a TS12 call

The MSD should typically be made available to the PSAP within 4 seconds measured from the time when end to end
connection with the PSAP is established;

A call progress indication shall be provided to the user whilst the MSD transmission is in progress.

Where the eCall indicators are not supported by the serving network, the time needed for the PSAP eCall modem to
differentiate between eCalls and other TS12 calls, before routing the call to an operator, shall not exceed 2 seconds
from when the IVS receives notification that the PSAP has answered the call.

When an eCall is routed to a PSAP, that does not support the eCall service, the In Vehicle System (IVS) shall not
emit any audible tones for longer than 2 seconds from the time that the call is first answered.

A.27.3 Requirements for the transfer of eCall data in an IMS

emergency call
The MSD should typically be available to the PSAP when the end to end connection with the PSAP has been
established.

Note: There are cases where a UE delivers multiple instances of an MSD to one or more PSAPs, for example
as per 3GPP TS 22.101 clause 10.1.2., when an IMS emergency call based eCall attempt has not been
successful but the MSD was successfully received by a PSAP. It is out of the scope of 3GPP as to how
to manage any duplicate information received by the PSAP(s) or emergency services as a result of this.

3GPP
Release 15 88 3GPP TS 22.101 V15.2.0 (2017-09)

Additional data (i.e. data not contained in the initial MSD) may be transferred at any time during the eCall (e.g. MSD
acknowledgement, resending of the MSD if requested by a PSAP).

The call setup time of an eCall shall be the same as for an IMS emergency call.

The IVS shall not emit any audible tones in order to transfer the MSD or other eCall related data.

A.27.4 Interworking requirements

A PSAP, which is connected to the IMS, and supports either IMS emergency call based eCall or TS12 based eCall,
shall be able to interwork with a TS12 based IVS using IMS Centralized Service, i.e. it shall be able to terminate the
emergency call from the IVS, receive the MSD and request additional data from the IVS, using the eCall Modem
end-to-end.

An IVS that supports IMS emergency call based eCalls shall also support TS12 based eCalls.

An IVS that supports IMS emergency call based eCalls and is attached via LTE access with no CS access available
shall support the transfer of MSD via IMS emergency call to a TS12 based PSAP using the eCall Modem end-to-end.

NOTE 1: It is assumed that the above scenario is very unlikely to occur on the market. Therefore the operation of
eCall Modem over a PS bearer should be considered as an option of last resort [58]. As such this is not
constrained by the requirements in A.27.2 and A.27.3.

In case of interworking between TS12 and IMS emergency call based eCall equipment the requirements given in
subclause A.27.2 shall apply, requirements given in subclause A.27.3 do not apply.

A.27.5 Domain selection

A PLMN shall indicate to an IVS whether IMS emergency call based eCalls are supported.

An IVS that supports both IMS emergency call based eCalls and TS12 based eCalls shall support domain selection
for an eCall in the same way as for any other emergency call except for determining PLMN support for an IMS
emergency based eCall using the PLMN indication for this.

A.28 Requirements for "In Case of Emergency" (ICE) information

The In Case of Emergency (ICE) information are used to enable first responders, such as paramedics, fire-fighters,
and police officers, to contact a victim's emergency contact(s) in order to identify the victim and obtain important
medical information or other information required during an emergency.

A UE shall have the capability to store one or more "ICE information" on the UICC. The "ICE information" shall list
the type of information which is to be configured by the mobile operator as described in the table below.

Table A.28.1: "ICE information" description

ICE information ICE information ICE information ICE information ICE information
type format type value value 1 value 2 value n

Description Two formats It shall be It shall be Present only if Present only if

shall be defined possible to store possible to have explicitly explicitly
in this release: this information at least one ICE indicated by the indicated by the
in text or graphic information value ICE information ICE information
1- Phone number format. field. If more than type format. type format.
format. For the one information
phone number value fields are
format it shall be required it shall
possible to store a be indicated by
name and a the ICE
phone number. information type
format.

3GPP
Release 15 89 3GPP TS 22.101 V15.2.0 (2017-09)

2- Free format. It shall be

possible for the
It shall be subscriber to add,
possible for the modify, view, or
mobile operator delete any ICE
to provision zero, information
one or several value.
instances of a
given format on For the free
the UICC. format ICE
information type
format, it shall be
possible to store
information in
text or graphic
format.

For pre-defined
ICE information
type formats the
ME should adapt
the input mode to
the type of the
ICE information
value (e.g.
numerical mode
for phone number
input).

The following table provides an example of ICE information stored on the UICC:

Table A.28.2: "ICE information" example

ICE information type ICE information type value ICE information value 1 ICE information value 2

Phone Number "Contact in case of My Wife +3364566

emergency"

Phone Number "Contact in case of Family Smith +3364565

emergency"

Phone Number "Contact in case of My Family doctor: Dr. +33643234

emergency" Jones

Free Format "Medical Information" My blood type is A+, I am N/A

allergic to etc.

Free Format "Home Postal Address" 15 rue de la Paix, Paris, N/A

France

Free Format "Language" French N/A

Free Format "Travel Information" London, from 3rd July. to N/A

29th July, 2008

Provision is made for direct and unambiguous read access from the UE to ICE information stored on the UICC.

The subscriber may choose not to enter any ICE information.

The default configuration for this information shall be that they are accessible even when the security features on

3GPP
Release 15 90 3GPP TS 22.101 V15.2.0 (2017-09)

either the UE or UICC have been enabled (e.g. the keypad is locked). It shall be possible for the subscriber to change
this default setting to prevent accessibility to the ICE information (i.e. a user configurable setting in the UICC
indicates whether the ICE information on the UICC shall be displayed or not, if the ICE access procedure described
in TS 22.030 [6] is invoked).

The unlocking of ICE information shall not allow access to other secure information on the UICC or UE. The ICE
information value should not be accessible to ME or UICC applications.

The ICE access procedure is described in TS 22.030 [6].

3GPP
Release 15 91 3GPP TS 22.101 V15.2.0 (2017-09)

Annex B (informative):
Additional number use case
Company X is customer of operator Z and has a subscription for voice and data with 10 SIM cards. The company also
decides to subscribe to the private numbering plan feature of operator Z. A certain corporate phone number is
assigned to company X, e.g. +43 676 88888 xx (with xx being the extensions of the users), and they can freely choose
the extensions for up to 100 SIM cards.

Initially company X take the existing 10 SIM cards (with the existing MSISDNs) and integrate them into the private
numbering plan by assigning the extensions 11 to 20 to these cards via a web portal. This is not a permanent
assignment, the extensions can be changed easily any time, old SIMs can be deleted from the private numbering plan
and new ones can be integrated whenever necessary. Special privileges or restrictions can be chosen on a per SIM
basis via the portal and special tariffs apply.

The CEO of company X calls a customer. The customer's phone displays the corporate number + extension of the
CEO as CLI. After a while the customer decides to call back the CEO and uses the corporate number + extension as
MSISDN. Later they also exchange some short messages, again the corporate number + extension of the CEO is used
as sender's MSISDN.

For all these calls and short messages operator Z is able to collect charging records containing the corporate number
+ extension.

The CEO also uses her smart phone to establish PS connections to browse the internet and to access the intranet via
the operator's gateway. The corporate number + extension is used for authentication and authorisation in the
company's intranet and its web applications. Charging for PS connections by operator Z is also based on this number.

In general the users in company X are not aware of their "real" underlying MSISDNs in the system, they only see the
corporate number + their extension and there is no need for them to know the underlying MSISDN.

3GPP
Release 15 92 3GPP TS 22.101 V15.2.0 (2017-09)

Annex C (informative):
Change history

Change history
SMG No. TDoc. No. CR. No. Section New Subject/Comments
affected version
SMG#22 302/97 001 4.6 (Role 3.1.0 SMG3 queried the separation of network
Model) operator into core and access, which, on
examination, SMG1 find unhelpful
SMG#22 319/97 002 3.1.0 Editorial Changes: FLMPTS was replaced by
(SMG1 IMT 2000, 2 new references given, additional
WPC clarifications.
125/97)
SMG#22 320/97 003 8.5, 9.3, 3.1.0 Changes on Emergency Calls, User
9.5, 17 identification, Multiple profiles and additional
handover requirements.
After SMG1 004 Draft Based on Approved Changes at SMG#22
SMG#23 433u/97 3.2.0 Distributed at SMG1 in Dresden Nov 3-7, 97
965/97 to be Approved at SMG#24
SMG#24 966/97 005 Sections 3.2.1 Restructuring of sections 8,9 and 11 to gather
8, 9, 11 all requirements relating to multiple
subscriptions into one section and to improve
the clarity.
SMG#24 967/97 006 Section 3.2.1 To improve the accuracy of text on numbering
8.1 principles and minor editorial change to
section 8.1

SMG#27 98-0551 007 Section 3.3.0 Removal of commercial role model from the
4.6 and specification in order to improve clarity
misc.
SMG#27 98-0552 008 New Section 3.3.0 To include requirements for network selection in service
(Not 18
Approved) (Not Applied) principles: NOT APPROVED > NOT APPLIED
Pre- (SMG1 Tdoc 008 r4 New [Draft Added Network Selection section - Agreed by
98-0893)
SMG#28 Rejected Section 18 3.4.0] correspondence - Jan 13, 1999 - Prepared with
99-040
Applied CRs applied with revision marks
SMG#27 98-0553 009 Section 4.3 3.3.0 To remove unnecessary reference to IN and B-
ISDN
SMG#27 98-0682 010 Section 11 3.3.0 To improve the clarity of service requirements
for multiple user profiles
Pre- (SMG1 Tdoc 011 Sections 1, 2, Draft 3.4.0 Clean up for UMTS phase 1
SMG#28 98-0869) 3, 4, 9, 10,
Agreed at SMG1 Rome
99-040 12, 17
Pre- (SMG1 Tdoc 012 Sections Draft 3.4.0 Changes in IC card and terminal service requirements
SMG#28 98-852) 3,8,9,11,14,1
Agreed at SMG1 Rome
99-040 5
Pre- (SMG1 Tdoc 013r1 Section 3.2 & Draft Clarification of general requirements for efficient use of
SMG#28 98-0894) 4.3 3.4.0
radio resources
99-040
Agreed by correspondence - Jan 13, 1999 - Prepared
with CRs applied with revision marks
Note Draft 3.4.0 SMG1 agreed only
pre-SMG#28 99-040 015 17 Draft 3.4.0 According to the outcome of the SMG 1 ad-hoc meeting
Rejected
on handover issues it is proposed that inter-operator
handover is not required for UMTS phase 1.(rejected by
smg#28)

3GPP
Release 15 93 3GPP TS 22.101 V15.2.0 (2017-09)

Change history
SMG No. TDoc. No. CR. No. Section New Subject/Comments
affected version
SMG#28 99-305 008r5 Revised 3.4.0 Network Selection presented at SMG#28 in 2201_008r4
Section 18
was further revised and Approved at SMG#28.
Note 3.4.0 Removal of Section 12 on UPT with CR 011 causes a
skip section from Section 11 to 13.

Change history
TSG SA SA Doc. SA1 Doc Spec CR Rev Rel Cat Subject/Comment Old New WI
#
SP-03 SP-99104 S1-99202 22.101 A016 R99 B Control of supplementary 3.4.0
services (GSM 02.04), may use
MMI procedures specified in
GSM 02.30 and existing GSM
MMI related MS features (GSM
02.07) may also be used.
Post- 22.101 R99 Updated Logo, … 3.5.0 3.5.1
SA#3
SP-04 SP-99229 S1-99387 22.101 021 R99 B MultiNumbering: It will be 3.5.0 3.6.0
possible for multiple MSISDNs to
be associated with a single
subscription.
SP-04 SP-99226 S1-99395 22.101 020 7 R99 B Emergency: To route the call to 3.5.0 3.6.0
the appropriate emergency
service if more than one
emergency number is supported
in a country.
SP-05 SP-99439 S1-99737 22.101 025 R99 B Support of SAT by USIM 3.6.0 3.7.0
SP-05 SP-99439 S1-99816 22.101 024 R99 B Clarification on the usage on 2G 3.6.0 3.7.0
SIM and 3G USIM
SP-05 SP-99435 S1-99851 22.101 022 R99 C Clarification of Emergency Call 3.6.0 3.7.0
requirements
SP-06 SP-99524 S1-991031 22.101 029 R99 B Emergency Call 3.7.0 3.8.0
SP-06 SP-99527 S1-991038 22.101 028 R99 C FDN 3.7.0 3.8.0
SP-06 SP-99519 S1-991026 22.101 026 R99 D Mainly editorial update for 3.7.0 3.8.0
GSM/3GPP use.
SP-07 SP-000060 S1-000112 22.101 030 R99 A Support of encryption in GPRS 3.8.0 3.9.0
mobile stations
SP-07 SP-000070 S1-000137 22.101 031 R99 F Fixed Dialing Number (FDN) 3.8.0 3.9.0
SP-08 SP-000210 S1-000271 22.101 033 R99 D Network selection procedures 3.9.0 3.10.0
removed from section 16,
reference to 22.011 added
SP-08 SP-000200 S1-000350 22.101 035 R99 B Emergency Calls and numbers 3.9.0 3.10.0
used
SP-08 SP-000201 S1-000362 22.101 038 R99 F CS multimedia support 3.9.0 3.10.0
SP-08 SP-000202 S1-000326 22.101 039 R99 F Clarification for USIM Application 3.9.0 3.10.0
selection
SP-08 SP-000210 S1-000270 22.101 034 R00 D Network selection procedures 3.9.0 4.0.0
removed from section 16,
reference to 22.011 added
SP-08 SP-000200 S1-000351 22.101 036 R00 B Emergency Calls and numbers 3.9.0 4.0.0
used
SP-08 SP-000213 S1-000352 22.101 037 R00 B Emergency Call enhancements 3.9.0 4.0.0
SP-09 SP-000383 S1-000603 22.101 040 R4 B Multimedia messaging 4.0.0 4.1.0
SP-09 SP-000383 S1-000605 22.101 041 R4 C Service Management 4.0.0 4.1.0
requirements
SP-09 SP-000430 S1-000700 22.101 042 1 R4 F General corrections and 4.0.0 4.1.0
clarifications to 22.101 for
Release 2000
SP-09 SP-000383 S1-000598 22.101 046 R4 D Editorial changes to 22.101 for 4.0.0 4.1.0
Release 2000
SP-09 SP-000430 S1-000698 22.101 047 1 R4 C Numbering Principles 4.0.0 4.1.0
SP-09 SP-000383 S1-000620 22.101 048 R4 C Service evolution 4.0.0 4.1.0
SP-09 SP-000391 S1-000573 22.101 049 R4 D Emergency Call 4.0.0 4.1.0
SP-09 SP-000405 S1-000649 22.101 050 R4 B Text Conversation 4.0.0 4.1.0
SP-09 SP-000383 S1-000625 22.101 043 R5 F Classification of services 4.0.0 5.0.0
SP-09 SP-000383 S1-000622 22.101 044 R5 B IP multimedia services 4.0.0 5.0.0
SP-09 SP-000383 S1-000621 22.101 045 R5 B IP multimedia session for 4.0.0 5.0.0
Emergency call

3GPP
Release 15 94 3GPP TS 22.101 V15.2.0 (2017-09)

SP-09 SP-000430 S1-000699 22.101 051 R5 C IM Number portability 4.0.0 5.0.0

SP-09 SP-000430 S1-000701 22.101 052 R5 F Introduction of IM CN Subsystem 4.0.0 5.0.0
SP-09 SP-000383 S1-000704 22.101 053 R5 F Subscription 4.0.0 5.0.0
SP-09 SP-000383 S1-000705 22.101 054 R5 F Roaming 4.0.0 5.0.0
SP-10 SP-000533 S1-000799 22.101 059 Rel-5 A Deleting Encrypted USIM-ME 5.0.0 5.1.0 TEI4
interface
SP-11 SP-010053 S1-010072 22.101 063 Rel-5 A Handling of interactions between 5.1.0 5.2.0 Service
applications requiring the access Clean up
to UE resources R99
SP-11 SP-010054 S1-010208 22.101 065 Rel-5 A PLMN name indication 5.1.0 5.2.0 TEI4
SP-11 SP-010055 S1-010179 22.101 067 Rel-5 A CR to 22.101 on Introduction of 5.1.0 5.2.0 UICC1-
CPHS features CPHS
SP-11 SP-010056 S1-010210 22.101 069 Rel-5 A Display of service provider name 5.1.0 5.2.0 TEI4
in the UE
SP-11 SP-010057 S1-010250 22.101 070 Rel-5 C CR to 22.101 on Clarifications on 5.1.0 5.2.0 EMC1-PS
IMS emergency call support
SP-12 SP-010262 S1-010505 22.101 072 Rel-5 A Replacement of references to 5.2.0 5.3.0 TEI4
23.121 for R4 onwards
SP-12 SP-010258 S1-010574 22.101 073 Rel-5 C Subscription and Provisioning 5.2.0 5.3.0 TEI5
SP-12 SP-010255 S1-010577 22.101 075 Rel-5 A Addition of a Streaming 5.2.0 5.3.0 PSTREAM
paragraph
SP-12 SP-010263 S1-010351 22.101 077 Rel-5 A CS Multimedia fallback to speech 5.2.0 5.3.0 TEI4
SP-12 SP-010253 S1-010595 22.101 080 Rel-5 A Clarification of PLMN Name 5.2.0 5.3.0 SPANME
Indication and Service Provider
Name Indication feature.
SP-13 SP-010441 S1-010832 22.101 084 Rel-5 A Addition of a statement on 5.3.0 5.4.0 TEI4
parameter storage on the
SIM/USIM.
SP-13 SP-010436 S1-010889 22.101 086 1 Rel-5 F Definition of Home Environment 5.3.0 5.4.0 VHE1
SP-15 SP-020052 S1-020609 22.101 087 Rel-5 B CR 22.101 Rel.5 B Service 5.4.0 5.5.0 SCUDIF
change and fallback for UDI/RDI
multimedia calls
SP-15 SP-020049 S1-020510 22.101 088 Rel-5 C CR to 22.101on IMS access 5.4.0 5.5.0 43000
SP-15 SP-020051 S1-020613 22.101 089 Rel-5 C CR to 22.101 on on USIM 5.4.0 5.5.0 UICC1
support in Rel-5 GSM only
terminals
SP-15 SP-020050 S1-020658 22.101 090 Rel-5 C CR to 22.101 on Access to IMS 5.4.0 5.5.0 TEI/ISIM
services using ISIM

Note: special dispensation was

given by SA #15 to allow some
leeway on the section numbering.
SP-15 SP-020045 S1-020457 22.101 092 - Rel-5 A Editorial CR to correct terms and 5.4.0 5.5.0 CORRECT
references
SP-15 SP-020126 22.101 093 Rel-5 F Correction of references to 5.4.0 5.5.0 IMS-CCR
obsolete SIP RFC 2543 IETF
specification
SP-16 SP-020381 22.101 095 1 Rel-5 F CR to 22.101 v5.5.0 on REL5 5.5.0 5.6.0 IMS
clean up
SP-16 SP-020255 S1-020848 22.101 096 Rel-6 D CR to 22.101 v5.5.0 on Editorial 5.5.0 6.0.0 IMS
for REL6
SP-17 SP-020557 S1-021849 22.101 103 Rel-6 F Clarification of SIM support in 6.0.0 6.1.0 TEI4
Rel-6
SP-17 SP-020557 S1-021755 22.101 104 Rel-6 B CR to 22.101 Removal of 6.0.0 6.1.0 TEI6
implementation details for
directory number in SMS and
other services
SP-17 SP-020557 S1-021775 22.101 105 Rel-6 F CR to 22.101 Rel-6 Clean up of 6.0.0 6.1.0 IMS
IMS Rel 6 to re-instate
requirements
SP-18 SP-020658 S1-022064 22.101 107 Rel-6 B CR to 22.101 on IMS number 6.1.0 6.2.0 IMS
portability rev of 1909
SP-18 SP-020658 S1-022119 22.101 108 Rel-6 B CR to 22.101 Rel 6 on 6.1.0 6.2.0 EMC1
Emergency calls
SP-18 SP-020666 S1-022263 22.101 109 Rel-6 B CR to 22.101 on WLAN 6.1.0 6.2.0 WLAN
interworking
SP-18 SP-020651 S1-022340 22.101 113 Rel-6 A CR to 22.101 on Support of SIM 6.1.0 6.2.0 TEI5
and USIM in REL-6
SP-19 SP-030022 S1-030215 22.101 114 - Rel-6 B Simultaneous connection to 6.2.0 6.3.0 WLAN-CR
3GPP systems and I-WLANs
SP-19 SP-030035 S1-030269 22.101 115 - Rel-6 B Requirements for Network 6.2.0 6.3.0 NTShar-
Sharing in Rel-6 CR

3GPP
Release 15 95 3GPP TS 22.101 V15.2.0 (2017-09)

SP-19 SP-030148 S1-030257 22.101 117 - Rel-6 A CR to 22.101 Rel 6 on SIM 6.2.0 6.3.0 TEI5
support
SP-20 SP-030351 22.101 125 1 Rel-6 A Alignment of Subscriber 6.3.0 6.4.0 TEI5
Identification requirements to
current implementation
SP-21 SP-030457 S1-030911 22.101 128 - Rel-6 A Clarification on USIM-based 6.4.0 6.5.0 IMS
access to IMS
SP-21 SP-030492 S1-031049 22.101 132 Rel-6 C Cleanup and modifications on 6.4.0 6.5.0 EMC1
identification of emergency
numbers in 22.101 Rel-6
SP-21 SP-030534 S1-031061 22.101 134 1 Rel-6 A Support of Release 4 SIM in 6.4.0 6.5.0 TEI5
Release 6
SP-22 SP-030700 S1-031339 22.101 135 - Rel-6 B Automatic Device Detection 6.5.0 6.6.0 TEI
SP-22 SP-030700 S1-031342 22.101 136 - Rel-6 C Correction of Core Network 6.5.0 6.6.0 EMC1
emergency call requirements
SP-22 SP-030687 S1-031344 22.101 137 - Rel-6 C Clarification of emergency call 6.5.0 6.6.0 EMC1
requirements
SP-22 SP-030790 - 22.101 141 - Rel-6 A Removal of unnecessary 6.5.0 6.6.0 EMC1
numbers from the ME default
emergency number list (Rel-6)
SP-23 SP-040084 S1-040198 22.101 145 - Rel-6 A Alignment to TS 31.102 on 6.6.0 6.7.0 TEI
FDN/BDN unsupported terminal
procedure.
SP-23 SP-040091 S1-040215 22.101 146 - Rel-6 B Improvements to Circuit 6.6.0 6.7.0 CS-VVS
Switched Video and Voice
Service procedures
SP-23 SP-040101 S1-040258 22.101 150 - Rel-6 D Extraction of redundant WLAN 6.6.0 6.7.0 WLAN
information – now in WLAN
TS22.234
SP-23 SP-040101 S1-040262 22.101 151 - Rel-6 D Extraction of redundant WLAN 6.6.0 6.7.0 WLAN
related simultaneous connection
information [ now in WLAN
TS22.234]
SP-24 SP-040288 S1-040427 22.101 152 - Rel-6 F Correction of UICC related text. 6.7.0 6.8.0 TEI
SP-24 SP-040292 S1-040537 22.101 154 - Rel-6 F Editorial Correction of R5 6.7.0 6.8.0 IMS2
reference
SP-24 SP-040301 S1-040513 22.101 153 - Rel-7 B Termination of location privacy 6.7.0 7.0.0 LCS2;
override for emergency calls EMC1
SP-27 SP-050058 S1-050161 22.101 158 - Rel-7 A Clean-up in Core Network 7.0.0 7.1.0 NTShar
Operator Name Indication
section (22.101)
SP-27 SP-050059 S1-050252 22.101 160 - Rel-7 A Removal of Reference to TS 7.0.0 7.1.0 TEI7
22.121
SP-28 SP-050216 S1-050519 22.101 163 - Rel-7 A Clarification on optionality of 7.1.0 7.2.0 TEI-6
Service Provider Name indication
SP-28 SP-050225 S1-050581 22.101 164 - Rel-7 B Voice call continuity 7.1.0 7.2.0 VCC
requirements
SP-29 SP-050522 S1-050793 22.101 0165 - Rel-7 F Correction of emergency number 7.2.0 7.3.0 TEI7
example
SP-29 SP-050522 S1-050873 22.101 0166 - Rel-7 F Requirements on the type of 7.2.0 7.3.0 TEI7
emergency
SP-29 SP-050522 S1-050796 22.101 0167 - Rel-7 C Modification to chapter 4.2 on 7.2.0 7.3.0 TEI7
service capabilities
SP-29 SP-050518 S1-050896 22.101 0168 - Rel-7 F Refinement of general 7.2.0 7.3.0 VCC
description of VCC
SP-29 SP-050518 S1-050897 22.101 0169 - Rel-7 C Charging requirements for voice 7.2.0 7.3.0 VCC
call continuity
SP-29 SP-050518 S1-050936 22.101 0171 1 Rel-7 C Clarification of VCC Triggers 7.2.0 7.3.0 VCC
SP-29 SP-050522 S1-050906 22.101 0172 - Rel-7 F Clarification on the identification 7.2.0 7.3.0 EMC1
of emergency numbers
SP-29 SP-050522 S1-050883 22.101 0173 - Rel-7 B Provisioning parameters stored 7.2.0 7.3.0 TEI7
on USIM
SP-29 SP-050518 S1-050934 22.101 0174 - Rel-7 C Supplementary Service 7.2.0 7.3.0 VCC
Requirements for VCC
SP-30 SP-050750 S1-051145 22.101 0176 - Rel-7 F Correcting reference to OMA DM 7.3.0 7.4.0 TEI7
and Client provisioning
specifications
SP-30 SP-050746 S1-051209 22.101 0177 - Rel-7 F Clarification of supplementary 7.3.0 7.4.0 VCC
servces requirements for VCC
SP-30 SP-050746 S1-051220 22.101 0178 - Rel-7 F Clarification of VCC Triggers 7.3.0 7.4.0 VCC
SP-30 SP-050737 S1-051236 22.101 0179 - Rel-7 A Introduction of Cell capability 7.3.0 7.4.0 TEI6
indicator
SP-30 SP-050805 - 22.101 0180 1 Rel-7 B Emergency sip uri to be stored in 7.3.0 7.4.0 EMC1
MT

3GPP
Release 15 96 3GPP TS 22.101 V15.2.0 (2017-09)

SP-31 SP-060207 - 22.101 0182 1 Rel-8 F Inclusion of AIPN within the 7.4.0 8.0.0 AIPN
3GPP service principles
specification
SP-32 SP-060448 - 22.101 0186 1 Rel-8 F Corrections to align the Rel-8 and 8.0.0 8.1.0 TEI8
(latest) Rel-7 versions of TS
22.101
SP-32 SP-060316 S1-060561 22.101 0187 - Rel-8 B VCC Additional flexibility 8.0.0 8.1.0 VCC
SP-32 SP-060315 S1-060621 22.101 0191 - Rel-8 A Clarification of IMS voice service 8.0.0 8.1.0 VCC
SP-32 SP-060435 - 22.101 0192 1 Rel-8 B QoS Parameters Provisioning 8.0.0 8.1.0 TEI8
SP-32 SP-060449 - 22.101 0193 2 Rel-8 B High Speed Interface between 8.0.0 8.1.0 TEI8
the Terminal and the UICC
SP-32 SP-060320 S1-060626 22.101 0194 - Rel-8 F Clarification on handling of 8.0.0 8.1.0 TEI-8
emergency number
SP-33 SP-060470 S1-060939 22.101 0197 - Rel-8 A Clarification on Domain Selection 8.1.0 8.2.0 TEI8
for MO and MT Operations
SP-33 SP-060468 S1-060950 22.101 0199 - Rel-8 A Emergency calls and ISIM 8.1.0 8.2.0 EMC1
SP-33 SP-060472 S1-060964 22.101 0200 - Rel-8 B Requirements for the 8.1.0 8.2.0 TEI8
determination of cell capability
usage - when requested by CN
SP-34 SP-060777 S1-061321 22.101 0195 3 Rel-8 C Requirements for the addition of 8.2.0 8.3.0 TEMCD
a data component to TS12
emergency calls and eCall MSD
(data) transfer requirements
SP-34 SP-060773 S1-061406 22.101 0201 - Rel-8 B Serving Environment / Mobile 8.2.0 8.3.0 TEI8
Virtual Network Identification
SP-34 SP-060765 S1-061347 22.101 0204 - Rel-8 A Removal of IMS emergency call 8.2.0 8.3.0 EMC1
identifier
SP-35 SP-070130 S1-070190 22.101 0205 1 Rel-8 D Addition of Evolved 3GPP 8.3.0 8.4.0 SAE-R
System description and
corrections to references
SP-35 SP-070134 S1-070299 22.101 0207 1 Rel-8 B Registration in Densely- 8.3.0 8.4.0 RED
populated area
SP-36 SP-070355 S1-070673 22.101 0211 1 Rel-8 C Graphic format of PLMN name 8.4.0 8.5.0 TEI8
SP-36 SP-070354 S1-070802 22.101 0214 1 Rel-8 A Alignment of SPDI definition 8.4.0 8.5.0 TEI5
between TS22.101 and
TS31.102
SP-36 SP-070472 S1-070790 22.101 0215 2 Rel-8 F Correction of the backward 8.4.0 8.5.0 TEI-8
compatibility requirement for the
HSP interface
SP-37 SP-070661 S1-071314 22.101 218 2 Rel-8 B ICS Requirements – General 8.5.0 8.6.0 ICS-RA

SP-37 SP-070661 S1-071315 22.101 221 2 Rel-8 B ICS Requirements - Service 8.5.0 8.6.0 ICS-RA
Consistency
SP-37 SP-070661 S1-071316 22.101 222 2 Rel-8 B ICS Requirements - Service 8.5.0 8.6.0 ICS-RA
Continuity
SP-37 SP-070661 S1-071317 22.101 225 2 Rel-8 B ICS Requirements - IMS 8.5.0 8.6.0 ICS-RA
Services
SP-37 SP-070662 S1-070995 22.101 216 1 Rel-8 C Clarification on graphic format of 8.5.0 8.6.0 TEI8
PLMN name
SP-37 SP-070676 - 22.101 217 4 Rel-8 B Requirements for eCall 8.5.0 8.6.0 EData
SP-38 SP-070850 S1-071712 22.101 0232 1 Rel-8 B ICS - Clarification of Service 8.6.0 8.7.0 ICSRA
Continuity
SP-38 SP-070850 S1-071713 22.101 0233 1 Rel-8 B ICS - Service Continuity 8.6.0 8.7.0 ICSRA
Requirements
SP-38 SP-070850 S1-071714 22.101 0234 1 Rel-8 B ICS - Roaming Support 8.6.0 8.7.0 ICSRA
SP-38 SP-070850 S1-071715 22.101 0235 1 Rel-8 B Clarify UE requirements for ICS 8.6.0 8.7.0 ICS-RA
SP-38 SP-070861 S1-071932 22.101 0229 2 Rel-8 B Requirements for Emergency 8.6.0 8.7.0 TEI8
Call-Back
SP-38 SP-070862 S1-071927 22.101 0241 2 Rel-8 B CS IP Interconnection 8.6.0 8.7.0 IPINTERC
requirement
SP-39 SP-080036 S1-080309 22.101 0237 6 Rel-8 B Requirements for "In Case of 8.7.0 8.8.0 ICE
Emergency" (ICE) information
SP-39 SP-080042 S1-080296 22.101 0250 1 Rel-8 F Update the related contents 8.7.0 8.8.0 AIPN-SAE
about "Evolved Packet System"
SP-39 SP-080041 S1-080297 22.101 0251 1 Rel-8 F CS multimedia calls 8.7.0 8.8.0 TEI8
SP-39 SP-080041 S1-080298 22.101 0252 1 Rel-8 D correction of wrong referencing 8.7.0 8.8.0 TEI8
SP-39 SP-080032 S1-080314 22.101 0253 2 Rel-8 B Requirements for transfer for 8.7.0 8.8.0 EData
data during emergency calls
SP-39 SP-080032 S1-080266 22.101 0254 1 Rel-8 B Requirements for the transfer of 8.7.0 8.8.0 EData
eCall Minimum Set of Data
SP-39 SP-080043 S1-080337 22.101 0255 2 Rel-8 B RAT indicator 8.7.0 8.8.0 TEI8

3GPP
Release 15 97 3GPP TS 22.101 V15.2.0 (2017-09)

SP-39 SP-080039 S1-080287 22.101 0256 1 Rel-8 B ICS requirement for roaming 8.7.0 8.8.0 ICSRA
SP-39 SP-080040 S1-080237 22.101 0262 1 Rel-8 B Additional requirements for CS IP 8.7.0 8.8.0 IPINTERC
interconnection
SP-39 SP-080043 S1-080299 22.101 0263 1 Rel-8 B Addition of Unique Device 8.7.0 8.8.0 TEI8
Identifier to Calling Line
Identification
SP-39 SP-080040 S1-080327 22.101 0265 1 Rel-8 B Clarification of requirements for 8.7.0 8.8.0 IPINTERC
CS IP interconnection
SP-40 SP-080308 S1-080746 22.101 0267 3 Rel-8 F Emergency Call Interaction 8.8.0 8.9.0 EMC1
SP-40 SP-080299 S1-080581 22.101 0269 1 Rel-8 C eCall call back requirements 8.8.0 8.9.0 EDATA
clarification
SP-40 SP-080298 S1-080735 22.101 0270 3 Rel-8 F Common IMS Proposals - 8.8.0 8.9.0 CIMS_3G
Requirements for Emergency PP2
Calls
SP-40 SP-080306 S1-080715 22.101 0271 1 Rel-8 F Correction of reference for PLMN 8.8.0 8.9.0 AIPN-SAE
architecture
SP-40 SP-080299 S1-080714 22.101 0272 1 Rel-8 F Corrections to general 8.8.0 8.9.0 EData
requirements for emergency calls
SP-40 SP-080308 S1-080560 22.101 0274 - Rel-8 F Clarification of IMS Emergency 8.8.0 8.9.0 EMC1
Calls
SP-40 SP-080299 S1-080743 22.101 0275 1 Rel-8 C Reconfigurable eCall only 8.8.0 8.9.0 EDATA
terminal access to test and
reconfiguration services
SP-40 SP-080302 S1-080705 22.101 0276 - Rel-8 F Correction of ICE requirements 8.8.0 8.9.0 ICE
SP-40 SP-080311 S1-080774 22.101 0268 3 Rel-9 B Requirements for Service 8.8.0 9.0.0 ETWS-S1
Alignment and Migration
SP-41 SP-080498 S1-082192 22.101 0282 1 Rel-9 F Clarification on IMS services 9.0.0 9.1.0 ICSRA
supported by ICS

SP-41 SP-080643 - 22.101 0280 2 Rel-9 F RED optimization of location 9.0.0 9.1.0 RED
update
SP-42 SP-080884 22.101 0290 6 Rel-9 A ICS Service Continuity 9.1.0 9.2.0 CIMS8
SP-42 SP-080779 S1-084415 22.101 281 2 Rel-9 B User Data Convergence 9.1.0 9.2.0 UDC
Requirements
SP-42 SP-080781 S1-084177 22.101 0283 2 Rel-9 F VCC for emergency calls 9.1.0 9.2.0 IMS_EME
R_GPRS_
EPS
SP-42 SP-080784 S1-084424 22.101 0290 3 Rel-9 C ICS Service Continuity 9.1.0 9.2.0 TEI9
SP-42 SP-080783 S1-084404 22.101 0299 3 Rel-9 B UICC applications access to IMS 9.1.0 9.2.0 TEI9
SP-42 SP-080781 S1-084096 22.101 300 - Rel-9 F Make IMS emergency calls 9.1.0 9.2.0 TEI9
available in all access systems
SP-43 SP-090079 S1-090174 22.101 0307 1 Rel-9 A Clarification and enhancement of 9.2.0 9.3.0 TEI9
ciphering indicator feature
SP-44 SP-090377 S1-091407 22.101 0312 4 Rel-9 F Domain selection for emergency 9.3.0 9.4.0 IMS_EME
call R_GPRS_
EPS
SP-44 SP-090369 S1-091393 22.101 0313 - Rel-9 A eCall - PSAP acknowledgement 9.3.0 9.4.0 Edata
to the IVS
SP-45 SP-090475 S1-093290 22.101 0315 1 Rel-9 A Minimise delay to emergency 9.4.0 9.5.0 EDATA
voice calls
SP-45 SP-090480 S1-093282 22.101 321 1 Rel-9 F Domain selection for emergency 9.4.0 9.5.0 IMS_EME
call R_GPRS_
EPS
SP-45 SP-090483 S1-093286 22.101 0316 1 Rel-10 F Add reference to MSD 9.4.0 10.0.0 EDATA
specification
SP-45 SP-090484 S1-093341 22.101 0320 4 Rel-10 B Selected IP Traffic Offload 9.4.0 10.0.0 LIPA_SIP
TO
SP-45 SP-090483 S1-093261 22.101 322 1 Rel-10 F Clarification of emergency call 9.4.0 10.0.0 TEI10
back requirements
SP-46 SP-090887 S1-094259 22.101 0336 1 Rel-10 A Providing eCall indication to the 10.0.0 10.1.0 EDATA
PSAP
SP-46 SP-090836 S1-094262 22.101 0338 - Rel-10 A Remove requirement for operator 10.0.0 10.1.0 EDATA
determined eCall call-back
duration.
SP-46 SP-090842 S1-094272 22.101 0330 1 Rel-10 A User data repository shall be 10.0.0 10.1.0 UDC
possible to be shared among
different PLMNs that have
trusted relationships
SP-46 SP-090844 S1-094499 22.101 0327 2 Rel-10 A Use of GTT-IP for IMS 10.0.0 10.1.0 TEI9
emergency calls (mirror)
SP-46 SP-090846 S1-094496 22.101 0328 1 Rel-10 B ICS Enhancements 10.0.0 10.1.0 TEI10
SP-46 SP-090849 S1-094300 22.101 0325 3 Rel-10 B Roaming and Mobility aspects for 10.0.0 10.1.0 LIPA_SIP
Selected IP Traffic Offload TO

3GPP
Release 15 98 3GPP TS 22.101 V15.2.0 (2017-09)

SP-47 SP-100187 S1-100321 22.101 0339 2 Rel-10 B SIPTO requirements common for 10.1.0 10.2.0 LIPA_SIP
macro network and H(e)NB TO
subsystems
SP-47 SP-100188 S1-100445 22.101 0332 6 Rel-10 C Clarification to Emergency call 10.1.0 10.2.0 TEI10
selection prioritization
SP-47 SP-100188 S1-100442 22.101 0340 1 Rel-10 C Clarification on ICS wrt data (CS) 10.1.0 10.2.0 TEI10
and fax
SP-47 SP-100191 S1-100431 22.101 0343 2 Rel-10 B IMS emergency call 10.1.0 10.2.0 IESE
enhancements
SP-48 SP-100431 S1-101060r 22.101 0347 6 Rel-10 B Addition of Requirement for UDC 10.2.0 10.3.0 TEI10
Data Model
SP-48 SP-100401 S1-101067 22.101 0350 - Rel-10 F Correction of reference 10.2.0 10.3.0 IESE
SIPTO_S
SP-49 SP-100585 S1-102403 22.101 0353 2 Rel-11 B SIPTO mobility/continuity 10.3.0 11.0.0 C
Clarification on Service SIPTO_S
SP-51 SP-110168 S1-110088 22.101 0360 - Rel-11 F Continuity for SIPTO 11.0.0 11.1.0 C
SP-52 SP-110373 S1-111410 22.101 0367 3 Rel-11 B IMS emergency call 11.1.0 11.2.0 NOVES
requirements for additional media
types
SP-52 SP-110376 S1-111209 22.101 0369 - Rel-11 D Removing text discrepancy 11.1.0 11.2.0 TEI11
between Rel-10 and Rel-11 for
UDC Data Model
SP-52 SP-110418 - 22.101 0372 2 Rel-11 A IMS emergency calls 11.1.0 11.2.0 IMS_EME
R_GPRS_
EPS
Correction of typo on cover page 11.2.0 11.2.1
SP-53 SP-110582 S1-112392 22.101 0373 1 Rel-11 F SIPTO in the Mobile Operator 11.2.0 11.3.0 TEI11
Network and Local
Residential/Enterprise Network
SP-53 SP-110576 S1-112101 22.101 0379 - Rel-11 B IMS emergency call support with 11.2.0 11.3.0 NOVES
other media handover
considerations
SP-53 SP-110576 S1-112344 22.101 0380 1 Rel-11 B Notification of IMS emergency 11.2.0 11.3.0 NOVES
call support with other media
SP-53 SP-110576 S1-112350 22.101 0385 3 Rel-11 B Domain Selection for IMS 11.2.1 11.3.0 NOVES
emergency calls with additional
media types
SP-53 SP-110579 S1-112385 22.101 0374 1 Rel-11 F SIPTO Service Continuity 11.2.0 11.3.0 SIPTO_S
C
SP-53 SP-110579 S1-112393 22.101 0378 2 Rel-11 C Clarification on collection of traffic 11.2.0 11.3.0 SIPTO_S
and signalling for SIPTO C
SP-53 SP-110582 S1-112025 22.101 0376 - Rel-11 F Correction of clause numbers 11.2.1 11.3.0 TEI11
and editorial corrections
SP-53 SP-110651 S1-112328 22.101 0383 3 Rel-11 F Moving "Network provided 11.2.1 11.3.0 SIMTC
destination for uplink data"
requirement from 22.368 into
22.101
SP-53 SP-110651 S1-112329 22.101 0384 4 Rel-11 F Moving PS-Only requirements 11.2.1 11.3.0 SIMTC
from 22.368 into 22.101
SP-54 SP-110811 S1-113245 22.101 0387 1 Rel-11 F IMS Multimedia Emergency 11.3.0 11.4.0 NOVES
Session support for UEs in
Limited Service Mode
SP-54 SP-110811 S1-113249 22.101 0388 2 Rel-11 F Correction and removal of 11.3.0 11.4.0 NOVES
inconsistencies to IMS
Emergency call when using other
media
SP-54 SP-110811 S1-113248 22.101 0390 2 Rel-11 F Indication of supported media 11.3.0 11.4.0 NOVES
during an IMS multimedia
emergency session
SP-54 SP-110811 S1-113250 22.101 0391 1 Rel-11 F Handover of other media to 11.3.0 11.4.0 NOVES
networks that do not support IMS
emergency voice calls
SP-54 SP-110873 S1-113093r 22.101 0392 2 Rel-11 F Media allowed on callback from 11.3.0 11.4.0 NOVES
PSAP
SP-54 SP-110811 S1-113094 22.101 0393 - Rel-11 F Routing IMS multimedia sessions 11.3.0 11.4.0 NOVES
towards the PSAP
SP-54 SP-110813 S1-113098 22.101 0394 - Rel-11 B PS additional number 11.3.0 11.4.0 TEI11
SP-55 SP-120103 S1-120256 22.101 0401 1 Rel-11 F PS only subscriptions with SMS 11.4.0 11.5.0 SIMTC
support
SP-55 SP-120105 S1-120346 22.101 0400 4 Rel-12 B Introduction of Small Data 11.4.0 12.0.0 TEI12
Applications requirements
SP-56 SP-120286 S1-121314 22.101 0409 1 Rel-12 A Emergency calls from non CSG 12.0.0 12.1.0 EHNB
members in CSG cells
SP-56 SP-120288 S1-121396 22.101 0412 1 Rel-12 A Clarification of PS additional 12.0.0 12.1.0 TEI11
numbers requirement

3GPP
Release 15 99 3GPP TS 22.101 V15.2.0 (2017-09)

SP-56 SP-120288 S1-121392 22.101 0415 - Rel-12 A Modification of how ME treats 12.0.0 12.1.0 TEI11
emergency call type(s)
SP-57 SP-120519 S1-122463 22.101 0423 1 Rel-12 A Correction of UE mandatory 12.1.0 12.2.0 TEI8
features
SP-57 SP-120528 S1-122221 22.101 0416 3 Rel-12 B Definitions for integration of 12.1.0 12.2.0 SSO_int
Single Sign-On (SSO)
frameworks with 3GPP networks
SP-57 SP-120528 S1-122433 22.101 0417 2 Rel-12 B Requirements for integration of 12.1.0 12.2.0 SSO_int
Single Sign-On (SSO)
frameworks with 3GPP networks
SP-58 SP-120868 S1-124504 22.101 0433 5 Rel-12 D MSISDN-less SMS Handling 12.2.0 12.3.0 MTCe-
SRM
SP-58 SP-120919 S1-124416 22.101 0434 4 Rel-12 B Addition of UPCON 12.2.0 12.3.0 UPCON
Requirements
SP-59 SP-130106 S1-131033 22.101 0444 - Rel-12 D Clarification of RAN user plane 12.3.0 12.4.0 UPCON
congestion definition
SP-59 SP-130112 S1-131226 22.101 0445 3 Rel-12 B Add Requirement on emergency 12.3.0 12.4.0 ESID
IM CN subsystem
SP-61 SP-130413 S1-134180 22.101 0463 1 Rel-13 B E-UTRAN Sharing 12.4.0 13.0.0 RSE
Enhancements
SP-62 SP-130601 S1-135293 22.101 0464 2 Rel-13 D Editorial fixes to RAN Sharing 13.0.0 13.1.0 RSE
Enhancements
SP-62 SP-130601 S1-135309 22.101 0465 3 Rel-13 B Support for Load Balancing in 13.0.0 13.1.0 RSE
Shared E-UTRAN
SP-62 SP-130601 S1-135310 22.101 0466 3 Rel-13 B Additional RAN Sharing 13.0.0 13.1.0 RSE
Requirements
SP-62 SP-130601 S1-135294 22.101 0468 2 Rel-13 C Clarification of Hosting E-UTRAN 13.0.0 13.1.0 RSE
Operator role
SP-62 SP-130601 S1-135313 22.101 0469 3 Rel-13 C Adding explanatory text to 13.0.0 13.1.0 RSE
requirements on E-UTRAN
Sharing
SP-62 SP-130601 S1-135312 22.101 0470 3 Rel-13 B Enabling Dynamic capacity 13.0.0 13.1.0 RSE
negotiation
SP-63 SP-140066 S1-140230 22.101 0471 1 Rel-13 C RSE load balancing under EPC 13.1.0 13.2.0 RSE
congestion situations
SP-65 SP-140501 S1-143604 22.101 0473 5 Rel-13 B Exposure of network service and 13.2.0 13.3.0 SEES
capabilities to 3rd party
SP-65 SP-140508 S1-143607 22.101 0476 4 Rel-13 B Co-ordinated SIPTO Change of 13.2.0 13.3.0 CSIPTO
P-GW
SP-65 SP-140510 S1-143279 22.101 0479 1 Rel-13 C Definition of (S)Gi-LAN 13.2.0 13.3.0 FMSS
SP-65 SP-140510 S1-143556 22.101 0478 3 Rel-13 B Requirements for Flexible Mobile 13.2.0 13.3.0 FMSS
Steering Service
SP-66 SP-140755 S1-144611 22.101 481 2 Rel-13 B GERAN & UTRAN Sharing, 13.3.0 13.4.0 GUSH
change to the title of Section 28
and update to clause 28.1
SP-66 SP-140755 S1-144617 22.101 482 2 Rel-13 B GERAN & UTRAN Sharing, new 13.3.0 13.4.0 GUSH
clauses 28.3 and 28.3.1
(Allocation of Shared GERAN &
UTRAN requirements).
SP-66 SP-140755 S1-144618 22.101 483 2 Rel-13 B GERAN & UTRAN Sharing, new 13.3.0 13.4.0 GUSH
clause 28.3.2 (OA&M access to
the shared RAN).
SP-66 SP-140755 S1-144533 22.101 484 1 Rel-13 B GERAN & UTRAN Sharing, new 13.3.0 13.4.0 GUSH
clause 28.3.3 (Generation and
retrieval of usage and accounting
information).
SP-66 SP-140755 S1-144534 22.101 485 1 Rel-13 B GERAN & UTRAN Sharing, new 13.3.0 13.4.0 GUSH
clause 28.3.4 (MDT Collection)
SP-66 SP-140755 S1-144640 22.101 486 3 Rel-13 B GERAN & UTRAN Sharing, new 13.3.0 13.4.0 GUSH
clause 28.3.5 (PWS Support)
SP-66 SP-140755 S1-144619 22.101 487 2 Rel-13 B GERAN & UTRAN Sharing, new 13.3.0 13.4.0 GUSH
clause 28.3.6 (Support for load
balancing).
SP-66 SP-140755 S1-144636 22.101 488 3 Rel-13 B GERAN & UTRAN Sharing, new 13.3.0 13.4.0 GUSH
clause 28.3.7 (Dynamic capacity
negotiation).
SP-66 SP-140781 S1-144528 22.101 493 - Rel-13 A eCall mode of operation 13.3.0 13.4.0 EDATA
SP-66 SP-140751 S1-144556 22.101 494 - Rel-13 F Align the MTC monitoring 13.3.0 13.4.0 TEI13
requirements with Service
Exposure requirements
SP-67 SP-150039 S1-150214 22.101 495 2 Rel-13 F Update of Definitions 13.4.0 13.5.0 GUSH
SP-68 SP-150272 S1-151547 22.101 499 3 Rel-14 C Requirement to support domain 13.5.0 14.0.0 eDSVCC
selection between VoLTE and
CDMA CS
SP-68 SP-150276 S1-151536 22.101 496 3 Rel-14 B Update of eCall definition to 13.5.0 14.0.0 EIEI
include IMS emergency call

3GPP
Release 15 100 3GPP TS 22.101 V15.2.0 (2017-09)

based eCall
SP-68 SP-150276 S1-151537 22.101 497 2 Rel-14 B Support of IMS emergency calls 13.5.0 14.0.0 EIEI
in ICS
SP-68 SP-150276 S1-151538 22.101 498 2 Rel-14 B Update of transfer of MSD to 13.5.0 14.0.0 EIEI
include IMS emergency call
based eCall
SP-69 SP-150539 S1-152457 22.101 501 1 Rel-14 B Enhancements for control of 14.0.0 14.1.0 CATS
traffic from UE-based
applications toward associated
server
SP-71 SP-160100 S1-160473 22.101 0508 2 Rel-14 B Requirements for enhancements 14.1.0 14.2.0 eULRS
on User Location Reporting
Support
SP-71 SP-160112 S1-160300 22.101 0509 2 Rel-14 B Paging policy selection criteria 14.1.0 14.2.0 PPEPO_L
requirements in LTE TE
SP-71 SP-160110 S1-160474 22.101 0510 4 Rel-14 B Requirements for enhanced TV 14.1.0 14.2.0 EnTV
service
SP-71 SP-160096 S1-160173 22.101 0511 Rel-14 F Clarification of relationship 14.1.0 14.2.0 TEI14
between GTT and Real Time
Text
SP-71 SP-160116 S1-160541 22.101 0512 2 Rel-14 B Accounting for usage when using 14.1.0 14.2.0 USOS
unlicensed access networks
SP-71 SP-160114 S1-160302 22.101 0513 Rel-14 B Requirements for supporting third 14.1.0 14.2.0 eFMSS
party owned (S)Gi-LAN service
SP-72 SP-160353 S1-161594 22.101 518 1 Rel-14 A Addition of Cellular IoT non-IP 14.2.0 14.3.0 SEES
transport to exposed services
and capabilities
SP-73 SP-160541 S1-162532 22.101 0519 1 Rel-14 F Clarification of mobility 14.3.0 14.4.0 EIEI
management procedures for UEs
in eCall mode
SP-74 SP-160888 S1-163032 22.101 0520 Rel-14 F Update of eCall MSD reference 14.4.0 14.5.0 TEI14
SP-74 SP-160888 S1-163392 22.101 0521 3 Rel-14 F Support of Emergency sessions 14.4.0 14.5.0 TEI14
over WLAN
SP-74 SP-160889 S1-163452 22.101 0522 3 Rel-14 F Clarification of the consequences 14.4.0 14.5.0 EIEI
of eCall second attempts on
another domain
SP-75 SP-170149 S1-171437 22.101 0524 2 Rel-14 A Alignment of UPCON Service 14.5.0 14.6.0 UPCON
Requirements
SP-75 SP-170154 S1-171445 22.101 0525 2 Rel-14 F Support of Emergency sessions 14.5.0 14.6.0 TEI14
over WLAN
SP-75 SP-170155 S1-171275 22.101 0526 1 Rel-15 C Additon of 5G RAN sharing 14.5.0 15.0.0 SMARTE
R
SP-75 SP-170162 S1-171415 22.101 0528 1 Rel-15 B Enhancement of the service 14.5.0 15.0.0 eBT
exposure for background data
transfer
SP-75 SP-170247 S1-171440 22.101 0530 Rel-15 F Addition of informing PS Data Off 14.5.0 15.0.0 TEI15
state to Third Party
SP-76 SP-170437 S1-172231 22.101 0535 1 Rel-15 A Adding Device Triggering to the 15.0.0 15.1.0 SEES
Exposed Services and
Capabilities
SP-76 SP-170443 S1-172281 22.101 0532 2 Rel-15 F Correction of 5G-RAN sharing 15.0.0 15.1.0 SMARTE
=> not implementable, written on R
another spec (22.011)
SP-76 SP-170447 S1-172235 22.101 0536 1 Rel-15 B Requirements for access to 15.0.0 15.1.0 PARLOS
restricted local operator services
SP-77 SP-170694 S1-173451 22.101 0537 1 Rel-15 D Remove restricted local operator 15.1.0 15.2.0 PARLOS
services definition
SP-77 SP-170692 S1-173260 22.101 0539 1 Rel-15 F Correction of the term "5G-RAN" 15.1.0 15.2.0 TEI15
to "NG-RAN" in RAN sharing

3GPP