(57)【要約】  受信デバイスへの次期送信セッションに関する通知のために、送信セッションにおける種々の可能な特定情報タイプの１タイプの特定情報を送信セッション特定情報フィールドに対応付ける。このフィールドを受信デバイスに通知するために使用する。さらに、次期送信セッションが新規か否かを示す反復値を、送信セッション特定情報フィールドに追加する。さらに、送信セッション特定情報により特定される送信セッションにおけるデータの取得を終了することができれば、受信デバイスは個々の送信セッション特定情報のために格納したコンテキストデータを解放することができる。
2008536373.tif 000002
【特許請求の範囲】
【請求項１】
次期送信セッションに関し受信デバイスに通知する方法であって、該方法が送信デバイスにおいて、
送信セッションにおいて送信される可能性がある少なくとも２つの異なる特定情報タイプの中の１つの特定情報タイプを選択するステップと、
前記選択された特定情報タイプの中の少なくとも１つの特定情報を送信セッション特定情報に対応付けるステップであって、前記少なくとも１つの特定情報が前記次期送信セッションにおいて送信され、
前記送信セッション特定情報を送信セッション特定情報フィールドに挿入するステップと、
前記受信デバイスへの前記次期送信セッションに関する通知のために前記送信セッション特定情報フィールドを提供するステップと、
を有することを特徴とする方法。
【請求項２】
前記少なくとも２つの特定情報タイプが、
送信セッションのファイルを特定するファイル特定情報、
送信セッションのファイルグループを特定するグループ専用特定情報、
ファイル特定情報のそれぞれが送信セッションの有するファイルグループのそれぞれのファイルを特定するファイル特定情報のリスト、
外部ファイルグループを特定する少なくとも１特定情報、
送信セッションの全てのファイルを特定する共通特定情報、
配信セッションを特定する配信セッション特定情報、および
送信セッションのＦＬＵＴＥファイル配信テーブルインスタンスを特定するファイル・ユニフォーム・リソース特定情報、
の少なくとも１つを有する、請求項１に記載の方法。
【請求項３】
前記対応付けるステップが、前記選択された特定情報タイプの前記少なくとも１つの特定情報の中の少なくとも所定の部分を選択し、前記送信セッション特定情報を獲得するステップを含む、請求項１に記載の方法。
【請求項４】
前記対応付けるステップが、前記選択された特定情報タイプの少なくとも２つの特定情報の中の少なくともそれぞれの部分を結合し、前記送信セッション特定情報を獲得するステップを含む、請求項１に記載の方法。
【請求項５】
前記対応付けるステップが、前記選択された特定情報タイプの前記少なくとも１つの特定情報の少なくとも一部に基づいてハッシュ値を生成し、前記送信セッション特定情報を獲得するステップを含む、請求項１に記載の方法。
【請求項６】
前記受信デバイスが、次期送信セッションに関する通知を受信し、前記通知における送信セッション特定情報フィールドの送信特定情報を前の送信セッションにおいて受信した少なくとも２つの特定情報タイプの特定情報と比較し、前記送信セッション特定情報が前の送信セッションにおいて受信した特定情報に符合し、前の送信セッションを含むデータが正しく受信されている場合、前記送信セッションのデータを取得することを放棄する、請求項１に記載の方法。
【請求項７】
受信デバイスへの次期送信セッションに関する通知をサポートする処理ユニットを有する送信デバイスであって、
前記処理コンポーネントが、送信セッションにおいて送信される可能性がある少なくとも２つの異なる特定情報タイプの中の１つの特定情報タイプを選択し、
前記処理コンポーネントが、選択された特定情報タイプの中の少なくとも１つの特定情報を送信セッション特定情報に対応付けられ、少なくとも１つの特定情報が次期送信セッションにおいて送信され、
前記処理コンポーネントが、前記送信セッション特定情報を送信セッション特定情報フィールドに挿入し、
前記処理コンポーネントが、前記受信デバイスへの前記次期送信セッションに関する通知のために前記送信セッション特定情報フィールドを提供する、
ことを特徴とする送信デバイス。
【請求項８】
請求項７に記載の前記送信デバイスを有することを特徴とする通信ネットワーク。
【請求項９】
請求項７に記載の前記送信デバイスおよび前記受信デバイスを有することを特徴とする通信システム。
【請求項１０】
次期送信セッションに関し受信デバイスに通知するソフトウエアコードであって、前記ソフトウエアコードが送信デバイスの処理ユニットにおいて動作する場合に、
送信セッションにおいて送信される可能性がある少なくとも２つの異なる特定情報タイプの中の１つの特定情報タイプを選択するステップと、
前記選択された特定情報タイプの中の少なくとも１つの特定情報を送信セッション特定情報に対応付けるステップであって、前記少なくとも１特定情報が前記次期送信セッションにおいて送信され、
前記送信セッション特定情報を送信セッション特定情報フィールドに挿入するステップと、
前記受信デバイスへの前記次期送信セッションに関する通知のために前記送信セッション特定情報フィールドを提供するステップと、
を実現する前記ソフトウエアコードが格納されることを特徴とするソフトウエアプログラム製品。
【請求項１１】
次期送信セッションに関し受信デバイスに通知する方法であって、前記受信デバイスにおいて、
次期送信セッションに関する通知を受信するステップと、
前記通知における送信セッション特定情報フィールドの送信特定情報を前の送信セッションにおいて受信した少なくとも２つの特定情報タイプの特定情報と比較するステップと、
前記送信セッション特定情報が前の送信セッションにおいて受信した特定情報に符合し、前の送信セッションが含むデータが正しく受信されている場合、前記送信セッションのデータを取得することを放棄するステップと、
を有することを特徴とする方法。
【請求項１２】
前記受信デバイスへの次期送信セッションに関する通知をサポートする処理ユニットを有する受信装置であって、
前記処理コンポーネントが、次期送信セッションに関する通知を受信し、
前記処理コンポーネントが、前記通知における送信セッション特定情報フィールドの送信特定情報を前の送信セッションにおいて受信した少なくとも２つの特定情報タイプの特定情報と比較し、
前記処理コンポーネントが、前記送信セッション特定情報が前の送信セッションにおいて受信した特定情報に符合し、前の送信セッションが含むデータが正しく受信されている場合、前記送信セッションのデータを取得することを放棄する、
ことを特徴とする受信装置。
【請求項１３】
次期送信セッションに関し受信デバイスに通知するソフトウエアコードであって、前記ソフトウエアコードが受信デバイスの処理ユニットにおいて動作する場合に
次期送信セッションに関する通知を受信するステップと、
前記通知における送信セッション特定情報フィールドの送信特定情報を前の送信セッションにおいて受信した少なくとも２つの特定情報タイプの特定情報と比較するステップと、
前記送信セッション特定情報が前の送信セッションにおいて受信した特定情報に符合し、前の送信セッションが含むデータが正しく受信されている場合、前記送信セッションのデータを取得することを放棄するステップと、
を実現する前記ソフトウエアコードが格納されることを特徴とするソフトウエアプログラム製品。
【請求項１４】
次期送信セッションに関し受信デバイスに通知する方法であって、送信デバイスにおいて、
前記次期送信セッションの反復の是非を示す反復値を送信セッション特定情報フィールドに挿入するステップと、
前記受信デバイスへの前記次期送信セッションに関する通知のために前記送信セッション特定情報フィールドを提供するステップと、
を有することを特徴とする方法。
【請求項１５】
送信セッション特定情報が提供されるべきであるかを判断する先行ステップを更に有し、前記送信セッションが新規送信セッションの場合および送信セッション特定情報が提供されるべきでない場合、同じ予め定められた反復値を使用する、請求項１４に記載の方法。
【請求項１６】
次期送信セッションが新規送信セッションであることを示す値に前記反復値が最後に設定された後、予め定められた時間の後に、前記送信デバイスが、次期送信セッションが新規送信セッションであることを示す値に前記反復値を設定する、請求項１４に記載の方法。
【請求項１７】
前記受信デバイスが次期送信セッションに関する通知を受信し、前記通知における送信セッション特定情報フィールドの反復値を評価し、前記反復値が、次期送信セッションが新規送信セッションであることを示す場合、前記通知に少なくとも１つの応答を行い、前記次期送信セッションに属するデータを取得する、請求項１４に記載の方法。
【請求項１８】
前記反復値が、次期送信セッションが新規送信セッションであることを示さず、対応する前の送信セッションのコンテンツが正しく受信されていないと判断する場合さらに、前記受信デバイスが、前記通知に少なくとも１つの応答を行い、前記次期送信セッションに属するデータを取得する、請求項１７に記載の方法。
【請求項１９】
受信デバイスへの次期送信セッションに関する通知をサポートする処理ユニットを有する送信デバイスであって、
前記処理コンポーネントが、前記次期送信セッションの反復の是非を示す反復値を送信セッション特定情報フィールドに挿入し、
前記処理コンポーネントが、前記受信デバイスへの前記次期送信セッションに関する通知のために前記送信セッション特定情報フィールドを提供する、
ことを特徴とする送信デバイス。
【請求項２０】
請求項１９に記載の前記送信デバイスを有することを特徴とする通信ネットワーク。
【請求項２１】
請求項１９に記載の前記送信デバイスおよび前記受信デバイスを有することを特徴とする通信システム。
【請求項２２】
次期送信セッションに関し受信デバイスに通知するソフトウエアコードであって、前記ソフトウエアコードが送信デバイスの処理ユニットにおいて動作する場合に、
前記次期送信セッションの反復の是非を示す反復値を送信セッション特定情報フィールドに挿入するステップと、
前記受信デバイスへの前記次期送信セッションに関する通知のために前記送信セッション特定情報フィールドを提供するステップと、
を実現する前記ソフトウエアコードが格納されることを特徴とするソフトウエアプログラム製品。
【請求項２３】
次期送信セッションに関し受信デバイスに通知する方法であって、受信デバイスにおいて、
次期送信セッションに関する通知を受信するステップと、
前記通知における送信セッション特定情報フィールドの反復値を評価するステップと、
を有することを特徴とする方法。
【請求項２４】
受信デバイスへの次期送信セッションに関する通知をサポートする処理ユニットを有する受信デバイスであって、
前記処理コンポーネントが、次期送信セッションに関する通知を受信し、
前記処理コンポーネントが、前記通知における送信セッション特定情報フィールドの反復値を評価する、
ことを特徴とする受信デバイス。
【請求項２５】
次期送信セッションに関し受信デバイスに通知するソフトウエアコードであって、前記ソフトウエアコードが受信デバイスの処理ユニットにおいて動作する場合に、
次期送信セッションに関する通知を受信するステップと、
前記通知における送信セッション特定情報フィールドの反復値を評価するステップと、
を実現する前記ソフトウエアコードが格納されることを特徴とするソフトウエアプログラム製品。
【請求項２６】
次期送信セッションに関し受信デバイスに通知する方法であって、受信デバイスにおいて、
コンテキストデータが格納される送信セッション特定情報を判断するステップであって、前記送信セッション特定情報は、前記送信セッション特定情報により特定される送信セッションにおけるデータの取得を終了することが可能であり、
前記送信セッション特定情報のために格納されたコンテキストデータを解放するステップと、
を有することを特徴とする方法。
【請求項２７】
受信デバイスへの次期送信セッションに関する通知をサポートする処理ユニットを有する受信デバイスであって、
前記処理コンポーネントが、コンテキストデータが格納される送信セッション特定情報を判断し、前記送信セッション特定情報は、前記送信セッション特定情報により特定される送信セッションにおけるデータの取得を終了することが可能であり、
前記処理コンポーネントが、前記送信セッション特定情報のために格納されたコンテキストデータを解放する、
ことを特徴とする受信デバイス。
【請求項２８】
請求項２７に記載の前記受信デバイスを有することを特徴とする通信システム。
【請求項２９】
次期送信セッションに関し受信デバイスに通知するソフトウエアコードであって、前記ソフトウエアコードが受信デバイスの処理ユニットにおいて動作する場合に、
次期送信セッションに関する通知を受信するステップと、
前記通知における送信セッション特定情報フィールドの反復値を評価するステップと、
前記反復値が、次期送信セッションが新規送信セッションであることを示す場合、前記通知に応答するステップと、
を実現する前記ソフトウエアコードが格納されることを特徴とするソフトウエアプログラム製品。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、次期送信セッションに関し受信デバイスに通知する方法に関する。本発明は、対応する送信デバイス、対応する受信デバイス、対応する通信ネットワークおよび通信システム並びに対応するソフトウエアプログラム製品にも同じように関係する。
【背景技術】
【０００２】
マルチメディアブロードキャスト／マルチキャストサービス（Ｍｕｌｔｉｍｅｄｉａ  Ｂｒｏａｄｃａｓｔ／Ｍｕｌｔｉｃａｓｔ  Ｓｅｒｖｉｃｅ、ＭＢＭＳ）はポイント・ツー・マルチポイント・サービスであり、データを１つのソースから複数の宛先へ同時に送信する。従って、同じデータを幾つかの受信機に送信する必要がある場合、ＭＢＭＳはネットワークリソースの効率的な共有を可能にする。
【０００３】
図１に示すように、ＭＢＭＳシステムを３つの機能レイヤに分割することができる。第１のレイヤ１０はベアラー（Ｂｅａｒｅ）サービスに対応し、第２のレイヤ１１は配信方法に対応し、第３のレイヤ１２はアプリケーションを可能にするユーザサービスに対応する。ＭＢＭＳベアラーサービスは、マルチキャストおよびブロードキャストインターネット・プロトコル（ＩＰ）・データをユーザ装置に効率的に伝送する機構を提供する。配信方法は、ダウンロード配信方法か、またはストリーミング配信方法のいずれかでありうる。配信方法は、データを配信するために１以上のＭＢＭＳベアラーおよび／または１以上のポイント・ツー・ポイント（ＯＴＯ）・ベアラーを使用することができる。ユーザサービスは、ＭＢＭＳ上におけるアプリケーションを可能にし、１または幾つかの配信方法を使用して、アプリケーションデータ、例えばマルチメディア・メッセージング・サービス（ＭＭＳ）・メッセージのためのデータを配信することができる。
【０００４】
例示的ダウンロード配信ユーザサービスの場合の、種々の機能レイヤ間の関係を図２に示す。この例では、第１のレイヤの１つのＭＢＭＳベアラーサービス＃ｘを第３のレイヤの幾つかのＭＢＭＳダウンロードセッション＃ｎ、＃ｎ＋１、などのために使用する。これらＭＢＭＳダウンロードセッションを第３のレイヤのＭＢＭＳダウンロード・ユーザ・サービスに使用する。
【０００５】
ＭＢＭＳセッションを、移動通信システムが有するコアネットワークのゲートウエイＧＰＲＳサポートノード（ＧＧＳＮ）および移動通信システムが有する無線接続ネットワーク（Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ、ＲＡＮ）を介して、ブロードキャストマルチキャスト−サービスセンタ（ＢＭ−ＳＣ）と移動通信システムのユーザ装置（ＵＥ）との間に設定することができる。従って、図１のレイヤ構成は、ＢＭ−ＳＣおよびＵＥに有効である。ＭＢＭＳ配信方法１１を、例えばインターネットを介してＢＭ−ＳＣに接続されたＭＢＭＳユーザ・サービス・プロバイダが、ＢＭ−ＳＣにおいて駆動する。次いで、ＢＭ−ＳＣは、ユーザサービス１２が使用することになるＭＢＭＳベアラーサービス１０を起動する。各ベアラーサービスを、一時的移動グループ特定情報（Ｔｅｍｐｏｒａｒｙ  Ｍｏｂｉｌｅ  Ｇｒｏｕｐ  Ｉｄｅｎｔｉｔｙ、ＴＭＧＩ）により一意に特定する。ＴＭＧＩはＢＭ−ＳＣによりグローバルに割り当てられ、ＢＭ−ＳＣが属する公衆陸上移動ネットワーク（Ｐｕｂｌｉｃ  Ｌａｎｄ  Ｍｏｂｉｌｅ  Ｎｅｔｗｏｒｋ、ＰＬＭＮ）のＰＬＭＮ特定情報ならびに３オクテット、即ちバイトのサイズを有するローカルＭＢＭＳベアラーサービス特定情報を構成上含む。ＴＭＧＩは、ＩＰマルチキャストアドレスと接続ポイント名（ＡＰＮ）との対と同等であり、使用するＭＢＭＳベアラーの効率的な特定に使用する。ＴＭＧＩを、マルチキャストセッションのためのＭＢＭＳセッションの起動中またはブロードキャストセッションのサービス通知中にＵＥに送信する。
【０００６】
ＭＢＭＳセッションが始まると、ＧＳＭ  ＥＤＧＥ  ＲＡＮ（ＧＥＲＡＮ）の例により図３に示すようにＭＢＭＳ通知手順を通じて、ＵＥは開始されるデータ送信または進行中のデータ送信に関する通知を受ける。ＴＭＧＩおよび選択可能なセッションＩＤを、ＢＭ−ＳＣがＧＥＲＡＮの基地局コントローラ（ＢＳＣ）に提供する。ＢＳＣは、ＵＥを構成する移動局（ＭＳ）へのＴＭＧＩおよび選択可能なセッションＩＤをページングし、移動局にデータ送信の開始について通報する。ページングは、移動局の空きまたは接続中でありうる現状とは無関係に行う。ＴＭＧＩおよび選択可能なセッションＩＤのみを含むページング要求による選択可能な予備通知の後、ＧＥＲＡＮはさらにチャネル要求を用いてセル毎に計数する目的のために、さらなるページング要求により通知に応答するように端末を促すことができる。この場合、移動局がＭＢＭＳセッションに関心があれば、移動局はチャネル要求をＢＳＣに送信する必要がある。ＧＥＲＡＮは、その場合入力チャネル要求を計数すればよい。計数処理は、所与のセルに対する最も効率的なデータ送信モードを判断するのに重要である。所与のセルにおいて少数の移動局のみがＭＢＭＳセッションに関心がある場合、ＧＥＲＡＮはこのセルではポイント・ツー・マルチポイント送信の代わりにポイント・ツー・ポイント送信を使用するように判断することができる。移動局はＴＭＧＩおよびセッションＩＤを評価し、移動局のＭＢＭＳセッションへの関心の有無を判断する。
【０００７】
セッションを反復する場合、ＢＭ−ＳＣは同じＴＭＧＩおよび同じセッションＩＤをＭＢＭＳセッションに割り当てるべきである。これにより、移動局はセッションが反復していることを知り、移動局がデータを既に正しく受信している場合はデータを受信しないように判断することができる。
【０００８】
加えて、ＢＭ−ＳＣは、同じセッションＩＤを使用して、以前のダウンロード配信セッションに対する補修後のデータを配信することができる。これにより、元データを第１の送信中に正しく受信している場合、移動局は補修データを無視することができよう。
【０００９】
２００５年２月の３ＧＰＰ  ＴＳＧ−ＳＡ＃３４の文献であるＴｄｏｃＳ４−０５０１０３「ＭＢＭＳセッション特定情報の使用」において、１オクテット（１バイト）のセッションＩＤをファイルのダウンロード毎にＢＭ−ＳＣにより割り当てることが提案されている。一方、ファイル配信方法では、ファイル配信セッションを非同期階層符号化／階層符号化伝送（Ａｓｙｎｃｈｒｏｎｏｕｓ  Ｌａｙｅｒｅｄ  Ｃｏｄｉｎｇ／Ｌａｙｅｒｅｄ  Ｃｏｄｉｎｇ  Ｔｒａｎｓｐｏｒｔ、ＡＬＣ／ＬＣＴ）プロトコルヘッダの１６または３２ビットフィールドにおけるセッションＩＤにより特定する。通知中のセッションＩＤの表現に利用可能な１オクテットの短いスペースが与えられる場合、このフィールドを有効に使用する方法に関する問題が生じる。セッションＩＤオクテットは十分な情報を有し、移動局がデータを既に受信したか否かを判断することができるようにすべきである。とはいえ、比較的大きなダウンロードセッションＩＤと比較的小さなＭＢＭＳセッションＩＤとの間の直接的対応付けは、正確性を欠かずには不可能である。
【００１０】
文献ＴｄｏｃＳ４−０５０１０３は、さらに移動局における有効性タイマの使用を提案している。この有効性タイマは、セッションＩＤの有効性を所与の時間の間に制限することを目的とし、その時間の後移動局は、以前に受信したセッションＩＤ値によりＭＢＭＳセッションを経て搬送されるデータは新規配信、即ち送信であり、連続、即ち反復ではないと想定すべきである。従って、一度セッションＩＤのインスタンスが満了すると、値を別の送信、即ち別のセッションＩＤのインスタンスに使用することができる。これにより、ＵＥがセッションＩＤを以前のＭＢＭＳ送信セッションインスタンスと誤解する危険なくセッションＩＤを再使用できるようになるものと想定される。
【００１１】
とはいえ、この手法には各移動局がそれぞれの受信セッションに対するタイマを記憶し、セッションが反復であるのか、またはセッションＩＤフィールドの再使用により同一の値になっているのかを判断しなければならない不利がある。セッションＩＤフィールドの再使用は、前のセッションに使用し、短くなったセッションＩＤを、次に新規セッションに使用する状況を意味する。さらに、ＢＭ−ＳＣが再使用を意味するタイマ値の正確な推定を行い、同時にセッションの反復を認めることは困難である。タイマ値は、セッション記述プロトコル（Ｓｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｒｏｔｏｃｏｌ、ＳＤＰ）のダウンロード・セッション・パラメータとして伝送する必要がある。この時点では、タイマの値はなお予測できないであろう。その結果、セルレベルにおける計数が不正確となる。さらに、セッションＩＤの開始時間を明瞭に判断することは不可能である。例えば、セッションＩＤに関する受信パケットがＵＥのタイマを開始させても、パケット損失により全ての移動局がそのタイマを同時に開始させるとは限らないと想定されよう。
【００１２】
別の問題は、セッションＩＤの使用が選択可能であることから生じる。ＵＥおよびＢＭ−ＳＣは共に、セッションＩＤフィールドを無視することを判断することができる。ＵＥがセッションＩＤフィールドを無視すると判断すれば、ＵＥはセッションＩＤフィールドを単に解釈しないであろう。ＵＥは、ＭＢＭＳセッションが新規セッションであると想定し、独立してその判断を行うであろう。一方、ＢＭ−ＳＣが、例えばセッションＩＤフィールドを未指定値に設定することによりセッションＩＤフィールドを使用しないと判断した場合、ＢＭ−ＳＣはＵＥがその未指定値を誤解しないであろうことを保証する必要がある。
【発明の開示】
【００１３】
以上に記述した課題を克服することが本発明の目的である。
【００１４】
本発明の第１の態様によれば、次期送信セッションに関し受信デバイスに通知する第１の方法を提案し、第１の方法は、送信セッションにおいて送信される可能性がある少なくとも２つの異なる特定情報タイプの中の１つの特定情報タイプを選択するステップを送信デバイスにおいて含む。本方法は、選択された特定情報タイプの中の少なくとも１つの特定情報を送信セッション特定情報に対応付けるステップであって、少なくとも１つの特定情報が次期送信セッションにおいて送信されるであろうステップをさらに含む。本方法は、送信セッション特定情報を送信セッション特定情報フィールドに挿入するステップをさらに含む。本方法は、受信デバイスへの次期送信セッションに関する通知のための送信セッション特定情報フィールドを提供するステップをさらに含む。
【００１５】
さらに、本発明の第１の態様が有する第１の方法を実現するための手段を備える送信デバイスを提案する。さらに、このような送信デバイスを有する通信ネットワークを提案する。さらに、このような送信デバイスおよび受信デバイスを有する通信システムを提案する。さらに、ソフトウエアプログラム製品を提案し、この製品は、送信デバイスの処理ユニットにおいて動作する場合に本発明の第１の態様が有する第１の方法のステップを実現するソフトウエアコードを格納する。
【００１６】
本発明の第１の態様によれば、次期送信セッションに関し受信デバイスに通知する第２の方法を提案し、第２の方法は、次期送信セッションに関する通知を受信するステップを受信デバイスにおいて含む。この方法は、通知における送信セッション特定情報フィールドの送信特定情報を、前の送信セッションにおいて受信した少なくとも２つの特定情報タイプの特定情報と比較するステップをさらに含む。この方法は、送信セッション特定情報が前の送信セッションにおいて受信した特定情報に符合し、前の送信セッションが含むデータを正しく受信している場合、送信セッションのデータを取得することを放棄するステップをさらに含む。
【００１７】
さらに、本発明の第１の態様が有するこの第２の方法を実現するための手段を有する受信デバイスを提案する。さらに、ソフトウエアプログラム製品を提案し、この製品は、受信デバイスの処理ユニットにおいて動作する場合に本発明の第１の態様が有する第２の方法のステップを実現するソフトウエアコードを格納する。
【００１８】
本発明の第１の態様は、送信セッション特定情報のための基本として種々の特定情報のタイプの中から選択を行うことにより、粒度情報を必要とするように設定することができるという考え方に由来する。
【００１９】
本発明の第１の態様が送信セッション特定情報フィールドのより柔軟な対応付けを許容することは、本発明の第１の態様の利点である。本発明の第１の態様は、例えば１ＭＢＭＳセッションを１ダウンロードセッションに使用する場合、セッションをＴＭＧＩを通じて特定することができ、この場合には、情報の冗長性を回避することを可能にする。送信セッション特定情報をファイル特定情報に基づいて設定することを認めれば、端末はデータを受信することの是非を先験的に、ファイルベースで、それ故にセッションベースよりさらに細かいグラニュラリティ（ｇｒａｎｕｌａｒｉｔｙ）において判断するであろう。
【００２０】
グラニュラリティが細かいことにより、受信デバイスは通知に応答することの是非およびデータを受信することの是非を各ファイルに対して判断することができる。例えば、ユーザセッションが大きな２ファイルを有し、同じＭＢＭＳベアラーセッションを両ファイルに使用し、一方の受信デバイスが両ファイルの一方のみを必要とする場合にも、この受信デバイスは、両ファイルを受信するであろうことをネットワークになお指示する必要があろう。また、幾つかのセッションの反復には、元セッションのサブセット、例えば最も重要なファイルのみをただ含むことがある。従って、１タイプの送信セッション特定情報のみを使用すれば、ユーザはセッションの反復を新規セッションと認識し、ユーザがデータを受信することを望むことを通知する必要があろう。これは、ファイルまたはファイルグループに基づくより細かなグラニュラリティの対応付けを有することにより回避することができる。
【００２１】
本発明を実装する場合、細かなグラニュラリティの対応付けは計数における精度を高め、ネットワークリソースのより効率的な使用を許容するが、受信デバイスはより多くのデータを格納する必要があることを考慮する必要がある。
【００２２】
特定情報を送信セッション特定情報への対応付けの基本として選択することができる、少なくとも２つの特定情報タイプは、種々の種類でありうる。
【００２３】
特定情報のタイプは、例えば送信セッションのファイルを特定するファイル特定情報を含むことができる。送信セッション特定情報は、例えばファイルの伝送オブジェクト特定情報（Ｔｒａｎｓｐｏｒｔ  Ｏｂｊｅｃｔ  Ｉｄｅｎｔｉｆｉｅｒ、ＴＯＩ）の最少有意ビット（ＬＳＢｓ）でありうる。
【００２４】
特定情報のタイプは、例えば送信セッションのファイルグループを特定するグループ専用特定情報をさらに含むことができる。グループが一方向伝送を経るファイル配信（Ｆｉｌｅ  Ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  Ｔｒａｎｓｐｏｒｔ、ＦＬＵＴＥ）ファイルグループであれば、送信セッション特定情報を、例えばファイル配信テーブル（Ｆｉｌｅ  Ｄｅｌｉｖｅｒｙ  Ｔａｂｌｅ、ＦＤＴ）インスタンスＩＤにおいて送信されるグループ専用特定情報から生成することができる。
【００２５】
特定情報のタイプは、例えば各ファイル特定情報が送信セッションの有するファイルグループのそれぞれのファイルを特定する、ファイル特定情報のリストをさらに含むことができる。この場合、送信セッション特定情報を、例えばファイルリストを表すＴＯＩリストから生成することができる。
【００２６】
特定情報のタイプは、例えば外部ファイルグループを特定する少なくとも１つの特定情報をさらに含むことができる。この場合、送信セッション特定情報を、例えばファイルグループのために生成することができ、このファイルグループと送信セッション特定情報との間の対応付けをある他のデータエンティティにおいて記述する。この、他のデータエンティティは、例えばショートメッセージサービス（ＳＭＳ）のメッセージ、ＳＤＰファイル、などであることができ、例えばＦＬＵＴＥ配信、ＳＭＳ、などにより送信デバイスへ分離して通信することができる。
【００２７】
特定情報のタイプは、例えば送信セッションの全てのファイルを特定する共通特定情報をさらに含むことができる。例えば、１つの送信セッション特定情報を、１つのＦＤＴインスタンスにおいて宣言する全てのファイルに対して作成することができる。この場合、送信セッション特定情報をＦＤＴインスタンスＩＤのＬＳＢから作成することができる。
【００２８】
特定情報のタイプは、例えば配信セッションを特定する配信セッション特定情報をさらに含むことができる。配信セッションは、完結したアプリケーションまたはユーザサービスのための全セッションであり、配信セッションは関係するアプリケーションデータを送信するために１以上の送信セッションを使用することができる。１配信セッション特定情報をダウンロード配信セッションのために作成する場合、送信セッション特定情報を伝送セッション特定情報（Ｔｒａｎｓｐｏｒｔ  Ｓｅｓｓｉｏｎ  Ｉｄｅｎｔｉｆｉｅｒ、ＴＳＩ）のＬＳＢまたはＴＭＧＩから生成することができる。
【００２９】
特定情報のタイプは、例えば送信セッションのＦＬＵＴＥファイル配信テーブルインスタンスを特定するファイル・ユニフォーム・リソース特定情報（ｆｉｌｅ  Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ、ＦｉｌｅＵＲＩ）をさらに含むことができる。ＦｉｌｅＵＲＩはＴＯＩと同様に使用することができる。
【００３０】
最後に、さらに特定情報の新規タイプをセッションにおいて定義し、選択可能な専用特定情報を提供することができる。例えば、要素または属性を含む新規ＦＤＴフィールドを導入して、データを提供することができ、このデータから送信セッション特定情報を作成することができる。
【００３１】
使用する特定情報タイプの判断は送信デバイスにより行うことができる。送信デバイスは、例えば大きなファイルのそれぞれまたはファイルグループに対して送信セッションを生成することを判断し、大きなファイルのそれぞれまたはファイルグループに対応する送信セッション特定情報を割り当てることができる。
【００３２】
送信デバイスは、ある基準に基づいて、コンテンツ、例えばファイル、ファイルグループ、ＦＤＴインスタンスにおけるファイル、またはファイルダウンロードセッションを対応付ける方法を判断することができる。このような基準の例は、同一ベアラーセッションを経て送信することを許容するデータのサイズ制限でありうる。この場合、送信デバイスは、例えば所与の最大サイズを超えないようにしつつ、可能な限り多くのダウンロード・セッション・ファイルを１バースト、即ち１送信セッション、に適合させればよい。
【００３３】
また、提案する対応付け（ｍａｐｐｉｎｇ）は種々の種類でありうる。
【００３４】
対応付けは、送信セッション特定情報を獲得するために、選択された特定情報タイプの少なくとも１つの特定情報が有する少なくとも予め定められた部分を選択することを含むことができる。例えば、特定情報の最少有意バイトまたは予め定められた数のＬＳＢを、送信セッション特定情報として使用することができよう。
【００３５】
加えて対応付けは、送信セッション特定情報を獲得するために、選択された特定情報タイプの少なくとも２つの特定情報が有する少なくともそれぞれの部分を結合することを含むことができる。
【００３６】
さらに対応付けは、送信セッション特定情報を獲得するために、選択された特定情報タイプの少なくとも１つの特定情報の有する少なくとも一部に基づくハッシュ値の生成を含むことができる。例えば、関係する全てのＴＯＩのバイナリ和をハッシュすることができよう。対応付けにハッシュを使用する場合、使用するハッシュ関数は送信デバイスおよび受信デバイスにおいて既知であるべきである。
【００３７】
送信セッション特定情報は、１オクテットのサイズ、即ち８ビットのサイズを有することができるが、同じく任意の他の適するサイズを有することができる。さらに、特定情報の予め定められた部分を送信セッション特定情報への対応付けに使用する場合、この予め定められた部分を種々の方法で選択することができる。例えば、最少若しくは最大有意オクテット、ＬＢＳ若しくは最大有意ビット（ＭＳＢｓ）または最少若しくは最大有意の４バイトのハッシュ、などを使用することができよう。
【００３８】
同一送信セッション特定情報を使用して、同一コンテンツに関係する種々のデータを記述することができる。例は以下の通りである；元データを送信セッション特定情報＃１０を用いて送信デバイスにより送信する。その後、送信デバイスは同一コンテンツに対する修復データを生成し、従ってセッションは正確に同一データを搬送しないが、同一送信セッション特定情報＃１０を使用する。
【００３９】
本発明の第２の態様によれば、次期送信セッションに関し受信デバイスに通知する第１の方法を提案し、第１の方法は、次期送信セッションの反復の是非を示す反復値を送信セッション特定情報フィールドに挿入するステップを送信デバイスにおいて含む。この方法は、受信デバイスへの次期送信セッションに関する通知のための送信セッション特定情報フィールドを提供するステップをさらに含む。
【００４０】
さらに、本発明の第２の態様が有する第１の方法を実現するための手段を備える送信デバイスを提案する。さらに、このような送信デバイスを有する通信ネットワークを提案する。さらに、このような送信デバイスおよび受信デバイスを有する通信システムを提案する。さらに、ソフトウエアプログラム製品を提案し、この製品は、送信デバイスの処理ユニットにおいて動作する場合に本発明の第２の態様が有する第１の方法のステップを実現するソフトウエアコードを格納する。
【００４１】
本発明の第２の態様によれば、次期送信セッションに関し受信デバイスに通知する第２の方法を提案し、第２の方法は、次期送信セッションに関する通知を受信するステップを受信デバイスにおいて含む。本方法は通知における送信セッション特定情報フィールドの反復値を評価するステップをさらに含む。
【００４２】
さらに、本発明の第２の態様が有するこの第２の方法を実現するための手段を有する受信デバイスを提案する。さらに、ソフトウエアプログラム製品を提案し、このソフトウエアプログラム製品は、受信デバイスの処理ユニットにおいて動作する場合に本発明の第２の態様が有する第２の方法のステップを実現するソフトウエアコードを格納する。
【００４３】
本発明の第２の態様は、送信デバイスが送信セッション特定情報を対応付けない場合、受信デバイスへの送信セッション特定情報の送信を回避すべきか、または受信デバイスに暗示的又は明示的に送信セッション特定情報を無視するように指令すべきか、いずれかであるという考えに由来する。送信デバイスが送信セッション特定情報フィールドに反復値を含み、この反復値が、送信セッションが新規であると考えられるか否かを示すことを提案する。
【００４４】
本発明の第２の態様が有効性タイマの維持、推定および受信デバイスへの信号通知を回避することを可能にすることは、本発明の第２の態様の利点である。タイマ推定の精度は、可能な計数機構の性能にかなりの影響を及ぼす可能性もあり、従ってタイマ推定の信号通知を先験的に回避することは計数精度を高めることになろう。
【００４５】
加えて反復値は、曖昧性、即ち同一送信セッション特定情報を種々の送信セッションに使用する場合のより良い処理を許容する。例えば、ファイル特定情報が４オクテットのサイズを有し、送信セッション特定情報に８ビットのサイズがあれば、同一送信セッション特定情報が種々のＴＯＩを有する種々のファイルに対して生成される可能性がある。この曖昧性により、反復値が提供されていない場合、受信デバイスは、セッションが新規であると想定し、後からそうでなく、データを既に受信していたことが判明すると考えられる。この状況は、セッションの反復の是非を示す反復値の使用により回避される。
【００４６】
本発明の第２の態様の例示的実施形態では、送信セッション特定情報フィールドの最大有意ビット（ＭＳＢ）を、次セッションの反復の是非を受信デバイスに信号通知するために留保する。「０」の値はその場合セッションが新規セッションであることを示すことができ、「１」の値はセッションが反復セッションであることを示すことができ、またはその逆も同様である。
【００４７】
本発明の第２の態様の前のステップでは、送信デバイスは送信セッション特定情報を全て使用するかを判断することができる。その場合、送信セッションが新規送信セッションである場合には、同じ所定の反復値を使用することができ、その場合には送信セッション特定情報を使用しない。従って、送信セッション特定情報フィールドを使用しない場合、次期送信セッションが新規セッションであることの指示が受信デバイスに対して常に存在することになろう。
【００４８】
さらに、反復値を次期送信セッションが新規送信セッションであることを示す値に最後に設定した後、所定の時間の後に、送信デバイスは、次期送信セッションが新規送信セッションであることを示す値に反復値を設定するとよい。送信デバイスは、この目的のために、所与の送信セッション特定情報の有効性に対するタイマを維持するとよい。タイマが満了するか、または再使用を行えば、送信デバイスは次期送信セッションが新規送信セッションであることを示す値に反復値を設定すればよい。
【００４９】
受信デバイスが、次期送信セッションに関する通知を受信すると、受信デバイスは通知における送信セッション特定情報フィールドの反復値を評価する。続いて、反復値が次期送信セッションが新規送信セッションであることを示す場合、受信デバイスは通知に応答すればよい。あるいは、またはさらに、反復値が、次期送信セッションが新規送信セッションであることを示す場合、受信デバイスは次期セッションのデータを取得すればよい。
【００５０】
反復値が次期送信セッションが新規送信セッションであることを示さない場合でも、対応する前の送信セッションのコンテンツを正しく受信していないと判断すれば、受信デバイスはさらに、この通知への応答、および／または次期セッションのデータの取得を実行することができる。
【００５１】
本発明の第３の態様によれば、次期送信セッションに関し受信デバイスに通知する方法を提案し、この方法は、送信セッション特定情報により特定される送信セッションにおけるデータの取得を終了させることができる送信セッション特定情報を判断するステップを受信デバイスにおいて含む。この方法は、この送信セッション特定情報のために格納するコンテキストデータを解放するステップをさらに含む。
【００５２】
さらに、本発明の第３の態様が有するこの方法を実現するための手段を備える受信デバイスを提案する。さらに、ソフトウエアプログラム製品を提案し、この製品は、受信デバイスの処理ユニットにおいて動作する場合に本発明の第３の態様が有する方法のステップを実現するソフトウエアコードを格納する。
【００５３】
本発明の第３の態様は、幾つかの場合に受信デバイスが、個々の送信セッションの持つデータの取得がなお適切か、または可能であるかを自ら明確に判断することができるとの考えに由来する。
【００５４】
送信セッション特定情報の再使用を容易にするのは、本発明の第３の手法の利点である。受信デバイスが個々の送信セッションを最早見張らなくてもよいことを比較的早い時点で知ることは、本発明の第３の手法のさらなる利点である。
【００５５】
受信デバイスが、送信セッション特定情報のインスタンスのコンテキストデータを解放することができると判断できることの基礎となる、幾つかの可能なイベントが存在する。
【００５６】
第１の可能なイベントとして、関係する全ファイルまたはファイルグループを正しく受信している。
【００５７】
第２の可能なイベントとして、ファイルまたはファイルグループの送信終了を検出するか、または判断する。これは、例えばＴＯＩを記述する大部分の直近のＦＤＴインスタンスが満了するか、またはオブジェクトの終了を受信する、などの場合でありうる。
【００５８】
第３の可能なイベントとして、ダウンロードセッションの終了を検出するか、または判断する。これは、例えばＳＤＰ終了時間が来る、セッションフラグの終了を受信する、などの場合でありうる。
【００５９】
特定の送信セッション特定情報のインスタンスのためのコンテキストデータを解放することができることの判断または検出は、例えば受信デバイスのアプリケーション部から受信デバイスのベアラー部へ、そのセッション送信特定情報、例えばＴＭＧＩまたはベアラー特定情報に対する通知／ページングに応答しないように指示するために使用することができる。結果として、受信デバイスが、移動通信システムのユーザ装置であれば、この受信デバイスはセルベースの応答受信デバイスの計数には計数されないであろう。受信デバイスが、同一送信セッション特定情報値を使用して、複数の「送信セッション」を受信すれば、これら「送信セッション」を全て解放し、その後セッション送信特定情報に対する関係データを解放すべきであることに注意すべきである。
【００６０】
本発明の種々の態様をそれ自体により、または任意の組み合わせにおいて使用することができることを理解すべきである。
【００６１】
いずれの場合においても、送信デバイスは、排他的ではないが例えばＢＭ−ＳＣであることができる。いずれの場合においても、受信デバイスは、排他的ではないが例えば移動局のような移動通信システムのユーザ装置であることができる。送信セッションは、排他的ではないが例えばストリーミングまたはダウンロードサービスを提供する、例えばＭＢＭＳセッションであることができる。
【００６２】
本発明の他の目的および特徴は、添付する図面と共に考察する以下の詳細な説明から明らかになるであろう。とはいえ、図面はただ図示する目的のために考えられており、本発明の範囲を規定するものとして考えられておらず、本発明の範囲については添付する本発明の範囲を参照すべきであることを理解すべきである。図面は寸法に比例して描かれておらず、単に本明細書において記述する構成および手順を概念的に図示するために考えられていることをさらに理解すべきである。
【発明を実施するための最良の形態】
【００６３】
図４は、ユーザ装置への次期ＭＢＭＳセッションに関する通知を本発明により実装することができる例示的通信システムの概要図である。
【００６４】
通信システムは、コアネットワーク４０および複数の中の１ネットワークのみを示す無線接続ネットワーク（ＲＡＮ）４４を含む移動通信ネットワークを備える。各ＲＡＮ４４は、１以上の無線セルにおける移動端末８０、即ちユーザ装置ＵＥに従来手法でサービスを提供する。例えばＵＭＴＳの場合、ＲＡＮ４４はこの目的のために複数のＲＮＣを備え、各ＲＮＣに複数のノードＢを接続すればよく、例えばＧＳＭの場合は、ＲＡＮ４４はこの目的のために複数のＢＳＣを備え、各ＢＳＣに複数のＢＴＳを接続すればよい。コアネットワークは複数のＳＧＳＮ（サービングＧＰＲＳサポートノード）の内の１つのみを示すＳＧＳＮ４１、ＧＧＳＮ４２およびＢＭ−ＳＣ６０を備える。ＭＢＭＳユーザ・サービス・プロバイダのコンテンツサーバ４６を、例えばインターネット（図示せず）を介してＢＭ−ＳＣ６０に接続することができる。ＢＭ−ＳＣ６０は、ＧＧＳＮ４２、それぞれのＳＧＳＮ４１およびそれぞれのＲＡＮ４４を介してコンテンツサーバ４６と移動端末８０との間のＭＢＭＳセッションを可能にする。移動局８０はこのように本発明による受信デバイスであり、一方ＢＭ−ＳＣ６０は本発明による送信デバイスである。
【００６５】
図５は、提示する本発明の実施形態において使用する図４の通信システムが有する、移動端末８０およびＢＭ−ＳＣ６０の詳細を図示するブロック図である。
【００６６】
ＢＭ−ＳＣ６０は、通知サポートソフトウエア６２を含むＢＭ−ＳＣ６０に実装するソフトウエアコードを動作させる、処理ユニット６１を備える。通知サポートソフトウエア６２は、ＢＭ−ＳＣ６０により使用されるより包括的なソフトウエアコードの一部を形成することができることを理解すべきである。ＢＭ−ＳＣ６０は、サポートする各ユーザサービスのための１２８の１ビット記載事項を有するテーブル６４を格納する、メモリ６３をさらに備える。即ち、各テーブルの記載事項は値「０」または値「１」を有することができる。メモリ６３は処理ユニット６１によりアクセスすることができる。ＢＭ−ＳＣは１２８のタイマ６５をさらに備え、各タイマ６５はテーブル記載事項の１記載事項に関連する。関連するテーブル記載事項を値「０」により上書きするたびに、各タイマ６５を再設定する。関連するタイマ６５が満了するか、またはＭＢＭＳセッションＩＤ値において再使用が生じれば、即ちＭＢＭＳセッションＩＤ値を新規ＭＢＭＳセッションのために初めて使用すれば、テーブル記載事項を値「０」により上書きする。
【００６７】
移動端末８０は、通知評価ソフトウエア８２を含む移動端末８０に実装するソフトウエアコードを動作させる処理ユニット８１を備える。通知評価ソフトウエア８２は移動端末８０により使用されるより包括的なソフトウエアコードの一部を形成することができることを理解すべきである。移動端末８０は、要求する各ユーザサービスのための１２８の記載事項を有するテーブル８４を格納するメモリ８３をさらに備える。各記載事項は、ダウンロードセッションＩＤ、ＦＤＴインスタンスＩＤ、グループＩＤ、受信データに属するＴＯＩ（単数または複数）、およびそれぞれのＭＢＭＳセッションＩＤフィールドと共に受信するデータの受信時間を含むことができる。
【００６８】
本発明の実施形態による図４の通信システムにおける動作を、次に図６乃至８を参照して記述することにする。
【００６９】
図６は、ＢＭ−ＳＣ６０における動作を示すフローチャートである。通知サポートソフトウエア６２を動作させた場合、提示するステップがより特定的に処理ユニット６１により実行される。
【００７０】
ＢＭ−ＳＣ６０が、個々のユーザサービスのためにコンテンツサーバ４６が提供するコンテンツを送信するために、新規または反復ＭＢＭＳセッションを確立することを考慮する場合に（ステップ６０１）、ＢＭ−ＳＣ６０は、まずセルレベルにおけるＭＢＭＳセッションに参加することを望む移動端末をより正確に計数することを可能にするためにＭＢＭＳセッションＩＤを使用することの是非を判断する（ステップ６０２）。
【００７１】
ＭＢＭＳセッションＩＤを使用しないのであれば、ＢＭ−ＳＣ６０はＭＢＭＳセッションＩＤフィールドの値を次期ダウンロードセッションに対して「０」に設定する（ステップ６０３）。
【００７２】
ＭＢＭＳセッションＩＤを使用するのであれば、ＢＭ−ＳＣ６０は次期ダウンロードセッションに対するＭＢＭＳセッションＩＤフィールドのためのデータを集める。このようなＭＢＭＳセッションＩＤフィールドの構成を図７に図示する。見て分かるように、ＭＢＭＳセッションＩＤフィールド７０は１オクテットのサイズを有し、特定情報ビット７１に対する７ＬＳＢおよびセッション反復フラグ７２に対する１ビットを含む。
【００７３】
ＢＭ−ＳＣ６０は、まずＭＢＭＳセッションＩＤの生成のために使用するダウンロードセッションに属するＩＤのタイプを選択する。より具体的には、ＢＭ−ＳＣ６０はＭＢＭＳセッションにおいて送信するコンテンツを判断し、このコンテンツに基づき適切な特定情報タイプを選択する（ステップ６０４）。
【００７４】
ＢＭ−ＳＣ６０は、ＭＢＭＳセッションＩＤの生成のための基本として、例えばダウンロード配信セッションファイル、ＦＬＵＴＥファイルグループ、ファイルグループ、外部ファイルグループ、１つのＦＤＴインスタンスまたはダウンロード配信セッションにおいて宣言する全てのファイルを選択する。
【００７５】
次に、ＢＭ−ＳＣ６０は、選択したＩＤタイプのそれぞれのＩＤまたは複数のＩＤを、ＭＢＭＳセッションＩＤとしてＭＢＭＳセッションＩＤフィールドの７ＬＳＢに対応付ける（ステップ６０５）。
【００７６】
ＭＢＭＳセッションＩＤを、例えばダウンロード配信セッションのファイルに対して生成するのであれば、ＢＭ−ＳＣ６０はファイルが有するＴＯＩの７ＬＳＢをＭＢＭＳセッションＩＤフィールドの７ＬＳＢに対応付ける。ＭＢＭＳセッションＩＤを、例えばＦＬＵＴＥファイルグループに対して生成するのであれば、ＢＭ−ＳＣ６０はＦＤＴインスタンスＩＤにおいて送信するグループ専用特定情報の７ＬＳＢをＭＢＭＳセッションＩＤフィールドの７ＬＳＢに対応付ける。ＭＢＭＳセッションＩＤを、例えばファイルグループに対して生成するのであれば、ＢＭ−ＳＣ６０はファイルリストを表すＴＯＩリストから例えばハッシュ関数により７ビットの値を生成する。ＢＭ−ＳＣ６０は、次いでこの値をＭＢＭＳセッションＩＤフィールドの７ＬＳＢに対応付ける。ＭＢＭＳセッションＩＤを、例えば外部ファイルグループに対して生成するのであれば、ＢＭ−ＳＣ６０はこの外部ファイルグループのファイルと、他のデータエンティティが例えばＦＬＵＴＥ配信、ＳＭＳ、などにより分離してＢＭ−ＳＣ６０に通信したＳＭＳ、ＳＤＰファイル、などのような幾つかの他のデータエンティティにおいて規定するＭＢＭＳセッションＩＤとの間の対応付けを使用する。再び、ＭＢＭＳセッションＩＤは１つの外部ファイルの特定情報、または特定情報の一部に適用するハッシュ関数に基づくことができる。ＢＭ−ＳＣ６０は、このＭＢＭＳセッションＩＤをＭＢＭＳセッションＩＤフィールドの７ＬＳＢに対応付ける。ＭＢＭＳセッションＩＤを、例えば１つのＦＤＴインスタンスにおいて宣言する全てのファイルに対して生成するのであれば、ＢＭ−ＳＣ６０はＦＤＴインスタンスＩＤの７ＬＳＢをＭＢＭＳセッションＩＤフィールドの７ＬＳＢに対応付ける。ＭＢＭＳセッションＩＤを、例えばダウンロード配信セッションに対して生成するのであれば、ＢＭ−ＳＣ６０はＴＳＩの７ＬＳＢをＭＢＭＳセッションＩＤフィールドの７ＬＳＢに対応付ける。
【００７７】
次いで、ＢＭ−ＳＣ６０は、決定したＭＢＭＳセッションＩＤへその指標により関連付けられたテーブル６４におけるＭＳＢの値を読み、ＭＢＭＳセッションＩＤフィールドのＭＳＢの位置におけるセッション反復フラッグとしてＭＢＭＳセッションＩＤフィールドにその値を加える（ステップ６０６）。
【００７８】
さらに、ＢＭ−ＳＣ６０はＭＢＳテーブル記載事項を値「１」に設定する。一方、ＭＢＭＳセッションがＭＢＭＳセッションの最後の反復であるとすれば、ＢＭ−ＳＣ６０はＭＢＳテーブル記載事項を値「０」に設定する（ステップ６０７）。
【００７９】
ＭＢＭＳセッションＩＤフィールドおよびＴＭＧＩを、次いでＭＢＭＳセッション開始要求部としてＧＧＳＮ４２に提供する（ステップ６０８）。ＴＭＧＩを従来手法においてＢＭ−ＳＣによりグローバルに割り当て、ＴＭＧＩは従ってローカルＭＢＭＳベアラーサービス特定情報および移動通信ネットワーク４０、４４のＰＬＭＮの特定情報を含む。
【００８０】
ＧＧＳＮ４２は、ＴＭＧＩおよびセッションＩＤを含むページングメッセージを生成し、ＭＢＭＳセッション通知としてＲＡＮ４４を介して移動端末８０に送信するように取り計らう。
【００８１】
図８は、移動端末８０における動作を示すフローチャートである。通知評価ソフトウエア８２を動作させた場合、提示するステップがより特定的に処理ユニット８１により実行される。
【００８２】
ページング要求を受信すると（ステップ８０１）、移動端末８０はまず含まれるＭＢＭＳセッションＩＤフィールドを評価すべきか判断する（ステップ８０２）。
【００８３】
移動端末８０がＭＢＭＳセッションＩＤフィールドを評価しないと判断すれば、移動端末８０は、データがなお必要かを判断するために次期ＭＢＭＳセッションのデータを取得する（図示せず）。
【００８４】
移動端末８０がＭＢＭＳセッションＩＤフィールドを評価すると判断すれば、移動端末８０は、まずＭＢＭＳセッションＩＤフィールドのＭＳＢに符合するセッション反復フラッグを調べる（ステップ８０３）。
【００８５】
ＭＢＭＳセッションＩＤフィールドのＭＳＢの値が「０」であれば、移動端末は次期ＭＢＭＳセッションにおけるデータが新規データであると想定する。この場合、移動端末８０はページング要求に応答し、ＭＢＭＳセッションにおけるデータを取得し、セッションデータを正しく受信後、新規データによりテーブル８３の関連記載事項を上書きする。関連する記載事項の指標は、ＭＢＭＳセッションＩＤフィールドの７ＬＳＢに符合する。一方、移動端末８０がこのＭＢＭＳセッションのために格納されたコンテキストデータを最早必要としないことを示すイベントを検出すると、移動端末８０はコンテキストデータ、即ちＭＢＭＳセッションに関連するテーブル記載事項におけるデータを解放し、従ってテーブル記載事項を別のＭＢＭＳセッションに使用することができる（ステップ８０４）。ＢＭ−ＳＣ６０がＭＢＭＳセッションＩＤを使用しないと判断したとすれば、この場合ＭＢＭＳセッションＩＤフィールドのＭＳＢが同じく「０」に設定されるため、新規データの着信が、また想定されることに注意すべきである。この場合、関連記載事項の指標を、取得するデータにおける特定情報に基づいて移動端末８０により決定することができる。
【００８６】
ＭＢＭＳセッションＩＤフィールドのＭＳＢの値が「１」であれば、移動端末８０はこの値をセッション反復の指示と解釈する。移動端末８０はＭＢＭＳセッションＩＤフィールドの７ＬＳＢに符合する指標を有するテーブル記載事項を選択する（ステップ８０５）。このテーブル記載事項に符号する項目を、正しく受信したものとテーブル８４において特定されれば（ステップ８０６）、移動端末８０はＭＢＭＳ通知メッセージに応答しない（ステップ８０７）。このテーブル記載事項に符合する項目を、正しく受信したものとテーブル８４において特定されなければ（ステップ８０６）、対照的に移動端末８０はＭＢＭＳ通知メッセージに応答する。さらに、移動端末８０はＭＢＭＳセッションにおけるデータを取得し、セッションデータを正しく受信後、新規データによりテーブル８３の関連記載事項を上書きする。一方、移動端末８０が関係データを最早必要としないことを示すイベントを検出すると、移動端末８０は関連するテーブル記載事項を解放し、従ってテーブル記載事項を別の送信セッションに使用することができる（ステップ８０８）。
【００８７】
このように、実際に送信を必要とするこれら移動端末のみがページングメッセージに応答するので、それぞれのセルにおける移動端末の正確な計数がこのセルにサービスを提供するＲＡＮ４４において可能になる。従って、移動局がタイマを使用して、受信するＭＢＭＳセッションＩＤの有効性を判断することを必要とせず、最も適する送信タイプ、即ちポイント・ツー・ポイントまたはポイント・ツー・マルチポイントを、このセルにおけるＭＢＭＳセッションに対して選択することができる。さらに、より細かな粒度は冗長な情報の送信を回避する手助けになる。
【００８８】
本発明の好ましい実施形態に適用する場合の本発明の基本的に新規な特徴を提示、記述し、指摘したが、本発明の精神から逸脱することなく記述するデバイスおよび方法の形態および詳細における種々の削除、置換および変更を当該技術者により為しうることは理解されよう。例えば、同じ結果を得るために本質的に同じ方法で本質的に同じ機能を実行するこれら要素および／または方法のステップの全ての組み合わせは、本発明の範囲内にあると特に考えられる。さらに、本発明の開示する形態または実施形態と共に提示および／または記述する構成および／または要素および／または方法のステップは、設計選択の一般的問題として他の開示または記述または示唆する形態若しくは実施形態に組み込むことができるものと認識すべきである。それ故、本明細書に添付する本発明の特許請求の範囲によって指示するようにのみ制限されると考える。
【図面の簡単な説明】
【００８９】
【図１】ＭＢＭＳサービス配信に関する機能レイヤの概要図である。
【図２】図１の機能レイヤの間の関係を図示する概要図である。
【図３】ＧＥＲＡＮにおけるＭＢＭＳセッションのための通知処理を示す概要図である。
【図４】本発明の実施形態を実装することができる通信システムの概要図である。
【図５】図４の通信システムにおける移動端末の実施形態およびＢＭ−ＳＣの実施形態の概要ブロック図である。
【図６】図５のＢＭ−ＳＣにおける動作を概括的に示すフローチャートである。
【図７】図４の通信システムにおいて使用するセッションＩＤフィールドの構成を図示する概要図である。
【図８】図５の移動端末における動作を概括的に示すフローチャートである。
【図１】
2008536373.tif 000003
【図２】
2008536373.tif 000004
【図３】
2008536373.tif 000005
【図４】
2008536373.tif 000006
【図５】
2008536373.tif 000007
【図６】
2008536373.tif 000008
【図７】
2008536373.tif 000009
【図８】
2008536373.tif 000010
【国際調査報告】
2008536373.tif 000011
2008536373.tif 000012
2008536373.tif 000013
2008536373.tif 000014
2008536373.tif 000015