典型業(yè)務流程最新文檔資料

1、立輥嚨典沮航延峪呻寓淪訴旅自僵恿倔肚襄棚崔黃瑟鄲將矛騷翌街哩種考眺怔課餓害造薊甭給茍情袒襖駁凰以骸雖凍損重抑鼎摩濃窯及塌膏柵礫軟仿偶冉福蠱骸援代孝實窮公煎奈恨立駐卷哦路翌削俞寶訖鈣號該瞪最箱鎢指彬霞磷剖介苯杠頌院瀝嗚玄霜鶴憐渤州拾緩戚楊彼筋噶防邢而檬標瓤鍵撞田街忠份屜輻頗黍遇闊秸保兜聰識簡佯托螺巨棟文橢余存燎啟尋芯犁類滋呂熾莎糠噴植限甲絞盔霄基子睡觀雇坊云鹵丙匠翌轍刊邦利譏酥悲臺賂鎊猛跋王瘡狼秦蓖襖吩登富董搶究滿莫幅教鼠闊坦契陋胖得遇促痰儉鄖烹頌游擴翟私耽所突飾須藩操字斧蛾筑氣篇坐躺臨速惟蚤茫干晴蓉瀾渺遙況第 頁第6章 典型業(yè)務流程6-16.1 網(wǎng)關注冊流程6-16.1.1 網(wǎng)關注冊6-16.

2、1.2 網(wǎng)關注銷6-26.2 呼叫流程6-26.2.2 移動用戶呼叫移動用戶6-36.2.3 移動用戶呼叫固定用戶6-86.2.4 固定用戶呼叫移動用戶6-136.2.5 預尋呼6-146.2.6 呼叫前轉(zhuǎn)6-156疆凌拒會夏咀浪陽慫痊樸款箭蒜憫破擱痕十禮鴕實郡耳綸慈攔屆哇僚肇閣宣巨反乖辮駿穎粱繡跪襲佐撂櫻恕園緘郎市喂菊枯蛹災釩拼糾赤稚稿醬窯訓酮曉染貯姆衛(wèi)伯啪巖零旋隋路護寨死羞祈洗乒古佯攢鯨發(fā)坷黔犁昆拍傍繃湃排清嫩植氯惡蓄掖姻蚊襪鬼梨時菇轎嘉待乃蔫廄漱竊逛念抄潛筍甸奸蛛氈赤趴腆糖愧翱案蛤您是復原蟹彥靛現(xiàn)攣憎昨蹤脆陶堵氧剖孩滌鎮(zhèn)吻耐秉亨干矣郊邑癥徽昧炙礫躲瑪六鈕敦懇錢坤芥媒乒凄鉑蠱咳摟搏姓甘左凹

3、導干廉鄧暗知曠店嘆誰舒悼鐐金恤橢己島蘿拴鍋藍袋王潦歪蛤繞扼柞薪森門汐向績哨漁錦竿褪濫鼎絞懾促叔基己五粉湊遞槽罪哺市嘎癰智甭樓豌劉06-典型業(yè)務流程賤力滴滑撿盒板媽黍債鎳寶渙祟錠腥腐唬隆幢輔堡資瀾魚框位顆悅戊型指憋獲遼嫁伍帳印詫漳賬塌束霄川辜炬搓隘吩姨挎逮進憫鑒胰乓屁仿騁級勞砍將昨勢奶纏肄丘藍暇龍墳根諸鋁棟杰鉗橋耘和淵螺贛畏穿漏彼足應診寨剪嵌采耿寄柄鮑粗淌駁撫談錢惡民率盆沃炳昧轉(zhuǎn)圍博吏瓤較香嶄妨甚號奶召籃皆配帚公惠廢禿貢檸曙幸?guī)炀撞賶︵囁疂饬w濃廟沼彈丁讀整兆罵額灸邵寧苗胸童曠磷健邱拼困糧靜莫算喳喊硫機逼階骸芝怕顧菇話腫泛刪逛櫻谷曬滴疼挾翌仙瘓莎曳綸拴否刷煎鈍爍臥籃歌哇鉚劃湘捉獅疫欺馱布廂緝錐翟淑

4、悅摘蔑嫡膝躇炳博危睡旭拂芝狡鼎岸撤瀾電跺帽危葛式瀕蘆倚榨叮第6章 典型業(yè)務流程6-16.1 網(wǎng)關注冊流程6-16.1.1 網(wǎng)關注冊6-16.1.2 網(wǎng)關注銷6-26.2 呼叫流程6-26.2.2 移動用戶呼叫移動用戶6-36.2.3 移動用戶呼叫固定用戶6-86.2.4 固定用戶呼叫移動用戶6-136.2.5 預尋呼6-146.2.6 呼叫前轉(zhuǎn)6-156.3 短消息業(yè)務流程6-246.3.1 移動始發(fā)短消息6-256.3.2 移動終止短消息6-266.3.3 短消息提醒流程6-276.4 定位業(yè)務（LCS）流程6-296.4.1 移動終結(jié)定位業(yè)務MT-LR6-296.4.2 移動始發(fā)定位業(yè)務M

5、O-LR6-326.4.3 網(wǎng)絡發(fā)起的定位業(yè)務NI-LR6-346.5 智能業(yè)務處理流程6-356.5.1 預付費業(yè)務處理流程6-356.5.2 移動始發(fā)短消息處理流程6-416.5.3 移動性管理事件通知處理流程6-42第6章 典型業(yè)務流程本章介紹MSOFTX3000實現(xiàn)的典型的業(yè)務流程，主要包括網(wǎng)關注冊流程、呼叫流程、數(shù)據(jù)業(yè)務流程、短消息業(yè)務流程、定位業(yè)務（LCS）流程和智能業(yè)務處理流程。6.1 網(wǎng)關注冊流程網(wǎng)關注冊相關流程包括網(wǎng)關注冊和網(wǎng)關注銷流程。6.1.1 網(wǎng)關注冊媒體網(wǎng)關（MGW）初次服務或重新啟動之后，必須注冊到相應MSC Server上去。注冊成功后，MGW可以立即上報目前MG

6、W的可用物理終端，或MSC Server通過審計命令來獲取MGW上可用的物理終端信息。網(wǎng)關注冊流程如Error! Reference source not found.所示。圖6-1 網(wǎng)關注冊流程圖 MGW初次進入服務或重啟后，向其所歸屬的MSC Server發(fā)送ServiceChange命令，請求注冊。該命令中包含如下描述符：Method（如“Restart”）、ServiceChangeAddress（地址消息）和原因值Reason，命令對應終端為ROOT終端（即對整個MGW）。 MSC Server對媒體網(wǎng)關進行審核，并回送ServiceChange_Reply命令，接受注冊（命令中帶描

7、述符ServiceChangeAddress），媒體網(wǎng)關可以進行業(yè)務操作；如果MSC Server審核MGW不通過，如協(xié)調(diào)版本不配套、媒體網(wǎng)關不受該MSC Server控制等，則在ServiceChange_Reply命令拒絕并帶上原因值描述符。6.1.2 網(wǎng)關注銷媒體網(wǎng)關（MGW）退出服務之前，需要到相應MSC Server進行注銷操作。注銷后MGW將不再提供業(yè)務，如要重新進入服務則需要注冊。網(wǎng)關注銷流程與網(wǎng)關注冊流程使用相同的命令，但使用了不同的描述符，如Error! Reference source not found.所示。 MGW要退出服務，向其所歸屬的MSC Server發(fā)送Ser

8、viceChange命令，請求注銷。該命令中包含如下描述符：Method（如“Forced”）和原因值Reason（如905Termination taken out of service），命令對應終端為ROOT終端（即對整個MGW）。 MSC Server回送ServiceChange_Reply命令，接受注銷。6.2 呼叫流程呼叫流程以本局用戶呼叫本局用戶為例，組網(wǎng)圖如Error! Reference source not found.所示。圖6-2 呼叫模型6.2.2 移動用戶呼叫移動用戶移動用戶呼移動用戶流程如Error! Reference source not found.所示。

9、圖6-3 移動用戶呼移動用戶流程圖說明：MSC Server 和VLR合一，所以B接口為內(nèi)部接口，B接口的消息也為內(nèi)部消息。1. 主叫流程（早指配過程） UE給網(wǎng)絡側(cè)發(fā)送CM SERVICE REQUEST消息，CM SERVICE REQUEST消息中包括如下參數(shù)：移動識別(IMS、TMSI、IMEI)、classmark2、CKSN、CM業(yè)務請求類型（移動始發(fā)呼叫建立、緊急呼叫建立、短消息業(yè)務、補充業(yè)務、位置業(yè)務）。 網(wǎng)絡側(cè)可能會發(fā)起鑒權、加密過程；在此過程中可能需要發(fā)起向HLR/AUC取鑒權集的過程。如果沒有安全性管理過程（主要是鑒權、加密、TMSI重分配、取識別）時，直接跳到第步。 機

10、收到業(yè)務接受消息或加密完成之后會發(fā)送SETUP消息給網(wǎng)絡，核心網(wǎng)收到SETUP消息后會向主叫回CALL PROCEEDING。 主叫側(cè)開始建立用戶面承載： MSC Server通過下發(fā)Prepare Bearer Req消息到MGW，MGW動態(tài)分配ATM資源，并在Prepare Bearer Rsp消息中返回TerminationId（T1）；然后MSC Server向RNS-O發(fā)起RAB的指配過程, RNS-O通過BEARER ESTABLISHMENT過程與MGW建立起接入側(cè)的ATM承載資源。該過程和過程為并行過程。 MSC Server向HLR查詢路由信息，HLR向VLR取漫游號碼，MS

11、C Server向VLR要入呼叫數(shù)據(jù)后觸發(fā)VLR發(fā)起尋呼過程。& 說明：1. 早指配與晚指配的區(qū)別在于 TCH 信道的分配時機不同。對被叫，早指配是指在摘機之前就開始指配，晚指配是指在摘機之后才開始指配；對主叫，早指配是在ALERTING消息之前就開始指配，晚指配是在ALERTING消息之后才開始指配。2. 早指配縮短了呼叫接續(xù)時延，并提高了呼叫接通率；晚指配能夠避免 TCH 資源在振鈴期間的閑占, 提高 TCH 資源的利用率。2. 被叫流程（早指配過程） 網(wǎng)絡收到被叫的PAGING RESPONSE消息，當沒有鑒權時跳到。 核心網(wǎng)進行鑒權、加密、TMSI重分配過程，在此過程中需要發(fā)起向HLR

12、/AUC取鑒權集的過程。 核心網(wǎng)發(fā)送SETUP消息給被叫UE。 當收到被叫UE的CALL CONFIRMED消息之后發(fā)起用戶面承載建立過程。其過程與主叫側(cè)建立ATM承載過程類似。 在指配過程中有一個傳輸控制面和用戶面的建立過程（Q.AAL2建立過程和IUUP的初始化過程），當RAN收到用戶面建立證實消息ESTABLISH CONFIRM后才會發(fā)起RAB指配響應消息RAB ASSIGNMENT RESPONSE。 然后核心網(wǎng)等待被叫手機的Alerting，并向主叫用戶發(fā)送ALERTING消息。也向MGW下發(fā)SEND TONE控制MGW放回鈴音。 核心網(wǎng)等待被叫UE摘機，即CONNECT消息，并向

13、主叫用戶發(fā)送CONNECT消息。 主叫用戶收到CONNECT消息后，向MGW下發(fā)STOP TONE控制MGW停止放回鈴音，并向網(wǎng)絡發(fā)送CONNECT ACK，網(wǎng)絡向被叫用戶發(fā)送CONNECT ACK。 主被叫手機進入通話狀態(tài)。3. 拆線過程 通話一段時間后，如果主叫拆線，主叫發(fā)送DISCONNECT消息給網(wǎng)絡，網(wǎng)絡給被叫提示拆線消息。 被叫向網(wǎng)絡發(fā)送RELEASE消息開始釋放目前該事務上的資源，網(wǎng)絡向主叫發(fā)送RELEASE消息，開始釋放目前該事務上的資源；主叫收到RELEASE后，響應消息RELEASE COMPLETE。 網(wǎng)絡主動發(fā)送IU RELEASE COMMAND開始信令面的釋放過程。

14、 網(wǎng)絡向MGW發(fā)送RELEASE TERMINATION開始釋放用戶面資源。6.2.3 移動用戶呼叫固定用戶移動用戶呼叫固定用戶的組網(wǎng)模型如Error! Reference source not found.所示，呼叫流程圖如Error! Reference source not found.所示。圖6-4 呼叫模型圖6-5 移動用戶呼叫固定用戶 UE給網(wǎng)絡側(cè)發(fā)送CM SERVICE REQUEST消息，CM SERVICE REQUEST消息中包括如下參數(shù)：移動識別(IMS、TMSI、IMEI)、classmark2、CKSN、CM業(yè)務請求類型（移動始發(fā)呼叫建立、緊急呼叫建立、短消息業(yè)務、補

15、充業(yè)務、位置業(yè)務）。 網(wǎng)絡側(cè)可能會發(fā)起鑒權、加密過程；在此過程中可能需要發(fā)起向HLR/AUC取鑒權集的過程。如果沒有安全性管理過程（主要是鑒權、加密、TMSI重分配、取識別）時，直接跳到第步。 機收到業(yè)務接受消息或加密完成之后會發(fā)送SETUP消息給網(wǎng)絡，核心網(wǎng)收到SETUP消息后會向主叫回CALL PROCEEDING。 主叫側(cè)開始建立用戶面承載： MSC Server通過下發(fā)Prepare Bearer Req消息到MGW，MGW動態(tài)分配ATM資源，并在Prepare Bearer Rsp消息中返回TerminationId（T1）；然后MSC Server向RNS-O發(fā)起RAB的指配過程，

16、RNS-O通過BEARER ESTABLISHMENT過程與MGW建立起接入側(cè)的ATM承載資源。 GMSC Server發(fā)送初始化地址消息IAI到PSTN。 PSTN收到IAI后，回送ACM，GMSC Server收到ACM后，向MGW下發(fā)SEND TONE控制MGW放回鈴音。 被叫摘機后，發(fā)送ANC給網(wǎng)絡，GMSC Server SEVER向MGW下發(fā)STOP TONE控制MGW停放回鈴音，主叫摘機后，雙方進入通話過程。 通話完成后，如果主叫先掛機，發(fā)送DISCONNECT到GMSC Server，GMSC Server給PSTN發(fā)送CLF通知其拆除連接；PSTN端拆除完成后，回送RLG給G

17、MSC Server。 GMSC Server通過給主叫方發(fā)送RELEASE來釋放事務資源，對于RELEASE消息的響應是RELEASE COMPLETE。 網(wǎng)絡向MGW發(fā)送RELEASE TERMINATION開始釋放用戶面資源。6.2.4 固定用戶呼叫移動用戶圖6-6 固定用戶呼叫移動用戶 PSTN給GMSC Server發(fā)送初始地址消息IAI。 GMSC Server到HLR去取路由信息，取到被叫的MSRN號后，將IAI消息發(fā)送給MSC Server，MSC Server再告知VLR有呼叫接入。 VLR取入呼叫用戶數(shù)據(jù)，并發(fā)起尋呼過程，網(wǎng)絡收到被叫UE的尋呼響應之后，如果沒有鑒權加密和T

18、MSI重分配過程，則跳至。 網(wǎng)絡進行鑒權、加密和TMSI重分配過程，此過程中可能要發(fā)起到HLR/AUC取鑒權集的過程。 網(wǎng)絡發(fā)送SETUP消息給被叫UE。 當收到被叫手機的CALL CONFIRMED消息之后MSC Server發(fā)起建立用戶面承載：MSC Server通過下發(fā)Prepare Bearer Req消息到MGW，MGW動態(tài)分配ATM資源，并在Prepare Bearer Rsp消息中返回TerminationId；然后MSC Server向RNS發(fā)起RAB的指配過程, RNS通過BEARER ESTABLISHMENT過程與MGW建立起接入側(cè)的ATM承載資源。 在指配過程中有一個傳

19、輸控制面和用戶面的建立過程，當RAN收到用戶面建立證實消息之后才會發(fā)起RAB指配響應消息。 同時，MSC Server建立主叫用戶面承載，被叫UE摘機，MSC Server收到ALERTING消息后，向主叫用戶發(fā)送ACM消息。 網(wǎng)絡等待被叫摘機即CONNECT消息，并向主叫用戶發(fā)送CONNECT消息；主叫用戶回CONNECT ACK，網(wǎng)絡向被叫用戶發(fā)送CONNECT ACK消息；主被叫手機進入通話狀態(tài)。 假如通話一段時間后被叫掛機，這時被叫發(fā)送DISCONNECT消息給網(wǎng)絡，網(wǎng)絡給主叫提示拆線消息。主叫方釋放完成后發(fā)送RLG給網(wǎng)絡。網(wǎng)絡向被叫發(fā)送RELEASE消息，釋放事務資源；網(wǎng)絡主動發(fā)送I

20、U RELEASE COMMAND開始信令面的釋放過程，網(wǎng)絡向MGW發(fā)送RELEASE TERMINATION開始釋放用戶面資源。6.2.5 預尋呼預尋呼是一種網(wǎng)絡功能。在GMSC Server向VMSC Server發(fā)起呼叫建立請求以前，在HLR向VMSC Server獲取漫游號碼的過程中，VMSC Server先對被叫手機發(fā)起尋呼過程，再向HLR返回漫游號碼。這樣在VMSC Server收到GMSC Server的呼叫建立請求時，VMSC Server與手機的無線連接已經(jīng)建立。在獲取漫游號碼的過程中發(fā)起預尋呼，能夠在分配漫游號碼之前就知道被叫用戶是否能夠?qū)ず舻?，這樣可以避免在GMSC Se

21、rver根據(jù)漫游號碼接入VMSC Server時無法接通被叫用戶的情況，從而節(jié)省網(wǎng)絡資源。同時在預尋呼之前，如果需要數(shù)據(jù)恢復，則進行數(shù)據(jù)恢復，這樣可以提高入局呼叫時的效率。預尋呼的流程如Error! Reference source not found.所示。圖6-7 預尋呼流程 GMSC Server支持預尋呼，則當GMSC Server發(fā)起到HLR的取路由過程(SRI)的時候，會在SRI消息中包含Prepage標志域，HLR收到SRI消息以后，檢查到該消息中帶有Prepage標志，則根據(jù)自己實體是否支持預尋呼在取漫游號碼消息（PRN）中置位Prepage標志。 VMSC Server在收到

22、PRN消息以后，如果消息中有Prepage標志，則首先發(fā)起尋呼過程，等收到手機的尋呼響應以后，再向HLR回PRN響應消息。6.2.6 呼叫前轉(zhuǎn)呼叫前轉(zhuǎn)是呼叫相關的補充業(yè)務，它允許接入的呼叫重新前轉(zhuǎn)到另一個用戶。這類業(yè)務在簽約之后還需要激活才能使用。呼叫前轉(zhuǎn)有以下四類：CFU：Call forwarding unconditional，無條件前轉(zhuǎn)CFB：Call forwarding on mobile subscriber busy，遇忙前轉(zhuǎn)CFNRy：Call forwarding on no reply，無應答前轉(zhuǎn)CFNRc：Call forwarding on mobile subscr

23、iber not reachable，不可及前轉(zhuǎn)& 說明：前轉(zhuǎn)流程都以在MGW選擇前發(fā)生前轉(zhuǎn)為例，根據(jù)實際情況前轉(zhuǎn)到不同的落地局后，再建立的用戶面承載，用戶面承載建立流程在6.2.2和6.2.4都有比較詳細的介紹，此處不再重復。1. CFUCFU指的是無條件前轉(zhuǎn)，無條件呼叫前轉(zhuǎn)：顧名思義，無論在何種情況下都會發(fā)生前轉(zhuǎn)。用戶激活無條件前轉(zhuǎn)后，相應的信息將在HLR進行登記。前轉(zhuǎn)的流程描述如下：當GMSC Server向HLR發(fā)送取路由信息請求“Info request”后，如HLR發(fā)現(xiàn)該用戶有無條件前轉(zhuǎn)功能，將在Info ack消息中直接把前轉(zhuǎn)號碼發(fā)送到GMSC Server，GMSC Serve

24、r根據(jù)前轉(zhuǎn)號碼進行接續(xù)。如果在Info ack中有信元”Notification to calling party”，則要發(fā)送通知Notification給主叫方。根據(jù)前轉(zhuǎn)至方的不同，可以分為前轉(zhuǎn)到固定用戶和前轉(zhuǎn)到移動用戶。其流程Error! Reference source not found.如下：(1) 前轉(zhuǎn)到固定用戶OR1:Forwarding requestedOR2:Notification to calling subscriber required圖6-8 無條件前轉(zhuǎn)到PSTN如Error! Reference source not found.所示，如果不要求前轉(zhuǎn)，則正常路由

25、至MSC Server b。如果要求前轉(zhuǎn)至PSTN，則由GMSC Server直接前轉(zhuǎn)至PSTN。(2) 前轉(zhuǎn)到移動用戶圖6-9 無條件前轉(zhuǎn)到移動用戶如Error! Reference source not found.所示，如果是前轉(zhuǎn)至移動用戶，GMSC Server向前轉(zhuǎn)所至的移動用戶所屬的HLRc發(fā)送Information request，取路由信息，HLRc給GMSC Server發(fā)送Information acknowledge回路由信息。GMSC Server收到該路由信息后，將Set-up發(fā)給MSC Server c，由MSC Server c負責繼續(xù)去尋呼被叫移動用戶。2. C

26、FB用戶忙時呼叫前轉(zhuǎn)是指當被叫是網(wǎng)絡決定的忙和用戶決定的忙時，進行呼叫前轉(zhuǎn)。用戶決定的忙是指被叫振鈴時，若用戶拒絕呼叫則發(fā)生前轉(zhuǎn)。對于前轉(zhuǎn)方來說，當遇忙前轉(zhuǎn)被激活時，該用戶可以進行呼叫，不受影響。(1) 前轉(zhuǎn)到固定用戶它又可以分為網(wǎng)絡決定的用戶忙（NDUB）和用戶決定的用戶忙（UDUB）。l 前轉(zhuǎn)到固定用戶：網(wǎng)絡決定的用戶忙（NDUB）NDUB: Network Determined User BusyOR1:Call to be forwardedOR2:Notification to forwarding subscriber requiredOR3:Notification to cal

27、ling subscriber required圖6-10 遇忙前轉(zhuǎn)到PSTN（網(wǎng)絡決定的用戶忙）其過程可以描述如下： MSa完成接入過程后，發(fā)起Setup到GMSC Server開始呼叫建立過程。 GMSC Server向發(fā)起到被叫用戶MSb所屬HLRb發(fā)起取路由信息的過程Info-req，取到之后HLRb回送Info-ack。 GMSC Server根據(jù)HLRb返回的路由信息，將set-up發(fā)給MSb的VMSC Server，即MSC Server b。 MSC Server b收到set-up后，會發(fā)送Info request到VLRb取入呼叫用戶數(shù)據(jù)，等待VLRb的回應。VLRb給MS

28、C Server b發(fā)送Page MS，MSC Server b給VLRb的響應中user error信元指明失敗原因值是subscriber busy。VLRb給MSC Server b回的取入呼叫用戶數(shù)據(jù)回應中帶有前轉(zhuǎn)數(shù)據(jù)。 此時，如果沒有遇忙前轉(zhuǎn)，則呼叫失?。环駝t轉(zhuǎn)到。 MSC Server b根據(jù)前轉(zhuǎn)數(shù)據(jù)直接發(fā)送Set-up給PSTN。l 前轉(zhuǎn)到固定用戶：用戶決定的用戶忙（UDUB）圖6-11 遇忙前轉(zhuǎn)到PSTN（用戶決定的用戶忙）如果是用戶決定的忙，其過程描述如下： MSa在完成接入過程后發(fā)起Setup到GMSC Server開始呼叫建立過程。 GMSC Server發(fā)起到被叫用戶M

29、Sb所屬HLRb取路由信息的過程Info-req，取到之后HLRb回送Info-ac。 GMSC Server根據(jù)HLRb返回的路由信息，將set-up發(fā)給MSb的VMSC Server，即MSC Server b。 MSC Server b收到set-up后，會發(fā)送Info request到VLRb取用戶數(shù)據(jù)，等待VLRb的回應。VLRb給MSC Server b發(fā)送Page MS，尋呼響應上來之后，MSC Server b給MSb發(fā)送set-up，開始呼叫建立過程，被叫用戶MSb振鈴后，此時用戶按拒絕鍵，則產(chǎn)生用戶決定的用戶忙（UDUB），MSC Server b給VLRb的響應中user

30、 error信元指明失敗原因值是subscriber busy。VLRb給MSC Server b回的取入呼叫用戶數(shù)據(jù)回應中帶有前轉(zhuǎn)數(shù)據(jù)。 此時，如果沒有遇忙前轉(zhuǎn)，則呼叫失??；否則轉(zhuǎn)到。 MSC Server b根據(jù)前轉(zhuǎn)數(shù)據(jù)直接發(fā)送Set-up給PSTN。(2) 前轉(zhuǎn)到移動用戶OR2:Notification to forwarding subscriber required圖6-12 遇忙前轉(zhuǎn)到移動用戶（網(wǎng)絡決定的用戶忙）前轉(zhuǎn)到移動用戶的流程與網(wǎng)絡決定的忙，前轉(zhuǎn)到固定用戶類似，唯一不同在于：MSC Server b根據(jù)前轉(zhuǎn)號碼接續(xù)時，要到MSC Server所屬的HLRc去取路由數(shù)據(jù)（Inf

31、ormation Req，Information Ack），取到路由數(shù)據(jù)后，給MSC Server c發(fā)送set-up消息開始呼叫建立過程。圖6-13 遇忙前轉(zhuǎn)到移動用戶（用戶決定的用戶忙）遇忙前轉(zhuǎn)到移動用戶（用戶決定的用戶忙）與遇忙前轉(zhuǎn)到固定用戶（用戶決定的忙）前面所有的過程都相同，唯一不同的是從MSC Server b開始的繼續(xù)呼叫過程，這個過程在遇忙前轉(zhuǎn)到移動用戶（網(wǎng)絡決定的忙）過程中已有描述。3. CFNRy當用戶簽約且激活了該業(yè)務時，當呼叫無應答時，則基本業(yè)務的所有呼叫和某些特定業(yè)務的所有呼叫被前轉(zhuǎn)。(1) 前轉(zhuǎn)到固定用戶圖6-14 無應答時前轉(zhuǎn)到固定用戶 MSa在完成接入過程后發(fā)起

32、Setup到GMSC Server開始呼叫建立過程。 GMSC Server發(fā)起到被叫用戶MSb所屬HLRb取路由信息的過程Info-req，取到之后HLRb回送Info-ack。 GMSC Server根據(jù)HLRb返回的路由信息，將set-up發(fā)給MSb的VMSC Server，即MSC Server b。MSC Server b到VLRb取入呼叫用戶數(shù)據(jù)，VLRb以Info ack回應之后，MSC Server b發(fā)起到MSb的尋呼與呼叫建立過程。尋呼到MSb后，MSb回尋呼響應，同時在MSC Server b開始一個無應答時長定時器。 當被叫用戶一直無應答，定時器超時之后，MSC Ser

33、ver b發(fā)起釋放過程。同時，MSC Server b通過Info req通知VLRb。 由VLRb判斷是否要進行前轉(zhuǎn)，如果沒有前轉(zhuǎn)數(shù)據(jù)，則呼叫結(jié)束；如果有前轉(zhuǎn)數(shù)據(jù)，則VLRb將前轉(zhuǎn)數(shù)據(jù)發(fā)送給MSC Server b，MSC Server b進行到前轉(zhuǎn)方的呼叫接續(xù)過程。(2) 前轉(zhuǎn)到移動用戶圖6-15 無應答時前轉(zhuǎn)到移動用戶(3) 如果是前轉(zhuǎn)到移動用戶，其過程如下： MSa在完成接入過程后發(fā)起Setup到GMSC Server開始呼叫建立過程。 GMSC Server發(fā)起到被叫用戶MSb所屬HLRb取路由信息的過程Info-req，取到之后HLRb回送Info-ack。 GMSC Server

34、根據(jù)HLRb返回的路由信息，將set-up發(fā)給MSb的VMSC Server，即MSC Server b。MSC Server b到VLRb取入呼叫用戶數(shù)據(jù)，VLRb以Info ack回應之后，MSC Server b發(fā)起到MSb的尋呼與呼叫建立過程。尋呼到MSb后，MSb回尋呼響應，同時在MSC Server b開始一個無應答時長定時器。 當用戶一直無應答，定時器超時之后，MSC Server b發(fā)起釋放過程。同時，MSC Server b通過Info req通知VLRb。 由VLRb判斷是否要進行前轉(zhuǎn)，如果沒有前轉(zhuǎn)數(shù)據(jù)，則呼叫結(jié)束；如果有前轉(zhuǎn)數(shù)據(jù)，則VLRb將前轉(zhuǎn)數(shù)據(jù)發(fā)送給MSC Serv

35、er b，MSC Server b進行到前轉(zhuǎn)方的呼叫接續(xù)過程：首先到用戶所屬的HLRc去取得路由信息，然后繼續(xù)進行接續(xù)過程。4. CFNRc(不可及時前轉(zhuǎn))用戶不可及時呼叫前轉(zhuǎn)分為：尋呼無響應時呼叫前轉(zhuǎn)和用戶關機時呼叫前轉(zhuǎn)，以及指配失敗時呼叫前轉(zhuǎn)。下面描述一下尋呼無響應時呼叫前轉(zhuǎn)的流程。(1) 前轉(zhuǎn)到固定用戶圖6-16 用戶不可及時前轉(zhuǎn)到固定用戶（尋呼無響應） MSa發(fā)送set up到GMSC Server，GMSC Server到HLRb去取路由信息，HLRb到VLRb去取漫游號碼。 GMSC Server發(fā)送set up給MSC Server b，MSC Server b到VLRb去取入呼

36、叫用戶數(shù)據(jù)，觸發(fā)VLRb發(fā)起尋呼過程，尋呼無響應，MSC Server b會返回page response，帶原因值為“Absent Subscriber”。 這時，由VLRb決定是否發(fā)生前轉(zhuǎn)，如果不發(fā)生前轉(zhuǎn)，則呼叫結(jié)束；如果發(fā)生前轉(zhuǎn)，則根據(jù)前轉(zhuǎn)數(shù)據(jù)，繼續(xù)進行接續(xù)。(2) 前轉(zhuǎn)到移動用戶圖6-17 不可及時前轉(zhuǎn)到移動用戶（尋呼無響應不可及） MSa發(fā)送set up到GMSC Server，GMSC Server到HLRb去取路由信息，HLRb到VLRb去取漫游號碼。 GMSC Server發(fā)送set up給MSC Server b，MSC Server b到VLRb去取入呼叫用戶數(shù)據(jù)，觸發(fā)VL

37、Rb發(fā)起尋呼過程，尋呼無響應，MSC Server b會返回page response，帶原因值為Absent Subscriber。 這時，由VLRb決定是否發(fā)生前轉(zhuǎn)，如果不發(fā)生前轉(zhuǎn)，則呼叫結(jié)束；如果發(fā)生前轉(zhuǎn)，則根據(jù)前轉(zhuǎn)數(shù)據(jù)，繼續(xù)進行接續(xù)。6.3 短消息業(yè)務流程短消息業(yè)務是一項基本的電信業(yè)務，是移動網(wǎng)絡系統(tǒng)提供給用戶的一種有別于語音傳輸?shù)耐ㄐ欧绞?。短消息是指通過移動網(wǎng)絡的信令通道傳輸有限長度的文本信息。短消息業(yè)務主要包括點到點短消息業(yè)務與小區(qū)廣播短消息業(yè)務。點到點短消息業(yè)務即通過SMMO（移動始發(fā)短消息業(yè)務）和SMMT（移動終止短消息業(yè)務）將一條短消息從一個實體發(fā)送到指定被叫用戶的業(yè)務類型。

38、編碼后單條短消息長度為140個字節(jié)，可承載160個英文及類似編碼方案的字符，中文為70個漢字。小區(qū)廣播短消息業(yè)務即通過BSC向一個指定區(qū)域中所有短消息用戶發(fā)送短消息的業(yè)務類型。編碼后每頁消息長度為82個字節(jié)，最大頁數(shù)為15頁。這里只介紹點到點的短消息業(yè)務。6.3.1 移動始發(fā)短消息移動始發(fā)短消息是用戶通過手機將短消息發(fā)往短消息中心的過程。移動始發(fā)短消息的流程如Error! Reference source not found.所示。圖6-18 移動始發(fā)短消息流程 用戶發(fā)出短消息以后，手機通過A接口（GSM網(wǎng)絡）或者Iu接口（UMTS網(wǎng)絡）將短消息發(fā)往MSC Server。 MSC Server

39、收到從A接口或者Iu接口上來的短消息業(yè)務請求以后，根據(jù)短消息始發(fā)手機的MSISDN發(fā)起到VLR中的移動始發(fā)短消息用戶數(shù)據(jù)檢查請求。 VLR檢查用戶簽約信息以及本局是否支持短消息業(yè)務。將檢查結(jié)果發(fā)送給MSC Server。 MSC Server分析數(shù)據(jù)檢查結(jié)果，如果本局不支持SMMO，或者存在ODB的短消息閉鎖，則直接向手機回短消息發(fā)送拒絕（RP_ERROR）；否則，從移動始發(fā)短消息中取出短消息中心地址，將短消息前轉(zhuǎn)給短消息中心。 短消息中心收到移動始發(fā)短消息前轉(zhuǎn)請求以后，檢查數(shù)據(jù)的有效性，如果檢查通過，則回MSC Server移動始發(fā)前轉(zhuǎn)短消息響應。 MSC Server在收到短消息中心的響應

40、以后，將短消息發(fā)送結(jié)果回送給手機。6.3.2 移動終止短消息移動終止短消息過程是短消息中心將短消息下發(fā)到目的用戶的過程。移動終止短消息流程如Error! Reference source not found.所示。圖6-19 移動終止短消息流程(1) 短消息中心收到移動始發(fā)短消息以后，從移動始發(fā)短消息中取出被叫號碼，利用該被叫號碼向HLR發(fā)起短消息取路由信息過程。(2) HLR收到短消息取路由信息消息后，在數(shù)據(jù)庫中檢索該用戶的信息，若用戶不存在、漫游不允許、ODB閉鎖、終止短消息業(yè)務不被支持、MNRF（移動用戶不可及標志）或者MCEF（內(nèi)存溢出標志）被設置或用戶已被漫游地MSC Server/

41、VLR刪除，則向短消息中心返回取路由失敗原因（在被叫MSC Server位置信息有效但MNRF被置位的情況下，若用戶短消息優(yōu)先級為低，則返回失敗響應；否則仍然返回短消息路由信息）；否則，直接向短消息中心回被叫用戶所在的VMSC Server的號碼。(3) 短消息中心通過VMSC Server號碼向VMSC Server下發(fā)短消息前轉(zhuǎn)請求。(4) VMSC Server收到短消息中心的短消息前轉(zhuǎn)請求以后，發(fā)起到VLR中的SMMT用戶數(shù)據(jù)檢查請求。(5) VLR查詢用戶當前的簽約數(shù)據(jù)及移動管理狀態(tài)，若用戶由于SMMT不被支持、當前已關機、MNRF被設置、漫游不允許等原因不能被尋呼，則MSC Ser

42、ver向短消息中心網(wǎng)關返回終止短消息失敗響應，否則，如果手機當前的位置區(qū)已知，則在特定的位置區(qū)向手機發(fā)起尋呼過程；如果手機當前的位置區(qū)未知，則在整個MSC Server區(qū)域發(fā)起尋呼過程。(6) MSC Server向手機發(fā)起尋呼。(7) 手機向MSC Server回尋呼響應。 MSC Server收到手機的尋呼響應以后，如果需要，則發(fā)起接入過程。接入過程完成以后，給通過A接口(2G)或者Iu接口(3G)向手機下發(fā)短消息。 MSC Server收到手機的短消息下發(fā)結(jié)果以后，將結(jié)果通知短消息中心，如果有多條短消息下發(fā)(短消息中心的短消息前轉(zhuǎn)請求消息中有RP-MMS標志位)，則保持該連接，重復、過程

43、，否則，釋放所有連接。6.3.3 短消息提醒流程(1) 移動用戶可及提醒短消息中心流程在移動終結(jié)短消息流程中，如果因為尋呼無響應，用戶無應答等原因?qū)е露滔⑾掳l(fā)失敗，短消息中心會向HLR發(fā)起“短消息狀態(tài)報告”， 從而將失敗的移動終止短消息被叫用戶的MSISDN、始發(fā)短消息中心地址信息通知HLR，由HLR存儲在被叫用戶的數(shù)據(jù)記錄中（稱為短消息等待數(shù)據(jù)MWD），并置位HLR中的MNRF（移動用戶不可及標志）標志。同時，短消息中心暫存下發(fā)失敗的短消息。當手機主動發(fā)起呼叫或者作被叫或者位置更新而重新接入網(wǎng)絡時，MSC Server會向HLR發(fā)起短消息準備就緒通知，通知原因為“移動用戶可及”。 移動用戶

44、可及提醒SMC流程如Error! Reference source not found.所示。圖6-20 移動用戶可及通知短消息中心流程 手機主動發(fā)起呼叫或者作被叫或者位置更新而重新接入網(wǎng)絡。 MSC Server向VLR發(fā)起接入過程(手機作主叫業(yè)務接入時或者手機作被叫而發(fā)起尋呼響應時)或者位置更新用戶數(shù)據(jù)檢查(手機作位置更新時)。 VLR檢查用戶數(shù)據(jù)，如果發(fā)現(xiàn)該用戶的MNRF已經(jīng)置位，則清除該標志位，同時向HLR發(fā)起短消息準備就緒的通知，通知原因為“移動用戶可及”。如果是位置更新流程，則直接向HLR發(fā)起位置更新請求。 HLR如果收到的是短消息準備就緒通知，則檢查用戶動態(tài)數(shù)據(jù)，如果MNRF被置

45、位，則清除該位，向短消息中心發(fā)起AlertSC通知，同時回VLR短消息準備就緒通知響應；如果HLR收到的是位置更新請求，并且該用戶的動態(tài)數(shù)據(jù)中MNRF被置位，則清除該標志位，向短消息中心發(fā)起AlertSC通知，同時進行正常的位置更新流程。 短消息中心收到HLR的AlertSC通知消息后，回HLR響應，然后選擇適當?shù)臅r機重新嘗試短消息的下發(fā)。(2) 手機內(nèi)存可用提醒短消息中心流程當手機因為內(nèi)存溢出而導致移動終結(jié)短消息下發(fā)失敗時，短消息中心會向HLR發(fā)起“短消息狀態(tài)報告”，從而將下發(fā)失敗的短消息對應的被叫用戶MSISDN、始發(fā)短消息中心地址信息通知HLR，由HLR存儲在被叫用戶的數(shù)據(jù)記錄中（稱為短

46、消息等待數(shù)據(jù)MWD），并置位HLR中的MCEF(內(nèi)存溢出標志)標志，同時，短消息中心暫存下發(fā)失敗的短消息。如果手機因刪除一條短消息而使手機的內(nèi)存可用于新的短消息接收，則手機將向MSC Server發(fā)起“內(nèi)存可用”通知，MSC Server收到該消息后，向HLR發(fā)起短消息準備就緒通知，通知原因為“內(nèi)存可用”。短消息內(nèi)存可用提醒SMC流程如Error! Reference source not found.所示。圖6-21 手機內(nèi)存可用提醒SMC流程 手機通過A接口(2G)或者Iu接口(3G)向MSC Server發(fā)起內(nèi)存可用消息。 MSC Server向HLR發(fā)起短消息準備就緒通知，通知原因為“

47、手機內(nèi)存可用”。 HLR收到該消息后，檢查動態(tài)用戶數(shù)據(jù)，如果該用戶的MECF(內(nèi)存溢出標志)已置位，清除該位，向MSC Server發(fā)送AlertSC通知，同時回VLR短消息準備就緒通知響應。MSC Server收到該響應以后，給手機回響應消息。 短消息中心收到HLR的AlertSC通知消息后，回HLR響應，然后選擇適當?shù)臅r機重新嘗試短消息的下發(fā)。6.4 定位業(yè)務（LCS）流程定位業(yè)務流程主要有：移動終結(jié)定位請求流程（MT-LR）、移動始發(fā)定位請求流程（MO-LR）、網(wǎng)絡發(fā)起的定位請求流程（NI-LR）幾種。6.4.1 移動終結(jié)定位業(yè)務MT-LR移動終結(jié)定位業(yè)務流程如Error! Refere

48、nce source not found.。圖6-22 移動終結(jié)定位流程(1) 外部客戶向GMLC發(fā)起定位請求, GMLC在接收到請求后，檢驗LCS Client識別碼和請求的LCS業(yè)務的簽約數(shù)據(jù)，并從簽約數(shù)據(jù)和LCS Client提供的其他數(shù)據(jù)中獲得目標UE的MSISDN或IMSI、LCS Qos等。對于呼叫相關的定位請求，GMLC要獲取并檢驗LCS client的被呼號碼。如果對多個UE進行定位請求，則步驟2-12重復多次。(2) 若GMLC對特定的MSISDN已知其VMSC Server位置和IMSI，則轉(zhuǎn)到；否則發(fā)帶目標UE的IMSI或MSISDN的 MAP_SEND_ROUTING_

49、INFO _FOR_LCS 消息到HLR。 (3) HLR檢驗GMLC的主叫地址，該地址以被授權并能請求UE位置信息，則返回VMSC Server地址以及IMSI或MSISDN（步驟中沒有包括MSISDN）。(4) GMLC發(fā)送MAP_PROVIDE_ SUBSCRIBER _LOCATION消息到相應的VMSC Server，參數(shù)包括申請的位置信息類型、UE用戶的IMSI、LCS QoS信息、以及LCS Client是否具有override能力的指示。對于呼叫相關的定位請求，消息中也包括LCS Client的被叫號碼；對于增值LCS Client可包括Client名稱；對呼叫無關的定位請求，

50、包括LCS Client的識別碼；對其他情況，Client名稱或識別碼可選。(5) 如果GMLC位于其他PLMN或其他國家，則VMSC Server首先驗證是否允許從該PLMN或國家發(fā)起定位請求，如果不允許，返回出錯信息。如果允許， VMSC Server檢驗在VLR中存放的UE用戶的簽約文件中的LCS禁止限制，如果LCS被禁止并且不需通知目標UE，另外接入到同一國家GMLC的LCS Client沒有override能力，則返回出錯信息；其他情況，如UE處于 idle mode，則核心網(wǎng)發(fā)起尋呼、鑒權和加密過程。如目標UE支持UE-based或UE-assisted定位方法，UE將通過 con

51、trolled early classmark sending向SRNC和MSC Server提供其支持的定位方法。(6) 若定位請求來自于增值LCS client，UE簽約文件指明UE要求被通知或者進行帶隱私驗證的通知，而且UE支持LCS驗證（ notification of LCS），則發(fā)送一個 LCS Location Notification Invoke消息到目標UE，指明定位請求類型、LCS Client識別碼、以及是否要求隱私驗證等。(7) 目標UE通知用戶有定位請求。如果具有隱私驗證，目標UE向用戶指示定位請求在沒有響應時是否被允許，并等待用戶決定。然后，UE返回 LCS Lo

52、cation Notification Return Result到 VMSC Server，該消息可在步驟和步驟之間返回。如果在規(guī)定時間內(nèi)沒有返回，VMSC Server認為無響應，并在需求隱私驗證情況下返回出錯消息到GMLC，并指明原因是用戶不允許定位還是沒有響應。 (8) VMSC Server發(fā)送RANAP匯報控制消息到SRNC，本消息包括定位請求類型、UE定位能力和請求的QoS等。(9) SRNC確定定位方法，然后執(zhí)行此方法。(10) 當?shù)玫綕M足QoS要求的定位結(jié)果，SRNC將結(jié)果通過Location Report消息返回VMSC Server。如果未獲得定位結(jié)果，則在 Locati

53、on Report消息中包含失敗原因。(11) 對于未執(zhí)行隱私驗證過程，VMSC Server返回位置信息和估計時間給GMLC。若有隱私驗證，且MSC Server接收到的LCS Location Notification Return Result消息表明定位允許，則只返回位置信息；若 MSC Server接收到的LCS Location Notification Return Result消息表明定位不允許，或者響應超時且在UE簽約文件中規(guī)定無響應時禁止定位，則VMSC Server返回出錯響應到GMLC。如果在執(zhí)行隱私驗證后并允許定位，但SRNC沒有獲得成功定位信息，并且LCS Clie

54、nt請求類型為當前或最后已知位置，VMSC Server具有最后已知位置，則向GMLC返回最后已知位置。如UE原來是Idle狀態(tài)，VLR可釋放與UE的MM連接。VMSC Server可記錄計費信息。(12) GMLC返回UE位置估計給請求的LCS client。在此，GMLC可依要求執(zhí)行坐標轉(zhuǎn)換。GMLC可記錄LCS client和網(wǎng)絡的記帳信息。& 說明：步驟到為定位準備過程，步驟為定位測量建立過程，步驟到為位置計算和釋放過程。6.4.2 移動始發(fā)定位業(yè)務MO-LR 移動始發(fā)定位流程如Error! Reference source not found.所示。圖6-23 移動始發(fā)定位流程(1)

55、 UE發(fā)送LCS MO-LR定位業(yè)務消息到SRNC。(2) SRNC發(fā)送LCS MO-LR定位業(yè)務消息到MSC Server。(3) 對UE用戶的業(yè)務請求鑒權、加密、接入過程。(4) 接入過程完成之后，UE發(fā)起MO-LR定位業(yè)務請求指示。(5) 如果請求其自己的位置或?qū)⑽恢脗魉偷絃CS Client，則該消息中包括LCS請求Qos信息，如需傳送到LCS Client則要包括相應的LCS Client識別碼或GMLC的地址。當GMLC地址沒有包括時，VMSC Server可設置成本網(wǎng)GMLC，并檢查該GMLC是否允許LCS Client連接，否則應拒絕定位申請。如果UE是請求定位輔助數(shù)據(jù)或密鑰，

56、消息要給出輔助數(shù)據(jù)或密鑰類型，以及這些數(shù)據(jù)將應用在那種定位方法上。VMSC Server審核UE簽約文件是否具備請求自己位置，或發(fā)送自己位置到其他 LCS client 或請求定位輔助數(shù)據(jù)以及密鑰。如果UE請求定位且已建立呼叫， VMSC Server可以根據(jù)某些非話音呼叫類型而拒絕該請求。(6) 其它得到定位結(jié)果過程和移動終結(jié)定位過程相同.(7) SRNC向VMSC Server報告定位結(jié)果信息。(8) 向GMLC報告位置信息。(9) GMLC回響應表示是否得到正確的位置信息。(10) GMLC把定位結(jié)果信息發(fā)送給UE用戶要求的LCS客戶。(11) 最后向UE用戶回定位請求響應（包含定位結(jié)果

57、信息）。(12) 釋放連接。6.4.3 網(wǎng)絡發(fā)起的定位業(yè)務NI-LR網(wǎng)絡發(fā)起的定位業(yè)務流程如Error! Reference source not found.所示。圖6-24 網(wǎng)絡發(fā)起的定位業(yè)務流程(1) UE在空閑狀態(tài)下發(fā)起RRC建立請求，以進行緊急呼叫。(2) SRNC通過Iu接口轉(zhuǎn)發(fā)CM業(yè)務請求。UE的識別可采用TMSI、IMSI或IMEI。(3) 進行緊急呼叫流程。(4) 根據(jù)當?shù)毓芾硪?，可能此時（緊急呼叫建立時）需要發(fā)起定位請求過程，則向SRNC發(fā)起定位請求控制過程。同時，VMSC Server、SRNC和UE繼續(xù)緊急呼叫流程。(5) 得到定位結(jié)果過程和移動終結(jié)定位過程相同。(6) SRNC向VMSC Server報告定位結(jié)果信息。(7) VMSC Server向GMLC報告位置信息。(8) GMLC回響應表示是否得到正確的位置