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)

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)

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
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
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
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
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
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
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
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
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
use a service provided by a mobile network operator. To preserve the limited supply of MSISDNs in the area, one
provider, suggests using a SIP capability and has offered to create a domain specifically for the Golden Gate Bridge,
goldengate.bridge.ca.net, allowing the state to assign its own names to the sensors. Messages are generated by the
state’s system and sent directly to the SIP URI assigned to a sensor when it was configured via a web service gateway
offered by the service provider. The service provider then translates the SIP URI into the IP address assigned to the
sensor when it first powered up and registered with the network. The sensors are pre-configured to send scheduled
reports to a web service provided by the state via the service provider’s messaging gateway. All messages are encrypted
in transit.
4.2.2 Actors
- The State of California
- Its wireless service provider
4.2.3 Pre-Conditions
- 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
.goldengate.bridge.ca.net.
- 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.2.4 Post-Conditions
- Sensors transmit data and trouble reports according to the schedule
- The state’s network receives and processes the reports
- The service provider’s network supports the traffic load
- Sensors are reachable via their SIP URI and the service provider’s message gateway
4.2.5 Normal Flow
In the course of normal operations, there are three main events for a given sensor:
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 state’s network sends a message to the sensor
Each of these events is comprised of a sequence of smaller steps.
Registration:
1) The sensor powers up
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
ETSI
3GPP TR 22.988 version 15.0.0 Release 15 10 ETSI TR 122 988 V15.0.0 (2019-07)
Remote-originated messages:
1) The sensor “wakes up” on schedule and establishes a SIP session with the SIP server
2) The sensor 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 sensor terminates the SIP session
5) The sensor goes back to “sleep”
Remote-terminated messages:
1) The state’s network generates a message addressed to a specific SIP URI
2) The state 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 sensor over the paging channel using the IMSI or IMPI
5) The sensor responds by establishing a SIP session with the SIP server
6) The service provider delivers the message to the sensor as a message payload
7) The sensor responds
8) The sensor terminates the SIP session
9) The sensor goes back to “sleep”
4.2.6 Alternative Flows
The messaging interface also allows the sensor to send trouble reports that go directly into the state’s trouble ticketing
system. These messages are generated by on-board logic in the sensor and sent to a different web service. The steps
required to do this are the same as for remote-originated messages described above.
4.2.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 the state uses occasionally
goes down. This is a result of the way the state’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 the state’s services come back online. The service provider has implemented Web
Services messaging and security practices.
4.3 Use case 3 Implantable Defibrillators
4.3.1 Short Description
Acme Medical Devices has introduced an implantable defibrillator that makes use the GSM network to provide 24 hour
access to patient status. These devices are expensive and are reserved for patients with very serious heart rhythm issues
or patients who have received a heart transplant. Existing implantable defibrillators require an external transceiver that
connects to a wired phone line. By embedding the mobile capability in the device, the expense and inconvenience of the
external transceiver is removed. The resulting devices are less expensive and allow the patient more latitude for travel
and moving around. Like existing devices, the lithium-ion batteries are charged by induction so no physical contact with
the device is required or desired.
ETSI
3GPP TR 22.988 version 15.0.0 Release 15 11 ETSI TR 122 988 V15.0.0 (2019-07)
The company estimates that 1-2 million devices will eventually be operating within North America, with the potential
for as many in Europe.
Regional and national wireless service providers have balked at allowing these devices to connect to their networks.
The problem, they say, is that the target markets for these devices are highly concentrated and would strain the
numbering resources in a few communities. Roaming is an issue but could be handled with existing business
agreements.
A consortium of service providers has proposed adopting SIP URIs as the primary means to address these devices.
Acme would be assigned a domain name, and would be free to assign each device a number or name of its choosing.
Acme has agreed to manufacture the devices to assume an IP connection, and Acme’s radio module manufacturers have
agreed to create modules that open an IP connection in response to a signal over the paging channel.
Future versions of the device may be able to capture location information and transmit that along with other medical
data to the nearest emergency call center or public safety answering point, effectively generating an automatic
emergency call.
4.3.2 Actors
- Acme Medical Devices Company
- Radio module manufacturers
- Wireless service provider
4.3.3 Pre-Conditions
- Acme’s suppliers provide IP-ready radio modules
- The service providers’ networks support SIP or IMS and are able to map a SIP URI to an IMSI or IMPI in their
HSS or HLR nodes
- The service providers have messaging gateways that allow Acme or doctors to contact specific devices via IM
messages or via SIP over IP
4.3.4 Post-Conditions
- Defibrillators can originate and receive messages over an IP connection
- The service providers’ networks support the loads
- Devices are reachable via their SIP URIs and the service provider message gateways
- Patients report increased satisfaction from not having to remain close to home
- The end-to-end system proves more reliable due to the nature of the connections between the old-style devices
and the external transceivers.
4.3.5 Normal Flow
In the course of normal operations, there are three main events for a given sensor:
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 company’s network sends a message to the sensor
Each of these events is comprised of a sequence of smaller steps.

Registration:
ETSI
3GPP TR 22.988 version 15.0.0 Release 15 12 ETSI TR 122 988 V15.0.0 (2019-07)
1) The devices are powered up and tested in the operating room before implantation
2) The device powers up
3) The radio module registers through the GPRSnetwork in the normal way
4) 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
Remote-originated messages (Assumes device is registered on the network):
1) The device “wakes up” on schedule and establishes a SIP session with the SIP server
2) The device 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 two messages are sent.
3) The SIP server acknowledges receipt of the message
4) The device terminates the SIP session
5) The device goes back to “sleep”
Remote-terminated messages:
1) The company’s network generates a message addressed to a specific SIP URI
2) The company 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 sensor over the paging channel using the IMSI or IMPI
5) The device responds by establishing a SIP session with the SIP server
6) The service provider delivers the message to the device as a message payload
7) The device responds
8) The device terminates the SIP session
9) The device goes back to “sleep”
4.3.6 Alternative Flows
When a device responds to an event in the patient’s heart, a report is generated an immediately sent to the doctor via the
company’s portal. Future versions of the device may use network and/or GPS information to capture location and
transmit an emergency call to the nearest emergency call center, either automatically or at the instructions of the
patient’s doctor.
4.3.7 Exceptions
The most critical exception occurs when the GSM network is unreachable. The radio modules are built to work on
every standard cellular network in either North America or Europe, depending on the model, but there are still areas that
do not have access to a network. In those cases, the device will queue up all event reports for transmission when the
network is next reachable.
4.4 Use case 4 (Wireless Utility Meters)
4.4.1 Short Description
The Edison Power company installed devices in its serving area to report meter readings at the end of billing cycles
each month. Devices can have different billing cycles. Each device is configured to send the meter reading to a pre-
ETSI
3GPP TR 22.988 version 15.0.0 Release 15 13 ETSI TR 122 988 V15.0.0 (2019-07)
configured Edison Power company server via the wireless connection.  The Edison Power company server can also
submit a request to an interworking gateway in the wireless service provider network to send a trigger to a specific
device to report the meter reading (e.g., when the service is terminated).
The Edison power company uses a device ID in the format of .meter.edisonpower.biz (e.g., a Fully
Qualified Domain Name (FQDN)) where the device-ID contains a 10-digit number and each number uniquely identifies
a device.
4.4.2 Actors
- Edison Power company
- Its wireless service provider
4.4.3 Pre-Conditions
- The wireless service provider has assigned an IMSI to each device and has provisioned that internal identifier
and other information on the relevant network nodes and on each device
- Devices are always powered on and attached to the wireless service provider network once it attaches to the
wireless service provider network
- Devices do not have always-on data connections but can listen and receive the trigger from the wireless service
provider network
- The wireless service provider network has an interworking gateway that allows the Edison Power company
server to submit a trigger request to be sent to a specific device indicated by a device ID in the format of <10-D
number>.meter.edisonpower.biz
- The wireless service provider network can map the device ID to the associated IMSI and send a trigger to the
associated device
- Each device has been configured to know where to send the meter reading to (e.g., Edison Power company
server’s IP address or domain name)
4.4.4 Post-Conditions
- Devices can send the meter reading over the data connection to the Edison Power company server at pre-
configured date/time of the month or when receiving a trigger from the Edison Power company server
- The Edison Power company server can submit a trigger request for any device and the wireless service provider
network can send the trigger to that device
4.4.5 Normal Flow
Send meter reading:
1) A device detects that it is scheduled to send a report or receives a trigger and takes the meter reading.
2) The device sets up a data connection and sends an IP packet containing its device ID and the meter reading to the
Edison Power company server’s IP address.
3) The Edison Power company server acknowledges the successful receipt of the meter reading.
4) The device terminates the data connection.
5) The wireless service provider network removes resources associated with the terminated data connection.

Submit a trigger request:
1) The Edison Power company server determines that it needs to ask a specific device to send the meter reading.
ETSI
3GPP TR 22.988 version 15.0.0 Release 15 14 ETSI TR 122 988 V15.0.0 (2019-07)
2) The Edison Power company server submits a trigger request for that specific device ID to an interworking
gateway in the wireless service provider network.
3) The interworking gateway in the wireless service provider network interrogates with relevant network nodes to
authenticate and authorize the request and sends a trigger to the device.
4) The device receives the trigger and invokes the “Send meter reading” process above to send the meter reading to
the Edison Power company server.
4.4.6 Alternative Flows
The wireless service provider network may return a positive indication to the Edison Power company server about the
successful delivery of the trigger to the device.
The Edison Power company server can include a command in the response to change the settings (e.g., date/time to
report meter reading) at the device when it receives the meter reading from the device.
4.4.7 Exceptions
The device re-sends the meter reading at a configured time later if it cannot communicate with the Edison Power
company server or the Edison Power company server indicates an internal problem.
The wireless service provider network may return a negative indication to the Edison Power company server if it fails to
deliver the trigger to the device.
4.5 Use case 5 (Wireless Weather Monitors
...