ETSI TR 122 988 V15.0.0 (2019-07)

Universal Mobile Telecommunications System (UMTS); LTE; Study on alternatives to E.164 for Machine-Type Communications (MTC) (3GPP TR 22.988 version 15.0.0 Release 15)

RTR/TSGS-0122988vf00

General Information

• Status: Published
• Publication Date: 22-Jul-2019
• Technical Committee: 3GPP SA 1 - Services
• Current Stage: 12 - Completion
• Completion Date: 23-Jul-2019

Standards Content (Sample)

ETSI TR 122 988 V15.0.0 (2019-07)






TECHNICAL REPORT
Universal Mobile Telecommunications System (UMTS);
LTE;
Study on alternatives to E.164 for Machine-Type
Communications (MTC)
(3GPP TR 22.988 version 15.0.0 Release 15)

---------------------- Page: 1 ----------------------
3GPP TR 22.988 version 15.0.0 Release 15 1 ETSI TR 122 988 V15.0.0 (2019-07)



Reference
RTR/TSGS-0122988vf00
Keywords
LTE,UMTS
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2019.
All rights reserved.

DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.

3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners.
®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI

---------------------- Page: 2 ----------------------
3GPP TR 22.988 version 15.0.0 Release 15 2 ETSI TR 122 988 V15.0.0 (2019-07)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Legal Notice
This Technical Report (TR) has been produced by ETSI 3rd Generation Partnership Project (3GPP).
The present document may refer to technical specifications or reports using their 3GPP identities. These shall be
interpreted as being references to the corresponding ETSI deliverables.
The cross reference between 3GPP and ETSI identities can be found under http://webapp.etsi.org/key/queryform.asp.
Modal verbs terminology
In the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be
interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI

---------------------- Page: 3 ----------------------
3GPP TR 22.988 version 15.0.0 Release 15 3 ETSI TR 122 988 V15.0.0 (2019-07)
Contents
Intellectual Property Rights . 2
Legal Notice . 2
Modal verbs terminology . 2
Foreword . 5
Introduction . 5
1 Scope . 6
2 References . 6
3 Definitions, symbols and abbreviations . 6
3.1 Definitions . 6
3.2 Symbols . 6
3.3 Abbreviations . 6
4 Use cases . 6
4.1 Use case 1 (Wireless Vending Machines) . 6
4.1.1 Short Description . 6
4.1.2 Actors . 7
4.1.3 Pre-Conditions . 7
4.1.4 Post-Conditions . 7
4.1.5 Normal Flow . 7
4.1.6 Alternative Flows . 8
4.1.7 Exceptions. 8
4.2 Use case 2 (Smart Bridges and Tunnels) . 8
4.2.1 Short Description . 8
4.2.2 Actors . 9
4.2.3 Pre-Conditions . 9
4.2.4 Post-Conditions . 9
4.2.5 Normal Flow . 9
4.2.6 Alternative Flows . 10
4.2.7 Exceptions. 10
4.3 Use case 3 Implantable Defibrillators . 10
4.3.1 Short Description . 10
4.3.2 Actors . 11
4.3.3 Pre-Conditions . 11
4.3.4 Post-Conditions . 11
4.3.5 Normal Flow . 11
4.3.6 Alternative Flows . 12
4.3.7 Exceptions. 12
4.4 Use case 4 (Wireless Utility Meters) . 12
4.4.1 Short Description . 12
4.4.2 Actors . 13
4.4.3 Pre-Conditions . 13
4.4.4 Post-Conditions . 13
4.4.5 Normal Flow . 13
4.4.6 Alternative Flows . 14
4.4.7 Exceptions. 14
4.5 Use case 5 (Wireless Weather Monitors) . 14
4.5.1 Short Description . 14
4.5.2 Actors . 14
4.5.3 Pre-Conditions . 14
4.5.4 Post-Conditions . 15
4.5.5 Normal Flow . 15
4.5.6 Alternative Flows . 15
4.5.7 Exceptions. 15
ETSI

---------------------- Page: 4 ----------------------
3GPP TR 22.988 version 15.0.0 Release 15 4 ETSI TR 122 988 V15.0.0 (2019-07)
5 High level Service Aspects . 16
5.1 What are the high level requirements for alternatives to E.164 for machine-type communications? . 16
5.1.1 Large capacity . 17
5.1.2 Compatibility with existing schemes . 17
5.1.3 Impact on existing systems and hardware. 17
5.1.4 Provisioning . 17
5.1.5 Device Identity Portability . 17
5.1.6 Charging . 18
5.1.7 Services . 18
5.2 What are the security, reliability, and priority handling requirements for alternatives to E.164 for
machine-type communications? . 18
5.3 Are there any implications due to roaming? . 18
5.4 Are there any implications on inter-domain routing? . 18
5.5 Are there any implications to hand-over between access networks? . 18
6 MMI Aspects . 18
7 Charging Aspects . 19
8 Security Aspects . 19
9 Analysis . 19
9.1 MSISDN (E.164) with existing number length . 21
9.2 MSISDN (E.164) with max length of 15 digits . 21
9.3 E.212 Numbers (IMSI) . 21
9.4 Other Numbering Plan Indicator in MAP . 21
9.5 Generic Uniform Resource Identifier (URI). 22
9.5.1 SIP Uniform Resource Identifier (URI) . 22
9.5.2 TEL Uniform Resource Identifier (URI) . 22
9.6 Fully Qualified Domain Name (FQDN) . 23
9.7 IPv4 Address . 23
9.8 IPv6 Address . 23
9.9 Network Access Identifier (NAI) . 24
10 Conclusion . 24
11 Potential requirements for alternatives to E.164 for machine-type communications . 25
Annex A:  Additional Definitions (Informative) . 26
Annex B: Change history . 27
History . 28


ETSI

---------------------- Page: 5 ----------------------
3GPP TR 22.988 version 15.0.0 Release 15 5 ETSI TR 122 988 V15.0.0 (2019-07)
Foreword
rd
This Technical Report has been produced by the 3 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.
Introduction
There are currently unprecedented demands within the telecommunications industry for E.164 MSISDNs resources and
these demands are expected to accelerate in the years to come. Accordingly, some countries and their national
regulatory authorities have expressed concerns over the numbering requirements of new services involving Machine
Type Communications (MTC) services and their expected rapid growth.
MTC demand is forecast to grow from 50M connections to over 200M by 2013. A large number of these services are
currently deployed over circuit-switched GSM architectures and therefore use E.164 MSISDNs although such services
do not require 'dialable' numbers, and generally do not communicate with each other by human interaction.
Without technical alternative to using public international numbering resources as addresses, and considering the
current forecasts and pending applications for numbers made to numbering plan administration agencies, there is a
significant risk that some national numbering/dialling plans will run out of numbers in the near future, which would
impact not only these MTC services but also the GSM/UMTS service providers in general.
ETSI

---------------------- Page: 6 ----------------------
3GPP TR 22.988 version 15.0.0 Release 15 6 ETSI TR 122 988 V15.0.0 (2019-07)
1 Scope
This document seeks to study and highlight the challenge of using the existing public numbering resources to support
Machine Type Communication (MTC) services and proposes that 3GPP develop an alternative to using public
numbering resources for MTC communications.
2 References
[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications".
[2] 3GPP TS 41.101: "Technical Specifications and Technical Reports for a GERAN-based 3GPP
system".
[3] IETF RFC 3986 "Uniform Resource Identifier (URI): Generic Syntax”.
3 Definitions, symbols 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].
(void)
3.2 Symbols
For the purposes of the present document, the following symbols apply:
(void)
3.3 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].
NIMTC Network Improvements for Machine Type Communications
MNO Mobile Network Operator
MTC Machine-Type Communications

4 Use cases
4.1 Use case 1 (Wireless Vending Machines)
4.1.1 Short Description
The Snack Company owns 100,000 snack vending machines in the Tri-City area. Each machine is connected to Snack’s
central network via a wireless connection and sends a report of sales every hour. These scheduled reports are staggered
so they don’t collide within Snack’s systems. These reports are short bursts of no more than a few hundred bytes of
data, and typically take less than 3 seconds to transmit. On occasion, Snack’s network will contact a machine by
sending it an SMS, to which the machine sends a response.
ETSI

---------------------- Page: 7 ----------------------
3GPP TR 22.988 version 15.0.0 Release 15 7 ETSI TR 122 988 V15.0.0 (2019-07)
Snack would like to add another 250,000 machines across the state, but their wireless service providers cannot provide
enough MSISDNs. One provider, however, has implemented SIP capability, and makes available radio modules that use
all-IP connections over the radio network. The main benefits to this new service is that each machine is assigned a SIP
URI rather than a MSISDN (an alphanumerical SIP URI that doesn’t encapsulate a phone number), and that the service
provider expects network loads and costs to decrease by going with all-IP traffic. The service provider’s network can
easily handle the traffic load from 350,000 vending machines.
The service provider has assigned Snack its own domain, vending. snack.com, so Snack can assign its own names to the
machines. Snack has chosen to use its internal asset numbers for machine names to simplify the mapping from their
asset management system to the messaging interface provided by the service provider. Messages are generated by
Snack’s system and sent via the Internet to a web service provided by the service provider. The service provider then
delivers the messages to the machines using SMS over IP. The machine modules are pre-configured to send scheduled
reports to a web service provided by the service provider that transmits them to Snack’s network. All messages are
encrypted in transit.
Because the service provider was able to “recover” 100,000 previously issued MSISDNs, it was able to expand its
coverage to wireless service consumers, generating much greater margins in the process.
4.1.2 Actors
- Snack Company
- Its wireless service provider
4.1.3 Pre-Conditions
- The service provider has available to it IP-ready radio modules
- The service provider’s network can support SIP or IMS, and is able to map a SIP URI to an IMSI or IMPI in its
HLR or HSS node. The service provider can support SIP URIs with a domain name of
vending.snack.com.
- The service provider has a messaging gateway, maybe not much more than a web service
- The radio modules are capable of establishing an IP connection in response to a page over the paging channel
4.1.4 Post-Conditions
- Vending machines transmit sales and trouble reports according to the schedule
- Snack’s network receives and processes the reports
- The service provider’s network supports the traffic load
- Machines are reachable via their SIP URI and the service provider’s message gateway
- The service provider’s experience allows it to lower the price charged to Snack by 25%
4.1.5 Normal Flow
In the course of normal operations, there are three main events for a given vending machine:
1) When it first powers up and registers with the network
2) When it generates and sends a report to the network
3) When the Snack network sends a message to the machine
Each of these events is comprised of a sequence of smaller steps.
Registration:
1) The machine powers up
ETSI

---------------------- Page: 8 ----------------------
3GPP TR 22.988 version 15.0.0 Release 15 8 ETSI TR 122 988 V15.0.0 (2019-07)
2) The radio module registers through the GPRSnetwork in the normal way
3) The radio module registers with the SIP server on the service provider’s network. This sets up the mapping
between the SIP URI in the HSS and the newly assigned IP address
Note: this would normally require a MSISDN+IMSI (IMSI for authentication and MSISDN generally required
in all back-office IT/IS).
Remote-originated messages:
1) The machine “wakes up” on schedule and establishes a SIP session with the SIP server
2) The machine generates a report as a short message then transmits that to the SIP server as a message payload. If
the message is more than 1500 bytes, then concatenated messages are sent.
3) The SIP server acknowledges receipt of the message
4) The machine terminates the SIP session
5) The machine goes back to “sleep”
Remote-terminated messages:
1) The Snack network generates a message addressed to a specific SIP URI
2) Snack sends the message to the service provider’s message gateway
3) The service provider’s HSS contains the mapping of SIP URI to IMSI or IMPI, and to the currently assigned IP
address
4) The service provider pages the machine over the paging channel using the IMSI or IMPI
5) The machine responds by establishing a SIP session with the SIP server
6) The service provider delivers the message to the machine as a message payload
7) The machine responds
8) The machine terminates the SIP session
9) The machine goes back to “sleep”
4.1.6 Alternative Flows
The messaging interface also allows the machine to send trouble reports that go directly into Snack’s trouble ticketing
system. These messages are generated by on-board logic in the machine and sent to a different web service. The steps
required to do this are the same as for remote-originated messages described above.
4.1.7 Exceptions
Due to the standard nature of the communications, the main exceptions occur when a message cannot be delivered for
some reason. The most common reason, based on early experience, is that the web service Acme occasionally goes
down. This is a result of the way Snack’s services are configured and not related to SIP or the service provider’s
network. When this happens, the web services on the service provider’s network queue the messages and deliver them
in the order they were received when Snack’s services come back online. The service provider has implemented Web
Services messaging and security practices.
4.2 Use case 2 (Smart Bridges and Tunnels)
4.2.1 Short Description
The State of California would like to install up to 150,000 sensors on the Golden Gate Bridge to monitor structural
elements by measuring displacement, temperature, humidity, and magnetic or ultrasonic resonance. These measures are
ETSI

---------------------- Page: 9 ----------------------
3GPP TR 22.988 version 15.0.0 Release 15 9 ETSI TR 122 988 V15.0.0 (2019-07)
used to detect structural deficiencies in the bridge that require attention, perhaps immediate attention. Each sensor takes
measurements on a periodic basis, “wakes up,” and transmits a short burst of data of less than a few hundred bytes to
the state’s central system where it is analyzed. On occasion, the state’s system will contact a sensor by sending it an
SMS, to which the machine sends a response. Most often, this is a result of the system needing more information based
on the report of another sensor nearby. The sensors use an IP data connection.
Due to the expense and time required to install wire-based connections and the advancements in battery technology, the
state wants to use wireless network. To avoid having to buy, install, and run its own radio network, the state decides to
u
...