Content for TR 23.724 Word version: 16.1.0

1… 5… 6… 6.18… 6.36… 7…

3.1 Definitions 3.2 Symbols 3.3 Abbreviations
...

1 Scope p. 16

This technical report studies and evaluates architecture enhancements to address the following objectives:

Objective I)

Enable CIoT/MTC functionalities in 5G CN.

The objective is to study how to support identified CioT/MTC functionalities in 5G CN with potential connectivity to WB-EUTRA (eMTC) and/or NB-IoT for 5GS capable devices.

The following CIoT/MTC functionalities need to be evaluated and studied how to enable them in 5G CN, if needed:

Equivalent overall functionalities as provided by SCEF for CIoT/MTC.
Monitoring.
Small data transmission (infrequent and frequent small data transmission including frequent small data transmission from tracking devices).
Additional power saving functions unless those are supported for 5G system in Rel-15.
Non-IP Data Delivery.
Overload control (as relevant in 5G CN).
Support of Coverage enhancement including adaptations in 5G CN required to support latencies.
Equivalent to Group communication and messaging.
Reliable communication via functionality equivalent to SCEF.
Inter-RAT mobility support to/from NB-IoT.
High latency communication.
Include location services procedures for IoT in 5G location services.

Ensure that regulatory requirements can be fulfilled at the same level as in EPC.

Objective II)

Co-existence and migration from EPC based eMTC/NB-IoT to 5GCN.

Study solutions for coexistence and migration from EPC towards 5G CN for eMTC/NB-IoT.

This objective will study solutions where the same service is offered to some UEs connected to EPC and some UEs connected to 5G CN e.g. using SCEF and equivalent functionalities in 5GCN. Solutions that assume that 5G CN needs to support EPC NAS signaling for legacy IoT devices access are not considered.

Any modifications in the EPC-5GC interworking "baseline" specific to CIOT will also be discussed as part of Objective II.

Objective III)

5G System enhancements to address 5G service requirements (based on TS 22.261 and TR 38.913).

To study system architecture enhancements to address related service requirements defined in TS 22.261 and RAN requirements defined in TR 38.913 and how to enable them in 5G CN, if needed. At least the following service requirements have been identified:

Enable the change of association between subscription and address/number of an IoT device within same operator and in between different operators.
Restricted Registration procedure to allow IoT device provisioning.

Any system implications for the RAN will be coordinated with RAN WGs.

This study is not going to study enhancements to EPC.

2 References p. 17

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

References are either specific (identified by date of publication, edition number, version number, etc.) or non specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.

[1]

TR 21.905: "Vocabulary for 3GPP Specifications".

[2]

TS 22.261: "Service requirements for next generation new services and markets".

[3]

TR 38.913: "Study on scenarios and requirements for next generation access technologies".

[4]

TS 23.401: "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access".

[5]

TS 23.501: "System Architecture for the 5G System".

[6]

TS 23.682: "Architecture enhancements to facilitate communications with packet data networks and applications".

[7]

TS 23.502: "Procedures for the 5G System".

[8]

TS 24.250: "Protocol for Reliable Data Service between UE and SCEF; Stage 3".

[9]

TS 29.122: "T8 reference point for northbound Application Programming Interfaces (APIs)".

[10]

TS 24.501: "Non-Access-Stratum (NAS) protocol for 5G System (5GS)".

[11] Void.

[12]

Open Mobile Alliance: "Lightweight Machine to Machine Requirements, V1.0".

[13]

MQTT For Sensor Networks, (MQTT-SN): www.mqtt.org.

[14]

RFC 6347: "Rescorla et al.: Datagram Transport Layer Security", IETF, January 2012.

[15]

TR 38.804: "Study on New Radio Access Technology; Radio Interface Protocol Aspects".

[16]

TS 29.244: "Interface between the Control Plane and the User Plane nodes".

[17]

TS 29.303: "Domain Name System Procedures; Stage 3".

[18]

TS 29.510: "5G System; Network function repository services; Stage 3".

[19]

TS 38.300: "NR; NR and NG-RAN Overall Description; Stage 2".

[20]

TS 23.222: "Functional architecture and information flows to support Common API Framework for 3GPP Northbound APIs".

[21]

TS 23.122: "Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle mode".

[22]

TS 36.413: "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP)".

[23]

TS 36.331: "Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification".

[24]

TS 33.401: "3GPP System Architecture Evolution (SAE); Security architecture".

[25]

TS 33.501: "Security architecture and procedures for 5G System".

[26]

TS 29.502: "Session Management Services; Stage 3".

[27]

TS 36.321: "Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) protocol specification".

3 Definitions, symbols and abbreviations p. 18

3.1 Definitions p. 18

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

3.2 Symbols p. 18

3.3 Abbreviations p. 18

For the purposes of the present document, the abbreviations given in TR 21.905 apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.

4 Architectural Assumptions and Principles p. 18

The following architecture assumptions and principles apply:

The assumption is that WB-E-UTRA and NB-IoT are connected to 5GC via N2/N3.
Regulatory requirements (e.g. LI) shall be fulfilled at the same level as in EPC.
No architectural enhancements made to EPC.
APIs for CIoT related services provided to the SCS/AS shall be common for UEs connected to EPS and 5GS and accessed via the HPLMN.

NOTE 1:
The level of support of the API may differ between EPS and 5GS.
Notifications and data from NFs in the VPLMN to the NEF can be routed through an IWK-NEF, similar to the IWK-SCEF in EPC.

NOTE 2:
Some solutions documented in this TR may not necessarily show the IWK-NEF. It is however assumed that IWK-NEF support will be added during the normative phase.
Support for small data delivery using IP data and Unstructured (Non-IP).
At least equivalent level of security for UEs used for CIoT in 5GS system as in EPS.

NOTE 3:
Security may need to be investigated by SA WG3.
Equivalent or reduced level of power consumption for UEs used for CIoT in 5GS system to that in EPS shall be supported.
UEs used for CIoT can be mobile or nomadic/static, and resource efficiency should be considered for both for relevant optimization(s).
The 5GS system is assumed to operate with a large number of UEs used for CIoT in the system and be able to appropriately handle overload and congestion situations.
External exposure of network capabilities towards SCS/AS or AF is supported via NEF.
UEs used for CIoT can simultaneously connect to one or multiple SCSs/ASs or AFs.