一、概述 二、初始注冊 三、后續(xù)注冊---重注冊 四、后續(xù)注冊---二次注冊 五、第三方注冊 5.1 S-CSCF與SCC AS的第三方注冊 5.2 S-CSCF與VoLTE AS的第三方注冊 5.3 S-CSCF與IP-SM-GW的第三方注冊 六、訂閱 七、常見初始注冊失敗 7.1 蘋果6s手機(jī)初始注冊失敗 7.2 三星S6手機(jī)初始注冊失敗 7.3 步步高VIVO X6D手機(jī)初始注冊失敗 7.4 金立GN9010手機(jī)初始注冊失敗
用戶開通了VoLTE簽約，并在VoLTE終端上打開“VoLTE”、“ims服務(wù)”或“HD高清語音”開關(guān)，在開機(jī)附著成功后，UE單獨(dú)發(fā)起APN=ims的PDN連接性請求，并成功建立QCI=5的ims信令默認(rèn)承載，接著UE發(fā)起注冊請求。 注冊流程拆分成初始注冊/后續(xù)注冊（重注冊）、后續(xù)注冊（二次注冊）、第三方注冊、訂閱共四個(gè)階段，其中后續(xù)注冊和初始注冊的區(qū)別在于注冊消息中增加了用戶認(rèn)證數(shù)據(jù)和接入網(wǎng)絡(luò)位置信息。成功的初始注冊必須經(jīng)過初始注冊、二次注冊、第三方注冊、訂閱階段，而成功的重注冊必須經(jīng)過重注冊、二次注冊、第三方注冊階段。 初始注冊、重注冊和二次注冊過程稱為基本注冊，基本注冊由用戶終端發(fā)起，基本注冊成功后，用戶就擁有了基本呼叫權(quán)限。第三方注冊由S-CSCF代替用戶終端發(fā)起，第三方注冊成功后，用戶就擁有了AS提供的相關(guān)業(yè)務(wù)權(quán)限?；咀?、第三方注冊示意圖如下：
▲本圖中1~4為初始注冊，5為二次注冊，6為第三方注冊 更加詳細(xì)的流程見下圖（融合HSS組網(wǎng)）：
1~12步驟為初始注冊，其中8~9步驟可以選擇性進(jìn)行（視S-CSCF本地剩余IMS認(rèn)證數(shù)據(jù)情況）； 13~24步驟為二次注冊，20~21步驟可以選擇性進(jìn)行（視S-CSCF本地有無用戶數(shù)據(jù)及iFC集合數(shù)據(jù)）； 25~26為S-CSCF向AS（應(yīng)用服務(wù)器）請求的第三方注冊，根據(jù)iFC準(zhǔn)則，涉及的應(yīng)用服務(wù)器為SCC AS、VoLTE AS、IP-SM-GW等，該過程步驟較多，此圖為示意圖。 從附著開始的IMS注冊過程中涉及了絕大多數(shù)協(xié)議：RRC、NAS、S1AP、SGsAP、GTP-C V2、GTP-U V1協(xié)議、SIP協(xié)議、Diameter協(xié)議等，作為選項(xiàng)還有MAP、CAP。 由于SIP消息與VoLTE優(yōu)化分析緊密結(jié)合，在此簡略介紹SIP協(xié)議：
作為VoLTE優(yōu)化工程師，一定要了解上述知識(shí)點(diǎn)，然后在工作中進(jìn)行驗(yàn)證性測試。日常工作中常用的方式就是采用測試手機(jī)和測試軟件相結(jié)合的方式進(jìn)行，比如采用HTC M8t手機(jī)和CDS測試軟件，在Uu接口上的信令消息截圖如下：
初始注冊事件發(fā)生的場景： 開機(jī)附著于LTE網(wǎng)絡(luò)，并完成建立IMS默認(rèn)承載之后； 從23G網(wǎng)絡(luò)重選上（或返回）LTE網(wǎng)絡(luò)，并完成TAU之后； IMS注銷之后，再次啟用IMS功能； 在重注冊失敗之后再次發(fā)起的注冊； 手機(jī)認(rèn)為必須經(jīng)過初始注冊流程（不兼容401認(rèn)證挑戰(zhàn)消息或終端BUG問題導(dǎo)致） 作為注冊消息的發(fā)起方---用戶終端，UE根據(jù)USIM信息，推導(dǎo)得出注冊用的私有身份標(biāo)識(shí)IMPI和臨時(shí)IMS公用身份標(biāo)識(shí)IMPU（即T-IMPU，為SIP格式，僅作注冊之用，不能用作呼叫）：
其中私有身份標(biāo)識(shí)是歸屬網(wǎng)絡(luò)運(yùn)營商提供的用戶唯一全球標(biāo)識(shí)，類似IMSI，用于對IMS用戶進(jìn)行鑒權(quán)認(rèn)證，該標(biāo)識(shí)對用戶不可見，簡明初始注冊示意圖如下：
初始注冊的過程在信令平臺(tái)的抓包如下：
空口中的register消息通過邏輯上的Gm口直到P-CSCF，該過程是通過該消息中Route頭域的P-CSCF地址來實(shí)現(xiàn)的，該地址被用來作為Request消息的路由。 關(guān)于Route頭域含義如下：當(dāng)一個(gè)Proxy Server收到一個(gè)Request消息時(shí)，會(huì)檢查Route字段的第一個(gè)地址是否等于自己，如果是，它可以從Route字段中刪去自己的地址信息，然后疊加下一段地址，并將消息轉(zhuǎn)發(fā)到Route字段中指定的下個(gè)地址；如果Route字段為空，則轉(zhuǎn)發(fā)到Request URI指定的地址。如果沒有就根據(jù)Contact頭域發(fā)送，如果連Contact都沒有，就根據(jù)From頭域發(fā)送。 關(guān)于Via頭域含義如下：當(dāng)發(fā)起一個(gè)SIP Request消息時(shí)，消息經(jīng)過的每一跳（包含發(fā)起方）都會(huì)在SIP消息中增加一個(gè)Via字段，內(nèi)容為自己的地址信息，表示通過此地址發(fā)往下一跳，為什么要增加Via字段來記錄Request消息經(jīng)過的地址呢？用以保存請求歷經(jīng)的路徑，實(shí)際上這個(gè)地址信息將被作為Request消息的Response消息的路由，Response消息逐段設(shè)置Via頭域地址，實(shí)現(xiàn)逐級(jí)返回，直到回到Request的發(fā)起方，因此Via頭域是一種給響應(yīng)消息返回留路徑的方式，是響應(yīng)消息的本路由段的目的地址。 另外Record-Route頭域?yàn)槟骋欢温酚傻哪康牡?、源頭傳遞信息（構(gòu)建路由集），從而發(fā)送消息時(shí)可構(gòu)建Route頭域。Path頭域?yàn)樽詴r(shí)才特有的，用于S-CSCF設(shè)置用戶的P-CSCF，作為反向請求直通路由至P-CSCF網(wǎng)元。Contact頭域?yàn)閁E的IPV6地址和端口號(hào)。 初始注冊詳述如下文： UE發(fā)起初始注冊時(shí)，Register消息中Authorization頭域中相關(guān)認(rèn)證授權(quán)信息為空（比如隨機(jī)數(shù)為空、認(rèn)證響應(yīng)為空、無完整性保護(hù)），如下圖：
經(jīng)Gm接口，P-CSCF收到Register消息后： 刪除Proxy-Require頭域，將Security-Client頭域保存到本地，調(diào)整Require頭域?yàn)閜ath，并在Authorization頭域中添加“integrity-protected=no”標(biāo)簽，表示初始注冊消息未受保護(hù)，增加以下頭域： 增加P-Access-Network-Info頭域?yàn)榻尤胛恢冒W(wǎng)絡(luò)類型、SBC域名、UE IPV6地址和端口號(hào)共四項(xiàng)，。
增加Path頭域?yàn)楸綪-CSCF地址（也即P-CSCF的主機(jī)名），而在I-CSCF轉(zhuǎn)發(fā)Register請求給S-CSCF時(shí)同樣要插入P-CSCF地址的path頭域，S-CSCF通過Path字段保存一個(gè)UE所使用的P-CSCF地址，這樣當(dāng)S-CSCF需要主動(dòng)向UE發(fā)送消息時(shí)（例如網(wǎng)絡(luò)端發(fā)起的De-register），S-CSCF就知道實(shí)際應(yīng)該發(fā)往的P-CSCF地址了，這是一種直達(dá)路由消息。 增加P-Visited-Network-ID頭域?yàn)镻-CSCF的域名（也即P-CSCF的本地網(wǎng)絡(luò)標(biāo)識(shí)）。 增加P-Charging-Vector頭域?yàn)镻-CSCF收到注冊消息后產(chǎn)生的ICID計(jì)費(fèi)標(biāo)識(shí)。 增加Feature-Caps頭域包含STN-SR號(hào)碼。 P-CSCF向I-CSCF進(jìn)行進(jìn)一步轉(zhuǎn)發(fā)Register消息，為了獲得入口I-CSCF網(wǎng)元IP地址，P-CSCF根據(jù)請求行中的Request-URI域名向DNS服務(wù)器發(fā)起查詢，由于目前UE基本注冊時(shí)的Request-URI字段統(tǒng)一設(shè)置為只有運(yùn)營商信息而不帶省份信息的域名sip:ims.mnc000.mcc460.3gppnetwork.org，鑒于P-CSCF只有DNS查詢而沒有被叫號(hào)碼分析功能，故查詢結(jié)果不能定位出是哪個(gè)省的用戶，也就不能路由到歸屬網(wǎng)絡(luò)的I-CSCF，結(jié)果只能為拜訪網(wǎng)絡(luò)的I-CSCF功能實(shí)體的IP地址（而在呼叫流程中，由于S-CSCF和MGCF具備被叫號(hào)碼分析功能和查詢ENUM/DNS功能，可得知IMS被叫用戶的歸屬網(wǎng)絡(luò)入口I-CSCF地址）。 作為拜訪網(wǎng)絡(luò)的I-CSCF為了判斷該用戶是否具備漫游的權(quán)限，根據(jù)From頭域中的T-IMPU標(biāo)識(shí)和拜訪網(wǎng)絡(luò)標(biāo)識(shí)P-Visited-Network-ID頭域，通過Cx接口向歸屬HSS發(fā)起USER-AUTHORIZATION-REQUEST查詢消息（該消息用于注冊流程，與呼叫流程中LIR不同），Diameter協(xié)議類型為注冊，根據(jù)信令網(wǎng)架構(gòu)，中間必須經(jīng)過LDRA或HDRA網(wǎng)元，DRA基于IMSI/主機(jī)名路由至歸屬HSS。HSS將該UAR相關(guān)頭域內(nèi)容與用戶開戶數(shù)據(jù)中漫游模板內(nèi)容進(jìn)行比對，若匹配，則回復(fù)給I-CSCF網(wǎng)元UAA消息，包含下面內(nèi)容。 由于HSS不存在該用戶的P-CSCF Network ID或S-CSCF名稱信息，故HSS判斷該用戶為first register（初始注冊），設(shè)置相關(guān)AVP屬性值對---實(shí)驗(yàn)性結(jié)果代碼為2001（DIAMETER_FIRST_REGISTRATION），下發(fā)S-CSCF服務(wù)器能力集（分為強(qiáng)制能力和可選能力），I-CSCF收到UAA消息后，根據(jù)其中的S-CSCF的能力集進(jìn)行某種選擇算法，選擇一個(gè)合適的S-CSCF。 在拜訪網(wǎng)絡(luò)的I-CSCF選定某個(gè)歸屬S-CSCF后， I-CSCF轉(zhuǎn)發(fā)Register消息至歸屬網(wǎng)絡(luò)S-CSCF，該消息的Request-URI頭域?yàn)镾-CSCF域名。 S-CSCF收到無認(rèn)證數(shù)據(jù)的初始注冊消息后，通過Cx接口發(fā)送MULTIMEDIA-AUTH-REQUEST消息給HSS，請求認(rèn)證向量集，同時(shí)也指示HSS實(shí)體：本S-CSCF即為該用戶歸屬服務(wù)器，MAR和MAA字面上為多媒體認(rèn)證請求和多媒體認(rèn)證回應(yīng)，實(shí)為提供IMS認(rèn)證向量消息，認(rèn)證算法指定為Digest-AKAv1-MD5（消息摘要算法5），認(rèn)證過程與EPC認(rèn)證流程相類似，也是雙向認(rèn)證，但認(rèn)證過程采用了五元組：XRES/RAND/AUTH/IK/CK，而非四元組，涉及S-CSCF、P-CSCF、UE三個(gè)實(shí)體。 在HSS的成功響應(yīng)消息中屬性值對---SIP-Auth-Data-Item，包含5套完整的認(rèn)證數(shù)據(jù)（S-CSCF對用戶認(rèn)證時(shí)任選一套即可，有點(diǎn)類似于EPS附著時(shí)MME對用戶認(rèn)證，總的來說不同類型的原始認(rèn)證數(shù)據(jù)均出自于HSS，而根據(jù)具體認(rèn)證內(nèi)容不同，涉及不同實(shí)體，關(guān)于附著認(rèn)證見EPS認(rèn)證和NAS解碼方面文檔）。 S-CSCF截留某一套的XRES后，將這套剩余認(rèn)證數(shù)據(jù)包括Digest認(rèn)證方式算法、隨機(jī)數(shù)RAND/認(rèn)證令牌AUTH（RAND/AUTH合成“nonce”）、完整性保護(hù)密鑰IK、加密密鑰CK打包在register401消息（即鑒權(quán)認(rèn)證挑戰(zhàn)）里并傳遞至I-CSCF，繼而I-CSCF將401消息傳遞給P-CSCF：
P-CSCF截留CK/IK后，將剩余的鑒權(quán)認(rèn)證元素RAND/AUTH（”Nonce”）、認(rèn)證算法通過401消息傳遞給UE，以上IMS認(rèn)證的五元組傳遞如下圖：
關(guān)于認(rèn)證過程描述見本文的二次注冊章節(jié)。
初始注冊成功后，用戶的簽約網(wǎng)絡(luò)會(huì)登記用戶的注冊時(shí)長T1。當(dāng)用戶的已注冊時(shí)長接近T1時(shí)，一般為50分鐘，UE需要向網(wǎng)絡(luò)側(cè)發(fā)起新的注冊請求，即重注冊。 重注冊的流程與初始注冊過程相似，對于UE手機(jī)和S-CSCF這兩個(gè)實(shí)體來說判斷重注冊與初始注冊的依據(jù)在于是否攜帶上次成功IMS認(rèn)證的數(shù)據(jù): AUTH/RAND/RES/IK/CK等，以及攜帶接入網(wǎng)絡(luò)位置信息。 P-CSCF通過完整性驗(yàn)證和解密后，在轉(zhuǎn)發(fā)注冊消息之前，和初始注冊時(shí)的頭域處理相類似，但有所改變，其中：Authorization頭域內(nèi)容調(diào)整“integrity-protected=yes”標(biāo)簽，表示注冊消息受保護(hù)；P-Access-Network-Info頭域內(nèi)容新增小區(qū)ID構(gòu)成五項(xiàng)。 P-CSCF依然以明文形式轉(zhuǎn)發(fā)register消息給I-CSCF。 值得注意的是：重注冊時(shí)Call-ID必須維持不變（IPV6地址也不變），之后由于現(xiàn)網(wǎng)S-CSCF設(shè)置為每次重注冊都認(rèn)證（重注冊時(shí)，S-CSCF對用戶進(jìn)行鑒權(quán)認(rèn)證是可選流程），那么同樣會(huì)生成401認(rèn)證挑戰(zhàn)，與初始注冊一樣也要經(jīng)歷IMS認(rèn)證過程。 而對于HSS實(shí)體來說，則依據(jù)數(shù)據(jù)庫是否存在該用戶的P-CSCF Network ID或S-CSCF名稱來判斷初始注冊或后續(xù)注冊，若不存在任一條件，則判斷為初始注冊，回復(fù)給I-CSCF則為S-CSCF能力集；若存在P-CSCF Network ID則判斷為后續(xù)注冊，回復(fù)給I-CSCF為S-CSCF能力集；若存在S-CSCF名稱則判斷為后續(xù)注冊，且回復(fù)給I-CSCF為S-CSCF名稱。 經(jīng)過I-CSCF與HSS的授權(quán)信息交互后，HSS判斷出用戶為后續(xù)注冊---DIAMETER_SUBSEQUENT_REGISTRATION (2002)，并給定S-CSCF名稱（而不是能力集），S-CSCF名稱經(jīng)DNS翻譯后，I-CSCF傳遞register消息至S-CSCF。 S-CSCF依據(jù)Register消息中授權(quán)認(rèn)證頭域的信息為該用戶的上次成功認(rèn)證信息，判斷本次注冊為重注冊。重注冊若設(shè)置為需要認(rèn)證時(shí)，可根據(jù)IMS認(rèn)證數(shù)據(jù)（初始注冊時(shí)下載了5套五元組）在S-CSCF的剩余情況來決定是否需要MAR和MAA的流程，否則可直接取用本地保存的未曾使用過的認(rèn)證數(shù)據(jù)。因此對于S-CSCF和HSS來說這是一個(gè)選擇性認(rèn)證過程，有利于縮短時(shí)延及降低S-CSCF與HSS之間的信令負(fù)荷，最終S-CSCF發(fā)送401鑒權(quán)認(rèn)證挑戰(zhàn)消息給I-CSCF，由I-CSCF傳遞給P-CSCF，之后通過Gm接口下發(fā)至UE。
后續(xù)注冊中的二次注冊指的是UE收到S-CSCF的401鑒權(quán)認(rèn)證挑戰(zhàn)消息之后，手機(jī)發(fā)起的第二次注冊過程，手機(jī)首先對網(wǎng)絡(luò)進(jìn)行認(rèn)證：根據(jù)算法、隨機(jī)數(shù)和USIM卡中的共享密鑰，對AUTH進(jìn)行驗(yàn)證以判斷網(wǎng)絡(luò)是否合法。 在驗(yàn)證通過后（XMAC與MAC一致，SQN在合理范圍內(nèi)），再基于共享密鑰、RAND和算法計(jì)算出RES/CK/IK，并通過Gm口將digest摘要認(rèn)證數(shù)據(jù)發(fā)送給P-CSCF網(wǎng)元：
簡明二次注冊示意圖如下：
9-12步驟是認(rèn)證成功所必須的，13步驟是為了進(jìn)一步觸發(fā)第三方注冊。 UE發(fā)起二次注冊，其中Call-ID頭域標(biāo)識(shí)保持不變，而From頭域tag標(biāo)識(shí)可變、Cseq頭域可變，并將生成的RES響應(yīng)值以及原始的RAND/AUTH通過加密通道發(fā)給P-CSCF，另外還攜帶接入網(wǎng)絡(luò)位置信息。 P-CSCF通過完整性驗(yàn)證和解密后，在轉(zhuǎn)發(fā)注冊消息之前，和初始注冊時(shí)的頭域處理相類似，但有所改變，其中：Authorization頭域內(nèi)容調(diào)整“integrity-protected=yes”標(biāo)簽，表示注冊消息受保護(hù)；P-Access-Network-Info頭域內(nèi)容新增小區(qū)ID構(gòu)成五項(xiàng)。 P-CSCF依然以明文形式轉(zhuǎn)發(fā)register消息給I-CSCF。 后續(xù)注冊的過程在信令平臺(tái)的抓包如下：
I-CSCF發(fā)送用戶授權(quán)請求UAR消息給HSS，HSS判斷出用戶為后續(xù)注冊---DIAMETER_SUBSEQUENT_REGISTRATION (2002)，將之前記錄的S-CSCF的地址信息（注意是S-CSCF名稱而不是能力集）通過UAA消息發(fā)送給I-CSCF，S-CSCF名稱經(jīng)DNS翻譯后，I-CSCF轉(zhuǎn)發(fā)Register消息至S-CSCF。 由S-CSCF比對RES響應(yīng)值與XRES期望響應(yīng)值，兩者匹配，則該用戶通過網(wǎng)絡(luò)鑒權(quán)。接下來是為觸發(fā)第三方注冊而進(jìn)行的流程，初始注冊觸發(fā)的二次注冊流程中一定存在取用戶數(shù)據(jù)流程，而重注冊觸發(fā)的二次注冊流程可根據(jù)該用戶數(shù)據(jù)在S-CSCF的預(yù)留情況，可選擇性進(jìn)行取用戶數(shù)據(jù)流程，這有利于縮短時(shí)延和降低Cx接口信令負(fù)荷，取用戶數(shù)據(jù)通過服務(wù)器分配請求SAR（Server Assignment Request）和SAA服務(wù)器分配回應(yīng)兩個(gè)過程來完成，下文假設(shè)為存在取用戶數(shù)據(jù)情況： S-CSCF發(fā)送消息SAR（類型為注冊）至HSS，由于相關(guān)用戶簽約和第三方認(rèn)證數(shù)據(jù)等是空的，HSS響應(yīng)S-CSCF的SAA消息，該消息包含了用戶簽約數(shù)據(jù)、兩套iFC（初始過濾準(zhǔn)則，用于觸發(fā)AS進(jìn)行第三方注冊以及后續(xù)業(yè)務(wù)AS邏輯順序）、計(jì)費(fèi)信息域名等。 S-CSCF原路返回或內(nèi)部傳遞SIP---INVITE 200 OK消息至I-CSCF，傳遞至P-CSCF，最終到達(dá)UE，確認(rèn)注冊成功，包含頭域敘述如下： P-Associated-URI頭域中包含了兩個(gè)IMS公用身份標(biāo)識(shí)(IMPU)，分別采用Tel URI和SIP URI格式，其中SIP URI格式包含該用戶歸屬省份信息，比如下述號(hào)碼為浙江移動(dòng)號(hào)碼：
Tel URI用于后續(xù)的語音呼叫，而SIP URI用于IMS網(wǎng)絡(luò)路由。 Contact頭域?yàn)樽猿晒τ脩舻腎MSI、IPV6地址和端口號(hào)、重注冊時(shí)長、終端支持業(yè)務(wù)類型等，截圖如下：
Service-Route頭域包含有該用戶歸屬的S-CSCF名稱，由S-CSCF向I-CSCF發(fā)送，繼而由I-CSCF傳遞給向P-CSCF，如下圖所示注冊成功消息中所示：
由P-CSCF保存Service-Route頭域內(nèi)容：歸屬S-CSCF名稱，這樣UE成功注冊之后的其它SIP消息（非注冊類，例如呼叫INVITE）抵達(dá)P-CSCF后，在轉(zhuǎn)往下一跳時(shí)，直接在Route字段放置該用戶的S-CSCF名稱，經(jīng)DNS翻譯后，可實(shí)現(xiàn)SIP消息無需再經(jīng)過I-CSCF實(shí)體就可直達(dá)該用戶的歸屬S-CSCF。也就是說在用戶IMS注冊成功后，用戶的非注冊類的SIP消息，即可經(jīng)Gm接口、Mw接口至歸屬網(wǎng)絡(luò)的S-CSCF，由S-CSCF進(jìn)行下一步邏輯處理。 Path頭域包含S-CSCF已登記的IPV4的P-CSCF地址，經(jīng)P-CSCF實(shí)體變換為IPV6的P-CSCF地址傳遞給UE，作為Gm接口的端地址。 Accept-Resource-Priority頭域包含用戶簽約的優(yōu)先級(jí)，比如wps.4。 可選項(xiàng)---Authentication-Info頭域，攜帶下一次重注冊的隨機(jī)項(xiàng)nonce。 下表為注冊前、中、后三個(gè)狀態(tài)的各相關(guān)網(wǎng)元必須要記錄的地址、域名、安全數(shù)據(jù)或用戶數(shù)據(jù)：
在基本注冊成功之后，歸屬S-CSCF代替用戶發(fā)起第三方注冊，第三方注冊過程僅在IMS核心網(wǎng)出現(xiàn)，Uu口無此信息，REGISTER消息中的Contact頭域包含該用戶歸屬S-CSCF的地址，以保證應(yīng)用服務(wù)器AS不會(huì)直接路由到用戶終端UE，而是總會(huì)先與S-CSCF聯(lián)絡(luò)。 S-CSCF網(wǎng)元檢查所下載的該用戶的初始過濾準(zhǔn)則iFC，并觸發(fā)去往為該用戶服務(wù)的相關(guān)網(wǎng)元的路由，通告相關(guān)網(wǎng)元該用戶已經(jīng)注冊且可到達(dá)，同時(shí)更新必要的網(wǎng)元數(shù)據(jù)，主要涉及S-CSCF與HSS/SCC-AS/VoLTE-AS/IP-SM-GW交互，涉及SIP協(xié)議的ISC接口、Diameter協(xié)議的Sh接口。 不同AS的第三方注冊消息構(gòu)造有如下特征： Request-Line內(nèi)容為具體第三方應(yīng)用服務(wù)器的名稱，比如SCC AS、VoLTE AS、IP-SM-GW； From頭域除了標(biāo)簽不一樣其余相同，其中主要內(nèi)容為S-CSCF名稱，代替了用戶的公有標(biāo)識(shí)IMPU，這是第三方注冊的由來； Via頭域除了分支不一樣其余相同； Call-ID頭域都是相互獨(dú)立的標(biāo)識(shí)，也與之前的基本注冊Call-ID不相關(guān)； To、Contact、P-Charging-Vector、P-Access-Network-Info、P-Visited-Network-ID頭域內(nèi)容均相同，To頭域?yàn)橛脩舻腟IP格式的公有標(biāo)識(shí)IMPU； 消息體（Message Body）內(nèi)容完全是一樣的，均為二次注冊內(nèi)容，該消息體是由I-CSCF傳遞到S-CSCF的，包含內(nèi)容有Request-Line、Message Header、I-CSCF IP地址的Via頭域、基本注冊Call-ID頭域、From/To頭域、成功認(rèn)證向量的Authorization頭域、Contact頭域、Path頭域、P-Visited-Network-ID頭域、P-Access-Network-Info頭域、P-Charging-Vector頭域、ATCF/STN-SR內(nèi)容的Feature-Caps頭域等。 鑒于第三方注冊可由初始注冊觸發(fā)，也可由重注冊觸發(fā)，主要環(huán)節(jié)是相同的。但由于初始注冊情況下，AS和IP短信網(wǎng)關(guān)并沒有該用戶的注冊信息，相關(guān)網(wǎng)元必須從HSS獲取該用戶的數(shù)據(jù)，相應(yīng)過程和時(shí)間會(huì)稍長；而重注冊情況下的第三方注冊相對來說簡潔明了且時(shí)間較短，下文假定為初始注冊情況下的第三方注冊。 REGISTER消息經(jīng)S-CSCF發(fā)送給AS后，AS發(fā)現(xiàn)并不存在該用戶的數(shù)據(jù)，因此判斷為初始注冊情況下的第三方注冊，發(fā)送UDR消息給融合HLR/HSS，請求獲取用戶數(shù)據(jù)（包括用戶身份數(shù)據(jù)、業(yè)務(wù)簽約數(shù)據(jù)等），HSS返回UDA響應(yīng)，攜帶用戶數(shù)據(jù)。AS根據(jù)收到的用戶數(shù)據(jù)對用戶進(jìn)行鑒權(quán)認(rèn)證，通過之后，AS將用戶數(shù)據(jù)保存到本地?cái)?shù)據(jù)庫，并繼續(xù)下一步流程，最后向S-CSCF返回第三方注冊的200OK的成功響應(yīng)。根據(jù)涉及的第三方注冊網(wǎng)元不同，分為三步：
這個(gè)步驟的第三方注冊目的是為了后續(xù)被叫接入域選和eSRVCC作準(zhǔn)備。 以類似sip:+8613958052120@zj.ims.mnc000.mcc460.3gppnetwork.org的公有標(biāo)識(shí)，向HSS請求用戶數(shù)據(jù)包括：MSISDN、IMSI、IMPI、IMPU（tel和sip兩種格式）、STN-SR（開戶數(shù)據(jù)，將被ATCF的地址所代替）、UE-SRVCC-Capability、Service-Indication等。 流程圖如下：
流程分為：用戶數(shù)據(jù)查詢UDR/UDA、訂閱通知SNR/SNA（向HSS訂閱用戶數(shù)據(jù)變化通知，若終端通過Ut/CS或業(yè)務(wù)發(fā)放系統(tǒng)引起補(bǔ)充業(yè)務(wù)有變化時(shí)HSS則通知AS）、SCC AS與ATCF的MESSAGE過程、檔案數(shù)據(jù)更新PUR、用戶數(shù)據(jù)插入ISD。 涉及STN-SR描述如下： STN-SR是ATCF的地址，UE在IMS網(wǎng)絡(luò)注冊時(shí)，ATCF根據(jù)終端能力和會(huì)話需要，為其分配STN-SR號(hào)碼，將ATCF置于信令路由中，以便該終端的注冊和呼叫相關(guān)消息都經(jīng)ATCF。在基本注冊時(shí)由SBC帶給S-CSCF，之后由S-CSCF帶給SCC AS，SCC AS同時(shí)從HSS處獲得HSS登記的STN-SR號(hào)碼，SCC AS比較從HSS和S-CSCF兩處獲得的STN-SR異同，若不相同則用S-CSCF處的數(shù)據(jù)通過PUR消息去更新HSS，并由SCC AS 通過HSS向MME下發(fā)用戶數(shù)據(jù)，其中包含STN-SR號(hào)碼以用于eSRVCC。 涉及ATU-STI、C-MSISDN描述如下： ATU-STI是SCC AS域名，由SCC AS配置而來，作為eSRVCC切換上來之后，ATCF路由至SCC AS之用；而C-MSISDN是由HSS分配的，是用戶數(shù)據(jù)的一部分。ATU-STI、C-MSISDN由SCC AS通過MESSAGE消息傳給ATCF，總體作用是ATCF將eSRVCC切換上來的用戶（INVITE消息中From頭域?yàn)橛脩魳?biāo)識(shí)，to頭域?yàn)锳TCF地址）進(jìn)行關(guān)聯(lián)計(jì)費(fèi)，而實(shí)現(xiàn)eSRVCC切換產(chǎn)生話單。 eMSC與ATCF交互的SIP消息（比如INVITE/200OK/ACK等）經(jīng)由I2接口，eMSC 與MME交互的GTP-C V2消息（比如SRVCC PStoCS請求/響應(yīng)/完成通告/完成確認(rèn)等）經(jīng)由Sv接口。 幾個(gè)關(guān)鍵參數(shù)的分配及傳遞如下表：
在S-CSCF與SCC-AS注冊完成后，會(huì)接著進(jìn)行VoLTE-AS注冊，VoLTE是處理呼叫業(yè)務(wù)的核心網(wǎng)元，包含基本業(yè)務(wù)、補(bǔ)充業(yè)務(wù)等，因此數(shù)據(jù)量較大。 以類似sip:+8613958052120@zj.ims.mnc000.mcc460.3gppnetwork.org的公有標(biāo)識(shí)，向HSS請求用戶數(shù)據(jù)包括： IMPI、IMPU（tel和sip兩種格式）、Service-Indication、IMS-CAMEL-Services等。 第三方注冊過程中會(huì)有多次UDR/UDA消息交互，此外還有檔案數(shù)據(jù)更新PUR/PUA、請求訂閱用戶數(shù)據(jù)SNR/SNA（向HSS訂閱用戶數(shù)據(jù)變化通知，若終端通過Ut/CS或業(yè)務(wù)發(fā)放系統(tǒng)引起補(bǔ)充業(yè)務(wù)有變化時(shí)HSS則通知AS）、用戶數(shù)據(jù)插入ISD過程。
完成S-CSCF與VoLTE AS的第三方注冊之后，根據(jù)iFC準(zhǔn)則，最后就是S-CSCF與IP-SM-GW的第三方注冊，目的是為了之后VoLTE用戶的收發(fā)短信都經(jīng)過該網(wǎng)元，實(shí)現(xiàn)IMS域與CS域間短消息互通的功能（涉及SIP協(xié)議與MAP協(xié)議轉(zhuǎn)換）。 由于IP短信網(wǎng)關(guān)地址并不在HSS簽約數(shù)據(jù)中，因此該節(jié)點(diǎn)與HSS之間需要數(shù)據(jù)更新過程，通過PUR/PUA過程來實(shí)現(xiàn)，用戶數(shù)據(jù)更新完成后，HSS才能為接受短信提供路由信息，也即IP-SM-GW的IP地址。 至此初始注冊情況下的第三方注冊成功完成，時(shí)長為400ms以內(nèi)，也即完成了整個(gè)IMS注冊，接下來是訂閱過程。 順便闡述一下重注冊情況下的第三方注冊，現(xiàn)網(wǎng)截圖如下：
由于SCC AS和VoLTE AS、IP-SM-GW存在該用戶數(shù)據(jù)，因此重注冊情況下的第三方注冊并不需要與HSS進(jìn)行交互，流程相對簡潔，時(shí)長在100ms以內(nèi)。
該過程由UE發(fā)起，并終止于UE，在Uu可觀察到相關(guān)消息。 SUBSCRIBE方法用于發(fā)起訂閱請求，NOTIFY方法用于通告當(dāng)前資源狀態(tài)，當(dāng)那些被訂閱的資源的狀態(tài)發(fā)生改變時(shí)，負(fù)責(zé)這一資源的網(wǎng)絡(luò)實(shí)體將向訂閱者發(fā)送通告，通報(bào)當(dāng)前資源狀態(tài)的變化情況，這是事件通告機(jī)制，以上都為單向行為，涉及以下幾個(gè)概念： (1)訂閱者---UE 訂閱者向通告者發(fā)送SUBSCRIBE消息以請求創(chuàng)建一次訂閱關(guān)系。訂閱者負(fù)責(zé)接收NOTIFY消息，這些NOTIFY消息中包含訂閱者所訂閱的資源信息。 (2)通告者---S-CSCF 通告者接收SUBSCRIBE消息，判斷P-Asserted-Identify頭域攜帶的用戶標(biāo)識(shí)已在S-CSCF上注冊，返回200(OK)響應(yīng)，指示訂閱成功。通告者負(fù)責(zé)產(chǎn)生NOTIFY消息，向訂閱者回饋當(dāng)前資源的狀態(tài)。 UE是訂閱者，訂閱由UE發(fā)起，涉及SBC、S-CSCF及HSS網(wǎng)元；而S-CSCF是通告者，通告是由HSS觸發(fā)、S-CSCF發(fā)起的。 通告者在成功創(chuàng)建訂閱關(guān)系后，必須立即發(fā)送NOTIFY消息，向訂閱者通告當(dāng)前訂閱資源的狀態(tài)。通告內(nèi)容也即消息體以xml格式予以表達(dá)，NOTIFY消息中必須包含擴(kuò)展的 Subscription-State頭域，指示創(chuàng)建的訂閱的狀態(tài)及剩余注冊時(shí)間。共有3種訂閱狀態(tài)，分別是： (1)active：訂閱已被接受且授權(quán)成功。 (2)pending：SUBSCRIBE請求已收到，但還沒有足夠的信息決定接受或拒絕此次訂閱。 (3)terminated：訂閱未激活或創(chuàng)建的訂閱關(guān)系終止。 對應(yīng)active狀態(tài)或pending狀態(tài)，該頭部還帶有expires參數(shù)指示此次訂閱的有效時(shí)長。對應(yīng)terminated狀態(tài)，該頭部應(yīng)包含reason參數(shù)指示訂閱被終止的原因，或者包含Retry-After參數(shù)，指示訂閱者過一段時(shí)間后重新發(fā)起訂閱請求。 對于訂閱已被接受且授權(quán)成功的notify截圖如下：
信令平臺(tái)抓包如下：
由于平臺(tái)原因，上述抓包中涉及HSS的幾個(gè)Diameter消息，予以補(bǔ)充如下： PNR（Push Notification Request）消息由命令碼309和設(shè)置命令標(biāo)志“R”表示，當(dāng)AS通過SNR（Subscribe Notifications Request）消息向HSS訂閱的數(shù)據(jù)被更新后，HSS通過PNR消息將更新后的數(shù)據(jù)發(fā)送給AS。 注意：訂閱和通告是同一個(gè)Call-ID，并且通告行為可延伸到23G網(wǎng)絡(luò)，也即通告消息可通過S-CSCF、SBC、GGSN傳至SGSN，之后通過Gb接口或IU-PS接口到達(dá)用戶手機(jī)，這種現(xiàn)象發(fā)生在當(dāng)UE重定向、盲重定向至23G網(wǎng)絡(luò)且在RAU完成之后，用戶發(fā)出register注銷消息SIP數(shù)據(jù)包（Expires: 0）。隨后網(wǎng)絡(luò)側(cè)會(huì)下發(fā)NOTIFY通告消息，告訴目前用戶IMS資源已改變（no resource），UE回復(fù)通告200OK消息，其中P-Access-Network-Info頭域上報(bào)UE所在網(wǎng)絡(luò)類型及小區(qū)標(biāo)識(shí)CGI（MCC+MNC+LAC+CI）或ECGI（MCC+MNC+TAC+CI）。
IMS注冊失敗與手機(jī)終端、IMS核心網(wǎng)設(shè)備是息息相關(guān)的，找出影響注冊成功率的終端型號(hào)和核心網(wǎng)元，并進(jìn)一步推動(dòng)解決問題。本章節(jié)僅以注冊成功率較低且請求數(shù)較高的幾款型號(hào)終端來進(jìn)行論述，不盡悉數(shù)。
在對蘋果6s（A1700）的手機(jī)進(jìn)行注冊失敗分析時(shí)，發(fā)現(xiàn)響應(yīng)碼為400的占比較高：
截取一個(gè)典型的蘋果6s手機(jī)（A1700）的注冊失敗信令圖：
在不考慮注冊消息在Gm重復(fù)發(fā)送的因素以外，針對蘋果終端失敗響應(yīng)碼為400的情況，這類初始注冊失敗有個(gè)特征： 先發(fā)起初始注冊，收到網(wǎng)絡(luò)下發(fā)的401挑戰(zhàn)，但手機(jī)不予理會(huì)，過幾秒鐘時(shí)間后，手機(jī)發(fā)起PDN連接性請求（APN=IMS），再次建立起IMS信令的默認(rèn)承載，并分配得到新的IPV6地址。 再次發(fā)起初始注冊，本次Call-ID與上次的相同，但不攜帶IMS認(rèn)證響應(yīng)RES結(jié)果（其Nonce和response均為空），Gm接口的P-CSCF地址改變（出于安全和負(fù)荷角度考慮，輪流使用兩個(gè)不同地址的代理服務(wù)器）。 當(dāng)S-CSCF收到本次的同一個(gè)Call-ID注冊信息，認(rèn)為是上次注冊的延續(xù)，但同時(shí)根據(jù)未攜帶IMS認(rèn)證信息也判斷出并非接在401認(rèn)證挑戰(zhàn)消息后的二次注冊，于是回應(yīng)失敗響應(yīng)碼400，具體原因值為“SIP Key Parameter Invalid”或“Invalid Message”。 建議終端廠家出補(bǔ)丁來解決401認(rèn)證挑戰(zhàn)消息的兼容性問題。 建議核查S-CSCF下發(fā)的401認(rèn)證挑戰(zhàn)消息的兼容性問題。
在對三星S6（TAC=35818206批次）的手機(jī)進(jìn)行注冊失敗分析時(shí)，發(fā)現(xiàn)原因值為486和500的占比較高：
手機(jī)發(fā)起初始注冊或重注冊，S-CSCF回送401挑戰(zhàn)消息，但手機(jī)UE未響應(yīng)401挑戰(zhàn)消息，稍后UE再次發(fā)起初始注冊（可發(fā)生APN=IMS的PDN重新連接，重新分配IPV6地址），兩次注冊的Call-ID不同，但由于S-CSCF注冊消息處理周期定時(shí)器（30s）還在工作，認(rèn)為同一個(gè)IMSI用戶的第一次注冊尚未完成，因此直接回應(yīng)486 Busy Here消息，原因值為'Too many register in parallel'，拒絕了注冊操作流程。由此產(chǎn)生了兩次初始注冊失敗，截圖如下：
建議終端廠家出補(bǔ)丁來解決401認(rèn)證挑戰(zhàn)消息的兼容性問題。 建議核查S-CSCF下發(fā)的401認(rèn)證挑戰(zhàn)消息的兼容性問題。 建議S-CSCF縮短注冊保護(hù)定時(shí)器時(shí)長或修改流程以信任新的注冊消息。 500失敗響應(yīng)碼為服務(wù)器內(nèi)部錯(cuò)誤，由S-CSCF實(shí)體產(chǎn)生，建議檢查S-CSCF內(nèi)部事件記錄。
在對步步高VIVO X6D（TAC=86989502批次）的手機(jī)進(jìn)行注冊失敗分析時(shí)，發(fā)現(xiàn)代碼為486和500的占比較高：
代碼486的產(chǎn)生類似三星S6手機(jī)過程：也是因?yàn)槭謾C(jī)不響應(yīng)401認(rèn)證挑戰(zhàn)消息，直至超時(shí)，而后手機(jī)再次發(fā)起初始注冊，但被S-CSCF拒絕，產(chǎn)生486 BUSY HERE代碼。 同時(shí)這款手機(jī)還有個(gè)問題：每隔一段時(shí)間發(fā)起一次初始注冊（無規(guī)律），而不是重注冊，那么S-CSCF會(huì)判斷為該用戶存在故障，于是一方面予以注冊成功，另一方面又是第三方注銷，存在邏輯上的混亂，之后是手機(jī)注銷。而后手機(jī)再次發(fā)起初始注冊，但對401認(rèn)證挑戰(zhàn)消息無響應(yīng)，如此循環(huán)。 500響應(yīng)碼的注冊失敗為服務(wù)器內(nèi)部錯(cuò)誤，由P-CSCF實(shí)體產(chǎn)生，原因值為“AKA IP+Port conflict”，這是因?yàn)橹癙GW分配的IPV6地址以及發(fā)布的兩個(gè)P-CSCF地址所產(chǎn)生的手機(jī)端口號(hào)被某個(gè)P-CSCF拒絕所導(dǎo)致，更換另一個(gè)P-CSCF則通過。
建議終端廠家出補(bǔ)丁來解決401認(rèn)證挑戰(zhàn)消息的兼容性問題。 建議核查S-CSCF下發(fā)的401認(rèn)證挑戰(zhàn)消息的兼容性問題。 建議終端廠家出補(bǔ)丁來解決多次初始注冊和注銷的BUG問題。 建議終端廠家出補(bǔ)丁來解決UE源端口號(hào)算法問題，以便讓P-CSCF所識(shí)別。
在對金立GN9010（TAC=86861202批次）的手機(jī)進(jìn)行注冊失敗分析時(shí)，發(fā)現(xiàn)原因值為486和500的占比較高。
其中失敗響應(yīng)碼486的產(chǎn)生過程和三星S6手機(jī)的一樣：也是手機(jī)發(fā)起初始注冊，S-CSCF回送401挑戰(zhàn)消息，但手機(jī)UE未響應(yīng)401挑戰(zhàn)，之后進(jìn)行PDN連接性請求，重新分配得到IPV6地址，而后進(jìn)行新的初始注冊，兩次注冊的Call-ID不同，但前后兩次時(shí)間差在S-CSCF的注冊保護(hù)定時(shí)器作用的時(shí)長內(nèi)，S-CSCF回送失敗響應(yīng)碼486，具體原因?yàn)椤癟oo Many Register in Parallel”。 而500失敗響應(yīng)碼的產(chǎn)生與步步高VIVO X6D的一樣：也是由P-CSCF實(shí)體產(chǎn)生，注冊失敗為服務(wù)器內(nèi)部錯(cuò)誤，原因值為“AKA IP+Port conflict”，這是因?yàn)橹癙GW分配的IPV6地址以及發(fā)布的兩個(gè)P-CSCF地址所產(chǎn)生的手機(jī)端口號(hào)被某個(gè)P-CSCF拒絕所導(dǎo)致，更換另一個(gè)P-CSCF則通過。 建議終端廠家出補(bǔ)丁來解決401認(rèn)證挑戰(zhàn)消息的兼容性問題。 建議核查S-CSCF下發(fā)的401認(rèn)證挑戰(zhàn)消息的兼容性問題。 建議S-CSCF縮短注冊保護(hù)定時(shí)器時(shí)長或修改流程以信任新的注冊消息。 建議終端廠家出補(bǔ)丁來解決UE源端口號(hào)算法問題，以便讓P-CSCF所識(shí)別。 由于寫文檔是非常辛苦的過程，希望得到大家的鼓勵(lì)和動(dòng)力,見下面“贊賞”按鈕，愿大家能獲得更多的知識(shí)點(diǎn)，對工作有強(qiáng)大的促進(jìn)。 作者介紹：周國有，從事核心網(wǎng)工作后轉(zhuǎn)至無線網(wǎng)優(yōu)，熟悉3GPP協(xié)議，熟悉信令流程，擅長234G互操作融合優(yōu)化，目前在杭州華星公司。
|
|
|
