GTP'

本頁使用了標題或全文手工轉換
維基百科,自由的百科全書

GTP'(GTP prime)是一個用於GSMUMTS通信網絡的基於IP網絡的協議。它可以使用UDPTCP的傳輸。儘管GTP'協議的消息結構與GTP相同(包括控制面的GTP-C和用戶面的GTP-U),它仍是一個獨立協議。GTP'協議使用UDP/TCP端口3386。[註 1]

GTP'的功能是在GSM、UMTS和LTE核心網中將計費數據從計費數據功能(CDF,Charging Data Function)傳輸到計費網關功能(CGF,Charging Gateway Function)。計費數據功能是對「計費」這一功能的抽象,以具體網元為例,通常是GGSN或SGSN等。而計費網關功能通常是一台中心服務器,收集各網元的計費數據,再統一傳輸給網絡運營商的計費中心(billing center)最終生成賬單。

在3GPP定義的GPRS核心網Ga接口上使用的是GTP'協議。

GTP'重用了GTP協議的諸多方面,然而在3GPP TS 32.295中卻描述為「僅僅部分重用了GTP協議的控制面」[1]。GTP'定義了與GTP不同的消息頭結構、獨有的消息類型、信元,以及一整套防止計費數據丟失或重複計算的機制。GTP'協議所傳輸的計費數據記錄英語Charging_data_record(英語:CDR,Charging Data Record)以ASN.1協議編碼[1]

消息頭結構[編輯]

GTP'消息頭結構如下。

+ Bits 0-2 3 4 5 6 7 8-15 16-31 32-47
0 版本號
Version
協議類型
PT [0]
保留
Reserved
頭長度
Hdr len
消息類型
Message Type
消息長度
Length
序列號
Sequence Number
版本號(Version)
長度為3比特。與GTP協議的這一字段含義相同。
協議類型(Protocol Type (PT))
長度為1比特。對GTP'協議來說取值必須為0。取值為1表示是GTP協議。
保留(Reserved)
長度為3比特,保留不用。取值必須全為1。
頭長度(Header Length (Hdr len))
長度為1比特。當版本號取值為0時有意義,此時本字段取值為0表示消息頭長度為20字節,取值為1表示消息長度為6字節。當版本號不為0時此位取值必須為0。
消息類型(Message Type)
長度為8比特,其值表示該GTP'消息的類型。
消息長度(Length)
長度為16比特,其值表示該GTP'消息體長度,不包括消息頭本身。
序列號(Sequence Number)
長度為16比特,表示該GTP'消息的序號,用於檢測消息丟失或重複。

消息類型[編輯]

GTP'協議重用了GTP協議的Version Not Supported、Echo Request和Echo Response這3種消息,此外還定義了如下3對消息。

  • Node Alive Request/Response
  • Redirection Request/Response
  • Data Record Transfer Request/Response

Node Alive Request/Response[編輯]

Node Alive消息對用於通知其他網元,本網元已經正常工作。Node Alive Request在網元啟動完成時發送,與Echo消息對所提供的通常維60秒間隔的握手機制相比,該消息對能夠及時通知對端網元繼續之前中斷的傳輸。Node Alive Request也可以用於將其他網元的狀態恢復通知給對端網元。

在GTP' version 2中,Node Alive Request支持IPv6地址。

Redirection Request/Response[編輯]

Redirection消息對可以用於

  1. 由CGF通知CDF,另其將CDR發送給另外的CGF。可用於CGF因維護或發生故障停止服務的場景。
  2. 由CGF通知CDF,自己與一個下游網元之間失去連接。

與GTP提供的Echo機制相比,Redirection消息對的好處是,CDF能從Redirection Request消息中得到CGF停止服務的直接或間接的原因。

Data Record Transfer Request/Response[編輯]

Data Record Transfer消息對提供了對CDR的可靠傳輸機制。

Data Record Transfer Request[編輯]

Data Record Transfer Request可以有以下4種功能。

  1. 發送數據記錄(Data Record):該消息可以攜帶0條至數條CDR。CDR應以ASN.1編碼,通常使用BER英語X.690#BER_encoding編碼規則,也可以使用PER編碼規則。
  2. 發送「可能重複」(possibly duplicated)的數據記錄:該消息可以攜帶1條至數條已經向其他CGF發送過的CDR。
  3. 取消數據記錄:該消息通知一個CGF從其「可能重複」緩存中清除1條或多條CDR。
  4. 釋放數據記錄:該消息通知一個CGF處理(使之生效)1條或多條CDR,並從「可能重複」緩存中移除。

Data Record Transfer消息對提供了一套防止丟失或重複計算CDR的機制。其大致機理為,CDF為每一條CDR編制序列號,CGF必須在Data Record Transfer Response消息中逐一對每一個序列號進行確認,未得到確認的CDR將被重傳。正常的CDR在被收到後會被轉存到非易失性存儲設備(例如硬盤)中,但重傳的CDR會被標記為「可能重複」,CGF接收到這樣的CDR,會存入一個專用的隊列中。只有得到CDF的再度確認,才會寫入非易失性存儲設備。數據記錄。此機制細節可以參看3GPP TS 32.295。

發送數據記錄時可以攜帶0條CDR。這使得在CGF重新恢復正常後,CDF可以向CGF發送Data Record Transfer消息,只攜帶CDR的序列號但不攜帶CDR,以獲取這些CDR在CGF側的狀態。

Data Record Transfer Response[編輯]

該消息攜帶對CDR傳輸和處理結果的確認。協議允許CGF在1條Data Record Transfer Response中確認多條Request消息攜帶的CDR以減少傳輸,但必須在CDF所指定的超時時長之內回復。

對每個CDR的確認都附帶一個原因值。在負載過高時,CGF可以通過特定的原因值拒絕處理CDR,從而使CDF選擇其他CGF來處理。

注釋[編輯]

  1. ^ GTP'協議的Request消息發給端口3386(也可以配置為其他端口),而發送方的端口是本地分配的;Response消息的發送、接受方端口號與Request消息的相反。[1]GTP協議的Request消息同樣允許本地分配發送方端口號,[2]但通常會使用與接收方相同的知名端口號2123/2152,因為可以用TEID(Tunnel Endpoint IDentifier)來區分不同的tunnel。GTP'協議沒有TEID,所以常使用不同的發送方端口號。

參考文獻[編輯]