手機電視業(yè)務平臺接口規(guī)范

QB-X-XXX-XXXX中國移動通信企業(yè)標準中國移動通信企業(yè)標準QB-QB-╳╳-╳╳╳-╳╳╳╳基于廣播方式的手機電視業(yè)務平臺接口規(guī)范基于廣播方式的手機電視業(yè)務平臺接口規(guī)范MobileTVServicePlatformMobileTVServicePlatformInterfaceSpecification版本號：版本號：1.0.0（征求意見稿）╳╳╳╳-╳╳╳╳-╳╳-╳╳實施╳╳╳╳-╳╳-╳╳發(fā)布中國移動通信有限公司發(fā)布中國移動通信有限公司發(fā)布QB-╳╳-╳╳╳-╳╳╳╳PAGE47目錄TOC\o"3-3"\h\z\t"標題1,1,標題2,2"1 范圍 12 規(guī)范性引用文件 13 術語、定義和縮略語 24 網絡結構 24.1 網元功能描述 24.2 接口描述 24.2.1 手機電視業(yè)務平臺與終端之間的接口 24.2.2 手機電視業(yè)務平臺與HLR之間的接口 34.2.3 手機電視業(yè)務平臺與BOSS之間的接口 34.2.4 手機電視業(yè)務平臺與WAP網關之間的接口 34.2.5 手機電視業(yè)務平臺與短信網關之間的接口 34.2.6 手機電視業(yè)務平臺之間的接口 34.2.7 手機電視業(yè)務平臺內部接口 34.2.8 手機電視業(yè)務平臺與廣電側手機電視系統(tǒng)的接口 35 接口定義 45.1 手機電視業(yè)務平臺與終端之間的接口 45.1.1 接口協(xié)議總體結構 45.1.2 接口協(xié)議描述 45.1.3 接口協(xié)議流程描述 55.1.4 異常情況處理 115.1.5 消息編碼定義 125.2 手機電視業(yè)務平臺與HLR之間的接口 275.2.1 接口協(xié)議總體結構 275.2.2 接口協(xié)議描述 275.2.3 接口協(xié)議流程描述 275.2.4 異常情況處理 275.2.5 消息編碼定義 275.3 手機電視業(yè)務平臺與BOSS之間的接口 325.4 手機電視業(yè)務平臺與WAP網關之間的接口 325.5 手機電視業(yè)務平臺與短信網關之間的接口 335.6 手機電視業(yè)務平臺之間的接口 335.6.1 接口協(xié)議總體結構 335.6.2 接口協(xié)議描述 335.6.3 接口協(xié)議流程描述 345.6.4 異常情況處理 355.6.5 消息編碼定義 355.7 手機電視業(yè)務平臺內部接口 445.7.1 接口協(xié)議總體結構 445.7.2 接口協(xié)議描述 445.7.3 接口協(xié)議流程描述 445.7.4 異常情況處理 455.7.5 消息編碼定義 455.8 手機電視業(yè)務平臺與廣電側手機電視系統(tǒng)的接口 465.8.1 接口協(xié)議總體結構 465.8.2 接口協(xié)議描述 465.8.3 接口定義 46E.1Service數據單元 51E.2Content數據單元 51E.3Access數據單元 52E.4PreviewData數據單元 52

前言本標準FORMTEXT的目的。本標準主要包括以下幾方面內容FORMTEXT。{以下內容視需要保留：本標準是FORMTEXT系列標準之一，下面是該系列標準的預計結構：FORMTEXT。本標準替代FORMTEXT，與原標準相比，主要差別如下：FORMTEXT。本標準與其他標準的關系：}本標準的附錄FORMTEXT為規(guī)范性附錄，附錄FORMTEXT為資料性附錄。本標準由中移FORMTEXT號印發(fā)。本標準由中國移動通信有限公司FORMTEXT提出并歸口。本標準由標準歸口部門負責解釋。本標準起草單位：FORMTEXT。本標準主要起草人：FORMTEXT。范圍本標準規(guī)定了FORMTEXT，供FORMTEXT中國移動內部和廠商共同使用；適用于FORMTEXT。規(guī)范性引用文件下列文件中的條款通過本標準的引用而成為本標準的條款。凡是注日期的引用文件，其隨后所有的修改單（不包括勘誤的內容）或修訂版均不適用于本標準，然而，鼓勵根據本標準達成協(xié)議的各方研究是 否可使用這些文件的最新版本。凡是不注日期的引用文件，其最新版本適用于本標準。[1]QB-X-XXX-XXXX《中國移動通信互聯(lián)網短信網關接口協(xié)議（v3.0.0）》中國移動通信有限公司[2]3GPP

TS

33.220GenericAuthenticationArchitecture(GAA);GenericBootstrappingArchitecture(Release6)3GPP

[3]IETFRFC

3310HypertextTransferProtocol(HTTP)DigestAuthenticationUsingAuthenticationandKeyAgreement(AKA)IETF[4]3GPP

TS

24.1093rdGenerationPartnershipProject;TechnicalSpecificationGroupCoreNetwork;Bootstrappinginterface(Ub)andnetworkapplicationfunctioninterface(Ua);Protocoldetails3GPP

[5]3GPP

TS

33.1023rdGenerationPartnershipProject;TechnicalSpecificationGroupServicesandSystemAspects;3GSecurity;Securityarchitecture3GPP

[6]IETFRFC2617HTTPAuthentication:BasicandDigestAccessAuthenticationIETF[7]3GPP

TS

26.346

MultimediaBroadcast/MulticastService;ProtocolsandCodecs3GPP

[8]IETF

RFC

3588

DiameterBaseProtocolIETF

[9]3GPPTS29.109GenericAuthenticationArchitecture(GAA);ZhandZnInterfacesbasedontheDiameterprotocol;Protocoldetails3GPP[10]3GPP

TS

29.0023rdGenerationPartnershipProject;TechnicalSpecificationGroupCoreNetworkandTerminals;MobileApplicationPart(MAP)specification;3GPP[11]ETSITS103197DVBSimulCryptHead-endimplementationofDVBSimulCrypt,-v1.4.1ETSI[12]手機電視業(yè)務指南規(guī)范[13]加擾器設備規(guī)范術語、定義和縮略語用戶標識：IMPI或IMSI。下列術語、定義和縮略語適用于本標準：AVAuthenticationVector鑒權元組網絡結構網元功能描述BSF模塊功能應相對獨立。接口描述手機電視業(yè)務平臺與終端之間的接口手機電視業(yè)務平臺與終端之間的接口功能如下：執(zhí)行GBA初始化流程，生成Ks。終端獲取業(yè)務指南執(zhí)行業(yè)務訂購和業(yè)務退訂完成業(yè)務密鑰的分發(fā)手機電視業(yè)務平臺與HLR之間的接口手機電視業(yè)務平臺與HLR之間的接口功能如下：手機電視業(yè)務平臺向用戶歸屬HLR/AuC請求AV（AuthenticationVector，鑒權元組）手機電視業(yè)務平臺與BOSS之間的接口手機電視業(yè)務平臺與BOSS系統(tǒng)之間的接口功能為：手機電視業(yè)務平臺將話單發(fā)送到BOSS系統(tǒng)。手機電視業(yè)務平臺與WAP網關之間的接口WAP網關在手機電視業(yè)務網絡中是終端與手機電視業(yè)務平臺進行HTTP交互的代理。當終端通過域名方式向手機電視業(yè)務平臺發(fā)起請求時，WAP網關根據終端IP地址確定終端的接入地，指定接受用戶請求的業(yè)務平臺，并將用戶請求發(fā)送給相應的手機電視業(yè)務平臺；同時，WAP網關將用戶的MSISDN插入到HTTP請求的消息頭中，發(fā)送給手機電視業(yè)務平臺。手機電視業(yè)務平臺與短信網關之間的接口手機電視業(yè)務平臺與短信網關之間的接口用于向傳送送由短消息承載的數據。手機電視業(yè)務平臺之間的接口手機電視業(yè)務平臺之間的接口的功能是：當用戶在漫游狀態(tài)下執(zhí)行手機電視業(yè)務的操作時，拜訪地手機電視業(yè)務平臺網絡需要和用戶歸屬地手機電視業(yè)務平臺中的BSF模塊和業(yè)務管理模塊進行用戶相關信息的交互，以使用戶在拜訪地可以收看拜訪地的電視節(jié)目。手機電視業(yè)務平臺之間的接口具體包含兩個功能：請求用戶密鑰。管理用戶訂購關系。業(yè)務信息同步。手機電視業(yè)務平臺內部接口為支持手機電視業(yè)務平臺網絡架構的可擴展性，手機電視業(yè)務平臺內部的BSF模塊應具有獨立性。手機電視業(yè)務平臺中的業(yè)務中心模塊與BSF模塊接口應遵循本規(guī)范規(guī)定的標準接口，以適應于未來網絡演進，使得BSF模塊可方便地從手機電視業(yè)務平臺中獨立出來。手機電視業(yè)務平臺與廣電側手機電視系統(tǒng)的接口手機電視業(yè)務平臺與廣電側手機電視系統(tǒng)的接口包括以下功能：業(yè)務信息同步訂購關系同步節(jié)目密鑰傳送接口定義手機電視業(yè)務平臺與終端之間的接口接口協(xié)議總體結構手機電視業(yè)務平臺與終端之間接口的總體協(xié)議結構如圖。HTTPDigestApplicationMIKEY/EXTApplicationHTTPTCPIPSMS手機電視業(yè)務平臺與終端之間接口能夠實現(xiàn)GBA初始化，業(yè)務應用和業(yè)務密鑰分發(fā)等功能。其功能基于HTTP/TCP/IP協(xié)議棧實現(xiàn)。接口協(xié)議描述GBA初始化當終端客戶端開啟并發(fā)現(xiàn)本地不存在Ks時，將會觸發(fā)GBA初始化流程。GBA初始化過程中，終端和手機電視業(yè)務平臺內部的BSF模塊進行基于HTTPdigestAKA認證協(xié)議的Bootstrapping流程，從而實現(xiàn)相互認證，協(xié)商會話密鑰。業(yè)務指南獲取終端通過移動通信網絡向手機電視業(yè)務平臺中的業(yè)務指南服務器發(fā)送業(yè)務指南獲取請求，業(yè)務指南服務器向終端發(fā)送最新的業(yè)務指南數據。該接口基于HTTP協(xié)議實現(xiàn)。業(yè)務訂購/退訂終端向手機電視業(yè)務平臺發(fā)送業(yè)務訂購/退訂請求，手機電視業(yè)務平臺執(zhí)行訂購關系處理操作后向終端返回響應。業(yè)務訂購的方式為：用戶在客戶端點擊業(yè)務訂購鏈接，觸發(fā)終端向手機電視業(yè)務平臺發(fā)送業(yè)務訂購消息。用戶通過發(fā)送短信訂購業(yè)務。（二階段）業(yè)務退訂的方式為：用戶登錄手機電視業(yè)務平臺提供的自服務界面，通過自服務功能退訂業(yè)務。平臺自服務功能的訪問方式包括WWW方式和WAP方式。用戶可以撥打客服電話退訂業(yè)務。客服人員通過登錄WWW管理界面完成業(yè)務退訂。用戶通過自服務方式或客服方式能夠退訂所有業(yè)務，包括用戶在歸屬地訂購的業(yè)務和用戶在拜訪地訂購的業(yè)務。用戶通過客戶端方式退訂業(yè)務。（二階段）業(yè)務密鑰分發(fā)手機電視業(yè)務平臺根據用戶的業(yè)務訂購狀態(tài)及節(jié)目的播放狀態(tài)等信息在適當時間向終端發(fā)送業(yè)務密鑰。用戶在終端上選擇感興趣的節(jié)目，如果在卡中未保存業(yè)務密鑰，則終端向手機電視業(yè)務平臺發(fā)送業(yè)務密鑰的獲取請求，手機電視業(yè)務平臺根據用戶的業(yè)務訂購關系向終端返回響應，業(yè)務密鑰可以包含在響應消息中。手機電視業(yè)務平臺可主動觸發(fā)終端的請求消息，并在響應消息中將業(yè)務密鑰發(fā)送給用戶。網絡觸發(fā)消息基于短信實現(xiàn)。密鑰獲取流程基于HTTP協(xié)議實現(xiàn)。接口協(xié)議流程描述GBA初始化流程流程圖如圖。

GBA初始化流程圖流程描述：終端向卡請求用戶標識。如用戶卡為SIM卡或僅支持USIM應用的UICC卡，則終端獲得用戶IMSI。如用戶卡為同時支持USIM、ISIM功能的UICC卡，則終端獲得用戶IMPI。終端向接入地WAP網關發(fā)送Bootstrapping_Initiation.REQ消息。接入地WAP網關向拜訪地手機電視業(yè)務平臺發(fā)送Bootstrapping_Initiation.REQ消息。拜訪地手機電視業(yè)務平臺從Bootstrapping_Initiation.REQ消息中獲取用戶標識。如用戶標識為IMSI，則將IMSI映射為IMPI，并查詢對應的BSF地址。映射規(guī)則參見附錄A。如用戶標識為IMPI，則查詢對應的BSF地址。拜訪地手機電視業(yè)務平臺向接入地WAP網關返回Bootstrapping_Initiation.RES消息。消息中包含歸屬BSF的地址。如果Bootstrapping_Initiation.REQ消息的用戶標識是IMSI，則Bootstrapping_Initiation.RES消息中還包含用戶的IMPI。接入地WAP網關向終端返回Bootstrapping_Initiation.RES消息。終端向接入地WAP網關發(fā)送Bootstrapping_Register.REQ消息，消息目標地址為用戶歸屬BSF。消息中包含用戶IMPI。接入地WAP網關向用戶歸屬BSF發(fā)送Bootstrapping_Register.REQ消息。歸屬BSF將用戶IMPI映射為IMSI，并向歸屬HLR/AuC發(fā)送AuthenticationDataRequest消息，請求多組AV(AuthenticationVector，鑒權元組)。HLR/AuC根據IMSI查找用戶鑒權密鑰(Ki或K)，根據請求的AV個數執(zhí)行多個AV運算；并向BSF發(fā)送AuthenticationDataResponse消息，返回運算獲得的AVs。當用戶為SIM卡用戶時，HLR/AuC執(zhí)行3元AV運算，生成(RAND,SRES,Kc)；當用戶為USIM卡用戶，HLR/AuC執(zhí)行5元AV，生成(RAND,AUTN,XRES,CK,IK)。歸屬BSF使用1組AV，向用戶接入地WAP網關返回Bootstrapping_Register.RES消息。如果是3元AV，則消息中包含RAND；如果是5元AV，則消息中包含RAND和AUTN*（AUTN*的計算方法參見3GPP

TS

33.220[2]）。接入地WAP網關向終端返回Bootstrapping_Register.RES消息。終端向卡發(fā)送AuthenticationCommand命令，其中攜帶RAND或(RAND,AUTN*)?？ㄟ\算獲得AV，并返回給終端。如用戶卡為SIM卡，則執(zhí)行3元AV運算，生成SRES；然后再生成RES：RES=KDF(key,"3gpp-gba-res",SRES)，具體參見3GPPTS33.220-740?？▽ES返回給終端；如用戶卡為USIM卡，則執(zhí)行5元AV運算。首先驗證AUTN*的有效性。若有效，則繼續(xù)運算(RES,CK,IK)，將RES返回給終端。若無效，觸發(fā)SQN重同步過程，參見“GBA初始化同步失敗”的流程終端向接入地WAP網關發(fā)送Bootstrapping_Authorization.REQ消息，消息目標地址為歸屬BSF。消息中包含SRES/RES的信息。接入地WAP網關向歸屬BSF發(fā)送Bootstrapping_Authorization.REQ消息。歸屬BSF進行鑒權。對于三元組，判斷終端發(fā)送的RES與BSF生成的RES是否相等；對于五元組，判斷終端發(fā)送的RES與BSF保存的XRES是否相等。若相等，則鑒權成功，生成Ks和B-TID。對于SIM卡，Ks=KDF(key,Ks-input,"3gpp-gba-ks",SRES)，其中key=Kc||Kc||RAND，Ks-input是BSF生成的一個128位隨機數。具體參見3GPPTS33.220-740。對于USIM卡，Ks=CK||IK。若SRES與RES不相等或RES與XRES不相等，則鑒權失敗。參見“GBA初始化鑒權失敗”歸屬BSF并向WAP網關返回Bootstrapping_Authorization.RES消息。鑒權成功消息中包含B-TID、Ks的生命周期。WAP網關向終端返回Bootstrapping_Authorization.RES消息。終端向卡中寫入B-TID、Ks的生命周期、RAND?？ㄉ蒏s。對于SIM卡，Ks=KDF(key,Ks-input,"3gpp-gba-ks",SRES)，其中key=Kc||Kc||RAND，Ks-input是BSF生成的一個128位隨機數。具體參見3GPPTS33.220-740。對于USIM卡，Ks=CK||IK。業(yè)務指南獲取流程流程描述：（1）終端向接入地WAP網關發(fā)送SG_Retrieve.REQ消息，請求瀏覽業(yè)務指南；（2）接入地WAP網關將SG_Retrieve.REQ消息發(fā)送給拜訪地手機電視業(yè)務平臺；（3）拜訪地手機電視業(yè)務平臺向接入地WAP網關發(fā)送SG_Retrieve.RES消息，消息中包含業(yè)務指南數據；（4）接入地WAP網關向終端發(fā)送SG_Retrieve.RES消息。業(yè)務訂購/退訂流程訂購業(yè)務流程流程描述：用戶在終端上點擊業(yè)務指南頁面中業(yè)務訂購的鏈接。終端向接入地WAP網關發(fā)送業(yè)務訂購請求。訂購請求中包含手機電視業(yè)務平臺的域名和訂購業(yè)務對應的PurchaseItemID。接入地WAP網關向拜訪地手機電視業(yè)務平臺發(fā)送業(yè)務訂購請求。拜訪地手機電視業(yè)務平臺向用戶歸屬地手機電視業(yè)務平臺的業(yè)務管理系統(tǒng)發(fā)送用戶訂購信息（SubscribeServiceReq）。用戶歸屬地手機電視業(yè)務平臺的業(yè)務管理系統(tǒng)向拜訪地手機電視業(yè)務平臺返回響應（SubscribeServiceResp）。拜訪地手機電視業(yè)務平臺向接入地WAP網返回響應。接入地WAP網向終端返回響應。訂購成功后歸屬地手機電視業(yè)務平臺向短信網關發(fā)送訂購成功通知消息。短信網關將訂購成功通知消息發(fā)送給短信中心。短信中心將訂購成功通知消息發(fā)送終端。退訂業(yè)務流程用戶退訂業(yè)務的流程如圖。流程描述：用戶通過自服務系統(tǒng)或客服系統(tǒng)向歸屬地手機電視業(yè)務平臺發(fā)送業(yè)務退訂請求。歸屬地手機電視業(yè)務平臺向用戶返回退訂響應。歸屬地手機電視業(yè)務平臺刪除用戶訂購關系。如果已通過網絡主動推送方式在業(yè)務密鑰生效之前提前向用戶發(fā)送了業(yè)務密鑰，則繼續(xù)執(zhí)行下面的流程；反之，則流程結束。歸屬地手機電視業(yè)務平臺生成無效業(yè)務密鑰。（注：僅有用戶歸屬地業(yè)務，用戶才會通過網絡主動推送方式提前獲得業(yè)務密鑰）（5）~（19）與“.2網絡主動推送方式”的流程中的（4）~（18）同。若用戶未發(fā)起SK_Retrieve.REQ消息，則網絡重復發(fā)送Notify消息。重復次數可配置。（二階段）業(yè)務密鑰分發(fā)流程業(yè)務密鑰分發(fā)有兩種方式：終端請求獲取方式：終端向手機電視業(yè)務平臺發(fā)送業(yè)務密鑰請求，業(yè)務平臺對終端鑒權通過后向終端發(fā)送業(yè)務密鑰。網絡主動推送方式：業(yè)務密鑰生成后，手機電視業(yè)務平臺主動向業(yè)務平臺所在地所有已訂購相應業(yè)務的用戶終端推送業(yè)務密鑰。終端主動請求方式終端從卡讀取的B-TID和MRK。終端向接入地WAP網關發(fā)送SK_Retrieve.REQ消息。接入地WAP網關向拜訪地手機電視業(yè)務平臺發(fā)送SK_Retrieve.REQ消息。拜訪地手機電視業(yè)務平臺向接入地WAP網關返回消息SK_Retrieve_Unauthorized消息（HTTP401WWW-Authenticate）。接入地WAP網關向終端返回SK_Retrieve_Unauthorized消息（HTTP401WWW-Authenticate）。終端向接入地WAP網關SK_Retrieve_Authorization_Request消息。接入地WAP網關向手機電視業(yè)務平臺發(fā)送SK_Retrieve_Authorization_Request消息。手機電視業(yè)務平臺查詢用戶密鑰。如果查詢結果為以下情況之一，則執(zhí)行（9）：用戶B-TID不存在用戶的MRK和MUK的生存時間已超過有效期若查詢結果為用戶B-TID存在且用戶的MRK和MUK有效，則執(zhí)行（11）。拜訪地手機電視業(yè)務平臺向用戶歸屬地手機電視業(yè)務平臺（歸屬地BSF）發(fā)送用戶密鑰獲取請求。歸屬地手機電視業(yè)務平臺（歸屬地BSF）將用戶密鑰返回給拜訪地手機電視業(yè)務平臺。（如果用戶密鑰過期，觸發(fā)重新GBA過程；如果B-TID不存在，）拜訪地手機電視業(yè)務平臺對用戶進行鑒權，判別網絡存儲的B-TID所對應的MRK信息與用戶發(fā)送的MRK是否一致。若不一致，則鑒權失敗，參見“用戶鑒權失敗”的流程。鑒權通過，拜訪地手機電視業(yè)務平臺根據以下情況判斷業(yè)務密鑰分發(fā)方式屬于終端主動請求方式：請求消息中不包含業(yè)務密鑰有效期，并且業(yè)務密鑰標識是當前所使用的。拜訪地手機電視業(yè)務平臺向歸屬地手機電視業(yè)務平臺的業(yè)務管理系統(tǒng)發(fā)送用戶訂購信息查詢請求。歸屬地手機電視業(yè)務平臺的業(yè)務管理系統(tǒng)向拜訪地手機電視業(yè)務平臺返回查詢結果。如用戶未訂購業(yè)務，參見“業(yè)務未訂購”的流程。拜訪地手機電視業(yè)務平臺向接入地WAP網關發(fā)送SK_Retrieve.RES消息。接入地WAP網關向終端發(fā)送送SK_Retrieve.RES消息。網絡主動推送方式流程描述：手機電視業(yè)務平臺生成新的業(yè)務密鑰消息，如新的頻道包月密鑰，或某節(jié)目密鑰消息。手機電視業(yè)務平臺向平臺所在地的訂購關系關系系統(tǒng)查詢已訂購該業(yè)務的本地用戶MSISDN列表。平臺所在地的訂購關系關系系統(tǒng)向手機電視業(yè)務平臺返回已訂購該業(yè)務的本地用戶信息，并更新每個用戶的已發(fā)送業(yè)務密鑰的記錄。手機電視業(yè)務平臺緩存用戶信息；并向短信網關發(fā)送業(yè)務密鑰發(fā)送通知消息，即Notify消息。若待發(fā)送的業(yè)務密鑰用于收看整個頻道，則通知消息中包含業(yè)務密鑰標識若待發(fā)送的業(yè)務密鑰用于收看某個節(jié)目，則通知消息中包含業(yè)務密鑰標識和業(yè)務密鑰有效性短信網關向手機電視業(yè)務平臺返回響應。短信網關向短信中心發(fā)送業(yè)務密鑰發(fā)送通知消息。短信中心向短信網關返回接收響應。短信中心向終端發(fā)送業(yè)務密鑰發(fā)送通知消息。終端從卡讀取的B-TID和MRK。終端向接入地WAP網關發(fā)送SK_Retrieve.REQ消息。接入地WAP網關向拜訪地手機電視業(yè)務平臺發(fā)送SK_Retrieve.REQ消息。拜訪地手機電視業(yè)務平臺向接入地WAP網關返回消息SK_Retrieve_Unauthorized消息（HTTP401WWW-Authenticate）。接入地WAP網關向終端返回SK_Retrieve_Unauthorized消息（HTTP401WWW-Authenticate）終端向接入地WAP網關SK_Retrieve_Authorization_Request消息。接入地WAP網關向手機電視業(yè)務平臺發(fā)送SK_Retrieve_Authorization_Request消息。手機電視業(yè)務平臺對用戶進行鑒權，查詢B-TID是否有效，判別用戶發(fā)送的MRK是否有效，判別網絡存儲的MRK和MUK是否在有效期內。如果用戶的B-TID存在，但MRK和MUK的生存時間已超過有效期，則觸發(fā)GBA過程如果用戶的B-TID不存在，或網絡存儲的B-TID所對應的MRK信息與用戶發(fā)送的MRK不一致，則鑒權失敗，參見“用戶鑒權失敗”的流程。（17）手機電視業(yè)務平臺根據以下情況之一判斷業(yè)務密鑰發(fā)送方式屬于網絡主動方式：情況一：請求消息中含有業(yè)務密鑰有效期；情況二：業(yè)務密鑰標識是下一個月即將使用的，并非當前業(yè)務密鑰標識；對于以上情況之一，手機電視業(yè)務平臺查詢用戶是否在緩存的用戶列表中。如果是，則拜訪地手機電視業(yè)務平臺向接入地WAP網關發(fā)送SK_Retrieve.RES消息。（18）接入地WAP網關向終端發(fā)送送SK_Retrieve.RES消息。異常情況處理GBA初始化同步失敗流程描述：1~12同“GBA初始化流程”。終端向卡發(fā)送AuthenticationCommand命令，其中攜帶RAND或(RAND,AUTN)?？ㄟ\算獲得AV，并返回給終端。如用戶卡為USIM卡，執(zhí)行5元AV運算，驗證AUTN的有效性。若無效，觸發(fā)SQN重同步過程（該過程為UMTS接入鑒權標準流程）。重新開始執(zhí)行第7步，但消息參數不同。消息編碼參見“5.1.5消息編碼定義”。GBA初始化鑒權失敗流程描述：1~15同“GBA初始化流程”。16.歸屬BSF進行鑒權，判斷SRES是否與RES相等或判斷RES是否與XRES相等；若不相等，則鑒權失敗。17.歸屬BSF向WAP網關返回鑒權失敗的響應消息。18.WAP網關向終端返回鑒權失敗的響應消息，HTTP響應的錯誤代碼為406。用戶鑒權失敗若鑒權失敗，則拜訪地手機電視業(yè)務平臺經WAP網關向終端發(fā)送SK_Retrieve.RES消息，HTTP響應的錯誤代碼為406。業(yè)務未訂購拜訪地手機電視業(yè)務平臺向終端SK_Retrieve.RES消息，HTTP響應的錯誤代碼為431。流程結束。服務器錯誤BSF發(fā)送Register消息響應后，很長時間沒有收到終端的Authorization請求，則GBA初始化失敗，鑒權元組按已使用處理。消息編碼定義Bootstrapping_Initiation消息Bootstrapping_Initiation.REQ消息發(fā)送方向：終端－>手機電視業(yè)務平臺。消息格式如下：POST<RequestURI>HTTP/1.1Host:Content-Type:Content-Length:User-Agent:Date:Accept:Referrer:<payload>RequestURI： /?requesttype=bootstrapping_initiationHost： 手機電視業(yè)務平臺的域名及端口Content-Type： application/xmlContent-Length： 表明了消息體長度；User-Agent： 表明了客戶端的信息；Date： 發(fā)起請求的日期、時間Accept： 終端可以接收的響應消息的媒體類型<payload>：消息體中包含一個XML文檔。其中包含用戶標識。信息如下：名稱類型是否可選對應關系描述數據類型UserIDE必選1用戶號碼。包含屬性：TypestringTypeA必選1用戶號碼的類型，可以為以下值：IMPIIMSIstring類型:E=ElementA=AttributeE1=sub-element,E2=sub-element’ssub-elementSchema參見附件。Bootstrapping_Initiation.RES消息發(fā)送方向：手機電視業(yè)務平臺－>終端。消息格式如下：HTTP/1.1200OKServer:Content-Type:Content-Length:Date:Expires:<payload>Server：服務器軟件信息Content-Type：application/xmlContent-Length：消息體長度；<payload>：消息體中包含了一個XML文檔，其中包含了歸屬地的BSF地址。信息如下：名稱類型是否可選對應關系描述數據類型UserIDE必選0..1用戶IMPI號碼。當Bootstrapping_Initiation.REQ中Type為IMPI時，此值為空stringTypeA必選0..1用戶號碼的類型，可以為以下值：IMPIstringBSFAddressE必選1用戶歸屬的BSF地址。BSF地址可以為以下形式之一：域名域名和端口IP地址IP地址和端口string類型:E=ElementA=AttributeE1=sub-element,E2=sub-element’ssub-elementSchema參見附件。Bootstrapping消息Bootstrapping過程包括包括4條消息。分別為：Bootstrapping_Register的.REQBootstrapping_Register的.RESBootstrapping_Authorization的.REQBootstrapping_Authorization的.RES。消息定義符合3GPP

TS

33.220[2]中Ub參考點上Bootstrapping過程中消息的定義。基于3GPPAKA協(xié)議（參見TS

33.102

[2]）和HTTPdigestAKAprotocol（參見RFC

3310

[4]）實現(xiàn)。Bootstrapping_Register.REQ消息發(fā)送方向：終端－>BSF。消息格式如下：GET<RequestURI>HTTP/1.1Host:User-Agent:Date:Accept:Referer:Authorization:Digest username, realm, nonce, uri, response, algorithm cnonce opaque qop nc autsRequestURI： 位于GET之后，默認使用“/”；Host： 指定了BSF服務器的域名及端口；其值從Bootstrapping_Initiation的響應消息中獲得；User-Agent： 發(fā)起請求的UserAgent的信息；Date： 描述請求發(fā)起的日期和時間；Accept： 指明UserAgent可以接收的響應消息的媒體類型；Referer： 允許Useragent指定是從哪個源地址發(fā)起的Bootstrapping流程；Authorization： 攜帶認證信息，信息如下：參數名稱類型長度說明username“string”variable用戶私有標識IMPI；realm,“string”variableBSF服務器的域名nonce“string”variable1、如果該消息是發(fā)起B(yǎng)ootstrapping流程時，這個參數為空；2、如果該消息是因為終端認證網絡失敗，即MAC不等于XMAC，SQN非法，那么該請求是用于提示BSF進行SQN重同步的。那么該值包含了BSF發(fā)來的響應消息中WWW-Authenticate頭中的nonce值的原文。uri,=requesturivariable此處的uri＝RequestURIresponse十六進制數321、如果該消息是發(fā)起B(yǎng)ootstrapping流程，則這個參數為空；2、如果該消息是因為終端認證網絡失敗，觸發(fā)重同步，則：Response=MD5[MD5(username:realm:password):nonce:nc:cnonce:qop:MD5(method:URI)]其中password為空字符串。具體可參見RFC2617。algorithmstringvariable默認使用AKAv1-MD5cnonce“string”variable1、如果該消息是發(fā)起B(yǎng)ootstrapping流程時，這個參數為空；2、如果服務器發(fā)送的WWWAuthenticate消息頭中的qop=auth或者auth-int,則終端需要指定的該值，服務器需要使用該值生成rpsauth值，以便終端驗證服務器的合法性。Cnonce的使用參照RFC2617文檔opaque“string”variable1、如果該消息是發(fā)起B(yǎng)ootstrapping流程時，這個參數為空；2、如果該消息是因為終端認證網絡失敗，觸發(fā)重同步，則終端原文返回服務器發(fā)送來的該字符串。Qop“qop-vale”variable1、如果該消息是發(fā)起B(yǎng)ootstrapping流程時，這個參數為空；2、如果該消息是因為終端認證網絡失敗，觸發(fā)重同步，如果服務器發(fā)送的wwwAuthenticate消息頭中包含該值，則終端返回的消息也應該包含該值，默認使用auth-intnc16進制數8Noncecounter，終端指定的值，對包含同一個nonce值的請求進行計數，當服務器發(fā)送的wwwAuthenticate消息頭中含有qop時，終端必須指定該值。auts“string”variable1、如果該消息是發(fā)起B(yǎng)ootstrapping流程時，這個參數為空；2、如果該消息是因為終端認證網絡失敗，觸發(fā)重同步，則AUTS＝SQNMS*f5*K(RAND)||MAC?S消息舉例：GET/HTTP/1.1Host::9999User-Agent:BootstrappingClientAgent;Release-6Date:Thu,08Jan200410:13:17GMTAccept:*/*Referer::2311/pkip/enrollAuthorization:Digestusername="user1_private@",realm="",nonce="",uri="/",response=""Bootstrapping_Register.RES消息發(fā)送方向：BSF－>終端。消息格式如下：HTTP/1.1401UnauthorizedServer:Date:WWW-Authenticate:Digest

realm,

nonce,

algorithm,

qop,Server: 包含了BSF服務器的信息，如版本信息；Date: 表明了該響應消息發(fā)出的日期和時間；WWW-Authenticate：攜帶信息如下： 參數名類型長度說明realm“string”variableBSF服務器的域名nonce“string”variable該值由服務器在向HLR/AuC取得鑒權元組后生成，1、對于五元組：nonce＝<base64encodingofRAND,AUTN,andserverspecificdata>2、對于三元組：nonce＝<base64encodingofRAND,andserverspecificdata>,其中serverspecificdata＝128bitrandomdata，此處可以參考3GPPTS33.220opaque“string”variableBSF指定該值，要求終端原文返回algorithmstringvariableAKAv1-MD5qop“qop-vale”variable默認使用auth-int消息舉例：HTTP/1.1401UnauthorizedServer:BootstrappingServer;Release-6Date:Thu,08Jan200410:13:17GMTWWW-Authenticate:Digestrealm="",nonce=base64(RAND+AUTN+serverspecificdata),algorithm=AKAv1-MD5,qop="auth-int"Bootstrapping_Authorization.REQ消息發(fā)送方向：終端－>BSF。消息格式如下：GET<requestURI>HTTP/1.1Host:User-Agent:Date:(e.g.Thu,08Jan200810:13:17GMTAccept:Referer:Authorization:Digestusername,realm,nonce,uri,response,algorithmcnonceopaqueqopncautsRequestURI： 位于GET之后，默認使用“/”；Host： 指定了BSF服務器的域名及端口；其值從Bootstrapping_Initiation的響應消息中獲得；User-Agent： 發(fā)起請求的UserAgent的信息；Date： 描述請求發(fā)起的日期和時間；Accept： 指明UserAgent可以接收的響應消息的媒體類型；Referer： 允許Useragent指定是從哪個源地址發(fā)起的Bootstrapping流程；Authorization： 攜帶信息如下：參數名稱類型長度說明username“string”variable用戶私有標識IMPIrealm“string”variableBSF服務器的域名nonce“string”variable其值為BSF發(fā)送的WWW-Authenticate消息頭中包含的nonce值的原文：1、五元組：nonce＝<base64encodingofRAND,AUTN,andserverspecificdata>2、三元組：nonce＝<base64encodingofRAND,andserverspecificdata>,其中serverspecificdata＝128bitrandomdatauri,=requesturivariable此處的uri與RequestURI相同response十六進制數32Response=MD5[MD5(username:realm:password):nonce:nc:cnonce:qop:MD5(method:URI)]終端使用RAND及AUTN中的信息驗證BSF，驗證過程中將生成一個res，如果驗證通過，即MAC＝XMAC，則利用res作為密碼生成這個response值。這里可以參考RFC2617文檔中response的相關描述。algorithmstringvariable默認使用AKAv1-MD5cnonce“string”variable如果BSF發(fā)送的WWWAuthenticate消息頭中的qop=auth或者auth-int，則終端需要指定的該值，服務器需要使用該值生成rpsauth值，以便終端驗證服務器的合法性。Cnonce的使用參照RFC2617文檔。opaque“string”variable如果BSF發(fā)送的WWWAuthenticate消息頭中包含該值，則終端需原文返回該值。Qop“qop-vale”variable如果BSF發(fā)送的wwwAuthenticate消息頭中包含該值，則終端返回的消息也應該包含該值，默認使用auth-intnc16進制數8Noncecounter，終端指定的值，對包含同一個nonce值的請求進行計數，當服務器發(fā)送的wwwAuthenticate消息頭中含有qop時，終端必須指定該值。auts“string”variable該值為空消息舉例：GET/HTTP/1.1Host::9999User-Agent:BootstrappingClientAgent;Release-6Date:Thu,08Jan200410:13:18GMTAccept:*/*Referer::2311/pkip/enrollAuthorization:Digestusername="user1_private@",realm="",nonce=base64(RAND+AUTN+serverspecificdata),uri="/",qop=auth-int,nc=00000001,cnonce="6629fae49393a05397450978507c4ef1",response="6629fae49393a05397450978507c4ef1",opaque="5ccc069c403ebaf9f0171e9517f30e41",algorithm=AKAv1-MD5Bootstrapping_Authorization.RES消息發(fā)送方向：BSF－>終端。消息格式如下：（鑒權成功消息）HTTP/1.1200OKServer:Date:Expires:Content-Type:Content-Length:Authentication-Info:qop,rspauth,cnonce,nc<payload>Server： BSF服務器信息Date： 發(fā)送這個響應消息的日期、時間Content-Type: 消息體的媒體類型Content-Length: 消息實體的長度，使用八位十進制數字表示Expires: 指定一個時間，表示在這個給定的時間過后這個響應消息就視為失效Authentication-Info：攜帶信息如下：參數類型長度說明qop“qop-vale”variable默認使用auth-intrspauth“string”variablerspauth=MD5[MD5(username:realm:password):nonce:nc:cnonce:qop:MD5(:URI)],服務器使用和終端生成responce相同的方式生成的值，用于終端對服務器的認證，該值只在終端發(fā)送的請求中的Authorization頭中qop=auth或者auth-int時生成并在響應消息中返回給終端。計算rspauth時username是IMPI，password是XRES，cnonce和nc是終端在請求消息中攜帶的這兩個參數的值cnonce“string”variable終端指定的一個值，該值只在終端發(fā)送的請求中的Authorization頭中qop=auth或者auth-int時，服務器才需要按照原文返回nc十六進制數8終端指定的一個值，該值只在終端發(fā)送的請求中的Authorization頭中qop=auth或者auth-int時，服務器才需要按照原文返回<payload>：消息體中包含一個XML文檔，文件描述了Bootstrapping過程成功后，生成的共享密鑰的B-TID及密鑰的生命周期。XMLschema定義如下：<?xmlversion="1.0"encoding="UTF-8"?><xs:schematargetNamespace="uri:3gpp-gba"xmlns:gba="uri:3gpp-gba"xmlns:xs="/2001/XMLSchema"><xs:complexTypename="tExtension"><xs:sequence><xs:anyprocessContents="lax"minOccurs="0"maxOccurs="unbounded"/></xs:sequence></xs:complexType><!--definitionoftherootelementcontainingB-TIDandkeylifetime--><xs:complexTypename="bootstrappingInfoType"><xs:sequence><xs:elementname="btid"type="xs:string"/><xs:elementname="lifetime"type="xs:dateTime"/><xs:elementname="Extension"type="tExtension"minOccurs="0"/></xs:sequence></xs:complexType><!--therootelement--><xs:elementname="BootstrappingInfo"type="gba:bootstrappingInfoType"/></xs:schema>消息舉例：HTTP/1.1200OKServer:BootstrappingServer;Release-6Authentication-Info:qop=auth-int,rspauth="6629fae49394a05397450978507c4ef1",cnonce="6629fae49393a05397450978507c4ef1",nc=00000001Date:Expires:Thu,08Jan200410:23:17GMTContent-Type:application/vnd.3gpp.bsf+xmlContent-Length:(...)<?xmlversion="1.0"encoding="UTF-8"?><BootstrappingInfoxmlns="uri:3gpp-gba"><btid>user@</btid><lifetime>2004-05-28T13:20:00Z</lifetime></BootstrappingInfo>SG_Retrieve消息SG_Retrieve.REQ消息發(fā)送方向：終端－>手機電視業(yè)務平臺消息格式如下：GET<RequestURI>HTTP/1.1Host:Content-Length:User-Agent:Date:Accept:RequestURI： /?requesttype=sg_retrieveHost： 手機電視業(yè)務平臺的域名及端口Content-Length： 表明了消息體長度；User-Agent： 表明了客戶端的信息；Date： 發(fā)起請求的日期、時間Accept： 終端可以接收的響應消息的媒體類型SG_Retrieve.RES消息發(fā)送方向：手機電視業(yè)務平臺－>終端消息格式如下：HTTP/1.1200OKServer:Content-Type:Content-Length:Date:Expires:<payload>Server：服務器軟件信息Content-Type：application/vnd.oma.bcast.sgduContent-Length：消息體長度；Date

：響應的日期、時間；<payload>：消息體中包含了一個XML文檔，其中包含SG信息。<payload>格式參見《手機電視業(yè)務指南規(guī)范》[12]。Subscribe消息Subscribe.REQ消息發(fā)送方向：終端－>手機電視業(yè)務平臺。消息格式如下：POST<RequestURI>HTTP/1.1Host:Content-Type:Content-Length:User-Agent:Date:Accept:Referrer:<payload>RequestURI： /?requesttype=registerHost： 手機電視業(yè)務平臺的域名及端口Content-Type： application/mbms-register+xmlContent-Length： 表明了消息體長度；User-Agent： 表明了客戶端的信息；Date： 發(fā)起請求的日期、時間Accept： 終端可以接收的響應消息的媒體類型<payload>：消息體中包含一個XML文檔。XMLSchema參見3GPP

TS

26.346[7]中ServiceProtectionRegistrationFormat。Schema中的“serviceID”的值為業(yè)務訂購對應的PurchaseItemID值。Subscribe.RES消息發(fā)送方向：手機電視業(yè)務平臺－>終端消息格式如下：HTTP/1.1StatusCodeServer:Content-Length:Date:StatusCode: HTTP響應狀態(tài)碼。如果業(yè)務訂購成功，狀態(tài)碼為200OK；如果訂購不成功，狀態(tài)碼為400。Server： 服務器軟件信息Content-Length：消息體長度；Date

： 響應的日期、時間；SK_Retrieve消息SK_Retrieve.REQ消息發(fā)送方向：終端－>手機電視業(yè)務平臺。消息格式如下：POST<RequestURI>HTTP/1.1Host:Content-Type:Content-Length:User-Agent:Date:Accept:Referrer:<payload>RequestURI： /?requesttype=msk-requestHost： 手機電視業(yè)務平臺的域名及端口Content-Type： application/mbms-msk+xmlContent-Length： 表明了消息體長度；User-Agent： 表明了客戶端的信息；Date： 發(fā)起請求的日期、時間Accept： 終端可以接收的響應消息的媒體類型<payload>：消息體中包含一個XML文檔。XMLSchema參見附件。（參見3GPP

TS

26.346[7]中MSKRequestFormat。Schema中包含keyDomainID和MSKID。增加KV字段。）對于終端主動請求方式，終端從廣播網絡的節(jié)目流消息中獲得業(yè)務密鑰標識（MSKID）。對于網絡主動推送方式，終端從Notify消息中獲得業(yè)務密鑰標識（MSKID）和（或）業(yè)務密鑰有效期（KV）。SK_Retrieve_Unauthorized消息發(fā)送方向：手機電視業(yè)務平臺－>終端。消息格式如下：HTTP/1.1401UnauthorizedServer:Date:WWW-Authenticate:Digestrealm,nonce,opaque,algorithm,qop,Server： 手機電視業(yè)務平臺信息Date： 響應發(fā)送的時間信息www-Authenticate頭包含的屬性參數參數類型長度說明Realm“String”Variable這個值分兩部分組成，以@符號分開，前面一半是3GPP-bootstrapping,標識服務器希望終端使用Ks_ext_NAF密鑰作為密碼在驗證時使用，@符號后面是手機電視業(yè)務平臺的域名。Nonce“string”variable服務器指定的一個值，發(fā)送給終端后，終端需要使用該值生成responceOpaque“string”variable服務器指定的值，終端在響應中需要原文返回AlgorithmStringvariable默認使用MD5Qop“qop-vale”variable默認使用auth-intSK_Retrieve_Authorization_Request消息發(fā)送方向：終端－>手機電視業(yè)務平臺。消息格式如下：POST<requestURI>HTTP/1.1HostContent-TypeContent-LengthUser-AgentDateAcceptRefererAuthorization:Digest

username,

realm,

nonce,

qop,

nc,

cnonce,

response,

opaque,

algorithm<payload>RequestURI： /?requesttype=msk-requestHost： 手機電視業(yè)務平臺的地址及端口Content-Type： application/mbms-msk+xmlContent-Length：表明了消息體長度；User-Agent： 表明了客戶端的信息。Date：發(fā)起請求的日期、時間Accept：終端可以接收的響應消息的媒體類型Authorization頭中的屬性參數：參數類型長度說明Username“string”variableUsername使用B-TIDRealm“string”variable這個值分兩部分組成，以@符號分開，前面一半是3GPP-bootstrapping,標識服務器希望終端使用Ks_ext_NAF密鑰作為密碼在驗證時使用，@符號后面是手機電視業(yè)務平臺的域名。Nonce“string”variable服務器指定的一個值，終端需要使用該值結合username（即B-TID），password（即Ks_ext_NAF）及相關參數生成response，服務器根據response驗證用戶，驗證通過進行后續(xù)處理。終端和服務器端對參數的處理參考RFC2617文檔。QopQop-valuevariable該消息的qop，如果服務器發(fā)送的wwwAuthenticate消息頭中包含該參數，則終端返回的消息也應該包含該參數，默認使用auth-intNc十六進制數8Noncecounter，終端指定的值，對包含同一個nonce值的請求進行計數，當服務器發(fā)送的wwwAuthenticate消息頭中含有qop時，終端必須指定該值。cnonce“string”variable如果服務器發(fā)送的WWWAuthenticate消息頭中的qop=auth或者auth-int,則終端需要指定的該值，服務器需要使用該值生成rpsauth值，以便終端驗證服務器的合法性。Cnonce的使用參照RFC2617文檔Response“十六進制數”32Reponce=MD5[MD5(username:realm:password):nonce:nc:cnonce:qop:MD5(method:URI)]終端計算該值時username是B-TID，password是Ks_ext_NAFopaque“string”variable服務器指定的值，如果服務器在發(fā)送的盤問中攜帶該值，終端必須在響應中原文返回該值algorithmstringvariable默認使用MD5算法<payload>：消息體中包含一個XML文檔。XMLSchema與SK_Retrieve.REQ的payload同。SK_Retrieve.RES消息發(fā)送方向：手機電視業(yè)務平臺－>終端。消息格式如下：HTTP/1.1200OKServer:Content-Type:Content-Length:Date:Expires:Authentication-Info:qop,rspauth,cnonce,nc<payload>Server： 手機電視業(yè)務平臺信息；Content-type：application/mbms-msk+xmlContent-Length：消息體長度；Date： 發(fā)出消息的日期和時間Expires： 消息失效時間，終端根據該服務器指定的時間判斷消息是否過期Authentication-info：包含的參數如下參數類型長度說明qopqop-valeVariable響應消息的qop，默認使用auth-intrspauth“string”Variable服務器使用和終端生成responce相同的方式生成的值，用于終端對服務器的認證，該值只在終端發(fā)送的請求中的Authorization頭中qop=auth或者auth-int時生成并在響應消息中返回給終端，計算rspauth時Username是服務器保存的B-TID，password是服務器保存的Ks_ext_NAF，cnonce和nc是服務器欲回復的那個終端發(fā)來的請求中攜帶的這兩個參數的值cnonce“string”Variable終端指定的一個值，該值只在終端發(fā)送的請求中的Authorization頭中qop=auth或者auth-int時，服務器才需要按照原文返回nc十六進制數8終端指定的一個值，該值只在終端發(fā)送的請求中的Authorization頭中qop=auth或者auth-int時，服務器才需要按照原文返回<payload>：消息體為MIKEY數據。具體結構參見附件。Notify消息消息發(fā)送方向：手機電視業(yè)務平臺—>終端目的端口號：16001短消息內容格式：SKID=<業(yè)務密鑰標識>

;KVF=<業(yè)務密鑰有效期起始值>

;KVT=<業(yè)務密鑰有效期終止值>

;ADDR=<手機電視業(yè)務平臺IP地址>

;例：SKID=47389

;KVF=12342

;KVT=12396

;ADDR=55

;短消息內容采用7比特編碼終端接收到這條短消息后，由客戶端進行解析，得到業(yè)務密鑰標識，業(yè)務密鑰有效期，獲取業(yè)務密鑰的手機電視業(yè)務平臺IP地址。手機電視業(yè)務平臺與HLR之間的接口接口協(xié)議總體結構手機電視業(yè)務平臺與HLR之間的接口消息為MAP接口消息。接口協(xié)議描述在終端進行GBA初始化過程中，歸屬地手機電視業(yè)務平臺（BSF模塊）通過與歸屬HLR交互，獲得用戶鑒權元組。接口協(xié)議流程描述參見“GBA初始化流程”。每次當BSF中沒有或者僅剩余1組AV時將會觸發(fā)本流程。BSF每次向HLR中請求的鑒權元組，都保存在BSF中。當BSF中保存的AV僅剩一組時，BSF應向HLR發(fā)起請求過程。BSF每次向HLR請求指定數目的AV（數目可配置，默認為五組），并且進行存儲。每次GBA初始化時，使用一組AV，之后將該組AV刪除。異常情況處理如果GBA初始化不成功，BSF也將刪除該組AV。消息編碼定義MAP-OPEN業(yè)務流程和消息編碼定義此業(yè)務用于手機電視業(yè)務平臺（的BSF模塊）與HLR之間建立一MAP對話。該業(yè)務是確認型業(yè)務，以表1中所示業(yè)務原語確認。（參見3GPP29.002

[10]）表1MAP—OPEN業(yè)務的業(yè)務原語參數請求指示響應確認應用上下文名目的地地址目的地參考起源地址起源參考專用信息響應地址結果拒絕原因提供者錯誤MMUUUUM(=)M(=)C(=)OC(=)C(=)UUUMCC(=)C(=)C(=)M(=)C(=)O應用上下文名：該參數表示所建立的應用上下文類型。如果對話被接受，則返回被接收的應用上下文名。該參數給出所支持的最高版本以防對話被拒絕。應用上下文名版本使用的操作infoRetrievalContextv2sendAuthenticationInfo目的地地址：一個有效的SCCP地址表示了目的地同層實體。在具體實現(xiàn)時，在指示中，該參數也可隱含在相關的業(yè)務接入點中。目的地參考： 無起源地址：一個有效的SCCP地址指明了MAP對話的請求者。在具體實現(xiàn)時，在請求中，該參數也可隱含在相關的原語中的業(yè)務接入點中。起源參考： 無專用信息：無響應地址：無結果：該參數指出對話是否被同層所接受。拒絕原因：此參數只有在結果參數指出對話被拒絕時才出現(xiàn)。它可取下列值：—