NR的寻呼机制学习

NR的寻呼机制（一）

这个系列介绍NR的寻呼（Paging）。和随机接入（RandomAccess）相似，在移动通信系统中，寻呼也是必不可少的。寻呼有什么作用呢？简单的说，在大部分时间里，网络不知道终端（MS或UE）“具体”在哪儿，两者之间只有“松散”的“连接”。终端通过随机接入（主动）联系网络，网络通过寻呼（主动）联系终端——“寻呼”中的“寻”就是寻找的意思。按照以往的惯例（挂羊头卖狗肉），我从上古时期说起，希望在5G退网前可以写完。

GSM部分主要参考韩斌杰的《GSM原理及其网络优化》；LTE部分主要参考金辉老师的《深入理解LTE-A》，ShareTechNote的《Paging》；NB-IoT部分主要参考金辉老师的《深入理解NB-IoT》；NR部分主要参考爱立信的《5GNR标准：下一代无线通信技术》、人民邮电出版社的《5G空口特性与关键技术》和《5G移动通信系统设计与标准详解》、金辉老师的《Paging：寻呼流程》和Haykey老师的《5G，4GPaging大比拼》。金辉老师的公众号是“金辉5G”，网站是“”（不积跬步，无以至千里），Haykey老师的公众号是“手机通信问题集锦”，推荐大家关注和学习。本人理论水平有限，也没有无线专业的工作经历，文章难免存在错漏，欢迎各位专家批评和指正。

说起“寻呼”，上世纪末流行过这么个玩意儿，名字就叫“寻呼机”（Pager），那会儿也算是身份的象征吧，人们喜欢把它别在腰间（怕别人看不见呀）。你要是在路上见到哪个人突然一哆嗦，脸上像吃了蜜似的，多半是收到“小甜甜”的呼唤了（过程2）——不过，“小甜甜”要先打电话给寻呼台（过程1），“牛魔王”也要找到电话亭才能回应（过程3）。由上可见，三个过程是相互独立的，靠人的行为连接起来，从某种意义来说，也算是一个完整的“移动通信系统”。“小甜甜”为啥通过寻呼台找“牛魔王”呢？原因是不知道“牛魔王”在哪儿，携带“寻呼机”的用户是会移动的，如果“牛魔王”一天到晚都待在洞里，把座机号告诉“小甜甜”不就得了。不过，这事儿交给寻呼台也没啥不同，寻呼台一样不知道“牛魔王”在哪儿，只能通过广播“寻”人，这就好像村里的大喇叭，一喊全村都听见了——“寻呼”中的“呼”就是呼喊的意思。当然，“牛魔王”要知道找的是他，广播得带上“牛魔王”的名字，为了不暴露身份（万一“牛夫人”听见了呢），使用呼号替代，这就“寻呼标识”。

如果只在村里广播，“牛魔王”在村里能找着，出远门就找不着了。相似的，在多大块地儿能找着用户，取决于寻呼信号的覆盖，这就是“寻呼范围”。对用户来说，“寻呼范围”越大，服务体验越好，但对运营商来说，“寻呼范围”越大，投入成本越高。更糟心的是，寻呼是通过广播实现的，扩大“寻呼范围”不会增加用户容量——好比村里多了几百号人，一个喇叭喊不过来了，加大音量有啥用呢？运营商要打好小算盘（赚钱），还得考虑系统支持的用户数量，这就是“寻呼容量”。

由上可见，“寻呼机”只能接收信号，无法上报位置，因而网络只能广播找人。“大哥大”可以发送信号，为啥也要寻呼呢？个人理解，对用户而言，语音业务需求是间歇性的，一天到晚电话不停的，那是卖保险的——在早期的香港影片中，“大哥大”是身份的象征，有的人爱拎在手里，说不好就是个水壶。别看“大哥大”个头大，电池存不了多少电，还特别耗电。所以，在大多数时候，“大哥大”还是“安安静静”的做个美男子吧。

对终端来说，是为了节省能源，对网络来说，是为了节省资源（你省省吧~）。如果网络一直保持和终端之间的连接，不仅终端受不了（费电），网络也受不了，因为无线资源是有限的。在一个网络中，通常不会出现所有用户同时通话的情况，如果只为通话用户建立连接，网络容量可以远大于连接数量——反过来，如果发生突发事件（比如地震），网络很可能会拥塞，因为有通话需求的用户多了，业务模型和网络规划不同。“大哥大”太遥远了，说一下稍近的GSM吧。在GSM中，MS（MobileStation）大部分时间处于空闲模式（IdleMode），通话时才处于专用模式（DedicatedMode）。更准确的说，如果BSC（BaseStationController）和MS之间存在RR连接（不一定存在业务通道），MS处于专用模式，否则处于空闲模式。RR连接是NAS信令连接的构成部分。反过来，如果MS处于空闲模式，NAS信令连接不存在，MSC（MobileSwitchingCenter）不知道MS在哪个小区（基站），需要通过寻呼找到MS。由上可见，在CS网络中，寻呼是由CN（CoreNetwork），即MSC触发的（CNInitiated）。这么看来，MS有点像绑着“寻呼机”的座机，把过程2和3（前半部分）连接起来，如果把过程1连接上就完美了。GSM是如何实现的呢——MSC替代了寻呼台，“小甜甜”打电话给寻呼台，变成了打给MSC。由于MSC服务范围有限，网络可能部署多个MSC，“牛魔王”开机时在某个MSC（MSC-T）登记，MSC-T再向“牛魔王”的HLR（HomeLocationRegister）登记。“小甜甜”发起呼叫时，GMSC（或MSC-O）向“牛魔王”的HLR查询（SRI），获得“牛魔王”的MSRN（MobileSubscriberRoamingNumber），就可以将呼叫接续到MSC-T。（嗯，这段不是很重要…）

MSC如何寻呼呢？

第一，用什么作为“寻呼标识”呢？我们使用排除法：MSISDN（MobileSubscriberInternationalISDNNumber）不合适，相当于在大喇叭直接喊“牛魔王”，太危险了；IMSI（InternationalMobileSubscriberIdentificationNumber）也不合适，对网络来说，IMSI是用户的永久标识，暴露次数多了，“牛夫人”容易和“牛魔王”联系起来，也不安全。因此，最好的选择，是MSC分配的TMSI（TemporaryMobileSubscriberIdentity），只有MSC和“牛魔王”知道MSISDN和TMSI的对应关系，还可以时不时更换，增加“牛夫人”猜测的难度。GSM协议规定，如果MSC使用TMSI寻呼失败，可以尝试使用IMSI寻呼，取决于运营商策略。第二，“寻呼范围”多大合适呢？这好像是句废话，如果MSC乐意，“寻呼范围”当然可以是MSC服务范围，这称为Global寻呼。不过，这也意味着MSC用户容量受限于空口（和业务模型），不合理。因此，GSM协议将MSC服务范围划分为若干个LA（LocationArea，位置区），在MS附着时，MSC将MS所在LA记录下来，MS有来电（或MT短信）时在对应LA寻呼即可，这称为Local寻呼。如果Local寻呼失败，可以尝试Global寻呼，取决于运营商策略。由此带来的问题是，如果MS移动到新的LA，需要向MSC报告一下，否则MSC在旧的LA找不到MS。因此，空闲模式的MS驻留到新的小区时，如果新的LA和旧的LA不一样，会向MSC发送LocationUpdate——这个过程称为“位置更新”。反过来，空闲模式的MS在同一LA的小区间移动，不会向MSC发送任何东西，MSC不知道MS具体在哪个小区（所以才需要寻呼）。另一个极端，如果MS移动出MSC服务范围，LocationUpdate会被新的MSC收到，新的MSC需要向HLR报告一下，否则呼叫会接续到旧的MSC，也找不到MS。由上可见，LA规划是一件复杂的事，需要考虑用户分布、话务模型和移动模型等因素。如果LA范围太大，包含用户数量过多，容易出现寻呼拥塞（寻呼需求过多）；如果LA范围太小，位置更新次数过多，又会增加信令负荷，且可能影响用户感知（流程冲突导致业务失败）。无论LA范围多大，应尽量选择人员移动较少的地方作为边界。

从高层角度看（上帝视角），寻呼的信令很简单，一来一回就两条消息。MSC向选择LA（MS所在LA，或MSC所有LA）的所有MS发送Paging，对应MS返回PagingResponse。不过，MSC自己是无法广播的（毕竟是Core，这种粗活怎么能干，要保持优雅），只能将Paging发送给BSC，由BSC控制基站（BTS）进行广播。MSC知道LA和BSC的对应关系，而BSC知道LA和小区的对应关系。

在CSFB中，终端（UE）平时待在EPS（EvolvedPacketSystem），通话（MO或MT）时才回到CS（CircuitSwitching）网络，移动性管理主要依赖EPS。终端在EPS进行“联合”（Combined）的附着和位置更新，这可以理解为，MME（MobilityManagementEntity）通过SGS接口“模拟”终端通过A接口进行附着和位置更新。MSC记录终端所在MME。MSC触发寻呼流程时，向MME（而不是BSC）发送Paging，终端返回ExtendServiceRequest作为响应，MME指示终端“Fallback”到CS（示图没有呈现），最后终端在CS返回PagingResponse，后续流程和CS相同。和CS的LA相似，EPS有TA（TrackingArea，跟踪区）。终端联合附着或位置更新时，MME根据TA-LA映射关系找到对应MSC。终端回落CS后，MME失去对终端的控制，后续的事情MME就一无所知了。由于TA和LA不可能完全重叠，终端在MSCPOOL边界收到Paging（EPS），回落CS后，可能重选另一个MSCPOOL的小区，PagingResponse（CS）被另一个MSC接收，需要MTRF（MobileTerminatingRoamingForward）或MTRR（MobileTerminatingRoamingRetry）来拯救呼叫，这里不展开了。这一篇谈GSM寻呼的实现。从高层角度看，寻呼由MSC触发，但从底层角度看，MS接收的信号来自于BTS。MSC管不着，也不想管BTS，于是MSC将寻呼请求（客气一下，其实是要求）传递给BSC，BSC再指挥BTS进行寻呼广播。MSC根据LA（MS所在LA，或MSC所有LA）确定BSC，BSC根据LA确定BTS（和小区），示图只画了1个BSC和1个BTS，实际上，MSC每生成1个寻呼请求，都会有多个BSC和BTS参与——所谓“领导张张嘴，下属跑断腿”啊。GSM引入寻呼，是因为MS会移动。因此，在“概念”上寻呼是一个MM（MobilityManagement）过程。不过，空闲模式的MS和MSC之间没有NAS信令连接（没对上眼），MSC向BSC发送的Paging不是DTAP（DirectTransferApplicationPart）消息（类似于NAS消息），而是BSSMAP（BSSManagementApplicationPart）消息。相似的，BSC和MS之间一开始也没有RR连接，MS确认MSC找的是自己后（寻呼ID匹配），才构成（L3的）PagingRESP，请求建立RR连接，并返回PagingRESP。

在空中接口，MS在PCH（PagingChannel，寻呼信道）接收寻呼。由于寻呼广播需要被小区所有MS听到，PCH映射到“公用”的CCCH（CommonControlChannel，公共控制信道）。反过来，只有网络“呼唤”的MS返回PagingRESP，此时需要“专用”的SDCCH（StandAloneDedicatedControlChannel，独立专用控制信道）——谁让我是“天选之子”呢。在MS和BSC之间，被“呼唤”的MS通过RACH（RandomAccessChannel，随机接入信道）向BTS发送ChannelRequest，BTS再向BSC发送ChannelRequired，以请求SDCCH资源。BSC确认信道资源准备后（ChannelActivation和ChannelActivationACK），向BTS发送ImmediateAssignCommand，BTS再通过AGCH（AccessGrantChannel，接入许可信道）向MS发送ImmediateAssignment，以指派SDCCH资源。在BSC和MSC之间，BSC会向MSC发送CR（ConnectionRequest），请求建立SCCP（SignalingConnectionPart）连接，同时携带（L3的）PagingRESP给MSC。

这里重点关注空口。MS待在空闲模式是可以省电，但如果接不了电话，就只是一块砖头。因此，MS需要持续的监听PCH，以确定是否有自己的来电（寻呼）。问题是，MS无法预知来电（寻呼）的时间（要是能知道，去干算命多好），如果一直竖着耳朵听，也不比专用模式轻松多少。由上，对于特定的MS来说，PCH分布必然不是连续的，这样MS才有歇息的机会。不过，MS歇太久也不合适，接续时间过长会影响（MO）用户的感知（你丫死哪儿去了？）。在说PCH之前，简单说一下GSM的帧结构。GSM应用TDMA（Time-DivisionMultipleAccess，时分复用）技术，1个TDMA帧包含8个时隙，对应8个物理信道。1326个TDMA帧构成1个超帧，包含51个26复帧，或26个51复帧（26x51=1326）。26复帧时间间隔为120ms，用于TCH（SACCH/T）和FACCH等业务信道，51复帧时间间隔约为235ms，用于BCCH、CCCH、SDCCH等控制信道。控制信道的映射关系如上图所示。将51复帧每一个TDMA帧的同一时隙（比如TS0）抽出来，构成一行（1个物理信道）。由于控制信道的交织机制（为了对抗干扰），BCCH、CCCH、SDCCH和SACCH横跨4个TDMA帧。以第一行为例，共包含5个F（频率校正脉冲序列）、5个S（同步脉冲序列）、1个B（BCCH，广播信道）、9个C（CCCH，公共控制信道）和1个N，共5+5+4+4x9+1=51时隙。如果CCCH使用1个物理信道，且不与SDCCH共用，1个BCCH复帧包含9个CCCH块（蓝色格子）；如果CCCH使用1个物理信道，且与SDCCH共用，1个BCCH复帧包含3个CCCH块。

不是所有CCCH都用于PCH，还要预留一些给AGCH（准许接入信道）。BTS通过AGCH指配SDCCH或TCH（TrafficChannel，业务信道），如果没有AGCH，别说语音无路（TCH）可走，寻呼响应（SDCCH）都无法返回，这系统也没啥用了。通过系统参数CCCHCONF（公共控制信道配置）和BSAGBLKRES（准许接入保留块数），MS可以确定PCH的CCCH块数量：如果CCCHCONF为'001'，1个BCCH复帧包含9个CCCH块，PCH的CCCH块数量为9–BSAGBLKRES；如果CCCHCONF不为'001'，1个BCCH复帧包含3个CCCH块，PCH的CCCH块数量为3–BSAGBLKRES。1个51复帧的PCH数量有限，协议又定义了系统参数BSPAMFRMS（寻呼信道复帧数），编码为'001'~'111'，分别表示2~9个51复帧。由此，CCCHCONF、BSAGBLKRES和BSPAMFRMS定义了一个PCH集合，包含PCH数量为((9or3)–BSAGBLKRES)xBSPAMFRMS。以上图为例，如果CCCHCONF不为'001'，BSAGBLKRES为2，BSPAMFRMS为6，集合包含的PCH数量为(9–2)x6=42。

如果要求MS监听每一个PCH，就没必要定义集合了。尽管PCH分布不是连续的，但间隔时间还是太短，MS刚眯一会儿又得竖起耳朵，省不了多少电。因此，GSM引入DRX（DiscontinuousReception，不连续接收）概念，在一个PCH集合中，MS只需要监听1个PCH，在其他时候可以“打盹儿”（测量另说）。更具体的，PCH集合划分为若干个寻呼组（PagingGroup），每组对应1个PCH，称为寻呼子信道。MS确定自己的寻呼组，就可以只在对应的寻呼子信道监听。

打个比方，“牛魔王”住在一个大院（小区）里，每天（PCH集合）都去传达室，看看“小甜甜”有没有来信（寻呼），大多数时候会空手而归。传达室大爷看“牛魔王”这么折腾，告诉他每周五（某个寻呼子信道）去一趟就好，传达室收到给“牛魔王”的信，先保存好，等周五再交给“牛魔王”。大院里的其他人（用户），比如“牛夫人”，告诉她别的天（其他寻呼子信道）去就好。如果大院里人太多，有些人只能安排在同一天（抽屉原理）——这些人就被划入一个组（寻呼组）。这里有个小问题，网络因为找不着MS，所以才寻呼MS——因此，大爷也不能见到“牛魔王”才告诉他，双方需要提前约定。GSM的实现方式，是利用IMSI进行分组——PagingGroup=(IMSImod1000)modN——N表示寻呼子信道的总数。对于特定的某一次寻呼，BSC和MS使用相同的IMSI计算，获得相同的PagingGroup，可以确保MS的寻呼在同一寻呼子信道发送和接收（3GPPTS05.02表达有点复杂，寻呼所在帧号FN满足PagingGroupdiv(NdivBSPAMFRMS)=(FNdiv51)modBSPAMFRMS），寻呼在复帧内的索引PagingBlockIndex=PagingGroupmod(NdivBSPAMFRMS)）。另外，根据IMSI分组，可以均衡PCH的负荷，因为如果用户数足够大，各寻呼组的用户数相近。通常来说，一个LA用户数量可以达到数十万，即使分到若干个寻呼组，单个寻呼子信道的“负担”也挺重的。幸好，一个寻呼子信道（CCCH块）可以同时携带（同一寻呼组）多个用户的寻呼，由于IMSI占用位数比TMSI大，如果全部使用TMSI寻呼，在空中接口，可以比IMSI多一倍容量。不过，无论寻呼ID是IMSI还是TMSI，在A接口，MSC都会将IMSI发送给BSC，用于计算MS的寻呼组。

由上可见，BSPAMFRMS定义了寻呼子信道的循环周期。在一个小区中，如果用户数量（和话务模型）是确定的，BSPAMFRMS越大，寻呼子信道数量越多，每个寻呼子信道分配的用户越少。反过来，BSPAMFRMS越小，寻呼子信道数量越少，每个寻呼子信道分配的用户越多。这么看来，BSPAMFRMS越大越好，尽管不会增加总体寻呼容量，但可以避免寻呼拥塞。不过，凡事都有两面，循环周期过大，也会增加寻呼到达MS时长，最终影响接续时长。沿用前面的例子，如果“小甜甜”周四来信，“牛魔王”周五来正好，如果“小甜甜”周六来信，得过好几天才能到“牛魔王”手里。如果BSPAMFRMS再大一点，比如说，“牛魔王”每4周才来看一次，平均时延会增加很多。由上，BSPAMFRMS配置需要综合考虑寻呼负荷和用户感知，不能过大（增加寻呼时延，增加接续时延），也不能过小（导致寻呼拥塞，降低接续成功率）。

最后，网络只能尽力“呼唤”MS，至于MS听不听得到，响应回不回得来，就只能看“缘分”了（佛性寻呼）。因为无线环境变化很快，寻呼又讲究“时机”，失败是常有的事。MSC在发送Paging时启动定时器T3113，在收到PagingRESP时终止T3113——如果T3113超时，MSC判定为寻呼失败。如果第一次寻呼失败，MSC可以再次发送Paging，并重启T3113。对MSC来说，重发寻呼和初次寻呼对应同一次MT业务（语音或短信），两者存在关联，而对BSC和BTS来说，此时还没有MS的“记忆”（没有SCCP连接和RR连接），视重发寻呼为一次独立的寻呼（Thisisthenewshit…），反正分辨初次寻呼和重发寻呼也没什么意义。MSC增加寻呼重发的次数，可以提高最终的寻呼成功率（R10），但寻呼时延和接续时延会相应增加。在实际网络中，MSC通常只会重发一次。有的厂家支持配置多次重发，但增益不会很明显——这就好像你找一个人，第一次有回应的可能性最大，往后可能性会越来越小，多喊几次也不会有多大帮助。NR的寻呼机制（三）这一篇谈GPRS的寻呼（没想到吧，我就是这么无聊）。本文参考了爱老师的《GPRS网络信令实例详解》，本人水平有限，有些地方理解不到位，请读者以爱老师为准。在进入寻呼主题之前，先简单介绍一下GPRS（GeneralPacketRadioService，通用分组无线服务）。GSM设计初衷是提供“移动语音”业务，GPRS可视为GSM的“补丁”，为GSM用户提供“移动数据”业务——通俗的说，就是“上网冲浪”（2G冲浪）。传统GSM网络的目标是为MS建立话音通道，而GPRS的目标是为MS建立数据通道。

语音业务的特点是“连续”和“独占”，MS通话期间连续占用1个语音通道（即使用户没在说话，此时MS通过DTX省电），（TCH）资源需求固定；数据业务的特点是“突发”和“共享”，（PDTCH）资源需求不固定，MS不一定连续占用资源（比如WEB业务，页面下载完成后，用户会浏览一会儿，此时MS和网络不一定交互），但需求有时较大，有时较小（取决于访问内容）。语音业务和数据业务的特点不同，为了充分利用网络资源，两种通道使用不同的交换方式，传统GSM是典型的CS（CircuitSwitching，电路交换）网络，而GPRS是PS（PacketSwitching，分组交换）网络。

GPRS利用传统GSM网络的无线部分（BSC和BTS，麻烦挤一挤），新增独立的PS核心网络（SGSN和GGSN）。为了避免混淆，以下GSM特指传统GSM网络的无线部分，CS和PS分别表示语音业务的“电路域”和数据业务的“分组域”。在PS中，为了实现CN（SGSN）和RAN（BSS）的对接，BSC需要新增处理分组（Packet）的“技能包”——PCU（PacketControlUnit）。PS网络就像一个“局域网”（LAN），GGSN是“局域网”的边界（网关），MS想到“外面的世界”看一看，关键是建立MS到GGSN的通道（PDP），GGSN会实现MS和外部PDN（ExternalPacketDataNetwork）之间的数据路由和转发。MS和GGSN之间的一个通道，由一个PDP（PacketDataProtocol）上下文描述，包含一个分配给MS的PDP地址（UEIP）以及其他相关参数，比如公网DNS服务器的IP地址。在控制面（信令面），SGSN和GGSN都参与PDP上下文的创建和维护；在用户面（业务面），SGSN和GGSN也都参与业务数据的转发。MS要“上网”，得分两步走。第一步，附着（Attach），MS和SGSN创建MM（MobilityManagement）上下文；第二步，激活PDP上下文（PDPContextActivation），MS、SGSN和GGSN创建PDP上下文。简单的说，MS先和SGSN说的上话（建立控制面通道，NAS信令连接），才能和GGSN说的上话（建立用户面通道，PDP上下文）。PDP状态和MM状态独立，但受限于MM状态——如果MM状态为IDLE，网络完全不知道MS在哪儿，更不可能有PDP上下文，PDP状态必然为INACTIVE。在控制面（或信令面），MS和SGSN之间的层3消息（GMM/SM）通过LLC（LogicalLinkConnection）实现可靠传输。在SGSN和BSS（参照协议，这里将BSC和BTS合并为BSS呈现）之间，LLCPDU由BSSGP（替代CS的BSSMAP）承载。在BSS和MS之间，GPRS借用局域网的协议分层，增加RLC（RadioLinkControl）和MAC（MediumAccessControl），底层沿用GSM的协议栈（开始出现EPS和NR的雏形）。在用户面（或业务面），MS和GGSN之间的业务数据经SGSN转发。在SGSN和GGSN之间，业务数据通过GTP-U（GPRSTunnellingProtocol–User，这名字够直白的）传输。在MS和SGSN之间，和控制面相似，业务数据也通过LLC实现可靠传输，只是在LLC之上增加SNDCP（SubnetworkDependenceConvergenceProtocol），实现业务数据的分段/重组和压缩/解压。在LLC之下，用户面和控制面协议栈完全相同，这意味着，无论是控制面的层3消息，还是用户面的业务数据，都会封装为LLCPDU传输，底层不进行区分——一个间接的“证据”是，在Um接口，承载LLCPDU的“RLC/MAC块”都是“RLC/MAC数据块”，不是“RLC/MAC控制块”。

言归正传。

PS为啥需要寻呼呢？和CS一样，是为了节省MS能源和网络资源。MS和网络（SGSN）之间的连接不能一直保持，有时网络（SGSN）不知道MS具体位置（小区），就需要“广播找人”。从MS角度看，在CS中，根据RR连接（SDCCH）是否存在，MS工作模式分为空闲模式（IdleMode）和专用模式（DedicatedMode）；相似的，在PS中，根据RR连接（TBF）是否存在，MS工作模式分为分组空闲模式（PacketIdleMode）和分组传输模式（PacketTransferMode）。

把CS和PS合并考虑，则稍微复杂一些。按照MS的服务能力，可分为三种类型：ClassA、ClassB和ClassC。简单的说，ClassA支持同时打电话（CS）和上网（PS）；ClassB打电话时不能上网，上网时不能打电话；ClassC只能打电话或上网。如果MS同时进行CS和PS业务，则处于DualTransferMode，简称DTM。ClassA用户体验好，但实现也较为复杂（成本高），大部分MS都是ClassB。由上，ClassA的MS有4种工作模式（组合）：Idle/PacketIdle、Dedicated（CS）、PacketTransfer（PS）、DualTransfer（CS+PS）。根据CS和PS业务发生的顺序，MS先进入Dedicatedmode或PacketTransfermode，再从Dedicatedmode或PacketTransfermode进入DualTransfermode。ClassB（或所在网络不支持DTM的ClassA）少一种工作模式（DTM）。RR连接存在于MS和BSS的RR实体之间，对SGSN不可见。SGSN和MS需要维护更高层的MM（MobilityManagement）状态。和CS不同，PS有三种MM状态：Idle、Standby和Ready。在PS中，（Packet）Idle表示MS没有附着，网络对MS状态一无所知，更谈不上寻呼了。因此，这里只关注Standby和Ready，简单的说，Standby表示MS已经附着，SGSN和MS已经建立MM上下文，但（LLC）连接不存在；Ready表示（LLC）连接存在，SGSN知道MS的具体小区，SGSN和MS之间可以传输LLCPDU。由于SGSN无法感知RR连接状态，MM状态和RR工作模式并不总是“同步”。如果忽略CS，SGSN只在（MM）Standby状态发送（PS）寻呼，MS只在（RR）PacketIdle模式监听（PS）寻呼。对于特定的MS，如果SGSN的MM状态为Ready，以下三种场景会转变为Standby：1、SGSN和MS之间长时间没有传输LLCPDU，Ready定时器超时（Readytimerexpiry）；2、SGSN强制进入Standby（Forcetostandby，主动转变）；3、RLC异常（AbnormalRLCCondition，被动转变）。反过来，如果SGSN的MM状态为Standby，SGSN接收到MS发送的任意LLCPDU（除了NullLLCframe），MM状态转变Ready——这个LLCPDU通常是对寻呼的响应，但不再显性的叫“PagingResponse”，好比“小甜甜”呼唤“牛魔王”，“牛魔王”不一定回“到”，回“亲爱的”、“乖乖”、“死样”都可以。

由上可见，在PS中，寻呼是由CN，即SGSN触发的（CNInitiated）。在CS中，寻呼标识可为TMSI或IMSI，由于TMSI是MSC分配的，SGSN不知道，使用自己分配的P-TMSI（PS的TMSI）替代。P-TMSI长度也为32，最高位（MSB）为“11”，以和CS的TMSI区分。和TMSI相似，如果SGSN组成SGSNPOOL，P-TMSI一部分用于表示NRI（NetworkResourceIdentity）。SGSN和MS基于P-TMSI生成（Local和Foreign）TLLI（TemporaryLinkLayerIdentity），作为LLC的用户标识。和CS不一样，在PS中，IMSI寻呼用于错误恢复（ErrorRecovery），如果网络错误导致P-TMSI不可用，网络可以触发IMSI寻呼。如果MS收到IMSI寻呼，应停止T3346，在本地去激活所有PDP，并进行Detach和Re-Attach。这就好像你妈平常都喊你小名（P-TMSI），有一天突然喊你大名（IMSI），你马上意识到出了什么状况，立马停下手里的事（DeactivatePDP和Detach），向老妈报到（Re-Attach）。在CS中，寻呼范围是MS所在LA（LocationArea，位置区）。相似的，在PS中，寻呼范围是MS所在RA（RoutingArea，路由区）。由于数据业务是“突发”的，MM状态变更比CS频繁，PS寻呼需求比CS会多一些，协议将RA定义为LA的子区域——一个LA可划分为多个RA，RA的标识RAI（RoutingAreaIdentification）由LAI（LocationAreaIdentification）和RAC（RoutingAreaCode）构成。大概是PS用户规模没达到预期，现网大部分LA没有划分，只包含一个RA。在CS中，如果MS移动到新的LA，需要向MSC发送LocationUpdateRequest（位置区更新），如果移动到新MSC服务范围，新MSC还会向HLR发送UpdateLocation。相似的，在PS中，如果MS移动到新的RA，需要向SGSN发送RoutingAreaRequest（路由区更新），如果移动到新SGSN服务范围，新SGSN也会向HLR发送UpdateLocation。在CS中，GMSC（语音）或SMSC（短信）通过HLR找到MS所在MSC，在HLR更新MSC地址很重要，否则被叫业务（MT语音或MT短信）无法接续。在PS中，如果PDP上下文是MS主动建立的（ActivatePDPContextRequest），下行数据到达时，GGSN已有PDP上下文，不需要向HLR查询就可以找到SGSN；如果下行数据（PDPPDU）到达时，GGSN没有PDP上下文，GGSN向HLR查询SGSN信息，通过SGSN要求MS启动PDP上下文激活流程（RequestPDPContextActivation）——问题是，GGSN和HLR之间的Gc接口使用SS7（7号信令），而GGSN产品通常基于路由器平台开发，为了降低实现难度（省钱），大部分产品没有实现Gc接口。一些“貌似”由网络触发PDP上下文建立的业务（比如说，彩信），实际是通过“带外”方式（比如说，短信）通知MS，MS再触发PDP上下文建立。

最后，CS和PS共用无线网络，从高层角度看，MS的CS模块和PS模块捆绑在一起，移动性可以“联合”管理——MS可以只向SGSN“报告”位置（RoutingAreaUpdateRequest），SGSN再通过Gs接口转告MSC（LocationUpdateRequest），这称为CombinedRA/LAUpdate，和CSFB的联合位置更新相似（相应的，CS业务的寻呼经Gs接口发送给SGSN，寻呼请求以PS方式发送给MS，寻呼响应以CS方式返回MSC）。在联合位置更新中，MS向SGSN“报告”，而不是向MSC“报告”，原因是RA比LA小，选择RAU而不是LU，可以及时反映MS位置变化。换个说法，联合位置更新大概是这么回事：MS的CS模块和PS模块就像外出旅行的小两口，为了让家长（CN）放心，男方（CS）给婆家（MSC）打电话（LU），女方（PS）给娘家（SGSN）打电话（RAU），如果婆家（MSC）和娘家（SGSN）常有联系（Gs接口），女方给娘家打电话，娘家再转告婆家就可以了。现实是，婆家和娘家大多不怎么来往，相似的，Gs接口通常也没有部署。NR的寻呼机制（四）这一篇谈GPRS（PS）寻呼的实现。在Gb接口，PS寻呼请求通过BSSGP（对应CS的BSSMAP）发送给BSC，BSC指示BTS进行寻呼广播，在相反方向，被“呼唤”的MS向SGSN发送任意LLCPDU作为寻呼响应。对于特定的MS，只有MM状态为Standby，SGSN才会发送PS寻呼请求——由于SGSN和MS之间没有连接，PS寻呼请求由PSPagingPDU携带，而不是DLUNIDATAPDU（封装了下行LLCPDU，类似于CS的DTAP消息）。如果MM状态为Ready，SGSN不会发送PS寻呼请求（没有必要），但可能会发送（来自Gs接口的）CS寻呼请求，由CSPagingPDU携带。在Um接口，PS寻呼请求通过PPCH（PacketPagingChannel）发送，在相反方向，作为寻呼响应的LLCPDU通过PDTCH（PacketDataTrafficChannel）发送。如果和CS对照，PPCH和CS的PCH（PagingChannel）对应，属于“公共”信道；PDTCH和SDCCH（StandAloneDedicatedControlChannel）对应，属于“专用”信道。相似的，MS通过PRACH（PacketRandomAccessChannel，对应RACH）请求PDTCH资源（ChannelRequest），BSS通过PAGCH（PacketAccessGrantChannel，对应AGCH）指派PDTCH资源（PacketUplinkAssignment）。

由上可见，PS寻呼和CS寻呼实现整体相似，最明显的差异是寻呼响应，以及返回的方式。在CS中，寻呼响应是层3消息（PagingResponse），通过特定的控制信道（SDCCH）发送；在PS中，寻呼响应可以是任意LLCPDU（除了NullLLCPDU），无论是层3消息还是业务数据，在底层都以相同的方式传送。更具体的，在PS中，MS和BSS的RR实体之间，需要建立MS到BSS的上行TBF，承载作为寻呼响应的LLCPDU。

TBF（TemporaryBlockFlow）是RR实体之间的逻辑连接，只在数据传送时存在。在某种程度上，TBF有一点像EPS（EvolvedPacketSystem）的RB（RadioBearer，无线承载）——只是GPRS还没有PDCP（PacketDataConvergenceProtocol）实体。TBF都是单向的，根据传送方向（上行/下行）和TFI（TemporaryFlowIdentity，取值为0~31）区分。在CS中，一个MS只占用一个物理信道（SDCCH或TCH），反正多了也没用，在PS中，一个MS可能占用多个物理信道，具体表现是TBF可能对应多个PDTCH，如果网络乐意，可以把物理信道资源都给一个用户，以提升单个用户的速率——广告上的峰值速率都是这么算出来的。

在PS中，多个MS也可以共享同一物理信道（大丈夫，能伸能屈）。更具体的，MS在ChannelRequest携带标识自己的随机数（RandomNumber），然后监测PAGCH，等待上行资源分配，如果PacketImmediateAssignment携带的随机数和自己匹配，则认为获得“不完全”授权。接着，MS根据PacketImmediateAssignment携带的TN（TimeslotNumber）和USF（UplinkStateFlag）监测下行链路，如果对应TN的下行块包含分配的USF，则认为获得“完全”授权，在上行方向对应TN发送数据。可以看到，GPRS开始出现“上行调度”的影子。

如果ChannelRequest的建立原因（EstablishmentCause）为SingleBlockPacketAccess（二次接入方式），PAGCH分配的上行资源会用于上报MS能力（MSCapability，比如支持多时隙），BSS根据MS能力，通过PACCH再次分配上行资源（包括TLLI、ARFCN、TN、TFI和USF）。如果ChannelRequest的建立原因为OnePhasePacketAccess（一次接入方式），则没有这两步，过程如上文所述。从上往下看，在MS侧，如果LLCPDU（包含LLChead、LLCpayload和FCS）较大，先分段，然后封装为多个“RLC/MAC数据块”（包含RLC/MAChead和RLC/MACpayload）,再由TBF对应的PDTCH传送。再往下，每个PDTCH对应一个“无线块”（RadioBlock）——在PS中，无线资源的分配单位就是“无线块”。那么，“无线块”是什么呢？在GSM中，用于PS的物理信道（时隙）称为PDCH。和CS的51复帧（控制）或26复帧（业务）不同，PS使用52复帧（控制+业务）。如果把连续4帧的同一时隙抽取出来，就构成1个“无线块”——每个“无线块”包含4个NormalBurst（常规突发脉冲序列），最多携带114x4=456位信息。52复帧包含12个“无线块”（B0~B11）。剩余52–4x12=4帧，2帧（X）为IdleFrame（空闲帧），用于识别邻区BSIC（BaseStationIdentityCode），进行干扰测量，2帧（T）为PTCCH（PacketTimingAdvanceControlChannel），用于传送TA（时间提前）信息。除了PDTCH，前面提到的各种PS逻辑信道，包括PPCH，也各对应一个“无线块”，具体信道类型可由“RLC/MAC块”头部和RLC/MAC控制消息类型确定——PRACH除外（在各种移动通信系统中，随机接入信道总是与众不同，因为携带的是“信号”（随机接入突发脉冲），而不是“数据”（常规突发脉冲））。由上，PS也有一套独立的逻辑信道，分为业务信道和控制信道。业务信道包括上行的PDTCH/U和下行的PDTCH/D，用于传送LLCPDU。控制信道包括PBCCH（PacketBroadcastControlChannel）、“公用”的PCCCH（PacketCommon