GPRS隧道協議
| 互聯網協定套組 |
|---|
| 應用層 |
| 傳輸層 |
| 網絡層 |
| 連結層 |
GPRS隧道協議（英語：GPRS Tunnelling Protocol，簡稱：GTP）是一組基於IP的通信協議，用於在GSM、UMTS和LTE網絡中承載GPRS（通用分組無線業務，英語：General Packet Radio Service）。
GTP協議目前有3個版本：version 2使用於LTE核心網；version 1使用於GSM和UMTS網絡，也應用於LTE網絡中以傳輸用戶面數據；version 0是早期版本，被1999年標準化的version 1替代[1]。
GTP協議的用途
GSM和UMTS網絡
GPRS核心網
GTP是GPRS核心網中使用的主要協議。它使得GSM或UMTS網絡的終端能夠在網絡中移動位置，同時能持續的通過同一個GGSN連接到互聯網。為了實現這一功能，GTP協議總是將用戶面數據從用戶位置所屬的SGSN傳輸到它開戶信息所對應的GGSN。
GPRS核心網使用三種 GTP協議。
- GTP-U用於為每個PDP上下文提供一個或多個隧道，用以傳輸用戶數據
- GTP-C用於控制目的，包括：
- GTP'用於從各個GSN傳送計費數據到計費網關功能（CGF，英語：Charging Gateway Function）。
GGSN和SGSN（合稱為「GSN」）在UDP端口2123上監聽GTP-C消息，在端口2152上監聽GTP-U消息。GTP協議通信可以通過GPRS漫遊交換（英語：GPRS Roaming Exchange）發生在不同運營商之間。
計費網關功能（CGF，英文：Charging Gateway Function）在TCP/UDP端口3386上監聽發送自GSN的GTP'消息。核心網發送計費信息到CGF，計費信息至少包含PDP上下文激活次數以及終端用戶傳送的數據量。與GTP-C和GTP-U不同，GTP'協議承載的報文通常只在單個運營商網絡內部使用，因此並不那麼標準化。運營商可以做特殊的配置，使用特別的編碼，甚至使用完全不同的系統來完成計費。
UMTS的核心網和接入網之間（Iu-PS接口）
GPRS核心網和UMTS接入網之間的Iu-PS接口上，用戶面也使用GTP-U協議。然而在控制面上並不使用GTP-C，而是用RANAP協議。GTP-U的隧道在Iu-PS接口上也是以RANAP協議管理的。
LTE網絡
LTE網絡中的GTP協議功能與GSM/UMTS網絡中基本相同。在控制面上LTE網絡使用GTPv2-C，用戶面上使用GTP-U，計費相關功能使用GTP'。
在S1接口（eNodeB和SGW之間）上，用戶面使用GTP-U協議。在接入網X2接口（兩個eNodeB之間）上，用戶面也使用GTP-U協議，控制面使用X2AP。[2][3]
協議特性
所有的GTP變種都有一些共有的特性。消息的結構都是相同的，GTP消息頭在UDP/TCP頭之後。
消息頭
GTP版本1
GTPv1消息頭包含如下的字段：[4]
| + | 0-2 | 3 | 4 | 5 | 6 | 7 | 8-15 | 16-23 | 24-31 | |||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | 版本號（Version） | 協議類型（Protocol type） | 保留（Reserved） | 擴展消息頭標誌位（Extension Header Flag） | 序列號標誌位（Sequence Number Flag） | N-PDU號標誌位（Number Flag） | 消息類型（Message Type） | 總長度（Total length） | ||||||||||||||||||||||||
| 32 | TEID | |||||||||||||||||||||||||||||||
| 64 | 序列號（Sequence number） | N-PDU號（number） | 下一擴展消息頭類型（Next extension header type） | |||||||||||||||||||||||||||||
- 版本（Version）
- 長度為3位，對於GTPv1來說，這個值始終是「1」。
- 協議類型（PT，全稱：Protocol Type）
- 長度為1位，取值為1表示GTP，0表示GTP'。
- 保留（Reserved）
- 長度為1位，保留字段（必須為0）。
- 擴展消息頭標誌位（E，全稱：Extension header flag）
- 長度為1位，標記是否存在一個可選的擴展消息頭字段。
- 序列號標誌位（S，全稱：Sequence number flag）
- 長度為1位，標記是否存在一個可選的序列號字段。
- N-PDU號標誌位（PN，全稱：N-PDU number flag）
- 長度為1位，標記是否存在一個可選的N-PDU號字段。
- 消息類型（Message Type）
- 長度為8位，指示GTP消息的類型。關於消息類型的定義，請參考3GPP TS 29.060第7.1節。
- 總長度（Total Length）
- 長度為16位，指示消息體長度，單位為字節，不包括GTP頭前8位元組的必選字段。
- 隧道端點標識（TEID，全稱：Tunnel endpoint identifier）
- 長度為32位（4個八位元組），用於區分GTP隧道中的不同連接。
- 序列號（Sequence number）
- 可選字段，長度為16位。當E、S或PN位中的任意一個取值為1時，這個字段存在。僅當S位為1時，這個字段必須被解析。
- N-PDU號（N-PDU number）
- 可選字段，長度為8位。當E、S或PN位中的任意一個取值為1時，這個字段存在。僅當PN位為1時，這個字段必須被解析。
- 下一擴展消息頭類型（Next extension header type）
- 可選字段，長度為8位。當E、S或PN位中的任意一個取值為1時，這個字段存在。僅當E位為1時，這個字段必須被解析。
下一擴展消息頭如下：
| + | Bits 0-7 | 8-23 | 24-31 | |||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | 總長度（Total length） | 內容（Contents） | ||||||||||||||||||||||||||||||
| ... | ... | |||||||||||||||||||||||||||||||
| ... | 內容（Contents） | 下一擴展消息頭（Next extension header） | ||||||||||||||||||||||||||||||
- 長度（Length）
- 長度為8位。這個字段指出本擴展消息頭的長度，包括長度（這個字段本身）、內容和下一擴展消息頭字段，以4個八位元組為單位，因此擴展消息頭的長度必須是4的倍數。
- 內容（Contents）
- 擴展消息頭內容。
- 下一擴展消息頭（Next extension header）
- 長度為8位。它指出下一擴展消息頭的類型，取值為0表示不存在下一個擴展消息頭。通過該字段可以實現多個擴展消息頭的串聯。
GTP版本2
它也被稱為「進化版GTP」（evolved-GTP）或「eGTP」。GTPv2-C消息頭包含如下的字段：[5]
| + | Bit 0-2 | 3 | 4 | 5-7 | 8-15 | 16-23 | 24-31 | |||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | 版本號（Version） | 捎帶消息標誌位（Piggybacking flag，簡稱P） | TEID標誌位（T） | 剩餘（Spare） | 消息類型（Message Type） | 總長度（Total length） | ||||||||||||||||||||||||||
| 32 | TEID（只有在T=1時才出現） | |||||||||||||||||||||||||||||||
| 64（有TEID）/32（無TEID） | 序列號（Sequence number） | 剩餘（Spare） | ||||||||||||||||||||||||||||||
注意：不存在GTPv2-U協議。在LTE中的GTP-U仍使用GTPv1-U。
- 版本號：長度為3位，對於GTPv2來說，這個值始終是「2」。
- 捎帶消息標誌位（Piggybacking flag）
- 如果被置為1，則在這條消息後面會有另外一條帶有完整消息頭的GTP消息。協議里具體規定了每種消息可以攜帶的消息類型。
- TEID標誌位（TEID flag）
- 如果被置為1，則TEID字段存在。只有Echo Request和Echo Response消息不攜帶TEID字段。
- 總長度（Total length）
- 包括消息頭和消息體的消息總長度（除去必選字段所在的前4個八位元組）。
連接機制
除了共同的消息結構之外，GTP協議還有一個共同的機制來驗證兩個節點之間的連接。這種機制依靠以下兩種消息實現：
- Echo Request
- Echo Response
每隔60秒，一個網元可以向每個有活躍連接的對端發送一個Echo Request，來確認連接有效。如果對端不回復Echo Response，則它可以被視為宕機，而該活躍連接將被刪除。
各種 GTP協議除了上述2個消息之外，沒有共通的消息類型。[6]也就是說，GTP-C，GTP-U和GTP'基本上是3種獨立的協議。
GTP-C - GTP控制面
GTP-C協議是GTP標準的「控制」部分。當一個簽約用戶請求一個PDP上下文，SGSN將發送一個「創建PDP上下文請求」（Create PDP Context Request）的消息給GGSN，給出該簽約用戶的請求的明細。該GGSN將發送一個「創建PDP上下文響應」（Create PDP Context Response）消息，這個消息會要麼給出被激活的PDP上下文內容，要麼指出一個失敗，及該失敗的原因。版本1和版本2的GTP-C消息使用UDP端口2123。
在LTE核心網中，GTPv2-C協議負責在S1、S5/S8等接口上創建、維持和刪除隧道。它被用於控制面路徑管理（control plane path management）、隧道管理（tunnel management）和移動性管理（mobility management）。它也控制轉發位置變更消息、SRNS上下文、並在LTE的網間切換中創建轉發隧道。
GTP-U - GTP用戶數據隧道
GTP-U是一個比較簡單的基於IP的隧道協議，它允許在各個端點集之間建立多個隧道。UMTS網絡中，每個簽約用戶擁有至少一個隧道。每一個激活的PDP上下文擁有至少一個隧道，當隧道多於1個時，多出來的隧道為特定的服務提供特定的端到端QoS。
每個隧道由一個GTP-U消息中的TEID（隧道端點標識符，{{lang-en|Tunnel Endpoint Identifier}）標識。TEID應當是一個動態分配的隨機數。如果這個隨機數能達到密碼級水平，則可以抵禦一定程度的攻擊。即使這樣，3GPP標準仍然要求所有的GTP流量，包括用戶數據，都應當在安全私有網絡中被發送，不能直接連接到互聯網。GTP-U使用UDP端口2152。
在LTE核心網中，使用GTPv1-U協議在GTP隧道上跨S1、S5/S8等接口上交換用戶數據。UE所收發的IP包被打包在GTPv1-U的包中，並在P-GW和eNodeB之間的各段隧道中傳輸。LTE網絡的X2接口，即eNodeB之間的接口上，用戶面協議使用的也是GTPv1-U[7]。
GTP' - 計費傳輸
GTP'協議被用於向CGF（計費網關功能，英語：Charging Gateway Function）傳輸計費數據。GTP'使用TCP/UDP端口3386。
協議棧
| 應用層協議 |
| IP（用戶） |
| GTP |
| UDP |
| IP |
| 二層（例如, WAN or以太網） |
GTP-U協議棧 |
GTP協議需要被承載在UDP協議上。早期版本GTPv0也允許TCP傳輸。
GTPv0是最早的GTP協議，控制面和用戶面使用相同的端口。
GTPv1於1999年在3GPP TS 29060版本3.3.0中被標準化。它實際上是兩個協議，一個用於控制面（被稱為「GTP-C」），而另一個則用於用戶數據隧道（被稱為「GTP-U」）。
GTP-U在UMTS網絡中也被用於從RNC往SGSN（即Iu-PS接口上）傳送用戶數據。然而，此時控制面使用的是RANAP協議而不是GTP-C。
GTP的歷史版本
GTP的原始版本（版本0）與3G/LTE核心網中使用中的版本1和版本2有顯著的不同：
- 隧道標識符（TEID）是非隨機的；
- 除了IP協議，也支持傳輸X.25協議的數據；
- 所有的功能都使用固定的3386端口（不像在GTPv1中僅僅用於計費）；
- 除了UDP以外，也可以使用TCP協議作為傳輸層；
- 與簽約用戶相關的字段，例如QoS，相對較少。
版本0中的非隨機TEID在有安全性問題：當一個攻擊者對任一漫遊合作夥伴網絡有訪問權限時，或可以找到其它一些方式來遠程地向GPRS骨幹網發送消息包的時候，就可以干擾網絡運行。版本0現在幾乎已完全被版本1所替代。即使這樣，新版本的標準仍聲明，GSN必須支持更舊的版本。但幸運的是，可以用簡單的IP訪問列表來禁止v0使用的3386端口，從而封鎖版本0。
GTP標準化
GTP原本是在ETSI（European Telecommunications Standards Institute）的GSM標準09.60中被標準化的。[8]隨着UMTS標準的創建，它被移動到3GPP。到2005年，3GPP將其做為3GPP標準29.060來維護。GTP'使用相同的消息格式，但是它的使用獨立的標準32.295，並且定義了它所傳輸的計費數據的標準化格式。
TS 29.060的後續版本取消了對GTPv1和v0互聯的支持，因此如果網絡中有GSN只支持v0的話，使用v1協議的其他網元也不會降到v0去配合。
GTPv2（用於EPC，即LTE核心網）在2008年進入起草階段，並在同年12月發佈。使用GTPv1的「版本不支持」機制，GTPv2支持到GTPv1的降級運行，但不提供到GTPv0的降級運行。
參見
參考資料
- ^ 3GPP TS 29.060 V3.3.0 General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp Interface. 1999-12-15 [2016-06-15]. （原始內容存檔於2020-06-22） （英語）.
- ^ 3GPP TS 36.423 Evolved Universal Terrestrial Radio Access Network (E-UTRAN); X2 Application Protocol (X2AP). [2016-07-22]. （原始內容存檔於2016-08-14）.
- ^ 3GPP TS 36.424 Evolved Universal Terrestrial Radio Access Network (E-UTRAN); X2 data transport. [2016-07-22]. （原始內容存檔於2016-07-25）.
- ^ 3GPP TS 29.060 section 6. [2014-10-08]. （原始內容存檔於2008-12-09）.
- ^ 3GPP TS 29.274 section 5. [2014-10-08]. （原始內容存檔於2008-10-11）.
- ^ 3GPP TS 29.060 section 7. [2014-10-08]. （原始內容存檔於2008-12-09）.
- ^ 3GPP TS 36.424 V8.2.0 Evolved Universal Terrestrial Radio Access Network (E-UTRAN); X2 data transport: 6. 2008-06 [2016-06-15]. （原始內容存檔於2020-07-20）.
- ^ Standard: ETSI - 3GPP TS 09.60. 2002-12-11 [2016-06-15]. （原始內容存檔於2016-08-13）.