簡介這份PPT講義以GSM網(wǎng)絡(luò)拓?fù)渑c信令協(xié)議為主線面向移動通信專業(yè)學(xué)生、網(wǎng)絡(luò)優(yōu)化工程師及通信運維人員系統(tǒng)梳理GSM系統(tǒng)結(jié)構(gòu)、七號信令網(wǎng)及核心接口流程。資源包內(nèi)含一個PPTX演示文稿壓縮后約1.27MB共11個章節(jié)依次覆蓋網(wǎng)絡(luò)拓?fù)?、信令協(xié)議結(jié)構(gòu)、NO.7信令網(wǎng)、各層協(xié)議、TUP/ISUP、信令流程、重要定時器、信令消息內(nèi)容及常用分析軟件。講義對TMSC、MSC、BSC、BTS、HLR/VLR/AUC等網(wǎng)元的功能劃分以及MTP、SCCP、MAP、TCAP、BSSAP等協(xié)議層次作了圖文對照說明并結(jié)合鑒權(quán)與加密、位置更新、呼叫建立、切換等場景展示信令消息交互邏輯。其中定時器與典型信令消息的講解尤其適合排查位置更新、切換異常等實際問題。目前已有78人學(xué)習(xí)瀏覽適合通信初學(xué)者作為入門教材也便于有經(jīng)驗者快速回顧網(wǎng)絡(luò)架構(gòu)、理解信令流程為網(wǎng)絡(luò)優(yōu)化和故障排查提供支撐。1. GSM網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)從BTS到TMSC一張拓?fù)鋱D里的分工邏輯GSM網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)常被畫成一張滿是BOX和連線的圖很多剛轉(zhuǎn)核心網(wǎng)的人第一反應(yīng)是背縮寫B(tài)TS、BSC、MSC、HLR、VLR、AUC、TMSC……真到處理信令問題時才發(fā)現(xiàn)背了名字不等于知道它們之間怎么協(xié)作。換個角度理解就順了BTS管無線信號BSC管無線資源和基站維護(hù)MSC管呼叫接續(xù)與計費HLR/VLR管用戶身份與當(dāng)前位置AUC管鑒權(quán)數(shù)據(jù)TMSC負(fù)責(zé)MSC之間的信令轉(zhuǎn)接。這份講義的價值是把這張拓?fù)鋱D里的每個網(wǎng)元職責(zé)、接口類型、七號信令協(xié)議分層和典型信令流程串成一條完整的學(xué)習(xí)鏈適合要做網(wǎng)絡(luò)優(yōu)化、信令分析或核心網(wǎng)運維的人從頭把GSM的骨架搭起來。2. 七號信令協(xié)議棧MTP、SCCP、TCAP、MAP、BSSAP的分層與封裝關(guān)系2.1 接口決定協(xié)議Um、Abis、A口的協(xié)議分工GSM網(wǎng)絡(luò)里的協(xié)議不是憑空分的而是按接口走的。一共三類接口MS到BTS之間的Um口、BTS到BSC之間的Abis口、BSC到MSC之間的A口。接口不同二層承載和三層消息寫法也不同。Um口物理層是無線空中接口二層用LAPDm三層承載的是CM呼叫管理、MM移動性管理、RR無線資源管理消息。Abis口BTS與BSC之間通常是PCM鏈路二層用LAPD傳輸?shù)募扔泻艚锌刂葡⒁灿谢揪S護(hù)管理消息BTSM。A口BSC與MSC之間走2M中繼底層用MTP上層用BSSAP承載DTAP和BSSMAP消息。接口位置二層協(xié)議三層主要內(nèi)容UmMS – BTSLAPDmRR / MM / CMAbisBTS – BSCLAPDBTSM 用戶業(yè)務(wù)ABSC – MSCMTP2BSSAPDTAP BSSMAPNSS內(nèi)部MSC / HLR / VLR之間MTP SCCPTCAP MAP / ISUP理解了接口歸屬再看協(xié)議棧就不亂了。A口和NSS內(nèi)部都屬于七號信令協(xié)議群用的是MTP、SCCP、TCAP這些基礎(chǔ)承載Um口和Abis口屬于GSM專用協(xié)議群側(cè)重?zé)o線資源的分配和無線鏈路管理。講義把這層分得很清楚GSM專用協(xié)議群解決“無線側(cè)怎么把消息送到BSC”七號信令協(xié)議群解決“BSC以上的節(jié)點之間怎么可靠地傳消息”。在實際抓包分析時第一件事就是確認(rèn)消息從哪個接口抓的。同一個“位置更新請求”在Um口看是MM層的消息在A口看是BSSMAP/DTAP承載在MSC與HLR之間看則是MAP操作。如果不知道接口歸屬很容易拿A口的報文去套Um口的字段定位就會偏。2.2 MTP1/2/3信令網(wǎng)的物理、鏈路與路由MTP是整個七號信令的基礎(chǔ)。它分成三層對應(yīng)OSI下面的三層但實際用起來要比OSI更貼近傳輸設(shè)施。MTP1是信令數(shù)據(jù)鏈路層最底下那層。在GSM里通常是2Mbit/s的PCM中繼上抽一個時隙跑64kbit/s信令鏈路。它只管把比特流從一端搬到另一端不做任何校驗和重傳。物理層告警、滑碼、誤碼都在這層體現(xiàn)。MTP2是信令鏈路層負(fù)責(zé)把比特組織成信令單元做定界、定位、差錯檢測和重傳。一條信令鏈路是否可用看MTP2的狀態(tài)就知道。常見問題里“鏈路反復(fù)倒換”多半是MTP2的定位或重傳參數(shù)貼邊誤碼率一高就掉線。MTP3是信令網(wǎng)功能層負(fù)責(zé)信令消息的路由選擇、信令鏈路管理、信令點間消息的轉(zhuǎn)發(fā)。它認(rèn)的是信令點編碼DPC/OPC即目的地/源點編碼和電路識別碼CIC。中國規(guī)范里信令點編碼是24位寫作“主信令區(qū)-副信令區(qū)-信令點”例如1-2-3。換算成十進(jìn)制時要注意165536 2256 3這個值在Wireshark里配置DPC/OPC時直接體現(xiàn)。提示MTP3里有SLS信令鏈路選擇碼用于選路SLS相同的一條會話通常走同一條鏈路這在分析單通或時延不均時很有用。2.3 SCCP與TCAP在MTP之上的傳輸與事務(wù)層MTP3只負(fù)責(zé)按DPC把消息送到一個信令點但一個信令點上可能同時駐留著MSC、VLR、HLR等多個“子系統(tǒng)”MTP不知道消息該給誰。SCCP就是解決這個問題的用子系統(tǒng)號SSN區(qū)分同一信令點內(nèi)的不同功能實體。SCCP的尋址有兩種按DPCSSN直接尋址或者按GT全局碼尋址。MAP消息在NSS內(nèi)部走時幾乎都用GT尋址因為HLR、MSC的GT是網(wǎng)絡(luò)規(guī)劃統(tǒng)一編排的不容易隨組網(wǎng)變化。STP的GT翻譯表負(fù)責(zé)把全局碼翻譯成DPCSSN。抓包時如果看到SCCP層提示“GT translation failed”基本是STP表沒配或配錯。TCAP在SCCP之上提供事務(wù)處理能力。它有點像一個輕量級的會話管理框架給每個操作分配事務(wù)ID把“請求-響應(yīng)”或“對話-多操作”組織起來。MAP的所有操作都跑在TCAP里。在Wireshark里看TCAP層里面會顯示當(dāng)前是“Invoke”還是“Return result”對應(yīng)到業(yè)務(wù)上就是“發(fā)出請求”和“收到響應(yīng)”。SCCP還有一個容易被忽略的點是它可以提供無連接服務(wù)和面向連接服務(wù)。GSM里MAP和BSSAP大多用無連接服務(wù)但某些承載業(yè)務(wù)需要端到端信令時會用面向連接類。排查超時問題時先確認(rèn)用的是哪種服務(wù)類型再決定從哪個定時器下手。2.4 BSSAP與MAPA口和NSS內(nèi)部的應(yīng)用消息BSSAP是A口的應(yīng)用協(xié)議分為DTAP和BSSMAP兩部分。DTAP是“透傳”消息把MS和MSC之間的CM/MM/RR消息原封不動穿過BSC送到MSCBSC只是搬運工。BSSMAP則是BSC與MSC之間的控制消息比如尋呼請求、切換命令、電路分配這些消息不是給MS看的而是BSC和MSC之間協(xié)調(diào)用的。一個典型的尋呼過程是這樣MSC收到被叫呼叫后在BSSMAP里發(fā)一個尋呼請求給BSCBSC在對應(yīng)LAI下所有小區(qū)下發(fā)尋呼信道消息MS在尋呼信道響應(yīng)BSC通過DTAP把MS的響應(yīng)透傳給MSC。這里如果MSC發(fā)到BSC的LAI和MS實際注冊的LAI不一致尋呼就會一直無響應(yīng)。MAP是NSS內(nèi)部的應(yīng)用協(xié)議負(fù)責(zé)移動性管理和業(yè)務(wù)控制包括位置更新、鑒權(quán)、切換、補(bǔ)充業(yè)務(wù)操作等。它跑在TCAP之上常見操作有更新位置請求、發(fā)送鑒權(quán)參數(shù)、提供漫游號碼等。因為MAP操作天然是請求-響應(yīng)模式所以每個MAP操作都有對應(yīng)的超時定時器超時后TCAP層會報對話中止。協(xié)議封裝順序可以做一個非常直觀的示意MS側(cè)發(fā)出CM/MM消息后先包成RR幀再壓到LAPDm里過Um口到BTSBTS解掉LAPDm后在Abis口用LAPD和BTSM承載送到BSCBSC再把消息塞進(jìn)SCCP經(jīng)MTP到MSC。整個過程像洋蔥一樣一層套一層哪一層封裝不匹配消息就在哪一層丟。3. TUP與ISUP電話用戶部分與ISDN用戶部分的呼叫接續(xù)差異3.1 TUP基本呼叫的消息集合TUP是電話用戶部分由MTP直接承載不經(jīng)過SCCP。它處理的是最基本的電話呼叫呼叫建立、應(yīng)答、釋放。TUP消息集不大常用的就幾個IAM初始地址消息、IAI帶附加信息的IAM、ACM地址全消息、ANC應(yīng)答消息帶計費、CLF前向釋放、CBK后向釋放、REL釋放、RLC釋放完成。TUP用CIC電路識別碼標(biāo)識一條中繼電路。兩個MSC之間如果有多條PCM中繼CIC就用來區(qū)分具體是哪一條時隙。打電話時IAM里帶的被叫號碼決定呼叫去哪里ACMA表示被叫開始振鈴ANC表示被叫摘機(jī)并啟動計費。釋放時由任一方發(fā)起REL對端回RLC后才算把電路釋放干凈。TUP比較“樸素”它不太支持主叫號碼透傳、多方通話、呼叫轉(zhuǎn)接這類補(bǔ)充業(yè)務(wù)。很多老PSTN交換機(jī)還在跑TUPGSM MSC和這類老設(shè)備對接時主叫號碼往往要在MSC側(cè)做號碼變換或通過IAI傳遞否則到對端就是匿名。3.2 ISUP從TUP擴(kuò)展出的參數(shù)與業(yè)務(wù)能力ISUP是在TUP基礎(chǔ)上發(fā)展起來的為ISDN業(yè)務(wù)設(shè)計支持語音、數(shù)據(jù)、圖像等多種承載服務(wù)。它和TUP最大的區(qū)別在兩點一是消息參數(shù)豐富二是支持端到端信令。TUP消息里主要就是被叫號碼、主叫類別這些基礎(chǔ)字段ISUP的IAM可以攜帶主叫號碼、被叫號碼、轉(zhuǎn)接網(wǎng)絡(luò)選擇、傳輸媒介要求、用戶業(yè)務(wù)信息等幾十個參數(shù)。傳輸媒介要求這個參數(shù)特別值得注意它告訴對端這條呼叫是語音、64kbit數(shù)據(jù)還是3.1kHz音頻如果MSC間配置不一致接通后可能聽不到聲音。另一個實際差異是ISUP支持SUS/RES暫停/恢復(fù)和CPR呼叫進(jìn)行等消息可以支撐呼叫保持、呼叫等待這類業(yè)務(wù)。TUP里做這些業(yè)務(wù)就很別扭。對比項TUPISUP承載方式MTP直接承載MTP SCCP部分情況典型消息IAM / ACM / ANC / CLF / RELIAM / ACM / ANM / SUS / RES / REL主叫號碼支持有限需IAI擴(kuò)展IAM直接攜帶補(bǔ)充業(yè)務(wù)弱強(qiáng)支持端到端信令適用場景老PSTN對接MSC間中繼、ISDN用戶現(xiàn)在的GSM網(wǎng)MSC之間和MSC到PSTN的呼叫基本都切到ISUP了只有存量老設(shè)備還在跑TUP。分析信令時認(rèn)識TUP不是要維護(hù)它而是為了在老設(shè)備對接場景里能看懂并且判斷是TUP字段不足還是MSC數(shù)據(jù)配置漏了。3.3 一個完整本地呼叫的TUP/ISUP交互過程拿一個GSM用戶呼叫PSTN用戶來舉例假設(shè)主叫側(cè)MSC用ISUP和中繼局對接整個呼叫接續(xù)的消息順序如下步驟方向消息含義1主叫MSC - 對端IAM攜帶被叫號碼、主叫號碼、傳輸媒介要求2對端 - 主叫MSCACM對端已找到被叫開始振鈴3對端 - 主叫MSCANM / ANM被叫摘機(jī)主叫MSC啟動計費4任一方掛機(jī)REL發(fā)起釋放攜帶釋放原因值5對端回應(yīng)RLC電路釋放完成這套流程里最容易出問題的是第1步和第4步。IAM里主叫號碼字段沒透傳就會導(dǎo)致被叫側(cè)來電顯示空白REL里的釋放原因值如果是不認(rèn)識的數(shù)值對接雙方可能理解不一致出現(xiàn)“一邊已經(jīng)釋放一邊還在等應(yīng)答”的狀態(tài)。我處理這類問題時的習(xí)慣是先看IAM字段全不全再看REL之后的RLC有沒有正常返回兩步走完基本能篩掉八成中繼接續(xù)故障。4. GSM信令流程與定時器鑒權(quán)、位置更新、尋呼與切換的節(jié)點排查避坑4.1 鑒權(quán)與加密A3/A8/A5如何配合完成身份核驗GSM的鑒權(quán)機(jī)制是挑戰(zhàn)-響應(yīng)模式核心參數(shù)有KiSIM卡密鑰、RAND隨機(jī)數(shù)、SRES鑒權(quán)響應(yīng)、Kc加密密鑰、A3/A8算法。流程是MSC/VLR從AUC取一組RAND和對應(yīng)的SRES把RAND發(fā)給MSSIM卡用內(nèi)部存的Ki跑A3算法算出SRES回傳MSC側(cè)比對兩邊SRES是否一致。一致就通過不一致就拒絕注冊。加密部分用A8算法基于同樣的RAND和Ki生成KcKc再交給A5算法在Um口做加密。A3和A8在SIM卡里往往是同一個復(fù)合算法的兩個輸出實際參數(shù)是AUC生成RAND、SRES、Kc三件套發(fā)給VLRVLR在需要時下發(fā)RAND給MS。這里面有個運維上的常見坑AUC里存的Ki和SIM卡里的Ki如果不同用戶就永遠(yuǎn)鑒權(quán)失敗?，F(xiàn)象是手機(jī)能收信號但一注冊就被拒信令消息里反復(fù)出現(xiàn)鑒權(quán)失敗。處理辦法是把SIM卡和HLR/AUC的Ki數(shù)據(jù)做一致性核驗特別是補(bǔ)卡后經(jīng)常出這種問題。4.2 位置更新流程從MS到HLR的消息走向與T3212位置更新分三種正常位置更新跨LAI、IMSI附著開機(jī)、周期性位置更新定時器觸發(fā)。前兩種是事件驅(qū)動周期性的則是網(wǎng)絡(luò)用T3212強(qiáng)制用戶定期報到。流程上MS發(fā)起位置更新請求到BSCBSC通過BSSMAP接入MSC/VLRMSC/VLR分析用戶IMSI或TMSI后向HLR發(fā)起MAP更新位置請求HLR記錄當(dāng)前所在VLR地址并通知舊VLR刪除該用戶數(shù)據(jù)。整個過程在信令上能看到一串消息MM層的位置更新請求、SCCP承載、MAP上的更新位置操作。T3212是周期性位置更新的核心參數(shù)。它由網(wǎng)絡(luò)在系統(tǒng)消息里廣播單位為6分鐘取值范圍0到255所以最大是25.5小時。取值越小用戶報到越頻繁網(wǎng)絡(luò)越容易感知用戶狀態(tài)但信令負(fù)荷和手機(jī)耗電都會上升。一般商用網(wǎng)取40到70之間也就是4到7小時一次。4.3 呼叫建立與尋呼T3113、T3192及消息交互主叫呼叫被叫時MSC收到IAM后先看被叫用戶登記在哪個VLR然后通過BSSMAP向?qū)?yīng)BSC下發(fā)尋呼請求BSC在被叫當(dāng)前LAI的所有小區(qū)發(fā)尋呼。被叫MS響應(yīng)后MSC做鑒權(quán)和加密隨后建立無線資源和中繼電路雙方進(jìn)入通話態(tài)。這條鏈路上的定時器很多MSC側(cè)等待尋呼響應(yīng)通常看T3113一般設(shè)在3到10秒過了就只能拆線被叫側(cè)MS在收到釋放指令后等待網(wǎng)絡(luò)釋放無線資源的定時器是T3192取值常見1到2秒設(shè)長了會讓人覺得掛機(jī)后手機(jī)半天沒反應(yīng)。這些都是設(shè)備商實現(xiàn)里的參數(shù)講義里直接列了名稱但具體數(shù)值每家略有差異核查時以現(xiàn)場網(wǎng)元配置為準(zhǔn)。切換信令也值得提一句。MSC內(nèi)切換走BSSMAP流程相對短MSC間切換要走M(jìn)AP目標(biāo)MSC/VLR要向HLR申請MSRN漫游號碼然后兩個MSC之間用ISUP建立中繼電路。MSRN分配慢或號碼池不夠切換就會超時失敗。4.4 避坑指南信令流程中最容易翻車的五個場景場景一T3212設(shè)太小引發(fā)位置更新風(fēng)暴現(xiàn)象BSC的CCCH負(fù)荷飆升位置更新請求量驟增用戶待機(jī)掉電快。 原因T3212以6分鐘為單位如果被配置成5全網(wǎng)每半小時就周期登記一次信令量直接翻幾倍。 解決核查系統(tǒng)消息里的T3212取值商用網(wǎng)一般不低于404小時并和核心網(wǎng)尋呼時長配合評估。場景二尋呼無響應(yīng)T3113超時現(xiàn)象被叫呼叫建立失敗MSC側(cè)報尋呼超時。 原因常見是BSC下發(fā)的LAI與MS實際注冊的LAI不一致或者TMSI重分配后舊TMSI還沒被全網(wǎng)清除。 解決抓A口消息對比尋呼請求里的LAI和MS當(dāng)前注冊位置必要時讓用戶在目標(biāo)LAI下重新開關(guān)機(jī)注冊。場景三IAM消息里沒有主叫號碼現(xiàn)象被叫來電顯示為空或外網(wǎng)統(tǒng)計主叫號碼不規(guī)范。 原因主叫MSC在IAM里沒填主叫號碼參數(shù)或者做了號碼變換后沒放回IAM。 解決抓MSC出局中繼的IAM核對主叫號碼字段檢查MSC數(shù)據(jù)里的主叫號碼透傳和號碼變換配置。場景四SCCP層GT翻譯失敗現(xiàn)象MAP操作發(fā)出去石沉大海TCAP超時后業(yè)務(wù)釋放。 原因STP上的GT翻譯表沒配或配錯把全局碼翻成了錯誤的DPC。 解決查看SCCP層返回的翻譯失敗指示核對STP的GT分析表再Ping一下目的信令點確認(rèn)MTP3可達(dá)。場景五MSC間切換時MSRN分配延遲現(xiàn)象切換請求發(fā)出后長時間無響應(yīng)隨即失敗。 原因目標(biāo)VLR向HLR申請MSRN的MAP信令時延過大或MSRN號碼池剩余太少。 解決檢查HLR到VLR的MAP鏈路時延查看VLR的MSRN號碼段占用率及時擴(kuò)容號碼資源。注意定時器核查不能只看一張PPT截圖上寫的默認(rèn)值。不同廠商的MSC在T3113、T3192上的實現(xiàn)粒度不同有的按秒、有的按百毫秒統(tǒng)一按秒理解會犯低級錯誤。5. 信令分析實戰(zhàn)從抓包配置到判斷網(wǎng)絡(luò)問題的三個習(xí)慣5.1 抓包前先做解碼配置Wireshark抓SS7消息最影響效率的就是點編碼配置。默認(rèn)情況下它不知道DPC/OPC怎么顯示抓出來的MTP3層是一串純數(shù)字看不懂。正確做法是先查清楚網(wǎng)絡(luò)規(guī)劃里的信令點編碼表把主信令區(qū)、副信令區(qū)、信令點編號全部錄入再把解碼顯示切到點分格式這樣一眼就能看出消息是發(fā)給哪個局的。5.2 判斷問題的層次歸屬收到一個“呼叫接不通”的投訴先別急著看應(yīng)用層。我的排查順序是MTP2狀態(tài)正不正常MTP3路由通不通SCCP的GT有沒有翻譯對TCAP里操作有沒有響應(yīng)最后才看MAP/ISUP參數(shù)對不對。這個順序就是協(xié)議棧順序哪一層斷了就在哪一層解決不要跨層猜。5.3 定時器聯(lián)動核查的一個實用技巧我自己養(yǎng)成的習(xí)慣是把T3212、T3113、T3192三個參數(shù)放在一張表里一起看。T3212決定的周期位置更新間隔必須遠(yuǎn)大于T3113的尋呼等待時間否則會出現(xiàn)“網(wǎng)絡(luò)正在尋呼用戶用戶恰好去做周期性位置更新”的撞車窗口表現(xiàn)為偶發(fā)尋呼無響應(yīng)。這個分析思路在投訴里的說法叫“周期性位置更新與尋呼碰撞”解決方式通常是把T3212調(diào)長給尋呼留出干凈窗口。從那以后我每次做核心網(wǎng)核查都會強(qiáng)制把這幾組定時器擺在一起過一遍先看單位、再看關(guān)聯(lián)關(guān)系最后才落到具體消息字段上。信令分析的門檻不在背消息名而在養(yǎng)成從物理層往上逐層確認(rèn)的習(xí)慣。希望幫到你。本文還有配套的精品資源點擊獲取