|
5G/NR - Paging |
||||||||||||||||||||||||||||
|
Paging is a critical functionality in cellular systems, used to notify a UE (User Equipment) of incoming services or messages while minimizing power consumption by not requiring continuous monitoring of the network Think of Paging as a "Wake-Up Call" service for your smartphone. When you aren't actively using your phone (it's in your pocket or on a desk), it goes into a deep sleep to save battery. If someone calls you or sends a text, the network needs a way to tap the phone on the shoulder and say, "Hey, wake up! There's data waiting for you." The overal purpose of Paging in NR is same as LTE Paging, but in details there are some differences between NR paging and LTE paging.
In LTE, Paging had performed roughly 3 main things as follows.
In NR, Paging functions mostly for Triggering RRC Setup (RRC Request and RRC Connection Resumption). System Information Modification and PWS/ETWS notification is done by DCI 1_0 with P_RNTI and corresponding PDSCH. The Core Concept: EfficiencyThe UE cannot monitor the network continuously. If it keeps listening every millisecond, the receiver must stay on all the time. This consumes a lot of power. As a result, the battery would drain very quickly. To avoid this problem, the network and the UE use DRX, which stands for Discontinuous Reception. With DRX, the UE does not listen all the time. It sleeps for most of the time. Then it wakes up only at specific timing points that are predefined by the network configuration. At each wake-up occasion, the UE checks whether there is any paging indication or paging message for itself. If there is no relevant message, the UE does not keep monitoring further. It immediately goes back to sleep mode. This allows the UE to save battery while still remaining reachable by the network. This mechanism is a balance between power saving and reachability. The UE is not always awake, so battery consumption stays low. But the UE still wakes up often enough to receive incoming call notification, data arrival notification, or other network-triggered events. In simple terms, DRX makes the UE behave like this: sleep most of the time, wake up briefly, check paging, and sleep again. This repeated on-and-off monitoring is the reason why idle mode operation can be power efficient while still allowing the network to contact the UE when needed. LTE vs. NR: The Shift in ResponsibilitiesIn LTE, the Paging message acts like a multi-purpose container. The network sends a single Paging message. This message includes not only the wake-up indication but also additional information such as system updates and emergency alerts. This means the UE wakes up, reads the Paging message, and gets everything it needs in one step. In NR, the design is more modular and efficient. The Paging message is no longer overloaded with multiple roles. Instead, the system separates responsibilities. The Paging mechanism mainly focuses on waking up the UE or triggering connection resume. Other types of information are delivered through different channels. For system updates, NR uses DCI. The gNB sends control information through the PDCCH. This allows the UE to receive updates in a more flexible and faster way. It also reduces the size and complexity of the Paging message itself. For emergency alerts, NR also leverages DCI-based mechanisms. This approach is more efficient because the network can deliver urgent information without waiting for the Paging cycle. As a result, latency is reduced and delivery becomes more reliable. Overall, LTE paging is a “one message does everything” approach. NR paging splits the roles into specialized procedures. This makes the system more scalable, more efficient, and better suited for diverse 5G use cases such as low latency services and massive device connectivity.
Why the Change in 5G?In 5G, the system is redesigned to reduce unnecessary processing and improve responsiveness. In LTE, the UE often had to decode the entire Paging message even for small updates. This increases processing load and wastes power, especially when the UE wakes up frequently due to DRX. The main idea in 5G is to avoid sending large messages when only a small indication is needed. Instead of embedding everything inside Paging, the network moves certain functions to the control channel level using DCI with P-RNTI. This allows the UE to detect important changes with minimal effort. In LTE, the UE wakes up and reads the Paging message. Even if the change is minor, such as a system information update or emergency alert, the UE still needs to decode the full Paging payload. This increases decoding complexity and consumes additional power. In NR, the gNB sends a short indication using DCI. This acts like a small flag. The UE wakes up, monitors PDCCH, and checks the DCI addressed with P-RNTI. If the flag is present, the UE immediately knows that there is a system information change or emergency alert. This approach avoids unnecessary decoding of large Paging messages. The UE only processes detailed information when it is really needed. As a result, power consumption is reduced and latency is improved. This design also allows faster reaction to urgent events. Since DCI can be transmitted more flexibly than Paging, emergency alerts can reach the UE quicker. This makes the system more efficient and better aligned with 5G requirements such as low latency and optimized power usage. In simple terms, LTE requires the UE to read a full message to find out if something changed. NR provides a quick signal first, and only if needed, the UE proceeds to read more detailed information.
RRC Connection ResumptionRRC Connection Resumption is one of the key enhancements introduced in 5G. It changes how the UE returns from idle or inactive state to a connected state. In LTE, when the UE wakes up due to paging, it typically performs a full RRC Setup procedure. This means the UE and eNB have to establish the connection from the beginning. All signaling steps are executed again. This increases latency and signaling overhead. In NR, a new state called RRC Inactive is introduced. In this state, the UE context is partially preserved in the network. The UE is not fully connected, but important information such as UE identity and configuration is still maintained. When paging is triggered in NR, the UE does not need to perform a full RRC Setup. Instead, it performs RRC Connection Resumption. This procedure reuses the stored context and quickly restores the connection. The gNB sends paging to indicate that data is available or that the UE should resume the connection. The UE wakes up, identifies the paging, and initiates the Resume procedure using the stored context. This reduces the number of signaling messages. It also reduces the time required to re-establish the connection. As a result, latency is lower and user experience is improved. In simple terms, LTE behaves like restarting a system from scratch every time. NR behaves like waking up from sleep mode. The system state is preserved, so the UE can quickly continue communication without full reinitialization. Paing MessageThe Paging message in NR follows ASN.1 encoding, similar to LTE. Paging ::= SEQUENCE { pagingRecordList PagingRecordList OPTIONAL, -- Need N lateNonCriticalExtension OCTET STRING OPTIONAL, nonCriticalExtension SEQUENCE{} OPTIONAL }
PagingRecordList ::= SEQUENCE (SIZE(1..maxNrofPageRec)) OF PagingRecord
PagingRecord ::= SEQUENCE { ue-Identity PagingUE-Identity, accessType ENUMERATED {non3GPP} OPTIONAL, -- Need N ... }
PagingUE-Identity ::= CHOICE { ng-5G-S-TMSI NG-5G-S-TMSI, fullI-RNTI I-RNTI-Value, ... } Key components include:
The highlevel structure and design concept of 5G paging message are as follows. The "Guest List" (PagingRecordList)The network doesn't usually send a separate radio message for every single phone. That would be a waste of bandwidth. Instead, it bundles multiple "wake-up calls" into one list. The PagingRecordList is a key concept in paging efficiency. The network does not send one paging message per UE. That would consume too much radio resource. Instead, the network groups multiple UEs into a single Paging message. In LTE and NR, the Paging message contains a list of UE identities. This list is called PagingRecordList. Each entry in this list corresponds to one UE that needs to be woken up. When the UE wakes up during its paging occasion, it reads the Paging message. Then it checks whether its own identity is included in the PagingRecordList. If the UE finds its identity in the list, it proceeds with further action such as connection setup or resumption. If not, it immediately goes back to sleep. This mechanism avoids unnecessary transmissions. A single Paging message can notify multiple UEs at the same time. This improves radio efficiency and reduces signaling overhead. The size of this list is limited. In 5G NR, the parameter maxNrofPageRec defines how many UEs can be included in one Paging message. This value is typically 32. This means the network can page up to 32 UEs using a single transmission. From UE perspective, the behavior is simple. UE wakes up, decodes Paging, searches for its ID, and decides whether to act or sleep. From network perspective, it is an efficient broadcast-style mechanism that minimizes resource usage while maintaining reachability. In simple terms, the network calls multiple UEs at once using a single message. Each UE listens briefly and responds only if its name is called.
The IDs: Who are you? (ue-Identity)This is the most critical part. The phone looks at this list to see if its name is on it. There are two main ways a 5G phone is identified here: The ue-Identity is the key field that determines whether the Paging message is intended for a specific UE. When the UE wakes up and reads the PagingRecordList, the first thing it does is compare the identities in the list with its own identity. In NR, there are multiple types of UE identities used for paging. These identities are designed for efficiency and privacy. One commonly used identity is ng-5G-S-TMSI. This is a temporary identity assigned by the network. The UE does not use its permanent identity such as IMSI over the air in normal operation. Instead, the network provides this temporary ID. This ID can be updated periodically. This prevents long-term tracking of the UE and improves user privacy. When the UE reads the Paging message, it checks if any entry in the PagingRecordList contains its ng-5G-S-TMSI. If there is a match, the UE knows that the paging is for itself and proceeds with the required action. Another identity used in NR is full-RNTI. This is mainly used when the UE is in RRC_INACTIVE state. In this state, the network still keeps part of the UE context. The full-RNTI acts as a resume identifier. When paging is triggered for an RRC_INACTIVE UE, the network can include full-RNTI in the PagingRecordList. The UE compares this value with its stored RNTI. If it matches, the UE understands that it should perform RRC Connection Resumption instead of starting from scratch. This dual identity mechanism allows flexible operation. ng-5G-S-TMSI is used for general paging with strong privacy protection. full-RNTI is used for fast resume procedures when context is preserved. From UE perspective, the logic is straightforward. UE wakes up, reads PagingRecordList, compares identities, and decides the next action. If no match is found, it goes back to sleep. If a match is found, it triggers connection setup or resumption depending on the identity type. In simple terms, the Paging message calls out a list of temporary names. The UE checks if one of those names belongs to it. If yes, it responds. If not, it ignores and sleeps again.
The Access Type (3GPP vs. non-3GPP)Access Type is an important concept introduced in 5G. It reflects the fact that a UE can be connected to the 5G Core through different types of access networks. In LTE, paging is always associated with the cellular access. The network assumes that the UE is reachable through the radio interface of the eNB. In 5G, the architecture is more flexible. The UE can access the 5G Core either through 3GPP access or non-3GPP access. These two access types are handled in a unified way by the core network. 3GPP access refers to the standard cellular connection through gNB. This is the typical 5G NR radio interface. non-3GPP access refers to other types of connectivity such as Wi-Fi. In this case, the UE connects to the 5G Core through an interworking function such as N3IWF or TNGF. Even though the radio is not NR, the core network still manages the UE in a similar way. Paging in 5G can take this access type into account. The network knows through which access the UE is currently reachable. Based on this, it can trigger paging over the appropriate path. For example, if the UE is connected via Wi-Fi using non-3GPP access, the network can page the UE through that path instead of the cellular interface. This improves reachability in scenarios where cellular coverage is weak but Wi-Fi is available. This mechanism allows seamless integration of different access technologies. The UE does not need to rely solely on cellular coverage to remain reachable. In simple terms, 5G treats Wi-Fi and cellular as different doors to the same system. The network can knock on whichever door the UE is currently using.
Extensions: Future-ProofingThe extension fields such as lateNonCriticalExtension and nonCriticalExtension are designed for long-term evolution of the standard. These fields act as placeholders in the message structure. In LTE and NR, RRC messages are defined using ASN.1. Once a message format is deployed, it cannot be easily changed without risking compatibility issues. Devices already in the field must continue to operate even when new features are introduced. To solve this, 3GPP includes extension containers in the message definition. These containers are initially empty or unused. But they provide space where new parameters can be added in future releases. When a newer network includes additional information inside these extension fields, older UEs will still be able to decode the message. This is because these fields are marked as non-critical. If the UE does not understand the content, it simply ignores it. This mechanism ensures backward compatibility. New features can be introduced without breaking existing devices. At the same time, newer devices that understand the extensions can take advantage of the added functionality. The lateNonCriticalExtension is typically used for future additions that come after the original extension structure. It provides an additional layer of extensibility as the specification continues to evolve. From UE perspective, the behavior is simple. UE decodes the known fields. If it encounters unknown extension content, it skips it and continues processing. There is no failure or crash. In simple terms, these extension fields are like reserved space in a message. They allow the standard to grow over time without forcing all devices to upgrade at once.
Paging ConfigurationTo understand Paging Configuration in 5G, it helps to think of it as a carefully scheduled check-in system between the UE and the network. A smartphone cannot keep its receiver fully active all the time. If the UE continuously monitors the radio channel without interruption, power consumption becomes very high. In that case, battery life would become impractical. This is why paging is built around a timing agreement between the UE and the cell. The basic idea is simple. The UE does not stay awake and listen all the time. Instead, the network tells the UE when it should wake up and monitor for paging. These wake-up moments occur only at specific times defined by the paging configuration. This means the UE spends most of its time in a low-power state. Then, at the scheduled moments, it briefly wakes up and checks whether the network has a paging indication or paging message for it. If there is nothing addressed to that UE, it quickly returns to sleep. This repeated sleep-and-check behavior is what makes idle or inactive operation power efficient. From network point of view, paging configuration is the rule set that determines when a UE should listen. From UE point of view, paging configuration is like a timetable. The UE follows that timetable very strictly. It knows exactly when to wake up, when to monitor the control channel, and when it can safely go back to sleep. This timing relationship is not random. It is carefully designed so that the network can still reach the UE with predictable delay, while the UE can preserve battery for as long as possible. In other words, paging configuration is a tradeoff between reachability and power saving. If the UE wakes up too often, the network can contact it quickly, but battery consumption increases. If the UE wakes up less often, battery consumption improves, but the waiting time for incoming calls or data may become longer. Paging configuration chooses a balanced point between these two needs. In 5G, this scheduling concept is even more important because the system must support many different service types, including conventional mobile broadband, low-latency applications, and devices that need very long battery life. Therefore, paging is not just a simple wake-up signal. It is part of a broader power-saving design that allows the UE to remain reachable without wasting radio and battery resources. In simple terms, the UE and the network agree on a calendar. The UE sleeps most of the time. At specific scheduled instants, it wakes up, checks whether the network is calling, and if nothing is there, it goes back to sleep again. SIB1 ::= SEQUENCE { cellSelectionInfo SEQUENCE { q-RxLevMin Q-RxLevMin, q-RxLevMinOffset INTEGER (1..8) OPTIONAL, -- Need R q-RxLevMinSUL Q-RxLevMin OPTIONAL, -- Need R q-QualMin Q-QualMin OPTIONAL, -- Need R q-QualMinOffset INTEGER (1..8) OPTIONAL -- Need R } OPTIONAL, -- Need S cellAccessRelatedInfo CellAccessRelatedInfo, connEstFailureControl ConnEstFailureControl OPTIONAL, -- Need R si-SchedulingInfo SI-SchedulingInfo OPTIONAL, -- Need R servingCellConfigCommon ServingCellConfigCommonSIB OPTIONAL, -- Need R ims-EmergencySupport ENUMERATED {true} OPTIONAL, -- Need R eCallOverIMS-Support ENUMERATED {true} OPTIONAL, -- Cond Absent ue-TimersAndConstants UE-TimersAndConstants OPTIONAL, -- Need R
uac-BarringInfo SEQUENCE { uac-BarringForCommon UAC-BarringPerCatList OPTIONAL, -- Need S uac-BarringPerPLMN-List UAC-BarringPerPLMN-List OPTIONAL, -- Need S uac-BarringInfoSetList UAC-BarringInfoSetList, uac-AccessCategory1-SelectionAssistanceInfo CHOICE { plmnCommon UAC-AccessCategory1-SelectionAssistanceInfo, individualPLMNList SEQUENCE (SIZE (2..maxPLMN)) OF UAC-AccessCategory1-SelectionAssistanceInfo } OPTIONAL } OPTIONAL, -- Need R
useFullResumeID ENUMERATED {true} OPTIONAL, -- Need N lateNonCriticalExtension OCTET STRING OPTIONAL, nonCriticalExtension SEQUENCE{} OPTIONAL }
UAC-AccessCategory1-SelectionAssistanceInfo ::= ENUMERATED {a, b, c}
ServingCellConfigCommonSIB ::= SEQUENCE { downlinkConfigCommon DownlinkConfigCommonSIB, uplinkConfigCommon UplinkConfigCommonSIB OPTIONAL, -- Need R supplementaryUplink UplinkConfigCommonSIB OPTIONAL, -- Need R n-TimingAdvanceOffset ENUMERATED { n0, n25560, n39936 } OPTIONAL, -- Need S ssb-PositionsInBurst SEQUENCE { inOneGroup BIT STRING (SIZE (8)), groupPresence BIT STRING (SIZE (8)) OPTIONAL -- Cond Above6GHzOnly }, ssb-PeriodicityServingCell ENUMERATED {ms5, ms10, ms20, ms40, ms80, ms160}, tdd-UL-DL-ConfigurationCommon TDD-UL-DL-ConfigCommon OPTIONAL, -- Cond TDD ss-PBCH-BlockPower INTEGER (-60..50), ... }
DownlinkConfigCommonSIB ::= SEQUENCE { frequencyInfoDL FrequencyInfoDL-SIB, initialDownlinkBWP BWP-DownlinkCommon, bcch-Config BCCH-Config, pcch-Config PCCH-Config, ... }
PCCH-Config ::= SEQUENCE { defaultPagingCycle PagingCycle, nAndPagingFrameOffset CHOICE { oneT NULL, halfT INTEGER (0..1), quarterT INTEGER (0..3), oneEighthT INTEGER (0..7), oneSixteenthT INTEGER (0..15) }, ns ENUMERATED {four, two, one}, firstPDCCH-MonitoringOccasionOfPO CHOICE { sCS15KHZoneT SEQUENCE (SIZE (1..maxPO-perPF)) OF INTEGER (0..139), sCS30KHZoneT-SCS15KHZhalfT SEQUENCE (SIZE (1..maxPO-perPF)) OF INTEGER (0..279), sCS60KHZoneT-SCS30KHZhalfT-SCS15KHZquarterT SEQUENCE (SIZE (1..maxPO-perPF)) OF INTEGER (0..559), sCS120KHZoneT-SCS60KHZhalfT-SCS30KHZquarterT-SCS15KHZoneEighthT SEQUENCE (SIZE (1..maxPO-perPF)) OF INTEGER (0..1119), sCS120KHZhalfT-SCS60KHZquarterT-SCS30KHZoneEighthT-SCS15KHZoneSixteenthT SEQUENCE (SIZE (1..maxPO-perPF)) OF INTEGER (0..2239), sCS120KHZquarterT-SCS60KHZoneEighthT-SCS30KHZoneSixteenthT SEQUENCE (SIZE (1..maxPO-perPF)) OF INTEGER (0..4479), sCS120KHZoneEighthT-SCS60KHZoneSixteenthT SEQUENCE (SIZE (1..maxPO-perPF)) OF INTEGER (0..8959), sCS120KHZoneSixteenthT SEQUENCE (SIZE (1..maxPO-perPF)) OF INTEGER (0..17919) } OPTIONAL, -- Need R ... }
Followings are the descriptions on some important paramters
For example, sCS15KHZoneT defines monitoring occasions with 15 kHz subcarrier spacing, while higher SCS values like sCS120KHZZoneSixteenthT allow finer paging locations Followings are the high level design principle of this configuration The High-Level Logic: The "Post Office" AnalogyThis analogy explains the high-level logic of paging configuration very well. The UE does not check the network randomly. It follows a structured timing rule, just like a person checking a post office box according to a fixed personal schedule. The first concept is the Paging Cycle. This is the largest timing unit in the paging design. It determines how often the UE wakes up to look for possible paging. In the post office analogy, this is the overall schedule of how often you decide to visit the post office. You may decide to go once every 32 days, once every 64 days, or once every 128 days. In real paging, the values are much shorter, but the idea is the same. This parameter controls the basic wake-up frequency. The next concept is the Paging Frame. Even if you decide to visit only once in a while, you still need to know which exact day in that larger period you will go. The Paging Frame provides that selection. It identifies the specific radio frame in which the UE should monitor for paging. In the analogy, this is like saying that within a monthly schedule, you will go on a particular day rather than on any random day. This helps distribute paging load across different UEs so that they do not all wake up at the same instant. Then comes the Paging Occasion. This is a finer timing point inside the selected Paging Frame. A radio frame is still a relatively large timing window, so the UE needs to know the exact monitoring moment within that frame. In the analogy, after deciding which day to visit the post office, you also decide the exact time, such as 8 AM, 12 PM, or 4 PM. The UE uses this rule to determine the exact time-domain opportunity where it should check for paging. This layered timing structure is important because it lets the network manage a very large number of UEs efficiently. At the highest level, the Paging Cycle controls how often the UE wakes up. At the next level, the Paging Frame chooses the specific frame. At the finest level, the Paging Occasion selects the exact monitoring point inside that frame. From UE perspective, the behavior is systematic. UE first determines its paging cycle. Based on that cycle, it calculates which paging frame belongs to it. Then within that frame, it determines the exact paging occasion. Only at that exact moment does it wake up and monitor the control channel. If no paging is detected, it goes back to sleep immediately. This is why paging is both power efficient and scalable. The UE does not waste power by checking continuously. The network does not waste resources by broadcasting to every UE individually at arbitrary times. Instead, both sides follow the same shared schedule. In simple terms, the Paging Cycle answers how often to check, the Paging Frame answers on which specific frame to check, and the Paging Occasion answers at what exact moment inside that frame to check Imagine you have a PO Box. To save gas, you don't drive to the post office every 5 minutes.
Breaking Down the ParametersThe paging configuration parameters are broadcast in SIB1. This is the basic rule set that every UE in the cell must follow. Once the UE reads SIB1, it knows exactly when and where to check for paging. Without this information, the UE cannot align its wake-up timing with the network. The defaultPagingCycle defines the fundamental wake-up interval. This parameter directly controls the trade-off between latency and battery consumption. If the cycle is short, the UE wakes up more frequently. This allows faster response to incoming calls or data. However, it increases power consumption. If the cycle is long, the UE sleeps longer and saves battery. But the response time becomes slower. In practical terms, values like rf32 mean the UE wakes up roughly every 320 ms. Values like rf256 mean the UE wakes up roughly every 2.56 seconds. This parameter sets the overall rhythm of UE wake-up behavior. The nAndPagingFrameOffset determines which specific radio frame the UE should monitor within the paging cycle. Even if all UEs share the same paging cycle, they should not wake up at the same exact moment. That would create a burst of load on the network. To avoid this, the network distributes UEs across different paging frames. The offset acts like a shift applied to each UE. As a result, different UEs wake up at different frames even though they follow the same cycle length. This spreads the load evenly across time. Once the UE identifies its paging frame, it needs to determine the exact monitoring opportunity within that frame. This is defined by ns and PDCCH monitoring configuration. The ns parameter defines how many paging occasions exist within a paging frame. For example, ns can be 1, 2, or 4. This means the UE may have one or multiple chances within that frame to detect paging. Increasing ns provides more opportunities, which can improve reliability or flexibility, but it also slightly increases UE monitoring effort. The firstPDCCH-Monitoring configuration defines the exact time-frequency location where the UE should look for paging indication. This is the most granular level of control. It tells the UE which symbols and which search space on the PDCCH should be monitored. Because 5G supports multiple subcarrier spacings, the exact timing must be precisely defined. The UE must align its monitoring down to very fine resolution in the radio frame. From UE perspective, the process is sequential. UE reads SIB1. UE calculates its paging cycle. UE determines its paging frame using the offset. UE identifies the paging occasion based on ns. UE monitors the PDCCH at the exact configured symbols. If no paging is detected, it goes back to sleep. This multi-level configuration allows the system to scale to a large number of UEs while keeping power consumption low and maintaining predictable paging latency. The Paging Cycle (defaultPagingCycle)This is the "Sleep vs. Speed" trade-off.
Paging Frame & Offset (nAndPagingFrameOffset)To prevent every single phone in a city from waking up at the exact same millisecond (which would crash the tower), the network spreads them out.
Paging Occasions (ns and firstPDCCH...)Once a phone identifies its "Paging Frame," it looks for the Paging Occasion (PO).
Why this matters for 5GThis matters in 5G because the service requirements are much wider than in earlier systems. In LTE, paging behavior was more uniform. Most devices followed a relatively fixed style of operation, and the paging design was less flexible. In 5G, the network has to support many very different UE types. Some UEs are smartphones that require fast reaction for voice calls, messaging, and interactive data. Some UEs are low-power sensors that may need to remain asleep for a very long time to preserve battery. Some UEs may be in RRC_INACTIVE and need fast connection resumption. Because of these different needs, paging cannot be designed as a one-size-fits-all mechanism. This is why the PCCH-Config in SIB1 is important. It gives the network a flexible way to define paging timing and monitoring behavior for the cell. Through this configuration, the network can control how often the UE wakes up, which frame it should monitor, and which exact monitoring opportunity it should use. This flexibility allows the network to balance several design goals at the same time. It can reduce battery consumption for power-sensitive devices. It can maintain low latency for devices that need quick response. It can also distribute paging load efficiently across many UEs so that the control channel is not overloaded. In practical terms, 5G paging is not just about waking up a phone for an incoming call. It is part of a broader system design that supports diverse traffic models, diverse device capabilities, and diverse power-saving requirements. From network perspective, flexible paging configuration means better resource management. From UE perspective, it means the device can remain reachable without wasting unnecessary power. In simple terms, 4G paging was more rigid because the device and service range were narrower. 5G paging is more flexible because the system must support everything from long-sleep IoT devices to highly responsive smartphones. The Paging HierarchyFollowing table recap of what I described above in terms of scale/granularity of each parameter. The paging hierarchy shows how the paging configuration is structured across multiple levels of timing granularity. Each level refines the UE’s wake-up behavior, starting from a coarse interval down to a very precise monitoring point. At the highest level, defaultPagingCycle defines the overall wake-up frequency. This is the macro-level control. It determines how often the UE wakes up to check for paging. A shorter cycle means more frequent wake-ups and lower latency. A longer cycle means fewer wake-ups and better power saving. At the next level, nAndPagingFrameOffset determines which specific radio frame the UE should monitor within that cycle. This is the meso-level control. It distributes UEs across different frames so that not all UEs wake up at the same time. This helps balance network load. At a finer level, ns defines how many paging occasions exist within the selected paging frame. This is the micro-level control. It determines how many opportunities the UE has within that frame to detect paging. More occasions increase flexibility and reliability, but also slightly increase monitoring effort. At the most detailed level, firstPDCCH-Monitoring configuration defines the exact monitoring location in time and frequency. This is the nano-level control. It specifies the exact symbols and search space where the UE should look for paging indication on the PDCCH. This level requires precise alignment with the radio waveform, especially because different numerologies are used in 5G. From UE perspective, these levels are applied step by step. UE first determines how often to wake up using defaultPagingCycle. Then it calculates which frame to monitor using the offset. Then it identifies the paging occasion using ns. Finally, it monitors the exact PDCCH location defined by the monitoring configuration. This hierarchical design allows very fine control over UE behavior. It ensures efficient use of radio resources while maintaining predictable paging performance. In simple terms, the hierarchy answers four questions in order. How often to wake up. Which frame to check. How many chances within that frame. And exactly where to look.
|
||||||||||||||||||||||||||||