rfc9391xml2.original.xml   rfc9391.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.11 (Ruby 2.
6.8) -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?rfc strict="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<?rfc compact="yes"?> -ietf-lpwan-schc-over-nbiot-15draft-ietf-lpwan-schc-over-nbiot-15" number="9391"
submissionType="IETF" category="std" consensus="true" tocInclude="true" sortRef
s="true" symRefs="true" updates="" obsoletes="" xml:lang="en" version="3">
<rfc ipr="trust200902" docName="draft-ietf-lpwan-schc-over-nbiot-15" category="s td" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" sym Refs="true">
<front> <front>
<title abbrev="LPWAN SCHC NB-IoT">Static Context Header Compression over Nar rowband Internet of Things</title> <title abbrev="LPWAN SCHC NB-IoT">Static Context Header Compression over Nar rowband Internet of Things</title>
<seriesInfo name="RFC" value="9391"/>
<author initials="E." surname="Ramos" fullname="Edgar Ramos"> <author initials="E." surname="Ramos" fullname="Edgar Ramos">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<postal> <postal>
<street>Hirsalantie 11</street> <street>Hirsalantie 11</street>
<city>02420 Jorvas, Kirkkonummi</city> <city>Jorvas, Kirkkonummi</city>
<code>02420</code>
<country>Finland</country> <country>Finland</country>
</postal> </postal>
<email>edgar.ramos@ericsson.com</email> <email>edgar.ramos@ericsson.com</email>
</address> </address>
</author> </author>
<author initials="A." surname="Minaburo" fullname="Ana Minaburo"> <author initials="A." surname="Minaburo" fullname="Ana Minaburo">
<organization>Acklio</organization> <organization>Acklio</organization>
<address> <address>
<postal> <postal>
<street>1137A Avenue des Champs Blancs</street> <street>1137A Avenue des Champs Blancs</street>
<city>35510 Cesson-Sevigne Cedex</city> <city>Cesson-Sevigne Cedex</city>
<code>35510</code>
<country>France</country> <country>France</country>
</postal> </postal>
<email>ana@ackl.io</email> <email>ana@ackl.io</email>
</address> </address>
</author> </author>
<date year="2023" month="April"/>
<date year="2022" month="December" day="15"/> <area>int</area>
<workgroup>lpwan</workgroup>
<area>Internet</area>
<workgroup>lpwan Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract> <abstract>
<t>This document describes Static Context Header Compression and
<t>This document describes Static Context Header Compression and Fragmentation ( fragmentation (SCHC) specifications, RFCs 8724 and 8824,
SCHC) specifications, RFC 8724 and RFC 8824, combination with the 3rd Generation in combination with the 3rd Generation Partnership Project (3GPP) and the
Partnership Project (3GPP) and the Narrowband Internet of Things (NB-IoT).</t> Narrowband Internet of Things (NB-IoT).</t>
<t>This document has two parts: one normative part that specifies the
<t>This document has two parts. One normative to specify the use of SCHC over NB use of SCHC over NB-IoT and one informational part that recommends some
-IoT. And one informational, which recommends some values if 3GPP wanted to use values if 3GPP wants to use SCHC inside their architectures.</t>
SCHC inside their architectures.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="Introduction">
<name>Introduction</name>
<t>This document defines scenarios where Static Context Header Compression
and fragmentation (SCHC) <xref target="RFC8724"/> <xref target="RFC8824"/> are
suitable for 3rd Generation Partnership Project (3GPP) and Narrowband Internet o
f Things (NB-IoT) protocol stacks.</t>
<t>In the 3GPP and the NB-IoT networks, header compression efficiently bri
ngs Internet connectivity to the Device UE (Dev-UE), the radio (RGW-eNB) and net
work (NGW-MME) gateways, and the Application Server. This document describes the
SCHC parameters supporting SCHC over the NB-IoT architecture.</t>
<t>This document assumes functionality for NB-IoT of 3GPP release 15 <xre
f target="R15-3GPP"/>. Otherwise, the text explicitly mentions other versions' f
unctionality.</t>
<section anchor="Introduction"><name>Introduction</name> <t>This document has two parts: normative end-to-end scenarios describing
how any application must use SCHC over the 3GPP public service and informational
<t>This document defines the scenarios where the Static Context Header Compressi scenarios about how 3GPP could use SCHC in their protocol stack network.</t>
on and fragmentation (SCHC) <xref target="RFC8724"/> and <xref target="RFC8824"/ </section>
> are suitable for 3rd Generation Partnership Project (3GPP) and Narrowband Inte <section anchor="conventions-and-definitions">
rnet of Things (NB-IoT) protocol stacks.</t> <name>Conventions and Definitions</name>
<t>
<t>In the 3GPP and the NB-IoT networks, header compression efficiently brings In The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
ternet connectivity to the Device-User Equipment (Dev-UE), the radio (RGW-eNB) a IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
nd network (NGW-MME) gateways, and the Application Server. This document describ NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
es the SCHC parameters supporting static context header compression and fragment RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
ation over the NB-IoT architecture.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
<t>This document assumes functionality for NB-IoT of 3GPP release 15 <xref targ described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
et="_3GPPR15"/>. Otherwise, the text explicitly mentions other versions' functio when, and only when, they appear in all capitals, as shown here.
nality.</t> </t>
</section>
<t>This document has two parts, a standard end-to-end scenario describing how an <section anchor="terminology">
y application must use SCHC over the 3GPP public service. And informational scen <name>Terminology</name>
arios about how 3GPP could use SCHC in their protocol stack network.</t> <t>This document will follow the terms defined in <xref
target="RFC8724"/>, <xref target="RFC8376"/>, and <xref
</section> target="TR23720"/>.</t>
<section anchor="conventions-and-definitions"><name>Conventions and Definitions<
/name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUI
RED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i
nterpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and
only when, they
appear in all capitals, as shown here.</t>
</section>
<section anchor="terminology"><name>Terminology</name>
<t>This document will follow the terms defined in <xref target="RFC8724"/>, in <
xref target="RFC8376"/>, and the <xref target="TR23720"/>.</t>
<t><list style="symbols">
<t>Capillary Gateway. A capillary gateway facilitates seamless integration bec
ause it has wide area connectivity through cellular and provides wide area acces
s as a proxy to other devices using LAN technologies (BT, Wi-Fi, Zigbee, or othe
rs.)</t>
<t>CIoT EPS. Cellular IoT Evolved Packet System. It is a functionality to impr
ove the support of small data transfers.</t>
<t>Dev-UE. Device - User Equipment.</t>
<t>DoNAS. Data over Non-Access Stratum.</t>
<t>EPC. Evolved Packet Connectivity. Core network of 3GPP LTE systems.</t>
<t>EUTRAN. Evolved Universal Terrestrial Radio Access Network. Radio access ne
twork of LTE-based systems.</t>
<t>HARQ. Hybrid Automatic Repeat Request.</t>
<t>HSS. Home Subscriber Server. It is a database that contains users' subscrip
tion data, including data needed for mobility management.</t>
<t>IP address. IPv6 or IPv4 address used.</t>
<t>IWK-SCEF. InterWorking Service Capabilities Exposure Function. It is used i
n roaming scenarios, it is located in the Visited PLMN and serves for interconne
ction with the SCEF of the Home PLMN.</t>
<t>L2. Layer-2 in the 3GPP architectures it includes MAC, RLC and PDCP layers
see <xref target="AppendixA"/>.</t>
<t>LCID. Logical Channel ID. Is the logical channel instance of the correspond
ing MAC SDU.</t>
<t>MAC. Medium Access Control protocol, part of L2.</t>
<t>NAS. Non-Access Stratum.</t>
<t>NB-IoT. Narrowband IoT. A 3GPP LPWAN technology based on the LTE architectu
re but with additional optimization for IoT and using a Narrowband spectrum freq
uency.</t>
<t>NGW-CSGN. Network Gateway - CIoT Serving Gateway Node.</t>
<t>NGW-CSGW. Network Gateway - Cellular Serving Gateway. It routes and forward
s the user data packets through the access network.</t>
<t>NGW-MME. Network Gateway - Mobility Management Entity. An entity in charge
of handling mobility of the Dev-UE.</t>
<t>NGW-PGW. Network Gateway - Packet Data Network Gateway. An interface betwee
n the internal with the external network.</t>
<t>NGW-SCEF. Network Gateway - Service Capability Exposure Function. EPC node
for exposure of 3GPP network service capabilities to 3rd party applications.</t>
<t>NIDD. Non-IP Data Delivery.</t>
<t>PDCP. Packet Data Convergence Protocol part of L2.</t>
<t>PLMN. Public Land Mobile Network. Combination of wireless communication ser
vices offered by a specific operator.</t>
<t>PDU. Protocol Data Unit. A data packet including headers that are transmitt
ed between entities through a protocol.</t>
<t>RLC. Radio Link Protocol part of L2.</t>
<t>RGW-eNB. Radio Gateway - evolved Node B. Base Station that controls the UE.
</t>
<t>SDU. Service Data Unit. A data packet (PDU) from higher layer protocols use
d by lower layer protocols as a payload of their own PDUs.</t>
</list></t>
</section>
<section anchor="nb-iot-architecture"><name>NB-IoT Architecture</name>
<t>The Narrowband Internet of Things (NB-IoT) architecture has a complex structu
re.
It relies on different NGWs from different providers. It can send data via diffe
rent paths, each with different characteristics in terms of bandwidth, acknowled
gments, and layer-2 reliability and segmentation.</t>
<t><xref target="Figure-Archi"/> shows this architecture, where the Network Gate
way Cellular Internet of Things Serving Gateway Node (NGW-CSGN) optimizes co-loc
ating entities in different paths. For example, a Dev-UE using the path formed b
y the Network Gateway Mobility Management Entity (NGW-MME), the NGW-CSGW, and Ne
twork Gateway Packet Data Network Gateway (NGW-PGW) may get a limited bandwidth
transmission from a few bytes/s to one thousand bytes/s only.</t>
<t>Another node introduced in the NB-IoT architecture is the Network Gateway Ser
vice Capability Exposure Function (NGW-SCEF),
which securely exposes service and network capabilities to entities external to
the network operator. The Open Mobile Alliance (OMA) <xref target="OMA0116"/> an
d the One Machine to Machine (OneM2M) <xref target="TR-0024"/> define the northb
ound APIs. <xref target="TS23222"/> defines architecture for the common API fram
ework for 3GPP northbound APIs and <xref target="TS33122"/> defines security asp
ects for common API framework for 3GPP northbound APIs. In this case, the path i
s small for data transmission. The main functions of the NGW-SCEF are Connectivi
ty path and Device Monitoring.</t>
<figure title="3GPP network architecture" anchor="Figure-Archi"><artwork><![CDAT
A[
+---+ +---------+ +------+
|Dev| \ | +-----+ | ---| HSS |
|-UE| \ | | NGW | | +------+
+---+ | | |-MME |\__
\ / +-----+ | \
+---+ \+-----+ /| | | +------+
|Dev| ----| RGW |- | | | | NGW- |
|-UE| |-eNB | | | | | SCEF |---------+
+---+ /+-----+ \| | | +------+ |
/ \ +------+| |
/ |\| NGW- || +-----+ +-----------+
+---+ / | | CSGW |--| NGW-|---|Application|
|Dev| | | || | PGW | | Server |
|-UE| | +------+| +-----+ +-----------+
+---+ | |
|NGW-CSGN |
+---------+
]]></artwork></figure>
</section>
<section anchor="data-transmission-in-the-3gpp-architecture"><name>Data Transmis
sion in the 3GPP Architecture</name>
<t>NB-IoT networks deal with end-to-end user data and in-band signaling between
the nodes and functions to configure, control, and monitor the system functions
and behaviors. The signaling uses a different path with specific protocols, hand
ling processes, and entities but can transport end-to-end user data for IoT serv
ices. In contrast, the end-to-end application only transports end-to-end data.</
t>
<t>The recommended 3GPP MTU size is 1358 bytes. The radio network protocols limi
t the packet sizes over the air, including radio protocol overhead, to 1600 byte
s, see <xref target="Radio-Parameters"/>. However, the recommended 3GPP MTU is s
maller to avoid fragmentation in the network backbone due to the payload encrypt
ion size (multiple of 16) and the additional core transport overhead handling.</
t>
<t>3GPP standardizes NB-IoT and, in general, the cellular technologies interface
s and functions. Therefore, the introduction of SCHC entities to Dev-UE, RGW-eNB
, and NGW-CSGN needs to be specified in the NB-IoT standard.</t>
<t>This document identifies the use cases of SCHC over the NB-IoT architecture.<
/t>
<t>First, the radio transmission where, see <xref target="Radio"/>, the Dev-UE a
nd the RGW-eNB can use the SCHC functionalities.</t>
<t>Second, the packets transmitted over the control path can also use SCHC when
the transmission goes over the NGW-MME or NGW-SCEF. See <xref target="DONAS"/>.<
/t>
<t>These two use cases are also valid for any 3GPP architecture and not only for
NB-IoT. And as the 3GPP internal network is involved, they have been put in the
informational part of this section.</t>
<t>And third, over the SCHC over Non-IP Data Delivery (NIDD) connection or at le
ast up to the operator network edge, see <xref target="E2E"/>. In this case, SCH
C functionalities are available in the application layer of the Dev-UE and the A
pplication Servers or a broker function at the edge of the operator network. NGW
-PGW or NGW-SCEF transmit the packets which are non-IP traffic, using IP tunneli
ng or API calls. It is also possible to benefit legacy devices with SCHC by usin
g the non-IP transmission features of the operator network.</t>
<t>A non-IP transmission refers to other layer-2 transport different from NB-IoT
.</t>
<section anchor="normative-part"><name>Normative Part.</name>
<t>This scenarios does not modify the 3GPP architecture or any of its components
, it only use it as a layer-2 transmission.</t>
<section anchor="E2E"><name>SCHC over Non-IP Data Delivery (NIDD)</name> <dl newline="false" spacing="normal">
<t>This section specifies the use of SCHC over Non-IP Data Delivery (NIDD) servi <dt>Capillary Gateway:</dt>
ces of 3GPP. The NIDD services of 3GPP enable the transmission of SCHC packets c <dd>Facilitates seamless integration because it
ompressed by the application layer. The packets can be delivered between the NGW has wide-area connectivity through cellular and provides wide-area
-PGW and the Application Server or between the NGW-SCEF and the Application Serv access as a proxy to other devices using LAN technologies (BT, Wi-Fi,
er, using IP-tunnels or API calls. In both cases, as compression occurs before t Zigbee, or others).</dd>
ransmission, the network will not understand the packet, and the network does no <dt>Cellular IoT Evolved Packet System (CIoT EPS):</dt>
t have context information of this compression. Therefore, the network will trea <dd>A functionality to improve the support of small data
t the packet as Non-IP traffic and deliver it to the other side without any othe transfers.</dd>
r protocol stack element, directly over the layer-2.</t> <dt>Device UE (Dev-UE):</dt>
<dd>As defined in <xref target="RFC8376" sectionFormat="comma" section="3
"/>.</dd>
<dt>Data over Non-Access Stratum (DoNAS):</dt>
<dd>Sending user data within signaling messages over the NAS functional l
ayer.</dd>
<dt>Evolved Packet Connectivity (EPC):</dt>
<dd>Core network of 3GPP LTE systems.</dd>
<dt>Evolved Universal Terrestrial Radio Access Network (EUTRAN):</dt>
<dd>Radio access network of LTE-based systems.</dd>
<dt>Hybrid Automatic Repeat reQuest (HARQ):</dt>
<dd>A combination of high-rate Forward Error Correction (FEC) and Automat
ic Repeat reQuest (ARQ) error control.</dd>
<dt>Home Subscriber Server (HSS):</dt>
<dd>A database that contains users' subscription data, including
data needed for mobility management.</dd>
<dt>IP address:</dt>
<dd>IPv6 or IPv4 address used.</dd>
<dt>InterWorking Service Capabilities Exposure Function
(IWK-SCEF):</dt>
<dd>Used in roaming scenarios, is located in the Visited PLMN, and
serves for interconnection with the Service Capabilities Exposure
Function (SCEF) of the Home PLMN.</dd>
<dt>Layer 2 (L2):</dt>
<dd>L2 in the 3GPP architectures includes MAC, RLC, and PDCP layers; see
<xref
target="AppendixA"/>.</dd>
<dt>Logical Channel ID (LCID):</dt>
<dd>The logical channel instance of the corresponding MAC SDU.</dd>
<dt>Medium Access Control (MAC) protocol:</dt>
<dd>Part of L2.</dd>
<dt>Non-Access Stratum (NAS):</dt>
<dd>Functional layer for signaling messages that establishes communicatio
n sessions and maintains the communication while the user moves.</dd>
<dt>Narrowband IoT (NB-IoT):</dt>
<dd>A 3GPP Low-Power WAN (LPWAN) technology based on the LTE
architecture but with additional optimization for IoT and using a
Narrowband spectrum frequency.</dd>
<dt>Network Gateway - CIoT Serving Gateway Node (NGW-CSGN):</dt>
<dd>As defined in <xref target="RFC8376" sectionFormat="comma" section="3
"/>.</dd>
<dt>Network Gateway - Cellular Serving Gateway (NGW-CSGW):</dt>
<dd>Routes and forwards the user data packets through the access
network.</dd>
<dt>Network Gateway - Mobility Management Entity (NGW-MME):</dt>
<dd>An entity in charge of handling mobility of the Dev-UE.</dd>
<dt>Network Gateway - Packet Data Network Gateway (NGW-PGW):</dt>
<dd>An interface between the internal and external network.</dd>
<dt>Network Gateway - Service Capability Exposure Function
(NGW-SCEF):</dt>
<dd>EPC node for exposure of 3GPP network service capabilities to third
party applications.</dd>
<dt>Non-IP Data Delivery (NIDD):</dt>
<dd>End-to-end communication between the UE and the Application Server.</
dd>
<dt>Packet Data Convergence Protocol (PDCP):</dt>
<dd>Part of L2.</dd>
<dt>Public Land-based Mobile Network (PLMN):</dt>
<dd>A combination of wireless communication services offered by a
specific operator.</dd>
<dt>Protocol Data Unit (PDU):</dt>
<dd>A data packet including headers that are transmitted between
entities through a protocol.</dd>
<dt>Radio Link Protocol (RLC):</dt>
<dd>Part of L2.</dd>
<dt>Radio Gateway - evolved Node B (RGW-eNB):</dt>
<dd>Base Station that controls the UE.</dd>
<dt>Service Data Unit (SDU):</dt>
<dd>A data packet (PDU) from higher-layer protocols used by lower-layer
protocols as a payload of their own PDUs.</dd>
</dl>
</section>
<section anchor="nb-iot-architecture">
<name>NB-IoT Architecture</name>
<t>The NB-IoT architecture has a complex structure.
It relies on different Network Gateways (NGWs) from different providers. I
t can send data via different paths, each with different characteristics in term
s of bandwidth, acknowledgments, and L2 reliability and segmentation.</t>
<section anchor="schc-entities-placing-over-nidd"><name>SCHC Entities Placing ov <t><xref target="Figure-Archi"/> shows this architecture, where the Networ
er NIDD</name> k Gateway - Cellular IoT Serving Gateway Node (NGW-CSGN) optimizes co-locating e
<t>In the two scenarios using NIDD compression, SCHC entities are located almost ntities in different paths. For example, a Dev-UE using the path formed by the N
on top of the stack. The NB-IoT connectivity services implement SCHC in the Dev etwork Gateway - Mobility Management Entity (NGW-MME), the NGW-CSGW, and the Net
-UE, an in the Application Server. The IP tunneling scenario requires that the A work Gateway - Packet Data Network Gateway (NGW-PGW) may get a limited bandwidth
pplication Server send the compressed packet over an IP connection terminated by transmission from a few bytes/s to one thousand bytes/s only.</t>
the 3GPP core network. If the transmission uses the NGW-SCEF services, it is po <t>Another node introduced in the NB-IoT architecture is the Network Gatew
ssible to utilize an API call to transfer the SCHC packets between the core netw ay - Service Capability Exposure Function (NGW-SCEF),
ork and the Application Server. Also, an IP tunnel could be established by the A which securely exposes service and network capabilities to entities external to
pplication Server if negotiated with the NGW-SCEF.</t> the network operator. The Open Mobile Alliance (OMA) <xref target="OMA0116"/> an
d the One Machine to Machine (OneM2M) <xref target="TR-0024"/> define the northb
ound APIs. <xref target="TS23222"/> defines architecture for the common API fram
ework for 3GPP northbound APIs. <xref target="TS33122"/> defines security aspect
s for a common API framework for 3GPP northbound APIs. In this case, the path is
small for data transmission.
The main functions of the NGW-SCEF are path connectivity and device monitoring.<
/t>
<figure anchor="Figure-Archi">
<name>3GPP Network Architecture</name>
<artwork><![CDATA[
+---+ +---------+ +------+
|Dev| \ | +-----+ | ---| HSS |
|-UE| \ | | NGW | | +------+
+---+ | | |-MME |\__
\ / +-----+ | \
+---+ \+-----+ /| | | +------+
|Dev| ----| RGW |- | | | | NGW- |
|-UE| |-eNB | | | | | SCEF |---------+
+---+ /+-----+ \| | | +------+ |
/ \ +------+| |
/ |\| NGW- || +-----+ +-----------+
+---+ / | | CSGW |--| NGW-|---|Application|
|Dev| | | || | PGW | | Server |
|-UE| | +------+| +-----+ +-----------+
+---+ | |
|NGW-CSGN |
+---------+
]]></artwork>
</figure>
</section>
<section anchor="data-transmission-in-the-3gpp-architecture">
<name>Data Transmission in the 3GPP Architecture</name>
<t>NB-IoT networks deal with end-to-end user data and in-band signaling be
tween the nodes and functions to configure, control, and monitor the system func
tions and behaviors. The signaling uses a different path with specific protocols
, handling processes, and entities but can transport end-to-end user data for Io
T services. In contrast, the end-to-end application only transports end-to-end d
ata.</t>
<t>The recommended 3GPP MTU size is 1358 bytes. The radio network protocol
s limit the packet sizes over the air, including radio protocol overhead, to 160
0 bytes; see <xref target="Radio-Parameters"/>. However, the recommended 3GPP MT
U is smaller to avoid fragmentation in the network backbone due to the payload e
ncryption size (multiple of 16) and the additional core transport overhead handl
ing.</t>
<t>3GPP standardizes NB-IoT and, in general, the interfaces and functions
of cellular technologies. Therefore, the introduction of SCHC entities to Dev-UE
, RGW-eNB, and NGW-CSGN needs to be specified in the NB-IoT standard.</t>
<figure title="End-to End Compression. SCHC entities placed when using Non-IP De <t>This document identifies the use cases of SCHC over the NB-IoT architec
livery (NIDD) 3GPP Services" anchor="Fig--NIDD"><artwork><![CDATA[ ture.</t>
<t>The first use case is of the radio transmission (see <xref target="Radi
o"/>) where the Dev-UE and the RGW-eNB can use the SCHC functionalities.</t>
<t>The second is where the packets transmitted over the control path can a
lso use SCHC when the transmission goes over the NGW-MME or NGW-SCEF (see <xref
target="DONAS"/>).</t>
<t>These two use cases are also valid for any 3GPP architecture and not on
ly for NB-IoT. And as the 3GPP internal network is involved, they have been put
in the informational part of this section.</t>
<t>And the third covers the SCHC over Non-IP Data Delivery (NIDD) connecti
on or at least up to the operator network edge (see <xref target="E2E"/>). In th
is case, SCHC functionalities are available in the application layer of the Dev-
UE and the Application Servers or a broker function at the edge of the operator
network. NGW-PGW or NGW-SCEF transmit the packets that are Non-IP traffic, using
IP tunneling or API calls. It is also possible to benefit legacy devices with S
CHC by using the Non-IP transmission features of the operator network.</t>
<t>A Non-IP transmission refers to an L2 transport that is different from
NB-IoT.</t>
<section anchor="normative-part">
<name>Normative Scenarios</name>
<t>These scenarios do not modify the 3GPP architecture or any of its
components. They only use the architecture as an L2
transmission.</t>
<section anchor="E2E">
<name>SCHC over Non-IP Data Delivery (NIDD)</name>
<t>This section specifies the use of SCHC over NIDD services of 3GPP.
The NIDD services of 3GPP enable the transmission of SCHC packets compressed by
the application layer. The packets can be delivered between the NGW-PGW and the
Application Server or between the NGW-SCEF and the Application Server, using IP-
tunnels or API calls. In both cases, as compression occurs before transmission,
the network will not understand the packet, and the network does not have contex
t information of this compression. Therefore, the network will treat the packet
as Non-IP traffic and deliver it to the other side without any other protocol st
ack element, directly over L2.</t>
<section anchor="schc-entities-placing-over-nidd">
<name>SCHC Entities Placing over NIDD</name>
<t>In the two scenarios using NIDD compression, SCHC entities are lo
cated almost on top of the stack. The NB-IoT connectivity services implement SCH
C in the Dev-UE, an in the Application Server. The IP tunneling scenario require
s that the Application Server send the compressed packet over an IP connection t
erminated by the 3GPP core network. If the transmission uses the NGW-SCEF servic
es, it is possible to utilize an API call to transfer the SCHC packets between t
he core network and the Application Server. Also, an IP tunnel could be establis
hed by the Application Server if negotiated with the NGW-SCEF.</t>
<figure anchor="Fig--NIDD">
<name>End-to-End Compression: SCHC Entities Placed when Using Non-
IP Delivery (NIDD) 3GPP Services</name>
<artwork><![CDATA[
+---------+ XXXXXXXXXXXXXXXXXXXXXXXX +--------+ +---------+ XXXXXXXXXXXXXXXXXXXXXXXX +--------+
| SCHC | XXX XXX | SCHC | | SCHC | XXX XXX | SCHC |
|(Non-IP) +-----XX........................XX....+--*---+(Non-IP)| |(Non-IP) +-----XX........................XX....+--*---+(Non-IP)|
+---------+ XX +----+ XX | | +--------+ +---------+ XX +----+ XX | | +--------+
| | XX |SCEF+-------+ | | | | | XX |SCEF+-------+ | | |
| | XXX 3GPP RAN & +----+ XXX +---+ UDP | | | XXX 3GPP RAN & +----+ XXX +---+ UDP |
| | XXX CORE NETWORK XXX | | | | | XXX CORE NETWORK XXX | | |
| L2 +---+XX +------------+ | +--------+ | L2 +---+XX +------------+ | +--------+
| | XX |IP TUNNELING+--+ | | | | XX |IP TUNNELING+--+ | |
| | XXX +------------+ +---+ IP | | | XXX +------------+ +---+ IP |
+---------+ XXXX XXXX | +--------+ +---------+ XXXX XXXX | +--------+
| PHY +------+ XXXXXXXXXXXXXXXXXXXXXXX +---+ PHY | | PHY +------+ XXXXXXXXXXXXXXXXXXXXXXX +---+ PHY |
+---------+ +--------+ +---------+ +--------+
Dev-UE Application Dev-UE Application
Server Server
]]></artwork>
</figure>
</section>
<section anchor="Config">
<name>Parameters for Static Context Header Compression and Fragmenta
tion (SCHC)</name>
<t>These scenarios <bcp14>MAY</bcp14> use the SCHC header compressio
n
capability to improve the transmission of IPv6 packets.</t>
<ul spacing="normal">
<li><t>SCHC Context Initialization</t>
<t>The application layer handles the static context.
Consequently, the context distribution <bcp14>MUST</bcp14> be
according to the application's capabilities, perhaps utilizing
IP data transmissions up to context initialization. Also, the
static context delivery may use the same IP tunneling or
NGW-SCEF services used later for the transport of SCHC packets.</t>
</li>
<li><t>SCHC Rules</t>
<t>For devices acting as a capillary gateway, several rules
match the diversity of devices and protocols used by the devices
associated with the gateway. Meanwhile, simpler devices may have
predetermined protocols and fixed parameters.</t></li>
<li><t>RuleID</t>
]]></artwork></figure> <t>This scenario can dynamically set the RuleID size before the
context delivery, for example, by negotiating between the
</section> applications when choosing a profile according to the type of
<section anchor="Config"><name>Parameters for Static Context Header Compression traffic and application deployed. Transmission optimization may
and Fragmentation (SCHC)</name> require only one Physical Layer transmission. SCHC overhead
<bcp14>SHOULD NOT</bcp14> exceed the available number of
<t>These scenarios <bcp14>MAY</bcp14> use SCHC header compression capability to effective bits of the smallest physical TB available to optimize
improve the transmission of IPv6 packets.</t> the transmission. The packets handled by 3GPP networks are
byte-aligned. Thus, to use the smallest TB, the maximum SCHC
<t><list style="symbols"> header size is 12 bits. On the other hand, more complex NB-IoT
<t>SCHC Context initialization.</t> devices (such as a capillary gateway) might require additional
</list></t> bits to handle the variety and multiple parameters of
higher-layer protocols deployed. The configuration may be part
<t>The application layer handles the static context; consequently, the context d of the agreed operation profile and content distribution.
istribution <bcp14>MUST</bcp14> be according to the application's capabilities, The RuleID field size may range from 2 bits, resulting in 4
perhaps utilizing IP data transmissions up to context initialization. Also, rules, to an 8-bit value, yielding up to 256 rules for use by
the static contexts delivery may use the same IP tunneling or NGW-SCEF services operators. A 256-rule maximum limit seems to be quite
used later for the SCHC packets transport.</t> reasonable, even for a device acting as a NAT. An application
may use a larger RuleID, but it should consider the byte
<t><list style="symbols"> alignment of the expected Compression Residue. In the minimum TB
<t>SCHC Rules.</t> size case, 2 bits of RuleID leave only 6 bits available for
</list></t> Compression Residue.</t></li>
<li><t>SCHC MAX_PACKET_SIZE</t>
<t>For devices acting as a capillary gateway, several rules match the diversity <t>In these scenarios, the maximum <bcp14>RECOMMENDED</bcp14>
of devices and protocols used by the devices associated with the gateway. Meanwh MTU size is 1358 bytes since the SCHC packets (and fragments)
ile, simpler devices may have predetermined protocols and fixed parameters.</t> are traversing the whole 3GPP network infrastructure (core and
radio), not only the radio as in the IP transmissions
<t><list style="symbols"> case.</t></li>
<t>Rule ID.</t> <li><t>Fragmentation</t>
</list></t> <t>Packets larger than 1358 bytes need the SCHC fragmentation
function. Since the 3GPP uses reliability functions, the No-ACK
<t>This scenario can dynamically set the RuleID size before the context delivery fragmentation mode <bcp14>MAY</bcp14> be enough in
. For example, negotiate between the applications when choosing a profile accord point-to-point connections. Nevertheless, additional
ing to the type of traffic and application deployed. considerations are described below for more complex
Transmission optimization may require only one physical layer transmission. SCHC cases.</t></li>
overhead <bcp14>SHOULD NOT</bcp14> exceed the available number of effective bit <li><t>Fragmentation Modes</t>
s of the smallest physical TB available to optimize the transmission. The packet <t>A global service assigns a QoS to the packets, e.g., depending
s handled by 3GPP networks are byte-aligned. Thus, to use the smallest TB, the m on the billing. Packets with very low QoS may get lost before
aximum SCHC header size is 12 bits. On the other hand, more complex NB-IoT devic arriving in the 3GPP radio network transmission, e.g., in
es (such as a capillary gateway) might require additional bits to handle the var between the links of a capillary gateway or due to buffer
iety and multiple parameters of higher-layer protocols deployed. overflow handling in a backhaul connection. The use of SCHC
The configuration may be part of the agreed operation profile and content distri fragmentation with the ACK-on-Error mode is
bution. The RuleID field size may range from 2 bits, resulting in 4 rules to an <bcp14>RECOMMENDED</bcp14> to secure additional reliability on
8-bit value that would yield up to 256 rules that can be used with the operators the packets transmitted with a small trade-off on further
and seems quite a reasonable maximum limit even for a device acting as a NAT. transmissions to signal the end-to-end arrival of the packets if
An application may use a larger RuleID, but it should consider the byte alignmen no transport protocol takes care of retransmission.<br/> Also,
t of the expected Compression Residue. In the minimum TB size case, 2 bits of Ru the ACK-on-Error mode could be desirable to keep track of all
leID leave only 6 bits available for Compression Residue.</t> the SCHC packets delivered. In that case, the fragmentation
function could be activated for all packets transmitted by the
<t><list style="symbols"> applications. SCHC ACK-on-Error fragmentation
<t>SCHC MAX_PACKET_SIZE.</t> <bcp14>MAY</bcp14> be activated in transmitting Non-IP packets
</list></t> on the NGW-MME. A Non-IP packet will use SCHC reserved RuleID
for non-compressing packets as <xref target="RFC8724"/> allows it.<
<t>In these scenarios, the maximum <bcp14>RECOMMENDED</bcp14> MTU size is 1358 b /t></li>
ytes since the SCHC packets (and fragments) are traversing the whole 3GPP networ <li><t>Fragmentation Parameters</t>
k infrastructure (core and radio), not only the radio as the IP transmissions ca <t>SCHC profile will have specific Rules for the fragmentation
se.</t> modes. The rule will identify which fragmentation mode is in
use, and <xref target="Radio-Parameters"/> defines the RuleID
<t><list style="symbols"> size.</t></li></ul>
<t>Fragmentation.</t> <t>SCHC parametrization considers that NB-IoT aligns the bit and
</list></t> uses padding and the size of the Transfer Block. SCHC will try to
reduce padding to optimize the compression of the information. The
<t>Packets larger than 1358 bytes need the SCHC fragmentation function. Since th header size needs to be a multiple of 4. The Tiles
e 3GPP uses reliability functions, the No-ACK fragmentation mode <bcp14>MAY</bcp <bcp14>MAY</bcp14> keep a fixed value of 4 or 8 bits to avoid
14> be enough in point-to-point connections. Nevertheless, additional considerat padding, except for when the transfer block equals 16 bits as
ions are described below for more complex cases.</t> the Tiles may be 2 bits. The transfer block size has a wide range
of values. Two configurations are <bcp14>RECOMMENDED</bcp14> for
<t><list style="symbols"> the fragmentation parameters.</t>
<t>Fragmentation modes.</t> <ul spacing="normal">
</list></t> <li>
<t>For Transfer Blocks smaller than or equal to 304 bits using a
<t>A global service assigns a QoS to the packets e.g. depending on the billing. n
Packets with very low QoS may get lost before arriving in the 3GPP radio network 8-bit Header_size configuration, with the size of the header
transmission, for example, in between the links of a capillary gateway or due t fields as follows:
o buffer overflow handling in a backhaul connection. </t>
The use of SCHC fragmentation with the ACK-on-Error mode is <bcp14>RECOMMENDED</ <ul spacing="normal">
bcp14> to secure additional reliability on the packets transmitted with a small <li>RuleID from 1 - 3 bits</li>
trade-off on further transmissions to signal the end-to-end arrival of the packe <li>DTag 1 bit</li>
ts if no transport protocol takes care of retransmission.<br /> <li>FCN 3 bits</li>
Also, the ACK-on-Error mode could be desirable to keep track of all the SCHC pac <li>W 1 bits</li>
kets delivered. In that case, the fragmentation function could be activated for </ul>
all packets transmitted by the applications. </li>
SCHC ACK-on-Error fragmentation <bcp14>MAY</bcp14> be activated in transmitting <li>
non-IP packets on the NGW-MME. A non-IP packet will use SCHC reserved RuleID for <t>For Transfer Blocks bigger than 304 bits using a 16-bit Heade
non-compressing packets as <xref target="RFC8724"/> allows it.</t> r_size configuration, with the size of the header fields as follows:
</t>
<t><list style="symbols"> <ul spacing="normal">
<t>Fragmentation Parameters.</t> <li>RulesID from 8 - 10 bits</li>
</list></t> <li>DTag 1 or 2 bits</li>
<li>FCN 3 bits</li>
<t>SCHC profile will have specific Rules for the fragmentation modes. The rule w <li>W 2 or 3 bits</li>
ill identify, which fragmentation mode is in use, </ul>
and section <xref target="Radio-Parameters"/> defines the RuleID size.</t> </li>
<li>WINDOW_SIZE of (2<sup>N</sup>)-1 is <bcp14>RECOMMENDED</bcp14>
<t>SCHC parametrization considers that NBIoT aligns the bit and uses padding and .</li>
the size of the Transfer Block. SCHC will try to reduce padding to optimize the <li>Reassembly Check Sequence (RCS) will follow the default size d
compression of the information. The Header size needs to be multiple of 4, and efined in <xref target="RFC8724" sectionFormat="of" section="8.2.3"/>, with a le
the Tiles <bcp14>MAY</bcp14> keep a fixed value of 4 or 8 bits to avoid padding ngth equal to the L2 Word.</li>
except for transfer block equals 16 bits where Tiles may be 2 bits. The transfer <li>MAX_ACK_REQ is <bcp14>RECOMMENDED</bcp14> to be 2, but applica
block size has a wide range of values. Two configurations are <bcp14>RECOMMENDE tions <bcp14>MAY</bcp14> change this value based on transmission conditions.</li
D</bcp14> for the fragmentation parameters.</t> >
</ul>
<t><list style="symbols"> <t>The IoT devices communicate with small data transfers and use the
<t>For Transfer Blocks smaller or equal to 304 bits using an 8-bit Header_size Power Save Mode and the Idle Mode Discontinuous Reception (DRX), which govern h
configuration, with the size of the header fields as follows: ow often the device wakes up, stays up, and is reachable. The use of the differe
<list style="symbols"> nt modes allows the battery to last ten years. Table 10.5.163a in <xref target="
<t>RuleID from 1 - 3 bits,</t> TS24008"/> defines the radio timer values with units incrementing by N. The unit
<t>DTag 1 bit,</t> s of N can be 1 hour or 10 hours. The range used for IoT is of N to 3N, where N
<t>FCN 3 bits,</t> increments by one.
<t>W 1 bits.</t>
</list></t>
<t>For Transfer Blocks bigger than 304 bits using a 16-bit Header_size configu
ration, with the size of the header fields as follows:
<list style="symbols">
<t>RulesID from 8 - 10 bits,</t>
<t>DTag 1 or 2 bits,</t>
<t>FCN 3 bits,</t>
<t>W 2 or 3 bits.</t>
</list></t>
<t>WINDOW_SIZE of 2^N-1 is <bcp14>RECOMMENDED</bcp14>.</t>
<t>RCS will follow the default size defined in section 8.2.3 of the <xref targ
et="RFC8724"/>, with a length equal to the L2 Word.</t>
<t>MAX_ACK_REQ is <bcp14>RECOMMENDED</bcp14> to be 2, but applications <bcp14>
MAY</bcp14> change this value based on transmission conditions.</t>
</list></t>
<t>The IoT devices communicate with small data transfer and use the Power Save M
ode and the Idle Mode DRX, which govern how often the device wakes up, stays up,
and is reachable. The use of the different modes allows the battery to last ten
years. Table 10.5.163a in <xref target="TS24008"/> specifies a range for the ra
dio timers as N to 3N in increments of one where the units of N can be 1 hour or
10 hours. The Inactivity Timer and the Retransmission Timer be set based on the
se limits.</t>
</section>
</section>
</section>
<section anchor="informational-part"><name>Informational Part.</name>
<t>These scenarios shows how 3GPP could use SCHC for their transmissions.</t>
<section anchor="Radio"><name>Use of SCHC over the Radio link</name>
<t>Deploying SCHC over the radio link only would require placing it as part of t
he protocol stack for data transfer between the Dev-UE and the RGW-eNB. This sta
ck is the functional layer responsible for transporting data over the wireless c
onnection and managing radio resources. There is support for features such as re
liability, segmentation, and concatenation. The transmissions use link adaptatio
n, meaning that the system will optimize the transport format used according to
the radio conditions, the number of bits to transmit, and the power and interfer
ence constraints. That means that the number of bits transmitted over the air de
pends on the selected Modulation and Coding Schemes (MCS). Transport Block (TB)
transmissions happen in the physical layer at network-synchronized intervals cal
led Transmission Time Interval (TTI). Each Transport Block has a different MCS a
nd number of bits available to transmit. The MAC layer <xref target="TR36321"/>
defines the Transport Blocks' characteristics. The Radio link stack shown in <xr
ef target="Fig-ProtocolArchi3"/> comprises the Packet Data Convergence Protocol
(PDCP) <xref target="TS36323"/>, Radio Link Protocol (RLC) <xref target="TS36322
"/>, Medium Access Control protocol (MAC) <xref target="TR36321"/>, and the Phys
ical Layer <xref target="TS36201"/>. The <xref target="AppendixA"/> gives more d
etails about these protocols.</t>
<figure title="SCHC over the Radio link" anchor="Fig-ProtocolArchi3"><artwork><!
[CDATA[
+---------+ +---------+ |
|IP/non-IP+------------------------------+IP/non-IP+->+
+---------+ | +---------------+ | +---------+ |
| PDCP +-------+ PDCP | GTP|U +------+ GTP-U |->+
| (SCHC) + + (SCHC)| + + | |
+---------+ | +---------------+ | +---------+ |
| RLC +-------+ RLC |UDP/IP +------+ UDP/IP +->+
+---------+ | +---------------+ | +---------+ |
| MAC +-------+ MAC | L2 +------+ L2 +->+
+---------+ | +---------------+ | +---------+ |
| PHY +-------+ PHY | PHY +------+ PHY +->+
+---------+ +---------------+ +---------+ |
C-Uu/ S1-U SGi
Dev-UE RGW-eNB NGW-CSGN
Radio Link
]]></artwork></figure>
<section anchor="schc-entities-placing-over-the-radio-link"><name>SCHC Entities The Inactivity Timer and the Retransmission Timer can be set based on
Placing over the Radio Link</name> these limits.</t>
<t>The 3GPP architecture supports Robust Header Compression (ROHC) <xref target= </section>
"RFC5795"/> in the PDCP layer. Therefore, the architecture can deploy SCHC heade </section>
r compression entities similarly without the need for significant changes in the </section>
3GPP specifications.</t> <section anchor="informational-part">
<name>Informational Scenarios</name>
<t>These scenarios show how 3GPP could use SCHC for their
transmissions.</t>
<section anchor="Radio">
<name>Use of SCHC over the Radio Link</name>
<t>Deploying SCHC over the Radio Link only would require placing it as
part of the protocol stack for data transfer between the Dev-UE and the RGW-eNB
. This stack is the functional layer responsible for transporting data over the
wireless connection and managing radio resources. There is support for features
such as reliability, segmentation, and concatenation. The transmissions use link
adaptation, meaning that the system will optimize the transport format used acc
ording to the radio conditions, the number of bits to transmit, and the power an
d interference constraints. That means that the number of bits transmitted over
the air depends on the selected Modulation and Coding Schemes (MCSs). Transport
Block (TB) transmissions happen in the Physical Layer at network-synchronized in
tervals called Transmission Time Interval (TTI). Each TB has a different MCS and
number of bits available to transmit. The MAC layer <xref target="TR36321"/> de
fines the characteristics of the TBs. The Radio Link stack shown in <xref target
="Fig-ProtocolArchi3"/> comprises the Packet Data Convergence Protocol (PDCP) <x
ref target="TS36323"/>, the Radio Link Protocol (RLC) <xref target="TS36322"/>,
the Medium Access Control protocol (MAC) <xref target="TR36321"/>, and the Physi
cal Layer <xref target="TS36201"/>. <xref target="AppendixA"/> gives more detail
s about these protocols.</t>
<figure anchor="Fig-ProtocolArchi3">
<name>SCHC over the Radio Link</name>
<artwork><![CDATA[
+---------+ +---------+ |
|IP/Non-IP+------------------------------+IP/Non-IP+->+
+---------+ | +---------------+ | +---------+ |
| PDCP +-------+ PDCP | GTP|U +------+ GTP-U |->+
| (SCHC) + + (SCHC)| + + | |
+---------+ | +---------------+ | +---------+ |
| RLC +-------+ RLC |UDP/IP +------+ UDP/IP +->+
+---------+ | +---------------+ | +---------+ |
| MAC +-------+ MAC | L2 +------+ L2 +->+
+---------+ | +---------------+ | +---------+ |
| PHY +-------+ PHY | PHY +------+ PHY +->+
+---------+ +---------------+ +---------+ |
C-Uu/ S1-U SGi
Dev-UE RGW-eNB NGW-CSGN
Radio Link
]]></artwork>
</figure>
<section anchor="schc-entities-placing-over-the-radio-link">
<t>The RLC layer has three functional modes Transparent Mode (TM), Unacknowledge <name>Placing SCHC Entities over the Radio Link</name>
d Mode (UM), and Acknowledged Mode (AM). The mode of operation controls the func <t>The 3GPP architecture supports Robust Header Compression (ROHC) <
tionalities of the RLC layer. xref target="RFC5795"/> in the PDCP layer. Therefore, the architecture can deplo
y SCHC header compression entities similarly without the need for significant ch
anges in the 3GPP specifications.</t>
<t>The RLC layer has three functional modes: Transparent Mode (TM),
Unacknowledged Mode (UM), and Acknowledged Mode (AM). The mode of operation cont
rols the functionalities of the RLC layer.
TM only applies to signaling packets, while AM or UM carry signaling and data pa ckets.</t> TM only applies to signaling packets, while AM or UM carry signaling and data pa ckets.</t>
<t>The RLC layer takes care of fragmentation unless for the Transparent Mode. In <t>The RLC layer takes care of fragmentation except for the TM. In AM or UM, the
AM or UM modes, the SCHC fragmentation is unnecessary and <bcp14>SHOULD NOT</bc SCHC fragmentation is unnecessary and <bcp14>SHOULD NOT</bcp14> be used. While
p14> be used. While sending IP packets, the Radio link does not commonly use the sending IP packets, the Radio Link does not commonly use the RLC TM. However, if
RLC Transparent Mode. However, if other protocol overhead optimizations are tar other protocol overhead optimizations are targeted for NB-IoT traffic, SCHC fra
geted for NB-IoT traffic, SCHC fragmentation may be used for TM transmission mod gmentation may be used for TM transmission in the future.</t>
e in the future.</t> </section>
</section>
</section> <section anchor="DONAS">
</section> <name>Use of SCHC over the Non-Access Stratum (NAS)</name>
<section anchor="DONAS"><name>Use of SCHC over the Non-Access Stratum (NAS)</nam <t>This section consists of IETF suggestions to the 3GPP. The NGW-MME
e> conveys mainly signaling between the Dev-UE and the cellular network <xref targe
<t>This section consists of IETF suggestions to the 3GPP. The NGW-MME conveys ma t="TR24301"/>. The network transports this traffic on top of the Radio Link.</t>
inly signaling between the Dev-UE and the cellular network <xref target="TR24301 <t>This kind of flow supports data transmissions to reduce the overhea
"/>. The network transports this traffic on top of the radio link.</t> d when transmitting infrequent small quantities of data. This transmission is kn
own as Data over Non-Access Stratum (DoNAS) or Control Plane CIoT EPS optimizati
<t>This kind of flow supports data transmissions to reduce the overhead when tra ons. In DoNAS, the Dev-UE uses the pre-established security, can piggyback small
nsmitting infrequent small quantities of data. This transmission is known as Dat uplink data into the initial uplink message, and uses an additional message to
a over Non-Access Stratum (DoNAS) or Control Plane Cellular Internet of Things ( receive a downlink small data response.</t>
CIoT) evolved packet system (EPS) optimizations. In DoNAS, the Dev-UE uses the p <t>The NGW-MME performs the data encryption from the network side in a
re-established security and can piggyback small uplink data into the initial upl DoNAS PDU. Depending on the data type signaled indication (IP or Non-IP data),
ink message and uses an additional message to receive a downlink small data resp the network allocates an IP address or establishes a direct forwarding path.
onse.</t>
<t>The NGW-MME performs the data encryption from the network side in a DoNAS PDU
. Depending on the data type signaled indication (IP or non-IP data), the networ
k allocates an IP address or establishes a direct forwarding path.
DoNAS is regulated under rate control upon previous agreement, meaning that a ma ximum number of bits per unit of time is agreed upon per device subscription bef orehand and configured in the device.</t> DoNAS is regulated under rate control upon previous agreement, meaning that a ma ximum number of bits per unit of time is agreed upon per device subscription bef orehand and configured in the device.</t>
<t>The system will use DoNAS when a terminal in a power-saving state r
<t>The system will use DoNAS when a terminal in a power-saving state requires a equires a short transmission and receives an acknowledgment or short feedback fr
short transmission and receives an acknowledgment or short feedback from the net om the network. Depending on the size of the buffered data to be transmitted, th
work. Depending on the size of buffered data to transmit, the Dev-UE might deplo e Dev-UE might deploy the connected mode transmission instead. The connected mod
y the connected mode transmissions instead, limiting and controlling the DoNAS t e would limit and control the DoNAS transmissions to predefined thresholds, and
ransmissions to predefined thresholds and a good resource optimization balance f it would be a good resource optimization balance for the terminal and the networ
or the terminal and the network. The support for mobility of DoNAS is present bu k. The support for mobility of DoNAS is present but produces additional overhead
t produces additional overhead. The <xref target="AppendixB"/> gives additional . <xref target="AppendixB"/> gives additional details of DoNAS.</t>
details of DoNAS.</t> <section anchor="schc-entities-placing-over-donas">
<name>Placing SCHC Entities over DoNAS</name>
<section anchor="schc-entities-placing-over-donas"><name>SCHC Entities Placing o <t>SCHC resides in this scenario's Non-Access Stratum (NAS) protocol
ver DoNAS</name> layer. The same principles as for <xref target="Radio"/> apply here as well. Be
<t>SCHC resides in this scenario's Non-Access Stratum (NAS) protocol layer. The cause the NAS protocol already uses ROHC <xref target="RFC5795"/>, it can also a
same principles as for the section <xref target="Radio"/> apply here as well. Be dapt SCHC for header compression. The main difference compared to the Radio Link
cause the NAS protocol already uses ROHC <xref target="RFC5795"/>, it can also a (<xref target="Radio"/>) is the physical placing of the SCHC entities. On the n
dapt SCHC for header compression. The main difference compared to the radio link etwork side, the NGW-MME resides in the core network and is the terminating node
, section <xref target="Radio"/>, is the physical placing of the SCHC entities. for NAS instead of the RGW-eNB.</t>
On the network side, the NGW-MME resides in the core network and is the terminat <figure anchor="Fig-ProtocolArchi4">
ing node for NAS instead of the RGW-eNB.</t> <name>SCHC Entities Placement in the 3GPP CIOT Radio Protocol Arch
itecture for DoNAS Transmissions</name>
<figure title="SCHC entities placement in the 3GPP CIOT radio protocol architect <artwork><![CDATA[
ure for DoNAS transmissions" anchor="Fig-ProtocolArchi4"><artwork><![CDATA[
+--------+ +--------+--------+ + +--------+ +--------+ +--------+--------+ + +--------+
| IP/ +--+-----------------+--+ IP/ | IP/ +-----+ IP/ | | IP/ +--+-----------------+--+ IP/ | IP/ +-----+ IP/ |
| Non-IP | | | | Non-IP | Non-IP | | | Non-IP | | Non-IP | | | | Non-IP | Non-IP | | | Non-IP |
+--------+ | | +-----------------+ | +--------+ +--------+ | | +-----------------+ | +--------+
| NAS +-----------------------+ NAS |GTP-C/U +-----+GTP-C/U | | NAS +-----------------------+ NAS |GTP-C/U +-----+GTP-C/U |
|(SCHC) | | | | (SCHC) | | | | | |(SCHC) | | | | (SCHC) | | | | |
+--------+ | +-----------+ | +-----------------+ | +--------+ +--------+ | +-----------+ | +-----------------+ | +--------+
| RRC +-----+RRC |S1|AP+-----+ S1|AP | | | | | | RRC +-----+RRC |S1|AP+-----+ S1|AP | | | | |
+--------+ | +-----------+ | +--------+ UDP +-----+ UDP | +--------+ | +-----------+ | +--------+ UDP +-----+ UDP |
| PDCP* +-----+PDCP*|SCTP +-----+ SCTP | | | | | | PDCP* +-----+PDCP*|SCTP +-----+ SCTP | | | | |
skipping to change at line 350 skipping to change at line 419
| RLC +-----+ RLC | IP +-----+ IP | IP +-----+ IP | | RLC +-----+ RLC | IP +-----+ IP | IP +-----+ IP |
+--------+ | +-----------+ | +-----------------+ | +--------+ +--------+ | +-----------+ | +-----------------+ | +--------+
| MAC +-----+ MAC | L2 +-----+ L2 | L2 +-----+ L2 | | MAC +-----+ MAC | L2 +-----+ L2 | L2 +-----+ L2 |
+--------+ | +-----------+ | +-----------------+ | +--------+ +--------+ | +-----------+ | +-----------------+ | +--------+
| PHY +--+--+ PHY | PHY +--+--+ PHY | PHY +-----+ PHY | | PHY +--+--+ PHY | PHY +--+--+ PHY | PHY +-----+ PHY |
+--------+ +-----+-----+ +--------+--------+ | +--------+ +--------+ +-----+-----+ +--------+--------+ | +--------+
C-Uu/ S1 SGi C-Uu/ S1 SGi
Dev-UE RGW-eNB NGW-MME NGW-PGW Dev-UE RGW-eNB NGW-MME NGW-PGW
*PDCP is bypassed until AS security is activated TGPP36300. *PDCP is bypassed until AS security is activated TGPP36300.
]]></artwork>
</figure>
</section>
</section>
<section anchor="Radio-Parameters">
<name>Parameters for Static Context Header Compression and
Fragmentation (SCHC) for the Radio Link and DoNAS Use Cases</name>
<t>If 3GPP incorporates SCHC, it is recommended that these scenarios
use the SCHC header compression <xref target="RFC8724"/> capability to
optimize the data transmission.</t>
<ul spacing="normal">
<li><t>SCHC Context Initialization</t>
<t>The Radio Resource Control (RRC) protocol is the main tool used
to configure the parameters of the Radio Link. It will configure
SCHC and the static context distribution as it has been made for ROHC
operation
<xref target="RFC5795"/> <xref
target="TS36323"/>.</t></li>
<li><t>SCHC Rules</t>
<t>The network operator defines the number of
rules in these scenarios. For this, the network operator must know th
e IP traffic the
device will carry. The operator might supply rules compatible with
the device's use case. For devices acting as a capillary gateway,
several rules match the diversity of devices and protocols used by
the devices associated with the gateway. Meanwhile, simpler
devices may have predetermined protocols and fixed parameters.
The use of IPv6 and IPv4 may force the operator to develop more rules
to deal with
each case.</t></li>
<li><t>RuleID</t>
<t>There is a reasonable assumption of 9 bytes of radio protocol
overhead for these transmission scenarios in NB-IoT, where PDCP
uses 5 bytes due to header and integrity protection and where RLC
and MAC use 4 bytes. The minimum physical TBs
that can withhold this overhead value, according to the 3GPP
Release 15 specification <xref target="R15-3GPP"/>, are 88, 104,
120, and 144 bits. As for <xref target="Config"/>, these
scenarios must optimize the Physical Layer where the smallest TB
is 12 bits. These 12 bits must include the Compression Residue in
addition to the RuleID. On the other hand, more complex NB-IoT
devices (such as a capillary gateway) might require additional
bits to handle the variety and multiple parameters of higher-layer
protocols deployed. In that sense, the operator may want
flexibility on the number and type of rules independently
supported by each device; consequently, these scenarios require a
configurable value. The configuration may be part of the agreed
operation profile with the content distribution. The RuleID field
size may range from 2 bits, resulting in 4 rules, to an 8-bit
value, yielding up to 256 rules for use with the operators. A
256-rule maximum limit seems to be quite reasonable, even for a
device acting as a NAT. An application may use a larger RuleID,
but it should consider the byte alignment of the expected
Compression Residue. In the minimum TB size case, 2 bits of RuleID
leave only 6 bits available for Compression Residue.</t></li>
<li><t>SCHC MAX_PACKET_SIZE</t>
<t>The Radio Link can handle the fragmentation of SCHC packets if
needed, including reliability. Hence, the packet size is limited
by the MTU that is handled by the radio protocols, which
corresponds to 1600 bytes for the 3GPP Release 15.</t></li>
<li><t>Fragmentation</t>
<t>For the Radio Link (<xref target="Radio"/>) and DoNAS (<xref
target="DONAS"/>) scenarios, the SCHC fragmentation functions are
disabled. The RLC layer of NB-IoT can segment packets into
suitable units that fit the selected TB for
transmissions of the Physical Layer. The block selection is made
according to the link adaptation input function in the MAC layer
and the quantity of data in the buffer. The link adaptation layer
may produce different results at each TTI, resulting in varying
physical TBs that depend
on the network load, interference, number of bits transmitted, and
QoS. Even if setting a value that allows the construction of data
units following the SCHC tiles principle, the protocol overhead
may be greater or equal to allowing the Radio Link protocols to
take care of the fragmentation intrinsically.</t></li>
<li><t>Fragmentation in RLC TM</t>
<t>The RLC TM mostly applies to control signaling
transmissions. When RLC operates in TM, the MAC
layer mechanisms ensure reliability and generate overhead. This
additional reliability implies sending repetitions or automatic
retransmissions.</t>
<t>The ACK-Always fragmentation mode of SCHC may reduce this
overhead in future operations when data transmissions may use this
mode. The ACK-Always mode may transmit compressed data with fewer
possible transmissions by using fixed or limited TBs
compatible with the tiling SCHC fragmentation handling. For SCHC
fragmentation parameters, see <xref target="Config"/>.</t></li></ul>
</section>
</section>
</section>
<section anchor="padding">
<name>Padding</name>
<t>NB-IoT and 3GPP wireless access, in general, assumes a byte-aligned pay
load. Therefore, the L2 Word for NB-IoT <bcp14>MUST</bcp14> be considered 8 bits
, and the padding treatment should use this value accordingly.</t>
</section>
<section anchor="iana-considerations">
<name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section>
<section anchor="security-considerations">
<name>Security Considerations</name>
<t>This document does not add any security considerations and follows <xre
f target="RFC8724"/> and the 3GPP access security document specified in <xref ta
rget="TS33122"/>.</t>
</section>
</middle>
<back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
724.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
824.xml"/>
</references>
<references>
<name>Informative References</name>
]]></artwork></figure> <reference anchor="RFC5795" target="https://www.rfc-editor.org/info/rfc5
795">
</section> <front>
</section> <title>The RObust Header Compression (ROHC) Framework</title>
<section anchor="Radio-Parameters"><name>Parameters for Static Context Header Co <author fullname="K. Sandlund" initials="K." surname="Sandlund"/>
mpression and Fragmentation (SCHC) for the Radio link and DONAS use-cases.</name <author fullname="G. Pelletier" initials="G." surname="Pelletier"/>
> <author fullname="L-E. Jonsson" initials="L-E." surname="Jonsson"/>
<date month="March" year="2010"/>
<t>If 3GPP incorporates SCHC, it is recommended that these scenarios use SCHC he </front>
ader compression <xref target="RFC8724"/> capability to optimize the data transm <seriesInfo name="RFC" value="5795"/>
ission.</t> <seriesInfo name="DOI" value="10.17487/RFC5795"/>
</reference>
<t><list style="symbols">
<t>SCHC Context initialization.</t>
</list></t>
<t>The RRC (Radio Resource Control) protocol is the main tool used to configure
the parameters of the Radio link. It will configure SCHC and the static context
distribution as it has made for ROHC <xref target="RFC5795"/> operation <xref ta
rget="TS36323"/>.</t>
<t><list style="symbols">
<t>SCHC Rules.</t>
</list></t>
<t>The network operator in these scenarios defines the number of rules. For this
, the network operator must know the IP traffic the device will carry. The opera
tor might supply rules compatible with the device's use case.
For devices acting as a capillary gateway, several rules match the diversity of
devices and protocols used by the devices associated with the gateway. Meanwhile
, simpler devices may have predetermined protocols and fixed parameters.
The use of IPv6 and IPv4 may force to get more rules to deal with each case.</t>
<t><list style="symbols">
<t>RuleID.</t>
</list></t>
<t>There is a reasonable assumption of 9 bytes of radio protocol overhead for th
ese transmission scenarios in NB-IoT, where PDCP uses 5 bytes due to header and
integrity protection, and RLC and MAC use 4 bytes. The minimum physical Transpo
rt Blocks (TB) that can withhold this overhead value according to 3GPP Release 1
5 specifications are 88, 104, 120, and 144 bits.
As for <xref target="Config"/>, these scenarios must optimize the physical layer
where the smallest TB is 12 bits.
These 12 bits must include the Compression Residue in addition to the RuleID. On
the other hand, more complex NB-IoT devices (such as a capillary gateway) might
require additional bits to handle the variety and multiple parameters of higher
-layer protocols deployed. In that sense, the operator may want flexibility on t
he number and type of rules independently supported by each device; consequently
, these scenarios require a configurable value.
The configuration may be part of the agreed operation profile with the content d
istribution. The RuleID field size may range from 2 bits, resulting in 4 rules t
o an 8-bit value that would yield up to 256 rules that can be used with the oper
ators and seems quite a reasonable maximum limit even for a device acting as a N
AT.
An application may use a larger RuleID, but it should consider the byte alignmen
t of the expected Compression Residue. In the minimum TB size case, 2 bits of Ru
leID leave only 6 bits available for Compression Residue.</t>
<t><list style="symbols">
<t>SCHC MAX_PACKET_SIZE.</t>
</list></t>
<t>The Radio Link can handle the fragmentation of SCHC packets if needed, includ
ing reliability. Hence, the packet size is limited by the MTU handled by the rad
io protocols, which corresponds to 1600 bytes for 3GPP Release 15.</t>
<t><list style="symbols">
<t>Fragmentation.</t>
</list></t>
<t>For the Radio link <xref target="Radio"/> and DoNAS' <xref target="DONAS"/> s
cenarios, the SCHC fragmentation functions are disabled. The RLC layer of NB-IoT
can segment packets into suitable units that fit the selected transport blocks
for transmissions of the physical layer. The block selection is made according t
o the link adaptation input function in the MAC layer and the quantity of data i
n the buffer. The link adaptation layer may produce different results at each Ti
me Transmission Interval (TTI), resulting in varying physical transport blocks t
hat depend on the network load, interference, number of bits transmitted, and Qo
S. Even if setting a value that allows the construction of data units following
the SCHC tiles principle, the protocol overhead may be greater or equal to allow
ing the Radio link protocols to take care of the fragmentation intrinsically.</t
>
<t><list style="symbols">
<t>Fragmentation in RLC Transparent Mode.</t>
</list></t>
<t>The RLC Transparent Mode mostly applies to control signaling transmissions. W
hen RLC operates in Transparent Mode, the MAC layer mechanisms ensure reliabilit
y and generate overhead. This additional reliability implies sending repetitions
or automatic retransmissions.</t>
<t>The ACK-Always fragmentation mode of SCHC may reduce this overhead in future
operations when data transmissions may use this mode. ACK-Always mode may transm
it compressed data with fewer possible transmissions by using fixed or limited t
ransport blocks compatible with the tiling SCHC fragmentation handling. For SCHC
fragmentation parameters see <xref target="Config"/>.</t>
</section>
</section>
</section>
<section anchor="padding"><name>Padding</name>
<t>NB-IoT and 3GPP wireless access, in general, assumes byte-aligned payload. Th
erefore, the layer 2 word for NB-IoT <bcp14>MUST</bcp14> be considered 8 bits, a
nd the padding treatment should use this value accordingly.</t>
</section>
<section anchor="iana-considerations"><name>IANA considerations</name>
<t>This document has no IANA actions.</t>
</section> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<section anchor="security-considerations"><name>Security considerations</name> 376.xml"/>
<t>This document does not add any security considerations and follows the <xref
target="RFC8724"/> and the 3GPP access security document specified in <xref targ
et="TS33122"/>.</t>
</section> <reference anchor="R15-3GPP" target="https://www.3gpp.org/specifications
-technologies/releases/release-15">
<front>
<title>Release 15</title>
<author>
<organization>3GPP</organization>
</author>
<date month="April" year="2019"/>
</front>
</reference>
</middle> <reference anchor="TR23720" target="https://www.3gpp.org/ftp/Specs/archi
ve/23_series/23.720/23720-d00.zip">
<front>
<title>Study on architecture enhancements for Cellular Internet of T
hings</title>
<author>
<organization>3GPP</organization>
</author>
<date month="March" year="2016"/>
</front>
<refcontent>3GPP TR 23.720 V13.0.0</refcontent>
</reference>
<back> <reference anchor="TS33122" target="https://www.3gpp.org/ftp//Specs/arch
ive/33_series/33.122/33122-f30.zip">
<front>
<title>Security aspects of Common API Framework (CAPIF) for 3GPP nor
thbound APIs</title>
<author>
<organization>3GPP</organization>
</author>
<date month="March" year="2019"/>
</front>
<refcontent>3GPP TS 33.122 V15.3.0</refcontent>
</reference>
<references title='Normative References'> <reference anchor="TR36321" target="https://www.3gpp.org/ftp/Specs/archi
ve/36_series/36.321/36321-d20.zip">
<front>
<title>Evolved Universal Terrestrial Radio Access (E-UTRA);
Medium Access Control (MAC) protocol specification
</title>
<author>
<organization>3GPP</organization>
</author>
<date month="June" year="2016"/>
</front>
<refcontent>3GPP TS 36.321 V13.2.0</refcontent>
</reference>
<reference anchor='RFC2119' target='https://www.rfc-editor.org/info/rfc2119'> <reference anchor="TS36322" target="https://www.3gpp.org/ftp/Specs/archi
<front> ve/36_series/36.322/36322-f01.zip">
<title>Key words for use in RFCs to Indicate Requirement Levels</title> <front>
<author fullname='S. Bradner' initials='S.' surname='Bradner'><organization/></a <title>Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
uthor> Link Control (RLC) protocol specification</title>
<date month='March' year='1997'/> <author>
<abstract><t>In many standards track documents several words are used to signify <organization>3GPP</organization>
the requirements in the specification. These words are often capitalized. This </author>
document defines these words as they should be interpreted in IETF documents. <date month="April" year="2018"/>
This document specifies an Internet Best Current Practices for the Internet Comm </front>
unity, and requests discussion and suggestions for improvements.</t></abstract> <refcontent>3GPP TS 36.322 V15.0.1</refcontent>
</front> </reference>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>
<reference anchor='RFC8174' target='https://www.rfc-editor.org/info/rfc8174'> <reference anchor="TS36201" target="https://www.3gpp.org/ftp/Specs/archi
<front> ve/36_series/36.201/36201-f10.zip">
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <front>
<author fullname='B. Leiba' initials='B.' surname='Leiba'><organization/></autho <title>Evolved Universal Terrestrial Radio Access (E-UTRA); LTE
r> physical layer; General description</title>
<date month='May' year='2017'/> <author>
<abstract><t>RFC 2119 specifies common key words that may be used in protocol s <organization>3GPP</organization>
pecifications. This document aims to reduce the ambiguity by clarifying that on </author>
ly UPPERCASE usage of the key words have the defined special meanings.</t></abs <date month="June" year="2018"/>
tract> </front>
</front> <refcontent>3GPP TS 36.201 V15.1.0</refcontent>
<seriesInfo name='BCP' value='14'/> </reference>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>
<reference anchor='RFC8724' target='https://www.rfc-editor.org/info/rfc8724'> <reference anchor="TR24301" target="https://www.3gpp.org/ftp//Specs/arch
<front> ive/24_series/24.301/24301-f80.zip">
<title>SCHC: Generic Framework for Static Context Header Compression and Fragmen <front>
tation</title> <title>Non-Access-Stratum (NAS) protocol for Evolved Packet System (
<author fullname='A. Minaburo' initials='A.' surname='Minaburo'><organization/>< EPS); Stage 3</title>
/author> <author>
<author fullname='L. Toutain' initials='L.' surname='Toutain'><organization/></a <organization>3GPP</organization>
uthor> </author>
<author fullname='C. Gomez' initials='C.' surname='Gomez'><organization/></autho <date month="December" year="2019"/>
r> </front>
<author fullname='D. Barthel' initials='D.' surname='Barthel'><organization/></a <refcontent>3GPP TS 24.301 V15.8.0</refcontent>
uthor> </reference>
<author fullname='JC. Zuniga' initials='JC.' surname='Zuniga'><organization/></a
uthor>
<date month='April' year='2020'/>
<abstract><t>This document defines the Static Context Header Compression and fra
gmentation (SCHC) framework, which provides both a header compression mechanism
and an optional fragmentation mechanism. SCHC has been designed with Low-Power W
ide Area Networks (LPWANs) in mind.</t><t>SCHC compression is based on a common
static context stored both in the LPWAN device and in the network infrastructure
side. This document defines a generic header compression mechanism and its appl
ication to compress IPv6/UDP headers.</t><t>This document also specifies an opti
onal fragmentation and reassembly mechanism. It can be used to support the IPv6
MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 da
tagrams that, after SCHC compression or when such compression was not possible,
still exceed the Layer 2 maximum payload size.</t><t>The SCHC header compression
and fragmentation mechanisms are independent of the specific LPWAN technology o
ver which they are used. This document defines generic functionalities and offer
s flexibility with regard to parameter settings and mechanism choices. This docu
ment standardizes the exchange over the LPWAN between two SCHC entities. Setting
s and choices specific to a technology or a product are expected to be grouped i
nto profiles, which are specified in other documents. Data models for the contex
t and profiles are out of scope.</t></abstract>
</front>
<seriesInfo name='RFC' value='8724'/>
<seriesInfo name='DOI' value='10.17487/RFC8724'/>
</reference>
<reference anchor='RFC8824' target='https://www.rfc-editor.org/info/rfc8824'> <reference anchor="TS24008" target="https://www.3gpp.org/ftp//Specs/arch
<front> ive/24_series/24.008/24008-f50.zip">
<title>Static Context Header Compression (SCHC) for the Constrained Application <front>
Protocol (CoAP)</title> <title>Mobile radio interface Layer 3 specification; Core network
<author fullname='A. Minaburo' initials='A.' surname='Minaburo'><organization/>< protocols; Stage 3</title>
/author> <author>
<author fullname='L. Toutain' initials='L.' surname='Toutain'><organization/></a <organization>3GPP</organization>
uthor> </author>
<author fullname='R. Andreasen' initials='R.' surname='Andreasen'><organization/ <date month="December" year="2018"/>
></author> </front>
<date month='June' year='2021'/> <refcontent>3GPP TS 24.008 V15.5.0</refcontent>
<abstract><t>This document defines how to compress Constrained Application Proto </reference>
col (CoAP) headers using the Static Context Header Compression and fragmentation
(SCHC) framework. SCHC defines a header compression mechanism adapted for Const
rained Devices. SCHC uses a static description of the header to reduce the heade
r's redundancy and size. While RFC 8724 describes the SCHC compression and fragm
entation framework, and its application for IPv6/UDP headers, this document appl
ies SCHC to CoAP headers. The CoAP header structure differs from IPv6 and UDP, s
ince CoAP uses a flexible header with a variable number of options, themselves o
f variable length. The CoAP message format is asymmetric: the request messages h
ave a header format different from the format in the response messages. This spe
cification gives guidance on applying SCHC to flexible headers and how to levera
ge the asymmetry for more efficient compression Rules.</t></abstract>
</front>
<seriesInfo name='RFC' value='8824'/>
<seriesInfo name='DOI' value='10.17487/RFC8824'/>
</reference>
</references> <reference anchor="TS36323" target="https://www.3gpp.org/ftp/Specs/archi
ve/36_series/36.323/36323-d20.zip">
<front>
<title>Evolved Universal Terrestrial Radio Access (E-UTRA);
Packet Data Convergence Protocol (PDCP) specification</title>
<author>
<organization>3GPP</organization>
</author>
<date month="June" year="2016"/>
</front>
<refcontent>3GPP TS 36.323 V13.2.0</refcontent>
</reference>
<references title='Informative References'> <reference anchor="TS36331" target="https://www.3gpp.org/ftp//Specs/arch
ive/36_series/36.331/36331-f51.zip">
<front>
<title>Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification</title>
<author>
<organization>3GPP</organization>
</author>
<date month="April" year="2019"/>
</front>
<refcontent>3GPP TS 36.331 V15.5.1</refcontent>
</reference>
<reference anchor='RFC5795' target='https://www.rfc-editor.org/info/rfc5795'> <reference anchor="TS23222" target="https://www.3gpp.org/ftp/Specs/archi
<front> ve/23_series/23.222/23222-f60.zip">
<title>The RObust Header Compression (ROHC) Framework</title> <front>
<author fullname='K. Sandlund' initials='K.' surname='Sandlund'><organization/>< <title>Functional architecture and information flows to support Comm
/author> on API Framework for 3GPP Northbound APIs; Stage 2</title>
<author fullname='G. Pelletier' initials='G.' surname='Pelletier'><organization/ <author>
></author> <organization>3GPP</organization>
<author fullname='L-E. Jonsson' initials='L-E.' surname='Jonsson'><organization/ </author>
></author> <date month="September" year="2022"/>
<date month='March' year='2010'/> </front>
<abstract><t>The Robust Header Compression (ROHC) protocol provides an efficient <refcontent>3GPP TS 23.222 V15.6.0</refcontent>
, flexible, and future-proof header compression concept. It is designed to oper </reference>
ate efficiently and robustly over various link technologies with different chara
cteristics.</t><t>The ROHC framework, along with a set of compression profiles,
was initially defined in RFC 3095. To improve and simplify the ROHC specificati
ons, this document explicitly defines the ROHC framework and the profile for unc
ompressed separately. More specifically, the definition of the framework does n
ot modify or update the definition of the framework specified by RFC 3095.</t><t
>This specification obsoletes RFC 4995. It fixes one interoperability issue tha
t was erroneously introduced in RFC 4995, and adds some minor clarifications. [
STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5795'/>
<seriesInfo name='DOI' value='10.17487/RFC5795'/>
</reference>
<reference anchor='RFC8376' target='https://www.rfc-editor.org/info/rfc8376'> <reference anchor="TR-0024" target="https://ftp.onem2m.org/work%20progra
<front> mme/WI-0037/TR-0024-3GPP_Interworking-V4_3_0.DOCX">
<title>Low-Power Wide Area Network (LPWAN) Overview</title> <front>
<author fullname='S. Farrell' initials='S.' role='editor' surname='Farrell'><org <title>3GPP_Interworking</title>
anization/></author> <author>
<date month='May' year='2018'/> <organization>OneM2M</organization>
<abstract><t>Low-Power Wide Area Networks (LPWANs) are wireless technologies wit </author>
h characteristics such as large coverage areas, low bandwidth, possibly very sma <date month="March" year="2020"/>
ll packet and application-layer data sizes, and long battery life operation. Th </front>
is memo is an informational overview of the set of LPWAN technologies being cons <refcontent>TR-0024-V4.3.0</refcontent>
idered in the IETF and of the gaps that exist between the needs of those technol </reference>
ogies and the goal of running IP in LPWANs.</t></abstract>
</front>
<seriesInfo name='RFC' value='8376'/>
<seriesInfo name='DOI' value='10.17487/RFC8376'/>
</reference>
<reference anchor="_3GPPR15" target="https://www.3gpp.org/release-15"> <reference anchor="OMA0116" target="https://www.openmobilealliance.org/r
<front> elease/REST_NetAPI_Common/V1_0-20180116-A/OMA-TS-REST_NetAPI_Common-V1_0-2018011
<title>The Mobile Broadband Standard</title> 6-A.pdf">
<author > <front>
<organization>3GPP</organization> <title>Common definitions for RESTful Network APIs</title>
</author> <author>
<date year="2019"/> <organization>Open Mobile Alliance</organization>
</front> </author>
</reference> <date month="January" year="2018"/>
<reference anchor="TR23720" target="https://www.3gpp.org/ftp/Specs/archive/23_se </front>
ries/23.720/23720-d00.zip"> <refcontent>Version 1.0</refcontent>
<front> </reference>
<title>Study on architecture enhancements for Cellular Internet of Things</t
itle>
<author >
<organization>3GPP</organization>
</author>
<date year="2015"/>
</front>
</reference>
<reference anchor="TS33122" target="https://www.3gpp.org/ftp//Specs/archive/33_s
eries/33.122/33122-f30.zip">
<front>
<title>Security aspects of Common API Framework (CAPIF) for 3GPP northbound
APIs</title>
<author >
<organization>3GPP</organization>
</author>
<date year="2018"/>
</front>
</reference>
<reference anchor="TR36321" target="https://www.3gpp.org/ftp/Specs/archive/36_se
ries/36.321/36321-d20.zip">
<front>
<title>Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Co
ntrol (MAC) protocol specification</title>
<author >
<organization>3GPP</organization>
</author>
<date year="2016"/>
</front>
</reference>
<reference anchor="TS36322" target="https://www.3gpp.org/ftp/Specs/archive/36_se
ries/36.322/36322-f01.zip">
<front>
<title>Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Link Contr
ol (RLC) protocol specification</title>
<author >
<organization>3GPP</organization>
</author>
<date year="2018"/>
</front>
</reference>
<reference anchor="TS36201" target="https://www.3gpp.org/ftp/Specs/archive/36_se
ries/36.201/36201-f10.zip">
<front>
<title>Evolved Universal Terrestrial Radio Access (E-UTRA); LTE physical lay
er; General description</title>
<author >
<organization>3GPP</organization>
</author>
<date year="2018"/>
</front>
</reference>
<reference anchor="TR24301" target="https://www.3gpp.org/ftp//Specs/archive/24_s
eries/24.301/24301-f80.zip">
<front>
<title>Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Co
ntrol (MAC) protocol specification</title>
<author >
<organization>3GPP</organization>
</author>
<date year="2019"/>
</front>
</reference>
<reference anchor="TR-0024" target="https://ftp.onem2m.org/work%20programme/WI-0
037/TR-0024-3GPP_Interworking-V4_3_0.DOCX">
<front>
<title>3GPP_Interworking</title>
<author >
<organization>OneM2M</organization>
</author>
<date year="2020"/>
</front>
</reference>
<reference anchor="OMA0116" target="https://www.openmobilealliance.org/release/R
EST_NetAPI_Common/V1_0-20180116-A/OMA-TS-REST_NetAPI_Common-V1_0-20180116-A.pdf"
>
<front>
<title>Common definitions for RESTful Network APIs</title>
<author >
<organization>OMA</organization>
</author>
<date year="2018"/>
</front>
</reference>
<reference anchor="TS24008" target="https://www.3gpp.org/ftp//Specs/archive/24_s
eries/24.008/24008-f50.zip">
<front>
<title>Mobile radio interface layer 3 specification.</title>
<author >
<organization>3GPP</organization>
</author>
<date year="2018"/>
</front>
</reference>
<reference anchor="TS36323" target="https://www.3gpp.org/ftp/Specs/archive/36_se
ries/36.323/36323-d20.zip">
<front>
<title>Evolved Universal Terrestrial Radio Access (E-UTRA); Packet Data Conv
ergence Protocol (PDCP) specification</title>
<author >
<organization>3GPP</organization>
</author>
<date year="2016"/>
</front>
</reference>
<reference anchor="TS36331" target="https://www.3gpp.org/ftp//Specs/archive/36_s
eries/36.331/36331-f51.zip">
<front>
<title>Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource C
ontrol (RRC); Protocol specification</title>
<author >
<organization>3GPP</organization>
</author>
<date year="2018"/>
</front>
</reference>
<reference anchor="TS23222" target="https://www.3gpp.org/ftp/Specs/archive/23_se
ries/23.222/23222-f60.zip">
<front>
<title>Common API Framework for 3GPP Northbound APIs</title>
<author >
<organization>3GPP</organization>
</author>
<date year="2022"/>
</front>
</reference>
</references>
</references> </references>
<section anchor="AppendixA"><name>NB-IoT User Plane protocol architecture</name> <section anchor="AppendixA">
<name>NB-IoT User Plane Protocol Architecture</name>
<section anchor="packet-data-convergence-protocol-pdcp-ts36323"><name>Packet Dat <section anchor="packet-data-convergence-protocol-pdcp-ts36323">
a Convergence Protocol (PDCP) <xref target="TS36323"/></name> <name>Packet Data Convergence Protocol (PDCP)</name>
<t>Each of the Radio Bearers (RB) is associated with one PDCP entity. Moreover, <t>Each of the Radio Bearers (RBs) is associated with one PDCP entity <x
a PDCP entity is associated with one or two RLC entities depending on the unidir ref target="TS36323"/>. Moreover, a PDCP entity is associated with one or two RL
ectional or bi-directional characteristics of the RB and RLC mode used. A PDCP e C entities, depending on the unidirectional or bidirectional characteristics of
ntity is associated with either a control plane or a user plane with independent the RB and RLC mode used. A PDCP entity is associated with either a control plan
configuration and functions. The maximum supported size for NB-IoT of a PDCP SD e or a user plane with independent configuration and functions. The maximum supp
U is 1600 octets. The primary services and functions of the PDCP sublayer for NB orted size for NB-IoT of a PDCP SDU is 1600 octets. The primary services and fun
-IoT for the user plane include:</t> ctions of the PDCP sublayer for NB-IoT for the user plane include:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Header compression and decompression using ROHC <xref
<t>Header compression and decompression using ROHC <xref target="RFC5795"/></t target="RFC5795"/></li>
> <li>Transfer of user and control data to higher and lower layers</li>
<t>Transfer of user and control data to higher and lower layers</t> <li>Duplicate detection of lower-layer SDUs when re-establishing
<t>Duplicate detection of lower layer SDUs when re-establishing connection (wh connection (when RLC with Acknowledge Mode is in use for User Plane
en RLC with Acknowledge Mode in use for User Plane only)</t> only)</li>
<t>Ciphering and deciphering</t> <li>Ciphering and deciphering</li>
<t>Timer-based SDU discard in uplink</t> <li>Timer-based SDU discard in uplink</li>
</list></t> </ul>
</section>
</section> <section anchor="radio-link-protocol-rlc-ts36322">
<section anchor="radio-link-protocol-rlc-ts36322"><name>Radio Link Protocol (RLC <name>Radio Link Protocol (RLC)</name>
) <xref target="TS36322"/></name> <t>RLC <xref target="TS36322"/> is an L2 protocol that operates between
<t>RLC is a layer-2 protocol that operates between the UE and the base station ( the User Equipment (UE) and the base station (eNB). It supports the packet deliv
eNB). It supports the packet delivery from higher layers to MAC, creating packet ery from higher layers to MAC, creating packets transmitted over the air, optimi
s transmitted over the air, optimizing the Transport Block utilization. RLC flow zing the TB utilization. RLC flow of data packets is unidirectional, and it is c
of data packets is unidirectional, and it is composed of a transmitter located omposed of a transmitter located in the transmission device and a receiver locat
in the transmission device and a receiver located in the destination device. The ed in the destination device. Therefore, to configure bidirectional flows, two s
refore, to configure bi-directional flows, two sets of entities, one in each dir ets of entities, one in each direction (downlink and uplink), must be configured
ection (downlink and uplink), must be configured and effectively peered to each and effectively peered to each other. The peering allows the transmission of co
other. The peering allows the transmission of control packets (ex., status repor ntrol packets (e.g., status reports) between entities. RLC can be configured for
ts) between entities. RLC can be configured for data transfer in one of the foll a data transfer in one of the following modes:</t>
owing modes:</t> <ul spacing="normal">
<li><t>Transparent Mode (TM)</t>
<t>RLC does not segment or concatenate SDUs from higher layers in
this mode and does not include any header with the payload. RLC
receives SDUs from upper layers when acting as a transmitter and
transmits directly to its flow RLC receiver via lower
layers. Similarly, upon reception, a TM RLC receiver would not
process the packets and only deliver them to higher layers.</t></li>
<li><t>Unacknowledged Mode (UM)</t>
<t>This mode provides support for segmentation and concatenation of
payload. The RLC packet's size depends on the indication given at a
particular transmission opportunity by the lower layer (MAC) and is
octet-aligned. The packet delivery to the receiver does not include
reliability support, and the loss of a segment from a packet means a
complete packet loss. Also, in lower-layer retransmissions, there is
no support for re-segmentation in case the radio
conditions change and trigger the selection of a smaller TB.
Additionally, it provides PDU duplication detection and
discards, out-of-sequence reordering, and loss
detection.</t></li>
<li><t>Acknowledged Mode (AM)</t>
<t><list style="symbols"> <t>In addition to the same functions supported by UM, this mode also
<t>Transparent Mode (TM). RLC does not segment or concatenate SDUs from higher adds a moving windows-based reliability service on top of the lower-lay
layers in this mode and does not include any header to the payload. RLC receive er
s SDUs from upper layers when acting as a transmitter and transmits directly to services.
its flow RLC receiver via lower layers. Similarly, a TM RLC receiver would only It also supports re-segmentation, and it requires
deliver without processing the packets to higher layers upon reception.</t> bidirectional communication to exchange acknowledgment reports,
<t>Unacknowledged Mode (UM). This mode provides support for segmentation and c called RLC Status Reports, and to trigger retransmissions. This model
oncatenation of payload. The RLC packet's size depends on the indication given a also supports protocol-error detection. The mode used depends on the
t a particular transmission opportunity by the lower layer (MAC) and is octet-al operator configuration for the type of data to be transmitted. For
igned. The packet delivery to the receiver does not include reliability support, example, data transmissions supporting mobility or requiring high
and the loss of a segment from a packet means a complete packet loss. Also, in reliability would be most likely configured using AM. Meanwhile,
the case of lower layer retransmissions, there is no support for re-segmentation streaming and real-time data would be mapped to a UM
in case of change of the radio conditions triggering the selection of a smaller configuration.</t></li>
transport block. Additionally, it provides PDU duplication detection and discar </ul>
ds, reordering of out-of-sequence, and loss detection.</t> </section>
<t>Acknowledged Mode (AM). In addition to the same functions supported by UM, <section anchor="medium-access-control-mac-tr36321">
this mode also adds a moving windows-based reliability service on top of the low <name>Medium Access Control (MAC)</name>
er layer services. It also supports re-segmentation, and it requires bidirection
al communication to exchange acknowledgment reports called RLC Status Report and
trigger retransmissions. This model also supports protocol error detection. The
mode used depends on the operator configuration for the type of data to be tran
smitted. For example, data transmissions supporting mobility or requiring high r
eliability would be most likely configured using AM. Meanwhile, streaming and re
al-time data would be mapped to a UM configuration.</t>
</list></t>
</section> <t>MAC <xref target="TR36321"/> provides a mapping between the higher layers abs
<section anchor="medium-access-control-mac-tr36321"><name>Medium Access Control traction called Logical Channels (which are comprised by the previously describe
(MAC) <xref target="TR36321"/></name> d protocols) and the Physical Layer channels (transport channels).
<t>MAC provides a mapping between the higher layers abstraction called Logical C
hannels comprised by the previously described protocols to the Physical layer ch
annels (transport channels). Additionally, MAC may multiplex packets from differ
ent Logical Channels and prioritize what to fit into one Transport Block if ther
e is data and space available to maximize data transmission efficiency. MAC also
provides error correction and reliability support through Hybrid Automatic Repe
at reQuest (HARQ), transport format selection, and scheduling information report
ing from the terminal to the network. MAC also adds the necessary padding and pi
ggyback control elements when possible and the higher layers data.</t>
<figure title="Example of User Plane packet encapsulation for two transport bloc Additionally, MAC may multiplex packets from different Logical Channels and prio
ks" anchor="Fig--MAC"><artwork><![CDATA[ ritize which ones to fit into one TB if there is data and space available to max
imize data transmission efficiency. MAC also provides error correction and relia
bility support through Hybrid Automatic Repeat reQuest (HARQ), transport format
selection, and scheduling information reported from the terminal to the network.
MAC also adds the necessary padding and piggyback control elements, when possib
le, as well as the higher layers data.</t>
<figure anchor="Fig--MAC">
<name>Example of User Plane Packet Encapsulation for Two Transport Blo
cks</name>
<artwork><![CDATA[
<Max. 1600 bytes> <Max. 1600 bytes>
+---+ +---+ +------+ +---+ +---+ +------+
Application |AP1| |AP1| | AP2 | Application |AP1| |AP1| | AP2 |
(IP/non-IP) |PDU| |PDU| | PDU | (IP/Non-IP) |PDU| |PDU| | PDU |
+---+ +---+ +------+ +---+ +---+ +------+
| | | | | | | | | | | |
PDCP +--------+ +-------- +-----------+ PDCP +--------+ +-------- +-----------+
|PDCP|AP1| |PDCP|AP1| |PDCP| AP2 | |PDCP|AP1| |PDCP|AP1| |PDCP| AP2 |
|Head|PDU| |Head|PDU| |Head| PDU | |Head|PDU| |Head|PDU| |Head| PDU |
+--------+ +--------+ +--------+--\ +--------+ +--------+ +--------+--\
| | | | | | | | |\ `--------\ | | | | | | | | |\ `--------\
+---------------------------+ | |(1)| `-------\(2)\ +---------------------------+ | |(1)| `-------\(2)\
RLC |RLC |PDCP|AP1|RLC |PDCP|AP1| +-------------+ +----|---+ RLC |RLC |PDCP|AP1|RLC |PDCP|AP1| +-------------+ +----|---+
|Head|Head|PDU|Head|Head|PDU| |RLC |PDCP|AP2| |RLC |AP2| |Head|Head|PDU|Head|Head|PDU| |RLC |PDCP|AP2| |RLC |AP2|
skipping to change at line 682 skipping to change at line 791
| | | | || | | / / | | | | || | | / /
+------------------------------------------+ +-----------+---+ +------------------------------------------+ +-----------+---+
MAC |MAC|RLC|PDCP|AP1|RLC|PDCP|AP1|RLC|PDCP|AP2| |MAC|RLC|AP2|Pad| MAC |MAC|RLC|PDCP|AP1|RLC|PDCP|AP1|RLC|PDCP|AP2| |MAC|RLC|AP2|Pad|
|Hea|Hea|Hea |PDU|Hea|Hea |PDU|Hea|Hea |PDU| |Hea|Hea|PDU|din| |Hea|Hea|Hea |PDU|Hea|Hea |PDU|Hea|Hea |PDU| |Hea|Hea|PDU|din|
|der|der|der | |der|der | |der|der | | |der|der| |g | |der|der|der | |der|der | |der|der | | |der|der| |g |
+------------------------------------------+ +-----------+---+ +------------------------------------------+ +-----------+---+
TB1 TB2 TB1 TB2
(1) Segment One (1) Segment One
(2) Segment Two (2) Segment Two
]]></artwork>
]]></artwork></figure> </figure>
</section>
</section> </section>
</section> <section anchor="AppendixB">
<section anchor="AppendixB"><name>NB-IoT Data over NAS (DoNAS)</name> <name>NB-IoT Data over NAS (DoNAS)</name>
<t>The Access Stratum (AS) protocol stack used by DoNAS is specific because the <t>The Access Stratum (AS) protocol stack used by DoNAS is specific becaus
radio network still needs to establish the security associations and reduce the e the radio network still needs to establish the security associations and reduc
protocol overhead, so the PDCP (Packet Data Convergence Protocol) is bypassed un e the protocol overhead so that the PDCP is bypassed until the AS security is ac
til AS security is activated. RLC (Radio Link Control protocol) uses, by default tivated. By default, RLC uses the AM. However, depending on the network's featur
, the AM mode, but depending on the network's features and the terminal, it may es and the terminal, RLC may change to other modes by the network operator. For
change to other modes by the network operator. For example, the transparent mode example, the TM does not add any header nor process the payload to reduce the ov
does not add any header or process the payload to reduce the overhead, but the erhead, but the MTU would be limited by the TB used to transmit the data, which
MTU would be limited by the transport block used to transmit the data, which is is a couple of thousand bits maximum. If UM (only terminals compatible with 3GPP
a couple of thousand bits maximum. If UM (only Release 15 compatible terminals) Release 15 <xref target="R15-3GPP"/>) is used, the RLC mechanisms of reliabilit
is used, the RLC mechanisms of reliability are disabled, and only the reliabilit y are disabled, and only the reliability provided by the MAC layer by HARQ is av
y provided by the MAC layer by HARQ is available. In this case, the protocol ove ailable. In this case, the protocol overhead might be smaller than the AM case b
rhead might be smaller than the AM case because of the lack of status reporting ecause of the lack of status reporting, but the overhead would have the same sup
but with the same support for segmentation up to 1600 bytes. NAS packets are enc port for segmentation up to 1600 bytes. NAS packets are encapsulated within an R
apsulated within an RRC (Radio Resource Control) <xref target="TS36331"/> messag RC <xref target="TS36331"/> message.</t>
e.</t> <t>Depending on the data type indication signaled (IP or Non-IP data), the netwo
rk allocates an IP address or establishes a direct forwarding path. DoNAS is reg
<t>Depending on the data type indication signaled (IP or non-IP data), the netwo ulated under rate control upon previous agreement, meaning that a maximum number
rk allocates an IP address or establishes a direct forwarding path. DoNAS is reg of bits per unit of time is agreed upon per device subscription beforehand and
ulated under rate control upon previous agreement, meaning that a maximum number configured in the device. The use of DoNAS is typically expected when a terminal
of bits per unit of time is agreed upon per device subscription beforehand and in a power-saving state requires a short transmission and is receiving an ackno
configured in the device. The use of DoNAS is typically expected when a terminal wledgment or short feedback from the network.
in a power-saving state requires a short transmission and receiving an acknowle Depending on the size of buffered data to be transmitted, the UE might be instru
dgment or short feedback from the network. Depending on the size of buffered dat cted to deploy the connected mode transmissions instead, limiting and controllin
a to transmit, the UE might be instructed to deploy the connected mode transmiss g the DoNAS transmissions to predefined thresholds and a good resource optimizat
ions instead, limiting and controlling the DoNAS transmissions to predefined thr ion balance for the terminal and the network. The support for mobility of DoNAS
esholds and a good resource optimization balance for the terminal the network. T is present but produces additional overhead.</t>
he support for mobility of DoNAS is present but produces additional overhead.</t <figure anchor="Fig--DONAS">
> <name>DoNAS Transmission Sequence from an Uplink Initiated Access</name>
<artwork><![CDATA[
<figure title="DoNAS transmission sequence from an Uplink initiated access" anch +--------+ +--------+ +--------+
or="Fig--DONAS"><artwork><![CDATA[ | | | | | | +-----------------+
+--------+ +--------+ +--------+ | UE | | C-BS | | C-SGN | |Roaming Scenarios|
| | | | | | +-----------------+ +----|---+ +--------+ +--------+ | +--------+ |
| UE | | C-BS | | C-SGN | |Roaming Scenarios| | | | | | | |
+----|---+ +--------+ +--------+ | +--------+ | +----------------|------------|+ | | P-GW | |
| | | | | | | | Attach | | +--------+ |
+----------------|------------|+ | | P-GW | | +------------------------------+ | | |
| Attach | | +--------+ | | | | | | |
+------------------------------+ | | | +------|------------|--------+ | | | |
| | | | | | |RRC connection establishment| | | | |
+------|------------|--------+ | | | | |with NAS PDU transmission | | | | |
|RRC Connection Establishment| | | | | |& Ack Rsp | | | | |
|with NAS PDU transmission | | | | | +----------------------------+ | | | |
|& Ack Rsp | | | | | | | | | | |
+----------------------------+ | | | | | |Initial UE | | | |
| | | | | | | |message | | | |
| |Initial UE | | | | | |----------->| | | |
| |message | | | | | | | | | |
| |----------->| | | | | | +---------------------+| | |
| | | | | | | | |Checks Integrity || | |
| | +---------------------+| | | | | |protection, decrypts || | |
| | |Checks Integrity || | | | | |data || | |
| | |protection, decrypts || | | | | +---------------------+| | |
| | |data || | | | | | Small data packet |
| | +---------------------+| | | | | |------------------------------->
| | | Small data packet | | | | Small data packet |
| | |-------------------------------> | | |<-------------------------------
| | | Small data packet | | | +----------|---------+ | | |
| | |<------------------------------- | | Integrity protection,| | | |
| | +----------|---------+ | | | | | encrypts data | | | |
| | Integrity protection,| | | | | | +--------------------+ | | |
| | encrypts data | | | | | | | | | |
| | +--------------------+ | | | | |Downlink NAS| | | |
| | | | | | | |message | | | |
| |Downlink NAS| | | | | |<-----------| | | |
| |message | | | | +-----------------------+ | | | |
| |<-----------| | | | |Small data delivery, | | | | |
+-----------------------+ | | | | |RRC connection release | | | | |
|Small Data Delivery, | | | | | +-----------------------+ | | | |
|RRC connection release | | | | | | |
+-----------------------+ | | | | | |
| | +-----------------+
| | ]]></artwork>
+-----------------+ </figure>
<figure anchor="Fig--ProtocolArchi5">
]]></artwork></figure> <name>Example of User Plane Packet Encapsulation for Data over NAS</name
>
<figure title="Example of User Plane packet encapsulation for Data over NAS" anc <artwork><![CDATA[
hor="Fig--ProtocolArchi5"><artwork><![CDATA[
+---+ +---+ +---+ +----+ +---+ +---+ +---+ +----+
Application |AP1| |AP1| |AP2| |AP2 | Application |AP1| |AP1| |AP2| |AP2 |
(IP/non-IP) |PDU| |PDU| |PDU| ............... |PDU | (IP/Non-IP) |PDU| |PDU| |PDU| ............... |PDU |
+---+ +---+ +---+ +----+ +---+ +---+ +---+ +----+
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| |/ / | \ | | | |/ / | \ | |
NAS /RRC +--------+---|---+----+ +---------+ NAS /RRC +--------+---|---+----+ +---------+
|NAS/|AP1|AP1|AP2|NAS/| |NAS/|AP2 | |NAS/|AP1|AP1|AP2|NAS/| |NAS/|AP2 |
|RRC |PDU|PDU|PDU|RRC | |RRC |PDU | |RRC |PDU|PDU|PDU|RRC | |RRC |PDU |
+--------+-|-+---+----+ +---------| +--------+-|-+---+----+ +---------|
skipping to change at line 774 skipping to change at line 884
| | | \ | +------------+ | | | \ | +------------+
| | LCID1 | \ | | / | | LCID1 | \ | | /
| | | \ \ | | | | | \ \ | |
| | | \ \ | | | | | \ \ | |
| | | \ \ \ | | | | \ \ \ |
+----+----+----------++-----|----+---------++----+---------|---+ +----+----+----------++-----|----+---------++----+---------|---+
MAC |MAC |RLC | RLC ||MAC |RLC | RLC ||MAC | RLC |Pad| MAC |MAC |RLC | RLC ||MAC |RLC | RLC ||MAC | RLC |Pad|
|Head|Head| PAYLOAD ||Head |Head| PAYLOAD ||Head| PDU | | |Head|Head| PAYLOAD ||Head |Head| PAYLOAD ||Head| PDU | |
+----+----+----------++-----+----+---------++----+---------+---+ +----+----+----------++-----+----+---------++----+---------+---+
TB1 TB2 TB3 TB1 TB2 TB3
]]></artwork>
]]></artwork></figure> </figure>
</section>
</section> <section anchor="acknowledgements" numbered="false">
<section anchor="acknowledgements"><name>Acknowledgements</name> <name>Acknowledgements</name>
<t>The authors would like to thank (in alphabetic order): <contact
<t>The authors would like to thank (in alphabetic order): Carles Gomez, Antti Ra fullname="Carles Gomez"/>, <contact fullname="Antti Ratilainen"/>,
tilainen, Tuomas Tirronen, Pascal Thubert, Éric Vyncke.</t> <contact fullname="Pascal Thubert"/>, <contact fullname="Tuomas
Tirronen"/>, and <contact fullname="Éric Vyncke"/>.</t>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIADLdmmMAA+197XbbxrbYfz7FNF69piKSkijbcXxOsy5NybZ6LJkRqePk
1q0vSA5J1CTAA4CSFTP937fos7Qv1v01XwAoy4lzzzq9ZVYsYgjMzN6zZ3/v
QbvdbuRFlEzfR8s00c9UkW10I15n9C0vuoeH3x92G9N0kkQr+HmaRbOiHeti
1l6ub6KknU8Wk3Z6rbN2Mo7Ton30uBFlOnqmzpJCZ4kuGjfzZ+r14G3vQr1N
sw9xMlcvs3Szbny4cTe1T7DfxiQqnqm8mDbyzXgV53mcJsXtGoY9Ox29aKzj
Zw2l8ttVpmf5M/XwVucPsSHNilJLkcWTwl1P0tU68huKdGIuGkVcLGGEYREV
8UT1YUT9sVCvdDTVGVyu1pmmiSgEUl1EWZbejAFhdu4qnanRAuDKG9F4nOlr
A+6w/6qvLp63z9IRIYEQVkJCtCkWafas0VZxAhCcdtRltEpzmCPj+3Q6jzLb
lmbQzSkAl+dpwoBqDXC9irM8WkZJEWt1dIQQx8XtM3XYfdQ9VP85za6jvKX+
EmcfPqTJZrWKCSebpMjgphdxAk9OoUmvonj5TGkcspPhkP+sZawOoNDMsddR
53ESjTdZaqfZSyK/kebZm3xYxqk3y6Oj4+96qnetk41WU52r/iJarXP1HMaf
5HbWx48fHx2qvsZx20N9Hc8TDZdT/TGYdgYPaTfrKIn+OYIROzBkkmYrWM1r
jfRy+aLfPTr6Xr4+Pfrukfn6Xdd+fQpflWrEyaz06OPvvn9sbjr+7gncpODq
+OVgcHlEPyhlllDRh0DH3+laiGu00Oo8HcdLrZ5naTQl+hnitouyKd04jQq4
r3t49D0/F2VzRNmiKNb5s4ODm5ubzvF8ve5A9weZXuoo17jVlBpddo+/6x7e
eyrDYjO9VUDOUTZZxIWeFJtMK50sEJ0rnRS5AhwAvpfLzRJIr4bKg/k+/vx8
Z8X6YLjWk/yAxrzWB93j9zmQls7hWwdmf0AwtKeHh51f4jVCNTw+Pup27w+V
nmwyoB4V5TAQwACzhb27Ajh7gzMklpW+gY2nmn24frFHMGInCmilWIyBqqZ4
Zwm4p/cDrgTdsYXu+LgDUBwQLO3ZsYXu8vjJcffo3tCdXqfLaz1VVwl0jztd
jXQGbAnYHHy/jKZxCrttAjtGNU/bV6PL3t6f1LmexpuVaUe+lqVL1Tzv9ffU
OkuBBcIlYiuexcB3Y2IoHuxPfsvCHj+xoD/pAIgHBGh72vUWFlruv7C/CXRu
fh0nHxzcl6/vCfc91/xOuLsENyz54ZEHN3T+x8L9enSq1ovbHOBaqmV0q7M/
qZc60RlcAr+dZPH6j4AXOjkg6NqzI0fi3UfHfzS8v5fE78Fra7Z395FlXo86
AOMBQdqePXWwtw8PWbbUwv4m0efdcx96xMZ74rQ3rB0E8+we1s4TptYBlW3V
XdFM8cn/2D0EuOfA7Vb64O0ZTOP4uwOZTrsySPuvj94fvz/snLzp/wQjvDnv
HR4dkYijz87pn/f8uQubnepZnMSIYxYgl6fD0WyzVBe6IMb7Jcw1XetkReIy
Wi5jFEy+3DvArt9Dv9Dlex794K9H7w/b2CdC0O4dwBzbo2G7eme7dGdnPZ3R
9uw+Ojx8em9yFWGeEV3GiNNZNNG859RxSHOdryFTAqKDmR7QfNuzxyFjPf5j
N9wANCxQBU6iIsLtBg/ONayOGpjN1hyc9Ad7f7RYOSb2elwWK8d/MLvh5kud
p5sMgHai5bKPuPl6suVO6I9JqB4Dw3nshEsXpM39hWqtZmQ1oos7NKJu93er
ezDRA5pue/aEl6/RaLfbKhoD9sFKazRAzcwVWJwbVEdFcI3BXPi8iYZqNUA0
xwcJ/aqJRliJIMEWAnVeof5PT9AFWAAtNBTHYMXQkzdxsVAFKO7H2VSkKLUP
oqyAi3wRr3HN/zuom6qJiNujzvCJO41E1WSTcK9ThnQR5QqYpVrDCHkHxYSy
lgyYrALELQ2xyTV2SSYmG6bUaQcssSlo91pZUyZNomVL3SziyUJlGiCEsaY5
WM0rra6j5QYQG8945cE8LWBTwFDYPfUNFl881ThknAUmQ96RdVvF0+lSNxoP
ENYsnW4mhKZPD/zLX6urCuIChkZY8olOoixOc5ilzmiwe671rG6tP30S4+7X
X+kmvn7K19B9vomLaAzcmyj+ixb3fgvr6R4FMEzE1FnCpIRYtlRCd6uEBSQQ
5YKBnHhA6hkQbQwQLm/VOKNR7MCTNElgfvE12j2wZtjnCZjLE92+gu2mTv+2
ideE7CY0t69O91p0Dwut5uXLt2198ZwBk0kACNB6fn66p+aw42+iW5iWmW9v
vV7KDgJ7KwOi66hdW5WWEOkHaBkYDMwYKG6zXgNrQd9Hzqs7kdWtAby6ukTl
Ht58YqxspSjP4QtoIptkwlsAkYQLLk+nQvKiU6ijxwoIRez6X3+F3QdDZTdx
rhlpNE/9ETEQ42LgKKTrpHifQiGClw/DEe/e4oBalYsTACzwabtI2/DH7geD
T8TYIr0BnIB96y3CapMXbqda/BBc680Y7lNAB0gQzBYCluDtugiYfUEj0KOT
dLOc+hxAdn9I1YZkkA08YGVAMIJLd+K0QUSBVh/0rYLbgfF8c341HH3T4r/q
4g19vzz98ers8vQEvw9f9V6/tl8acsfw1Zur1yfum3uy/wYI9uKEH4ZWFTQ1
vjnv/fwNU/E3bwajszcXvdffMFQBxWTEY8ea1TkgRGSFUd4wRI34U8/7g//9
v44eAan8B/ErAVPhC/QswQWwsIRHSxOgE74EBN42YOl0lGEvoNWqSbQGNrRE
IoCtAchPFDI/QOe3/wUx81+fqT+PJ+ujRz9IAwIcNBqcBY2Es2pL5WFGYk1T
zTAWm0F7CdPhfHs/B9cG714jkQ0oXas4SZfp/La8U25iQNIsXS6BLHkDZqtc
xAYthcfmW+76+LsneG141qdP4h+DLQ2YVX3A+nIZZbfqJfM32Bm0FNwoTE+B
Mh/D/oUrWBsdrZaoCCJdzEVOjPUkwh0S85a+QRmJbu8SU15k6Wa+UBPjTMNp
wTa6jtH76R6KWNOEjiL8+SOxc2YsU2LoOWxH5AKvexeAiMmCUAb6lGo+H7XU
27j9Im6pf4nnYw3sCpgcPZt39hBi5Hang2HHc+lhiyjAotEPb/NCrzrqrFAx
ziLkmzCbeIXzZtksjBx5aL5CWp6iPQDKW5LPcFgYlQVOR+SRaqtQItEt6UUP
ZkW2BGswYJ2Jzj2EzorNCm87HfQ75dn2PSQDXClsXSPADF9HV0hOQNF8TlGF
v+h8id4vhmtHWmWNvHFgiPYYZMfUH+hV7/LHjnp1C8Ia1OdNka5I0l1q2PsF
/Pkb6FsE/qshAP8KlbDhZswcJrNi1SwDIhaHALRHJPCLCBQy5M0ZiJqcHySf
Dt2K+2Cy3EyRVGhNEq2nMD+Ue2RP42KuoiSaa7MKZ6CPTKcodWHUwfUTpB74
+8i04lhTuvHtX9rD/umLDisgJooxZAGDGyuiAZAqTz+u0xzdyi+EjAxE2Bnu
1SyNVqQHGBnUwp0ENyxTkG18D1LaX+M8xsvB6/ML2jwozzQ7GIhNm+3m6+s4
S1wf/E4IxqcRhNfdjnqNFnq7awZghcxXa2kihEX4ft7rg63wuk9jo2nLFj4y
BeQtoBGBvI4/9pC7QP/9sxMYAXYm+t/6iwjmtlTYdsYa0VJ+mshPsJYFejfM
bCcp0uI6TWgFYXA1PLnCnuFrZ4e3y0jlFukURJddfIQ2V/2WMqaCr82S6SBb
h4JXls2A4klEnjLGcGMFoYPxpmDcA8XEolukQJOr+BfmlbhYpLAlU2FjkT80
OewzAGyW4e5IJrc0R9BD+8OXsGWNA0kYNvASYmlEeBhGk+aLdKq9B9/WPmg4
YOlhIk9g1cjuSfFMs5sIdRWxtDLeTWviPrll6/hryBbMBEAm1o1/bvbgud2D
6hS0JuRiPVD26SuSJhAIGNi4mEAp0yVO1e5foRXhsDLgoB5g319T+pVGdJ6r
MfyqNS8xteIy2i0Fyi+3lOBkhlAdt8IVbut4ArB2MHCnbIhp87vh4IbTigqL
UtpxGJBIaLkhyQc6MfHgi7OTE6Z94G4E+4leIr8nysJt3Pm8JyvcTcRC1ICV
6tdII+IBtFKi77kO4LGbGC0LoAw0uDeJUdkFGIxPgaiEXTW+RSNAvBOwb9AQ
TTOe51XHTYcmClKrwG3qUaPH8dmKyllWkDqLEnkVF8hBzfoSjREGhYgjy0Fw
UOB1HT98sgMdYjuaW93Ca5GvuBsV/P4chddQLDgrxIBv8d5iAkYmZ0lmJ6BN
QMgeMIl0pRbxHHUj9raa6Yt0AYSCyljzK2tX0e0yjaayicCoQb0bOiZvBiik
Yh32PAbH9ss9Lf+AMy5oSLRql/ojRsE3YqwitwGKRDIAwR0TKQArgB2VM4Cu
TbTFLCceNYmQhGAOhJjrOPLvjIoFyFEdTRa8cd1PyE6iCcw6zkEZyUn4kToN
ECBIoIkWC1CaJx+S9Gapp2R1i+W/FIGJEzZ7mSWxs80BeZ8+vYjnAFybUAd2
EJo0OdtYPlJano+nzDfuiDnXsnv2VqCU2DMSR+OGa5MWgXdbao+TMqY66gVx
nQhXBy1xZqgioXB6eBuyphVTVd2MdzN050lh/4ERS4zUcj938GnuCPj7Hmhu
YKHAbZFaAqy0q83imb3OzhOiIVDi9Q1MHITaATFM9AoWi3ST4wxMOxqpsHy9
hM0NYsexOO6cHlbjckFtrQ4l92H9DBMKj71Wgz2TOQbwNRjMJAfI7OJ+fO9U
WQTY5bXySdxgVks3/JQyMN6Atmb4dk8CS6r55ryHPkOJfonPEDtB/+s57KY4
Ic+A+drk8N0e2ZYUWYNn2C7lsUP3eQfvY/+8vS/cEiT+WP2zbvlZ1S1f6ldc
m5Io4XWdl1MhsIcv6hpVfN65k8j4v2gzQAsbfPikM/qE7BjJK7BQrPmYG23F
rDfJJd98447ZZUTrfZ4C70/R1Qlk+T/o02gotd9ut/dV8MEm/ux7l/tw8xb6
2qp3/s1b+X0fvsGfLdpf2Mpxzi3sfPj+Lnhgi7Omv2HvMpVteDPudbV99/59
wzV7/R1447/jQS1I78xPB1tl+t1W4WnTvC9xTm3l30kThSYHCDajgMZbwjtp
EbYOc/48Dsw83tXNwwHrQXjgA2vu9DFTfebAb35n5u7Wx19Yf4IHQX/wH7JT
BIW7QJi2not6a/Gmyg/yF/w2oAVmWNn2ViU0eg868D431dKDdYjzbzBSbNcN
HqE37J749Ew98EUux/b+08NAd/bZzMNfScMhGTPypYVvCoeKTylCASzGGAWe
t9rZRxH5mNts1cVzdB6BKPUtCxQvYmJZDgGsFXTCGYHSMuohi8kV8wJ2OpGP
xXuOpJheRNdxitoR8h436AZFSFk74qlbZduqhi1nZUEb2nNalB8rYNDIReWL
+B05v2oxYExdo+YTJyWQorxgRuo95/vyyVlse8/927DnDmuhNn4HopnW63x0
BVD/QtL46PjxU5brjA2O8xhScIowKQ/C1EntyElvsvGDKM58RxJ3Y53/eBta
Gi1cuKMnh4c8ZEtcImQQtAc26oOhlFegj8NTEn2qA8EIFpxBqqLrNC5Hf4RI
DTRjmPkYFZrpRhuhb3R7sOOyW3aKEWqaq82yiEHLQ2F09MSFaT2HxSQ19hJ7
NgVISxiAf5qsCdcQxoxWlEzJAT3nTCsG07p8A3ettbdLm4AWLNNAPiJuYz+U
auK8znZLRVttGUtM1ErDSNDvl0s4Q+i9oswZUCoxKjA3YKBZrK3/g/SAPIw3
747EvYgzQ+xMO4FuSup/QC3or3ceDbs6Ahltu02uXUjR903HFIceAk3hIjia
zgPj1054YpxmyA2w42iZe8FuDNZwsMGf8Tz1d4eo9egndR6QIUFz8uaiN6RA
A6wmzvgm9bCHmg8Ndw0TZ58sBvQqHkjWeNOCWYILWXIML8ods7Z+GrMrYqQw
tsA55gT0e42+HQBrvSkMAYRxQGPZk8KXszOVLAJchjiDnizsXrZBjXMFtPqz
k5M95flkEcZCYYS1UJu12ahGK7fzBovTksRp9xR5RqiB1q07I/Q6ipcUzBfY
fJ7KHoDAX3ZHMDun2apxln6Ap8xgOH9i29O5ddOW598xLjifKCwBBlTJxg7O
PGEMwl0Y4m+J3YktG/QN4wX0hgr7BBhjbmMCSEFgIeUxAk07PAHFH5E8jya3
Nl5Eoo7QBqars2ndqJ61qCP2fO8CD4ih9kFgWORvMrEq4ypwfNTJXzJJhZBB
DXmAWUaS2YI5Fx3mQS4mPcVNh7tglU5Nzkt1q8gegonHBbna1iATyHURy/6R
IB15YoL5GaMFJ/PgnpT96QFSp0xVSNywV8csw7ScO7rznIEEG4tt/K3yE/B+
ovIKczKDGQIzORTOZ1HZETyMfSDCaCbQDc3N8xQaZod0vXvX4BKUn2BDb+cj
jtbbTOt5mdJhRikxaFbE8iAzJJ2AfQsaGUnLABmtQEWgADJSEJi1QKaFmRAD
7kLE5n5LccQzTWqKxystk/RmUxHcwehFpqNA0wJQLoJ9T7MQ3COdGg5J+4ky
r3AjY3oG0Tk1l/Iw9JL8Ti3YbKBbYW6K5ddC8EzjQuSnRokYLKMJcRkiUyA6
k6SEYsttRF4rIkoP7lZJI0GOZmJ30XKV5gXFi9K1YSo0VyFw1hqCSLml9xjd
caSGeMknVtuJrCJYn4ykQwZqE2kwshRnWnzjOyiZHKvihzF7SNaNcASDnw18
6VZQ9gLBPPY41MSLRwMxz6qblqyTYLcY+E0c1OfwmyJeoh4bJXaTEJ1IvN3P
teIt7e9HfzJ3ZnL1QLC0BEbGoCQCAXPQOSbMxfnCQVqDv3gGA83TIiaM2NiR
1ZIaznhtNErOG/j8tONTbwrvN7YMtLOwy/eq2mb72LaxbfJm3JNuf/qps+PD
v8Bd3+LQ5rFtGYq6CezLr/SbuGMCKAI/QV0PW8TevhvHOWcYiqAHAy1R4mXv
Qv1TMIef7Jzg8upksLuH/pvLU3VxOnr75vIvVWRW5/C667reiYd2CMVuPNQh
YguUObq6uDh9fXbxcp9RvhMPqo4eynMQPJwNuId6mqzMw2+sQDF49bM/1P4u
sg7mBMPxc3VzuNfHm4Myqu4Xffz9jJ96T9R9PswNyn6qdptEiDipTsm7AbJo
6qf0dkpCZQ0SCjkJWmUihkSbKilSROwSeMjZz4XyznkhyIz6Henjnx70yUX1
qzHtnHw87/3sDMiaRNaJi4OU0qjKehyl3wgPp2Q16rJvFRFACpg+v5iI26jW
2iGHhcmrDrJs/4RfckqxACWhZe1h7HwaYwbUeEMdUbLhmFIb0oxcQKKVeKM9
zINgTEuBzbCI1rkIKzFlKiGCXKzAST1QLIQa1bnnRke6pSCYcQfksLwVk6ki
UzkuvASplNlQSyAvrb3isH65WZJnAWOExqSKJhRT5KBuOWUQzddrKrTL8FGY
ZjFh+TelTDPJ3LB9cSJgKXBNt5s78jydlETp3KRunOsoAVMSA5c5aUxulogf
0mCBAqeaVRTtD0aOp/gjKTdmfxDgCDNmKzVCW4wshOltEq0wd2mJuhqrUHj/
2Qn72Iw27tOUybkIA61WRQjUFD+Fgzf8ZJGmkiwEc59hzK5CkHg2ACmYnjLt
b4mpXi/TW8xfCxzeQXYS4kvUQ7YY0asYFlGWolzWuCMPocuaBRgnWotr0fol
ks1qzF4IDbbwhCzecVxYa5v9nqAv2zFHz73H0biW0HaFaYSGHO98oiM/BsC6
Ofpo27DR5kAL+Ngmb5kyj2ASo+fMGFbRx3i1WQVczfqZuwQAFqh4xsqC3KAr
pAKT8SCKvqHMZr5B30ft9tlTq3i+KOxKeK5ZQhbMleGjEa+BLrXkIVjnrldp
gHlTlCLSLieBeBTBpEpxB0cJY+35w2Aa8wxXlD0ieI8lRRiZCD0JmScvieyM
WayXU0YbUVmUzDU7QhiDLQA3x+kDRYNZ80hYB3rAE/W0DbdwgQ5bLTekjd9S
n8xFu4+fmEcos4YteWImlmUYZ04uSRt6lStAMWy/CEaP8pT9Cma9OTYAnIzT
9iJZvID3XfRGnUYvCUsRhCujkyWbA8oZBS0KnECP+YJmjxIIs1loakiTimiS
7D1Buf6IUWsdKAZYcxdPN1rcgjBdEBw4XdgqhF72EnbtxpIFWGpkhLSrn/Bv
bmPRIQc1Q1gRcN776f2g1//L6ej98OxfTm0Rjy/9w83iZcPvCMxAE+YcVCRQ
0y93yfdM9hYJDvHc3SzSpQ4z4+JkhnElSStSTbL1sCdyu++1nBfZ+eLFf1xy
5bGflWAP9B9oGcgUZV2B0hIfoMRwPHbRBsrTzGb6DS3YBADZv35CkQ2ESLJM
2gbEl3pbYWoKaltokCaUuwabZp3GSYGRMvriWec55iUCAqE/zMNrhdEeJkOR
N4htV+Ux1lhywCnTHjMjZ1QVQzStnFyk82U6xroak7iSYzgSN8yP6dDFqBib
ujPvIDPSnOorubWADQo2KYN02sak9uCcsB+TA7REF4tI3SjL4mthIhbHYfQv
dJPNfIEcJ4Ekhgl8oD1Uw6VRvZKA23iDnl0SgzOcm42gYnkLhecW0WbprQdz
XN8/Gi6v5Viw8m1Q80+zjJZgSlvI31pYCUnZQv6S+tQk2KyLBHGismSxwA9T
3U5nM0XEmpEcC7cFjkVB5UrsFnGOmc6zYCz0gaSeA9z66oroA+amRZzgmulQ
jqsGu1/q4bd+GKC0ODNqwQet1zjShIoRCJ4yW7FOXWGcJCRMRk/9XnWDIcu/
Jv2TJMFyWYvQqpMZNgNNIoAjHEx2sRshTlynSEQSbTADps63TJnVvfAGdrZa
Iww4OpqgUyuGMZQB91urDOP80jOww6BcFMuNsASgZqMPfG2Z0SzKAA1POrfN
LSD7wVobVUZmQvQb87gEXW9NpW4N76PoHoLZarAsl0Lbmph7UF7r6el25nxv
ZpRgwxBFk7h4TmHdJfEvZkyFpO+jWY7bDpUB8SaSmJN9MDJOyefLFP29HFZl
XzgZwECMm4m2fZTV28DRPytHKxlprzx11A90+2H+R86/P4qXms102jGRGD+s
WeGtyNWeWjWTkw/M/FClXxe8kAa0MYKmQFGNQKE8EsWCs1p5LFEkjZo8Mmq7
e5jmzunBVAXGqiFMhguy4ZmbNNROWUr5bLCeuEo2HZpe4Zq4TAsUAggEJdMf
PmI4pEDD6J+M6/esZPnzaTmG7a+/mAqk+dLu4gq+HI8j+NZuSFSBj1RbHbMa
TL+djKI5NEIDX7/oXwS/v+Ufd4M1judWQSmDA8v0B4GTG3ieAjxHh1WAYKZd
r7UKVhdvOXawvT27OHnzlnROnEb3v120j0oikM31/rBSJAnbHqQuZ/T4tZKG
VzztdDvHBriggFIE41Inc0zvMnSB973u4pl1UxoUlWJg7O8vT3+sEctI9Kzy
B/Y87j0seZprjp/x1nNVRb5tjokcsYgR0hh8C9LVUmjJ5aqWHxo+RVMfUCXA
EFnzObJQwxPO0JKklpPLnwzLnaMyk1AddDorRB0S++eGxPdm3ULH1C1/o3Q3
1GMjAA6EMu900XDY82Oi3yvOe2PpQgw1AunJHHGJyRE43K2OKJGNBPzRYedx
5+jJccSlrXI+DebV23hzZCxKYQSSbBOvkI9jpJE29gV2AOp3Joe7pTPycLgs
fEAoN18YC/IIcLAh/gAEjV+FiZ0lkYnXjXAUl6oTqDPyI6YegWz2i8dyzQYm
VVs8wAMj/EQUkwcQ+le5jmBXcbrAHpf0NonqX5Wj8TRZQhOquerTA05AajRO
yC9ABY3BzZm7mcu5aXjjpVhLCJUTDHzHQSlGG+ZLkxzwVO76xCc5XIE7kGR7
lwIjnikuF+RQoRVS5pSFqS2tJQPSVSTZCCY5ULB0wSX6ZXK8jclJo9w8KfjF
EWy2iPHmeJp3K6gKaRkvCe7XxBPgJY9wzkYHaPPR2jy50lHClq/EayX9kxhe
1SFmZge0xP6PiquQgXPcRaL11jlnxL9RQ53+sCYewrmtmL2HO3pC4gPPq4E2
whQMjHP2Iszlvuvy0aI4EyvQKrk5LBL5P4A9bZaRXaZ+SuAMJwuNB1s0z/vD
vQ4LQYKepKBqjp7vlfC7wHMHbNy85NmEuYqJ2M5vk8kiSxNArIB6jQoO+nyh
YVTe4FykgyZQczQ6g6mcYuFReT6s4zhGCLPm/LYQOYG/02CKiQWrYHmuWG9B
xwmW9NvSmPnDcr2TOOXcVuY9xYcuEHvFAJUpdaMU6GMYg3TR2ITq73v0FZVk
4OlUKFXrKun4JEJzWxdvu7uyVw6088B3xDkwy/naoIjPGcQUutGiVKOs5jEW
T5NbY6oLQLk5+4N5s3WTdhrl0ot7hSSDGymN/mxwwJZaEHmtfva9G3/Yr4wZ
RFnD9uqYXKftPbEvLVv1cjTYXrnQLFy2r7AbHnNron3KwLkvLVt77f9RNp5v
Pr9z4lhoHk6cW7ZXJ4MDsHbtxOVafQVk4fYKx+SWrQT07ZgS3/8aY5Zi5LhA
HP2Wv/th844x1Y4x6wjR+/TbV5uglMR8hkdEDF7Dy5gerQ2nm+xk/2PSr4MB
HQuohMRDjmNi47u0FYxrfy6Nyz1BA44WdUmTIs1Be0/HeIJQTSC8efnGnqSF
JyAD7xD54Q5BqKS+BYNQ0JCUqp2RcRvnz0GaL6MM1StJdiP5qcX1hA44OruN
K1lB5c0DT2d4tpuYDbhzTEScip11oD2xQs6SI2LJRAWlo/O9lrpKXCUsC2L4
5Qp/Qbbbq/7WO9+T4je8RA3bBoyCcudyBrMoi3auoP2es55J9pP2/I+e04rs
FSxhPEcV/eocvYpgSrj7IlMg7JIJQpSEzsjQgbBJSEk0RkUZReRJtCMTGlu7
/P944AeqmtAfOpHpzGsXLZVQVUe9JWhycYU7t1+rrK7bDE2uZly6RAAErTpT
W3cSz8qpkzZ868eC2cfCZxsK7UkI02Zp10Ap3h5SO/ERWMLAGmLfXSIEIDUS
u82T6pEdqnnRG2IOCtcXhOnH5LnL2YDDQ/Jhd89hg9jSKrNLJPVSihcmqMDc
5lSsubzdUaxVMktsRYuJKdDZSnj0rVE2gmADsxiy9014PswIdaaVyTj4ECdU
mU8BBculapJInB+RQpxmLbl8w/cjY4SMM17EVfC3TWS4DmZjYGUVm1nBkuFc
ElQOgXXcdT6RatIhRnuKYomstQE/puPqd5eyN/t0VIA5KsEUYbGB0zwdDPdC
qqQtRwMFdTI2iRQYatvP0HQFwGh+AR9ex/P57ZhUXkLCZs3bCSEDRT8VNyul
4pgfV7hp59p5fbFYxoVbzM+0EhONSQ2g5gPKWL92bhkxULXwIEOAwB/RXGMA
6Eavaov8aYVHUJQITYElQgMfjXFSjp4xoWBKCNMzmTFTE6FuAmORQIBkJu2F
GdvonZlEfASMdywSuUktdtmawTxrc0gMM+Zi0Wnw3MgjNEfLDcan1HOg9MKV
Hm3WlEagr+N0k3OCAadvByZvZIPKJUsJEEceG9pFaIbFuclS4J5tKlB4PBSH
CheUIcNWOVdc2qowfkiWybe2kccyaLS/IpP2vOQVIfO4nUfX5lxH7bKtI7Sx
wC4LNhcFqJlmmKqCUycQ3fzQDGAioi2TQ83SG58tRyW1iL/AnPd2DqeaiHbC
UQfyiOgpM+uQ2eAhTVTvSK4rI19lOZcmPM8YqrApSsJiNyzqIAAZOZJxFdQ8
TafW3RImJY3xZR4T59qzKC8VLUjZq+ee8Y8JsgSJKhfiFj2zaz7aIQ+OaxIO
WrYZn1ub0bvZWI5mgHtUF9B9DROco8PvzPmLxtH3MN8t+azU9spXKPUPzPNk
giEf8c1LpXAYGMOwHmhTt3S8It53A7y5o57LCX4kcwFNdpBomQEqbpnroR7s
q8GUn28LB8lj5RyRVR3XOxLB+EAmHOSKMj5oN5SErerkW8b3Zz03xusocjTI
mbVJWT7rdCeQIOsNVqCmQECGM8UNHI6VQ5qInng/WOVVvJWey2C/bKaVP+4G
7879Uib12eBA7q06D/Ylb/tAbE/65qry6RIzwiVfuGSm84ca7Q3Bne4ygKW2
j5rJhe0IC+JN1d3r8ES3bNEl0T8wPop9c4m1CuKb2A2L3LENGv0M+RIs++EM
7gvL5WXfwbJPV9vh0bY3MPinC/VV5mGLFPbDS1xbtES/tb/Q1XbYHw3svXTx
deZxJz5e+/igy61i7wy3cHmBNKpq+1eah3hyTO94yU4c0yIenK1fquG3f6V5
iNNmX3YpXnKj36I8P5CZh2kv8w/5vdJiG+vm4W2OqsdneFTZQeLuqfh66vw8
yvLSctvg5VuscsLLb8lTAsx0fLuOqJZsAzx6qWCbWwU9zr0cmBFYacdPjg8P
O5VDPkJP0aPAUxRWS3ABv+cc6Z+BqV06wqFy+FCN8kJVFI2vW0VhBLRn0tPB
P2jWorhtc46dMnE5P6Wl0Tibmap3EFmg75Cqjh2bmjn/ZAkThQlCiXeVafhZ
QGHJRhBtqh56dL9CDWSTzfr3R3j6jYhe0heKNF2yU8E/IEWSzfxM5xCjVCdO
ert7hqZns3XCo9eDyo8oNwcaryKR+GUFyHNteZGOauGE7w+wBeVxJYE2COQ4
U4eymrlwALXE0FCz3dH552g8cEzfFdX6gXtCBTrIWBdzD5MRgKozqIacRU16
WUGxVJsNwt08zO1BDp1/PzUhXjoD1SbR4Yd4NjD2B8QxIfsfs1EppGSz171j
gjAmaFOLOf2HiYMDy0EOOp3ZvzaV1t9LgjFSQ/0JNIaf5KVSKkdcQG/swDOn
DhJPJsX+sXQv6azCEUyUd07sGUdkdZw9v/YkYJStiJhH/nE7Jifd1XGU4pIS
nDWp+oggNAfZDrJAcXJMEL/mWk73ooLQ4U1Oy6dPW+ro8BH80z3kyR49eiQ5
RT1m3J8+SQ0bH7cS7ELaSQGjK8WJXbqIVyriF4NI3oZccodyjDI9VpNqT/4D
sSuNKSQk8g9dWmJzbcHmNsm2ju3A1sHXrKgZgBGHCcvC/4hTS2UT76k44SQB
fg+ImPvMHmiHMRpqCvyCRbYIcKlvuO2I4H5vPYxlR/+/KObfWVGMS62gNAfE
t7edSq9wKR1WQicG4An1wXljLp+oA+plMtH+wU62qMYegcoiEuttvAo451bx
TnnjND93yHoeHmHmzsN0vLa2JOZFVY/1fE2o0aI+/dCdCFUuGLqjVkaqUeIc
10Mcci5wh1l6cnoGnQTMLlOLTvTl27cbcV4fbYKZnEJkc4tc0tSYRZPNHbPO
S5PIFsgBno/kMFNnEi4hfbGSdFVK64IJ4ilUttRA7BSX4WN0VInS3JoYjbmT
3bs8iXLf3ANuOfFwellHzFFyzHYifkn5S0FGU5jMVOJBIBMoNdDiooI+wjLz
aMvMRVvFI+laQepY647UMJbdP6ZDfFUFZm3NMImS2YzP97xUUk5Ec0fFEcJ4
8Tkz2LioieoKylC3jtNWmK1otRDh/XM8wKaUKh75fXpbwElCXP3og7YB5ioj
wOPt8M1iVFBcU2sBSK8N6TZcJLsSu8dDZ8LIuQm5uPBmmCSq3mJAAztjgcBO
0XLHrRKRrjQmIcT5Cg9ppGONy0dj80GAhQ786nG+q1wJlXVKg5CYRgZ0VMib
NFHc2JeIhFVDxsrCOpveEl/VVVc0YlgulzlLzNTXN+m0Xj5Ma20r4ijSUxN4
dcX3uOcpyO4NTwPiLfboM+8kHeqNJPBMY0KlO+EmGMGeVsbmCMBvGH1l09WZ
a3j6gEniDbFhT3Ikq7LmBv9NZXQSnVGX+Q1XA64IabhDH+WdeSatlt8EEZ4E
aV5D5pdfm3MqK/kzTF5dek2Wn3xgzmMwegJ08VRUJXemlZTT4H4lmSC6hV2s
kllBu+6BOutd9ErVkDUvLEtSvjGamAybB+6F23c+bTM2YH50glVe/5i8dcMx
tfI7/Kw/S963YfuxQwXHXHrnYpvXFGIo0Tvhn95HxLH6er/Ypwcuc5KS1X9D
AmiDcmIDH81zDZwFSKx5CbZgXDXpMTefrFQt7wU5B/pIKYsl8n/Y9SzK8ZuU
mJr1DFbqTEE6cBBbwn8ZkFPbbym/MMCA8Jzflwmd017n/J3e5+alYzLjInf8
JuGdVGk6O5ev6V7P1CmZI9UDU62C7iwi0g7D1/wJ2oYndMwsqXspgGYqs0AU
rtBatKeFhKcTC+TURb4Z8x71BjA+TQ8OMXufoVh7Vf9mw6n2W5jhlT1t8LQt
cYJZ0ABe5NmGuOVlGPSuBvfiixzfsLVhW4SyfbVVEPzXYwBWhNv7SSQ4Ha9K
oHlj5CQtkZcAx5KXqxIJFd62QguDXkAWr2F+Ni8NdqlcI4BYKSIv0cIFAr13
gi9DxB4pD4V23r2yqBs4v9g/5tHV3qLGZEW8n+LkpTfRa7Zy47DGF2OSK9Wm
IXkmiD2LpvIyElI76KVRE+TEfqXprvz/lvG7GJWqnELPJ+pI+QQCSelRRtGz
un9e2tVSn0SecToYk8pwcDu4mWTl920FfjRj5VKygmRsVJ6YYq5ZYo5b4XdN
+nLN912XmAzCgQYRHjeo2UQ1LKslr7AV94Z5SDVtihHlJRGJgLZO3qax819o
TnKxB66AWrjWWiLu1CU5loQBaKFOJ33KJzO5Y4PluAb9sUOVYMUG3SpEIHuV
V+zwaokDwptatRgoTph3i6pstXZKryQ+UpupygNYGWvMQXrdgym60bzFayjV
ZGCsTGGc7cj47VBgi2M0PGKbB7ZJPG4E2CxuAE4X8nwkPuHRtpPr3B1diUdk
oeGCJO6NkdG7bnz2hmdKSNYwSsbReXg7+4XIyWFO1zS5xXLEu3vLi+zPtIQf
SqfCDteFifPsSgwW/Z4waV/v6Gfl+GVR1aooXHhfKSRQeF4Pc1PLGRQJeXlt
mJ9DpxRH5KmLJ3zqeHjeEU4ETcJb4xvxZQCXl0jqB4lG/6SgKtczWSsG1xW6
8Y0bwYJTVZdpLsdLGHqVt9XIMFxFZV6bVNjh8TlzSqVJXYk4OOEDU7KRSLPm
WEOSBksC8i5YFXzrmvQntapBnqqrHAPcUqWxISDnB2GozDn2obkCU7fWH5Js
XDhKGaDk2/jHVhVefZ7IRHKMgvLOA2OO+aZop7M2O3zRq8AaQJ6754lod+Wr
n1W975RU5XSfwNF8dd7y+QWnP2EuGzRQ7h9wLODOuUjzgAbkRJQw/9dfNe99
CQX3beVuaZ2sWLNJhuNAlw1ft4bs/qMsZynPUNi2qW/DLTdkhn5JvwiH4qLy
suXt9vuyNF2rdGg698IthasPIF90aUPb+ECo89r8PwkHGJ1vHLzcrXTCWo3d
7r162yUIZoJDenccsL5gzW7MMSB0lu8y/oBC1BNirLP2zsO4I9qfK6Pqwfdl
m3JU2fa3PWJBIoniiKoXfIj5bPD6erhKGVwDnTJ2F0XUcTmJPeTp0RhrNiVz
nhe+9LrO3Jb9WT+ySdYlWWJOCQq9XQuvEo8pemK6azpGYNr2yswA4UC/iQk4
fbRSqfQ2uMpkOWYcp2ALo5i4obSHlBy+5A1GtaKsUMYzxxTte1tAuZjosA6T
rCsSPmWCsq+ln6CBCpPnU+nNSjDpk5/dsbEaoaDMOwh3vS430z/i63JVE9+q
i+na5Vpfy3uZLeSThZ5u5Bgid243b3VyKplUYptQG74wzIOGmBv/ZApY/INP
XE69UQ7lHG7Re6x7y8i9kBDlnS6uyPL+nz+fRx87Xtjih9qnwxcRlV5LZF8t
VT71FT/b3uBou+MKk6x6g67aNpq2YnPP/QiCbLvjCp9EObfdcbTs/eZb92Rw
FHE5PdK87KlhikLDHtvBq8Pa7dKPdWNusSeLlfBKLg2Oyk+iM8BiJbySS8FR
+ckds60mw72rjBlgyLzSy32RH98p9a+mG6+Pu6p29/0Bmkd7W9vDu2Z3713D
FLOqLWVEWjyFV6UhHHzbEPeMHouy8Cocort1o+LVLnC2pZHLnQZr5M0k+Fa+
2g+6Ly3X7k7wzdFH9solKx54/0tLw/8tvIs+7w/w/9Il34WjdIM+/NzY8sVB
pQfT9P79+3t1sa3+cuD+UA+fqQsPVyjYl4RQSnKFf3C1AxKrvQDKsDfj1QAW
l2aB62z+V4bAdly4m/EK5IF0AYq5+Z8B3n3hbsaruSlR/p24ULWf0fO6XNfw
jm6jARtYDcUee5PoBmxhez26SauneSPmzWHerHiifup71dlsAx0hWufmIIuZ
uKfLsRyqbTYuVa/irje0JXbOH//8V457lUpFgkoRPuHB5NDZQhh7PtvYq/4I
T0rMC3pviDlXzPpETWmJebcmu7ht8MKrR6x5VVqeOi9y83OBhL0vyBpmT0zT
85CWT4/Yo3y3FqJBToeSYwa5epeTUSoRAsHGw9yd92IUGaM6kQ2LWqs52sm8
Bohrq0V5rr6JNbBVrLdNfFtkIFWiRuKESjPjvPGdUTuqQRkwkxpijY9S2kiJ
EG3CbfDyJlTWTPZIzL6JjRC8e58uZb1xPIJe+gGWTZP8T17inhexNFjMabVx
WCl3xtiKizDTWZFedNnLDWGV1x3v6t0mmrhLjrHBa2hAXZrAMLp+7eteqxkB
lEQ31s7BgQetCSWR58TsKWPfy8mUgZuUzLNN4Z22hi6Hna4yTulyum6HS7XM
4Y2Z9viLRJswqTC5O99aogbHeJCMFLJ26AioXfWknrvNlpb+4fWk6v+JelL/
TDQLECBVzpK3iW1fu7ZUTjH8NywutYWlY001cpiSw8zkH7LSNMAJLuLXqzI1
2sRnFJM/6tMIta393Res2ZnnanRk7yLos13tgqqK5Kl++/nQu6BX/5quLlP2
oA1NyqCnHG7vnq6bTamt1ny562JbAU66qEAYWFHb/XIXg/bLt6UubMe9osBQ
XOkTugzqAfncaVLV3jyD6zfgoqaL/Trw/Ql8pgt+7TiKqb4LtJ8auYDMavv5
TrALkqRyKELIDMsW6s4u/gljBOoyX6vq535d3Lkg98DG11mT2qfO5FwL3H+/
sQtz2MXvmIWHjh/+frjYsU77X9LFtr/QmH13ZstkqP2LuvALa6aazv3Iv7AL
ksHlzxd18RVwUXMxdEefiAV8/y7u5mrtH/6t5vHnz0zkPih1wOx/EYWe1VVf
bb+oCzlJRoIbtvl308aXAbLj4gu6ODG5LsDd/36cyyeGz3Zx1wEH1c5ru9gy
5QYvzG2FN322CxSrXv5aJhb4F3TxFQD5ss+22vJ36KK2wL/q/OOKbXH/Ve0R
ZXISJLUjUVd8qBSXRhd8Pi+QJrr97BtBa6NgHAjy/62fM+jZ1VgWRxjsv90q
gqi5Ppolzl7vX1V6KSg11+P4C6ZdMydl2JX5t/aW+pH/kR+WOAbd9W7HwzXP
NpD+DuRYktLhEFv5G66Adz5oaTJb6OuAKIb/73JD3S3VCB/xHaIV8z811N5S
edib9pY9+ndMuzJy3dcdMuiuZ9/VtZb6LD8OAqIUkUYd9/177xb7/e55v3MP
wVfvu/niP/o5DPg3u+9miHKgtIrAd7U/2l898MLZlFnolhs85S5YUzNMJWCK
Up+JeksNQYs/lum5Ei2lYHLz6KC7t6UGtSUbsdnFFuWPJR3vDJVC5xXJsB+M
hR2rqhYRoLW8pQMofHlT0wcHSLcVvlCVvH54s2YSlR7eVTu4E4pdPXxJB/U9
+BTnfD7un2AltmHzfuk2Dp+b8KghKaXMidLUapuF9LjVuw4CpFNLVb2fX7/p
nShDVdwctjLxGYA/D06puQxOTYSzPrA5et6tacX2Y++qUT1hJzxi5/FvjG0G
oUt+EbGff0n5QfLm3k2xwAJ0Dkxhfh2nIkWgJjXR+b1cL6KxxmQoSvrce6b6
UYa1my/Tlf6lpXpJUcTqEsZeRnGiwZIebdJVlKtRnGUpNQyinM6hWGzGGlNw
/8//zKC7v94mMPtO4/8CPDl4sPq1AAA=
</rfc> </rfc>
 End of changes. 50 change blocks. 
1349 lines changed or deleted 955 lines changed or added

This html diff was produced by rfcdiff 1.48.