【文章內容簡介】 GSM 網(wǎng)絡中引入 CAMEL 業(yè)務后的功能模型見圖 1。gsmSSF gsmSSF圖 1 第二階段 CAMEL 業(yè)務的功能結構HLR gsmSCFGMSC MSC/VLRMAPMAPMAPCAPCAPMS歸屬網(wǎng)絡gsmSRFCAPMAP詢問網(wǎng)絡 拜訪網(wǎng)絡3 / 89 各種物理配置情形 gsmSSF 功能通常放在 MSC 或 GMSC。 情形 1，到智能外設 IP 有直接路徑 其中 IP 的 gsmSRF 通過 ISUP 連接到 MSC/GMSC 中的 gsmSSF, gsmSCF 通過 直接與 gsmSRF 相連。 情形 2a，通過具有中繼功能的輔助 SSF 連接到 IP；IP 與輔助 SSF 合設 MSC/GMSC 中的 gsmSSF 通過 ISUP 連接到 MSC/GMSC 中的輔助 gsmSSF，中繼接入 gsmSRF。gsmSCF 通過七號信令直接接入到輔助 gsmSSF。gsmSRF 與輔助 gsmSSF 合設，采用內部接口。情形 2b，通過具有中繼功能的輔助 SSF 連接到 IP，IP 與輔助 SSF 不合設 MSC/GMSC 中的輔助 gsmSSF 通過 ISUP 連接到 MSC/GMSC 中的 gsmSSF。gsmSCF通過七號信令直接接入到輔助 gsmSSF。gsmSRF 在 IP 中，連接到輔助 gsmSSF。初始gsmSSP 采用 ISUP 或 DSS1 通過輔助 gsmSSF 中繼接入 gsmSRF。輔助 SSP 與 IP 之間采用ISUP情形 3，有中繼功能的情況下連接到 IP；IP 與 SSF 合設。SCPSCPgsmSCFgsmSSF/gsmCCF gsmSRF初始SSP ISUPIPgsmSSF/gsmCCF輔助 SSPgsmSCFgsmSSF/gsmCCF gsmSSF/gsmCCFSCP初始 SSPISUP IPgsmSRF輔助 SSPSSPISUP IP gsmSRFgsmSSF/gsmCCFgsmSCF4 / 89 IP 中的 gsmSRF 連接到 gsmSSF，采用內部接口由 gsm SSF 中繼接入 gsmSCF 。gsmSSF 與 gsmSRF 合設。情形 4，有中繼功能的情況下連接到 IP；IP 與 SSF 不合設。 IP 中的 gsmSRF 連接到 gsmSSF，采用 ISUP 或 DSS1 由 gsm SSF 中繼接入 gsmSCF 。 5 CAP的基本規(guī)定 CAP的規(guī)程結構 CAP 是遠端業(yè)務操作單元(ROSE)用戶規(guī)程。CAP 的規(guī)程結構如圖 2。 PE 與 PE 之間或者為單個交互作用，或者為多個交互作用。 在情況 a 中，SACF 在使用應用業(yè)務單元(ASE)時提供并列的功能，包括 ASE 所支持gsmSCFgsmSSF/gsmCCF gsmSRFASE’sTCAPSACFSAOASE’sTCAPSACFSAO ASE’sTCAPSACFSAOMACFSCP應用處理SSP多個并列的交互作用(b)IPSCCPMTPgsmSCFgsmSSF/gsmCCFgsmSRFSCCPMTP初始 SSP應用處理ISUP 或 DSS1單個交互作用(a)IP圖 2 CAP 的規(guī)程結構內部接口5 / 89的操作的順序(基于所接收原語的順序 )。單個相關目標(SAO)表示在一對 PE 之間通過單個交換作用所采用的 SACF 加上一組 ASE。在情況 b 中，MACF 在幾個 SAO 中提供并列的功能，每個 SAO 與遠端 PE 中的一個 SAO 交互。每個 ASE 支持一個或多個操作。 應用上下文(AC)協(xié)商機制允許兩個通信實體準確地表示它們的能力以及對接口能力的要求。因此允許通過能力集演化。 如果一對通信 FE 不支持特定 AC 的指示，應支持預先安排的應用上下文。 CAP尋址 CAP 的尋址采用 《國內 信令方式－信令連接控制部分(SCCP)》提供的 0 類或 1類業(yè)務。采用 GT 尋址，CAP 的子系統(tǒng)號(SSN) 為 0000,0101。 SCCP 的各類業(yè)務 (0 類或 1 類)取決于應用。1 類業(yè)務在接收到對端的響應(TR_CONTINUE 或 TREND)之前可以發(fā)送多個 TCAP 消息(TR_CONTINUE) 到對端。不能使用 RESULT－NL。然而如果應用程序使用 RESULT－NL(且需要分段)，應用程序應設置為 1 類業(yè)務。 根據(jù) ，TC 對段數(shù)沒有限制。然而如果 TC 用戶確定所使用的網(wǎng)絡業(yè)務支持用戶數(shù)據(jù)的分段和重組，不必使用 TC－RESULT －NL(RR_NL)且盡量避免。如果應用程序請求的話，可以使用 return 選項。 LegID的定義和使用 在 gsmSCF 與 gsmSSF 之間交換的 LegID 有兩類： －發(fā)送側 LegID，和 －接收側 LegID 發(fā)送側 LegID 用于 gsmSCF 至 gsmSSF 的操作中，接收側 LegID 用于 gsmSSF 至gsmSCF 的操作中。 LegID 的分配：對于所有操作均包括一個 LegID ； －LegID＝1 指主叫用戶，尤其當 啟動 DP 發(fā)往 gsmSCF 時呼叫中涉及的呼叫方。 －LegID＝2 指被叫方，呼叫中作為 連接或繼續(xù)操作結果生成的呼叫方。 CAP的兼容性機制 CAP 的兼容性機制主要有如下兩類： 與 INAP 兼容。 當 CAP 與 INAP 互通時，如果接收到 INAP 的操作，但該操作不是 CAP 的一部分或者 CAP 中有此操作但不包括該參數(shù)： －對于未知的操作和參數(shù)，gsmSSF 應采用正常的差錯處理程序。 －除了啟動 DP 操作中的參數(shù)外，對于未知的參數(shù)和操作，gsmSCF 應采用正常的差錯處理程序。對于 INAP 中指定的啟動 DP 中的所有參數(shù)，gsmSCF 均應知道，CAP 中不包括的參數(shù)應該忽略。 CAP 中增加的標簽指定為 50 以上。 與 CAP 今后的版本兼容 －對現(xiàn)有 CAP 改變較大時：即為了支持所需的 CAMEL 業(yè)務，必須有較大的功能改變時。當純粹增加新功能時，如果某功能實體不支持增加的功能，可以不提供所需的CAMEL 業(yè)務。如果是在現(xiàn)有功能上修改時，兩個功能實體應就功能變化達成共識。這種6 / 89改變需要新的 AC。 －對現(xiàn)有 CAP 改變較小時：即為了支持所需的 CAMEL 業(yè)務，不需要進行功能的改變時。如果是對現(xiàn)有功能的修改，既可以用舊的變量也可以用修改的變量執(zhí)行相關功能。如果是純粹增加的功能，可以不去執(zhí)行。這種情況不需要新的 AC。 SACF/MACF規(guī)則 TCAP 應用上下文(AC) TCAP AC 協(xié)商規(guī)則要求被提議的 AC，如果能夠接受，應在第一個后向消息中返回。如果 AC 不可接受，且 TC 用戶不希望繼續(xù)該對話，可以向始發(fā)者提供一個替換 AC 以便開始一個新的對話。 注：如果 gsmSSF 提供的 AC，gsmSCF 不能接收，不返回替換 AC。如果發(fā)送給gsmSCF 的 AC 不可接收，一般是在提供的用戶數(shù)據(jù)中有差錯或者 gsmSSF 中的差錯。 操作的串/并行執(zhí)行 有時需要區(qū)別一個操作是以串行還是并行(同步) 的方式執(zhí)行?？赡芡降牟僮饔校? －計費操作可以與其它任何操作同步執(zhí)行。 需要同步的操作應放置在同一個 TCAP 消息中。有些操作要等到其它操作執(zhí)行到一定程度或完成以后再執(zhí)行。PE(通常是 SCP)通過在兩個不同的消息中發(fā)送該操作進行控制。 這并不意味著同一消息中的操作都要同時執(zhí)行，只是需要的時候才同步執(zhí)行。6 CAP的抽象語句本節(jié)規(guī)定 CAP 的抽象語句。CAP 中所使用的 ISUP 和 DSS1 參數(shù)，參數(shù)值編碼的定義見 ISUP 或 DSS1。DSS1/ISUP 定義的參數(shù)標識由 CAP 定義的參數(shù)標識替代。應用于抽象語法的編碼規(guī)則為 基本編碼規(guī)則(BER)，見 ， 。附加的編碼見 ISUP 和 DSS1。有些數(shù)據(jù)類型來自于 CS1 INAP 和 MAP。 操作宏中操作的類別如下：第 1 類：在 操作宏的定義中出現(xiàn)結果和差錯。第 2 類：在 操作宏的定義中僅出現(xiàn)差錯。第 3 類：在 操作宏的定義中僅出現(xiàn)結果。第 4 類：在 操作宏的定義中結果和差錯均不出現(xiàn)。CAP 的抽象語法由幾個描述操作，差錯和相關數(shù)據(jù)類型的 模塊組成。包含 CAP 類型定義的模塊有 CAP－操作，CAP－差錯，CAP－數(shù)據(jù)類型，CAP－碼，CAP－類別。 操作類型CAPOperations {ccitt(0) identifiedanization(4) etsi(0) mobileDomain(0) gsmNetwork(1) modules(3) capoperations(50) version2(1)} 本模塊包含 CAP V2操作的類型定義。DEFINITIONS ::=BEGINIMPORTSOPERATIONFROM TCAPMessages {ccitt remendation q 773 modules(2) messages(1) version2(2)}7 / 89 差錯類型Cancelled,CancelFailed,ETCFailed,ImproperCallerResponse,MissingCustomerRecord,MissingParameter,ParameterOutOfRange,RequestedInfoError,TaskRefused,UnavailableResource,UnexpectedComponentSequence,UnexpectedDataValue,UnexpectedParameter,UnknownLegID,SystemFailureFROM CS1Errors {ccitt(0) identifiedanization(4) etsi(0) inDomain(1) inwork(1) modules(0) cs1errors(1) version1(0)} CAP 參量類型ApplyChargingArg,ApplyChargingReportArg,AssistRequestInstructionsArg,CallInformationReportArg,CallInformationRequestArg,CancelArg,ConnectArg,ConnectToResourceArg,EstablishTemporaryConnectionArg,EventReportBCSMArg,FurnishChargingInformationArg,InitialDPArg,PlayAnnouncementArg,PromptAndCollectUserInformationArg,ReceivedInformationArg,ReleaseCallArg,RequestReportBCSMEventArg,ResetTimerArg,SendChargingInformationArg,SpecializedResourceReportArgFROM CAPDataTypes {ccitt(0) identifiedanization(4) etsi(0) mobileDomain(0) gsmNetwork(1) modules(3) capdatatypes(52) version2(1)}。8 / 89 CAP 操作的類型定義 gsmSCFgsmSSF 操作ActivityTest ::= OPERATIONRESULT 傳送方向 : gsmSCF gsmSSF, 定時器 : Tat 這個操作用來檢查 gsmSCF 和 gsmSSF 之間的關系是否仍然存在。如果關系仍然存在， 則 gsmSSF 將響應。如果 gsmSCF 沒有收到響應，就認為 gsmSSF 由于某種原因出現(xiàn) 了故障， gsmSCF 將采取適當?shù)膭幼?。ApplyCharging ::= OPERATIONARGUMENTApplyChargingArgERRORS {MissingParameter,UnexpectedComponentSequence,UnexpectedParameter,UnexpectedDataValue,ParameterOutOfRange,SystemFailure,TaskRefused, UnknowLegID} 傳送方向 : gsmSCF gsmSSF, 定時器 : Tac gsmSCF 使用本操作和 gsmSSF CSE 中控制呼叫時長的計費機制進行相互作用。 ApplyChargingReport ::= OPERATIONARGUMENTApplyChargingReportArgERRORS