- Paging Cycle in GSM
Question:
What is a paging cycle ? How do we determine the value of the paging cycle and how does this value map to specification ?
Answer:
Paging
Cycle is the network wait time for transmission of PAGING REQUEST
messages to the same paging subgroup. Mobile will synchronize to its
paging sub channel (PCH) to check for any pages are associated with its
TMSI.
It is broadcasted as ‘bs_pa_mfrms‘ parameter in ‘control_chan_desc‘ of ‘System Information 3‘ by the network as shown below:Day 10819 14:20:36.718 [A0] 0x512F GSM RR Signaling Message -- System Information Type 3
Channel Type = BCCH (1)
Direction = Downlink
Message Type = System Information Type 3 (27)
Message Length in bytes = 23
L3 Message in Hex:
49 06 1B B7 25 02 F8 01 C7 38 E8 03 1E 54 A0 00 BD 00 00 8F
00 40 4B
Decoded Message:
------------------------------------------------
chan_type = 1 (0x1)
l2_pseudo_len = 18 (0x12)
trans_id_or_skip_ind = 0 (0x0)
prot_disc = 6 (0x6) (GSM_RR_MANAGEMENT)
msg_type = 27 (0x1b)
prot
rr_man_prot
SYSTEM_INFORMATION_3
cell_ident
cell_ident_val = 46885 (0xb725)
loc_area_ident
mcc_1 = 2 (0x2)
mcc_2 = 0 (0x0)
mcc_3 = 8 (0x8)
mnc_3 = 15 (0xf)
mnc_1 = 1 (0x1)
mnc_2 = 0 (0x0)
loc_area_code = 51000 (0xc738)
control_chan_desc
mscr = 1 (0x1)
att = 1 (0x1)
bs_ag_blks_res = 5 (0x5)
ccch_conf = 0 (0x0)
bs_pa_mfrms = 3 (0x3)From 3GPP TS 04.18 Table 10.5.2.11.1 the allowed values of the paging cycle are as follows:-
BS-PA-MFRMS (octet 3)
Bits
3 2 1
0 0 0 2 multiframes period for transmission of PAGING REQUEST messages to the same paging subgroup
0 0 1 3 multiframes period for transmission of PAGING REQUEST messages to the same paging subgroup
0 1 0 4 multiframes period for transmission of PAGING REQUEST messages to the same paging subgroup
.
.
1 1 1 9 multiframes period for transmission of PAGING REQUEST messages to the same paging subgroupThe parameter
bs_pa_mfrms value 0 to 7 map to multiframes value 2 to 9 for e.g.
bs_pa_mfrms value of 3 corresponds to 5 multiframes period - https://qualcomm-cdmatech-support.my.salesforce.com/50130000000WALQ?retURL=%2Fui%2Fsolution%2FSolutionBrowserPage%3Fcid%3D02n30000000DYIn 中找到
NV_ACQ_ORDER_PREF_I , NV browser如何找到这项呢，点击Full Path Name，acq_order_pref就是了。
For more details on these NV
items and different values, please go through the customer doc #
80-VD664-1: Band Preference Settings for GSM/UMTS Targets.
3. RXQUAL:
l1_send.c 02399 gs1:Serving RXQUAL: FULL=7 SUB=0 DTX=1
的RXQUAL测量值相对较好，虽然FULL 一直在 7，但SUB 保持在0 附近。
07:36:37:758 ~ 07:36:54:796 约17 s的时间中
RXQUAL 升高 （4~7 ）之间，误码率较高。导致掉话。rxqual: baike.baidu.com/view/2470407.htm
RxQual（Full/Sub）：下行接收质量
这个事情是这样的，网络存在开启DTX和不开启DTX两种情况，不开启DTX时，网络将会针对手机通话当中所有的信号质量进行测量，此时使用FULL（全局测量），否则使用SUB（局部测量）。FULL的时候所有时隙都会被测量，所以是（4个26复帧中的4个空闲帧除外），SUB ——对12个突发脉冲进行平均（4个SACCH突发脉冲，8个特定位置(52,53,54,55,56,57,58,59)的TCH突发脉冲）
RXQUAL=3时，通话质量尚可，当RXQUAL≥6时，用户基本无法正常通话。如果某个区域RXQUAL为6和7的采样统计数高而RXLEV大于－85dBm的采样数较高，一般可以认为该区域存在干扰。对于网络中存在外源或者频点干扰，可以根据实际情况，调整基站天线方位角、下倾角，也可减小干扰。
RxLev：http://baike.baidu.com/view/3506926.htm，
MSG [04009/01] GSM GPRS GRR/Medium 08:39:35.533 rr_ded_meas_reporting.c 05896 gs1:releasing RXLEV_FULL=40 RXLEV_SUB=35
=35，对应（-110+35）=-75dbm。该区域存在干扰。
高通的xx对这样去判断不太认可。另一个我认识的别的单位的同志要求有几个都是>=6是，认为有效，高通的lulu针对的只有一个=6。
RxQual Bit Error Rate (BER)
6 6.4% < BER < 12.8%
7 12.8% < BER
有的时候RxQual和RxLev都差，这时容易发生小区重选超时消息，最后导致重选被禁掉：
“MSG [04009/01] GSM GPRS GRR/Medium 08:25:42.994 rr_g2w.c 03333 gs2:UTRAN reselection has been inhibited”
4. 查信噪比情况时
对 GSM DSDS L1 Burst Metrics 该消息，QCAT的分析更直观些。
2015 Feb 9 08:39:35.237 [A5] 0x5A6C GSM DSDS L1 Burst Metrics
Subscription ID = 1
---------------------------------------------------------------------------------------------------------------------------------
| FN | CHAN |ARFCN | RSSI | PWR (dBm)| DC[I] | DC[Q] | FREQ | TIME | SNR (dB)|GAIN_STATE|BAND_CLASS |
---------------------------------------------------------------------------------------------------------------------------------
| 788341| FACCH_AFS| 532| 2679164| -65.06| 4| -55| -1| 0| 21.07| 2| 9 (DCS)|
| 788342| FACCH_AFS| 522| 2657295| -64.75| 134| 73| 1| 0| 20.74| 2| 9 (DCS)|
| 788343| FACCH_AFS| 522| 2590813| -64.88| -83| 53| -9| 0| 21.07| 2| 9 (DCS)|
| 788344| FACCH_AFS| 606| 722364| -71.06| 0| 0| 17| 0| 18.44| 2| 9 (DCS)|
Radio Link Failure is related with RLF counter： a)Unsuccessful decoding of SACCH block decrements Radio Link Failure Counter by 1 b)Successful decoding of SACCH block increments Radio Link Failure Counter by 2 c)When Radio Link Failure Counter is 0, then the call will be terminated locally. Spec reference：TS 45008 11.4.2 CTS-MS procedure The aim of determining radio link failure in the CTS-MS is to ensure that calls with unacceptable voice/data quality, which cannot be improved either by RF power control or intra-cell handover, are either re established or released in a defined manner. The radio link failure criterion is based on the radio link counter S_CTS. If the CTS-MS is unable to decode a SACCH message (BFI = 1), S_CTS is decreased by 1. In the case of a successful reception of a SACCH message (BFI = 0) S_CTS is increased by 2. In any case S_CTS shall not exceed the value of CTS_RADIO_LINK_TIMEOUT. If S_CTS reaches 0 a CTS radio link failure shall be declared.
6. 漫游
15：57 ====>RAU OTA LOG [0x7B3A/008/008]GMM/Routing Area Update Request 07:57:23.366 Subscription ID: 0, Direction: MS To Network, Length: 63 =================================================================== 到此未发现ATT/RAU 返回。 未发现Paging消息。
上面是一同事分析的，测试地在外地，北京的卡漫游过去。
6. GSM RSSI
>103 就超过阈值了
开始通话时在 GSM1800 小区从 16：23：44 切换到GSM900 小区此后1分在 ARFCN 7416：24：52 ARFCN 81 后不停LU， 根据测试工程师描述此后掉话。 对比小区RSSI MSG [00090/01] MMODE QMI/Medium 08:24:26.730 qm_meas.c 00920 GSM rssi 101, err_rate 7
7. 无法拨通电话
看log
PCCH/Paging 02:23:55.266 Radio Bearer ID: 0, Freq: 37900, SFN: 385
LTE RRC/High/PAG 02:23:55.266 lte_rrc_paging.c 01169 UE id did not match - false page
无法寻呼到手机，最后是同事改了nv解决的问题。