通信接口的製作方法

2023-11-06 13:27:47

專利名稱：通信接口的製作方法
技術領域：
本發明涉及通信接口和對這種通信接口進行操作的方法。
技術背景隨著對網際網路訪問的改進並且在網際網路上利用VoiP進行通信的語 音應用，以及用來玩遊戲和下載或調整時間的小型可攜式設備的使用的 不斷增加，通過最終鏈路與這些設備連接這一問題對用戶的體驗產生了 不利的影響。開發中的技術目前允許數據在面向連接的網絡(例如PSTN) 和無連接網絡(例如網際網路)二者中以很高的速度傳送。在許多情況下， 網絡的最終接入點本身是無線鏈路，無線鏈路可以是公共接入無線點， 例如通常設置在辦公室、咖啡廳和商場以便人們能夠使用膝上型計算機、 PPC (例如Hewlett-Packard IPAQ )和其他設備藉助於網際網路或全球資訊網 來進行通信。這種通信能力的可獲得性(availability)以及具備使用視頻、數據和 程序以及語音的能力的不斷複雜化的行動電話的發展，意味著最終用戶 可以在電話通信(telephony)中訪問並傳送非常大的數據文件和/或諸如 VoiP或視頻的對時間要求嚴格(time critical)的數據。如果行動裝置與接入點之間的連接例如是藍牙和其他低功率無線電 或者例如是經由紅外埠的，則網絡接入點與行動電話或PPC之間的最 終鏈路上可能有明顯的帶寬限制。當需要在該連接上處理多個連接或高密度數據消息時，上述帶寬限 制可能導致數據消息的明顯丟失，因此必須對最終鏈路進行最有效的利 用。發明內容本發明提供了一種對位於通信網絡與最終用戶設備之間的最終鏈路 上的通信接口進行操作的方法，該方法包括以下步驟針對每個鄰近的數據消息序列，在所述通信接口與所述設備之間創 建鏈路標識；在所述接口處存儲所述鏈路標識到源地址和目的地址的映射；針對從所述設備接收到的每個尋址消息，用與所述目的地相對應的報頭信息來替換鏈路標識信息；以及針對從源接收到的每個消息，用鏈路標識信息來替換報頭信息，由此，極大地提高了最終鏈路中的數據消息的數據有效載荷與目的地數據的比例。本發明的第二方面提供了 一種位於通信網絡與最終用戶設備之間的 最終鏈路上的通信接口，該通信接口包括無線收發機，用於向所述最 終用戶設備發送數據消息並從所述最終用戶設備接收數據消息；與通信 網絡的高速連接，用於向和從遠程設備發送和接收數據消息；以及控制 器，該控制器針對所述最終用戶設備與遠程設備之間的每個鄰近的數據 消息序列，創建用於去往或來自所述最終用戶設備的消息的第一地址， 和用於所述遠程設備的第二地址，所述控制器存儲有所述第一地址和所 述第二地址之間的映射，並且在接收到來自所述最終用戶設備的數據消 息時，用所述第二地址替換所述第一地址，而在接收到去往所述最終用 戶設備的數據消息時，用所述第一地址替換所述第二地址，所述第一地 址相比所述第二地址包括少得多的數據，由此通過所述最終鏈路傳送到 所述最終用戶設備的每個消息的數據有效載荷都被最大化。


下面將參照附圖，僅以實例的方式對根據本發明的通信接口進行描 述，附圖中圖1是示出通信系統中的接口的示意性框圖； 圖1A更詳細地示出了圖1的一部分；圖2到圖9示出了在該接口的各個操作階段中的消息(數據報)結構；圖10和圖11分別是針對伺服器和行動裝置的類圖(class diagram);而圖12到圖17是分組序列(packetsequence)圖。
具體實施方式
首先參照圖1,接入點1提供了到網際網路2的網關，使得能夠通過 網際網路2與遠程終端、網際網路節點或伺服器3、 4進行通信。到網際網路的 連接是已知的形式並且以己知方式運行以向並從遠程伺服器3 、 4發送和 接收消息。這種消息(或數據報)包括報頭和"數據有效載荷"，報頭定 義了數據報的目的地以及用於對該數據報作出應答的返回地址。報頭數據的長度取決於所使用的協議並可以包括相當大量的字節。 一些協議試圖使報頭數據量最小化，但這些協議都確定了特定數量的包括 一個或多個字節的欄位來實現數據報的源和目的地。其他特徵包括命令數 據，例如每個所發送的分組中所要求的信息(例如在進行HTP請求時)。接入點1因此包括IP (網際網路協議)棧5，用於通過其與網際網路2 的寬帶連接來接收和發送數據報。接入點1與遠程設備3、 4之間通過網際網路2的通信是標準格式的， 並且因為這種通信的設置和運行是公知的，所以在此不作進一步描述。接入點1的另一標準運行特徵是允許配備有藍牙的行動裝置(例如 行動電話7)與接入點1進行通信和經由接入點1進行通信的藍牙無線通 信配置6。將配備藍牙的設備彼此配對就其正常運行而言也是公知的，所 以這些基本系統在此也不作進一步描述。然而， 一旦完成了這種配對， 就在接入點1處提供特殊的控制器8 (此處為BLIP控制器8)以管理並 提高接入點1與行動裝置7之間的通信效率。為避免引起懷疑，接入點1與行動裝置7之間的該最終鏈路不必須 是藍牙鏈路，因為本發明可用於針對其他類型的最終鏈路(包括但不限 於紅外傳送、其他低功率無線鏈路以及其他具有有限帶寬的鏈路)來改 進接入點1與行動裝置7之間的通信效率。在運行於提供基本連接的可靠底層藍牙協議(RFCOMM-ACL)下的 藍牙鏈路的當前情況下，僅需要隨每個分組發送最小量的附加信息。因 此對於行動裝置7與遠程伺服器之間的包括一序列數據報(或分組)的 每個通信而言， 一旦BLIP控制器8和行動裝置7啟動了通信，就僅需要 幾比特的數據(在同一行動裝置上實現多個應用)和一些非常小的分組 排序編號(sequencingnumbering)。接著考慮圖1A，其利用了OSI分層模型的基本概念，藍牙層6A、 6B近似相當於提供基本成幀和鏈路同步的OSI鏈路層。如圖1A所示， 客戶機和伺服器都使用相同的0++類作為他們的服務。圖中可以看到核 心類。僅當存在寬帶連接時，LAN處理器IO才用於接入點1中。鏈路管 理器11A、 IIB保持著(最多16條)虛擬鏈路的狀態控制，其中兩條可 以為特殊用途而預留，從而使得在任意時刻都能夠通過藍牙連接建立14 個可用的通信鏈路，並為上層12、 13、伺服器和客戶機類提供一組公共 控制和數據基元(primitive)。藍牙處理器6A/6B在保持鏈路整體性的同 時，向和從鏈路層發送和接收數據分組。可以從圖10的類圖中看到伺服器在接入點中的運行的更詳細視圖， 而圖11以詳細類圖示出了行動裝置的運行。下面通過參照圖2到圖9，來考慮鏈路管理器IIA、 11B與藍牙對 6A、 6B之間的通信的協議和運行。在通信中使用了有線協議，從而參照圖2並假設總是首先傳輸第一 字節的第一位，通用格式包括兩字節的分組報頭，之後是包括命令序列 或數據有效載荷的多個字節。分組是命令或純數據，有效載荷或命令相 對於被設定為1023位元組的分組最大值而言長度是可變的。選擇1023字 節的固定限制是為了避免更小的數據分組弓I起額外的分組報頭。需要超過 1023位元組的有效載荷的應用被要求處理超大的數據載荷的碎片，因而通過 要求高的或可變長度的有效載荷長度定義欄位，使得不增加報頭尺寸。因此如圖3所示，兩字節的報頭欄位具有可能的最小值並利用字節 1的前4位來提供鏈路標識，該鏈路標識使得源和目的地可以引導出 (direct)藍牙鏈路上的最多16個通信。不使用鏈路確認，因為我們假設藍牙連接是可靠的，從而不需要分組標識和流控制技術。包括第一字節的第5位和第6位的下一欄位是簡單序列號，用於檢査所接收的分組是否為正確的序列。儘管我們假設底層藍牙連接是可靠 的，但是序列號僅確保如果在處理連續消息中出現錯誤，則可以採取校 正動作。發送方和接收方都增加各自的計數，從而在每個方向(0,1，2,3，0,1，2,...)保持發射和接收序列計數器，由此為連接提供某種類 型健全檢查。假設底層連接是可靠的，那麼就不需要更長序列檢查。最 終，10位欄位(字節1的最後2位加上字節2的8位)定義了允許多達 1023位元組的有效載荷的長度(不包括報頭的16位)。不使用分組的交織(interleave)，從而鏈路管理器1A和11B可用此在尋找另一分組報頭 之前接收消息中的剩餘數據(或命令)。因此，發送方(接入點或設備) 總是一次利用僅16位來發送一個完整的分組，以高效地向和從正確的源 和目的地輸運多達1023位元組的數據。圖4示出了命令序列，其在需要時跟隨著報頭。緊接著報頭的2個 字節可包括命令代碼和版本定義，命令代碼指示了所需的操作而版本確 保了接入點與設備之間相同層級的協議支持。如果設備發出了接入點不 能支持的請求，那麼它將返回指示該設備請求不能被處理的結果代碼。 這樣的目的是使得恆定值和行為能夠在更新版本中變化而無需與先前版 本的向後兼容。由命令代碼定義的操作包括Bad Version、NewLink、NewLink Result、 LinkDown、 Heartbeat和VersionError。可以根據需要向命名空間中添加 其他操作。因此，例如，如果接入點檢測到版本不兼容，它將返回圖5所示的 簡單分組，該分組包括兩個字節錯誤、命令代碼"BadVersion"以及指示了 接入點伺服器所運行的版本的版本欄位。圖6中示出了在設備7與目的地之間創建新鏈路以產生新的虛擬鏈 路。接入點伺服器將分配鏈路ID。因此，在報頭和命令代碼以及版本字 段(4位元組)之後，將定義在目的地主機(例如3、 4)與接入點1之間 使用的協議。該協議將取決於由行動裝置7發起的鏈路的類型。為鏈路標誌標識分配了一個字節，鏈路標識使得設備能夠定義關於所創建鏈路的額外信息，例如，標誌(flag)可指示出所使用的地址是Ipv4還是lpv6， 地址串的格式，例如地址是否加點(例如10丄2.3的格式)，或地址是 resolve.me.com格式的串(DNS地址類型)。標誌還可指示鏈路是僅供流 出(outgoing)數據使用，即指示對於此鏈路沒有流入數據業務，而且不 會通過該藍牙連接發送任何LAN業務。鏈路標誌欄位中還定義了其他特 徵，如重用地址(指示如果本地埠在用，則可以不顧這種情況而與所 定義的本地埠創建連接)。目的地長度欄位中提供了兩個字節，使得能夠指定目的地地址的長 度，而在隨後的兩個欄位中定義了設備的兩字節源埠和目的地埠 。最終，目的地地址數據被保存在數據分組的最後一個欄位中，使得 接入點能夠與期望的遠程終端目標建立通信。現在轉到圖7，對於newlink (新鏈路)命令分組的響應是 newlinkresult，其包括報頭和命令/版本欄位、結果代碼、在整個通信中要 使用的並且反映了最後6個字節中的源IP位址和源埠 (如由之前發送 的newlink命令中的目的地埠和地址欄位定義的)的鏈路id。因此，結果代碼包括響應，該響應指示了由接入點l接收的對於 所發送的請求的響應並包括"LinkcreationOK"，其表示該鏈路目前正 在運行並且所返回的鏈路標識是有效的； "FailedLinkCreationDNSerror"，其表示目的地地址中給出的名稱不能被 解析；"FailedLinkCreationNoResponse"，其表示遠程節點無法作出響應； 或"FailedLinkCreationNoLinks"，其表示接入點1與行動裝置7之間沒有 任何空閒鏈路可用。圖8是LINK DOWN命令消息，該命令代碼指示所標識的鏈路不再 被使用。該命令可從設備7發送到接入點1，以便通告己經完成了通信所 以伺服器13可以終止真實的IP通信。另選的是，如果伺服器13檢測到 運行鏈路已經終止，其它會向行動裝置7發送該命令。最後，圖9中示出了簡單的"heartbeat(心跳)"命令，以周期間隔(例 如大約每13秒)在每個方向上發送簡單的4位元組消息，以確保鏈路仍在運行(live)。只要在延長時段(例如29秒)內沒有接收到心跳(表示 沒有接收到兩個這種連續的心跳命令)，就會導致接入點1和行動裝置7 都終止藍牙連接。下面參照圖10到圖11來考慮伺服器類圖(接入點1)和設備客戶 機類圖(行動裝置7) 。 BLIP接入點和客戶機設備都使用藍牙處理器和 鏈路管理器的相同核心類。這兩個類均假設符合(adhere to) IControl接 口的控制/報告類。該接口定義了控制客戶機或伺服器類所必須提供的接 口的最小集合。實質上這些僅是報告回調(callback)，對於客戶機是 "IPLiteClient"類，而對於伺服器是"IPLiteServer"類。控制器創建了藍牙事 務處理器(BTTH)和鏈路管理器(LinkManager)，並將兩個處理器彼 此關聯起來。在被用於伺服器模式時，兩個處理器都大致地處理事件， 僅當藍牙鏈路完全關閉，且兩個對象都需要被清除(clean)時才僅報告 回控制器。在被用於客戶機模式時，處理器將所有事件都報告給用戶應 用。此設計是通過用戶提供的回調來實現這一點的。這種實現對於設計 的影響在於，其被封裝於DLL中並且DLL可由多個應用來使用。每個 應用都創建其與接入點的邏輯鏈路。這是必需的，否則每個應用都不得 不共享同一用戶鏈路空間(即，被限制於14條虛擬鏈路)。用戶回調有 一些公共欄位也有可變長度的有效載荷。公共欄位返回了伺服器句柄、 鏈路ID和結果代碼。結果代碼確定了有效載荷的內容(例如，可以是命 令響應或流入數據)。用戶應用必須利用鏈路控制調用或發送數據，來 指定所有事務上的伺服器句柄以及鏈路ID。IPLiteCUent類主要定義了 BLIP與應用之間的層，並且因此提供了 到應用的接口。這可變為給每個客戶機平臺其自身的外觀和感受。另外，LinkManager使用多個LAN handler類，與Link ID--關聯，以便在與IPLiteServer—起使用時提供接口並控制寬帶鏈路。針對每個客戶機(或 伺服器)提供並耦接一個BTTH和LinkMnager給出了一個連接的良好封 裝(encapsulation)。這些類一同來管理IP協議事務和控制。圖11示出了行動裝置類圖。伺服器使用客戶機套接字(socket)來索引遠程客戶機結構的表，除了套接字是用於連接到伺服器的套接字以 外，客戶機使用了相同的機制。在研究了 Bluetooth Lite (BLIP)系統和接入點以及行動裝置基本事 務的協議結構之後，我們下面考慮針對各種發生的通信的消息流。下面參照圖12來考慮伺服器初始化和連接。當落入廣告(advertise) 其具備藍牙處理能力的接入點1的範圍內時，行動裝置7發現服務並發 送正常藍牙連接消息以確定其存在。接入點1可以處理來自配備有藍牙 的設備的最多7個同時連接，這是協議目前規定的最大值。連接消息未 被明確應答，因為如果其失敗則設備7將從較低藍牙層得到藍牙錯誤 (B luetooth error )。首先，伺服器設置包括多個步驟。控制應用調用在IPLiteSever範例 (instance)中的Open (打開)。這設定了藍牙服務廣告並對連接進行監 聽。 一旦設備進行連接，就產生藍牙處理器和鏈路管理器。LinkManager 產生一些LanHandler對象，而BTTH監聽對於客戶機套接字的請求。 IPLiteserver在由客戶機套接字索引的列表中保存了對兩個處理器的引用 (reference)，並監聽其他藍牙連接。現在轉到圖13，當行動裝置7位於經適當配備的接入點1的範圍內 吋，其可通過向其blip客戶機12發送打開連接消息而初始化。blip客戶 機隨後通過向接入點發送連接消息來嘗試打開接入點1藍牙RFCOMM 連接。接入點1返回確認消息，接著blip客戶機12創建LinkManager 11A 和藍牙處理器(BTTH)6A。blip客戶機12隨後通過向BTTH發送syncLink 消息來使連接同步，其中BTTH向接入點1中的客戶機發送了 Sync消息。 BTTH隨後向blip客戶機12返回確認並等待來自接入點1的SyncAck消 息。 一旦設備7和接入點1同步，BTTH就發送表示了客戶機和伺服器已 彼此初始化的事件代碼"NotifyLinkReset"，從而允許隨後利用BLIP協議 進行分組傳送。 一旦初始化完成，接入點1的伺服器和blip客戶機12就 如前所述開始傳輸和監控心跳。對行動裝置7和接入點1進行了初始化之後，將分別按照圖14和 15所示的處理來創建新鏈路，我們下面將描述設備到接入點以及接入點到遠程位置信號流。因此，在行動裝置7被用戶要求從遠程站點3、 4獲得信息時，其產 生要傳送至其BLIP客戶機12的TCP請求。BLIP客戶機12指示 LinkManager IIA創建鏈路，從而向藍牙處理器6A發送命令消息。隨後 向接入點發送NewLink命令消息，該接入點由於底層的可靠連接而被假 定為已經確認。在接入點1處，藍牙處理器6B接收Newlink消息，藍牙處理器6B 處理對於鏈路管理器11B的命令，鏈路管理器11B將Open (打開)命令 轉發到Lan處理器10， Lan處理器10藉助於通信網絡向遠程IP節點3、 4發送命令數據報。LAN處理器10返回LinkResult命令消息到藍牙處理 器6B，藍牙處理器6B向行動裝置7發回NotifyNewLink結果數據報， 該數據報在行動裝置7處由藍牙處理器6A接收。隨後通過鏈路管理器11A 和BLIP客戶機12向具有該結果的設備發送Process Command消息。如果 出於任何原因該請求失敗，則客戶機將不會接收到NewLink命令和消息而 是接收到NewLinkFailure命令消息，該命令消息將由設備來適當處理。一旦建立了設備與遠程IP節點之間的鏈路，數據傳輸就是以下的簡 單過程Blip客戶機12調用客戶機桟，而BTTH 6A利用鏈路管理器11A 通過該鏈路來發送後續數據分組。在接入點1處，數據分組被藍牙處理 器6B獲取，傳遞到鏈路管理器11B並接著傳遞到具有針對遠程IP節點 3、 4的適當地址報頭信息的LAN處理器10。 LAN處理器10從遠程IP 節點3、 4接收到的返回數據分組被返回到鏈路管理器11B，在鏈路管理 器11B處剝離出TCP報頭(RTP、 UDP等)，隨後藍牙處理器6B經由 該鏈路將分組傳輸給行動裝置7中的藍牙處理器6A。現在轉到圖16， 一旦行動裝置7的用戶停止使用遠程站點3、 4，或 設備確定不再需要該鏈路，就通過相應的藍牙處理器6A、 6B向接入點1 發送LinkDown命令，並隨後發送到鏈路管理器IIB，鏈路管理器11B 確定合適的遠程連接，並將Close (關閉)消息傳遞到LAN處理器10。 LAN處理器10隨後向遠程站點3、 4轉發掉話(drop connection)數據報 並且鏈路管理器從它的記錄中刪除該鏈路。另一方面，如果遠程EP節點3、 4掉話，則圖17示出了這一過程。 在此，經由通信網絡2接收的連接斷開(down)數據報被LAN處理器 IO接收，並且向鏈路管理器llB發送LinkDown命令消息，鏈路管理器 1 IB通過相應的藍牙處理器6B、 6A將LinkDown命令發送到行動裝置7 以供使用。行動裝置7和接入點1現在可以進入各自的清理(cleanup)過程來 釋放鏈路以供隨後使用。在鏈路故障或心跳故障的情況下也有相應的清理過程，其使得移動 設備能夠以一種有組織的方式從用戶應用中退出。儘管此處所指的報頭通常為TCP/TRP/UDP類型，但是還應注意，更 長的報頭，例如在超文本傳輸(HTTP)中使用的報頭，也可以就特定鏈 路完全地緩存(cache)在接入點1處。通過緩存整個HTTP報頭，可以 顯著地節省傳輸時間。例如，457位元組的報頭將僅由4位元組來代表。這種報頭的實例如下n, Ettemnt II, sec: 00:ll:化5cU訴xf, ost: 00'.0d:72Ui:81ie Internet Protocol, Src Add,': 192.168.1.73 (192.16S'丄76), OSt Add'': 207,68.172.246 (207.68.372.245) ajTfai、sroission control Protocol, src Port'. 3301 (3301), Dst Poft: http (80), S柳1, Ado 1， Lan: 403 b Mypectgxt Transfer p"ot。c。1 GET / HTTP/l.lVVlAccept: iraage/srff, iraagaA-xMtaap,化age/jpeg, fn,age/pjp的,app"cat on/x-sl，ockwave-flash, *7*\r、ii Acc印t-Language: en-gb;r、ri Acc印t-Encoding: gzi'p, def1ate、r、nUser-Asisnt; MozmaM.O (compatible: MSIE 6.0; Windows NT 5.1; SV1; .NET CUR 1,1.4322; .NETCLR 2.0.50210VAt， Host: home, microsoft,con《r、n Cormection: Ke印-A"HVe、r、n\r、n在接入點能夠緩存任何類型的報頭，由此得到通過從接入點1到行動裝置7的藍牙鏈路的傳輸時間的顯著節省。儘管此類報頭意味著最初的NewLink消息更加複雜，但是對於每個 此類HTTP消息，其僅發送一次，而在整個轉發和返回消息的序列中都 是有效的。創建了新鏈路時，該鏈路實質上是新的http連接，並且將指 定公共參數，於是對於該連接內的每個單獨的http事務，將得到節省。可以根據事務的類型來將NewLink命令階段所設置的報頭的特定部 分用於用戶或設備7隨後請求的不同交易，並且接入點1可以選擇合適 的部分。
權利要求
1、一種對位於通信網絡與最終用戶設備之間的最終鏈路上的通信接口進行操作的方法，該方法包括以下步驟針對每個鄰近的數據消息序列，在所述通信接口與所述設備之間創建鏈路標識；在所述接口處存儲所述鏈路標識到源地址和目的地址的映射；針對從所述設備接收到的每個尋址消息，用與所述目的地相對應的報頭信息來替換鏈路標識信息；以及針對從源接收到的每個消息，用鏈路標識信息來替換報頭信息，由此，極大地提高了所述最終鏈路中的數據消息的數據有效載荷與目的地數據的比例。
2、 根據權利要求l所述的對通信接口進行操作的方法，其中，在所 述接口處對所述報頭信息進行緩存。
3、 根據權利要求1或權利要求2所述的對通信接口進行操作的方法， 其中所述報頭信息在第一消息中被從所述最終用戶設備發送到所述接 口，所述第一消息在所述最終鏈路具有多條從所述用戶設備到所述接口 的信道的情況下建立額外的這種信道。
4、 根據權利要求1、 2或3中任意一項所述的對通信接口進行操作 的方法，其中所述最終鏈路根據藍牙協議運行。
5、 一種位於通信網絡與最終用戶設備之間的最終鏈路上的通信接 口，該通信接口包括無線收發機，用於向所述最終用戶設備發送數據 消息並從所述最終用戶設備接收數據消息；與通信網絡的高速連接，用 於向和從遠程設備發送和接收數據消息；以及控制器，該控制器針對所 述最終用戶設備與遠程設備之間的每個鄰近的數據消息序列，創建用於 去往或來自所述最終用戶設備的消息的第一地址，和用於所述遠程設備 的第二地址，所述控制器存儲有所述第一地址和所述第二地址之間的映 射，並且在接收到來自所述最終用戶設備的數據消息時，用所述第二地 址替換所述第一地址，而在接收到去往所述最終用戶設備的數據消息時，用所述第一地址替換所述第二地址，所述第一地址相比所述第二地址包 括少得多的數據，由此通過所述最終鏈路傳送到所述最終用戶設備的每 個消息的數據有效載荷都被最大化。
全文摘要
在通往網際網路(2)的接入點(1)處，控制器(8)將與數據報一同接收到的報頭數據縮減為最小報頭，經由藍牙接口傳輸到行動裝置。這是通過為行動裝置(7)和遠程IP節點(3，4)之間的每個通信序列建立鏈路標識而實現的。通過在藍牙鏈路上使用最小報頭，較之使用網際網路上所需的全部報頭的情況，能夠以快得多的速度傳送由行動裝置接收或發送的數據報。
文檔編號H04L29/06GK101258724SQ200680032407
公開日2008年9月3日 申請日期2006年9月6日 優先權日2005年9月6日
發明者尼古拉斯·威廉·法羅 申請人:英國電訊有限公司