[STANDARDS]

AN OVERVIEW OF
3GPP EXPOSED SERVICES
FOR IoT SERVICE PLATFORMS
Besides providing IP-based data pipes to cellular devices, the 3GPP Core Network consists of a rich
set of network services and capabilities, such as charging, mobility management, session management,
policy enforcement, control plane messaging, reachability management, and control of deep sleep modes.
This article presents an overview the 3GPP SCEF Northbound API Interface (T8) standard, which has
been specified in 3GPP Release 15 to expose some of the internal network services and capabilities.
We first give an overview of the history of the Service Capability Exposure Function (SCEF) API exposing
function, then provide an overview of the services and capabilities that are exposed by the Northbound
APIs along with examples of how the APIs may be used by a services platform.

16 GetMobile June 2018 | Volume 22, Issue 2


Michael Starsinic, Dale Seed, Chonggang Wang InterDigital Communications, USA
Editors: Michelle X. Gong and Shiwen Mao
I
n a “traditional” Internet of Things (IoT)
deployment architecture, an IoT server
offers a set of services (e.g., data storage,
reachability management, device manage-
ment, etc.), to customer facing applications and
controls large groups of devices. For example,
in an asset tracking application, an IoT server
might communicate with asset tracking devices
and provide interfaces that allow customers
to view where their assets are located, where
they have been, and request notifications when
devices leave or arrive in an area. Besides
managing data exchange with the devices, the
IoT server typically provides additional device
management services, such as providing the
ability to push software upgrades to tracking
devices. Figure 1 shows an example of this
traditional IoT architecture, where the asset
Photo, istockphoto.com
tracking devices are 3GPP user equipment
(UEs). In this example, the devices are associ-
ated with packages and vehicles in a warehouse
and the devices’ connections to the IoT server
are made over the 3GPP Network.
June 2018 | Volume 22, Issue 2 GetMobile
[STANDARDS]
FIGURE 1.
Traditional IoT architecture.
As shown in Figure 1, the traditional
architecture treats the underlying 3GPP
Network as a data pipe. However, the 3GPP
Network consists of many more services
and capabilities beyond providing simple
data pipes. For example, the 3GPP Network
Mobility Management Entity (MME) is
generally aware of UE status (e.g. location
and reachability) and can send control plane
messages to devices, the RAN Congestion
Awareness Function (RCAF) can provide
network status (e.g. congestion levels), and
the Policy and Charging Rules Function can
apply charging and QoS polices to select
traffic flows. Additionally, there are messaging
services within the 3GPP Network, such as
the Short Message Service – Service Center
(SMS-SC) and the Broadcast Multicast –
Service Center (BM-SC). Also, the 3GPP
Network’s Home Subscriber Server (HSS)
provides the necessary infrastructure for
subscription management and device
authentication and authorization.
17
[STANDARDS]

In order to facilitate the IoT server’s

use of the services and capabilities in the
3GPP Network, 3GPP has developed a
new interface in Release 15, which exposes
northbound Application Programming
Interfaces (APIs) to the IoT server. These
APIs, which are now defined in TS 29.122
[1] allow the IoT server to access the
capabilities and services of the 3GPP
Network. The APIs are terminated in the
3GPP Network at the Service Capability
Exposure Function (SCEF). This new API
interface is shown in Figure 2 and is called
T8. In 3GPP terminology, the Service
Capability Server/Application Server (SCS/
AS) is a server (i.e., an IoT server) that uses
the T8 APIs to access the capabilities and
services of the 3GPP Network.
In this article, we provide an overview
of the functionality that is exposed to the
SCS/AS over the T8 APIs. The remainder
of this article is structured as follows.
Section I provides an overview of the SCEF
and a brief history of its standardization.
Section II is a discussion of T8 APIs that
are exposed by the SCEF to allow for
monitoring device status that is known to
the core network but has traditionally been
hidden from third parties. Section III is an
overview of T8 APIs that can be used by FIGURE 2. Traditional IoT architecture with the SCEF.
the SCS/AS to configure services that are
associated with the UEs that it controls/
manages. Section IV describes T8 APIs the SCS/AS. Thus, the SCS/AS is securely southbound Interfaces) and not how the
that are used by the SCS/AS and 3GPP isolated from the internal 3GPP network SCEF interacts with the SCS/AS (on the
Network to better coordinate when the nodes. Although the SCEF is part of the Northbound Interface) to expose services
SCS/AS exchanges data with its associated network operator’s trust domain, the SCS/ and capabilities.
UEs. Section V presents T8 APIs that AS(s) that it interfaces to may or may not be In Release 15, 3GPP standardized
can be used by the SCS/AS to exchange part of the network operator’s trust domain. the SCEF Northbound APIs [3]. The
small data packets with UEs via the 3GPP For example, an SCS/AS may be a device architectural definition was completed
control plane. In Section VI, we describe management platform that is deployed and by 3GPP’s Service and System Aspects
APIs that can be used by the SCS/AS to controlled by the network operator or it may Working Group 2 (SA2) as part of the
take advantage of the Policy and Charging be a services platform that is deployed by a Northbound APIs for SCEF – SCS/AS
infrastructure within the core network. third party that has a business relationship Interworking (NAPS) work Item [4] and
Lastly, in Section VII, we conclude the with the network operator. resulted in extensive updates to TS 23.682
article and discuss what is coming next in In Release 13, 3GPP only standardized [2], which specifies how the SCEF interacts
terms of service exposure standardization. how the SCEF interacts with other nodes with the SCS/AS. The Northbound API
within the 3GPP core network. The interface was given the name T8. The
I. THE SERVICE CAPABILITY interfaces that connect the SCEF to internal protocol definition of the Northbound
EXPOSURE FUNCTION (SCEF) core network nodes are termed Southbound APIs was defined by 3GPP’s Core Network
The SCEF is a 3GPP core network node interfaces and listed in Table 1. In Release and Terminals Working Group 3 (CT3) in
that was added in the 3GPP Release 13 13, the APIs that were exposed by the a new specification, TS 29.122 [1], which
specifications. The architecture of the SCEF SCEF, on the SCEF Northbound Interface binds the T8 APIs to Hypertext Transfer
is defined in TS 23.682 [2]. The SCEF towards SCS/AS, were deemed outside the Protocol (HTTP). Furthermore, SA6
exposes 3GPP services and capabilities to scope of the 3GPP specifications. Thus, created a new specification, TS 23.222 [5],
the SCS/AS via a set of APIs and hides the 3GPP only standardized how the SCEF which defines a common API framework
underlying 3GPP network topology from interacts with the core network (on the (CAPIF) that specifies API aspects that are

18 GetMobile June 2018 | Volume 22, Issue 2

 [STANDARDS]

TABLE 1. SCEF Southbound Interfaces

Reference Nodes Protocol Specification

Point Name
Nt PCRF – SCEF Diameter TS 29.154
S6t, S6m HSS – SCEF Diameter TS 29.336
T6a/b MME – SCEF Diameter TS 29.128
T7 SCEF – IWK-SCEF Diameter TS 29.128
Ns RCAF - SCEF Diameter TS 29.153
Nu PFDF – SCEF HTTP TS 29.250
Rx PCRF - SCEF Diameter TS 29.214
xMB-U BM-SC - SCEF HTTP TS 29.116
xMB-C BM-SC - SCEF HTTPS TS 29.116
MB2-U BM-SC - SCEF UDP TS 29.468
MB2-C BM-SC – SCEF Diameter TS 29.468
T4 SMS-SC – SCEF Diameter TS 29.337 FIGURE 3. Example of monitoring request and notification flow.

common to all Northbound API interfaces
(e.g., registration, discovery, identity
management).
The APIs that are exposed by the SCEF
on the T8 interface generally fall into 4
categories; APIs that allow the SCS/AS to
access the internal capabilities of the 3GPP
core network (discussed in Section II),
APIs that allow the SCS/AS to assist the
3GPP core network in more efficiently
configuring the 3GPP core network services
(discussed in Section III), APIs that allow
the SCS/AS to better coordinate its activity
with the 3GPP core network (discussed in
Section IV), and APIs that allow the SCS/
AS to send and receive small data packets
via the control plane of the 3GPP core
network (discussed in section V).
II. APIS FOR MONITORING
EVENTS AND STATUS
Based on its control plane interactions
with the UE, the 3GPP core network has
a significant amount of insight into the
UE’s status. This status information is often
information that is desired by the SCS/AS,
but has not traditionally been shared by the
core network. Instead, the SCS/AS has relied
on application layer interaction with the UE
to detect things, such as the UE’s availability
status (e.g., heartbeat messages) and location
(e.g., GPS information). The T8 APIs
provide the SCS/AS with access to a rich set
of UE status information. The SCS/AS can
access the status information for individual
UEs or for groups of UEs. The SCS/AS
can in turn expose this information to the
applications that it hosts, thus reducing
the amount of application layer interaction
required to obtain the information. This
results in increased battery life and more
efficient use of spectrum. Some examples
of the type of status information and
indications that the 3GPP core network can
expose to the SCS/AS are listed in Table 2.
The T8 Interface Monitoring Event
API allows the SCS/AS to monitor the
events listed in Table 2 for a single UE or
for a group of UEs. When the Monitoring
Event API is invoked, the SCS/AS identifies
the UE or group of UEs by specifying the
associated External Identifier or External
Group Identifier respectively. These
identifiers are defined in [2] and intended
to be exposed outside of the 3GPP network
operator’s trust domain. The SCEF and
Home Subscriber Server (HSS) will map
these identifiers to internal core network
identifier(s) (e.g., an International Mobile
Subscriber Identity/IMSI) so that internal
subscription identifiers are not exposed
outside of the trust domain. Figure 3 shows
an example flow, where the SCS/AS uses an
HTTP POST to request that the 3GPP core
network monitor a UE or a group of UEs
for an event. The event is indicated with a
Monitoring Type Attribute, which indicates
one of the events listed in Table 2.
III. APIS FOR SERVICE
CONFIGURATION
The 3GPP core network offers several
services that are particularly useful to
UEs that are used in IoT applications.
For example, the 3GPP core network is
able to configure UEs to use power saving
features such as Power Saving Mode (PSM)
and Extended idle-mode Discontinuous
Reception (eDRX), configure a UE’s use of
the Enhanced Coverage feature, provide
information to the RAN to help the RAN
minimize UE state transitions, and buffer
downlink packets that are sent towards
UEs that cannot be paged because they
are in deep sleep. These features can be
configured based on parameters that are
statically configured in the UEs sub-
scription. However, by configuring these
services in a relatively static manner, the
usefulness can become somewhat limited.
For example, some sensor applications
that are hosted in a UE may typically be
able to sleep for long stretches of time, but
the SCS/AS may want to demand that the
UE be available more quickly during an
emergency situation.
The T8 Interface exposes APIs that
allow the SCS/AS to influence whether
these features are active and how they are
configured. The APIs that can be used to
configure these services are listed in Table 3
along with some examples of how the SCS/
AS may use them.

June 2018 | Volume 22, Issue 2 GetMobile 19

[STANDARDS]
IV. APIS FOR SCS/AS AND
NETWORK COORDINATION
Some APIs can be used by the 3GPP Network
and SCS/AS to better manage network
resources and avoid network congestion; two
examples are the Reporting Network Status
API and Background Data Transfer API.
The Reporting Network Status API
allows the SCS/AS to receive reports from
the 3GPP Network about congestion
levels in a given area. Since IoT traffic is
often time tolerant and IoT devices are
often known to be in particular areas, this
information can be used by the SCS/AS to
delay interaction with UEs (e.g., polling)
that are in a congested area until the
congestion situation has subsided.
Sometimes, an SCS/AS may know that
it needs to exchange data with a number of
UEs in a geographical area. For example, the
SCS/AS may know that it needs to send a 10
Mbyte software upgrade to 100 sensors in
the next 24 hours or that it needs to collect
1 Mbyte of data from 100 sensors sometime
in the next 24 hours. In such scenarios,
the Background Data Transfer API allows
the SCS/AS to provide the network with
the requirements of the data transfer (e.g.
number of UEs, how much data per UE,
and time constraints). The network’s policy
engine (i.e., the Policy and Charging Rules
Function/PCRF) is able to provide the SCS/
AS with a set of policy(s) that indicate the
best time(s) to perform the data transfer. The
SCS/AS can then activate the transfer policy
for the UEs that are going to be involved in
the data transfer. Thus, this API gives the
network operator the ability to influence the
SCS/AS to delay its activity until time periods
where the network is typically underutilized
and, in return, SCS/AS service providers may
receive better charging rates.
V. APIS FOR CONTROL
PLANE DATA EXCHANGE
Some IoT devices are characterized by the
fact that they only send and receive small
data packets. The data packets could be
so small that, when sent over an IP based
protocol, the protocol overhead may far
outweigh the actual data being exchanged.
The SCEF exposes APIs that allow the SCS/
AS to exchange data with the UE via two
different control plane based data delivery
methods, SMS and NAS-based Non-IP
Data Delivery (NIDD).
20 GetMobile June 2018 | Volume 22, Issue 2
TABLE 2. Monitoring Types and Example Usages
Monitoring Type Example Usage
Loss of Connectivity The SCS/AS can request notification if the UE loses connectivity, for
example, if the UE detaches from the 3GPP Network, if the 3GPP
Network detaches the UE, or if the UE has not communicated with the
3GPP Network after a pre-defined time.
Reachability The SCS/AS can request notification when the UE attaches or wakes
up and is available to communicate with the SCS/AS. This option is
used when the SCS/AS needs to detect when a UE becomes reachable
after being in a long power saving sleep cycle.
Location The SCS/AS can request the current, or last known, location of a UE.
Change of International Mobile Equipment Identifier (IMEI) identifies the device
IMSI IMEI Association that is being used to access the network with the subscription that is
associated with the IMSI. The SCS/AS can request notification if the
UE’s IMSI is suddenly associated with a different device, possibly
indicating that a SIM card was moved to a separate device.
Roaming Status The SCS/AS can request notification if the UE is roaming, and to be
notified if the UE’s status changes to roaming or not roaming. The
SCS/AS can use this information to delay data exchange until the UE
is not roaming.
Communication Failure The SCS/AS can request that it be sent a notification if there is a failure
associated with the UE’s 3GPP Radio Access Network (RAN),
Non-Access Stratum (NAS), or WLAN Access Network connections.
Availability after The Application Server can request notification when the UE becomes
Downlink Data Failure reachable after any downlink data sent to the UE is discarded. For
example, if the application attempts to send data to a sleeping device,
the 3GPP Network may discard the data and notify the SCS/AS when it
wakes up and is available to communicate.
Number of UEs in a The SCS/AS can request a report of how many UEs that are associated
Geographical Area with a specific group are in a geographical area. For example, a fleet
tracking SCS/AS could use this information to check how many of its
delivery trucks are in a geographic area.
For SMS Delivery, the SCEF exposes the application’s PDN connection. 3GPP has
APIs that allow the SCS/AS to exchange also standardized a Reliable Data Service
data packets with UE hosted applications protocol that can be used when exchanging
via SMS. An Application Port ID is used data packets between the UE and SCEF. This
on the API interface to multiplex traffic protocol, which requires a 1 to 3-byte header
for the case where the UE hosts multiple on the non-IP data packet, is defined in TS
SMS-based applications. The UE uses the 24.250 and can be used to multiplex traffic
Application Port ID field of the SMS header from multiple applications onto the same
to determine the receiving application and PDN connection instead of provisioning
indicate the sending application. separate APNs. Besides being used to
For data delivery over NAS, the SCEF multiplex traffic from multiple applications,
exposes APIs that allow the SCS/AS to the protocol can be used to simplify the
exchange data packets with the UE. The UE hosted applications because it can be
NAS data packets are associated with a configured to provide functionality such as
PDN connection between the UE and acknowledged and in sequence delivery.
the SCEF. When the UE hosts multiple These control plane, non-IP, data
applications that need to exchange small delivery methods can also be used to trigger
data packets with the SCEF, the data from UE hosted applications. For example, IoT
the applications can be multiplexed onto applications are often characterized by the
separate PDN connections, of course this fact that they rarely need to receive data but
assumes that each UE hosted application periodically send a heartbeat message to a
has been provisioned with an Access Point server to indicate that the device is active
Name (APN) that can be used to establish and able to receive data. Rather than send
 [STANDARDS]

TABLE 3. Configuration Parameters and Example Usages
API Example Usage
Enhanced Coverage The SCS/AS can use this API to check if Enhanced Coverage
Restriction Control Restriction is enabled for a UE and to disable or enable this feature.
The SCS/AS service provider and network operator may have an
agreement whereby the service provider is charged extra for
coverage enhancements. The service provider can use this API to turn
on the feature only for devices that need to be reached immediately.
Network Parameter The SCS/AS can use this API to tell the 3GPP Network the maximum
Configuration acceptable delay between the UE’s reachability occasions and how
long the UE needs to be available for mobile terminated data after
it becomes reachable. The network can use this information to
configure the UE’s DRX cycles, Power Saving Mode, and Tracking Area
Update timer.
This API can also be used to tell the network how many downlink
packets the network should buffer for the UE when it is sleeping.
Communication Pattern The SCS/AS can use this API to tell the network when a device is
Configuration expected to communicate. The core network can then use this
information to create assistance information for the RAN. The RAN
may then use the assistance information to minimize UE state
transitions.
5G, it is notable that the 3GPP Release 15
5G Core Network (5GC) already supports
exposing some of the same functions defined
on the T8 interface by the 4G Evolved Packet
Core (EPC). SA2 is conducting a study called
Cellular IoT Support and Evolution for the
5G System (FS_CIoT_5G), whose objectives
include providing functionality in the 5GC
that is equivalent to what is provided by the
SCEF in the EPC [7]. n
Michael Starsinic (Michael.Starsinic@
InterDigital.com) is a principal engineer at
InterDigital, Inc. and represents Convida
Wireless in 3GPP’s SA2 working group. For the
past seven years, his research interests have
been centered on IoT related communication
technologies. Michael has been working on
cellular communications technologies, such
as 3G FDD/TDD, LTE, and 5G since 2001. His
experience spans multiple areas of the network
and protocol stack.

Dale Seed (Dale.Seed@InterDigital.Com)

heartbeat messages to the server, the UE
can listen on an SMS Port or Non-IP PDN
Connection for a short trigger, or wake up
message, requesting that the UE application
contact the server. Since SMS messages are
stored in the network when the recipient
UE is sleeping, SMS triggers are particularly
useful for initiating contact with UEs that
sleep for long stretches of time.
The SCEF also provides APIs that the
SCS/AS can use to send the same data to
groups of devices. When sending data to a
group, the group is identified by an External
Group Identifier. The T8 APIs provide for
two group message delivery methods. The
first method uses the Multimedia Broadcast
Multicast Service (MBMS) and requires that
the MBMS information be distributed to
the recipient UEs before the group message
is broadcast over the identified geographical
area. The second group message delivery
method uses NIDD to send the same
non-IP packet to the group of UEs that is
identified by the External Group Identifier.
VI. POLICY AND CHARGING
CONTROL APIS
The T8 interface also exposes APIs that
allow the SCS/AS to better take advantage
of the PCC system within the 3GPP core
network. The SCS/AS can use the Session
QoS API to indicate the desired level of
QoS (e.g., jitter, latency, and priority) for
a given IP traffic flow. A Chargeable Party
API allows the SCS/AS to inform the
network that it will start or stop sponsoring
a given traffic flow. The SCS/AS can also
use the T8 Interface to provide Packet
Flow Descriptors (PFDs) to the Packet
Flow Description Function (PFDF) within
the 3GPP network so they can be used to
detect certain types of traffic flow and apply
specific PCC rules to the detected flows.
VII. CONCLUSION
This article presented an overview of the
SCEF Northbound API Interface (T8),
which has been standardized in 3GPP
Release 15. We first gave an overview
of history of the SCEF standardization
and then an overview of the services
and capabilities that are exposed by the
Northbound APIs along with examples of
how the APIs may be used by an SCS/AS.
Industry adoption of the T8 Interface
has already begun. oneM2M is a standards
development organization that is developing
service layer standards for IoT devices,
gateways, and servers [8]. oneM2M’s
Infrastructure Common Services Entity
(IN-CSE) is a type of SCS/AS that can
make use of the T8 APIs. oneM2M has
already standardized how an IN-CSE can
take advantage of the T8 APIs, including
defining how oneM2M messages can
be exchanged with UE hosted oneM2M
Applications via NIDD APIs [9].
As the telecom industry moves towards
is a principal engineer at InterDigital, Inc.,
where he leads the architecture and design of
InterDigital’s Chordant IoT Platform. He serves as
chairman of the oneM2M Architecture Working
Group, and is a member of Convida Wireless, a
partnership between InterDigital and Sony that
is focused on IoT research and development.
Chonggang Wang (Chonggang.Wang@
InterDigital.Com) is a member of technical
staff at InterDigital, Inc. His research interests
span IoT architecture and protocols, distributed
ledger and blockchain technologies, edge
and fog computing, semantics computing
and services, augmented intelligence for
autonomous IoT systems, etc. He is an IEEE
Fellow for contributions to IoT enabling
technologies.
REFERENCES
[1] 3GPP TS 29.122, T8 reference point for
Northbound APIs (Release 15).
[2] 3GPP TS 23.682, Architecture enhancements
to facilitate communications with packet data
networks and applications (Release 15).
[3] 3GPP SA SP-160952, Northbound SCEF API
standardisation requested by oneM2M.
[4] 3GPP SA SP-170240, Northbound APIs for
SCEF – SCS/AS Interworking.
[5] 3GPP TS 23.222, Functional architecture and
information flows to support Common API
Framework for 3GPP Northbound APIs;
Stage 2 (Release 15).
[6] 3GPP TS 24.250, Protocol for Reliable Data Service
between UE and SCEF; Stage 3 (Release 15).
[7] 3GPP SA SP-170801, New SID on Cellular IoT
support and evolution for the 5G System.
[8] oneM2M TS-0001, Functional Architecture.
[9] oneM2M TS-00026, 3GPP Interworking.

June 2018 | Volume 22, Issue 2 GetMobile 21