JP2009531917A - メッセージ要素の内容表示方法 - Google Patents

Abstract

本発明によるメッセージ要素の内容を指示するための方法は、当該メッセージ要素外のインジケータを供給することからなっている。これは特にデュアルトランスファーモードハンドオーバーコマンドの指示に該当している。

Description

本発明は、例えば５つのメッセージが存在するデュアルトランスファモードハンドオーバーコマンドなどのようなメッセージ要素の内容を表示する方法に関しており、特に、例えばＧＰＲＳ（General Packet Radio Service）、ＥＤＧＥ（Enhanced Data Rates for GSM Evolution)、ＤＴＭハンドオーバー等のためのデュアルトランスファモード（ＤＴＭ）ハンドオーバーコマンドの改善された表示方法の提供に関している。ＤＴＭハンドオーバーは最近になって移動電話用に許容されるべく設計仕様されたプロシージャであり、このプロシージャは現在のところ新たなセルに対してハンドオーバーすべく割り当てないし確保された回線交換（ＣＳ）リソースとパケット交換（ＰＳ）リソースを有している。このプロシージャはＣＳリソースとＰＳリソースの平行したハンドオーバーのために、既存のプロシージャを使用している。

図１及び図２に示されているように、ソースベースステーションサブシステム（ＢＳＳ）１は２つのリクエストの送信によってハンドオーバーを開始する。この場合１つは回線交換リソースに関するものであり、これはＣＳコアネットワーク３に送信され、他のもう１つはＰＳ（パケット交換）リソースに関し、ＰＳコアネットワーク７へ送信されている。これらのリクエストは順方向に各コアネットワークを介してターゲットＢＢＳ５まで転送される。

それらのリクエストに添付されているのは、ＤＴＭハンドオーバープロシージャの部分を形成するリクエストの指示である。それによりターゲットＢＢＳ５は、第１のリクエストの受信時に、第２のリクエストに対する待機をリソース割り当て前に知ることができる。

通常は、ターゲットＢＢＳはＰＳリソースとＣＳリソースの両方を割り当て、"ＤＴＭハンドオーバーコマンド"メッセージを構築する。これは両コアネットワーク３，７を介してソースＢＢＳまで返信される。それによりソースＢＢＳは適切なメッセージ内に封入されるメッセージの２つのコピーを受信する。

しかしながら例えば遅延や喪失などの問題がコアネットワークにおいて生じたならばそれは唯１つのリクエストしか受信されないこと、あるいは可用なリソースの欠落を意味し、ターゲットＢＢＳ５は最後にはＰＳ若しくはＣＳのうちのどちらか１つのドメインにおけるリソースのみの割り当てに終止してしまう結果となる。ＣＳリソースのみが割り当てられた場合には、ターゲットＢＢＳは１つのハンドオーバーコマンドを構築し、それをＣＳコアネットワーク３を介してソースＢＢＳまで返信する。

コアネットワークノードに与える影響がでないことを保証するためには、移動交換センサ（ＭＳＣ）とＳＧＳＮ（serving GPRS Support node)、ＣＳ及びＰＳハンドオーバーのための既存のメッセージフローが各ドメイン内で使用される。通常は新たな情報要素は既存のメッセージに容易に追加することができ、情報要素識別子（ＩＥＩ）によって識別される。しかしながらＣＳハンドオーバーのケースでは、いくつかの既存の情報要素（特に無線を介して移動局へ送信すべきハンドオーバーコマンドメッセージの含まれている情報要素）は、特にコアネットワークによって特殊な方法で処理されなければならない。それらの情報要素はコアネットワークによって検査ができないのに、ターゲットＢＢＳからソースＢＢＳまで透過的に通過する。コアネットワークによる同じような処理はＤＴＭハンドオーバーに使用される相応のＤＴＭハンドオーバーコマンドメッセージに対しても要求される。それ故、コアネットワークに必要とされる変更を最小にするために、有利には、ＤＴＭハンドオーバーのケースにおいて移動局へ送信されるメッセージが慣用のＣＳハンドオーバーに使用されるエアーインターフェースハンドオーバーコマンドの搬送に使用されるのと同じ情報要素識別子ＩＥＩによって識別された情報要素ＩＥ内に含まれる。

しかしながらソースＢＳＳにおいて、ＣＳハンドオーバー又はＤＴＭハンドオーバーに関する情報要素の内容を確定するのが不可能な場合には非常に困難となり得る。それ故ＣＳコアネットワークからのＤＴＭハンドオーバーコマンドが含まれている受信メッセージと（ＣＳのみの）ハンドオーバーコマンドが含まれているメッセージとの間の区別も難しくなる。これらのメッセージは非常に複雑な方法で処理されるので、ソースＢＢＳはどのメッセージがハンドオーバーの進行のために含まれているのかを知る必要がある。

いくつかの状況においてはソースＢＢＳにとってどのメッセージが含まれているかを推論することは可能である。例えばその成功例として、ＰＳドメインとＣＳドメインの両方から肯定応答の受信メッセージが受信された場合には、それらが両方ともＤＴＭハンドオーバーコマンドを含む。しかしながらＣＳコアネットワークからソースＢＢＳ１によって唯１つだけのメッセージが受信された場合には、どのタイプのメッセージが受信されたのかを確定することは不可能である。１つのメッセージは、ＤＴＭハンドオーバーがＣＳのみのハンドオーバーという結果になった場合のケースから推量され、必ずしもエラーケースというわけではない。

つまりＣＳドメインにおいて肯定応答が受信された場合と、ＰＳドメインにおいて、そのドメインでターゲットＢＢＳにより何のリソースも確保されないことを"原因"値を用いて指示する否定応答が受信された場合の内容を推論することは不可能である。その他のエラーケースは、ＰＳメッセージが何も受信されなかった場合、又はＰＳメッセージがＰＳコアネットワークにおいてエラーを示した場合に含まれるが、しかしながらそれらの問題に対する解決策は現在に至るまで何も提案されていない。本発明によるメッセージ要素の内容を指示するための方法は、当該メッセージ要素外のインジケータを提供することからなっている。

この発明は、１つのＩＥの内容を他の場合のＩＥを用いてシグナリング可能にするものであり、それによってコアネットワークノードが影響を受けることがなくなるが、受信されたメッセージがＤＴＭハンドオーバーコマンドを含んでいるか否かをソースＢＢＳが知ることは保証される。

有利にはメッセージ要素は識別部分と内容部分からなっている。

代替的にメッセージ要素はさらに長さ部分からなっている。

有利には前記インジケータは同じメッセージ要素内で送信された特定のビットシーケンスからなっている。

代替的に、前記インジケータは異なるメッセージ要素内で送信された特定のビットシーケンスからなっている。

有利には前記メッセージ要素はフィールド要素か、又は３ＧＰＰネットワーク内のデバイス間で送信されたメッセージの一部である情報要素である。

有利には前記インジケータは既存のメッセージ要素内のデュアルトランスファモードハンドオーバーコマンドの存在を指示し、当該方法は、既存のメッセージ要素内のデュアルトランスファモードハンドオーバーコマンドの存在を他のメッセージ要素における指示子を送信する。

有利には、前記指示子は、他の情報要素内の１つ以上のエキストラビットからなっている。

有利には前記他の情報要素は新ＢＳＳから旧ＢＳＳのインフォメーション情報要素である。

有利には前記新ＢＳＳから旧ＢＳＳのインフォメーション情報要素はＢＳＳＭＡＰハンドオーバーコマンド内に含まれている。

以下では、本発明によるメッセージ要素の内容を指示するための方法の実施例を添付の図面を参照して説明する。

図１はリターンパス内でのエラーを伴ったデュアルトランスファモードハンドオーバーのメッセージシーケンスチャートを示した図であり、
図２はリターンパス内でのエラーを伴ったデュアルトランスファモードハンドオーバーのメッセージシーケンスチャートを示した図であり、
図３はＢＳＳＭＡＰハンドオーバーコマンドメッセージの一例を表した図である。

図１には、ソースＢＳＳがハンドオーバー要求メッセージ２をＣＳコアネットワーク３に送信しているメッセージシーケンスチャートが示されている。このＣＳコアネットワークはハンドオーバーリクエスト４をターゲットＢＳＳ５に送信する。同じようにソースＢＳＳ１はＰＳハンドオーバー要求メッセージ６をＰＳコアネットワーク７に送信する。このＰＳコアネットワーク７はＰＳハンドオーバーリクエスト８をターゲットＢＳＳ５に送信する。ＣＳリソース及びＰＳリソースがターゲットＢＳＳによって割り当てられている場合、ターゲットＢＳＳはハンドオーバーリクエスト受信応答１０をＣＳコアネットワークに返信し、ＣＳコアネットワークはＢＳＳＭＡＰハンドオーバーコマンド１１をソースＢＳＳに送信する。ターゲットＢＳＳはＰＳハンドオーバーリクエスト受信応答１２を送信する。これらのメッセージ１０，１１，１２は全てＣＳリソースとＰＳリソースの両方が割り当てられてからはＤＴＭハンドオーバーコマンドメッセージを含む。しかしながら何らかの遅延若しくはエラー１３のために、ＰＳドメイン内で、ＰＳコアネットワーク７から所定期間内に何もメッセージが送信されない場合は、Ｔ２３にて終了する（Ｔ２３ ｅｘｐｉｒｙ）１４。

図２には他のメッセージエラーが表されている。ソースＢＳＳ１はハンドオーバー要求メッセージ２をＣＳコアネットワーク３に送信する。このＣＳコアネットワーク３はハンドオーバーリクエスト４をターゲットＢＳＳ５に送信する。ソースＢＳＳはＰＳハンドオーバー要求メッセージ６を送信するが、但しＰＳドメイン内の遅延若しくはエラー１５のために、タイムリミットを越えてしまい、Ｔ２３にて終了する（Ｔ２３ｅｘｐｉｒｙ）。ターゲットＢＳＳはＣＳリソースのみを割り当て（１６）、ハンドオーバーリクエスト受信応答１０をコアネットワーク３に返信する。このコアネットワーク３はＢＳＳＭＡＰハンドオーバーコマンド１１をＴ２３での終了（T23 ｅｘｐｉｒｙ)前に送信する。これらのメッセージ１０，１１はＣＳリソースのみしか割り当てられていないのでハンドオーバーコマンドメッセージしか含まない。

本発明はＩＥの未知の内容である実質的にはＤＴＭハンドオーバーコマンドを表示すべく情報要素を加算していわゆる"透明なコンテナ"を存在させるものである。新たに定められたＩＥの不在は、ＣＳだけのためのハンドオーバーコマンドメッセージであることを指示し、これはＣＳのみのハンドオーバーコマンドのケースにおいて慣用の特性に相応し、それ故にバックワードコンバーチブルである。

ＢＳＳＭＡＰハンドオーバーコマンドの例は図３に示されている。このハンドオーバーコマンドメッセージはモバイルステーションコントローラ（ＭＳＣ）からベースステーションサブシステムＢＳＳに送信され、モバイルステーション（ＭＳ）が再調整するターゲットチャネルを含んでいる。

図３にはＢＳＳＭＡＰハンドオーバーコマンド１１が表されており、これは（情報要素としての関連で）メッセージ要素を作り上げ、レイヤ３の情報、情報要素（ＩＥ）２０を含み、さらに新ＢＳＳインフォメーションメッセージから旧ＢＳＳ情報メッセージ２１を含んでいる。レイヤー３インフォメーション情報要素ＩＥ２０は情報要素識別子（ＩＥＩ）２２、長さ情報２３、ハンドオーバーコマンドやＤＴＭハンドオーバーコマンドなどのコンテンツ２４からなっている。新ＢＢＳから旧ＢＳＳのインフォメーション情報要素２１は、情報要素識別子（ＩＥＩ）２５、長さ情報２６，複数のＤＴＭハンドオーバーコマンド表示メッセージ２７を有している。ＤＴＭハンドオーバーコマンド表示メッセージ２７はＩＥＩ２８とオプショナルコンテンツ２９を有している。新ＢＢＳから旧ＢＳＳのインフォメーションメッセージ２１内においては表示メッセージ２７の存在若しくは不在が、レイヤー３インフォメーション情報要素の内容を示すのに使用できる。又は表示メッセージ２７内の何らかの特定の内容２９がこの目的のために設けられる
以下のテーブル１は図１及び２において（ＢＳＳＭＡＰ）ハンドオーバーコマンド（これはレイヤー３インフォメーションＩＥに包含され得るハンドオーバーコマンドと同じではない）として示されていることに関連するものである。このレイヤ３インフォメーションはＤＴＭハンドオーバーコマンドか又はハンドオーバーコマンドを含んでいる。通常は情報要素（ＩＥ）の内容はＩＥＩの値によって識別される。しかしながらこのケースにおいてはそれらが共に同じＩＥＩ（これはレイヤー３インフォメーションＩＥ）によって識別されるので、ソースＢＳＳはこの手法によってレイヤー３情報ＩＥの内容を確定できない。

いくつかのケースにおいては進行中のプロシージャのタイプによって内容を確定することが可能である（例えば他のＧＳＭセルに対するハンドオーバー又はＵＭＴＳ（ＵＴＲＡＮ）セルに対するハンドオーバーなど）。ＤＴＭハンドオーバーのケースにおいては、旧ＢＳＳ情報はＤＴＭハンドオーバープロシージャを開始し、新ＢＳＳ情報はそれをＣＳハンドオーバーだけに絞るべく変更する。それ故に旧ＢＳＳ情報は、どのプロシージャが当該ケースにおいて進行中かは正確に認識できない。

しかしながら新ＢＳＳから旧ＢＳＳのインフォメーションＩＥはさらに以下でも説明する３ＧＰＰＴＳ４８.００８標準ドキュメントから抽出して説明する"フィールド要素（Field Elements）"として関連するサブセクションに細分化される。３.２.２.８０ New BSS to Old BSS Informationこの情報要素は、ＭＳＣを介したＢＢＳ間でフィールド要素を通過させるための基本コンテナとして定められる。

それらのフィールド要素は新ＢＳＳ情報要素フィールドから旧ＢＳＳ情報要素フィールドに通過される。エラーハンドリングはサブクローズ３.１.１９.７において特定された新ＢＳＳから旧ＢＳＳ情報要素フィールドのためのエンティティの受信によって実行される。

テーブル２内の長さ指示子（ｏｃｔｅｔ２）は二進数であり、長さインジケータｏｃｔｅｔがゼロにセットされた後で内容の絶対長さを表示している。新ＢＳＳから旧ＢＳＳの情報要素フィールドはテーブル３にリストアップされた０若しくはそれ以上のフィールド要素から作成される。それらのフィールド要素は、旧ＢＳＳから新ＢＳＳの情報要素フィールドにおける何らかの状態において現われる。フィールド要素の構成は未知のフィールド要素を無視するための受入れを許容する。

新ＢＳＳから旧ＢＳＳの誤ったインフォメーションＩＥの受信は、ハンドオーバーコマンド（HANDOVER COMMAND）又はハンドオーバーエラーメッセージ（HANDOVER FAILURE message）の拒絶を引き起こさない。そのようなケースでは新ＢＳＳから旧ＢＳＳのインフォメーションＩＥが放棄され、ハンドオーバープロシージャが継続される。

テーブル４に示されているように、レイヤー３インフォメーションＩＥが、ハンドオーバーコマンドではなくてＤＴＭハンドオーバーコマンドであったことを指示するために当該ＩＥに付加的フィールド要素を加算することが可能である。

プロシージャに対するこのような付加なしで、ソースＢＢＳはいくつかのケースにおいては、受信したメッセージのタイプがとのタイプなのか確定できない理由からハンドオーバーを中途終了する。このことは、例えばＣＳのみのハンドオーバーよりも信頼性を低下させる。

本願発明は他の方法では不可能であったケースにおいてソースＢＳＳに受信したメッセージのタイプの確定とハンドオーバーへの選択を可能にさせる。このことは"原因"値（cause value）を用いた既存の（若しくは代替的な）機構に比べてメリットをもたらす。なぜなら本願発明の方法は、メッセージの内容がどの原因値を指示しているかを認識できるソースＢＳＳよりもシンプルだからである。さらに本願発明は将来的にも耐え得る。なえならそれらの原因値は将来的に変更されるからである。

ＤＴＭハンドオーバーコマンド情報要素の一例は以下に定められる。

新ＢＢＳから旧ＢＢＳのインフォメーションＩＥにおけるフィールド要素の存在は、（ＲＬＣ／ＭＡＣ）ＤＴＭ ＨＡＮＤＯＶＥＲ ＣＯＭＭＡＮＤ メッセージが同じＢＳＳＭＡＰメッセージ内で搬送されたレイヤー３インフォメーションＩＥ内に含まれていることを指示する。

フィールド要素と情報要素がどこにあるかは、当該記述、等価語、大型構造の表示成分要素など目的毎に異なる。さらにスペアビットは今後の定義を定めるべく用いられ得るが、現下ではそれらは全てゼロになるまで定義される。

Claims (10)

1. メッセージ要素の内容を指示するための方法において、当該メッセージ要素外のインジケータを供給することを特徴とする方法。
2. メッセージ要素が識別部分と内容部分からなっている、請求項１記載の方法。
3. メッセージ要素がさらに長さ部分からなっている、請求項２記載の方法。
4. 前記インジケータは同じメッセージ要素内で送信された特定のビットシーケンスからなっている、請求項１から３いずれか１項記載の方法。
5. 前記インジケータは異なるメッセージ要素内で送信された特定のビットシーケンスからなっている、請求項１から３いずれか１項記載の方法。
6. 前記メッセージ要素はフィールド要素か、又は３ＧＰＰネットワーク内のデバイス間で送信されたメッセージの一部である情報要素である、請求項１から５いずれか１項記載の方法。
7. 前記インジケータは既存のメッセージ要素内のデュアルトランスファモードハンドオーバーコマンドの存在を指示し、既存のメッセージ要素内のデュアルトランスファモードハンドオーバーコマンドの存在を他のメッセージ要素における指示子が送信される、請求項１から６いずれか１項記載の方法。
8. 前記インジケータは他の情報要素内の１つ以上の特別なビットからなっている、請求項１から７いずれか１項記載の方法。
9. 前記他の情報要素は新ＢＳＳから旧ＢＳＳの情報要素である、請求項８記載の方法。
10. 新ＢＳＳから旧ＢＳＳのインフォメーション情報要素はＢＳＳＭＡＰハンドオーバーコマンド内に含まれている、請求項９記載の方法。

Images