專利名稱：一種gtp消息傳輸?shù)姆椒把b置的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通訊領(lǐng)域，尤其涉及一種GTP消息傳輸?shù)姆椒把b置。
背景技術(shù)：
GRPS隧道協(xié)議(GPRS Tunneling Protocol, GTP協(xié)議)是一種廣泛應(yīng)用 于GPRS網(wǎng)絡(luò)的網(wǎng)元，如服務(wù)GPRS支持節(jié)點(Serving GPRS Support Node, SGSN),網(wǎng)關(guān)GPRS支持節(jié)點(Gateway GPRS Support Node, GGSN)等之間 的通訊協(xié)議，并將繼續(xù)在演進(jìn)分組系統(tǒng) (Evolved Packet System, EPS)中佳_ 用。附圖1為GTP協(xié)議棧示意圖，從GTP的協(xié)議?？梢钥闯?，GTP協(xié)議底層 采用無連接、不保證可靠性的用戶數(shù)據(jù)包協(xié)議(User Datagram Protocol, UDP 協(xié)議)，而GTP協(xié)議中大多數(shù)控制消息都需要保證可靠性傳輸，對每一個需要 保證可靠性傳輸?shù)腉TP請求消息，協(xié)議中都定義一個相應(yīng)的GTP響應(yīng)消息。 為了發(fā)送節(jié)點能夠匹配GTP請求消息和GTP響應(yīng)消息，GTP協(xié)議中規(guī)定，發(fā) 送節(jié)點為每一個GTP請求消息分配一個序列號(Sequence Number )，發(fā)送節(jié)點 通過源IP地址、源UDP端口號和GTP序列號唯一標(biāo)識一條GTP請求消息， 接收節(jié)點在返回GTP響應(yīng)消息時，GTP響應(yīng)消息的目的IP地址填寫對應(yīng)GTP 請求消息的源IP地址，GTP響應(yīng)消息的目的UDP端口號填寫對應(yīng)GTP請求 消息的源UDP端口號，GTP響應(yīng)消息的GTP序列號填寫對應(yīng)GTP請求消息 中的GTP序列號，通過源IP地址+源UDP端口號+GTP序列號(對GTP響應(yīng) 消息來說是目的IP地址+目的UDP端口號+GTP序列號)的三元組，發(fā)送節(jié)點 可以正確匹配發(fā)送的GTP請求消息和接收的GTP響應(yīng)消息。
在GPRS標(biāo)準(zhǔn)發(fā)展的過程中，又引入了 Iu-Flex等新技術(shù)，這些技術(shù)對 GTP協(xié)議提出了 一種新的應(yīng)用場景即發(fā)送節(jié)點發(fā)送GTP請求消息后，接收到GTP請求消息的中間節(jié)點將其轉(zhuǎn)發(fā)給最終的處理節(jié)點進(jìn)行處理，最終處理 節(jié)點處理GTP請求消息，然后直接向發(fā)送節(jié)點返回GTP響應(yīng)消息，參見附圖 2，
步驟201.源節(jié)點發(fā)送GTP請求消息，消息中設(shè)置源IP地址設(shè)置為源節(jié)點 的IP地址(IP-Source),源UDP端口 (Port—Source)由源節(jié)點分配，GTP序列 號(Sequence)也由源節(jié)點分配；
步驟202.消息達(dá)到中間節(jié)點后，中間節(jié)點向目的節(jié)點發(fā)送該GTP請求消息， 消息中設(shè)置源IP地址設(shè)置為中間節(jié)點的IP地址 (IP—Middle ),源UDP端口 (Port—Middle)按照GTP協(xié)議規(guī)定由中間節(jié)點重新分配，GTP序列號(Sequence) 也從接收到的GTP請求消息中拷貝；
步驟203.目的節(jié)點接收到中間節(jié)點轉(zhuǎn)發(fā)的GTP請求消息后，處理該消息， 直接向源節(jié)點返回GTP響應(yīng)消息，GTP響應(yīng)消息的目的IP地址設(shè)置為源IP地 址(IP—Source )， GTP序列號(Sequence ) 乂九接收到的GTP請求消息中拷貝。 GTP響應(yīng)消息才艮據(jù)目的地址(IP-Source ) 3各由至源節(jié)點。
發(fā)明人在實現(xiàn)本發(fā)明的過程中發(fā)現(xiàn)按照目前GTP協(xié)議規(guī)定，GTP響應(yīng)消 息的目的UDP端口號應(yīng)該填寫為對應(yīng)的GTP請求消息的源端口號，目的節(jié)點在 返回GTP響應(yīng)消息時，GTP響應(yīng)消息的目的UDP端口號為Port-Middle, 而 Port—Middle不一定等于Port-Source,因此GTP響應(yīng)消息到達(dá)源節(jié)點后，或 者導(dǎo)致處理錯誤，或者源節(jié)點根本沒有監(jiān)聽該UDP端口 Port-Middle,而直接 丟棄GTP響應(yīng)消息，導(dǎo)致流程處理失敗。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明實施例提出一種方案，解決了使得在存在中間節(jié)點轉(zhuǎn)發(fā) 的情況下，目的節(jié)點無從得知含源節(jié)點分配的源UDP端口信息的問題。
本發(fā)明實施例提供了一種GTP消息傳輸?shù)姆椒ǎń邮誈TP請求消息，所述GTP請求消息中包含源節(jié)點分配的源UDP端口信息；為所述GTP請求消息 重新分配源UDP端口信息；發(fā)送包含源節(jié)點分配的源UDP端口信息的信元和重 新分配的源UDP端口信息的GTP請求消息。
本發(fā)明實施例又提供了一種GTP消息傳輸?shù)姆椒ǎń邮誈TP請求消 息，所述GTP請求消息中包含源節(jié)點分配的源UDP端口信息；將所述GTP請求 消息的源UDP端口信息設(shè)置為源節(jié)點分配的源UDP端口信息；發(fā)送所述包含源 節(jié)點分配的源UDP端口信息的GTP請求消息。
本發(fā)明實施例又提供了一種GTP消息傳輸系統(tǒng)，包括第一節(jié)點、第二結(jié) 點和第三節(jié)點，其中，第一節(jié)點，用于向第二結(jié)點發(fā)送GTP請求消息，所述GTP 請求消息中包含源節(jié)點分配的源UDP端口信息；第二結(jié)點，用于為所述GTP請 求消息重新分配源UDP端口信息，向第三節(jié)點發(fā)送包含源節(jié)點分配的源UDP端 口信息的信元和重新分配的源UDP端口信息的GTP請求消息。
本發(fā)明實施例又提供了一種源節(jié)點，包括解析單元，用于根據(jù)中間節(jié)點 對應(yīng)的域名解析出所述中間節(jié)點的IP地址；發(fā)送單元，用于向所述解析出的中 間節(jié)點發(fā)送GTP請求消息，所述GTP請求消息中包含所述源節(jié)點分配的源UDP端 口信息的信元和源節(jié)點分配的源UDP端口信息。
本發(fā)明實施例又提供了一種中間節(jié)點，包括接收單元，用于接收GTP請 求消息；分配單元，用于為所述GTP請求消息重新分配源UDP端口信息；發(fā)送 單元，用于發(fā)送包含源節(jié)點分配的源UDP端口信息的信元和重新分配的源UDP 端口信息的GTP請求消息。
本發(fā)明實施例又提供了一種目的節(jié)點，包括接收單元，用于接收GTP請 求消息，所述GTP請求消息中包含源節(jié)點分配的源UDP端口信息的信元和源 UDP端口信息；響應(yīng)單元，根據(jù)所述源節(jié)點分配的源UDP端口信息的信元向源 節(jié)點發(fā)送GTP響應(yīng)消息。
本發(fā)明實施例通過在GTP請求消息添加源節(jié)點分配的源UDP端口信息的
7信元或者中間結(jié)點在轉(zhuǎn)發(fā)GTP請求消息的時候直接將GTP請求消息的源UDP端 口信息設(shè)置為源節(jié)點分配的源UDP端口信息的方式，使得在存在中間節(jié)點轉(zhuǎn)發(fā) 的情況下，目的節(jié)點能夠得知源節(jié)點分配的源UDP端口信息，從而保證了流程 的順利處理。


圖1為GTP協(xié)議棧示意圖2為 一種GTP消息傳輸示意圖3為本發(fā)明實施例提供的 一種GTP消息傳輸?shù)姆椒ㄊ疽鈭D； 圖4為本發(fā)明實施例提供的另一種GTP消息傳輸?shù)姆椒ㄊ疽鈭D； 圖5為本發(fā)明實施例提供的再一種GTP消息傳輸?shù)姆椒ㄊ疽鈭D； 圖6為本發(fā)明實施例提供的又一種GTP消息傳輸?shù)姆椒ㄊ疽鈭D； 圖7為本發(fā)明實施例提供的一種GTP消息傳輸系統(tǒng)示意圖； 圖8為本發(fā)明實施例提供的 一 種源節(jié)點示意圖； 圖9為本發(fā)明實施例提供的 一種中間節(jié)點示意圖； 圖IO為本發(fā)明實施例提供的一種目的節(jié)點示意圖。
具體實施例方式
參見圖3，本發(fā)明實施例提供了一種GTP消息傳輸?shù)姆椒?，包?步驟301.接收GTP請求消息，該GTP請求消息中包含源節(jié)點分配的源 UDP端口信息；
此處接收的GTP消息既可以是源節(jié)點發(fā)送的，也可以是中間結(jié)點發(fā)送的。 步驟302.為所述GTP請求消息重新分配源UDP端口信息； 此步驟中還可以包括判斷接收的GTP請求消息中是否包含源節(jié)點分配的 源UDP端口信息的信元(Information Element);如果接收的GTP請求消息中不 包含源節(jié)點分配的源UDP端口信息的信元，根據(jù)接收的GTP請求消息中包含源 節(jié)點分配的源UDP端口信息在GTP請求消息中添加包含源節(jié)點分配的源UDP端口信息的信元；如果接收的GTP請求消息中包含源節(jié)點分配的源UDP端口信 息的信元，直接進(jìn)入步驟303。
步驟303.發(fā)送包含重新分配的UDP端口信息和源節(jié)點分配的源UDP端口 信息的信元的GTP請求消息。
此處GTP請求消息既可以是發(fā)送給目的節(jié)點的，也可以是發(fā)送給另外一個 中間結(jié)點的。如果是發(fā)給了目的節(jié)點，那么目的節(jié)點根據(jù)GTP請求消息中的源 節(jié)點分配的源UDP端口信息信元，向該源節(jié)點發(fā)送GTP響應(yīng)消息。如果是發(fā)給 了另外一個中間節(jié)點，那么此中間結(jié)點最終會將此GTP請求消息發(fā)給目的節(jié) 點，由目的節(jié)點進(jìn)行上述處理。
本發(fā)明實施例通過在GTP請求消息添加源節(jié)點分配的源UDP端口信息的 信元，^f吏得在存在中間節(jié)點轉(zhuǎn)發(fā)的情況下，目的節(jié)點能夠得知源節(jié)點分配的源 UDP端口信息，從而保證了流程的順利處理。
需要說明的是本發(fā)明實施例中涉及到的源UDP端口信息是指設(shè)置在GTP 消息底層的UDP協(xié)議頭部"源端口號"字段中的UDP端口號值；源UDP端口 信息的信元是指添加在GTP消息的信元列表中其中一個信元，本發(fā)明實施例 中的源UDP端口信息的信元的值包含了由源節(jié)點分配的源UDP端口號。
參見附圖4,本發(fā)明實施例提供了一種GTP消息傳輸?shù)姆椒ǎ芍虚g節(jié)點 在發(fā)送GTP請求消息時將源節(jié)點發(fā)送的GTP請求消息的源UDP端口信息作為一 個信元附加在轉(zhuǎn)發(fā)的GTP請求消息中，以UMTS系統(tǒng)中路由區(qū)更新流程為例， 將發(fā)起GTP會話的新側(cè)SGSN稱作源節(jié)點，根據(jù)老路由區(qū)標(biāo)識(Old Routing Area I den t i t y ， 01 d RAI )解析到的中間節(jié)點SGSN稱作中間節(jié)點，終端原來注冊 的舊側(cè)SGSN稱作目的節(jié)點，SGSN上下文請求消息稱作GTP請求消息，UDP端 口信息為UDP端口號。
步-驟400.源節(jié)點解析出中間節(jié)點的IP地址IP-Midd 1 e;源節(jié)點接收到終端發(fā)送的路由區(qū)更新請求消息，從該路由區(qū)更新請求消息
中獲取01d RAI,根據(jù)該01d RAI進(jìn)行域名系統(tǒng)(Domain name System, DNS) 解析，獲得服務(wù)于該Old RA的SGSN的IP地址，Iu-flex技術(shù)中，由多個 SGSN組成一個SGSN POOL共同服務(wù)于老路由區(qū)(Old Routing Area, Old RA )， 源節(jié)點才艮據(jù)Old RAI通過DNS解析到的舊側(cè)SGSN可能并不是目的節(jié)點，而是 一個中間節(jié)點，這里源節(jié)點并不知道其根據(jù)Old RAI解析到的節(jié)點是目的節(jié)點， 還是一個中間節(jié)點，這里假設(shè)解析到的節(jié)點是中間結(jié)點。
此處源節(jié)點是在路由區(qū)更新的流程中根據(jù)中間結(jié)點的域名解析出中間節(jié) 點的IP地址，實際在其它流程中，例如在PDP上下文激活過程中，SGSN^Mv終 端的PDP激活請求消息中，可以從HLR中獲取的簽約數(shù)據(jù)中，或者才艮據(jù)本身的 配置，確定本次激活使用的APN，通過DNS解析得到中間結(jié)點的IP地址。
步驟40L源節(jié)點才艮據(jù)解析出的IP地址向中間節(jié)點發(fā)送GTP請求消息；
GTP請求消息中的源IP地址，目的IP地址，源UDP端口號，目的UDP端 口號，GTP序列號五元組標(biāo)識為IP—Source, IP—Middle, Port—Source, Port-Registered, GTP—Seq，其中目的UDP端口號Port— Registered可以始 終為GTP協(xié)議的注冊端口號，在GTPvl和v2版本中，注冊端口號為2123,步 驟4 0 0中的路由區(qū)更新請求消息中攜帶由目的節(jié)點為終端分配的分組臨時移動 用戶標(biāo)識 (Packet-Temporary Mobile Station Identity , P-TMSI ),源節(jié) 點將該P-TMSI包含在GTP請求消息中。
步驟402.中間節(jié)點接收到GTP請求消息后，為該GTP請求消息重新分配 源UDP端口號，并且在GTP請求消息中添加包含源節(jié)點分配的源UDP端口號 的信元，向目的節(jié)點發(fā)送包含重新分配的源UDP端口號和源節(jié)點分配的源 UDP端口號的信元的GTP請求消息；
中間節(jié)點從該GTP請求消息中獲得P-TMSI，由于該P-TMSI是由目的節(jié)點分 配的，其中包含了能夠在目的節(jié)點所屬的SGSN POOL內(nèi)唯一標(biāo)識目的節(jié)點的的網(wǎng)絡(luò)資源標(biāo)識(Network Resource Identifier, NRI ) ， P—TMSI中包含的NRI 只有屬于同一個SGSNPOOL的所有SGSN才能識別，中間節(jié)點發(fā)現(xiàn)P-TMSI中包 含的NRI并不是對應(yīng)自己，則通過本地配置或DNS解析根據(jù)NRI得到真正分配 該P-TMSI的舊側(cè)SGSN,即目的節(jié)點的IP地址IP-Dest。中間節(jié)電為該GTP 請求消息重新分配源UDP端口號Port-Middle,中間節(jié)點向目的節(jié)點發(fā)送該 GTP請求消息，該GTP請求消息中的源IP地址，目的IP地址，源UDP端口號， 目的UDP端口號，GTP序列號五元組標(biāo)識為IP_Middle2， IP_Dest， Port—Middle Port—Registered, GTP_Seq,其中中間節(jié)點發(fā)送的GTP請求消息使用的源地址 IP—Middle2可以與源節(jié)點發(fā)送GTP請求消息使用的目的地址IP—Middle相同, 也可以不相同。中間節(jié)點在發(fā)送GTP請求消息時，將從源節(jié)點接收的GTP請求 消息本身的源IP地址，即IP—Source作為"源IP地址，，信元附加在轉(zhuǎn)發(fā)的GTP 請求消息中，同時中間節(jié)點在其發(fā)送的GTP請求消息中附加"源UDP端口號" 信元，其值設(shè)置為其從源節(jié)點接收的GTP請求消息本身的源UDP端口，即 Port_Source。
步驟403.目的節(jié)點接收到GTP請求消息，根據(jù)GTP請求消息中的源節(jié)點 分配的源UDP端口號的信元，向源節(jié)點發(fā)送響應(yīng)消息。
目的節(jié)點從GTP請求消息中獲得P-TMSI,發(fā)現(xiàn)P-TMSI中包含的NRI是對應(yīng)
自己的，即這個P-TMSI是由自己給終端分配的，從而知道自己是該GTP請求
消息的最終目的節(jié)點。目的節(jié)點對GTP請求消息進(jìn)行信令處理，向源節(jié)點返回
GTP響應(yīng)消息，GTP響應(yīng)消息中的源IP地址，目的IP地址，源UDP端口號，
目的UDP端口號，GTP序列號五元組標(biāo)識為IP_Dest2， IP—Source,
Port—Registered, Port — Source, GTP_Seq，其中GTP響應(yīng)消息的源IP地址
IP一Dest2可以與中間節(jié)點轉(zhuǎn)發(fā)的GTP請求消息的目的地址IP一Dest相同，也可
以不相同；源UDP端口號一般使用對應(yīng)GTP請求消息的目的端口號，即
Port-Registered;目的IP地址使用中間節(jié)點轉(zhuǎn)發(fā)的GTP請求消息中附加的"源
IP地址"信元，即IP_Source;目的節(jié)點檢查從中間節(jié)點發(fā)送的GTP請求消息中是否附加了 "源UDP端口號"信元，如果是則使用該信元的值Port —Source 作為GTP響應(yīng)消息的目的UDP端口號，如果未附加則使用從中間節(jié)點轉(zhuǎn)發(fā)的GTP 請求消息本身的源UDP端口號Port-Middle作為GTP響應(yīng)消息的目的UPD端口 號。在本實施例中，GTP請求消息附加了 "源UDP端口號"信元，因此使用該 信元的值作為GTP響應(yīng)消息的目的UDP端口號。
上述實施例中，中間節(jié)點在發(fā)送GTP請求消息時，仍然由中間節(jié)點分配新 的源UDP端口號，^旦中間節(jié)點將4妄收到的GTP:f貪求消息中的源UDP端口號作為 一個新的信元附加在消息中轉(zhuǎn)發(fā)給目的節(jié)點；目的節(jié)點檢查從中間節(jié)點發(fā)送的 GTP請求消息中是否附加了 "源UDP端口號"信元，如果是則使用該信元的值 作為GTP響應(yīng)消息的目的UDP端口號。由于GTP響應(yīng)消息的目的IP地址，目 的端口號，GTP序號都是源節(jié)點分配的，因此GTP響應(yīng)消息達(dá)到源節(jié)點后，源 節(jié)點能夠正確處理，匹配到對應(yīng)的GTP請求消息。
參見附圖5,本發(fā)明實施例提供了一種GTP消息傳輸?shù)姆椒?，在源?jié)點在 發(fā)送GTP請求消息時，將源節(jié)點分配的源UDP端口信息作為一個信元附加在GTP 請求消息中，而中間節(jié)點在發(fā)送GTP請求消息時無需再執(zhí)行附加信元梯:作，以 函TS系統(tǒng)中路由區(qū)更新流程為例，將發(fā)起GTP會話的新側(cè)SGSN稱作源節(jié)點， 才艮據(jù)Old RAI解析到的中間節(jié)點SGSN稱作中間節(jié)點，終端原來注冊的舊側(cè)SGSN 稱作目的節(jié)點，SGSN上下文請求消息稱作GTP消息，UDP端口信息為UDP端 口號。
步驟500.源節(jié)點根據(jù)路由區(qū)更新消息解析出中間節(jié)點的IP地址 IP_Middle;
具體參見步驟400;
步驟5 01.源節(jié)點向中間節(jié)點發(fā)送GTP請求消息，所述GTP請求消息中包含 源節(jié)點分配的源UDP端口號以及源節(jié)點分配的源UDP端口號的信元；
12GTP請求消息的源IP地址，目的IP地址，源UDP端口號，目的UDP端口 號，GTP序列號五元組標(biāo)識為(IP-Source, IP—Middle, Port-Source, Port-Registered, GTP-Seq),其中目的UDP端口號Port— Registered始終為 GTP協(xié)議的注冊端口號，在GTP vl和v2版本中，注冊端口號為2123。源節(jié)點 在發(fā)送的GTP請求消息中，將分配的源UDP端口號(Port-Source2)作為一個 信元附加在消息中。其中，附加的"源UDP端口號"信元的值Port—Source2 可以與發(fā)送的GTP請求消息本身的源UDP端口號Por t-Source相同，也可以不 相同。步驟500中的路由區(qū)更新請求消息中攜帶由目的節(jié)點為終端分配的 P-TMSI，源節(jié)點將該P-TMSI包含在GTP請求消息中。
步驟502.中間節(jié)點接收到GTP請求消息后，為該GTP請求消息重新分配 源UDP端口號，向目的節(jié)點發(fā)送該GTP請求消息，該該GTP請求消息包括中 間節(jié)點重新分配的源UDP端口號以及源節(jié)點分配的源UDP端口號的信元；
中間節(jié)點接收到GTP請求消息后，判斷出自身為中間結(jié)點，通過本地配置 或DNS解析等方式，得到目的節(jié)點的IP地址IP-Dest。中間節(jié)點向目的節(jié)點發(fā) 送該GTP請求消息，GTP請求消息的源IP地址，目的IP地址，源UDP端口號， 目的UDP端口號，GTP序列號五元組標(biāo)識為IP—Middle2， IP-Dest， Port—Middle: Port-Registered, GTP-Seq,其中中間節(jié)點發(fā)送的GTP請求消息使用的源地址 IP一Middle2可以與源節(jié)點發(fā)送GTP請求消息使用的目的地址IP—Middle相同， 也可以不相同。中間節(jié)點在轉(zhuǎn)發(fā)消息時，將從源節(jié)點接收的GTP請求消息本身 的源IP地址IP-Source作為"源IP地址"信元附加在轉(zhuǎn)發(fā)的GTP請求消息中, 同時中間節(jié)點判斷其從源節(jié)點接收的GTP請求消息含有"源UDP端口號"信元， 因此中間節(jié)點不再需要如實施例二中在發(fā)送的GTP請求消息中附加"源UDP端 口號"信元，而是保持發(fā)送到目的節(jié)點的GTP請求消息中附加的"源UDP端口 號"信元的值與接收的GTP請求消息中的值相同，即Port-Source2。
步驟503.目的節(jié)點接收到中間節(jié)點發(fā)送的GTP請求消息，根據(jù)GTP請求消息中的源節(jié)點分配的源UDP端口號的信元，向源節(jié)點發(fā)送響應(yīng)消息。 具體參見步驟403.
上述實施例中，中間節(jié)點在發(fā)送GTP請求消息時，仍然由中間節(jié)點分配新 的源UDP端口號，但是源節(jié)點在GTP請求消息中，將分配的源UDP端口號作為 一個信元附加在GTP請求消息中，后續(xù)中間結(jié)點保持發(fā)送到目的節(jié)點的GTP請 求消息中附加的"源UDP端口號，，信元的值與接收的GTP請求消息中的值相同， 目的節(jié)點檢查從中間節(jié)點發(fā)送的GTP請求消息中是否附加了 "源UDP端口號" 信元，如果是則使用該信元的值作為GTP響應(yīng)消息的目的UDP端口號。由于GTP 響應(yīng)消息的目的IP地址，目的端口號，GTP序號都是源節(jié)點分配的，因此GTP 響應(yīng)消息達(dá)到源節(jié)點后，源節(jié)點能夠正確處理，匹配到對應(yīng)的GTP請求消息。
上述三個實施例提供的在GTP請求消息中增加"源UDP端口號"信元的方 法，為提供最大的靈活性，如可能存在兩個個或多個中間節(jié)點轉(zhuǎn)發(fā)的情況，對 中間節(jié)點的處理可以做如下規(guī)定如果中間節(jié)點接收到的GTP請求消息中已經(jīng) 附加了源UDP端口號信元，則中間節(jié)點將該已附加的源UDP端口號信元隨GTP 請求消息繼續(xù)發(fā)送給下個節(jié)點，而不再將接收到的GTP請求消息本身的源端口 號作為一個信元附加；只有在中間節(jié)點接收到的GTP請求消息中沒有附加源 UDP端口號信元的情況下，中間節(jié)點才將接收到的GTP請求消息本身的源端口 號作為一個信元附加在轉(zhuǎn)發(fā)的消息上。目的節(jié)點在返回GTP響應(yīng)消息時，如果 接收到的GTP請求消息中包含了源UDP端口號信元，則使用該信元的值作為GTP 響應(yīng)消息的目的UDP端口號，否則使用GTP請求消息本身源UDP端口號作為GTP 響應(yīng)消息的目的UDP端口號。
參見附圖6,本發(fā)明實施例提供了一種GTP消息傳輸?shù)姆椒?，中間節(jié)點在 轉(zhuǎn)發(fā)GTP消息時，不再自己為轉(zhuǎn)發(fā)的消息分配源UDP端口信息，而總是將轉(zhuǎn)發(fā) 的GTP請求消息中的源端口信息設(shè)置為接收到的GTP請求消息的源端口信 ，以麗TS系統(tǒng)中路由區(qū)更新流程為例，將發(fā)起GTP會話的新側(cè)SGSN稱作源節(jié)點， #>據(jù)Old RAI解析到的中間節(jié)點SGSN稱作中間節(jié)點，終端原來注冊的舊側(cè)SGSN 稱作目的節(jié)點，SGSN上下文請求消息稱作GTP消息，UDP端口信息為UDP端 口號。
步驟600.源節(jié)點根據(jù)路由區(qū)更新消息解析出中間節(jié)點的IP地址 IP—Middle,具體參見步驟400;
步驟6 01.源節(jié)點向中間節(jié)點發(fā)送GTP請求消息，該GTP請求消息中包含 源節(jié)點分配的源UDP端口號，具體參見步驟401;
步驟602.中間節(jié)點根據(jù)所述源節(jié)點分配的源UDP端口號，將所述GTP請 求消息的源UDP端口信息設(shè)置為源節(jié)點分配的源UDP端口號，向目的節(jié)點發(fā) 送該GTP請求消息；
中間節(jié)點接收到GTP請求消息后，判斷出自身為中間結(jié)點，通過本地配置 或DNS解析等方式，得到目的節(jié)點的IP地址IP—Dest。中間節(jié)點向目的節(jié)點發(fā) 送該GTP請求消息，GTP請求消息的源IP地址，目的IP地址，源UDP端口號， 目的UDP端口號，GTP序列號五元組標(biāo)識為工P-Middle2， IP—Dest, Port — Source: Port-Registered, GTP一Seq，中間節(jié)點轉(zhuǎn)發(fā)GTP請求消息使用的源地址 IP_Mi dd 1 e2可以與源節(jié)點發(fā)送GTP請求消息使用的目的地址IP—Mi dd 1 e相同， 也可以不相同。中間節(jié)點在轉(zhuǎn)發(fā)消息時，將從源節(jié)點接收的GTP請求消息本身 的源IP地址，即IP-Source作為"源IP地址"信元附加在轉(zhuǎn)發(fā)的GTP請求消 息中，同時中間節(jié)點不再為轉(zhuǎn)發(fā)的GTP請求消息分配源UDP端口，而是使用接 收的GTP請求消息本身的UDP端口 ，即Port-Source作為轉(zhuǎn)發(fā)GTP請求消息的 源UDP端口號。
步驟603.目的節(jié)點接收到GTP請求消息，根據(jù)該GTP請求消息中的源節(jié)點 分配的源UDP端口號向源節(jié)點發(fā)送響應(yīng)消息。
目的節(jié)點從GTP請求消息中獲得P-TMSI ，發(fā)現(xiàn)P-TMSI中包含的NRI是對應(yīng)自己的，即這個P-TMSI是由自己給終端分配的， >夂人而知道自己是該GTP請求 消息的最終目的節(jié)點。目的節(jié)點對GTP請求消息進(jìn)行信令處理，向源節(jié)點返回 GTP響應(yīng)消息。GTP響應(yīng)消息的源IP地址，目的IP地址，源UDP端口號，目 的UDP端口號，GTP序列號五元組標(biāo)識為IP_Dest2 , IP—Source, Port—Registered, Port —Source, GTP—Seq,其中GTP響應(yīng)消息的源IP地址 IP一Dest2可以與中間節(jié)點轉(zhuǎn)發(fā)的GTP請求消息的目的地址IP—Dest相同，也可 以不相同；源UDP端口號一般使用對應(yīng)GTP請求消息的目的端口號，即 Port-Registered;目的IP地址使用中間節(jié)點轉(zhuǎn)發(fā)的GTP請求消息中附加的源 IP地址信元，即IP_Source;目的UDP端口號使用從中間節(jié)點轉(zhuǎn)發(fā)的GTP請求 消息本身的源UDP端口號作為GTP響應(yīng)消息的目的UPD端口號，由于中間節(jié)點 使用源節(jié)點分配的源UDP端口號作為轉(zhuǎn)發(fā)消息的UDP端口號，因此這里是 Port—Source。由于GTP響應(yīng)消息的目的IP地址，目的端口號，GTP序號都的 確是源節(jié)點分配的，因此GTP響應(yīng)消息達(dá)到源節(jié)點后，源節(jié)點能夠正確處理， 匹配到對應(yīng)的GTP請求消息。
本發(fā)明實施例4^供的方案使得在存在中間節(jié)點的情況下，源節(jié)點能夠為GTP 請求消息分配不同的源UDP端口號，而從目的節(jié)點返回的GTP響應(yīng)消息的目的 UDP端口號仍能與源節(jié)點為GTP請求消息分配的源UDP端口號一致。從而使得 以分布式系統(tǒng)實現(xiàn)的GTP設(shè)備中，通過源UDP端口號來復(fù)用設(shè)備間的IP通道， 提升設(shè)備容量和性能，減少IP地址消耗成為可能。
上述實施例均以麗TS系統(tǒng)中路由區(qū)更新流程為例對本發(fā)明實施例的方案進(jìn) 行闡明的，本發(fā)明實施例提供的方案還可以應(yīng)用于切換等流程，上述實施例中 的的"源節(jié)點"，"中間節(jié)點"，"目的節(jié)點"在不同的場景下標(biāo)識不同的實體網(wǎng) 元如在Iu-Flex場景下，源節(jié)點可以為新側(cè)應(yīng)E/SGSN,中間節(jié)點為與舊側(cè) SGSN在同 一個POOL內(nèi)的代理SGSN，而目的節(jié)點為存儲用戶上下文的舊側(cè)SGSN; 而在GGSN/GW Redirect場景下，源節(jié)點可以為SGSN/MME或Serving GW,中間 節(jié)點為SGSN/薩E從DNS Server等方式解析得到的代理GGSN/Serving GW/PDN
16GW節(jié)點，而目的節(jié)點則是由代理節(jié)點選擇的最終處理連接請求的GGSN/ Serving GW / PDN GW,上述解釋對于下述實施例也適用。
參見附圖7，本發(fā)明實施例提供了一種GTP消息傳輸系統(tǒng)，包括第一節(jié)點 701、第二結(jié)點702和第三節(jié)點703,其中，第一節(jié)點701，用于向第二結(jié)點發(fā)送 GTP請求消息，所述GTP請求消息中包含源節(jié)點分配的源UDP端口信息；第二結(jié) 點702，用于為所述GTP請求消息重新分配源UDP端口信息，向第三節(jié)點703發(fā)送 包含源節(jié)點分配的源UDP端口信息的信元和重新分配的源UDP端口信息的GTP請 求消息。第三節(jié)點7 0 3用于根據(jù)所述GTP請求消息中的源節(jié)點分配的源UDP端口 信息信元，向所述源節(jié)點發(fā)送GTP響應(yīng)消息。
第二節(jié)點702還用于判斷所述接收的GTP請求消息中是否包含所述源UDP 端口信息的信元；所述接收的GTP請求消息中不包含所述源UDP端口信息的信 元，在所述接收的GTP請求消息中添加包含所述源節(jié)點分配的源UDP端口信息 的信元。
本發(fā)明實施例GTP消息傳輸系統(tǒng)中的第 一 節(jié)點7 01為源節(jié)點或者第 一 中間 節(jié)點，第二節(jié)點702為第二中間節(jié)點，第三節(jié)點703為目的節(jié)點或者第三中間節(jié) 點。
參見圖8，本發(fā)明實施例提供了一種源節(jié)點，包括解析單元801，用于根 據(jù)中間節(jié)點對應(yīng)的域名解析出所述中間節(jié)點的IP地址；發(fā)送單元802，用于向 所述解析出的中間節(jié)點發(fā)送GTP請求消息，所述GTP請求消息中包含所述源節(jié)點 分配的源UDP端口信息的信元和源節(jié)點分配的源UDP端口信息。
參見圖9，本發(fā)明實施例提供了一種中間節(jié)點，包括接收單元901，用于 接收GTP請求消息；分配單元902,用于為所述GTP請求消息重新分配源UDP端口信息；發(fā)送單元903,用01于發(fā)送包含源節(jié)點分配的源UDP端口信息的信元 和重新分配的源UDP端口信息的GTP請求消息。本發(fā)明實施例提供的中間節(jié)電 還可以包括第一判斷單元904，用于判斷所述接收的GTP請求消息中是否包含 源UDP端口號的信元；信元添加單元905，用于在判斷單元判斷出所述GTP請求 消息中不包含源UDP端口號的信元時，在所述GTP請求消息中添加源節(jié)點分配的 源UDP端口信息的信元。
參見圖10，本發(fā)明實施例提供了一種目的節(jié)點，包括接收單元1001，用 于接收GTP請求消息，所述GTP請求消息中包含源節(jié)點分配的源UDP端口信 息的信元和源UDP端口信息；響應(yīng)單元1002，才艮據(jù)所述源節(jié)點分配的源UDP 端口信息的信元向源節(jié)點發(fā)送GTP響應(yīng)消息。
本領(lǐng)域普通技術(shù)人員可以理解實現(xiàn)上述方法實施例的全部或部分步驟可 以通過程序指令相關(guān)的硬件來完成，前述的程序可以存儲于計算機可讀取存儲 介質(zhì)中，該程序在執(zhí)行時，執(zhí)行包括上述方法實施例的步驟；而前述的存儲介 質(zhì)包括ROM、 RAM、石茲-萊或者光盤等各種可以存儲程序代碼的介質(zhì)。
顯然，本領(lǐng)域的技術(shù)人員可以對本發(fā)明進(jìn)行各種改動和變型而不脫離本發(fā) 明的精神和范圍。這樣，倘若本發(fā)明的這些修改和變型屬于本發(fā)明權(quán)利要求及 其等同技術(shù)的范圍之內(nèi)，則本發(fā)明也意圖包含這些改動和變型在內(nèi)。
權(quán)利要求
1.一種GTP消息傳輸?shù)姆椒?，其特征在于，包括接收GTP請求消息，所述GTP請求消息中包含源節(jié)點分配的源UDP端口信息；為所述GTP請求消息重新分配源UDP端口信息；發(fā)送包含源節(jié)點分配的源UDP端口信息的信元和重新分配的源UDP端口信息的GTP請求消息。
2. 如權(quán)利要求1所述的GTP消息傳輸?shù)姆椒ǎ涮卣髟谟?，所述方法還包括判斷所述接收的GTP請求消息中是否包含所述源節(jié)點分配的源UDP端口 信息的4言元；所述接收的GTP請求消息中不包含所述源節(jié)點分配的源UDP端口信息的 信元，根據(jù)所述接收的GTP請求消息中包含源節(jié)點分配的源UDP端口信息在所 述GTP請求消息中添加包含所述源節(jié)點分配的源UDP端口信息的信元。
3. 如權(quán)利要求1 2所述的GTP消息傳輸?shù)姆椒?，其特征在于，所述方法還 包括目的節(jié)點根據(jù)所述GTP請求消息中的源節(jié)點分配的源UDP端口信息的信 元，向所述源節(jié)點發(fā)送GTP響應(yīng)消息。
4. 一種GTP消息傳輸?shù)姆椒?，其特征在于，包括接收GTP請求消息，所述GTP請求消息中包含源節(jié)點分配的源UDP端口信臺.將所述GTP請求消息的源UDP端口信息設(shè)置為源節(jié)點分配的源UDP端口 "息;發(fā)送所述包含源節(jié)點分配的源UDP端口信息的GTP請求消息。
5. —種GTP消息傳輸系統(tǒng)，其特征在于，包括第一節(jié)點、第二結(jié)點和第三節(jié)點，其中，第一節(jié)點，用于向第二結(jié)點發(fā)送GTP請求消息，所述GTP請求消息中包含源 節(jié)點分配的源UDP端口信息；第二結(jié)點，用于為所述GTP請求消息重新分配源UDP端口信息，向第三節(jié) 點發(fā)送包含源節(jié)點分配的源UDP端口信息的信元和重新分配的源UDP端口信 息的GTP請求消息。
6. 如權(quán)利要求5所述的系統(tǒng)，其特征在于，所述第二節(jié)點還用于判斷所述 接收的GTP請求消息中是否包含所述源節(jié)點分配的源UDP端口信息的信元；所 述"I姿收的GTP請求消息中不包含所述源節(jié)點分配的源UDP端口信息的信元，在 所述接收的GTP請求消息中添加包含所述源節(jié)點分配的源UDP端口信息的信 元。
7. 如權(quán)利要求5所述的系統(tǒng)，其特征在于，所述第一節(jié)點為源節(jié)點或者第 一中間節(jié)點，所述第二節(jié)點為第二中間節(jié)點，所述第三節(jié)點為目的節(jié)點或者第 三中間節(jié)點。
8. 如權(quán)利要求5 7所述的系統(tǒng)，其特征在于，所述第三節(jié)點用于根據(jù)所述 GTP請求消息中的源節(jié)點分配的源UDP端口信息信元，向所述源節(jié)點發(fā)送GTP 響應(yīng)消息。
9. 一種源節(jié)點，其特征在于，包括解析單元，用于根據(jù)中間節(jié)點對應(yīng)的域名解析出所述中間節(jié)點的IP地址； 發(fā)送單元，用于向所述解析出的中間節(jié)點發(fā)送GTP請求消息，所述GTP請求 消息中包含所述源節(jié)點分配的源UDP端口信息的信元和源節(jié)點分配的源UDP 端口j言息。
10. —種中間節(jié)點，其特征在于，包括 接收單元，用于接收GTP請求消息；分配單元，用于為所述GTP請求消息重新分配源UDP端口信息； 發(fā)送單元，用于發(fā)送包含源節(jié)點分配的源UDP端口信息的信元和重新分配的源UDP端口信息的GTP請求消息。
11. 如權(quán)利要求10所述的中間節(jié)點，其特征在于，還包括 第一判斷單元，用于判斷所述接收的GTP請求消息中是否包含源UDP端口號的信元；信元添加單元，用于在判斷單元判斷出所述GTP請求消息中不包含源UDP 端口號的信元時，在所述GTP請求消息中添加源節(jié)點分配的源UDP端口信息的 信元；
12. —種目的節(jié)點，其特征在于，包括接收單元，用于接收GTP請求消息，所述GTP請求消息中包含源節(jié)點分配的 源UDP端口信息的信元和源UDP端口信息；響應(yīng)單元，根據(jù)所述源節(jié)點分配的源UDP端口信息的信元向源節(jié)點發(fā)送 GTP響應(yīng)消息。
全文摘要
本發(fā)明實施例提供了一種GTP消息傳輸?shù)姆椒ǎń邮誈TP請求消息，GTP請求消息中包含源節(jié)點分配的源UDP端口信息；為該GTP請求消息重新分配源UDP端口信息；發(fā)送包含源節(jié)點分配的源UDP端口信息的信元和重新分配的源UDP端口信息的GTP請求消息，本發(fā)明實施例還提供了另外一種GTP消息傳輸?shù)姆椒?，以及一種GTP消息傳輸系統(tǒng)、源節(jié)點、中間結(jié)點、目的節(jié)點，使得在存在中間節(jié)點轉(zhuǎn)發(fā)的情況下，目的節(jié)點能夠得知源節(jié)點分配的源UDP端口信息，從而保證了流程的順利處理。
文檔編號H04L29/06GK101640670SQ20081014257
公開日2010年2月3日 申請日期2008年7月30日 優(yōu)先權(quán)日2008年7月30日
發(fā)明者宇 銀 申請人:華為技術(shù)有限公司