簡介GSM-R智能網(wǎng)系統(tǒng)技術(shù)文檔基于CAMEL3協(xié)議系統(tǒng)闡述鐵路專用移動通信智能網(wǎng)架構(gòu)面向鐵路通信工程師、網(wǎng)絡(luò)規(guī)劃人員、運(yùn)維人員及通信相關(guān)專業(yè)讀者。文檔從智能網(wǎng)起源與發(fā)展講起逐一剖析gsmSSP、gprsSSP、SCP、HLR、VLR、IP、SMP、SMAP、SCEP等核心節(jié)點的職責(zé)與數(shù)據(jù)交互并詳解SCP異地冗余設(shè)置及主備數(shù)據(jù)實時同步、SSP的OVERLAY與目標(biāo)網(wǎng)兩種組網(wǎng)方式的選型依據(jù)。系統(tǒng)功能方面涵蓋電路與分組交換呼叫控制、USSD、短消息業(yè)務(wù)、補(bǔ)充業(yè)務(wù)通知、移動性管理、用戶數(shù)據(jù)監(jiān)控等基本和擴(kuò)展能力接入矩陣結(jié)合EIRENE規(guī)范解析鐵路調(diào)度中呼叫權(quán)限控制規(guī)則。全文為單獨一篇doc文檔約759KB便于離線閱讀和標(biāo)注。目前已有249人學(xué)習(xí)下載可作GSM-R技術(shù)學(xué)習(xí)、網(wǎng)絡(luò)規(guī)劃設(shè)計和鐵路通信培訓(xùn)的參考材料。1. GSM-R智能網(wǎng)系統(tǒng)到底解決了鐵路調(diào)度里的什么問題調(diào)度員按車次號呼叫一列行進(jìn)中的動車司機(jī)用司機(jī)-本務(wù)這樣的功能號接通列車剛跨過調(diào)度分界點呼叫就自動接到了新任調(diào)度臺——這些手機(jī)號根本不透明的鐵路業(yè)務(wù)靠的就是 GSM-R 智能網(wǎng)系統(tǒng)。它把電信網(wǎng)里業(yè)務(wù)與交換分離的思路搬進(jìn)鐵路專用移動通信網(wǎng)在 MSC/MSS 之上疊加 SSP/SCP 控制點通過 CAMEL 機(jī)制把呼叫暫時攔停、查一次業(yè)務(wù)庫、改一次被叫號碼或換一條路由再放回到交換網(wǎng)里繼續(xù)接續(xù)。對鐵路通信工程師來說它直接解決調(diào)度通信里找不到該找的人、接不到該接的臺、緊急呼叫搶不通三個老大難問題。要想知道這套系統(tǒng)怎么落地、參數(shù)怎么設(shè)、什么環(huán)節(jié)最容易翻車下面的內(nèi)容按架構(gòu)、數(shù)據(jù)配置、信令調(diào)測到現(xiàn)場排障的順序逐步展開。2. 移動智能網(wǎng)如何變成鐵路專用GSM-R智能網(wǎng)的架構(gòu)與業(yè)務(wù)映射2.1 智能網(wǎng)四類實體在GSM-R里各管什么智能網(wǎng)不是單獨一臺設(shè)備而是一套把接續(xù)邏輯從交換機(jī)里抽出來、集中控制的架構(gòu)。GSM-R 智能網(wǎng)系統(tǒng)沿用智能網(wǎng)標(biāo)準(zhǔn)模型里的四類功能實體SSP 負(fù)責(zé)識別這個呼叫需要交給智能網(wǎng)處理SCP 負(fù)責(zé)執(zhí)行業(yè)務(wù)邏輯比如查功能號表、做號碼翻譯SDP 負(fù)責(zé)存業(yè)務(wù)數(shù)據(jù)車次號與手機(jī)號的綁定關(guān)系、小區(qū)與調(diào)度區(qū)的對應(yīng)表都在這里SCE 則用來在線編輯和下發(fā)業(yè)務(wù)邏輯。在工程實施中SCP 和 SDP 多數(shù)情況下合設(shè)為一臺設(shè)備SSP 則由 MSC/MSS 兼任并不需要額外插一臺獨立交換機(jī)。GSM-R 智能網(wǎng)與公網(wǎng)移動智能網(wǎng)的最大區(qū)別在于業(yè)務(wù)重心。公網(wǎng)智能網(wǎng)里跑得最多的是預(yù)付費和彩鈴對話模型是收到 InitialDP 后查余額、扣費、播放提示音GSM-R 智能網(wǎng)里則完全圍繞調(diào)度身份來組織業(yè)務(wù)SCP 上的核心邏輯是收到呼叫信息后去查功能號表或者位置映射表返回一個真實可接續(xù)的號碼。這個差異決定了后續(xù)所有數(shù)據(jù)配置的重心都落在號碼變換和位置匹配上而不是計費賬目上。理解這一點就明白為什么同一套 CAMEL 機(jī)制在兩個網(wǎng)絡(luò)里調(diào)測的側(cè)重點完全不同。2.2 CAMEL 觸發(fā)點智能網(wǎng)怎么接管一次 GSM-R 呼叫GSM-R 智能網(wǎng)對呼叫的接管依賴 CAMEL 機(jī)制核心是移動用戶 HLR 里的 CSICAMEL 簽約信息。MSC/SSP 會根據(jù) HLR 下發(fā)的 O-CSI 和 T-CSI 中的觸發(fā)點設(shè)置在呼叫的某個特定時刻暫停處理并向 SCP 發(fā)出 InitialDP 請求。GSM-R 工程里最常見的是兩類觸發(fā)觸發(fā)類型通俗說法典型 GSM-R 業(yè)務(wù)關(guān)鍵數(shù)據(jù)O-CSI主叫撥號后被攔停主叫功能號預(yù)處理、呼出限制主叫 IMSI、主叫號碼、被叫號碼T-CSI來話到達(dá)被叫側(cè)后被攔停功能尋址、基于位置的尋址被叫接入號、被叫號碼、位置信息組合觸發(fā)一次呼叫先后在主叫側(cè)和被叫側(cè)各攔一次號碼分析 位置再分析兩次 InitialDP 的 serviceKey 不同需要特別注意一次 GSM-R 智能網(wǎng)呼叫可能產(chǎn)生兩次觸發(fā)。主叫側(cè) O-CSI 先觸發(fā)一次SCP 可以在這里判斷主叫是否有權(quán)發(fā)起該業(yè)務(wù)后續(xù)被叫號碼收集完成后由被叫側(cè) T-CSI 再觸發(fā)一次SCP 這時才真正去查功能號綁定表或者位置映射表。很多初次調(diào)測的人只關(guān)注 T-CSI結(jié)果主叫側(cè)數(shù)據(jù)沒配信令跟蹤里連第一次 InitialDP 都看不到。2.3 五類 GSM-R 業(yè)務(wù)落到智能網(wǎng)側(cè)變成什么GSM-R 網(wǎng)絡(luò)里的傳統(tǒng)調(diào)度業(yè)務(wù)并不是全靠智能網(wǎng)才能實現(xiàn)但智能網(wǎng)能讓它們從靠交換局?jǐn)?shù)據(jù)硬頂變成靠業(yè)務(wù)邏輯靈活配置。工程上常見的業(yè)務(wù)映射有以下幾類功能尋址把車次號功能碼翻譯成當(dāng)前擔(dān)當(dāng)該功能的司機(jī)手機(jī)號SCP 返回的是真實 MSISDN基于位置的尋址根據(jù)呼叫所在的小區(qū)或位置區(qū)判定當(dāng)前調(diào)度區(qū)再把呼叫接給對應(yīng)調(diào)度臺呼叫優(yōu)先級識別 eMLPP 級別在智能網(wǎng)層面為高優(yōu)先級呼叫提供排隊和接續(xù)保障組呼 VGCS 和廣播呼叫 VBS 則借助 SCP 下發(fā)的組成員列表和組 ID讓 MSC 快速建立組呼信道。這里要澄清一個誤區(qū)GSM-R 里的無線預(yù)占和 eMLPP 資源搶占由 BSS 和交換側(cè)的 MLPP 機(jī)制完成智能網(wǎng)不負(fù)責(zé)搶信道。智能網(wǎng)在優(yōu)先級業(yè)務(wù)里的角色是識別呼叫類別、決定是否排隊、以及在呼叫接續(xù)參數(shù)中傳遞優(yōu)先級標(biāo)記。所以實際調(diào)測時千萬別在 SCP 上試圖去實現(xiàn)無線側(cè)的搶占邏輯那是把兩套不同層面的機(jī)制混為一談了。3. 讓業(yè)務(wù)跑起來的基礎(chǔ)數(shù)據(jù)HLR簽約、SCP數(shù)據(jù)與MSS觸發(fā)配置3.1 HLR側(cè)T-CSI/O-CSI簽約一個配置片段看懂所有參數(shù)GSM-R 智能網(wǎng)的數(shù)據(jù)配置從 HLR 簽約開始。沒有 CSIMSC 就不會往 SCP 發(fā) InitialDP后面一切業(yè)務(wù)邏輯都是空談。下文給出一個設(shè)備無關(guān)的簽約數(shù)據(jù)示例實際做數(shù)據(jù)時按廠商網(wǎng)管界面的等價操作完成// HLR CAMEL 簽約數(shù)據(jù)示例按廠商網(wǎng)管界面等價操作理解 ADD CAMEL-SUB: IMSI460010312345678, T-CSI100, GSMSCF-ADDR86700210001, SERVICEKEY21, DEFAULT-CALL-HANDLINGRELEASE, TRIGGER-TYPET-CSI, TRIGGER-DPROUTING-ADDRESS-ANALYSIS;這段配置里值得逐一說明的參數(shù)有五個。IMSI 必須綁定用戶唯一標(biāo)識而不是 MSISDN因為 GSM-R 終端在機(jī)車和司機(jī)之間頻繁換插按手機(jī)號簽約很容易出現(xiàn)號在人不在的錯配。T-CSI 是 HLR 里區(qū)分不同觸發(fā)類別的編號它和 SCP 側(cè)的業(yè)務(wù)鍵 SERVICEKEY 不一定相同兩邊映射關(guān)系要單獨核對。GSMSCF-ADDR 填的是 SCP 的 GT 地址MSC 靠它做 SCCP 層尋址這個地址一旦寫錯信令直接走不到 SCP。DEFAULT-CALL-HANDLING 是 SCP 故障或超時情況下 MSC 的兜底動作取值只有 RELEASE 和 CONTINUE 兩種。鐵路調(diào)度通信里我一般建議選 RELEASE理由很直白調(diào)度呼叫寧可接不通也不能因為 SCP 故障把緊急呼叫錯誤接到一個不相干的普通用戶那里。TRIGGER-DP 決定在呼叫的哪個階段攔停常見做法把觸發(fā)點設(shè)在路由地址分析階段這樣被叫號碼已經(jīng)收集完整SCP 拿著完整號碼去查庫才有意義。3.2 SCP業(yè)務(wù)數(shù)據(jù)功能號表與調(diào)度區(qū)映射怎么建SCP 側(cè)數(shù)據(jù)是 GSM-R 智能網(wǎng)真正跑業(yè)務(wù)的地方。工程交付時最花時間的往往不是信令調(diào)測而是把兩條業(yè)務(wù)表做扎實。第一條是功能號綁定表核心字段包括車次號、功能碼、當(dāng)前綁定 MSISDN、生效時間和失效時間。需要注意車次號與司機(jī)的綁定不是永久關(guān)系司機(jī)上車值乘時通過注冊流程寫入 SCP退乘后必須解除綁定否則調(diào)度呼叫會接到一個已經(jīng)下班的司機(jī)手機(jī)上。第二條是位置映射表核心字段包括位置區(qū)編號 LAC、小區(qū)標(biāo)識 CI、調(diào)度區(qū)編號和該調(diào)度區(qū)對應(yīng)的調(diào)度臺號碼。建表時最容易忽略的是跨區(qū)覆蓋場景一個小區(qū)覆蓋扇區(qū)伸到相鄰調(diào)度區(qū)邊界列車在這個小區(qū)下呼叫按主服務(wù)小區(qū)映射會接錯調(diào)度臺。常見做法是把邊界小區(qū)同時配置歸屬主調(diào)度區(qū)并加一條優(yōu)先級字段讓 SCP 按先精確小區(qū)、再位置區(qū)的順序匹配。SCP 上業(yè)務(wù)數(shù)據(jù)的增加和修改一般通過 SCE 完成。3.3 MSS/SSP側(cè)觸發(fā)數(shù)據(jù)GT翻譯與IMSI分析的核對項HLR 和 SCP 兩側(cè)數(shù)據(jù)都配好后MSS/SSP 側(cè)還有幾個核對項缺一個業(yè)務(wù)就起不來。第一是確認(rèn) MSC 的 IMSI 分析數(shù)據(jù)里對該號段啟用了 CAMEL 觸發(fā)否則 MSC 收到 CSI 也不會真的去觸發(fā)智能網(wǎng)。第二是核對 SCCP 層 GT 翻譯MSC 到 SCP 方向的路由要有一條SCP 回 MSC 方向的路由也要有一條這兩條經(jīng)常只配了一邊。第三是確認(rèn)兩邊配置的子系統(tǒng)號 SSN 一致SCP 側(cè) SSN 配置錯誤時MSC 發(fā)過去的報文會在 TCAP 層直接超時。再有一個是 CAMEL 版本配套。不同階段版本的 MSC 和 SCP 在 InitialDP 里的字段支持度差異很大例如位置信息字段在 CAMEL2 里并非必選而基于位置的尋址業(yè)務(wù)必須要用這個字段。遇到SCP 側(cè)收到了 InitialDP 但看不到小區(qū)號這類問題多半是版本協(xié)商后字段沒帶上。這些核對項全部過一遍后GSM-R 智能網(wǎng)才具備撥測條件下一步才能談信令參數(shù)。4. 功能尋址一次呼叫的完整信令路徑從InitialDP到Connect的關(guān)鍵參數(shù)4.1 功能尋址呼叫的信令路徑每一步往哪看把 GSM-R 智能網(wǎng)的功能尋址業(yè)務(wù)跑一遍完整呼叫能直觀看到信令參數(shù)在哪一步起作用。假設(shè)調(diào)度員要呼叫車次號 G1234 的司機(jī)撥號是接入碼加車次號加功能碼完整信令路徑如下主叫 MSC 根據(jù) O-CSI 觸發(fā)智能網(wǎng)先向 SCP 發(fā)出一條 InitialDP攜帶主叫號碼和原始被叫接入號。SCP 收到 O-CSI 觸發(fā)的 InitialDP 后檢查主叫權(quán)限然后返回 Continue告訴 MSC 繼續(xù)收集被叫號碼。MSC 完成號碼收集后被叫側(cè) MSC 根據(jù) T-CSI 觸發(fā)第二次 InitialDP這時 SCP 才去查功能號綁定表。SCP 查到 G1234 當(dāng)前綁定司機(jī)手機(jī)號后向 MSC 返回 Connect攜帶 destinationRoutingAddress 作為真正的被叫號碼。MSC 按普通呼叫接續(xù)流程向該手機(jī)號發(fā)起尋呼呼叫進(jìn)入正常的 GSM-R 語音通道。工程上我把這條路徑當(dāng)作 GSM-R 智能網(wǎng)調(diào)測的標(biāo)準(zhǔn)流。凡是功能尋址不通先按這個順序查第一次 InitialDP 有沒有發(fā)出、第一次之后有沒有收到 Continue、第二次 InitialDP 有沒有帶上完整被叫號碼、Connect 里的號碼對不對。四次交互中任何一次缺失信令跟蹤里一眼就能看出來不用靠猜。4.2 CAP消息關(guān)鍵字段locationInformation和destinationRoutingAddressGSM-R 智能網(wǎng)的信令參數(shù)主要集中在 CAP 消息里。調(diào)測時重點關(guān)注下面幾個字段它們幾乎決定了所有業(yè)務(wù)能否正確執(zhí)行// CAP InitialDP 關(guān)鍵字段邏輯示意非真實 ASN.1 編碼 { operationCode: initialDP, serviceKey: 21, imsi: 460010312345678, calledPartyNumber: 0089961234, callingPartyNumber: 00898654321, locationInformation: { cellGlobalId: 460-XX-LAC-CI, ageOfLocationInformation: 3 } }InitialDP 里的 serviceKey 是 SCP 識別業(yè)務(wù)邏輯的入口HLR 簽約數(shù)據(jù)里的 T-CSI 和 SCP 的 SERVICEKEY 需要映射正確IMSI 和 calledPartyNumber 是 SCP 做號碼翻譯的輸入locationInformation 中的 cellGlobalId 在基于位置的尋址里是核心判斷依據(jù)MSC 必須把這個字段真實上報否則 SCP 不知道呼叫從哪個區(qū)來。Connect 消息里的 destinationRoutingAddress 是 SCP 翻譯后的真實被叫號碼這個號碼的 TON/NPI 參數(shù)必須和 MSC 的路由分析數(shù)據(jù)一致不然交換機(jī)拿到號碼后照樣翻譯不出去。4.3 超時、缺省動作與優(yōu)先級傳遞三個方向的參數(shù)取舍GSM-R 智能網(wǎng)里還有一類參數(shù)不直接決定業(yè)務(wù)邏輯但決定業(yè)務(wù)穩(wěn)定性。SCP 響應(yīng)超時計時器就是最典型的一個MSC 發(fā)出 InitialDP 后SCP 需要在規(guī)定時間內(nèi)返回 Continue 或 Connect超時后 MSC 按 HLR 簽約數(shù)據(jù)里的 DEFAULT-CALL-HANDLING 執(zhí)行兜底動作。這個計時器設(shè)多少需要權(quán)衡太短會讓 SCP 負(fù)載稍高時就誤釋放正常呼叫太長則會讓調(diào)度員在守候時覺得呼叫卡住了。我一般按廠商模板取 5 到 10 秒再結(jié)合 SCP 處理能力動態(tài)調(diào)整。另一個需要關(guān)注的參數(shù)是呼叫釋放原因 cause。SCP 主動拒絕某一呼叫時會在 ReleaseCall 里攜帶 cause 值這個值最終會透傳到交換機(jī)的呼叫記錄里。工程上建議把 SCP 內(nèi)各類失敗場景的 cause 編碼統(tǒng)一規(guī)劃例如業(yè)務(wù)鍵錯誤、號碼綁定不存在、位置映射失敗各用不同 cause這樣后續(xù)查話單和信令跟蹤時不用逐條抓包就能快速歸類故障。優(yōu)先級傳遞方面需要單獨提醒eMLPP 優(yōu)先級在 CAMEL 對話里不是靠 SCP 控制無線資源的SCP 能做的是在 InitialDP 里讀取呼叫優(yōu)先級標(biāo)記、決定是否讓高優(yōu)先級業(yè)務(wù)插隊并在 Connect 后續(xù)接續(xù)時把優(yōu)先級參數(shù)帶回給 MSC。如果工程現(xiàn)場出現(xiàn)緊急呼叫被智能網(wǎng)排隊排住了的問題大概率是觸發(fā)條件里沒排除高優(yōu)先級呼叫類別而不是 SCP 本身業(yè)務(wù)邏輯有問題。5. GSM-R智能網(wǎng)現(xiàn)場避坑5個高發(fā)故障的定位與處置5.1 CSI 沒下發(fā)導(dǎo)致呼叫根本不觸發(fā)現(xiàn)場最常見的故障是HLR 里明明配了簽約但撥功能號沒有任何反應(yīng)信令跟蹤里連 InitialDP 都看不到。這類問題的原因是 VLR 里緩存的用戶簽約數(shù)據(jù)沒更新或者終端入網(wǎng)時 HLR 尚未完成 CSI 下發(fā)還有一種情況是 MSC 的 CAMEL 版本較老只支持 O-CSI 不支持 T-CSI。解決辦法是讓終端做一次重新位置更新或者開關(guān)機(jī)強(qiáng)制從 HLR 拉取最新簽約數(shù)據(jù)同時核對 MSC 的 CAMEL 功能開關(guān)。工程交付時我會要求核心網(wǎng)側(cè)在割接后主動觸發(fā)一次批量位置更新避免列車車載終端長時間不關(guān)機(jī)、帶著舊簽約數(shù)據(jù)一直跑。5.2 被叫號碼的 TON/NPI 錯配導(dǎo)致翻譯翻車另一種高頻故障是 SCP 返回的號碼在信令里看著正確但 MSC 出局時路由失敗呼叫直接釋放。抓包分析會發(fā)現(xiàn) Connect 消息里的 destinationRoutingAddress 攜帶的 TON/NPI 和 MSC 號碼分析數(shù)據(jù)不一致。比如 SCP 按 unknown 格式返回號碼MSC 側(cè)則按國內(nèi)號碼規(guī)則分析兩邊對不上交換機(jī)自然不認(rèn)。解決方法是全網(wǎng)統(tǒng)一編號計劃SCP 側(cè)返回號碼時統(tǒng)一按 E.164 格式化TON 設(shè)為 national、NPI 設(shè)為 ISDNMSC 側(cè)路由分析按同一規(guī)則配置。這個坑在功能尋址業(yè)務(wù)里尤其高發(fā)因為調(diào)度員撥的是接入碼加車次號而 SCP 返回的是完整手機(jī)號碼兩者的號碼屬性天然不同。5.3 邊界小區(qū)映射錯位導(dǎo)致基于位置的尋址誤判基于位置的尋址出現(xiàn)列車在 A 區(qū)卻接到 B 區(qū)調(diào)度臺的故障時多數(shù)人第一反應(yīng)是小區(qū)表配錯了實際查下來常常是邊界小區(qū)歸屬模糊。GSM-R 網(wǎng)絡(luò)里很多基站覆蓋遠(yuǎn)端延伸到相鄰調(diào)度區(qū)列車在邊界地帶的主服務(wù)小區(qū)可能一會兒切到 A 區(qū)、一會兒切到 B 區(qū)如果映射表只按 LAC 粗粒度配置就會出現(xiàn)誤判。解決方法是位置映射表做到小區(qū)粒度配置 CGI 而不是只配 LAC并且把邊界區(qū)域的越區(qū)覆蓋小區(qū)明確歸屬到管轄區(qū)驗收時安排列車在調(diào)度分界點往返跑兩次對比兩次呼叫接續(xù)的調(diào)度臺是否一致。血的教訓(xùn)是邊界場景永遠(yuǎn)不要拿單一地點的一次撥測結(jié)果下結(jié)論。5.4 雙MSC共用SCP時GT翻譯不一致組網(wǎng)規(guī)模稍大后GSM-R 智能網(wǎng)經(jīng)常是兩臺 MSC 共用一臺 SCP故障表現(xiàn)卻很怪在 MSC1 下業(yè)務(wù)一切正常終端漫游或切換到 MSC2 后功能尋址完全失效。原因是 MSC2 側(cè)的 SCCP 層 GT 翻譯數(shù)據(jù)沒配全或者 SCP 回程地址在 MSC2 上沒有對應(yīng)翻譯更隱蔽的是兩臺 MSC 的 CAMEL 階段版本不同MSC2 老版本不支持 SCP 下發(fā)的某個字段。排查時先在 MSC2 側(cè)做 SCCP 環(huán)回測試確認(rèn) GT 路由雙向可達(dá)再核對兩端的 CAMEL 版本協(xié)商結(jié)果。SCP 側(cè)也可以按 MSC 地址分別配置業(yè)務(wù)鍵避免不同 MSC 上報的業(yè)務(wù)數(shù)據(jù)互相干擾。5.5 緊急呼叫被智能網(wǎng)攔截引發(fā)優(yōu)先級業(yè)務(wù)沖突最危險的一類故障是緊急呼叫被智能網(wǎng)攔住了。司機(jī)按下緊急呼叫后本應(yīng)立即通過 eMLPP 預(yù)占資源接通調(diào)度臺結(jié)果卻沒反應(yīng)或者被排到隊列里。查信令會發(fā)現(xiàn)緊急呼叫類別被 O-CSI/T-CSI 當(dāng)成普通呼叫觸發(fā)了智能網(wǎng)SCP 處理過程中的排隊邏輯把高優(yōu)先級呼叫給拖住了。解決方法是交換側(cè)觸發(fā)分析數(shù)據(jù)里必須把緊急呼叫類別排除在智能網(wǎng)觸發(fā)條件之外讓這類呼叫繞過 SCP 直通SCP 側(cè)如需要識別優(yōu)先級應(yīng)通過 InitialDP 攜帶的優(yōu)先級字段做快速放行而不是進(jìn)入普通業(yè)務(wù)隊列。任何涉及行車安全的呼叫都不應(yīng)該依賴 SCP 的正常業(yè)務(wù)處理時長這必須作為一條硬性設(shè)計要求寫進(jìn)實施方案。6. 交付驗收這樣驗證GSM-R智能網(wǎng)信令過濾與場景呼叫矩陣GSM-R 智能網(wǎng)系統(tǒng)驗收階段我一般不會只做撥個號打通就算過而是用兩層驗證兜底。第一層是信令級驗證在 MSC 側(cè)信令監(jiān)測點抓 SCCP 承載的 TCAP 消息過濾出 CAP 報文重點核對關(guān)鍵路徑上的三組消息HLR 位置更新后的 CSI 下發(fā)、呼叫觸發(fā)時的 InitialDP、SCP 應(yīng)答的 Connect/ReleaseCall?，F(xiàn)場抓包時按一次呼叫的對話 ID 關(guān)聯(lián)全部消息檢查 InitialDP 里的 locationInformation 是否攜帶 CGI、Connect 里的 destinationRoutingAddress 的 TON/NPI 是否統(tǒng)一。第二層是業(yè)務(wù)級驗證按場景矩陣逐項撥測不能只測正常路徑還要測邊界和異常路徑。測試場景撥測方法預(yù)期結(jié)果信令核查點功能尋址調(diào)度臺撥車次號功能碼接通當(dāng)前綁定司機(jī)InitialDP → Connect 號碼是否與綁定一致基于位置的尋址列車在調(diào)度分界點兩側(cè)分別撥測分別接至對應(yīng)調(diào)度臺locationInformation 內(nèi) CGI 與映射表一致緊急呼叫模擬 eMLPP 最高優(yōu)先級呼叫快速接通且不排隊信令中無 SCP 攔截記錄SCP 主備倒換主用 SCP 手動倒換新呼叫恢復(fù)且存量呼叫記錄可查SCP 側(cè)業(yè)務(wù)恢復(fù)時間達(dá)標(biāo)驗收現(xiàn)場最容易漏掉的是 SCP 負(fù)荷較高時的超時行為我會專門做一次斷點測試在 SCP 側(cè)臨時把一條業(yè)務(wù)數(shù)據(jù)的查詢延時調(diào)大觀察 MSC 側(cè)是否按 DEFAULT-CALL-HANDLING 正確動作。還有一次教訓(xùn)讓我印象深刻功能尋址在測試環(huán)境一直正常上了真實列車環(huán)境就偶發(fā)接錯調(diào)度臺查了一個下午才發(fā)現(xiàn)是功能號綁定表里塞了兩條數(shù)據(jù)動檢車次和旅客車次綁到了同一個司機(jī)號上。從那以后我養(yǎng)成習(xí)慣每次驗收前先讓數(shù)據(jù)維護(hù)方導(dǎo)出一份綁定表做人工復(fù)核而不是直接扎進(jìn)信令里查。驗證 GSM-R 智能網(wǎng)先把數(shù)據(jù)看住再談鏈路和信令順序反了會多走很多彎路。希望幫到你。本文還有配套的精品資源點擊獲取