專利名稱：用于發送消息的方法
技術領域：
本發明涉及一種用于在通信網絡中發送消息的方法。
背景技術：
第三代合作組織項目(3GPP)目前討論了在通信網絡中作為一個網絡單元的多媒體消息業務中心(MMSC)的問題，例如，在通用分組無線電系統(GPRS)和通用移動通信系統(UMTS)中的使用。遺憾的是，大部分問題仍不確定，如終端能力和用戶簡表的管理。
從技術的觀點來看，多媒體消息業務中心的功能提供了一種部分工作于存儲和轉發模式的非實時業務。另外，多媒體消息利用例如GPRS空中接口發送，而且消息的內容可以是文本、圖像、語音、視頻片段等，或上述內容的任意組合。例如，利用這種多媒體消息業務這些內容可以從一個移動臺發送到另一移動臺。
根據多媒體消息的業務描述，消息的內容和長度在理論上不受限制。然而，由于存在各種不同類型的終端(例如，移動臺)，網絡中出現了這些終端的多種不同能力。因此，每個這些終端不可避免地造成其特定的限制和制約，尤其是在處理多媒體消息的能力上。
例如，可用的存儲容量受限，而且不同終端之間存在差異，因此，不是所有的終端都能接收所有可能的內容。此外，單個終端的能力也可能動態變化，例如，如果終端已經接收和存儲了一條消息，那么剩余的存儲空間將減小。類似地，終端可以與類似膝上型計算機等的其他設備連接或斷開。
此外，除了由終端能力造成的制約外，用戶可能希望創建或修正其自身的用戶簡表，從而也將導致特別的限制。例如，用戶可能希望使某些類型的多媒體消息存儲于多媒體消息業務中心，轉發到一個因特網地址或被丟棄。這些用戶定義的限制可基于例如，多媒體消息的大小、內容-類型或發送人。
從前述可以看出，這將出現新的問題，即，由于缺乏接收、存儲、處理或顯示多媒體消息的能力，某些部分的多媒體消息或甚至整個消息將不受接收終端的控制。由此，不受控地發送多媒體消息將造成終端出現嚴重的問題直至系統故障，這可能導致至少部分喪失終端功能，從而中斷通信。
發明內容
因此，本發明的一個目的是，提供一種用于在包括至少一個終端和一個消息發送功能的通信網絡中發送消息的方法，而且該方法沒有上述缺陷。
根據本發明，這個目的是通過一種用于在包括至少一個終端和一種消息發送功能的通信網絡中發送消息的方法實現的，所述方法包括步驟一旦出現一個預定條件，就從所述終端提交涉及該終端能力和當前用戶簡表的信息到所述消息發送功能；所述消息發送功能根據所述信息確定如何為所述終端處理所述消息發送功能接收的消息；以及所述消息發送功能根據所述確定步驟的結果處理所述消息。
此外，該目的是通過一種用于在包括至少一個終端和一個消息發送功能的通信網絡中發送消息的方法實現的，所述方法包括步驟所述消息發送功能為所述終端接收消息；從所述消息發送功能發送一個關于出現所述消息的通知到所述終端；所述終端根據其能力和當前用戶簡表確定如何處理所述接收消息；所述終端應答所述消息發送功能發送的通知，同時根據所述確定步驟的結果下達指令；以及所述消息發送功能根據所述指令處理所述消息。
此外，本發明提出了一種消息發送功能設備，包括用于接收消息和信息的接收裝置；用于處理接收的信息數據和消息的處理裝置；存儲裝置；用于分別發送信息和消息到所述終端的發送裝置。
另外，本發明還還提出了一種終端設備，包括用于接收消息和信息的接收裝置；用于處理接收的信息數據和消息的處理裝置；存儲裝置；用于分別發送信息和消息到所述終端的發送裝置。
對本發明的進一步改進在相應的所附權利要求書中陳述。
因此，本發明的一個優點在于，對消息的處理是基于接收終端的能力和對應用戶的用戶簡表。因此，能相應地處理每條消息和這條消息的每部分。總之，不再可能出現終端故障或者功能喪失，而且根據本發明的方法還為用戶靈活和自由地加入網絡提供了更大的余地。
下面通過參考附圖舉例詳細描述本發明的優選實施例。
圖1示出了根據本發明的第一實施例，在多媒體消息業務中心和接收終端之間發送多媒體消息的基本信令序列的原理圖；圖2示出了根據本發明的第二個實施例，在多媒體消息業務中心接收到一個新的移動臺終接的多媒體消息后，實現的一個功能例子的流程圖；以及圖3示出了根據本發明的第二個實施例，在終端接收到MMSNotify消息后，實現的一個功能例子的另一流程圖。
具體實現方式根據本發明，根據類似移動臺的接收終端的能力和用戶簡表，處理多媒體消息的提交作為在通信網絡中發送的一種消息例子。如何處理該提交的決定基于多媒體消息的內容、大小和類型，終端的能力以及與所述終端相關的用戶的用戶簡表被相應的判決裝置獲得的情況。
對要發送的這些消息的處理將在該通信網絡的另一元素，即實現消息發送功能的網絡設備中執行。在下面對本發明的優選實施例的描述中，將通過參考該多媒體消息服務中心的例子作為實現消息發送功能的這種網絡設備，以及通過參考多媒體消息的例子作為發送消息來描述。然而，應注意，這些例子決不是限制。即，單一媒體消息也可以發送，而且消息發送功能無需在單個網絡設備(如多媒體消息服務中心)中實現，而是也可以為分發功能。
對于上面提到的判決，為說明起見，多媒體消息可以認為是多媒體消息業務中心始發的，而終端能力和用戶簡表可以認為是一個相應的終端所固有的。因此，信息必須以任何一種方式發送以便能判決。
此外，為方便起見，如果判決是自動的并且根據終端和用戶提供的參數優化也是可以理解的。然而，這并不是本發明的前提。
由于多媒體消息可具有一定的格式，多個部分(段)，不同內容(文本、圖像、語音、視頻等等)，不同大小或發送人識別，顯然，這取決于接收終端的能力和當前定義的用戶簡表，終端是否能接收、顯示或處理這些多媒體消息，以及取決于用戶是否希望這樣做。
因此，關于如何處理這些多媒體消息的判決結果可以是，應全部、部分或經修正后發送，應丟棄，存儲于多媒體消息業務中心，或應轉發到例如一個因特網郵件地址。前面提到，不自動判決，而是請示用戶如何做，這在一般情況下還是在特殊情況下，當然都是可能的。此外，由于在多媒體消息業務中心估計沒有無限的內存空間提供使用，在多媒體消息業務中心存儲多媒體消息將在大部分情況下被限制到一定的時間周期(因此，在清除存儲的消息之前，MMSC可以通過一個相應的通告通知用戶該時間周期終止)。如果只應發送部分多媒體消息，未被發送部分也可以被存儲、轉發或丟棄。修正多媒體消息的情況通常可能是將多媒體消息從一種格式轉換為另一種格式，但對數據進行壓縮或其他形式的處理通過上述表述也應能理解。結果，不像這樣劃分的多媒體消息可通過這種處理分段。對于如何處理提交多媒體消息的幾種可能性，判決結果也可能最終是上述各項的各種組合。
除此之外，如果多媒體消息業務中心被指定為通用分組無線電和通用移動通信系統的一個新的網絡單元，那么，數據發送將很有可能通過使用根據所述系統的相應的其他網絡單元在協議數據單元非實時執行，為清晰起見，在本發明的描述中這些其他網絡單元被忽略。
第一個實施例根據本發明的第一個實施例，涉及選擇發送多媒體消息的判決在多媒體消息業務中心(MMSC)執行。這種方案的基本觀點在于，接收到一個新的多媒體消息后，多媒體消息業務中心能立刻決定必須選擇哪種發送類型。換句話說，多媒體消息業務中心用作終端的預過濾器。
為提供這種功能，終端能力和當前用戶簡表必須存儲于多媒體消息業務中心。此外，這種信息必須在一定條件下刷新。如果這些信息(終端能力和用戶簡表)以及傳遞的多媒體消息業務中心從不改變，信息必須提交并且存儲一次，而且不會被刷新。當然，這些先決條件幾乎不會滿足。因此，初始信息和刷新的信息必須提交給多媒體消息業務中心以便保持該中心存儲的信息有效。
這些信息可以包括所述終端的顯示類型、所述終端的鍵盤類型、所述終端支持的編解碼電路、所述終端的存儲器大小、所述終端與其他設備的電連接、連接所述終端等的外部附件，當然還包括當前用戶簡表。
當從終端提交信息給多媒體消息業務中心時有幾種可能的條件，而且刷新的可能性并不僅限制為一種條件。然而，刷新應聯系刷新的必要性，或至少聯系提交該信息與必須提交的其他數據(可以是這兩個網絡單元之間的任何信令序列)的可能性，以避免業務干擾。因此，當終端啟動其信令序列以提交信息時的條件是預定的。這個條件可以是所述終端登錄所述網絡，所述終端的連接條件改變，語境激活或語境條件改變，用戶簡表產生或修正，終端始發的業務或終端終接的業務，所述多媒體消息業務中心的請求，所述多媒體消息業務中心通知所述終端一個新的多媒體消息的出現和/或內容，等等。
參考圖1，通過一旦預定的語境條件激活就提交信息的例子，示意了提交關于終端能力和當前用戶簡表信息的信令序列。
因此，在第一步驟S11，諸如移動臺的終端MS通過一個支持節點SN請求語境激活多媒體消息業務中心MMSC。利用這個語境激活請求，終端MS同時提交其能力CAP和當前用戶簡表UP。根據GPRS或UMTS的當前網絡例子，圖1所示的整個信令可利用協議數據單元PDU發生。
這個發送完成后，多媒體消息業務中心MMSC存儲該終端MS的用戶簡表UP。由于多媒體消息業務中心的能力限制，可能或必須在終端MS的能力CAP范圍內調整終端MS的用戶簡表UP。然而，用戶可以禁止這種修正其優選用戶簡表。用戶簡表UP的存儲和其最終處理在步驟S12執行。
在第三步驟S13，從多媒體消息業務中心MMSC通過支持節點SN至少提交該語境激活的確認到終端MS。
然而，如果用于終端MS的多媒體消息MM當前出現在多媒體消息業務中心MMSC，那么在步驟S13之前將為步驟S14，其中這個多媒體消息MM根據存儲于多媒體消息業務中心MMSC中的用戶簡表UP處理。對多媒體消息MM的處理對應基于目前存儲于多媒體消息業務中心MMSC的終端MS能力CAP和用戶簡表UP的判決過程的結果。這種判決過程的可能結果在上面詳細討論，而且再次提到，根據第一個實施例，這種判決是由多媒體消息業務中心MMSC執行的。
根據這種判決結果，處理多媒體消息MM可能要求處理多媒體消息MM的數據(例如在經修正后發送或部分發送的情況下)或不要求這種處理，這在上面已經提到。在任何情況下，如果至少部分多媒體消息MM必須提交給終端MS，這將在步驟S13與提交語境激活確認一起執行。
前面提到，圖1描繪的例子僅提供用于示意，而且第一個實施例并不限制為這個例子。由此，本領域的技術人員完全知道，根據上述的第一個實施例，使圖1所示的過程分別適應于其他可能性。
第二個實施例除了根據第一個實施例的技術解決方案，還有其他可選方案用于僅在終端方維持終端能力和用戶簡表信息，由此終端做出選擇發送多媒體消息的判定。
因此，第二個實施例的基本觀點在于，終端能力和用戶簡表信息存儲于終端，例如終端設備，或在移動終端的情況下，存儲于SIM，或存儲于兩者中。由此，發送多媒體消息的決定在終端做出。
現在參考圖2和圖3描述根據第二個實施例的多媒體消息業務中心和終端的功能。
圖2示意了根據這個實施例，一旦接收到一個新的移動臺終接的多媒體消息MM，多媒體消息業務中心MMSC的功能例子。由此可見，多媒體消息業務中心MMSC在接收到一個新的多媒體消息MM(步驟S20)后，在步驟S21自動發送一個特殊控制消息MMSNotify到終端MS。MMSNotify消息包含有關實際的多媒體消息MM的信息，如該消息的總體尺寸、內容、內容類型、可讀描述，等等。
根據存儲的有關終端能力CAP和其當前用戶簡表UP的信息，終端MS現在處理MMSNotify消息中包含的信息，由此決定如何處理多媒體消息MM。根據這個判決過程，終端MS發送一個相應的應答消息到多媒體消息業務中心MMSC，該消息在步驟S22被多媒體消息業務中心MMSC接收。這個過程通過圖3中的例子示意，下面將對此進行描述。
應注意，本發明并不限制發送MMSNotify消息的裝置為終端MS。例如，多媒體消息業務中心MMSC也可以發送MMSNotify消息作為一種特殊的SMS消息，該消息接著被終端MS分析，或多媒體消息業務中心MMSC可利用多媒體消息業務專用的一種特定承載(例如，控制信道)。
無論如何，根據第二個實施例用于分別交換消息和信息的信令序列基于下面的原理。一接收到MMSNotify消息，終端MS提交MSResultRequest消息作為應答，該消息在步驟S22被多媒體消息業務中心MMSC接收。然而，由于判決過程的結果不同，可能的MMSResultRequest消息互不相同。因此，MMSResultRequest消息可以是例如，MMSDeliverReq，MMSStoreReq，MMSForwardReq或MMSDiscardReq。
因此，在步驟S23，多媒體消息業務中心MMSC檢查終端MS的應答是否為MMSStoreReq消息，如果為“yes”，則多媒體消息MM在步驟S26存儲于多媒體消息業務中心。如果為“no”，則該過程繼續進行到步驟S24，以檢查應答是否為MMSDeliverReq消息。
如果MMSDeliverReq消息被終端MS應答，該過程進行到步驟S27，其中多媒體消息業務中心MMSC檢查MMSDeliverReq消息，多媒體消息應被部分發送還是全部發送。圖2所示的步驟S29表示發送部分多媒體消息MM到終端MS的情形，其后是上面提到的步驟S26，其中至少未被發送的部分多媒體消息MM被存儲于多媒體消息業務中心MMSC。與此相反，步驟S210表示發送全部多媒體消息MM到多媒體消息業務中心MMSC的情形，其后是步驟S211，其中在發送后從多媒體消息業務中心MMSC去除這個多媒體消息MM。
如果MMSDeliverReq消息沒有被終端MS應答，那么在該過程的步驟S25檢查MMSForwardReq消息是否被應答。如果沒有被應答，假設出現MMSDiscardReq消息，而且根據步驟S211多媒體消息MM從多媒體消息業務中心MMSC去除。如果出現MMSForwardReq消息，多媒體消息MM在步驟S211被從多媒體消息業務中心MMSC去除前，在步驟S28首先轉發到由MMSForwardReq消息給定的目的地。
現在參考圖3描述根據圖2的步驟S21，在步驟S30接收到MMSNotify消息后終端MS的功能。
具體來說，終端MS在步驟S31檢查其能力CAP和用戶簡表UP，之后是對應的判決步驟S32-S35。從圖3可看出，將決策權交與用戶的選擇包含作為對應于步驟S32的一個選項。如果設置用戶簡表UP以便用戶應對發送多媒體消息MM做出判決，那么用戶輸入的結果被進一步傳送到步驟S33-S35。如果該判決是自動執行，根據本發明的第二個實施例，終端MS根據其用戶簡表UP和能力CAP決定如何處理多媒體消息業務中心MMSC中出現的多媒體消息MM。不管怎樣，在這種情況下結果也將進一步送至步驟S33-S35。
上面討論了終端MS如何決定發送多媒體消息MM的幾種選擇，而且其中一些選擇在圖3示意作為示例。即，在步驟S33終端檢查結果是否為部分或全部恢復多媒體消息MM，如果正是這樣，在接下來的步驟S37中，MMSDeliverReq消息被發送到多媒體消息業務中心MMSC。如果多媒體消息MM不應被恢復，但在步驟S34檢測結果為應轉發消息MM，那么在下面的步驟S38發送MMSForwardReq消息到多媒體消息業務中心MMSC。如果結果不是轉發該消息，該過程進行到步驟S35，以檢查結果是否為使多媒體消息MM存儲于多媒體消息業務中心MMSC。如果結果為TRUE，接下來的步驟S39包括發送MMSStoreReq消息到多媒體消息業務中心MMSC，如果結果不是TRUE，下面的步驟S40包括發送MMSDiscardReq消息到多媒體消息業務中心MMSC，這是假設上述為判決過程的結果。
在任何情況下，所有步驟S37-S40后都跟隨步驟S41，在步驟S41中，再一次檢測用戶簡表，以確定用戶在步驟S42是否應接收到關于出現多媒體消息MM以及可能有關對其執行的處理的適當通知。在這兩種情況下，流程結束直到接收到另一MMSNotify消息。
上面提到，根據圖3的其中一個步驟S37-S40，終端MS發送的應答消息在圖2的步驟S22被多媒體消息業務中心MMSC接收。此外，這個應答消息都包含多媒體消息業務中心MMSC根據終端始發的發送多媒體消息MM決定而作用所需的所有信息。
還應注意，圖2和圖3描繪的例子并不限制本發明，而且上面已經詳細陳述了發送多媒體消息的選擇范圍。根據本發明，沿著上面陳述的描述思路，可以很容易地對圖2和圖3的流程圖作進一步的精煉和改進。
作為第二個實施例的另一個可選方案，終端和多媒體消息業務中心之間的信令可以利用單個請求-應答消息對實現。換句話說，終端總是能用MMSNotifyReply消息應答MMSNotify消息。在這種情況下，通過在所述MMSNotifyReply消息中為每部分多媒體消息分配一個控制標志(例如，用2bits表示)可以實現終端和多媒體消息業務中心的預期功能。如果該標志的值被發送、存儲、轉發或丟棄，該終端能利用一個簡單的應答消息通知多媒體消息業務中心如何處理每部分多媒體消息。
這種技術解決方案能提供更為靈活的功能。例如，很明顯，根據這個可選方案，能利用一個應答消息命令多媒體消息業務中心將每部分多媒體消息與其它部分獨立、區別對待，以便某些部分可以發送到終端，而某些部分可以轉發到一個因特網郵件地址，等等。
然而，這是假定多媒體消息各部分明確定義，而且多媒體消息業務中心能處理分隔的每部分多媒體消息。
根據第二個實施例，還具有下述優點終端能力和用戶簡表信息不必在多媒體消息業務中心維護，由此不會浪費多媒體消息業務中心的存儲和處理能力，而是留作其他目的。
此外，信息不必在每次出現預定條件都發送以保持存儲于多媒體消息業務中心的信息有效。因此，在終端和多媒體消息業務中心之間不會引起額外的信令。總之，可以確保信息總是最新，而且由于刷新信令不會造成業務干擾。
另外，在多媒體消息業務中心不必執行額外的處理。由于可以預期，根據第二個實施例，多媒體消息業務中心的結構可以保持在一個較低的難度級別，即多媒體消息業務中心的實現變得更為簡單，而且其性能要求降低，這可能就是為什么優選這個實施例的原因。
如上所述，本發明提出了一種用于在包括至少一個終端和一個消息發送功能的通信網絡中發送消息的方法，所述方法包括步驟所述消息發送功能MMSC為所述終端MS接收消息MM；從所述消息發送功能MMSC發送關于出現所述消息MM的通知MMSNotify到所述終端MS；所述終端MS根據其能力CAP和當前用戶簡表UP決定如何處理所述接收消息MM；所述終端MS應答所述消息發送功能MMSC發送的通知，同時根據所述確定步驟的結果下達指令；以及所述消息發送功能MMSC根據所述指令處理所述消息MM。
應理解的是，上面的描述和附圖僅用于通過舉例示意本發明。因此本發明的優選實施例可以在所附權利要求書的范圍內改變。
權利要求
1.一種用于在包括至少一個終端和一個消息發送功能的通信網絡中發送消息的方法，所述方法包括步驟一旦出現一個預定條件，就從所述終端(MS)提交涉及終端(MS)能力(CAP)和其當前用戶簡表(UP)的信息到所述消息發送功能(MMSC)；所述消息發送功能(MMSC)根據所述信息確定如何為所述終端(MS)處理所述消息發送功能(MMSC)接收的消息(MM)；以及所述消息發送功能(MMSC)根據所述確定步驟的結果處理所述消息(MM)。
2.根據權利要求1的方法，還包括在所述消息發送功能(MMSC)存儲所述信息的步驟。
3.根據權利要求1的方法，其中所述確定步驟的結果至少存在于所述終端(MS)的所述消息(MM)被全部、部分發送或是經修正后發送到所述終端(MS)，所述消息(MM)被丟棄，所述消息(MM)被轉發到另一終端，或所述消息(MM)被存儲于所述消息發送功能(MMSC)。
4.根據權利要求1的方法，其中所述預定條件為下面事件中的至少一個所述終端(MS)登錄所述網絡，所述終端(MS)的連接條件改變，語境激活或語境條件的改變，用戶簡表(UP)創建或用戶簡表(UP)修正，終端始發的業務或終端終接的業務，所述消息發送功能(MMSC)的請求，所述消息發送功能(MMSC)通知所述終端(MS)出現一個新消息(MM)，以及所述消息發送功能(MMSC)通知所述終端(MS)一個新消息(MM)的內容、類型和大小。
5.根據權利要求1的方法，其中涉及所述終端(MS)的所述能力(CAP)的所述信息包括下面的至少一個所述終端(MS)的顯示類型，所述終端(MS)的鍵盤類型，所述終端(MS)支持的編解碼電路，所述終端(MS)的存儲器大小，所述終端(MS)與其他設備的電連接，連接所述終端(MS)的外部附件，或當前用戶簡表(UP)。
6.一種用于在包括至少一個終端和一個消息發送功能的通信網絡中發送消息的方法，所述方法包括步驟所述消息發送功能(MMSC)為所述終端(MS)接收消息(MM)；從所述消息發送功能(MMSC)發送關于出現所述消息(MM)的通知(MMSNotify)到所述終端(MS)；所述終端(MS)根據其能力(CAP)和當前用戶簡表(UP)，確定如何處理所述接收消息(MM)；所述終端(MS)應答所述消息發送功能(MMSC)發送的通知，同時根據所述確定步驟的結果下達指令；以及所述消息發送功能(MMSC)根據所述指令來處理所述消息(MM)。
7.根據權利要求6的方法，其中所述確定步驟的結果至少存在于所述終端(MS)的所述消息(MM)被全部、部分發送或經修正后發送到所述終端(MS)，所述消息(MM)被丟棄，所述消息(MM)被轉發到另一終端，或所述消息(MM)被存儲于所述消息發送功能(MMSC)。
8.根據權利要求6的方法，其中從所述消息發送功能(MMSC)發送到所述終端(MS)的關于出現所述消息(MM)的所述通知(MMSNotify)還通知所述消息(MM)的至少內容、類型和大小。
9.根據權利要求8的方法，其中所述終端(MS)在信令過程中通過發送一個包含所述消息(MM)每個部分的控制標志的通知應答消息來應答所述消息發送功能(MMSC)，而所述控制標志的值可以被發送、修正、存儲、轉發或丟棄。
10.根據權利要求6的方法，其中所述確定步驟包括所述終端(MS)請示用戶如何處理消息(MM)以及用戶輸入的表示所述確定步驟結果的輸入。
11.一種消息發送功能設備，包括用于接收消息(MM)和信息的接收裝置；用于處理接收信息數據和消息(MM)的處理裝置；存儲裝置；用于分別發送信息和消息(MM)到所述終端(MS)的發送裝置。
12.一種終端設備，包括用于接收消息(MM)和信息的接收裝置；用于處理接收信息數據和消息(MM)的處理裝置；存儲裝置；用于分別發送信息和消息(MM)到所述終端(MS)的發送裝置。
全文摘要
本發明提出了一種用于在包括至少一個終端和一個消息發送功能的通信網絡中發送消息的方法,所述方法包括步驟:所述消息發送功能(MMSC)為所述終端(MS)接收消息;從所述消息發送功能(MMSC)發送關于出現所述消息(MM)的通知(MMSNotify)到所述終端(MS);所述終端(MS)根據其能力(CAP)和當前用戶簡表(UP)確定如何處理所述接收消息(MM);所述終端(MS)應答所述消息發送功能(MMSC)發送的通知,同時根據所述確定步驟的結果下達指令;以及所述消息發送功能(MMSC)根據所述指令處理所述消息(MM)。
文檔編號H04L12/58GK1348650SQ99816578
公開日2002年5月8日 申請日期1999年4月19日 優先權日1999年4月19日
發明者邁克爾·羅克, 加科·塞萬托, 阿迪·穆霍寧 申請人:諾基亞網絡有限公司