简介这份PPT课件系统讲解GSM全球移动通信系统的接口与呼叫流程适合通信网络工程师、移动通信学习者及运营商技术人员快速建立对GSM核心信令的宏观认识。内容从GSM协议栈中的MS、BSC、MSC、RR等组件切入详细阐述A接口、Abis接口、Um接口的物理连接与传递信息并通过位置更新、鉴权加密、呼叫释放、主被叫及切换等典型流程梳理了从信道请求到连接建立的完整信令交互过程。资源包仅含1个pptx文件大小约493KB以图文页形式呈现便于直接投屏讲解或按页查阅。目前已有84人学习适合作为移动通信入门培训课件或运维人员进行故障排查时的随身参考。通过学习可掌握GSM接口功能划分与各流程中关键消息的收发顺序为后续网络优化与问题定位打下基础。1. GSM接口与呼叫流程把信令路径读通再谈排障做GSM网络优化的人几乎都被同一个问题问过Um接口、Abis接口和A接口到底各管什么呼叫流程看起来像一串消息流水账真正出故障时又不知道从哪一条开始查。我的看法是把GSM接口与呼叫流程放在一起讲恰恰是GSM原理里最值钱的一页——接口决定信令走哪条路呼叫流程决定信令按什么次序走分开背都是死知识合在一起看才能定位问题。这篇笔记就按接口协议栈和呼叫流程两条线展开最后落到A接口trace与空口信令的对照排查上。适合刚接触GSM的接入侧或核心网工程师也适合正被拉去处理呼叫建立类投诉的网优人员。2. GSM接口的协议栈底牌Um、Abis与A接口各管一段GSM网络里的“接口”不是PPT上画的一条线而是设备之间明确分工的信令和业务承载约定。排查时先分清无线侧接口和网络侧接口责任边界完全不同Um和Abis出的问题BSC以下的优化手段还能救A接口以上出的问题你再怎么调小区参数都白费。所以本章先把接口体系立住后面讲呼叫流程才能对号入座。2.1 一张接口表从Um到A再到MSC间接口GSM接口体系看着很多但真正参与一次普通主被叫的只有Um、Abis、A三个。B、C、D、E、F、G这些核心网接口是在位置更新、被叫路由查询、切换或短消息时才出现。我建议先背下面这张表把角色记牢排查时才知道该去查哪一段。接口连接两端承载协议在呼叫流程中的角色UmMS到BTS空中接口协议栈LAPDm RR/MM/CC信道请求、寻呼、业务承载AbisBTS到BSC厂商扩展LAPD TRAU帧信令集中、语音编码变换传输ABSC到MSCSS7协议栈MTP/SCCP BSSAP寻呼下发、呼叫控制、切换控制BMSC到VLR内部接口读取用户位置与签约数据CMSC到HLRMAP over SCCP被叫路由信息获取DVLR到HLRMAP over SCCP位置更新时取签约数据EMSC到MSCMAP ISUPMSC间切换、呼叫重建FMSC到EIRMAP设备状态查询GVLR到VLRMAP跨VLR的位置更新大多数GSM教材还会提一句“B接口在MSC内部一般不单独出信令trace”。实际排障时你更常见的也是Um、Abis、A三层MS在空口发起请求BSC在Abis上收拢到一条信令链路再通过A接口交给MSC。核心网侧C/D/E接口属于MAP领域位置更新和切换流程里才需要去MSC和HLR的trace里看。2.2 Um接口空口信道是呼叫流程的入口Um接口是MS和BTS之间的空中接口也是呼叫流程最先碰到的瓶颈。很多网优人员盯着SDCCH拥塞率看却忽略了Um接口上还有RACH、AGCH和PCH三个“限流阀”RACH用于手机主动发起接入主叫流程的第一步Channel Request就走这里AGCH用于网络回复Immediate Assignment让手机从RACH转到SDCCHPCH用于网络下发寻呼被叫流程的第一步Paging Request走这里SDCCH是建立控制信道承载鉴权、位置更新、CM呼叫控制等消息TCH才是业务信道呼叫进入通话阶段后占用的就是它。空口还有一个容易被低估的配置点PCH的寻呼组。移动台平时并不是一直在听PCH只在属于它的寻呼子信道醒来监听。如果MSC下发的寻呼消息和BSC配置的寻呼组不匹配或者PCH容量不足导致寻呼消息排队手机就算信号满格也“叫不醒”。排查被叫无法接通时请先确认这一点再往核心网查。2.3 Abis与A接口LAPD与SCCP各承载什么Abis接口是BTS到BSC的“最后一公里”传统组网下走E1/T1信令时隙用LAPD协议承载业务时隙承载TRAU帧。TRAU帧里装的是语音编解码后的13kbps数据但帧结构会补到16kbps所以一条64kbps的PCM时隙可以复用4路TCH。这就带来一个常见误解有人认为Abis一个时隙等于一路通话实际要看是否启用了子时隙复用。A接口是BSC到MSC之间的SS7接口协议栈从下到上是MTP、SCCP、BSSAP。BSSAP分成两个部分DTAP直接传输协议MSC和MS之间的MM/CC消息透传比如CM Service Request、SetupBSMAPBSS管理应用部分是BSC和MSC之间的管理消息比如Paging、Assignment Request、Handover Required。提示在A接口trace里先分清消息属于DTAP还是BSMAP再往下层看。DTAP消息在SCCP层以上丢失多半是核心网业务处理异常BSMAP消息在SCCP层建立失败则要查A接口电路或MTP链路。3. 呼叫流程九步走主叫、被叫与位置更新的信令快照呼叫流程不是拿来背的是拿来对照trace的。每个消息都有方向、有承载信道、有它在哪个接口被转发。真正排障时你不需要记住所有消息只需要记住“这个阶段应该出现什么消息没出现就是这一段的接口或资源出问题”。3.1 移动主叫RACH到CONNECT的九条消息一次GSM移动主叫从MS主动发起到网络接通被叫主干消息可以压缩成下面九条。这里用“方向”和“承载”标注是为了让你知道每一条消息发生在哪个接口边界。步骤方向消息承载信道/接口关键作用1上行Channel RequestUmRACHMS申请接入携带随机参考2下行Immediate AssignmentUmAGCH→SDCCHBSC分配SDCCH给MS3上行CM Service RequestUmSDCCHADTAP携带TMSI和呼叫服务类型4下行Authentication RequestUmSDCCHADTAP下发随机数RAND5上行Authentication ResponseUmSDCCHADTAPMS返回SRES6下行/上行Cipher Mode Command/CompleteUmSDCCHABSMAP/DTAP启用加密7上行SetupUmSDCCHADTAP携带被叫号码和承载能力8下行Call ProceedingUmSDCCHADTAP网络确认呼叫请求9下行/上行Assignment Command/CompleteUmSDCCH→FACCHABSMAP分配TCH进入业务信道这九条之后还有Alerting和Connect分别代表被叫振铃和接通。注意第三步的CM Service Request里携带的是TMSI、LAI以及服务类型如果TMSI失效或LAI和MSC/VLR记录不一致MSC会在这一步前先触发位置更新。第七步的Setup里被叫号码以BCD编码存放信令分析时解错BCD格式会直接把号码看偏。3.2 移动被叫寻呼响应是MT呼叫的分水岭移动被叫和主叫最大的区别在于第一步网络不知道MS在哪只能通过MSC/VLR记录的LAI向该位置区内所有小区下发Paging消息。Paging Request在A接口由MSC发给BSC属于BSMAP消息BSC再到PCH上发送Paging Request给MS。MS收到寻呼后再发起和主叫类似的接入流程。步骤方向消息承载信道/接口关键作用1下行Paging RequestABSMAPUmPCHMSC按LAI发起寻呼2上行Channel RequestUmRACHMS回应寻呼触发接入3下行Immediate AssignmentUmAGCH→SDCCH分配SDCCH4上行Paging ResponseUmSDCCHADTAP携带TMSI/IMSIMS确认收到5下行Authentication RequestUmSDCCHADTAP可选鉴权6上行Authentication ResponseUmSDCCHADTAP鉴权响应7下行SetupUmSDCCHADTAPMSC向MS下发呼叫建立8上行Call ConfirmedUmSDCCHADTAPMS确认可接受呼叫9下行/上行Assignment Command/CompleteUmSDCCH→FACCH分配TCH被叫流程的“Paging Response”是关键分水岭MS回了Paging Response说明寻呼已经送达位置区配置基本正常MS一直不回应那就要往LAC配置、TMSI有效性和PCH容量方向排查。MSC寻呼失败时看Paging Response是否到达A接口是最有效的判据。3.3 位置更新与BSC间切换两条进阶信令路径位置更新看似和呼叫流程无关实际它决定了MSC该往哪里寻呼。手机的重选或跨LA移动会触发Location Updating Request消息经SDCCH送到MSC/VLRVLR通过D接口向HLR查询用户签约数据成功后下发Location Updating Accept和新的TMSI。如果位置更新失败MS虽然能驻留小区但MSC/VLR里的位置信息是旧的被叫寻呼必然失败。BSC间切换则要走A接口源BSC通过BSSAP向MSC发送Handover RequiredMSC向目标BSC发送Handover Request目标BSC分配资源和A接口电路后返回Handover Request Acknowledge源BSC再向MS下发Handover Command。每一步都对应一个BSMAP消息MSC间切换还会牵涉E接口的MAP信令和ISUP中继。切换失败时先确认A接口trace走到哪一步断的比在基站侧盲目调邻区参数有效得多。4. 呼叫流程定时器与LA参数一张表锁定调参方向定时器是GSM呼叫流程里最容易被忽略的“隐形开关”。定时器超时后网络或手机直接释放链路用户侧看到的就是“呼叫失败”“无法接入”或“网络无响应”。我不主张一上来就改定时器但一定要知道每个定时器超时时问题卡在流程的哪一段。4.1 网络侧定时器T3101/T3107/T3113的组合开关网络侧的定时器主要管三段接入段、指配段、寻呼段。T3101管的是BSC从收到Channel Request到完成Immediate Assignment的时间T3107管的是网络发出指配请求后等待Assignment Complete的时间T3113管的是MSC等待寻呼响应的时间。定时器所在位置作用超时表现调参方向T3101BSC信道请求到立即指配MS反复发Channel Request但无指派查RACH/AGCH拥塞不要只加定时器值T3107BSC/MSC指配请求到指配完成呼叫建立慢或中断查Abis资源与A接口电路T3113MSC寻呼请求到寻呼响应被叫无法接通查PCH容量和LAI一致性三个定时器配合起来可以把一次失败的呼叫切成三段如果手机连Immediate Assignment都没等到问题在接入段如果消息走到指配阶段才超时问题在业务信道分配段如果是被叫侧迟迟不回Paging Response问题在寻呼段。这样分段排障时就不容易被空口或核心网“互相甩锅”带偏。4.2 手机侧定时器T3210/T3220直接决定用户感知手机侧也有定时器而且这些定时器超时时屏幕直接给用户报“呼叫失败”或“网络错误”。T3210是MS在发送Setup后等待网络Call Confirmed/指配的定时器T3220是MS发送Location Updating Request后等待Location Updating Accept的定时器。平时最典型的问题是核心网D接口HLR响应慢导致MSC迟迟不给MS回Location Updating Accept最终T3220超时手机显示无法注册。这时候在基站侧看SDCCH一切正常在A接口看消息也到了MSC真正的瓶颈在HLR查询或VLR处理上。手机侧trace能直接看到T3220走完了多少秒对应A接口trace的时间戳就能确认是谁拖慢了流程。4.3 LA划分与周期性位置更新参数联动的调优方向LA位置区划分是GSM网络规划里最典型的“两难”问题。LA太小用户移动频繁跨LA位置更新请求大量消耗SDCCHLA太大寻呼消息会在更多小区下广播PCH和A接口寻呼负荷都会升高。T3212周期性位置更新参数也需要跟着LA一起考虑。T3212的单位是6分钟常见配置从几十分钟到若干小时0表示不启动周期性位置更新。设得越短MSC/VLR越能确认用户在网但SDCCH开销越大设得越长寻呼失败率上升。小区重选参数CRO和ACCMIN也会影响手机在LA边界的选择把它们和T3212联动调整是缓解位置更新风暴的常用手段。5. 排查实战GSM接口与呼叫流程的5个高频故障下面这五个案例是我在GSM呼叫建立类问题里见得最多的翻车点。每条按“现象→原因→解决”的顺序写照着这个路径下结论能少爬很多冤枉路。5.1 主叫在CM Service Request后无鉴权A接口SCCP断了现象手机一直停在“呼叫中”空口侧trace能看到CM Service Request已经发出但网络侧迟迟不下发Authentication Request。原因SDCCH已经建立说明Um和Abis接口正常。CM Service Request属于DTAP消息经BSSAP透传到MSC后MSC需要先建立或复用SCCP连接再处理。此时收不到鉴权请求大概率是MSC侧SCCP连接建立失败、VLR中用户鉴权参数异常或者A接口MTP链路负荷过高导致下行消息丢失。解决在MSC侧抓A接口trace先看SCCP层有没有完成CR/CC连接建立再看CM Service Request是否到达MSC上层。如果SCCP建立失败查A接口电路和MTP链路状态如果SCCP正常而VLR没回应重刷新HLR签约数据并观察。不要第一时间爬BTS这条路径几分钟内就能分清责任。5.2 被叫寻呼无响应TMSI失效与IMSI寻呼兜底现象MSC侧显示Paging已发出手机满信号但就是不响应位置区内多个小区都唤不醒。原因最常见三个A接口Paging消息里的LAI和小区广播的LAC不一致导致BSC在错误的位置区下发寻呼MSC用TMSI寻呼但VLR中的TMSI和手机侧不一致PCH容量不足或寻呼组配置错手机醒来时没等到属于自己的寻呼消息。解决先在A接口trace里看Paging消息带的是TMSI还是IMSI、LAI是多少再和小区配置核对。如果全是TMSI寻呼且失败率高临时把MSC/VLR的寻呼策略改为IMSI寻呼做对照测试能确认是TMSI失配还是无线侧寻呼拥塞。最后查看BSC的PCH拥塞统计确认是否有寻呼丢弃。5.3 加密命令后掉话A5算法与TRAU帧的隐性错配现象呼叫建立到Cipher Mode Complete后链路很快被释放用户感觉“刚接通就断”且只发生在开启加密的小区。原因A5算法支持不一致是最直接的原因——网络侧选择A5/1但手机只支持A5/0手机无法完成加密模式。另一个容易被忽略的原因是Abis接口的TRAU帧在加密模式下失步或者A接口电路没有真正激活导致加密后业务通道无法承载。解决先做对照实验把小区加密算法临时降级到A5/0如果故障消失基本锁定为算法支持问题。再检查BSC/MSC的算法优先级列表和终端能力是否匹配。最后看Abis接口TRAU帧同步状态和A接口电路状态用电路测试确认64k链路通不通。5.4 BSC间切换失败A接口电路配置是首要嫌疑现象Handover Required从源BSC发到MSC后目标BSC不回Handover Request Acknowledge或者直接返回Handover Failure。原因目标BSC和MSC之间没有空闲的A接口电路CIC配置错误目标小区的外部小区表数据错BCCH频点或BSIC与现场不符目标小区TCH资源不足。A接口电路问题占了这类故障很高比例。解决看A接口trace里Handover Request消息携带的CIC字段先核对电路分配情况。再到BSC侧做A接口电路导通测试确认MSC到目标BSC的电路可用。如果电路正常再核对目标小区外部定义用扫频数据对照现场BCCH/BSIC是否一致。5.5 位置更新风暴挤占SDCCH呼叫建立大面积变慢现象忙时SDCCH拥塞率飙升主叫呼叫建立成功率下降集中在某个LA边界区域严重时RACH上也出现大量接入失败。原因LA划分过小用户来回穿越边界产生频繁位置更新T3212周期位置更新设置过短小区重选参数CRO/ACCMIN设置不当造成手机在LA边界乒乓重选。解决把LA边界挪到用户流动少的自然屏障处比如河道、高速服务区、大型厂区边缘减少跨LA触发次数在保障寻呼成功率的前提下调大T3212校准CRO和ACCMIN避免手机在两个LA间反复重选。处理后重点看两个指标SDCCH拥塞率和每小时位置更新次数。6. 用信令trace验证呼叫流程一版可复用的复盘模板每次处理完一个呼叫建立类问题我都会把A接口trace和空口trace的时间戳对齐把主线消息抽出来填进一张复盘表。这张表不需要很复杂重在把“哪一段慢、哪一段断”标清楚。时间戳接口/链路消息名方向关键参数与判定T1Um/RACHChannel Request上行接入是否被AGCH回应T2Um/AGCHImmediate Assignment下行SDCCH建立时长T3A/DTAPCM Service Request上行TMSI、LAI是否有效T4A/DTAPAuthentication Request/Response下行/上行鉴权向量是否到位T5Um/AAssignment Command/Complete下行/上行TCH指配是否成功T6Um/AAlerting/Connect下行/上行接通时延分段定位的习惯我沿用很久从Channel Request到Immediate Assignment算“接入段”从CM Service Request到Authentication算“鉴权段”从Setup到Assignment Complete算“指配段”从Alerting到Connect算“振铃段”。哪一段慢就去查哪一段涉及的接口资源不许凭感觉把锅甩给空口。以前我处理过一个被叫无法接通问题先在基站侧查PCH统计查了大半天没结论最后回MSC看trace发现Paging消息里的LAC和小区广播不一致纯数据配置问题。从那以后我坚持“先拉trace再定责任”的排查顺序血泪教训换来的习惯。希望你也能少走这段弯路用同样的复盘模板把GSM接口与呼叫流程变成自己的排障地图。本文还有配套的精品资源点击获取 GSM接口与呼叫流程详解：Um、Abis、A接口协议栈及信令排障指南
简介这份PPT课件系统讲解GSM全球移动通信系统的接口与呼叫流程适合通信网络工程师、移动通信学习者及运营商技术人员快速建立对GSM核心信令的宏观认识。内容从GSM协议栈中的MS、BSC、MSC、RR等组件切入详细阐述A接口、Abis接口、Um接口的物理连接与传递信息并通过位置更新、鉴权加密、呼叫释放、主被叫及切换等典型流程梳理了从信道请求到连接建立的完整信令交互过程。资源包仅含1个pptx文件大小约493KB以图文页形式呈现便于直接投屏讲解或按页查阅。目前已有84人学习适合作为移动通信入门培训课件或运维人员进行故障排查时的随身参考。通过学习可掌握GSM接口功能划分与各流程中关键消息的收发顺序为后续网络优化与问题定位打下基础。1. GSM接口与呼叫流程把信令路径读通再谈排障做GSM网络优化的人几乎都被同一个问题问过Um接口、Abis接口和A接口到底各管什么呼叫流程看起来像一串消息流水账真正出故障时又不知道从哪一条开始查。我的看法是把GSM接口与呼叫流程放在一起讲恰恰是GSM原理里最值钱的一页——接口决定信令走哪条路呼叫流程决定信令按什么次序走分开背都是死知识合在一起看才能定位问题。这篇笔记就按接口协议栈和呼叫流程两条线展开最后落到A接口trace与空口信令的对照排查上。适合刚接触GSM的接入侧或核心网工程师也适合正被拉去处理呼叫建立类投诉的网优人员。2. GSM接口的协议栈底牌Um、Abis与A接口各管一段GSM网络里的“接口”不是PPT上画的一条线而是设备之间明确分工的信令和业务承载约定。排查时先分清无线侧接口和网络侧接口责任边界完全不同Um和Abis出的问题BSC以下的优化手段还能救A接口以上出的问题你再怎么调小区参数都白费。所以本章先把接口体系立住后面讲呼叫流程才能对号入座。2.1 一张接口表从Um到A再到MSC间接口GSM接口体系看着很多但真正参与一次普通主被叫的只有Um、Abis、A三个。B、C、D、E、F、G这些核心网接口是在位置更新、被叫路由查询、切换或短消息时才出现。我建议先背下面这张表把角色记牢排查时才知道该去查哪一段。接口连接两端承载协议在呼叫流程中的角色UmMS到BTS空中接口协议栈LAPDm RR/MM/CC信道请求、寻呼、业务承载AbisBTS到BSC厂商扩展LAPD TRAU帧信令集中、语音编码变换传输ABSC到MSCSS7协议栈MTP/SCCP BSSAP寻呼下发、呼叫控制、切换控制BMSC到VLR内部接口读取用户位置与签约数据CMSC到HLRMAP over SCCP被叫路由信息获取DVLR到HLRMAP over SCCP位置更新时取签约数据EMSC到MSCMAP ISUPMSC间切换、呼叫重建FMSC到EIRMAP设备状态查询GVLR到VLRMAP跨VLR的位置更新大多数GSM教材还会提一句“B接口在MSC内部一般不单独出信令trace”。实际排障时你更常见的也是Um、Abis、A三层MS在空口发起请求BSC在Abis上收拢到一条信令链路再通过A接口交给MSC。核心网侧C/D/E接口属于MAP领域位置更新和切换流程里才需要去MSC和HLR的trace里看。2.2 Um接口空口信道是呼叫流程的入口Um接口是MS和BTS之间的空中接口也是呼叫流程最先碰到的瓶颈。很多网优人员盯着SDCCH拥塞率看却忽略了Um接口上还有RACH、AGCH和PCH三个“限流阀”RACH用于手机主动发起接入主叫流程的第一步Channel Request就走这里AGCH用于网络回复Immediate Assignment让手机从RACH转到SDCCHPCH用于网络下发寻呼被叫流程的第一步Paging Request走这里SDCCH是建立控制信道承载鉴权、位置更新、CM呼叫控制等消息TCH才是业务信道呼叫进入通话阶段后占用的就是它。空口还有一个容易被低估的配置点PCH的寻呼组。移动台平时并不是一直在听PCH只在属于它的寻呼子信道醒来监听。如果MSC下发的寻呼消息和BSC配置的寻呼组不匹配或者PCH容量不足导致寻呼消息排队手机就算信号满格也“叫不醒”。排查被叫无法接通时请先确认这一点再往核心网查。2.3 Abis与A接口LAPD与SCCP各承载什么Abis接口是BTS到BSC的“最后一公里”传统组网下走E1/T1信令时隙用LAPD协议承载业务时隙承载TRAU帧。TRAU帧里装的是语音编解码后的13kbps数据但帧结构会补到16kbps所以一条64kbps的PCM时隙可以复用4路TCH。这就带来一个常见误解有人认为Abis一个时隙等于一路通话实际要看是否启用了子时隙复用。A接口是BSC到MSC之间的SS7接口协议栈从下到上是MTP、SCCP、BSSAP。BSSAP分成两个部分DTAP直接传输协议MSC和MS之间的MM/CC消息透传比如CM Service Request、SetupBSMAPBSS管理应用部分是BSC和MSC之间的管理消息比如Paging、Assignment Request、Handover Required。提示在A接口trace里先分清消息属于DTAP还是BSMAP再往下层看。DTAP消息在SCCP层以上丢失多半是核心网业务处理异常BSMAP消息在SCCP层建立失败则要查A接口电路或MTP链路。3. 呼叫流程九步走主叫、被叫与位置更新的信令快照呼叫流程不是拿来背的是拿来对照trace的。每个消息都有方向、有承载信道、有它在哪个接口被转发。真正排障时你不需要记住所有消息只需要记住“这个阶段应该出现什么消息没出现就是这一段的接口或资源出问题”。3.1 移动主叫RACH到CONNECT的九条消息一次GSM移动主叫从MS主动发起到网络接通被叫主干消息可以压缩成下面九条。这里用“方向”和“承载”标注是为了让你知道每一条消息发生在哪个接口边界。步骤方向消息承载信道/接口关键作用1上行Channel RequestUmRACHMS申请接入携带随机参考2下行Immediate AssignmentUmAGCH→SDCCHBSC分配SDCCH给MS3上行CM Service RequestUmSDCCHADTAP携带TMSI和呼叫服务类型4下行Authentication RequestUmSDCCHADTAP下发随机数RAND5上行Authentication ResponseUmSDCCHADTAPMS返回SRES6下行/上行Cipher Mode Command/CompleteUmSDCCHABSMAP/DTAP启用加密7上行SetupUmSDCCHADTAP携带被叫号码和承载能力8下行Call ProceedingUmSDCCHADTAP网络确认呼叫请求9下行/上行Assignment Command/CompleteUmSDCCH→FACCHABSMAP分配TCH进入业务信道这九条之后还有Alerting和Connect分别代表被叫振铃和接通。注意第三步的CM Service Request里携带的是TMSI、LAI以及服务类型如果TMSI失效或LAI和MSC/VLR记录不一致MSC会在这一步前先触发位置更新。第七步的Setup里被叫号码以BCD编码存放信令分析时解错BCD格式会直接把号码看偏。3.2 移动被叫寻呼响应是MT呼叫的分水岭移动被叫和主叫最大的区别在于第一步网络不知道MS在哪只能通过MSC/VLR记录的LAI向该位置区内所有小区下发Paging消息。Paging Request在A接口由MSC发给BSC属于BSMAP消息BSC再到PCH上发送Paging Request给MS。MS收到寻呼后再发起和主叫类似的接入流程。步骤方向消息承载信道/接口关键作用1下行Paging RequestABSMAPUmPCHMSC按LAI发起寻呼2上行Channel RequestUmRACHMS回应寻呼触发接入3下行Immediate AssignmentUmAGCH→SDCCH分配SDCCH4上行Paging ResponseUmSDCCHADTAP携带TMSI/IMSIMS确认收到5下行Authentication RequestUmSDCCHADTAP可选鉴权6上行Authentication ResponseUmSDCCHADTAP鉴权响应7下行SetupUmSDCCHADTAPMSC向MS下发呼叫建立8上行Call ConfirmedUmSDCCHADTAPMS确认可接受呼叫9下行/上行Assignment Command/CompleteUmSDCCH→FACCH分配TCH被叫流程的“Paging Response”是关键分水岭MS回了Paging Response说明寻呼已经送达位置区配置基本正常MS一直不回应那就要往LAC配置、TMSI有效性和PCH容量方向排查。MSC寻呼失败时看Paging Response是否到达A接口是最有效的判据。3.3 位置更新与BSC间切换两条进阶信令路径位置更新看似和呼叫流程无关实际它决定了MSC该往哪里寻呼。手机的重选或跨LA移动会触发Location Updating Request消息经SDCCH送到MSC/VLRVLR通过D接口向HLR查询用户签约数据成功后下发Location Updating Accept和新的TMSI。如果位置更新失败MS虽然能驻留小区但MSC/VLR里的位置信息是旧的被叫寻呼必然失败。BSC间切换则要走A接口源BSC通过BSSAP向MSC发送Handover RequiredMSC向目标BSC发送Handover Request目标BSC分配资源和A接口电路后返回Handover Request Acknowledge源BSC再向MS下发Handover Command。每一步都对应一个BSMAP消息MSC间切换还会牵涉E接口的MAP信令和ISUP中继。切换失败时先确认A接口trace走到哪一步断的比在基站侧盲目调邻区参数有效得多。4. 呼叫流程定时器与LA参数一张表锁定调参方向定时器是GSM呼叫流程里最容易被忽略的“隐形开关”。定时器超时后网络或手机直接释放链路用户侧看到的就是“呼叫失败”“无法接入”或“网络无响应”。我不主张一上来就改定时器但一定要知道每个定时器超时时问题卡在流程的哪一段。4.1 网络侧定时器T3101/T3107/T3113的组合开关网络侧的定时器主要管三段接入段、指配段、寻呼段。T3101管的是BSC从收到Channel Request到完成Immediate Assignment的时间T3107管的是网络发出指配请求后等待Assignment Complete的时间T3113管的是MSC等待寻呼响应的时间。定时器所在位置作用超时表现调参方向T3101BSC信道请求到立即指配MS反复发Channel Request但无指派查RACH/AGCH拥塞不要只加定时器值T3107BSC/MSC指配请求到指配完成呼叫建立慢或中断查Abis资源与A接口电路T3113MSC寻呼请求到寻呼响应被叫无法接通查PCH容量和LAI一致性三个定时器配合起来可以把一次失败的呼叫切成三段如果手机连Immediate Assignment都没等到问题在接入段如果消息走到指配阶段才超时问题在业务信道分配段如果是被叫侧迟迟不回Paging Response问题在寻呼段。这样分段排障时就不容易被空口或核心网“互相甩锅”带偏。4.2 手机侧定时器T3210/T3220直接决定用户感知手机侧也有定时器而且这些定时器超时时屏幕直接给用户报“呼叫失败”或“网络错误”。T3210是MS在发送Setup后等待网络Call Confirmed/指配的定时器T3220是MS发送Location Updating Request后等待Location Updating Accept的定时器。平时最典型的问题是核心网D接口HLR响应慢导致MSC迟迟不给MS回Location Updating Accept最终T3220超时手机显示无法注册。这时候在基站侧看SDCCH一切正常在A接口看消息也到了MSC真正的瓶颈在HLR查询或VLR处理上。手机侧trace能直接看到T3220走完了多少秒对应A接口trace的时间戳就能确认是谁拖慢了流程。4.3 LA划分与周期性位置更新参数联动的调优方向LA位置区划分是GSM网络规划里最典型的“两难”问题。LA太小用户移动频繁跨LA位置更新请求大量消耗SDCCHLA太大寻呼消息会在更多小区下广播PCH和A接口寻呼负荷都会升高。T3212周期性位置更新参数也需要跟着LA一起考虑。T3212的单位是6分钟常见配置从几十分钟到若干小时0表示不启动周期性位置更新。设得越短MSC/VLR越能确认用户在网但SDCCH开销越大设得越长寻呼失败率上升。小区重选参数CRO和ACCMIN也会影响手机在LA边界的选择把它们和T3212联动调整是缓解位置更新风暴的常用手段。5. 排查实战GSM接口与呼叫流程的5个高频故障下面这五个案例是我在GSM呼叫建立类问题里见得最多的翻车点。每条按“现象→原因→解决”的顺序写照着这个路径下结论能少爬很多冤枉路。5.1 主叫在CM Service Request后无鉴权A接口SCCP断了现象手机一直停在“呼叫中”空口侧trace能看到CM Service Request已经发出但网络侧迟迟不下发Authentication Request。原因SDCCH已经建立说明Um和Abis接口正常。CM Service Request属于DTAP消息经BSSAP透传到MSC后MSC需要先建立或复用SCCP连接再处理。此时收不到鉴权请求大概率是MSC侧SCCP连接建立失败、VLR中用户鉴权参数异常或者A接口MTP链路负荷过高导致下行消息丢失。解决在MSC侧抓A接口trace先看SCCP层有没有完成CR/CC连接建立再看CM Service Request是否到达MSC上层。如果SCCP建立失败查A接口电路和MTP链路状态如果SCCP正常而VLR没回应重刷新HLR签约数据并观察。不要第一时间爬BTS这条路径几分钟内就能分清责任。5.2 被叫寻呼无响应TMSI失效与IMSI寻呼兜底现象MSC侧显示Paging已发出手机满信号但就是不响应位置区内多个小区都唤不醒。原因最常见三个A接口Paging消息里的LAI和小区广播的LAC不一致导致BSC在错误的位置区下发寻呼MSC用TMSI寻呼但VLR中的TMSI和手机侧不一致PCH容量不足或寻呼组配置错手机醒来时没等到属于自己的寻呼消息。解决先在A接口trace里看Paging消息带的是TMSI还是IMSI、LAI是多少再和小区配置核对。如果全是TMSI寻呼且失败率高临时把MSC/VLR的寻呼策略改为IMSI寻呼做对照测试能确认是TMSI失配还是无线侧寻呼拥塞。最后查看BSC的PCH拥塞统计确认是否有寻呼丢弃。5.3 加密命令后掉话A5算法与TRAU帧的隐性错配现象呼叫建立到Cipher Mode Complete后链路很快被释放用户感觉“刚接通就断”且只发生在开启加密的小区。原因A5算法支持不一致是最直接的原因——网络侧选择A5/1但手机只支持A5/0手机无法完成加密模式。另一个容易被忽略的原因是Abis接口的TRAU帧在加密模式下失步或者A接口电路没有真正激活导致加密后业务通道无法承载。解决先做对照实验把小区加密算法临时降级到A5/0如果故障消失基本锁定为算法支持问题。再检查BSC/MSC的算法优先级列表和终端能力是否匹配。最后看Abis接口TRAU帧同步状态和A接口电路状态用电路测试确认64k链路通不通。5.4 BSC间切换失败A接口电路配置是首要嫌疑现象Handover Required从源BSC发到MSC后目标BSC不回Handover Request Acknowledge或者直接返回Handover Failure。原因目标BSC和MSC之间没有空闲的A接口电路CIC配置错误目标小区的外部小区表数据错BCCH频点或BSIC与现场不符目标小区TCH资源不足。A接口电路问题占了这类故障很高比例。解决看A接口trace里Handover Request消息携带的CIC字段先核对电路分配情况。再到BSC侧做A接口电路导通测试确认MSC到目标BSC的电路可用。如果电路正常再核对目标小区外部定义用扫频数据对照现场BCCH/BSIC是否一致。5.5 位置更新风暴挤占SDCCH呼叫建立大面积变慢现象忙时SDCCH拥塞率飙升主叫呼叫建立成功率下降集中在某个LA边界区域严重时RACH上也出现大量接入失败。原因LA划分过小用户来回穿越边界产生频繁位置更新T3212周期位置更新设置过短小区重选参数CRO/ACCMIN设置不当造成手机在LA边界乒乓重选。解决把LA边界挪到用户流动少的自然屏障处比如河道、高速服务区、大型厂区边缘减少跨LA触发次数在保障寻呼成功率的前提下调大T3212校准CRO和ACCMIN避免手机在两个LA间反复重选。处理后重点看两个指标SDCCH拥塞率和每小时位置更新次数。6. 用信令trace验证呼叫流程一版可复用的复盘模板每次处理完一个呼叫建立类问题我都会把A接口trace和空口trace的时间戳对齐把主线消息抽出来填进一张复盘表。这张表不需要很复杂重在把“哪一段慢、哪一段断”标清楚。时间戳接口/链路消息名方向关键参数与判定T1Um/RACHChannel Request上行接入是否被AGCH回应T2Um/AGCHImmediate Assignment下行SDCCH建立时长T3A/DTAPCM Service Request上行TMSI、LAI是否有效T4A/DTAPAuthentication Request/Response下行/上行鉴权向量是否到位T5Um/AAssignment Command/Complete下行/上行TCH指配是否成功T6Um/AAlerting/Connect下行/上行接通时延分段定位的习惯我沿用很久从Channel Request到Immediate Assignment算“接入段”从CM Service Request到Authentication算“鉴权段”从Setup到Assignment Complete算“指配段”从Alerting到Connect算“振铃段”。哪一段慢就去查哪一段涉及的接口资源不许凭感觉把锅甩给空口。以前我处理过一个被叫无法接通问题先在基站侧查PCH统计查了大半天没结论最后回MSC看trace发现Paging消息里的LAC和小区广播不一致纯数据配置问题。从那以后我坚持“先拉trace再定责任”的排查顺序血泪教训换来的习惯。希望你也能少走这段弯路用同样的复盘模板把GSM接口与呼叫流程变成自己的排障地图。本文还有配套的精品资源点击获取 RELATED READING
延伸阅读
更多一线实战笔记与深度复盘，助您持续精进
