處理非永久通信鏈路上的通信的方法
2023-05-25 01:31:21
專利名稱：處理非永久通信鏈路上的通信的方法
技術領域：
本申請涉及通信領域。更具體地，本申請涉及一種處理非永久通信鏈路上的通信的方法。
背景技術：
目前，無線數據通信設備由於受到用戶的歡迎而廣泛使用。
這樣的無線數據通信設備通常具有多個應用程式，如，電子收發消息應用程式、網際網路瀏覽器應用程式、即時收發消息(IM)應用程式等。
在使用中，無線數據通信設備可以臨時位於無線連接不再可用的區域。因而該無線數據通信設備超出覆蓋。
因此，在這樣的情況下，從運行在無線通信設備上的應用程式中生成的輸出消息(也稱為出局消息或要傳送的消息)將對於任何伺服器來說，變得不可送達。更精確地，對於每條輸出消息，傳輸/網絡層單獨地向每個應用程式報告消息傳輸失敗。然後，應用程式必須進行相應地編程以處理這樣的故障。
本領域普通技術人員將意識到，這樣的情況尤其在由多個應用程式傳送大量消息時，會產生很大的開銷。
本領域普通技術人員還將意識到，頻繁的無線通信嘗試將顯著地減少無線數據通信設備的電池壽命。
存在對克服上述缺陷中的至少一個的方法的需求。
該申請的特徵將從查看以下公開、附圖和描述中顯而易見。
為了易於理解該申請，作為附圖中的示例來示出實施例。
圖1是示出了有利地使用處理非永久通信鏈路上通信方法的系統的結構框圖；圖2是示出了使用根據實施例的通信管理單元，與傳輸/網絡層進行通信的多個通信應用程式的結構框圖；圖3是示出了具體是通信管理單元的實施例的結構框圖；在該實施例中，通信管理單元包括調度單元、多個隊列和編隊控制單元；圖4是示出了一種方法的流程圖，其中通信應用程式根據實施例進行通信；執行發現通信鏈路是否可用的檢查；圖5是示出了一種方法的流程圖，其中在通信鏈路可用的情況下，將消息提供給用於傳輸的傳輸/網絡層；圖6是示出了一種方法的流程圖，其中，將消息提供給實施例中的隊列；根據第一步，選擇適合的隊列，以及根據第二步，將消息提供給所選擇的適合隊列；以及圖7是示出了一種方法的流程圖，其中，考慮了當執行檢查以發現通信鏈路是否可用時所發生的情況。
具體實施例方式
根據第一方案，提供了一種處理非永久通信鏈路上的通信的方法。該方法包括中心地從多個應用程式中的至少一個應用程式中接收要傳送的消息；檢查非永久通信鏈路的可用性；如果非永久通信鏈路不可用，則將接收到的消息進行編隊以用於將來的傳輸；以及如果該通信鏈路可用，則將消息提供給傳輸/網絡層。
根據另一方案，提供了一種通信管理單元，用於在非永久通信鏈路上處理從多個應用程式至傳輸/網絡層的通信。所述通信管理單元包括調度單元，用於從多個應用程式中的至少一個應用程式中接收要傳送的消息；編隊控制單元，用於檢查非永久通信鏈路的可用性；以及隊列，用於如果非永久通信鏈路不可用，則將接收到的消息進行編隊，以及用於如果通信鏈路可用，則將消息提供給傳輸/網絡層。
在以下對實施例的描述中，對附圖的參照是作為示例的演示。將理解，可以在不偏離所公開的應用程式的範圍的情況下，可以構造其它實施例。
現在參照圖1，圖1示出了系統的實施例，其中，可以有利地使用以下公開的用於處理非永久通信鏈路上的通信的方法。
系統包括伺服器單元10、網絡12、多個傳送設備16和多個用戶設備18。
伺服器單元10適於將要發送的信號在通信鏈路上提供給多個用戶設備18。在該實施例中，通信鏈路是空中接口，並且未示出。伺服器單元10可以包括永久或暫時地與多個用戶設備18連接的任何類型的處理單元。
網絡12包括區域網(LAN)、城域網(MAN)以及廣域網(WAN)中的至少一個。在實施例中，網絡12包括的廣域網是網際網路。
多個傳送設備16包括無線發射機，適於將數據傳送至多個用戶設備18。
多個用戶設備18包括適於至少處理數據的設備。在圖1示出的一個實施例中，多個用戶設備18是無線用戶設備。應當理解，可以使用不同類型的設備，如個人數字助理(PDA)、智慧型電話等。在實施例中，多個用戶設備18包括，由Research In Motion Limited製造的Blackberry(TM)設備。
更精確地，伺服器單元10適於向網絡12提供，尤其是要發送的信號。
多個傳送設備16中的至少一個適於將信號傳送至多個用戶設備18中的至少一個。
現在參照圖2，示出了多個應用程式20怎樣與傳輸/網絡層24進行通信。應當理解，在這裡公開的實施例中，多個應用程式20位於多個用戶設備18中的至少一個上(圖1)。可選地，多個應用程式可以位於伺服器單元10上(圖1)。
提供了通信管理單元22，通信管理單元22適於接收至少一個由多個應用程式20提供的要傳送的消息。通信管理單元22還適於將要傳送的消息提供至傳輸/網絡層24。
在這裡的實施例中，通信管理單元22以系統級容器來實現。還將理解，通信管理單元22適於監聽與用戶設備18的網絡覆蓋狀態相關的事件。這些事件由低級傳輸層(也稱為傳輸/網絡層24)產生。傳輸/網絡層24可以使用輪詢解決方案，其中，傳輸/網絡層24周期性地嘗試打開至網絡的成功連接，以檢測無線設備18的狀態。然而，傳輸層設計者可以使用一些其它解決方案來始終如一地更新無線設備18地狀態。當通信管理單元22接收來自傳輸層的事件，指示設備超出覆蓋區時，開始將由多個應用程式20中的任何一個提供的消息進行編隊，以及不嘗試通過傳輸/網絡層24來傳輸任何消息。將理解並在以下進一步示出，可以根據不同的標準來選擇隊列。事實上，如實施例中，可以每個目的伺服器一個隊列(即，標準是目的伺服器數)、每應用程式一個隊列(即，標準是應用程式數)、單個隊列等，依據需求而定。當通信管理單元22接收來自傳輸層的事件，指示設備在覆蓋區內時，繼續通過傳輸/網絡層24進行消息的傳輸。將理解，在一個實施例中，通信管理單元22還熟知多個應用程式可以與之進行通信的不同的伺服器。可以在應用程式安裝時間，或者，如在實施例中，在包含通信單元的系統與每個伺服器之間最初發生握手時，來獲得這樣的信息。在這樣的握手之後，可以安裝與該伺服器進行通信的應用程式。將理解，必須通知每個伺服器，無線設備18回到覆蓋區內，然後應當將在伺服器上隊列的任何消息發送至應用程式，這可以通過將任何類型的消息發送至伺服器來實現。所以，如果有至少一個應用程式消息要發送至伺服器，則發送應用程式消息。可選地，可以發送特定的「心跳(Heartbeat)」消息。當伺服器成功地從之前不可達的無線設備18中接收消息時，伺服器重新開始至該設備的消息傳輸。
在公開的實施例中，多個應用程式20包括第一通信應用程式26、第二通信應用程式28和第三通信應用程式30。
仍在圖2中公開的實施例中，第一通信應用程式26提供要傳送至通信管理單元22的第一消息，而第二通信應用程式28提供要傳送至通信管理單元22的第二消息，以及第三通信應用程式30提供要傳送至通信管理單元22的第三消息。
通信管理單元22接收由傳輸/網絡層24提供的狀態信號。狀態信號表示意在用於傳送消息的通信鏈路的可用性。通信管理單元22提供要發送至用戶設備18的傳輸/網絡層24的至少一個消息。
傳輸/網絡層24在通信鏈路(這裡未示出)上傳送要發送的消息。
現在參照圖3，示出了通信管理單元22的示例。
在圖3公開的實施例中，通信管理單元22包括調度單元36、多個隊列32、以及編隊控制單元44。
調度單元36接收由多個應用程式20提供的要傳送的多個消息。
調度單元36適於根據至少一個標準來對多個消息進行分類。在一個實施例中，標準是消息的目的伺服器。事實上本領域普通技術人員將理解，第一給定消息會意在遞送至第一伺服器，而第二給定消息會意在遞送至第二給定伺服器。
多個隊列32中的每個用於存儲由多個應用程式20提供的要傳送至通信管理單元22的多個消息中的至少一個。
在一個實施例中，多個隊列32的隊列數取決於以上公開的至少一個標準。
通信管理單元22還包括編隊控制單元44。編隊控制單元44適於控制多個隊列32。在公開的實施例中，編隊控制單元44接收由傳輸/網絡層24提供的狀態信號，以及將多個相應的啟用信號提供給多個隊列32中的每個隊列。提供給給定隊列的啟用信號表示可用的通信鏈路，因而用於清空給定隊列。將理解，根據依據隊列類型的不同策略，可以將啟用信號提供給多個隊列32。
多個隊列32中的每個隊列提供發送至傳輸/網絡層24的相應隊列消息。
在圖3公開的實施例中，多個隊列32包括第一隊列38、第二隊列40和第三隊列42。本領域普通技術人員將理解，在實施例中，不為給定隊列設置最大大小。然而，優選地，使用從多個應用程式20的任何一個中發送的未決消息數目來設置限制。仍在本實施例中，對於由給定應用程式運行於其中的系統、或在安裝時間由給定應用程式自身規定的給定應用程式，限制低於最大輸出未決消息數目。由通信管理單元22來施加該限制。一旦達到限制，則通知給定應用程式。由給定應用程式負責防止用戶發送任何其它消息。然後，通信管理單元22在達到限制之後，拒絕來自給定應用程式的所有消息。然後，應用程式必須執行對所拒絕消息的必要處理。當通信鏈路可用時，圖3中公開的編隊控制單元44可以將第一啟用信號提供給第一隊列38，將第二啟用信號提供給第二隊列40，以及將第三啟用信號提供給第三隊列42。
響應第一啟用信號，第一隊列38可以提供發送至傳輸/網絡層24的相應隊列消息；而響應第二啟用信號，第二隊列40可以提供發送至傳輸/網絡層24的相應的隊列消息；以及響應第三啟用信號，第三隊列42可以提供發送至傳輸/網絡層24的相應的隊列消息。
現在參照圖4，示出了實施例，其中，示出了通信應用程式怎樣根據實施例進行通信。
根據步驟50，從通信應用程式中接收傳送消息的請求。由通信管理單元22來接收該請求。
在一個實施例中，消息直接提供給通信管理單元22。
根據步驟52，為了發現通信鏈路是否可用，來執行檢查。在實施例中，通過檢查屬於輸出消息隊列的狀態變量的狀態來執行檢查。將狀態變量設置為「啟用」(即，通信鏈路可用)或者「禁用」(即，通信鏈路不可用)之一。本領域普通技術人員應當理解，依據由傳輸/網絡層24提供的接收事件來將狀態變量設置為「啟用」或「禁用」之一。應當理解，由於會有附加原因，甚至在設備在覆蓋區內時，不向伺服器發送任何消息(例如，遠程伺服器中斷)，所以優選地，獨立地為每個隊列保持狀態變量。檢查隊列狀態，以查看是否應當發送新消息或使新消息保持隊列。
在通信鏈路不可用的情況下，根據步驟58，將要傳送的消息提供給隊列。在實施例中，將消息提供給多個隊列32中的隊列。
在通信鏈路可用的情況下，根據步驟54，將消息提供給傳輸/網絡層24(見圖2)用於傳輸。
根據步驟56，由傳輸/網絡層24來傳送消息。
參照圖5，示出了根據一個實施例，怎樣將要傳送的消息提供給傳輸/網絡層24(見圖2)用於傳輸。
根據步驟60，將要傳送的消息提供給相應的隊列。如上所述，依據不同的標準，將要傳送的消息提供給相應的隊列。在該實施例中，使用調度單元36(見圖3)，將要傳送的消息提供給相應的隊列。
根據步驟62，清空相應的隊列，以將隊列消息提供給傳輸/網絡層24。仍在該實施例中，使用由編隊控制單元44(見圖3)提供的啟用信號，來清空相應的隊列。
現在參照圖6，示出了在通信鏈路不可用時，怎樣將要傳送的消息提供給隊列。
根據步驟70，為要傳送的消息選擇適合隊列。依據如上所述的至少一個標準，使用調度單元36(見圖3)，在多個隊列32中選擇適合隊列。
根據步驟72，將要傳送的消息提供給所選擇的適合隊列。
現在參照圖7，示出了在通信鏈路變得可用時發生的情況。
根據步驟80，在傳輸/網絡層24(見圖2)處執行狀態檢查。
根據步驟82，為了發現通信鏈路現在是否可用，執行檢查。
在通信鏈路可用的情況下，以及根據步驟84，將啟用信號提供給多個隊列32。
根據步驟86，將指示提供給遠程單元。事實上，指示用於向遠程單元通知，該遠程單元通過通信鏈路與哪個用戶設備18連接，使得用戶設備18可以在遠程單元上重新註冊。
根據步驟88，清空多個隊列32。
本領域普通技術人員將理解，沒有通信管理單元22，多個應用程式20中的每個將必須獨立地監聽和處理覆蓋區事件。此外，本領域普通技術人員還將理解，必須處理其它不同類型的事件。例如，當用戶關閉或打開無線電/無線覆蓋區時產生的「無線電開/關」事件。本領域普通技術人員將理解，通信管理單元22能夠處理與網絡覆蓋相關的所有事件，以及將這些事件解譯為是否能夠發送消息。
儘管以上描述與發明人當前預計的特定實施例相關，但是將理解，在廣義範圍內的申請包括這裡描述元件的機械和功能的等同物。
權利要求
1.一種處理非永久通信鏈路上的通信的方法，所述方法包括中心地從多個應用程式中的至少一個應用程式中接收要傳送的消息；檢查所述非永久通信鏈路的可用性；如果所述非永久通信鏈路不可用，則將所述接收到的消息進行編隊以便於將來的傳輸；以及如果所述非永久通信鏈路可用，則將所述消息提供給傳輸/網絡層。
2.如權利要求1所述的方法，其中，對所述接收到的消息進行編隊以便於將來的傳輸包括針對所述接收到的消息，從多個隊列中選擇適合隊列，以及從所述所選擇的適合隊列中提供所述接收到的消息。
3.如權利要求2所述的方法，其中，所述多個隊列包括每應用程式一個隊列和每目的伺服器一個隊列之一。
4.如權利要求1所述的方法，其中，所述檢查包括從所述傳輸/網絡層接收狀態信號。
5.如權利要求4所述的方法，其中，響應由所述傳輸/網絡層提供的至少一個事件，來執行所述狀態信號的所述接收。
6.如權利要求4所述的方法，其中，響應狀態檢查的請求，來提供所述狀態信號的所述接收。
7.如權利要求1所述的方法，其中，在具有給定限制的給定隊列中執行所述編隊。
8.如權利要求7所述的方法，其中，使用針對給定應用程式發送的最大消息數目中的至少一個，來生成所述給定限制。
9.如權利要求7所述的方法，其中，當所述給定隊列達到所述給定限制時，將通知提供到給定應用程式。
10.如權利要求9所述的方法，其中，當接收到所述通知時，所述應用程式通知用戶。
11.一種計算機可讀存儲器，包括當執行時進行以下步驟的指令中心地從多個應用程式中的至少一個應用程式中接收要傳送的消息；檢查所述非永久通信鏈路的可用性；如果所述非永久通信鏈路不可用，則將所述接收到的消息進行編隊以便於將來的傳輸；以及如果所述非永久通信鏈路可用，則將所述消息提供給傳輸/網絡層。
12.如權利要求11所述的計算機可讀存儲器，其中，對所述接收到的消息進行編隊以便於將來的傳輸包括針對所述接收到的消息，從多個隊列中選擇適合隊列，以及從所述所選擇的適合隊列中提供所述接收到的消息。
13.如權利要求12所述的計算機可讀存儲器，其中，所述多個隊列包括每應用程式一個隊列和每目的伺服器一個隊列之一。
14.如權利要求11所述的計算機可讀存儲器，其中，所述檢查包括從所述傳輸/網絡層中接收狀態信號。
15.如權利要求14所述的計算機可讀存儲器，其中，響應由所述傳輸/網絡層提供的至少一個事件，來執行所述狀態信號的所述接收。
16.如權利要求14所述的計算機可讀存儲器，其中，響應狀態檢查的請求，來提供所述狀態信號的所述接收。
17.如權利要求11所述的計算機可讀存儲器，其中，在具有給定限制的給定隊列中執行所述編隊。
18.如權利要求17所述的計算機可讀存儲器，其中，使用針對給定應用程式發送的最大消息數目中的至少一個，來生成所述給定限制。
19.如權利要求17所述的計算機可讀存儲器，其中，當所述給定隊列達到所述給定限制時，將通知提供到給定應用程式。
20.如權利要求19所述的計算機可讀存儲器，其中，當接收到所述通知時，所述應用程式通知用戶。
21.一種通信管理單元，用於在非永久通信鏈路上處理從多個應用程式至傳輸/網絡層的通信，所述通信管理單元包括調度單元，用於從所述多個應用程式中的至少一個應用程式中接收要傳送的消息；編隊控制單元，用於檢查所述非永久通信鏈路的可用性；以及隊列，用於如果所述非永久通信鏈路不可用，則將所述接收到的消息進行編隊，以及用於如果所述通信鏈路可用，則將所述消息提供給傳輸/網絡層。
22.如權利要求21所述的通信管理單元，其中，所述隊列包括多個隊列，其中，所述編隊控制單元還用於針對所述接收到的消息，從所述多個隊列中選擇適合隊列，以及從所述所選擇的適合隊列中提供所述接收到的消息。
23.如權利要求22所述的通信管理單元，其中，所述多個隊列包括每應用程式一個隊列和每目的伺服器一個隊列之一。
24.如權利要求21所述的通信管理單元，其中，所述編隊控制單元還用於接收表示所述非永久通信鏈路的可用性的狀態信號，以及用於在所述非永久通信鏈路可用時，產生啟用信號；以及所述隊列還用於在沒有所述啟用信號時，將所述接收到的消息進行編隊；以及在所述啟用信號存在時，轉發所述接收到的消息。
25.如權利要求24所述的通信管理單元，其中，所述編隊控制單元響應由所述傳輸/網絡層提供的至少一個事件，來接收所述狀態信號。
26.如權利要求24所述的通信管理單元，其中，所述編隊控制單元響應狀態檢查的請求，來接收所述狀態信號。
27.如權利要求21所述的通信管理單元，其中，所述隊列包括多個隊列，其中，所述編隊控制單元還用於，針對所述接收到的消息，在所述多個隊列中選擇適合隊列；從所述所選擇的適合隊列中提供所述接收到的消息；以及所述多個隊列中的給定隊列具有給定限制。
28.如權利要求27所述的通信管理單元，其中，使用針對給定應用程式發送的最大消息數中的至少一個，來生成所述給定限制。
29.如權利要求27所述的方法，其中，所述給定隊列達到所述給定限制，以及當所述給定隊列達到所述給定限制時，將通知提供給給定應用程式。
30.如權利要求29所述的通信管理單元，其中，當接收到所述通知時，所述應用程式通知用戶。
全文摘要
公開了一種處理非永久通信鏈路上的通信的方法，所述方法包括，中心地從多個應用程式接收要傳送的消息；檢查非永久通信鏈路的可用性；如果非永久通信鏈路不可用，則將接收到的消息進行編隊，以便將來的傳輸；以及如果非永久通信鏈路可用，則將消息提供給傳輸/網絡層。
文檔編號H04L29/04GK1957577SQ200680000245
公開日2007年5月2日 申請日期2006年4月18日 優先權日2005年4月18日
發明者詩曼提·卡馬卡爾, 麥可·申菲爾德, 卡門·B·維塔諾夫, 傑弗裡·克里斯多福·羅傑斯, 菲拉·比布爾, 布倫杜沙·L·弗裡奇 申請人:捷訊研究有限公司