Menu
Latest
12 meetings · Prague, Jeju · 12–16 Oct
Reports
RAN1#126-bis · SA2#177

Glossary term · Identifier

SC-N-RNTI

Single Cell Notification RNTI

Identifier →

SC-N-RNTI is a Radio Network Temporary Identifier used in LTE to notify multicast-subscribed UEs of changes on the Single Cell Multicast Control Channel, prompting them to check for updated service information.

Introduced
Rel-13
Where
Radio Access Network › E-UTRAN (LTE)
Specifications
2 specs
SC-N-RNTI Description Purpose What changed Neighbours Specifications

Description

The Single Cell Notification RNTI (SC-N-RNTI) is a specific type of Radio Network Temporary Identifier (RNTI) used within the LTE Radio Access Network for Single-Cell Point-to-Multipoint (SC-PTM) operations. An RNTI is a unique identifier assigned by the eNodeB to a UE or a group of UEs, used to scramble and identify control channel messages on the Physical Downlink Control Channel (PDCCH) or Enhanced PDCCH (EPDCCH). The SC-N-RNTI has a fixed, predefined hexadecimal value (specified in the 3GPP standards), which is known a priori by all UEs capable of SC-PTM. Its sole purpose is to indicate a notification or change in the Single Cell Multicast Control Channel (SC-MCCH), which carries the configuration and scheduling information for available SC-PTM services.

Operationally, the eNodeB transmits a special PDCCH message scrambled with the SC-N-RNTI. This message does not schedule any user data transmission; instead, it serves as a paging-like indicator. When a UE interested in SC-PTM services is in RRC_IDLE or RRC_CONNECTED state, it periodically monitors the PDCCH for this specific RNTI. The detection of the SC-N-RNTI on the PDCCH is an instruction for the UE to immediately read the SC-MCCH. The SC-MCCH itself is transmitted on the PDSCH at specific modification periods, and its content includes a list of available SC-MTCHs (Single Cell Multicast Transport Channels), their corresponding scheduling information, and associated Group RNTIs (G-RNTIs). By using the SC-N-RNTI as a trigger, UEs do not need to continuously decode the SC-MCCH, which would consume significant battery power. They only need to decode it when a change is signaled, which is far more efficient.

The SC-N-RNTI mechanism is a critical component of the SC-PTM power-saving design. The notification is broadcast to all UEs in the cell capable of SC-PTM. The eNodeB transmits the SC-N-RNTI on the PDCCH during a specific time window within the SC-MCCH modification period, typically just before the updated SC-MCCH information becomes valid. This ensures UEs have enough time to acquire the new configuration. The SC-N-RNTI is part of the broader RNTI space in LTE, which includes other identifiers like the C-RNTI (Cell RNTI for unicast), P-RNTI (Paging RNTI), SI-RNTI (System Information RNTI), and the G-RNTI used to schedule the actual SC-MTCH data transmissions. Its fixed value ensures no additional configuration signaling is required for UEs to recognize it, simplifying implementation and ensuring interoperability.

Purpose & Motivation

The SC-N-RNTI was created to solve the problem of efficient notification and power management for UEs subscribed to SC-PTM services. In multicast/broadcast systems, a key challenge is informing a potentially large group of devices about changes to service availability or configuration without requiring each device to constantly monitor a control channel, which would rapidly drain battery life, especially for IoT or public safety devices that may need to operate for extended periods.

Before mechanisms like the SC-N-RNTI, devices might have needed to periodically wake up and decode the multicast control channel (like SC-MCCH) at its full repetition rate to check for updates. This is inefficient if updates are infrequent. The SC-N-RNTI provides an asynchronous, low-overhead alert system. It allows UEs to remain in a low-power state for most of the time, only activating their full receiver circuitry to monitor the PDCCH for the brief periods when the SC-N-RNTI might be transmitted. This design pattern is similar to the use of P-RNTI for paging in idle mode but is specialized for multicast service notifications.

Introduced in 3GPP Release 13 alongside the broader SC-PTM framework, the SC-N-RNTI was a necessary enabler for practical and battery-efficient multicast services on LTE, particularly for machine-type communication and mission-critical push-to-talk scenarios. It addressed a fundamental trade-off between service accessibility and device power consumption, making SC-PTM a viable technology for always-on or long-lived group communication sessions where devices need to be reachable for new multicast data without excessive energy cost.

What changed in its specifications

The latest release-to-release comparison of specifications that define SC-N-RNTI. Each summary describes the whole specification, not only this term.

TS 36.300Rel-18 → Rel-19

Rel-19 added NTN IoT Phase 3 for LTE, covering regenerative payload S1 removal, Msg3 early data transmission, and ETWS/CMAS for NB-IoT NTN. It also added inter-RAT mobility from E-UTRAN terrestrial network to NR NTN, plus NR NTN feeder link switchover via handover.

Full comparison in TS 36.300 →
TS 36.321Rel-18 → Rel-19

Rel-19 adds to TS 36.321 a contention-based Msg3 early data transmission (CB-Msg3-EDT) procedure, along with new definitions and abbreviations. This is the only feature overview provided, so no other additions can be named.

Full comparison in TS 36.321 →

Evolution Across Releases

An overview written from the defining specifications, not a verified change history. For the exact text, open the specifications listed below.

Rel-13 Initial

Initial definition with a standardized hexadecimal value. Integrated into the SC-PTM notification procedure to inform UEs of changes to the SC-MCCH, forming a core part of the power-efficient multicast service acquisition mechanism in LTE.

Defining Specifications

3GPP specifications that define or reference SC-N-RNTI, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TS 36.300 vj20 E-UTRAN Radio Interface Protocol Architecture Rel-19 read
TS 36.321 vj30 E-UTRA MAC Protocol Specification Rel-19 read