TW525397B - Method to transfer a tunnel between nodes of a GPRS system - Google Patents

Description

525397 五、發明説明（1 ) 本發明涉及一種在第二節點上設置GPRS(General

Packet RacHo Semce)之第一服務節點之通道所用之方法 〇

若行動式終端機（其使用相關之通道）由第一服務節 點之供應區切換至第二節點時，則設置一種通道區是需 要的。此種切換會造成一種RAU(Routing Area Update， 路徑區更新），在其路徑中資料經由終端機之PDP-上下 文而由第一服務節點繼續到達第二服務節點。這些資料 之傳送是以GTP (GPRS-Tunnel-Protocol)規約之資訊形式 來進行。此種GTP規約之資訊在路由區更新時另外可用 .來構成/拆解PDP-上下文且繼續傳送PDP-上下文。GTP 規約之細節可參考此文獻3G TS 23.060 Technical Specification Group Service and System Aspects; General Packet Radio Service(GPRS); Service Description; Stage 2(Release 1 999)，例如，Version V3.3.0 of April 2000 of 3GPP(3rd Generation Partnership Project, www.3GPP. ORG o 在二個服務節點之間所傳送之資料可使第二服務節點 及一個接觸區容納於一個閘路（G a t e W a y)節點中且由該 處形成此上下文所需之完整之資訊，這些資訊使該節點 對GTP通道進行切換，使終端機所需之服務可繼續而不 會中斷。 就GTP規約而言，目前有二個版本（VerS1〇n)已標準化 ，其中之一是GSM 09.60中之GTP-Version 0，亦稱爲 525397 五、發明説明（2 )

Release 98或97 ;另一個是GTP-Version 1，在上述已揭 不之文件TS 23.060中亦稱爲Reiease 99。Version 1之 標準所追求的是· Version 1之節點可與Version 0者一 起操作，且GTP通道可與最高可能之版本（Versi〇n)來操 作。 所接收之節點因此可辨認GTP版本，據此可設定所接 收之資訊，各資訊分別在字頭中承載一種特徵符號，其 可對應於各別之版本。依據版本1所設定之這些資訊不 可由這些節點（其依據版本〇或更早之標準來操作）所 解釋。版本1之節點因此必須處於此種狀態，即：在依 據GTP版本（其使用一種節點，資訊發送至此節點）之 情況下，則依據版本1或版本0來設定這些資訊。 GTP規約之版本0或版本1之間之主要不同是〃此種 方法〃，資訊依據此種方法而配屬於已形成之通道或 PDP-上下文。在版本0時使用所謂通道辨認字（簡稱 TIDS )，其作爲資訊之一部份而傳送且由IMSI (International Mobile Subscriber Identity)及 NSAPI (Network Layer Service Access Point Identifier)所組成。 IMSI是用戶之明確且廣泛性之特徵字；NSAPI須參考多 個PDP-上下文（其可配屬於此用戶）中之一。由於通道 辨認字不能正確地以12位元組（Byte)長度來處理，則在 其位置處須另外使用2位元組長度之流動標纖（Flow Labels) ’其可快速地使資訊分配給上下文。但這些流動 標纖未必很明確地標示，此乃因爲其所具有之値之範圍 -4- 525397 五、發明説明（3 ) 是6 5 0 0 0且每一節點可明確地形成多個上下文。 各流動標纖在驅動G T P通道時被設定；每一加入此通 道之節點通知該對立節點：其利用哪種流動標纖來獲得 此通道中之隨後之各資訊（這對此種PDP_上下文而言是 同意義的）。在第一資訊（其在通道構造之範圍中由一 個服務節點發送至閘路節點，形成PDP C〇ntext Request )中此種流動標纖保持在〇，因爲各閘路節點仍未設定 此流動標纖，且此通道辨認字已傳送；此通道之所有隨 後之資訊須利用此種由閘路節點所設定之流動標纖來發 送。正確而言’須分別設定二個流動標纖，一個用來作 信號通知而另一個用於資料中。但以下只考慮此種信號 通知用之流動標纖。 在GTP版本1中設定所謂TEID(Tunnel Endpoint Indentifier)，其功能與流動標纖相同，但長度是4位元 組。此TEID因此與版本〇之流動標纖不相容，但這些 TEID可明確地設定。版本〇中已知之通道辨認字未包含 在版本1之資訊中。IMSI及NS API (其使資訊明確地配 屬於PDP-上下文）只在第一資訊（形成pdp Context Request)中由服務節點包含至閘路節點。 GTP之此二個版本在各別之版本中可完美地作用著。 在標準化時，版本1用之節點亦須支撐G T P版本0，即 ，其是反向（backwards)相容的。這是需要的，不同版本 之節點因此可一起操作。 但若行動式無線電用戶移動至一種網路（其包含不同 525397 五、發明説明（4 ) 版本之節點）中且由一服務節點之供應區切換至另一供 應區’則會發生一些問題。此種切換會造成一種r A U (Routing Area Update)，其中一種通道由此節點（其供應 區中先前已保持著此用戶）轉移至神供應區之節點。在 此種過程之範圍中，PDP-上下文之資料須藉助於GTP資 訊而由老節點繼續傳送至新節點。此種資料需要新節點 ，以便容納此種至閘路節點之接觸區且切換此種GTP通 道’使此用戶所需之服務可未中斷地繼續進行。若所有 加入此通道之切換之三個節點屬於相同之GTP版本，則 此種切換不會發生問題。若其中二個是版本〇之節點且 第三個是版本丨之節點，則此時不會發生問題，因爲所 有在各節點之間交換之資訊必須是GTP版本〇之資訊。 當然若二個節點屬於版本丨且第三節點屬於版本〇，則 下述情況會造成困難：版本丨之二個節點互相與版本i 之資訊相通信且因此在第三節點中是與版本〇之資訊相 通信。以下須區別三個情況： 1 ·行動式無線電用戶由版本〇之第一服務節點移動至 版本1之桌一節點。在此種情況中，第一服務節點與笫 二服務節點，閘路節點通信時須使用GTP版本〇 ;聞路 節點與第二服務節點之間之通信依據版本1來進行。在 構成此通道時，閘路節點分配一種流動標纖，其由第一 服務節點所使用以便標示此通道所屬之資訊。若此二個 服務節點容納該接觸區，以便預備設置此通道，則其依 據版本〇來通信，且第一服務節點提供該流動標纖至第 525397 五、發明説明（ ) 一 節 點 5 此 流 動 標 纖 原 來 由 閘路 節點配屬 於此通道。爲 了 由 閘 路 節 點 獲 得 此 通 道 所 需之 上下文資 料’則第二服 務 節 點 必 須 可 提 供 ~ 種 具 有 此種 流動標纖 之資訊至閘路 節 點 0 但 第 二 服 務 節 點 及 閘 路節 點是依據 版本0來通信 其 不 允 許 此 流 動 標 纖 之 傳 送； 可依據版 本1來傳送 TEIE >以耳〕 Z代此種流動標纖， 但It丨 二種流動標纖在此種通 道 用 之 閘 路 節 點 中 未 被 疋 義 。聞 路節點因 此並未使GTP 版 本 1 之 資 訊 配 屬 於 現 有 之 通道 。由於此 種資訊"U p d a t e PDP C c ntext R eq uest' 未 包 含 IMSI及NS API，則閘路節 點 並 未 發 現 此 上 下 文 若 此 閘路 節點忽略 此TEID時。 2. 行 動 式 Μ j\\\ 線 電 用 戶 由 版 本1 之第一服 務節點移動至 版 本 0 之 節 點 〇 在 此 種 情 況 下， 在第一服 務節點及閘路 節 點 之 間 通 信 時 在 通 道 之 構 造範 圍中使用 GTP版本1， 即 通 道 之 TEID已確定 ，但無流動標纖 。就二個服務 節 點 之 間 之 通 信 而 言 須 使 用 GTP 版本0， 但這只允許使 用 // 流 動 標 纖 // 〇 傳 送 TEID至第二節點是不可能的， 即 使 其 存 在 時 5 其 仍 不 能 處 理TEID。第二 :服務節點因 此 仍 不 能 找 出 此 流 動 標 纖 ( 藉此 可要求閘 路節點所需之 上 下 文 資 料 ) Ο 3. 行 動 式 ίκ j\w 線 電 用 戶 由 版 本1 之服務節 點移動至另一 相 同 版 本 之 節 點 但 閘 路 節 點依 據版本0 來操作。在此 種 情 況 下 5 各 服 務 節 點 依 據 版本 1互相通 信，但閘路節 點 依 據 版 本 0 而 與 服 務 節 點 相通 信。此閘 路節點在通道 構 成 時 因 此 分 配 — 種 流 動 標 纖， 但其不是 由第·服務傳 - 7-

525397 五、發明説明（6 ) 送至第二節點，使第二節點亦不能詢問 文資訊。 本發明之目的是提供一種方法以便可 第一服務節點之通道形成至第二節點， 閘路節點之下存在此GTP規約之至少-及另一個版本1之節點，則第二節點亦 在第一服務節點是版本0之節點且第 路節點是依據第1版本操作時，則上述 範圍第1項之方法達成。其設計方式是 需之要求（其使第二服務節點指向閘路 關通道之IMSI及NSAPI之說明。此目f 點對所儲存之上下文形成一種明確之對 下文資料位於第二節點。 所需之IMS I及NS API之說明以很簡 方式傳送：第二服務節點及閘路節點在 下繼續操作此種在GTP規約之版本下所 此種情況下，由第二節點至閘路節點之 上下文（即’資訊"Update PDP Context 之要求含有先前所需之說明。此種解法 約（其在與閘路節點通信時使用於第二 與此通道之預先分層有關，已交換之資 若一通道由第二節點或由版本1之另一 與閘路節點之通信是依據版本1來進行 是由版本0之節點所構成，則與閘路節 閘路節點之上下 使G P R S系統之 若在服務節點和 -個版本0之節點 可作用。 :二服務節點及閘 目的以申請專利 :調整上下文所 節點）包含此相 的允許此閘路節 應且使所需之上 易之方式以下述 相同之規約版本 :形成之通道。在 即將發送之調整 R e q u e s t")所需 因此包含：此規 服務節點中）是 訊屬於此通道。 節點所構成，則 ;若此通道原來 點之通信因此另 525397 五'發明説明（7 ) 外依據版本〇來進行，雖然此二個已加入之節點主要是 以版本〇來操作。 所使用之版本之此種控制方式可簡易地達成，若第一 服務節點首先發送一種引導此通道設置過程用之資訊 (S G S N C ο n t e X t R e q u e s t)至第二服務節點，第二服務節點 在調整此上下文而對閘路節點有要求時使用此種資訊之 版本且第二節點在此版本中回答所有指向其之資訊（其 已被接收者）。 另一種可能是：第二節點依據版本1發送一種型式是 •'Create PDP Context Request"之資訊作爲適應此通道所 需之要求以取代傳統之資訊’'Update PDP Context Request"。此種資訊依據上述文件TS 29.060由接收用之 閘路節點正確地處理，即，現有之PDP上下文又被發現 且已改變之參數被取代。以此種方式，則至第二服務節 點之通道可被設定且亦可在此版本中改變。 此外，另一方式是：可發送此種具有TEID之資訊 nUpdate PDP Context Request"，其具有値 0 且其除了依 據ts 2 3.060所設置之資訊元素以外另含有IMSI及 NS API，以便在閘路節點中可分配給相對應之PDP上下 文。 若第二服務節點或閘路節點是一種版本0之節點且其 它節點是版本1之節點，則本發明之目的以申請專利範 圍第5項之方法來達成，其中第二服務節點及閘路節點 需要一種流動標纖以便可在第二服務節點上設置第一節 525397 五、發明説明（8 ) 點之通道’此流動標纖由第一服務節點所設定以用於第 二節點。 此種流動標纖之分配因此有各種不同之可能性。若閘 路節點是一種版本1用之節點（其依據版本丨來形成此 通道之構造），則在構成時只有TEID (但不具備該流 動標纖）配屬於該通道。在此種情況下，適當之方式是 其屬第一服務節點（其使流動標纖分配給該通道）。 第一種方式是：第一服務節點分配此上下文一種流動 標纖，其値對一種通道由版本1之服務節點轉換至版木 0之服務節點而言是特定的，即，不同之値用於所有之 流動標纖中，各流動標纖用於依據版本0來操作之正規 節點之通信。第二服務節點可對此種特定之流動標纖之 接收起反應，此時其發出一種資訊’’Create PDP Context Request"至閘路節點以取代此資訊"Update PDP Context Request"(其通常發送至閘路節點，若第二服務節點已 由相同版本之第一服務節點獲得正確之流動標纖時）。 此種"Create PDP Context Request"資訊含有 IMSI 及 NS API且因此可明確地辨認閘路節點上此種待調整之上 下文。另一種設計方式是：第二服務節點發送一種資訊 •'Update PDP Context Request"至閘路節點’其當然與版 本1之適用之規約不同而另外具有1MSI及NSAPI而又 可允許一種辨認。此種設計方式是可能的’因爲現有之 規章未設置此種具有流動標纖〇之PDP Update Requests 且其處理因此未規約化。 -10- 525397 五、發明説明（9 ) 第二種方式在閘路節點依據版本1且第二服務節點依 據版本〇來操作時同樣是可使用的’其設計方式是：閘 路節點不只分配每一由第一服務節點依據版本1所設置 之上下文一種TEID外，還伺時支配一種固定之方法， 藉此可使每一由版本1所設置之本文（正確而言是其 TEID )分配到一種流動標纖。因此，在閘路節點中…種 TEID及流動標纖對應於每一由GTP版本1所設置之上 下文。適當之方式是在設定TEIDs時此閘路節點可考慮 這樣所造成之流動標纖，以便可依據此流動標纖有效地 辨認上下文。相同之方法亦可用於第一服務節點。若一 個通道（其由第一服務節點依據GTP版本1所設置）須 依據版本0轉向至第二服務節點，則第一服務節點可藉 由本方法之使用直接測定此流動標纖之正確値目可用於 第二服務節點，據此使此閘路節點可辨認此pD p上下文 。第二服務節點因此可以相同之方式對閘路節點起反應 ，以表示其是否已依據版本〇而移交一種服務節點之此 通道。 一種較佳（因爲特別簡單）之方法（用來分配此流動 標纖至TEID )是使此流動標纖同樣以TEID之二個低値 之位元組來設定。反之，若閘路節點是版本〇之節點且 此一個服務節點是版本1之節點，則〃一種流動標纖配 屬於此通道〃已在其構成時由閘路節點所進行，此種流 動纖在第服務節點中已爲人所知。爲了使此流動標 纖傳送至第二節點（經由版本卜資訊），則適當之方式 -11 - 525397 五、發明説明（1G) 是使其封裝在版本1-資訊之TEID欄中。 由於流動標纖未塡入此TEID欄中，則可有利地使用 TEID欄中仍保留之位置來傳送一種預定之値，否則此 値未出現在TEID欄中且第二服務節點因此可辨認：所 傳送之値是與TEID無關而是與〃已包封〃之流動標纖 有關，因此可正確地處理此値。此種預定之値例如可以 是0。 以下將依據圖式來說明本發明之實施例。圖式簡單說 明： 第1至3圖位置GTP-版本1之二個節點及依據GTP-版本0之一個節點加入之情況下在二個服務節點之問轉 移一種通道時可能之組態圖。 第4至6圖在不同之組態中轉移此通道時之信號流程 圖。 在第1圖之組態中，第1服務節點SGSN1 (終端機 M S之通道原本設在此節點上）是一種g T P -版本0之節 點；其與閘路節點G G S Ν及G Τ Ρ -版本〇之第二服務節點 SGSN2互相通信，即，所交換之資訊之特徵是流動標纖 及TEID °閘路節點GGSN和第二服務節點SGSN2依據 版本1互相通信，其資訊之特徵是TEIDs。 第4圖一方面是在驅動PDP本文時且另一方面是在設 置GTP通道時終端機MS和三個節點SGSN1、SGSN2、 GGSN之間之信號之流程。GTP-版本〇之資訊以細箭頭 表示，版本1之資訊以粗箭頭所示。這些未在各節點之 -12- 525397 五、發明説明（11 ) 間交換之資訊（因此未遵照GTP-規約，例如，與終端機 MS交換之資訊）以虛線表示。 在步驟1中，終端機MS發送一種要求至SGSNO以驅 動 PDP 上下文（Activate PDP Context Request)，其另外亦 設定所期望之服務之N S A PI及形式或品質。此服務節點 SGSN1 使 PDP 版本 0 之要求"Create PDP Context Request"對準閘路節點GGSN，其中會告知此閘路節該 IMSI及NSAPI (步驟2 )。聞路節點在其pDp-上下文表 格中產生一種新的登載，其允許終端機M S之資料封包 在SGSN1及一種未顯示在圖中之外部網路之間流通且計 費且分配給此閘路節點一種流動標纖。閘路節點在步驟 3 中發送一種資訊"Create PDP Context Request"回到第 ~ 服務節點SGSN 1作爲確認用，其含有已分配到之流動標 纖。第一服務節點藉由此資訊"Activate PDP Context Request"對此終端機MS確認上下文已設立（步驟4 )。 藉由所屬之流動標纖，則S GSN 1可確認此終端機MS 之資料封包（其屬於新設立之上下文），使閘路節點 GGSN可區別其與其它終端機之資料封包或區別同一終 端機之屬於其它上下文之資料封包。 此種通道之設置過程因此以終端機在步驟5中發送〜 種要求"Routing Area Update Request"至第二服務節點 SGSN2作爲開始。此節點SGSN2依據GTP-版本1來操 作。 藉由 GTP 版本 〇 之一種資訊"SGSN Context Request" -13- 525397 五、發明説明（12 ) (步驟6)，則第一服務節點S G S N 1首先知道：該上下 文應轉交；則SGSN1藉由此資訊"SGSN Context

Response"(步驟7 )來確認此種轉交且開始緩衝這些來 自PDP網路之決定該用戶台MS所需之資料封包。步驟

8中在新服務節點SGSN2已確認其藉由資訊"SGSN

Context Acknowledge"預備接收資料之後，此節點SGSN1 使已緩衝之資料封包在步驟9中繼續傳送至節點SGSN2 〇 爲了使決定用戶台MS所需之資料封包不爯發送至 SGSN1，而是直接發送至新的服務節點SGSN2，則閘路 節點GGSN對此種變化必須是知悉的。這是藉由上下文 調整時所需之要求來達成，此種要求在步驟1 0中由 SGSN2傳送至閘路節點GGSN。 在接收相同版本之服務節點之上下文時上下文調整時 所需之要求是資訊"Update PDP Context Request"時，則 第二服務節點在此處所考慮之情況中使用一種型式是 "Create PDP Context Request11之資訊作爲要求。此種資 訊相對於GTP版本1之資訊"Update PDP Context Request"而言具有此終端機MS之IMSI及NS API。此種 閘路節點在此種型式之資訊時不須等候：此種資訊以確 定之TEID被發送；其因此不必解釋此資訊之此種TEID ，而是在其所傳送之表格中直接依據IMSI及NS API來 辨認相關之上下文。這樣所發現之上下文登載會被實際 化，其方式是使新的服務節點SGSN2以及GTP版本對 -14- 525397 五、發明説明（13) 應於此上下文登載，據此來進行GGSN及服務節點之間 之通信。 若閘路節點已成功地進行此種運算，則其在步驟1 1 中藉由型式是"Create PDP Context Response"或"Update PDP Context Responsen2此種資訊對新SGSN2確認此種 運算已成功。 在終端機MS在步驟18中已獲得其RAU-需求 11 R 〇 u t i n g A r e a U p d a t e A c c e p t"之確認之前，此二個服務 節點仍須與行動式無線電通信系統之Home Location Register (HLR)進行資訊交換，在此種過程中在此種暫存 器中須註明此終端機分配給新服務節點SGSN2。這些步 驟與GSM-或UMTS無線電通信系統中已爲人所知之步 驟並無不同，此處不再詳述。 另一種方式是，爲了在步驟1 0中使用此種資訊 ’'Create PDP Context Request "，則亦可使用一種相對於 GTP-版本1作微不足道之修改之型式是"Update PDP Context Request”之資訊。此種已修改之資訊含有〇値之 TEID及終端機MS之IMSI及NSAPI。閘路節點GGSN 末發出0値之TEIDs。若其接收一種TEID = 0之"Update PDP Context Request"，則由此可決定出：TEID不是由 閘路節點GGSN所設定，因此在GGSN之上下文表格中 不會有一種登載對應於此TEID。此GGSN因此追溯到 IMS I及NS API之情況中，以便辨認此種與"Update PDP Context Request”相關之上下文且使其以上述方式而被實 -15- 525397 五、發明説明（14) 際化。 另一種可能方式是：步驟1 〇之實際化要求所需之第 二服務節點各別選取此種GTP版本（其中在步驟S7中 已獲得此資訊"SGSN Context Acknowledge")，此處是版 本0。以此種方式，則第二服務節點對GGSN就相關之 上下文而言是一種版本0-節點，則藉由指出此流動標纖 即可辨認此種可調整之上下文，且由閘路節點可獲得同 樣是版本〇之回答資訊。以此種方式可在新的服務節點 SGSN2上正確地設定此上下文，當所使用之GTP版本保 持相同時。 由第一服務節點GGSN1至第二GGSN2設置此通道所 用之第二種方法不同於第4圖所示之信號流程圖之處是 :第二服務節點在步驟1 0中使用版本〇以便使上下文 實際化，其中第二節點在步驟7中已獲得此通道之流動 標纖。閘路節點在步驟1 1時同樣使用版本0對此進行 回答。即，雖然第二服務節點SGSN2及閘路節點GGSN 掌握版本1，其仍使用版本0繼續道引此種版本0所形 成之通道。 由於在第二種方法中在轉移至第二服務節點時此通道 之版本未改變，則特殊之措施是需要的，若此通道第二 次須轉移至版本1之第三服務節點時。 在此種版本0-通道由第二服務節點轉移至第三服務節 點時，此二個節點使用版本1，則會形成此種和以下情 況相同之問題：一種在版本1之第一服務節點和版本〇 -16- 525397 五 '發明説明（15 ) 之閘路節點之間所形成之通道必須轉移至版本1之第二 服務節點。此問題之稍後所描述之一些解法因此可用在 此情況中。 第2圖是一種組態，其中GTP版本1之第一節點 SGSN1，GTP版本1之閘路節點GGSN以及版本〇之第 二服務節點S GS N2互相通信。第一服務節點s G S N 1及 聞路卽點GGSN使用此種由TEID(Tunnel Endpoint Identifier)所表示之版本1之資訊，第二服務節點sGSNl 和SGSN2使用此種由流動標纖及TEID所表示之版本0 之資訊。 第5圖所示之通道之形成及轉移所需之各步驟之順序 對應於第4圖。當然，不同資訊所用之GTP版本亦藉巾 粗、細箭頭來區別。步驟2和3中該上下文之要求 "Create PDP Context Re quest"及對此之回答就其目標之 設定而言是與第4圖者相對應，但其不同處是：其使用 G T P版本1，因此，此閘路節點g G S N使一種T EID分配 至上下文且向第一服務節點S G S N 1報告此事。 依據GTP-版本0之此種要求"GSGN Context Request11 (其使第二服務節點SGSN2在步驟6中指向第一服務節 點）是由第一服務節點以"SGSN Context Response"版木 0來回答。在此種純粹依據版本〇來運行之通道設置中 ’此種ΜήΛ在其貝日Λ兀素（IE)"PDP Context"中包含一種 由閘路通道在此種上下文所用之第一服務節點上所設定 之流動標纖。此處由於此種流動標纖不存在，則在第一 -17- 525397 五、發明説明（16 ) 服務節點中一種流動標纖依據先前已決定之方法由閘路 節點GGSN所設定之TEID算出。算出此種流動標纖之 一種特別簡單之方法是使用TEID之二個低値之位元組 作爲流動標纖且忽略二個較高値之位元組。此種流動標 纖由第二服務節點在其步驟1 0中對準閘路節點之要求 中作爲上下文之調整用。由於本方法對閘路節點GGSN 而言是〃已知的〃（藉本方法使第一服務節點GGSN1 可由TEIDs中產生此流動標纖），則第一服務節點在接 收相對應之流動標纖時在一種對上下文實際化之要求時 在步驟1 0中可輕易地由第二服務節點找出其表格中少 數之上下文（其可與此種實際化有關）。在此種情況下 測定實際上之相關性是極容易的。 使上下文實際化之另一種可能性是使用0値之流動標 纖’類似於上述第4圖所述者。由於具有此種値之流動 標纖不能另外設定或所有情況都由一種版本〇之服務節 點用在型式是"Create PDP Context Requestπ之資訊中（ 其中此通道之流動標纖在此資訊之發送時間點時仍然未 知）’則在閘路節點GGSN由第二服務節點SGSN2接收 此種流動標纖値是〇之資訊時，此閘路節點◦ G s N可由 此推斷：此流動標纖不可由其本身來設定，且因此在忽 略此流動標纖及使用此種一起傳送之辨認資訊（即，終 端機之包含在資訊頭中之TID中之iMSI及NSApi )時 須使此資訊分配給某一通道。 其它方式是仍可對GTP版本0進行補充，此時若第二 -18- 525397 五、發明説明（17 ) 服務節點S G S N 2由第一服務節點得到—種流動標纖設定 至0之資訊時，則第二服務節點s G s N 2發送一種型式是 "Create PDP Context Request"之資訊。 在第3圖所示之第三組態中，此二個服務節點SGSN工 、SGSN2屬GTP版本1且閘路節點GGSN是版本〇之節 點。此通道之構成及其由第一服務節點S g S N 1轉移至第 一服務節點S G S N 2是顯不在第6圖中。此通道在步驟1 至4中之構成方式是與第丨、4圖中者類似。此二個服 務節點必須使用版本1。爲了使服務節點S G S N 1和閘路 節點G G S N之間所處理之流動標纖可傳送至第二服務節 點S G S N 2 ’則須藉由版本1之連接來達成。爲了使流動 標纖傳送至第二服務節點SGSN2，則第一服務節點 SGSN 1須增加二個高値之位元組使成一種TEID之格式 ’其在步驟7中（SGSN Context Response)傳送至第二節 點 SGSN2。 依據本方法之第一種形式，二個在第6圖中以虛線箭 頭所示之資訊然後互換：節點SGSN在步驟ι〇·中發送版 本1之上下文調整（Update PDP Context Request)之要求 至閘路節點G G S N。由於G G S N只掌控版本〇，則其通知 弟一卽點S G S N 2 (步驟1 0 " ) ••其不能處理此種要求。 第二節點然後辨認：閘路節點需要一種具有流動標纖之 版本0之資訊，且因此在步驟1 〇中產生一種新的要求 ’這次是依據版本0，其中加入此種由第一節點SGSN1 所接收之TEID之二個低値之位元組作爲流動標纖。 -19· 525397 五、發明説明（18 ) 依據第二種方式，第一服務節點SGSN1使用二個具 有一種預定値之位元組，以便使分配至此通道之流動標 纖擴充成TEID之格式。此種預定値（此處是0 )在正常 產生版本1之PDP上下文時不設定，使第二服務節點 SGSN2可辨認此二個位元組之値，第7步驟中以TEID 之格式傳送至第二服務節點之資訊是一種流動標纖，其 又形成且在步驟10中使上下文實際化所需之要求中可 立刻選取版本0之可由閘路節點GGSN所解釋之資訊格 式。 由於在第二種形式中由第二服務節點SGSN2所使用 之用於實際化要求之此種版本不是在第二節點SGSN2和 閘路節點GGSN之間對話時由GGSN所決定，而是由資 訊"SGSN Context Response"之版本所決定，則此種方法 亦適用於上述已提及之情況，即：一種通道，其原來形 成在版本0之一個服務節點SGSN1及版本1之GGSN之 間且隨後在此通道原來所使用之規約版本保持在版本！ 之第三服務節點時切換至版本i之第二服務節點SGSN2 〇 依據第三種方式’第7步驟中即將傳送之上下文資訊 以下述方式擴充：流動標纖及TEID都可被傳送且作爲 特徵用。這可藉由其它資料欄添加至上下文資訊中而達 成’上下文接收此流動標纖，使得當已知時此TEID及 流動標纖都可傳送至第二服務節點S G S N 2。亦可添加-種簡單之旗標，其狀態表示一種資訊之TEID欄之內容 -20- 525397 五、發明説明（19 ) 以作爲TEID或作爲流動標纖。TEID之値之範圍因此末 受限。 第三種方式亦適用於使一種以版本〇來操作之通道轉 移至版本1之第三服務節點。 第四種可能方式是：在服務節點之間亦使用GTP版本 0。第二服務節點GGSN2以GTP版本1開始與第一節點 SGSN1對話，這樣可了解第一節點（SGSN1);第一節點 因此須以正常方式以GTP版本丨來回答。但第一節點 SGSN1僞裝〃未了解〃此GTP版本1之資訊，其促使第 二服務節點S G S N 2來使用版本〇，因此可傳送此流動標 纖。此種方式允許一種版本〇之通道在保持版本之情況 下轉移至第三服務節點。 符號說明 SGSN1、SGSN2···服務節點 GGSN···閘路節點 MS…終端機 IE…資訊元素 HLR···原位暫存器

Claims (1)

1. 525397 六、申請專利範圍 1 · 一種行動式無線電通信系統（特別是GPRS系統）中 使通道由第一服務節點（SGSN1)轉移至第二服務節點 (SGSN1)所用之方法，此行動式無線電通信系統包含各 服務節點（SGSN1，SGSN2)及一種閘路節點（GGSN)，這 些節點中至少一個是GTP規約之版本〇用之節點且其 它節點屬GTP規約之版本]_，第二節點（SGSN2)獲得一 種〃要求〃資訊使終端機（MS)之通道轉移（RAU Request) 且使此種與通道有關之上下文調整所用之要求可指向 閘路節點（GGSN)，其特徵爲：在第一服務節點（SGSni) 是一種版本0之節點且第二服務節點（SGSN2)，閘極節 點(GGSN)屬版本1時，則上下文調整所需之要求含有 此相關通道之IMSI及NSAPI之說明。 2. 如申請專利範圍第1項之方法，其中此要求是一種 "Create PDP Context'Request"型式之資訊。 3. 如申請專利範圍第1項之方法，其中此要求是一種 nUpdatePDP Context Request"型式之資訊，其含有〇値 之TEID及含有此通道之有關IMSI及NSAPI之說明。 4. 如申請專利範圍第1項之方法，其中閘路節點（GGSN) 及第二服務節點（SGSN2)依據GTP規約之版本〇來驅動 此種已轉移之通道。 5. —種行動式無線電通信系統（特別是GPRS系統）中 使通道由第一服務節點（SGSN1)轉移至第二服務節點 (SGSN1)所用之方法，此行動式無線電通信系統包含各 服務節點（SGSN1,SGSN2)及一種閘路節點（GGSN)，這 -22- 525397 六、申請專利範圍 些節點中至少一個是GTP規約之版本〇用之節點且其 它節點屬GTP規約之版本卜第二節點（SGSN2)獲得一 種要求資訊使終端機（M S)之通道轉移（R A U R e q u e s t) 且使此種與通道有關之上下文調整所用之要求可指向 閘路節點（GGSN)，其特徵爲：在第一服務節點（sgsnu 和閘路節點（GGSN)屬版本1之節點且第二服務節點 (SGSN2)屬版本〇之節點時，或閘路節點（GGSN)屬版本 〇之節點且各服務節點（SGSN1、SGSN2)分別屬版本丄 之節點時，則第一服務節點（SGSN 1)使一種配屬於上下 文之流動標纖傳送至第二服務節點，第二服務節點 (SGSN2)在添加此種所配屬之流動標纖之情況下發送 此種與此通道相關之上下文調整所需之要求。 6 ·如申i靑專利範圍第5項之方法，其中在第一服務節點 (SGSN1)及閘路節點（GGSN)屬版本1之節點且第二服 務卽點（S G S N 2)屬版本〇之節點時，則第一*服務節點 (SGSN1)分配此上下文一種具有預定値之流動標纖，其 在一種通道由版本1之服務節點轉移至版本〇之服務 節點時是特定的。 7 ·如申請專利範圍第6項之方法，其中流動標纖之値是 0 ° 8 ·如申請專利範圍第5至7項中任一項之方法，其中第 二服務節點（SGSN2)發送一種"Create PDP Context Request"型式之資訊以作爲此種與通道相關之上下文 調整時所需之要求。 -23- 525397 六、申請專利範圍 9.如申請專利範圍第5項之方法，其中在第一服務節點 (SGSN1)及閘路節點（GGSN)屬版本1之節點且第二服 務節點（SGSN2)屬版本0之節點時，則第一服務節點 (S G S N 1)依據一種已設定之方法使流動標纖分配至每 一依據版本1而設置之上下，且閘路節點（GGSN)依據 相同之方法來分配相同之流動標纖。 1 〇·如申請專利範圍第9項之方法，其中此流動標纖之 分配方法包含：此種流動標纖以TEID之二個低値位元 組來同時進行設定。 1 1 ·如申請專利範圍第5項之方法，其中在閘路節點 (GGSN)是版本0之節點且此二個服務節點（SGSN1、 SGSN2)屬版本1時，則由閘路節點（GGSN)分配至此通 道之流動標纖傳送至一種由SGSN1發送至第二服務節 點（SGSN2)之資訊之TEID欄中。 1 2.如申請專利範圍第1 1項之方法，其中第二服務節點 發送一種依據版本1使上下文實際化所需之要求至閘 路節點（GGSN) ’且若閘路節點（GGSN)不能處理此要求 時，則閘路節點由TEID欄中抽出此流動標纖且在使用 此種已抽出之流動標纖之情況下發送一種依據版本〇 之新要求。 1 3 ·如申請專利範圍第1 1項之方法，其中在TEID欄之 未由流動標纖所塡入之位元組中載入一種預定之値， 其就一種通道在二個版本1之服務節點之間藉由版本 0之鬧路節點進行轉移而言是特定的。 -24- 525397 六、申請專利範圍 14·如申請專利範圍第13項之方法，其中若TEID欄含 有該預定之値時，則第二服務節點（SGSN2)依據版本〇 發送此種上下文實際化時所需之要求。 1 5.如申請專利範圍第1 3或1 4項之方法，其中此特定 値是0。 16.如申請專利範圍第11項之方法，其中除了 TEID欄 之外又傳送一種標記，其指出：此TEID欄是否含有一 種TEID或含有一種流動標纖。 i 7.如申請專利範圍第5項之方法，其中在閘路節點 (GGSN)是版本0之節點且各服務節點（SGSN1、SGSN2) 是版本1之節點時，則由閘路節點（GGSN)分配給此通 道之流動標纖傳送至一種由第一（SGSN 1)至第二服務 節點（SGSN2)之資訊之與TEID欄不同之特殊之資料欄 中。 -25-