Paging is the mechanism in which Network tells UE saying "I have something for you". Then UE decode the content (Paging Cause) of the Paging message and UE has to initiate the appropriate the procedure.
In most cases, this paging process happens while UE is in idle mode. This means that UE has to monitor whether the networking is sending any paging message to it and it has to spend some energy(battery) to run this "Monitoring" process.
If I have to run this "Monitoring" process continously even in the idle mode, isn't it too much waste of engergy ?Yes, it is.
Is there any way to prevent this kind of energy waste ? There would be no way to prevent this envergy consumption completely (if you can come out with any idea to prevent this completely, you don't need to read this any more.. just do early retire and enjoy your life whereever you want to go with huge money coming out of your patent -:), but there would be some way to reduce the consumption in great degree.What is it ? There may be many different way to do this.. but most common method (probably easiest to realize) is to make some 'contract' between UE and Network.What kind of contract it would be like ? It is like "Hey.. Mr. Net.. don't send the paging method continuously.. just transmit it in a kind of burst mode with a certain interval. I will go sleep when you are not transmitting Paging and I will just wake up exactly at the time you are transmitting the paging message".This way UE can save the battery while it is in sleep and can get the paging message as well. It means that UE is recieving some data from the network "discontinously". This kind of reception mechanism is called DRX (Discontinous Reception).Here we have an important question. How can UE knows the exact timing when the Network send the paging ? The simplest solution for this would be to make another contract about "Paging transmission timing". you see the logic ?
The rest of this page follows that contract in order. It shows where the UE learns the paging cycle, how it works out its own paging frame and subframe, how it recognises its identity in the message, and what four real Paging messages look like.
Followings are the topics to be covered in this page.
- Overview on Paging Mechanism
- Paging Parameters in SIB2
- Paging Occasion and Paging Frame
- UE ID in Paging Message
- TTCN for Paging Cycle Calculation
- Paging in Connected Mode
- Examples of Paging Message
- Reference
Overview on Paging Mechanism
Why does an idle UE need a fixed schedule to be paged? In idle mode the UE has no dedicated channel, so the network cannot reach it directly. The UE therefore wakes up at agreed times and checks the PDCCH, and the three steps below make up that cycle.
i) During the idle mode, UE gets into and stay in sleeping mode defined in DRX cycle (Discontinous Receive Cycle). (This DRX is cycle is defined in SIB2)
ii) UE periodically wake up and monitor PDCCH in order to check for the presence of a paging message(UE looks for any information encrypted by P-RNTI)
iii) If the PDCCH indicates that a paging message is transmitted in the subframe, then UE needs to demodulate the PCH to see if the paging message is directed to it.
The P-RNTI in step ii) is one fixed value, FFFE, shared by all UEs (36.321 v19.3.0 clause 7.1). The eNB scrambles the CRC of the PDCCH with it, so the UE finds the Paging message with a CRC check. Nothing is encrypted at this stage. The PDCCH uses DCI format 1A or 1C, and it points to the PDSCH that carries the PCH (36.213 v19.4.0 clause 7.1).
Note : Paging messages are sent by a MME to all eNodeBs in a Tracking Area and those eNodeBs in a Tracking Area is transmitting the same paging message.
Note : Each eNodeB can contain cells belonging to different tracking areas but each cell can only belong to one Tracking Area.
The MME does not know the cell of an idle UE, only its tracking area list. It therefore sends the S1AP Paging to every eNB that serves a tracking area in that list, and each eNB then sends the Paging message in every cell of those tracking areas. That is why paging costs radio resources in many cells for one UE.
Sleep, wake up, check the PDCCH : the DRX cycle in idle mode.P-RNTI = FFFE : the same value for all UEs; the Paging message itself names the UE.Paged in the whole TA list : the MME does not know the cell of an idle UE.
Paging Parameters in SIB2
Where do the cycle length and the paging density come from? Both are broadcast in SIB2, in pcch-Config inside radioResourceConfigCommon. The capture below shows the two values one cell sent, with the lines that do not concern paging cut out by the author.
Decoded RRC message from a tester log,
BCCH-DL-SCH-Message ::= SEQUENCE
+-message ::= CHOICE [c1]
+-c1 ::= CHOICE [systemInformation]
+-systemInformation ::= SEQUENCE
+-criticalExtensions ::= CHOICE [systemInformation-r8]
+-systemInformation-r8 ::= SEQUENCE [0]
+-sib-TypeAndInfo ::= SEQUENCE OF SIZE(1..maxSIB[32]) [1]
| +- ::= CHOICE [sib2]
| +-sib2 ::= SEQUENCE [00]
......
| | +-pcch-Config ::= SEQUENCE
| | | +-defaultPagingCycle ::= ENUMERATED [rf128]
| | | +-nB ::= ENUMERATED [oneT]
defaultPagingCycle = rf128 means a cycle of 128 radio frames, which is 1.28 s. nB = oneT means that nB equals T, so there are as many paging occasions per cycle as there are radio frames. The next section turns these two values into a paging frame and a paging subframe for each UE.
Now it's time to get into the official specification.
Following is based on
PCCH-Config ::= SEQUENCE {
defaultPagingCycle ENUMERATED {
rf32, rf64, rf128, rf256},
nB ENUMERATED {
fourT, twoT, oneT, halfT, quarterT, oneEighthT,
oneSixteenthT, oneThirtySecondT}
}
PCCH-Config-v1310 ::= SEQUENCE {
paging-narrowBands-r13 INTEGER (1..maxAvailNarrowBands-r13),
mpdcch-NumRepetition-Paging-r13 ENUMERATED {r1, r2, r4, r8, r16, r32, r64, r128, r256},
nB-v1310 ENUMERATED {one64thT, one128thT, one256thT}
OPTIONAL -- Need OR
}
PCCH-Config-v1700 ::= SEQUENCE {
ranPagingInIdlePO-r17 ENUMERATED {true}
}
The Release 8 structure is unchanged: four cycle lengths from rf32 to rf256, and eight values of nB from fourT to oneThirtySecondT. PCCH-Config-v1310 adds the paging narrowbands, the MPDCCH repetitions and three smaller nB values for eMTC UEs. PCCH-Config-v1700 adds ranPagingInIdlePO-r17, which lets a UE in RRC_INACTIVE use its idle mode T to find its paging subframe (36.304 v19.2.0 clause 7.1). Both extensions sit in extension groups of RadioResourceConfigCommonSIB.
rf128 = 1.28 s : the default paging cycle T of this cell.oneT : nB = T, one paging frame in every radio frame.-v1310 and -v1700 extensions : eMTC paging and RRC_INACTIVE; the Release 8 fields are unchanged.
Paging Occasion and Paging Frame
There are two most important terminologies which is PF(Paging Frame) and PO(Paging Occasion). 3GPP 36.304 - [7 Paging] explain this two terms as follows :
* Paging Occasion (PO) is a subframe where there may be P-RNTI transmitted on PDCCH addressing the paging message.
* Paging Frame (PF) is one Radio Frame, which may contain one or multiple Paging Occasion(s).
As you know, LTE has two timing units as many of other technology. Timing Unit in Frame scale (SFN : System Frame Number) is one unit and the timing unit in subframe level (Subframe Number). It means that you have to know both SFN and Subframe Number to locate exact position in LTE time domain. Regarding the paging cycle, PF(Paging Frame) + PO(Paging Occasion) let you know the exact timing when UE has to wake up to catch the paging message being sent to it.
Let's tackle the PF first.
PF = SFN mod T = (T div N) x (UE_ID mod N)
Then where does T come from ? According to 36.304, T is defined as follows :
T is DRX cycle of the UE. T is determined by the shortest of the UE specific DRX value, if allocated by upperlayers, and a default DRX value broadcast in system information . If UE specific DRX is not configured by upperlayers, the default value is applied.
It means UE can get the T from two different source, one from the system information (SIB2, IE defaultPagingCycle) and the one from upper layer. Then which value does UE has to use ? It depends on the situation. If upper layer send the value, it use the value from the uppder layer, otherwise UE has to use the value from SIB2.
Then let's think about where does other values come from. These values are defined as follows in the specification.
N = min(T, nB), which means the smaller one among T and nB.
nB can be any one of 4T, 2T, T, T/2, T/4, T/8, T/16, T/32, which comes from SIB2 (IE nB).
|
nB |
4T |
2T |
T |
1/2 T |
1/4 T |
1/8 T |
1/16 T |
1/32 T |
|
N |
1 |
1 |
1 |
1/2 |
1/4 |
1/8 |
1/16 |
1/32 |
There is some rare cases where UE specifies "UE Specific DRX value" (as described in 36.304) via Attach Request or Tracking Area Update Request as shown below.
Attach Request capture. The DRX parameter IE 5C asks for T = 32, which is shorter than the rf128 of the SIB2 capture above, so this UE would use T = 32.
Refer to 24.008 10.5.5.6 DRX parameter for the details.
< 24.008 Table 10.5.139/3GPP TS 24.008: DRX parameter information element >
UE_ID = IMSI mod 1024, where IMSI should be used in Decimal format and is stored in USIM.
By this, we got PF now. Then what is the next step ? We have to get PO (Paging Occasion).
36.304 defines PO as follows :
36.304 subframe pattern for FDD. Ns picks the row, and i_s picks the column.
As you see the table,
i) When Ns = 1, there can be only one paging occation (only one subframe where paging message is carried) within a Paging Frame and the subframe number is 9.
ii) When Ns = 2, there can be two paging occations (two subframes where paging message is carried) within a Paging Frame and the subframe number is 4 and 9.
iii) When Ns = 4, there can be four paging occations (four subframes where paging message is carried) within a Paging Frame and the subframe number is 0,4,5 and 9.
From the table, we can figure out PO if we get i_s. Then how to get i_s ?
We already explained how to get N. We only have to know Ns now. 36.304 defines Ns as follows:
Ns = max(1, nB/T), which means that Ns is the larger value between 1 and NB/T.
|
nB |
4T |
2T |
T |
1/2 T |
1/4 T |
1/8 T |
1/16 T |
1/32 T |
|
Ns |
4 |
2 |
1 |
1 |
1 |
1 |
1 |
1 |
The page has not yet given i_s itself. 36.304 v19.2.0 clause 7.1 gives it as i_s = floor(UE_ID/N) mod Ns. When Ns is 1, i_s is always 0 and the PO is subframe 9. The UE_ID therefore chooses both the paging frame, through UE_ID mod N, and the paging subframe, through floor(UE_ID/N).
Take the two captures on this page together. The IMSI of Example 2 is 001010123456789, which is the decimal number 1010123456789, so UE_ID = 1010123456789 mod 1024 = 277. The SIB2 capture gives T = 128 and nB = T, so N = 128 and Ns = 1. The PF is then SFN mod 128 = 277 mod 128 = 21, which means SFN 21, 149, 277 and so on, and the PO is subframe 9 of each of them.
For TDD, the subframe pattern is different, because subframes 4 and 9 can be uplink subframes. The table below compares the two patterns of 36.304 v19.2.0 clause 7.2 for P-RNTI on the PDCCH.
Ns | FDD, i_s = 0 / 1 / 2 / 3 | TDD, i_s = 0 / 1 / 2 / 3 |
1 | 9 | 0 |
2 | 4 / 9 | 0 / 5 |
4 | 0 / 4 / 5 / 9 | 0 / 1 / 5 / 6 |
The current 36.304 also extends the formulas. The value of nB can go down to T/256, and for NB-IoT to T/1024. UE_ID is 5G-S-TMSI mod 1024 when the cell is connected to 5GC, and IMSI mod 4096 or mod 16384 when the P-RNTI is sent on NPDCCH or MPDCCH. A UE with an extended DRX value of 512 radio frames uses T = 512. The IMSI is always read as a decimal number, so IMSI 12 means twelve, not 1 x 16 + 2.
SFN mod T = (T div N) x (UE_ID mod N) : the paging frame.i_s = floor(UE_ID/N) mod Ns : the paging subframe, from the FDD or TDD pattern.UE_ID = IMSI mod 1024 : UE_ID 277 gives SFN 21 and subframe 9 with rf128 and oneT.Shortest T wins : the UE specific DRX in the Attach Request against defaultPagingCycle.
UE ID in Paging Message
Once the UE has woken up in its PO and found a Paging message, how does it know the message is meant for it? One Paging message can page several UEs, so the UE compares each PagingRecord with its own identity.
If you see the ue-identity field (IE) of Paging message, you will see there are two choices, s-TMSI and IMSI.
Which type of UE ID is commonly used. The answer is s-TMSI. If everything is normal, Network send Paging with s-TMSI, but if something (e.g, Network Failure) happens during registration and it fails to allocate TMSI to the UE, NW would send Paging with IMSI.
If UE get the paging with IMSI, it should tear down all the existing Bearer and delete TAI, TAI List, KSIASMI and get into EMM-DEREGISTERED status. And then redo 'Attach Request'.
Following is based on
Paging ::= SEQUENCE {
pagingRecordList PagingRecordList OPTIONAL, -- Need ON
systemInfoModification ENUMERATED {true} OPTIONAL, -- Need ON
etws-Indication ENUMERATED {true} OPTIONAL, -- Need ON
nonCriticalExtension Paging-v890-IEs OPTIONAL
}
Paging-v890-IEs ::= SEQUENCE {
lateNonCriticalExtension OCTET STRING OPTIONAL,
nonCriticalExtension Paging-v920-IEs OPTIONAL
}
Paging-v920-IEs ::= SEQUENCE {
cmas-Indication-r9 ENUMERATED {true} OPTIONAL, -- Need ON
nonCriticalExtension Paging-v1130-IEs OPTIONAL
}
Paging-v1130-IEs ::= SEQUENCE {
eab-ParamModification-r11 ENUMERATED {true} OPTIONAL, -- Need ON
nonCriticalExtension Paging-v1310-IEs OPTIONAL
}
Paging-v1310-IEs ::= SEQUENCE {
redistributionIndication-r13 ENUMERATED {true} OPTIONAL, -- Need ON
systemInfoModification-eDRX-r13 ENUMERATED {true} OPTIONAL, -- Need ON
nonCriticalExtension Paging-v1530-IEs OPTIONAL
}
Paging-v1530-IEs ::= SEQUENCE {
accessType ENUMERATED {non3GPP} OPTIONAL, -- Need ON
nonCriticalExtension Paging-v1610-IEs OPTIONAL
}
Paging-v1610-IEs ::= SEQUENCE {
pagingRecordList-v1610 PagingRecordList-v1610 OPTIONAL, -- Need ON
uac-ParamModification-r16 ENUMERATED {true} OPTIONAL, -- Need ON
nonCriticalExtension Paging-v1700-IEs OPTIONAL
}
Paging-v1700-IEs ::= SEQUENCE {
pagingRecordList-v1700 PagingRecordList-v1700 OPTIONAL, -- Need ON
nonCriticalExtension SEQUENCE {} OPTIONAL
}
PagingRecordList ::= SEQUENCE (SIZE (1..maxPageRec)) OF PagingRecord
PagingRecord ::= SEQUENCE {
ue-Identity PagingUE-Identity,
cn-Domain ENUMERATED {ps, cs},
...
}
PagingUE-Identity ::= CHOICE {
s-TMSI S-TMSI,
imsi IMSI,
...,
ng-5G-S-TMSI-r15 NG-5G-S-TMSI-r15,
fullI-RNTI-r15 I-RNTI-r15
}
IMSI ::= SEQUENCE (SIZE (6..21)) OF IMSI-Digit
IMSI-Digit ::= INTEGER (0..9)
S-TMSI ::= SEQUENCE {
mmec MMEC,
m-TMSI BIT STRING (SIZE (32))
}
PagingRecordList-v1610 ::= SEQUENCE (SIZE (1..maxPageRec)) OF PagingRecord-v1610
PagingRecord-v1610 ::= SEQUENCE {
accessType-r16 ENUMERATED {non3GPP} OPTIONAL, -- Need ON
mt-EDT-r16 ENUMERATED {true} OPTIONAL -- Need ON
}
PagingRecordList-v1700 ::= SEQUENCE (SIZE (1..maxPageRec)) OF PagingRecord-v1700
PagingRecord-v1700 ::= SEQUENCE {
pagingCause-r17 ENUMERATED {voice} OPTIONAL -- Need ON
}
One message carries up to maxPageRec = 16 records. The S-TMSI is the 8-bit MMEC plus the 32-bit M-TMSI, and cn-Domain tells the UE whether the core network has PS data or a CS call, for example a CSFB call. Later releases added ng-5G-S-TMSI-r15 and fullI-RNTI-r15 for LTE connected to 5GC and for RAN paging in RRC_INACTIVE. The -v1700 extension adds pagingCause-r17 with the value voice.
24.301 v20.0.0 clause 5.6.2.2.2 treats paging with IMSI as an abnormal procedure for error recovery. The UE locally detaches, deletes the GUTI, the last visited TAI, the TAI list and KSIASME, and enters EMM-DEREGISTERED. It then answers only with an Attach Request, so the network does not run the paging timers T3413 and T3415 for this case.
Up to 16 PagingRecords : each with an identity and a CN domain.S-TMSI normally, IMSI only for recovery : paging with IMSI leads to a new attach.5GC identities from Release 15 : ng-5G-S-TMSI-r15 and fullI-RNTI-r15.
TTCN for Paging Cycle Calculation
Even though I tried to explain clearly, exact paging cycle calcuation is pretty confusing procedures. If you are interested in exact steps of Paging Cycle Calculation, I would recommend you to refer to TTCN source code from ETSI.
Refer to following two functions in EUTRA_Paging.ttcn
i) function f_EUTRA_GetPagingCycleValue ( DefaultPagingCycle_Type p_PagingCycle)
ii) function f_EUTRA_Calculate_PF_PO ( SystemFrameNumber_Type p_Sfn,
DefaultPagingCycle_Type p_T,
PCCH_Config.nB p_Nb,
hexstring p_Imsi,
EUTRA_FDD_TDD_Mode_Type p_Fdd_Tdd )
Refer to Where can I get TTCN and Viewer ? if you want to get TTCN source code and TTCN Viewer.
These functions come from the LTE conformance test suites of 36.523-3, which ETSI also publishes. The test system uses them to decide when to send each Paging message, so they follow the formulas of the section above. The p_Fdd_Tdd parameter selects the FDD or TDD subframe pattern. The IMSI arrives as a hexstring, and it has to be read as a decimal number before the mod 1024, as 36.304 requires.
Why does a test system need this exact calculation? A UE reads only its own PO, so a Paging message sent one subframe early or late is never seen. The test would then fail although the UE is correct. The functions take the same three inputs as the formulas above: T and nB from SIB2, and the IMSI of the test SIM. With the SIB2 and IMSI of this page, they return SFN 21 and subframe 9. The FDD or TDD choice matters as well. With Ns = 2, an FDD cell pages in subframe 4 or 9, while a TDD cell pages in subframe 0 or 5, so one wrong mode moves every Paging message.
f_EUTRA_GetPagingCycleValue : turns defaultPagingCycle into T.f_EUTRA_Calculate_PF_PO : applies the PF and i_s formulas for FDD or TDD.
Paging in Connected Mode
In most case, Paging message is transmitted from network and monitored by UE while UE is in Idle mode. But there are some cases where Paging is transmitted and should be monitored while UE is in Communication State. In this case how often (meaning at which timing) UE has to monitor Paging ? In case of WCDMA, it was simple because when UE is in connected mode Paging is delivered to UE via DCCH. So UE doesn't care about Paging detection timing (actually UE does not monitor PCCH unless UE is in PCH), but in LTE UE has to get the Paging through PCCH regardless of whether it is in Idle mode or Connected mode. Therefore, in case of LTE monitoring timing of Paging need to be considered even in the connected mode.
There are roughly two different types of Paging. One is a Paging which is for only one specific UE and the other type is the Paging that applies to all UEs which are in a certain area (e.g, Tracking Area). One example of the paging that applies to all the UEs in a certain area is PWS message like CMAS/ETWS etc.
The behavior for each of these cases can be a little different between UE and Network.
UE
A connected UE does not need a Paging message to be reached, because it already has a dedicated connection. It still reads paging for notifications that are sent to every UE in the cell, as the two cases below show.
i) For Paging specific to the UE : UE would monitor Paging at a specific timing as described above in this page.
ii) For Paging common to all the UE (like CMAS): ETWS and/or CMAS capable UEs in RRC_CONNECTED shall attempt to read paging at least once every defaultPagingCycle to check whether ETWS and/or CMAS notification is present or not (36.331, section 5.2.1.3).
Network
The network side is the mirror of the UE side. The eNB cannot see which UEs in the cell will read which PO, so a notification meant for all of them has to reach every PO that any UE may monitor.
i) For Paging specific to the UE : Networ would transmit the Paging at a specific timing as described above in this page.
ii) For Paging common to all the UE (like CMAS): Since Network does not know which UE in the area support CMAS/ETWS and which UE is camped on, the network may need to send paging messages in every paging occasion used in the cell to let (possible) UE's know there's an ETWS or CMAS notification being broadcast. (This statement is from LTE University(http://lteuniversity.com/ask_the_expert/f/59/t/3898.aspx ) This is pretty reasonable idea and I agree with this, but I haven't confirmed this in 3GPP spec.)
36.331 v19.3.0 still carries the UE rule in clause 5.2.1.3. It now excludes BL UEs, UEs in CE and NB-IoT UEs, which receive these notifications in other ways. The same clause gives a basis for the network behaviour as well. An idle UE checks for systemInfoModification at least modificationPeriodCoeff times in each modification period, so the eNB has to repeat the indication across the POs of that period. Clause 5.3.2.1 says only that E-UTRAN sends the Paging message in the UE's paging occasion.
Connected UEs read paging at least once per defaultPagingCycle : for ETWS and CMAS, 36.331 clause 5.2.1.3.Notifications for all UEs : repeated in the POs of the cell.
Examples of Paging Message
What does a real Paging message look like? The four captures below cover the two UE identities, and two messages with no identity at all: one for ETWS and one for a system information change.
Example 1 - Paging with s-TMSI
This is the usual case. The pagingRecordList carries one record with the S-TMSI, MMEC 00000001 and M-TMSI 1, and cn-Domain ps. The bits [1000] after paging are the presence bits of the four optional fields, so only the record list is present.
Decoded RRC message from a tester log,
PCCH-Message ::= SEQUENCE
+-message ::= CHOICE [c1]
+-c1 ::= CHOICE [paging]
+-paging ::= SEQUENCE [1000]
+-pagingRecordList ::= SEQUENCE OF SIZE(1..maxPageRec[16]) [1] OPTIONAL:Exist
| +-PagingRecord ::= SEQUENCE
| +-ue-Identity ::= CHOICE [s-TMSI]
| | +-s-TMSI ::= SEQUENCE
| | +-mmec ::= BIT STRING SIZE(8) [00000001]
| | +-m-TMSI ::= BIT STRING SIZE(32) [00000000000000000000000000000001]
| +-cn-Domain ::= ENUMERATED [ps]
+-systemInfoModification ::= ENUMERATED OPTIONAL:Omit
+-etws-Indication ::= ENUMERATED OPTIONAL:Omit
+-nonCriticalExtension ::= SEQUENCE OPTIONAL:Omit
Example 2 - Paging with IMSI
Here the network pages with the IMSI, as it does when the S-TMSI is not available. The 15 digits 001010123456789 are MCC 001 and MNC 01, the test PLMN, and they give the UE_ID of 277 worked out above.
Decoded RRC message from a tester log,
PCCH-Message ::= SEQUENCE
+-message ::= CHOICE [c1]
+-c1 ::= CHOICE [paging]
+-paging ::= SEQUENCE [1000]
+-pagingRecordList ::= SEQUENCE OF SIZE(1..maxPageRec[16]) [1] OPTIONAL:Exist
| +-PagingRecord ::= SEQUENCE
| +-ue-Identity ::= CHOICE [imsi]
| | +-imsi ::= SEQUENCE OF SIZE(6..21) [15]
| | +-IMSI-Digit ::= INTEGER (0..9) [0]
| | +-IMSI-Digit ::= INTEGER (0..9) [0]
| | +-IMSI-Digit ::= INTEGER (0..9) [1]
| | +-IMSI-Digit ::= INTEGER (0..9) [0]
| | +-IMSI-Digit ::= INTEGER (0..9) [1]
| | +-IMSI-Digit ::= INTEGER (0..9) [0]
| | +-IMSI-Digit ::= INTEGER (0..9) [1]
| | +-IMSI-Digit ::= INTEGER (0..9) [2]
| | +-IMSI-Digit ::= INTEGER (0..9) [3]
| | +-IMSI-Digit ::= INTEGER (0..9) [4]
| | +-IMSI-Digit ::= INTEGER (0..9) [5]
| | +-IMSI-Digit ::= INTEGER (0..9) [6]
| | +-IMSI-Digit ::= INTEGER (0..9) [7]
| | +-IMSI-Digit ::= INTEGER (0..9) [8]
| | +-IMSI-Digit ::= INTEGER (0..9) [9]
| +-cn-Domain ::= ENUMERATED [ps]
+-systemInfoModification ::= ENUMERATED OPTIONAL:Omit
+-etws-Indication ::= ENUMERATED OPTIONAL:Omit
+-nonCriticalExtension ::= SEQUENCE OPTIONAL:Omit
Example 3 - Paging for ETWS
This message pages no UE at all. The presence bits [0110] show that systemInfoModification and etws-Indication are present, so every UE that reads it re-acquires SIB1 and then the ETWS SIBs, SIB10 and SIB11.
Decoded RRC message from a tester log,
PCCH-Message ::= SEQUENCE
+-message ::= CHOICE [c1]
+-c1 ::= CHOICE [paging]
+-paging ::= SEQUENCE [0110]
+-pagingRecordList ::= SEQUENCE OF OPTIONAL:Omit
+-systemInfoModification ::= ENUMERATED [true] OPTIONAL:Exist
+-etws-Indication ::= ENUMERATED [true] OPTIONAL:Exist
+-nonCriticalExtension ::= SEQUENCE OPTIONAL:Omit
Example 4 - Paging for system Info Modification
The last message carries only systemInfoModification, with presence bits [0100]. It tells the UEs that the system information will change at the next modification period boundary, without naming any UE.
Decoded RRC message from a tester log,
RRC_LTE:PCCH-Message
PCCH-Message ::= SEQUENCE
+-message ::= CHOICE [c1]
+-c1 ::= CHOICE [paging]
+-paging ::= SEQUENCE [0100]
+-pagingRecordList ::= SEQUENCE OF OPTIONAL:Omit
+-systemInfoModification ::= ENUMERATED [true] OPTIONAL:Exist
+-etws-Indication ::= ENUMERATED OPTIONAL:Omit
+-nonCriticalExtension ::= SEQUENCE OPTIONAL:Omit
s-TMSI or IMSI in pagingRecordList : for one UE at a time.etws-Indication and systemInfoModification : for every UE in the cell, with no record list.The bits after paging : the presence of the four optional fields.
Reference
[1] 3GPP TS 36.304 v19.2.0 - clause 7.1, Discontinuous Reception for paging, and clause 7.2, Subframe Patterns
[2] 3GPP TS 36.331 v19.3.0 - clauses 5.2.1.3 and 5.3.2, and the ASN.1 of Paging and PCCH-Config
[3] 3GPP TS 24.301 v20.0.0 - clause 5.6.2.2.2, Paging for EPS services through E-UTRAN using IMSI
[4] 3GPP TS 24.008 - clause 10.5.5.6, DRX parameter
[5] 3GPP TS 36.321 v19.3.0 - clause 7.1, RNTI values