在SCCP協議中，消息都是遵循上面描述的固定結構。對某一條具體的消息，比如CR(conneetion qequest)，在Q.713協議中對消息中包含的參數做了規定[5]，如表2所示。

表2　SCCP CR消息參數表

SCCP消息中消息類型，必選固定部分參數和必選可變部分參數都是按照固定的順序規定好的，而可選部分參數的情況并不固定，消息中只規定了可能包含的可選參數，但對可選參數在實際消息中是否出現以及出現的順序并沒有說明。

在編寫解碼函數的程序時，由于SCCP協議最底層的解碼單位是參數級別，即像Message type，Source local reference和Protocol class等參數，各自都有對應的參數解碼函數，因此對于消息類型參數，必選固定部分參數，必選可變部分參數，只要按照順序調用參數解碼函數就可以完成解碼，真正復雜的是對可選參數的處理，因為消息定義中的可選參數在實際消息中是否出現以及參數出現的順序是不固定的，唯一確定的是，可以通過可選部分參數指針找到可選部分參數開始的位置，然后通過消息總長度減去固定部分長度得到可選部分長度，最后再根據可選參數部分的結構通過循環處理的方式進行解碼，每次循環處理的過程是先判斷可選參數的類型，然后調用相應的參數解碼函數。下面用一個流程圖來說明CR消息的解碼過程，此過程可以推廣到所有其他SCCP消息的解碼，如圖4所示。

圖4　SCCP協議CR消息的解碼流程圖

3、實際測試中的SCCP消息組裝問題

網絡中的SCCP消息長度一般在100個字節內，SCCP消息需要封裝上層RANAP或者RNSAP的數據，而上層數據通常不會很長，一條SCCP消息完全可以容納，但在少數情況下，上層數據需要分段由幾條SCCP消息中傳輸，而多條SCCP消息再分散在底層的ATM信元中傳送。這個現象從邏輯上是容易理解的，但從數據分析的角度，尤其是從數據接收端的角度來看，處理就要復雜很多，因為盡管數據分段的情況相對較少，但是信令分析注重消息解析的準確性和信令流程的連貫性，為了達到這2個要求，就要保證接收端能夠準確完成數據的組裝，在此基礎上，對SCCP層的分析以及更高層如RANAP協議的分析才能夠保證。

在SCCP協議的消息中，絕大部分都包含data或longdata參數，這2個參數表示SCCP的用戶數據(service data unit，SDU)，也叫做SCCP上層協議的協議數據單元(protocol olata unit，PDU)。SCCP的大多數消息都包含數據參數，從而加大了獲取PDU的難度，另外，消息類型的不同導致獲取的方法也不同，包含Data參數的消息分類如表3所示。

表3　包含Data參數的消息分類表

　　當調用SCCP協議模塊的獲取上層PDU函數時，首先判斷消息類型，如果不在

以上消息類型中，則不存在用戶數據，那么僅僅完成解碼即可;如果是以上消息類型中的一種，那么就需要調用相應的函數進行獲取SDU的操作。由于包含用戶數據的消息比較多，為了處理方便和邏輯清晰，在模塊實現時為表3中的消息定義了各自的函數。

表3中有兩列內容分別是輔助參數和它們的存在性。輔助參數是指在相應消息中對于獲取SDU有幫助的參數，而存在性就表示該輔助參數在相應消息中的存在可能，F和V表示一定存在，0表示可能存在。輔助參數的作用主要是用來告知消息中包含的Data是完整的還是需要分段傳送的，如果完整，那么取得數據后函數就把PDU數據返回;否則要對來自多條SCCP消息的多個Data進行組裝。在表3中用A，B，C，D對消息處理進行了分類，每個類型代表一種處理的復雜程度如表4所示。

表4　獲取SDU分析表a

根據獲取Data數據的復雜程度，把相應函數分為4類。每類函數根據處理的復雜程度，都需要輔助函數的支持，例如，類型2中對DT1和DT2的處理，這2條消息中都有參數包含more data indicator字段，其作用是指示本條數據消息后面是否有屬于同一個SDU的數據，因此該參數是DT1和DT2消息獲取數據的重要操作依據。對于其他類型的函數，輔助參數起著同樣的作用，另外個別輔助參數本身是可選的，如類型4函數中的輔助參數segments，因此在類型4函數處理時需要判斷的條件就很多，首先需要知道segments參數是否存在，存在的話才有組裝的可能，不存在的話說明數據不需要組裝。4類函數對參數的需要性如表5所示。

表5　獲取SDU分析表b