Content for  TR 21.917  Word version:  17.0.1

Top   Top   Up   Prev   Next
0…   5…   5.2   6…   6.3…   6.3.2…   6.3.3…   6.3.4…   7…   7.4…   8…   9…   10…   11…   11.9…   12…   13…   14…   15…   15.6…   16…   17…   18…   18.10…   19…


7.4  Support of Enhanced Industrial IoT (IIoT)p. 58

UID Name Acronym WG WID WI rapporteur name/company
850012Study on enhanced support of Industrial IoTFS_IIoTS2SP-200298Nokia, Devaki Chandramouli,
880010Study on security for enhanced support of Industrial IoTFS_IIoT_SECS3SP-200355Nokia, Anja Jerichow
920024Security for enhanced support of Industrial IoTIIoT_SECS3SP-210421Nokia, Anja Jerichow
910059Support of Enhanced Industrial IIoTIIoTSP-200973Devaki Chandramouli, Nokia
900008Stage 2 for IIoTIIoTS2SP-200973Devaki Chandramouli, Nokia
910014CT aspects of support of enhanced IIoTIIoTctCP-212100Won, Sung Hwan, Nokia
910060CT1 aspects of support of enhanced IIoTIIoTC1CP-212100Won, Sung Hwan, Nokia
910061CT3 aspects of support of enhanced IIoTIIoTC3CP-212100Won, Sung Hwan, Nokia
910062CT4 aspects of support of enhanced IIoTIIoTC4CP-212100Won, Sung Hwan, Nokia
Summary based on the input provided by Nokia in SP-220425.
In Release 17, the 5G System expands the support for Time Synchronization and Time Sensitive communications for any application.
The 5G System architecture enables any Application Function (AF) - in the same or different trust domain - to provide its requirements for QoS, traffic characteristics for QoS scheduling optimization, time synchronization activation and deactivation.
If the AF is in a different trust domain from the 5G System, then it provides input via exposure framework, NEF API. If the AF is in the same trust domain as the 5G System, then it provides input directly via the Time Sensitive communication Time Synchronization function (TSCTSF).
The Functional Architecture is shown in the Figure below:
Copy of original 3GPP image for 3GPP TS 21.917, Fig. 7.4-1: Architecture to enable Time Sensitive Communication and Time Synchronization services
The Figure below depicts the two main synchronization methods supported: the 5GS synchronization and the (g)PTP domain synchronization.
  • 5G Clock synchronization: Used for NG RAN synchronization and also distributed to the UE. 5G Clock synchronization over the radio interface towards the UE is specified in TS 38.331.
  • (g)PTP synchronization: Provides time synchronization service to (g)PTP network. This process follows the standards IEEE Std 802.1AS or IEEE 1588 operation.
The two synchronization processes can be considered independent from each other and the gNB only needs to be synchronized to the 5G Grand Master (GM) clock.
Copy of original 3GPP image for 3GPP TS 21.917, Fig. 7.4-2: 5G system is modelled as PTP instance for supporting time synchronization
In order to support (g)PtP time synchronization, the 5G System operates in any of the following modes:
  1. as time-aware system (IEEE Std 802.1AS).
  2. as Boundary Clock (IEEE Std 1588).
  3. as peer-to-peer Transparent Clock (IEEE Std 1588).
  4. as end-to-end Transparent Clock (IEEE Std 1588).
The 5GS shall be modelled as an IEEE Std 802.1AS or IEEE Std 1588 compliant entity based on the above configuration. The TTs located at the edge of the 5G system (i.e. device side DS-TT and network side NW-TT) are responsible for fulfilling functionalities related to IEEE Std 802.1AS or IEEE Std 1588.
The 5G System is provisioned by the profiles supported by 3GPP specifications that include: Default PTP Profile, IEEE Std 802.1AS PTP profile for transport of timing as defined in IEEE Std 802.1AS, SMPTE Profile for use of IEEE Std 1588 Precision Time Protocol in Professional Broadcast Applications.
Furthermore, (g)PtP time synchronization is supported for the scenarios when Grand Master clock is behind the UE (uplink time sync, UE - UE time sync) and behind the network (down link time sync).
The ability for the AF to influence activation of 5G reference time distribution to the UE(s) along with time synchronization error budget (based on the accuracy needed for the application) has also been introduced.
Time Sensitive Communication and QoS
TSC Assistance Information (TSCAI) describes traffic characteristics that may be provided for use by the gNB, to allow more efficiently scheduled radio resources for periodic traffic and applying to PDU session type Ethernet and IP.
TSCAI describes TSC traffic characteristics for use in the 5G System. The knowledge of TSC traffic pattern is useful for 5G-AN to allow it to more efficiently schedule periodic and deterministic traffic flows either via Configured Grants, Semi-Persistent Scheduling or with Dynamic Grants.
Assistance Information Description
Flow DirectionThe direction of the TSC flow (uplink or downlink).
PeriodicityIt refers to the time period between start of two data bursts.
Burst Arrival Time (optional)The latest possible time when the first packet of the data burst arrives at either the ingress of the RAN (downlink flow direction) or the egress interface of the UE (uplink flow direction).
Survival Time (optional)Survival Time, as defined in TS 22.261, is synonymous with the time period an application can survive without any data burst.
5GS determines TSC Assistance Container based on information provided by an AF/NEF and may provide it to PCF for IP type and Ethernet type PDU sessions.
The AF may provide the traffic pattern parameters such as Burst Arrival Time with reference to the ingress port, Periodicity, Flow Direction, Survival Time and Time domain to the NEF. The NEF forwards the received traffic pattern parameters to TSCTSF.
The AF trusted by the operator can be allowed to provide such traffic pattern parameters to TSCTSF directly. The TSCTSF is responsible for determining and forwarding these traffic pattern parameters in TSC Assistance Container to the SMF (via PCF).
Survival Time was also introduced as part of TSCAI in order for the AF to provide the time period an application can survive without any burst. It refers to the time that an application consuming a communication service may continue without an anticipated message. Maximum number of messages (message is equivalent to a burst) or in terms of time units. Single burst is expected within a single time period referred to as the periodicity.
TS 23.501: System Architecture for 5G System; Stage 2 (clauses 4.4.8, 5.27, 5.28)
TS 23.502: Procedures for 5G System; Stage 2
TS 23.503: Policy and Charging Control Framework for the 5G System; Stage 2
For details of the IEEE work, go to:

7.5  Support of reduced capability NR devicesp. 60

UID Name Acronym WG WID WI rapporteur name/company
900062Support of reduced capability NR devicesNR_redcapRP-211574Ericsson
860035Study on support of reduced capability NR devicesFS_NR_redcapR1RP-202704Ericsson
900162Core part: NR_redcapNR_redcap-CoreR1RP-211574Ericsson
900262Perf. part: NR_redcapNR_redcap-PerfR4RP-211574Ericsson
930018Architecture Enhancement for NR Reduced Capability DevicesARCH_NR_REDCAPS2SP-211100Aihua Li, China Mobile
940005CT1 aspects of NR_redcapARCH_NR_REDCAPC1CP-213081Chen Xu, China Mobile
950047CT3 aspects of NR_redcapARCH_NR_REDCAPC3CP-220304Chen Xu, China Mobile
940100CT4 aspects of NR_redcapARCH_NR_REDCAPC4CP-213081Chen Xu, China Mobile
950044CT6 aspects of NR_redcapARCH_NR_REDCAPC6CP-213081Chen Xu, China Mobile
940027Charging aspects of Architecture Enhancement for NR Reduced Capability DevicesARCH_NR_REDCAPS5SP-211428Dong Jia, China Mobile
Summary based on the input provided by Ericsson in RP-221163.
This Rel-17 work item introduces support for UE complexity reduction techniques and UE power saving techniques suitable for IoT use cases such as industrial wireless sensors, video surveillance, and wearables, with requirements on low UE complexity and/or low UE power consumption and with relatively relaxed data rate requirements. Following an initial study [1], this work item [2] specified support for a reduced capability (RedCap) UE type and two UE power saving techniques: Extended DRX in RRC idle/inactive state, and RRM measurement relaxation for neighbour cells.
The following key functionalities are introduced as part of this work item:
Reduced capability (RedCap) UE type:
The new reduced capability (RedCap) UE type enables reduced UE complexity through various UE complexity reduction techniques. A RedCap UE supports a maximum UE Rx/Tx bandwidth of 20 MHz in FR1 and 100 MHz in FR2 (whereas a normal NR UE supports at least 100 MHz in FR1 and 200 MHz in FR2). A RedCap UE cannot support larger Rx/Tx UE bandwidths than 20 MHz in FR1 and 100 MHz in FR2, and it cannot support features related to carrier aggregation (CA), dual connectivity (DC), more than 2 UE Rx/Tx antenna branches, or more than 2 DL/UL MIMO layers.
A RedCap UE can furthermore have a reduced antenna configuration and a reduced number of DL MIMO layers:
  • For FR1, a RedCap UE supports 1 or 2 UE Rx branches and 1 or 2 DL MIMO layers. The supported number of DL MIMO layers is the same as the implemented number of Rx branches, and as a result, 2-Rx RedCap UEs have twice as high DL peak rate as 1-Rx RedCap UEs. The UE indicates to gNB how many branches/layers it supports. The gNB can allow or disallow access from 1-Rx and 2-Rx RedCap UEs separately per cell.
  • For FR2, a RedCap UE can either support a legacy UE power class such as PC3 or the new lower UE power class PC7 (with a reduced-complexity reference UE Rx/Tx antenna configuration with either 1 panel with 4 elements or 2 panels with 2 elements each, corresponding to half the number of array elements compared to a legacy PC3 UE). Furthermore, the UE indicates support for 1 or 2 DL MIMO layers (independent of the antenna configuration).
A RedCap UE in FDD mode can report per band whether it implements half-duplex FDD (HD-FDD) or full-duplex FDD (FD-FDD) support. In HD-FDD operation, the UE is not required to transmit and receive at the same time. The network indicates in SIB1 whether the cell supports HD-FDD RedCap UEs.
A RedCap UE can be implemented with or without support for DL 256QAM in FR1. Compared to 64QAM (which is mandatory for RedCap UEs), 256QAM support increases the peak data rate by ~33%. Support for UL 256QAM in FR1 and DL/UL 256QAM in FR2 is also optional for RedCap UEs, but this is true even for legacy NR UEs.
Some higher layer features are optional for RedCap UEs: RedCap UEs can optionally support 16 DRBs (as normal NR UEs) but only have mandatory support of 8 DRBs. RedCap UEs can optionally support 18-bit PDCP/RLC sequence numbers (as normal NR UEs) but only have mandatory support for 12-bit sequence numbers. RedCap UEs have optional (but not mandatory) support for automatic neighbour relation (ANR) functionality.
Due to the reduced UE bandwidth, there are some modifications of the bandwidth part (BWP) operation. Separate initial DL/UL BWPs can be configured for random access for RedCap UEs, which may be required if one or both of the ordinary initial DL/UL BWPs in the cell are configured with a bandwidth which is wider than the maximum RedCap UE bandwidth (i.e., wider than 20 MHz in FR1 or wider than 100 MHz in FR2). A separate initial DL BWP can, but does not need to, contain SSB/CORESET#0/SIB. A DL BWP used in connected mode needs to contain (cell-defining or non-cell-defining) SSB but not necessarily CORESET#0/SIB.
The UE provides an early indication already during random access that it is a RedCap UE. If RedCap-specific PRACH resources are configured in the cell, the early indication is provided implicitly already by Msg1. In any case, an indication will be provided in Msg3 (or MsgA in case of 2-step RACH) in the form of a RedCap-specific LCID value for CCCH.
To minimize UL resource fragmentation for other UEs, the network can choose to disable frequency hopping for the PUCCH transmission carrying HARQ-ACK feedback for Msg4 (similar to how PUCCH frequency hopping can be disabled in connected mode).
Extended DRX in RRC idle/inactive state:
Extended DRX cycles are introduced for RRC idle state (up to 10485.76 seconds, i.e., roughly 3 hours) and RRC inactive state (up to 10.24 seconds) as an optional feature for both RedCap and non-RedCap UEs. For use cases with relatively relaxed requirements on DL reachability/latency, the network may configure an extended DRX cycle, which may reduce the UE power consumption substantially during periods with large enough packet inter-arrival time.
RRM measurement relaxation for neighbour cells:
RRM measurement relaxation for neighbour cells is introduced as an optional feature for RedCap UEs that can be enabled by the network. In RRC idle/inactive states, to help reduce UE power consumption, the UE is allowed to further relax neighbour-cell RRM measurements (compared to existing Rel-16 relaxation functionality) when an RSRP/RSRQ-based stationarity criterion is met for a period of time, or when both the stationarity criterion and a not-at-cell-edge criterion are met. In RRC connected state, the network may configure the RSRP/RSRQ-based stationarity criterion and in that case the UE shall report when the criterion is met or no longer met (and how to use the reporting information is up to the network implementation).
Charging aspects (as per SP-220697 from China Mobile)
SA2 have studied the architecture enhancement for NR RedCap and introduced the NR RedCap UEs differentiation requirement in clause 5.41 of TS 23.501. Accordingly, CT3 and CT4 have specified a new RAT type NR RedCap. Based on the conclusion, SA5 mainly focus on the charging requirement of 'RedCap NR Devices' or 'devices using NR RedCap', which can be used by operators to charge differentially.
Stage 2 work on WI ARCH_NR_REDCAP for TS 32.255, TS 32.256 and TS 32.274: Add charging requirement for SMF, AMF and SMSF to support NR RedCap, providing for NR RedCap UE using NR the RAT Type NR_REDCAP.
Stage 3 work on WI ARCH_NR_REDCAP for TS 32.298: Adding NR RedCap as a new RATType in CHF-CDR.
TR 38.875: V17.0.0, "Study on support of reduced capability NR devices"
RP-220966: "Revised WID on support of reduced capability NR devices"
RP-221162: "Status report for support of reduced capability NR devices"
TS 23.501: "System architecture for the 5G System (5GS)"
TS 32.255: "5G data connectivity domain charging"
TS 32.256: "5G connection and mobility domain charging"
TS 32.274: "Short Message Service (SMS) charging"
TS 32.298: "Charging Data Record (CDR) parameter description"

7.6  IoT and 5G access via Satellite/Non-Terrestrial (NTN) linkp. 62

See the section "5G access via Satellite/Non-Terrestrial (NTN) link".

7.7  Charging enhancement for URLLC and CIoTp. 62

UID Name Acronym WG WID WI rapporteur name/company
890020Charging enhancement for URLLC5G_URLLCS5SP-200769Huawei, Chen Shan
Summary based on the input provided by Huawei in SP-220571
As per the clause 5.33 of TS 23.501 the redundant transmission for high reliability communication to support Ultra Reliable Low Latency Communication (URLLC) is defined.
The WID 5G_URLLC specifies the charging principle, charging requirements, service operations and charging information for URLLC service charging, including:
  • For dual connectivity based end to end Redundant User Plane Paths, SMF shall collect and report the usage for each redundant PDU session.
  • For redundant transmission at N3/N9 interface and transport layer, the SMF shall collect and report the usage not counting redundant packets.
  • QoS Monitoring to assist URLLC Service are reported.
The corresponding Open API and ASN.1 for URLLC service charging are specified in the TS 32.291 and TS 32.298.
Related CRs:
TS 32.255: "Charging management; 5G Data connectivity domain charging; stage 2".
TS 32.291: "Charging management; 5G system; Charging service, stage 3".
TS 32.298: "Charging management; Charging Data Record (CDR) parameter description".
UID Name Acronym WG WID WI rapporteur name/company
940044Charging enhancements for 5G CIoT5G_CIoT_CHS5SP-211448Zhu, Lei, Huawei
Summary based on the input provided by Huawei in SP-220573.
This WID provides some charging enhancements for the 5GS CIoT features specified e.g. in TS 23.501 and TS 23.502. This 5GS CIoT charging is specified in TS 32.255. The support 5GS and EPC interwork scenarios are considered, as well as the roaming scenario. The charging information and CDR content are described in TS 32.291 and TS 32.298.
Related CRs:

7.8  Messaging in 5Gp. 63

UID Name Acronym WG WID WI rapporteur name/company
930030Support of the 5GMSG ServiceFS_5GMARCHS6SP-200835Liu, Yue, China Mobile
840036Study on support of the 5GMSG ServiceFS_5GMARCHS6SP-200835Liu, Yue, China Mobile
890010Study on security aspects of the 5GMSG Service (St1 in Rel16)FS_SEC_5GMSGS3SP-200878Xiaoting Huang, China Mobile
930005Security aspects of the 5GMSG Service5GMSGS3SP-210835Xiaoting Huang, China Mobile
930040Application Architecture for MSGin5G Service5GMARCHSP-200832Liu, Yue, China Mobile
890026Application Architecture for MSGin5G Service5GMARCHS6SP-200832Liu, Yue, China Mobile
930004CT aspects for enabling MSGin5G Service5GMARCHctCP-212106Liu, Yue, China Mobile
930041CT1 aspects for enabling MSGin5G Service5GMARCHC1CP-212106Liu, Yue, China Mobile
930042CT3 aspects for enabling MSGin5G Service5GMARCHC3CP-212106Liu, Yue, China Mobile
Summary based on the input provided by China Mobile in SP-220285.
This Feature improves the messaging communication capability of the 5G System, especially for Massive Internet of Things (MIoT). It is based on the study in TR 23.700-24.
The following Figure, from TS 23.554, provides the high level illustration of the MSGin5G service:
Copy of original 3GPP image for 3GPP TS 21.917, Fig. 7.8-1: Application Architecture of the MSGin5G Service
The following functions are specified:
  1. Configuration of MSGin5G UE and Non-MSGin5G UE to get the MSGin5G Service configuration information (e.g. UE Service ID);
  2. Registration of MSGin5G UE and registration of Message Gateway on behalf of the Non-3GPP UEs;
  3. Message delivery procedures for the message communication models listed below (the message can be delivered between different PLMNs):
    • Point-to-point message which happens between a person and a thing or two things;
    • Application-to-point message/ Point-to-application message which happens between an application server and an IoT device;
    • Group message which originates at a UE and terminated at a group of UEs, all members in the group can send and receive the message;
    • Broadcast message which originates at an application sever in the network or an UE and terminated at all the UEs in a specific service area within a cell or multiple cells;
    • Message delivery based on messaging topic which the message is delivered to all subscribers (UE or Application Server) of this messaging topic.
  4. Message Aggregation can be used to optimize communications towards the same target by aggregating one or more messages into a single message;
  5. MSGin5G message can be segmented transmission if the content is larger than the maximum payload length of a message and reassembled by the suitable recipient;
  6. MSGin5G message can be stored by the MSGin5G Server if a UE is unavailable (disconnected or power off) for future delivery once the UE becomes available;
  7. 3GPP network functionalities of UE reachability status monitoring and device triggering can be leveraged by the MSGin5G Service via Core Network exposure.
  8. The Service Enabler Architecture Layer for Verticals (SEAL) capabilities "Group management service" and "Configuration management service" can be used by the MSGin5G service. These services are specified in TS 23.434 and TS 23.554.
TS 23.554: "Application architecture for MSGin5G Service; Stage 2" (specifies functional architecture, procedures, information flows and APIs )
TS 22.262: "Message Service within the 5G System".
TS 33.501: "Security architecture and procedures for 5G System".
TS 24.538: "Enabling MSGin5G Service; Protocol specification" (specifies detailed procedures over CoAP protocol between MSGin5G Client and MSGin5G Server)
TS 29.538: "Enabling MSGin5G Service; Application Programming Interfaces (API) specification;" (specifies the RESTful APIs provided by MSGin5G Server towards the Application Server and Message Gateway)
TS 23.434: "Service Enabler Architecture Layer for Verticals".
UID Name Acronym WG WID WI rapporteur name/company
890001Service-based support for SMS in 5GCSMS_SBICP-212023HAOUARI, Wafa, Orange
890028CT1 aspects of SMS_SBISMS_SBIC1CP-212023HAOUARI, Wafa, Orange
890029CT4 aspects of SMS_SBISMS_SBIC4CP-212023HAOUARI, Wafa, Orange
No summary was provided.

Up   Top   ToC