JP4386286B2 - 移動通信システムおよび通信制御方法 - Google Patents
移動通信システムおよび通信制御方法 Download PDFInfo
- Publication number
- JP4386286B2 JP4386286B2 JP2005208446A JP2005208446A JP4386286B2 JP 4386286 B2 JP4386286 B2 JP 4386286B2 JP 2005208446 A JP2005208446 A JP 2005208446A JP 2005208446 A JP2005208446 A JP 2005208446A JP 4386286 B2 JP4386286 B2 JP 4386286B2
- Authority
- JP
- Japan
- Prior art keywords
- ind
- information
- req
- radio
- concealment
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Landscapes
- Mobile Radio Communication Systems (AREA)
Description
上記発明によれば、マルチメディア化に対応した各種データの伝送に適したCDMA方式の無線通信方法および無線通信システムを提供することができる。
この発明は、基地局は、とまり木チャネルを介して、とまり木チャネル送信電力値および上り干渉量を含む報知情報を送信し、移動局は、周辺の各基地局から前記報知情報を受信するとともに各基地局毎に前記とまり木チャネルの受信レベルを検知し、各基地局毎に前記受信レベルおよび前記報知情報内のとまり木チャネル送信電力値から当該移動局と当該基地局との間の伝搬損失を算出し、前記各基地局毎に算出した伝搬損失、前記各基地局からの報知情報に含まれる上り干渉量および基地局所要受信SIRを用いた演算により各基地局毎に所要上り送信電力を算出し、待ち受けるべき無線ゾーンまたは通過中にハンドオーバすべき無線ゾーンを選択するに当たっては、所要上り送信電力が最小となる無線ゾーンを選択し、当該所要上り送信電力に基づいて上り送信電力の制御を行うことを特徴とする無線ゾーンおよび上り送信電力の制御方法を提供するものである。
(1.1):はじめに
本システムは、周波数利用効率の向上を図り、多元・高速信号へ柔軟に対応するとともに、固定網相当の高品質化等を実現すべく、無線アクセス方式にWideband−Code Divison Multiple Access(W−CDMA)を適用した移動通信システムに関するものである。
まず、本発明の一実施形態に係わるW−CDMA移動通信システムの全体構成を図1を参照して説明する。図に示すように本システムは、移動局装置(MS)および無線基地局系装置(BSS)から構成される。基地局系装置(BSS)は、無線基地局装置(BTS)と交換機(MCC)で構成され、有線伝送路(HW)で接続されている。
また、交換機(MCC)は、固定網PSTNやISDN、電話機、あるいはLANを介して パーソナルコンピュータと接続されている。
このような構成によって、高品質音声、N−ISDN、パケット、またはモデム信号の伝送が可能となっている。
次に、本明細書で用いる略語の説明を図265に示す。なお、この明細書において特に定義しない用語は、ITU−Tの勧告Q.65に準拠して記載する。
第2章は、W−CDMA移動通信システムのアクセス系インタフェースについての規 定を行うものである。本システムにおけるアクセス系インタフェースには、図2に示すように移動局装置(MS)と無線基地局装置(BTS)との間の無線インターフェ ース、および無線基地局装置(BTS)と交換機(MCC)間のBTS−MCCインターフェースが含まれる。なお、以下に説明するアクセス方式をW−CDMAのみならず、他のものに適用してもよいことは勿論である。
1)プロトコル規定に必要なシステム提供サービス、システム能力の規定
2)提供サービス、システム能力サポートのためのシステム機能構成及び制御方式
3)プロトコル規定のための参照構成、インタフェース規定点
4)無線インタフェースの物理構成、物理的条件
5)無線インタフェースにおける信号転送プロトコル(レイヤ2)
6)無線インタフェースにおける制御プロトコル(レイヤ3)
7)基地局・MCC間インタフェースの物理構成、電気的条件
8)基地局・MCC間インタフェースの情報伝達プロトコル
(ATMレイヤ,AAL type2)
9)基地局・MCC間インタフェースの信号転送プロトコル(AAL)
10)基地局・MCC間インタフェースの制御プロトコル(レイヤ3)
本章における制御方式、及びプロトコル仕様はTTC IMT−2000特別専門委員会NAアドホックにおける議論に基づいて作成された勧告草案Q.FNA,Q.FIF,Q.FSA,Q.FSRに準拠する。
次に、アクセス系インタフェースの特徴部分について説明する。
(2.2.1):ハンドオーバ
移動通信網においては、複数の無線ゾーンが設けられており、各無線ゾーンには基地局が各々設けられている。各基地局と移動局装置(MS)間の通信には、とまり木チャネルと呼ばれる無線チャネルが用いられ、周波数帯域の異なる複数のとまり木チャネルの中から通信に使用される無線チャネルが選択される。また、各とまり木チャネルには通信内容を伝送するためのトラヒックチャネルTCHが構成 されている。ところで、移動通信において、移動局装置(MS)が無線ゾーンを跨って移動すると、基地局からの電波の受信レベルが低下して通信品質が劣化する。このため、受信レベルの高い基地局との間で通信を行うように通信の相手方を変更する必要が生じる。この場合、移動局装置(MS)の使用するトラヒックチャネルTCHの切替が行われるが、このことはハンドオーバと呼ばれる。
付随制御チャネル(ACCH:Associated Control Channel)は、音声やデータの通信に使用されるトラフィックチャネルTCHと同一無線リソースを利用した制御チャネルである。このACCHを利用することにより、移動局(MS)と基地局(BS)との間で制御情報を授受を行うことができる。
この場合、複数の呼に対応した各無線リソース(すなわち、各トラヒックチャネルTCHに利用されている無線リソース)の各々に対してACCHを設定し、各ACCHを介して制御情報の授受を行う、という方法も考えられる。
まず、図260は、移動局が複数の通信を同時に行うことができるシステムの一例を示したものである。図260に示すように、移動局装置(MS)と基地局(BS)の間では、複数の呼に対応した各トラヒックチャネルTCHを介して、各呼に対応した通信が行われる。
また、基地局(BS)にはBCFr1およびBCFr2が、網内にはTACFがBSC機能として設けられている。
TACAFは、この切替要求を受け取るとACCH2の設定要求をBCAF2に通知し、BCAF2はACCH2の設定を行う。
この後、TACAFはACCHが切り替わったことを報告する切替完了通知をTACFに送る。
次に、TACFはACCH1の解放要求をBCFr1に対して行うと、BCFr1はACCH1の解放を行う。これにより、ACCHの切替が完了し、トラフィックチャネルTCH2と同一無線リソースを使用するACCH2を介して移動局装置(MS)と網側との間の制御情報の授受が行われる。
なお、ACCHの切替手順については、2.4.3.5.7章に詳述する。
移動通信においては、エアーインターフェースによって通信が行われるため、不正傍受やデータ改ざんを防ぐために信号を暗号化することが行われる。信号を秘匿(暗号化)することはサイファリング(Ciphering)と呼ばれ、また、秘匿解 除(復号化)することはデサイファリング(Deciphering)とよばれる。
例えば、基地局制御装置RNCは、移動機MSがダイバーシティハンドオーバ制御が可能である場合に、図751に示すように、基地局制御装置RNCが複数の無線基地局BS1〜BS3に対し同一の送信信号(未秘匿信号)を配信し、各無線基地局BS1〜BS3において秘匿処理を実行し、移動機MSに対して秘匿後の送信信号(秘匿信号)を送信するように構成した場合を想定する。
図64に示すように、移動機MS(Mobil Station)には、UIMF、MCFおよびTACAFが設けられている。UIMFは、移動ユーザに関する情報を保持し、ユーザ認証および秘匿演算を提供する。また、MCFは、非呼関連のサービスにおける網とのインタフェースである。TACAFは、発信,ページングの検出等の移動機端末へのアクセスを制御する。
より詳細には、まず、網側のLRCFから、サイファリングの開始を指示するStart Ciphering req.indが、TACF/SACFを介して移動端末側のTACAF/MCFに通知される。
そして、移動端末側で、秘匿が施された信号を受信すると、受信信号の秘匿解除制御がTACAF/MCFで行われる。なお、秘匿キーは、この処理に先立って、UIMFから取得している。
これにより、網側からの送信される送信信号(下り信号)については、秘匿が確保される。
これにより、網側は、これ以降、受信する信号にはサイファリングが施されていることを検知することができる。このため、移動端末側のTACAF/MCFは、Start Ciphering req.confを送信すると、これ以降送信する信号は、所定の秘匿処理を特定するための秘匿実施種別および秘匿キーを用いて秘匿を施す。そして、網側で、秘匿が施された信号を受信すると、受信信号の秘匿解除がTACF/SACFで制御される。これにより、移動端末側から送信される送信信号(上り信号)については、秘匿が確保される。
そこで、以下の説明においては、秘匿処理をどの情報に施すのが有効であるかについて検討する。なお、この処理は、秘匿開始タイミングの制御とは独立して処理可能である。
本システムの概略構成図を図753に示す。
図753に示すように、本システムは、移動機MSと、移動機MSと無線回線を介して接続された複数の無線基地局BSと、複数の無線基地局BSを制御するための基地局制御装置RNCと、基地局制御装置RNCを固定網に接続するための交換局MSCと、を備えて構成されている。
(1)移動機MS及び基地局制御装置RNCはダイバーシティ合成/分配を行う機能を有している。
(2)無線回線側におけるOSI参照モデルの第1層は、移動機MSと各無線基地局BSとの間で終端している。
(3)無線回線側におけるOSI参照モデルの第2層は、移動機MSから基地局制御装置RNCの間で終端している。
(4)本システムにおけるOSI参照モデルの第3層は、移動機MSから基地局制御装置RNCの間若しくは、移動機MSから交換局MSCの間で終端している。
(1)第2層フレーム再送機能を有している。
(2)第3層フレームが複数の第2層フレームにまたがった場合に、元の順序となるように、第3層フレームを構成する機能を有している。
(3)同一の情報に対応する秘匿信号及び未秘匿信号を同時に受信した場合に、双方を解読可能な機能は有していない。
この結果、アプリケーションは、第2層秘匿実施/解除部に網側からの信号の秘匿解除を行う旨の設定を行う(ステップS9)。
(1)第2層の機能である第2層フレーム再送機能を利用することができない。
(2)第3層フレームが複数のフレームにまたがった場合に元の順序となるように、第3層フレームを構成する機能を利用することができない。
という不具合が生じることとなる。
このため、本システムでは、秘匿をかける情報を第3層以上とし、第2層には秘匿をかけないようにし、第2層で秘匿開始の相互通知を行うようにしている。
本システムでは、各移動局装置(MS)を識別するための個人識別子(IMUI)を予め割り当てて、各移動局装置(MS)と網側で保持する。この個人識別子(IMUI)を用いて通信を行うことも可能であるが、移動通信においては、エアーインターフェースによって通信が行われるため、個人識別子(IMUI)が傍受されるおそれがある。この場合、傍受した第3者によって、他人の個人識別子(IMUI)を用いた不正な通信が行われる可能性がある。
次に、本システムの概要について説明する。
(2.3.1):提供サービス
本システムは、音声やデータ等の様々な情報の通信を総合的に提供するものであり、1つの移動端末上で同時に複数のベアラサービスを提供する。例えば、64kbit/s非制限デイジタルベアラ×2等がある。また、これまでのPDC方式移動通信システムにかわり、有線区間をATM化し、無線区間をCDMA化している。これにより、高品質かつ高速度の伝送を行うことができる。
以下に示す図266にサービスの内容を示す。なお、本システムは、PSTN、N−ISDN、PLML、B−ISDN、およびIMT−2000との相互接続が可能である。
本システムでは、以下のベアラサービスを提供する
(1)回線交換モード
a)8kbit/s音声ベアラサービス
本ベアラサービスは、音声サービスのサポートを目的とする。Um点におけるディジタル信号は、標準G.729に適合しているものとする。ただし、ビット透過性は保証されない。また、本ベアラサービスは音声帯域データ通信のサポートは意図していない。8kbit/s音声ベアラサービスの内容を図267に示す。
本ベアラサービスは、Um点間で情報が変更されることのない64kbit/sに多重化されたサブレートの情報転送を提供する。64kbit/s非制限ベアラサービスの内容を図267に示す。
本ベアラサービスは、Um点間で情報が変更されることのない384kbit/sに多重化されたサブレートの情報転送を提供する。マルチプルレート非制限ベアラサービスの内容を図269に示す。
本システムにおいては上述した回線モードのベアラサービスの他、パケット回線モードにおいてもベアラサービスを提供できるようになっている。
本システムにおけるモビリティ・ポータビリティサービスとして、個人識別子(IMUI:International Mobile User Identity)を採用する。個人識別子(IMUI)は、各移動端末を識別するために予め割り当てられたものであり、移動局装置(MS)と交換機(MCC)が各々保持している。移動局装置(MS)が無線エリアを跨って移動 した際に、この個人識別子(IMUI)を用いて、位置登録やハンドオーバなどが行われる。これにより、任意の場所で通信を行うことが可能となる。
本システムは、誤り訂正符号や再送機能を有している。これにより、音声通話に関しては網内(エアー含む)の平均ビット誤り率10−3を保証し、一方、音声を除くデータ通信、制御情報等の情報については同様に平均ビット誤り率10−6を保証する。
(2.3.2.1):通信サービスに関するシステム能力
(2.3.2.1.1):発信
発信とは、ユーザからの発信要求に基づき、MSが網にアクセスし、相手ユーザとの通信に必要な網内、網−MS間でのアクセスリンク及び相手ユーザへのコネクションの設定等を行う一連の制御手順をいう。本手順は、SDCCH制御、ユーザID Retrieval、認証、秘匿開始、アクセスリンク設定等の手順と発信ユーザとの相互の情報転送、分析手順等により実現される。
a)MSの発信を一時的移動ユーザ識別子(TMUI)を用いて網に通知し、Terminal Associationの起動を行う。また、MSの能力をMSから網に通知し、網はそのM S能力を保持してその後の新たな呼の生起時に網においてMSに対する新たな呼の受け付け制御する。
b)発信要求MSを認識して、網内データベースより当該MSの情報を網内の分析、制御機能まで転送する能力。(発信MSのTMUIが網で認識出来ない場合は、MS固有の移動ユーザ識別子(IMUI)をMS に問い合わせ、MSを認識する。)
c)上記、当該MS情報に基づいてMSの正当性を確認するユーザ認証制御を行う。この点については、本章、ユーザ認証で詳述する。
d)MSと網との間の制御チャネル、情報チャネルの傍受、改ざんを防ぐための秘匿制御を行う。この点については、本章、秘匿で詳述する。
e)上記、一連手順の成功、失敗をMSに通知する。
また、本システムは、前述のTerminal Association制御機能のInstanceを発信呼制御機能に通知し両者を関連づける能力を備える。
また、本システムは、MSからのサービス要求時のMSの周りの無線状態をMSから網へ通知し、網で認識するを備える。
また、本システムは、MSからのサービス要求に基づき、ユーザのプロファイルを収集、分析し、サービス提供を判定する能力を備える。
また、本システムは、上記MSの要求サービスの分析に基づき、サービスを提供するための網内リソース(音声コーディック、データトランク、網内有線回線等)の捕捉及び起動、設定を行う能力を備える。
また、本システムは、端末上で呼が進行中にも、新たなユーザからの発信を提供する能力を備える。
着信とは、第3者のユーザから本システムユーザへのサービス要求に基づき、網がユーザMSを呼出し、その応答を受け付け、着信ユーザとの通信に必要な網内、網−MS間でのアクセスリンク及び相手ユーザへのコネクションの設定等を行う一連の制御手順をいう。本手順は、Paging、SDCCH制御、ユーザID Retrieval、認証、秘匿開始、網内ルーチング、アクセスリンク設定等の手順と着信ユーザとの相互の情報転送、分析手順等により実現される。
a)網がMSに対応したPagingエリアを認識し、Pagingを行うPaging−CHを特定する。この後、そのPaging−CH上でPagingを実行する網内ノード(BTS)へ信号を配信し、BTSにて必要なエリア(セクタ単位)でPagingを行う。
b)MSのPagingに対する応答を網に通知するためのSDCCHを確立させる。この点については、本章、SDCCH制御で詳述する。
c)網からの呼出に対して、MS が応答すると、着信MSと網とのTerminal Associationを起動する。また、応答信号と呼出信号の対応を、Paging IDを用いて取る。さらに、MSの能力をMSから網に通知し、網はそのMS能力を保持してその後の新たな呼の生起時に網においてMSに対する新たな呼の受け付け制御する。
また、本システムは、Paging応答時のMSの周りの無線状態をMSから網へ通知し、網で認識する能力を備える。
a)MSの正当性を確認するユーザ認証制御を行う。この点については、本章およびユーザ認証の章で詳述する。
b)MSと網との間の制御チャネル、情報チャネルの傍受、改ざんを防ぐための秘匿制御を行う。この点については、本章および秘匿の章で詳述する。
c)上記、一連手順の成功、失敗をMSに通知する。
また、本システムは、端末上で呼が進行中にも、新たなユーザからの発信を提供する能力を備える。
また、本システムは、通信中ユーザへの独立な呼の着信(追加呼)を提供する能力を備える。ただし、追加呼に関しては既に通信中のMSのユーザ認証がなされているため、ユーザ認証を実施しない。
呼解放とは、ユーザからの呼解放要求、通信中の相手ユーザからの呼解放要求または、無線回線の劣化検出を契機に、相手ユーザとの通信に使用している網内のリンク、網−MS間でのアクセスリンク及び相手ユーザとのコネクションの解放を行う一連の手順。本手順は、ユーザ切断(ユーザステータス更新)、アクセスリンク解放の手順のより実現される。
また、本システムは、通信相手ユーザからの呼解放要求を網からユーザへ通知する能力を備える。
また、本システムは、呼解放によるユーザステータス更新のためにユーザプロファイルを更新する能力を備える。
また、本システムは、同期はずれ検出によるアクセスリンク解放手順(アクセスリンク解放[3.2.2.3章]参照)を契機として呼を解放する能力を備える。
また、本システムは、MSからのアクセスリンク解放要求を契機に呼を解放する能力を備える。
また、本システムは、発呼途中放棄によるMSからの呼解放を可能とする能力を備える。
(2.3.2.2.1):SDCCH制御
SDCCH制御とは、MSが網にアクセスし、制御メッセージを送受するためのSDCCH(Stand−alone Dedicated Control Channel)、及び網内での制御メッセージ転 送のためのアクセス有線リンクを確立するための手順、また、本SDCCH及び網内アクセス有線リンクを不必要となった時点で解放する手順をいう。本手順はMS発信、MS着信、MS位置登録を含むMS−網間のインタラクションが必要なすべての手順にともなって実行される。
また、本システムは、網、及びMSが、SDCCHが不要になったことを認識し(位置登録等の非呼関連手順の終了、ACCHへの移行等)、各々ローカルに解放を実行する能力を備える。
アクセスリンク設定とは、MS発信/MS着信時に、ユーザ情報転送のための通信チャネル、制御信号転送のための制御チャネルを網−MS間で設定するための手順をいう。本手順には網内のアクセス有線リンク設定のための手順、及び網−MS間のアクセス無線リンク設定のための手順が含まれる。
また、本システムは、MSが、とまり木チャネル測定結果及び網からの報知情報に基づき、網に対してアクセス有線リンク、アクセス無線リンク設定候補セクタを指定する能力を備える。なお、呼受付制御については2.3.2.2.7章に詳述する。
、本アクセス有線リンク設定には、ユーザ情報転送のための通信チャネル、及び必要な場合には制御信号転送のための制御チャネルが含まれる。
(2.3.2.2.3):アクセスリンク解放
また、MSがアクセスリンクのすべてのハンドオーバブランチにおいて同期はずれを検出した場合に、本アクセスリンクの無線チャネル送信を停止し、網に同期はずれ検出をさせる能力を備える。なお、MSは本イベントを網に通知するようにしてもよい。
また、本システムは、ダイバーシチハンドオーバ中のアクセスリンク解放に伴って、そのアクセスリンクのすべてのハンドオーバブランチを解放する能力を備える。
ハンドオーバとは、MSの移動、通信品質劣化、トラヒック分散、その他の理由により、通信を継続させながらMSの網へのアクセスポイントを変更する手順をいう。本手順にはアクセス無線リンクの切替、及び場合によってはアクセス有線リンクの切替手順が含まれる。
まず、本システムは、次のハンドオーバをサポートする能力を備える。
a)セル内セクタ間ブランチ追加ハンドオーバにあっては、使用中のハンドオ ーバブランチと同一セル異セクタ内にハンドオーバブランチを追加するハンドオーバが行われる。本ハンドオーバに伴ってアクセス有線リンクの追加は行われない。
また、本システムは、ブランチ追加ハンドオーバの場合、網が追加ブランチについて、既存ブランチと同一の無線周波数を持つ無線周波数チャネル上にアクセス無線リンクのための無線リソースを割り当てる能力を備える。また、1コネクションのすべてのブランチについて同一の上りコードリソースを割り当てる能力を備える。無線リソース選択については2.3.2.2.5章に詳述する。
また、本システムは、ブランチ追加ハンドオーバにおいて、MSが、報知情報(20msec定期報告情報)に基づいて、自身と各ブランチ追加候補セクタとの上りロングコード位相差、及び自身の用いているフレームオフセット群、スロットオフセット群を網に通知する能力を備える。
また、本システムは、アクセスリンク設定と同時にブランチ追加ハンドオーバ、その他のコネクションのブランチ切替ハンドオーバ、ACCH切替、その他のコネクションのコード種別切替が実行され得る。
また、本システムでは、アクセスリンク解放と同時にACCH切替が実行され得る
。なお、SDCCHのハンドオーバは行わない。
無線リソース選択とは、SDCCH設定、アクセスリンク設定、ハンドオーバの各手順のために、MSより送られた情報に基づき適当な無線リソース(無線周波数チャネル、ショートコード、オフセット値等)を選択することをいう。
また、本システムは、網が、個々のMS固有の上りロングコードを網内データベースより得る能力を備える。
、品質に基づき、要求された無線リソース選択の実行/拒否を決定する能力を備える。
また、本システムは、網が、セクタ毎の下りショートコードの使用状況を管理し、要求に応じて個々のコネクションのための下りショートコードを選択する能力を備える。
また、本システムは、網が、SDCCH設定手順、アクセスリンク設定手順のための無線リソース選択において無線フレームオフセット群、スロットオフセット群を選択する能力を備える。
送信電力制御とは、RACH・FACH上の信号送信、SDCCH設定、アクセスリンク設定、ハンドオーバの各手順における無線アクセスリンクの初期送信電力決定、また、ダイバーシチハンドオーバ中の各ハンドオーバブランチの下り送信電力制御を行うことをいう。なお、本手順にはレイヤ1によって実行される送信電力制御は含まない。
移動局から基地局へ上り無線チャネルを介して送信を行うときの送信電力は、上り無線チャネルの容量を節約し、かつ、他の無線アクセスリンクへの悪影響を防止するためにも、可能な限り最小に抑えるべきである。そして、上り送信電力を最小化するためには、例えば待ち受けるべき無線ゾーンまたは通信中にハンドオーバすべき無線ゾーンを選択する場合に最小の送信電力で交信を行うことが可能な無線ゾーンを選択するべきであり、その選択をするための何らかの手段が必要である。
まず、本システムは、網が、とまり木CHにおける定期報告情報(20msec毎に送信する報知情報)を使用して、基地局内の伝送損失(ケーブルロス等)を考慮して補正した補正後とまり木CH送信電力値を報知する能力を備える。
また、本システムは、MSが、補正後とまり木CH送信電力値、上り干渉量、MSで測定したとまり木CH受信電力値、運用データとして保持する基地局所要受信SIRを基に、初期送信電力値を設定する能力を備える。
まず、図792に示すように、基地局AおよびBが存在し、それぞれのとまり木チャネルを介して報知情報を送信しており、各々のとまり木チャネル送信電力値(上記補正後のもの)がPaおよびPbであったとする。また、移動局が双方の基地局からとまり木チャネルを介して報知情報を受信したときの受信レベルをRaおよびRbとする。
そして、移動局では、例えば待ち受けるべき無線ゾーンの選択時あるいはハンドオーバ先の無線ゾーンの選択時に、上記のようにして各基地局毎に求めた伝搬損失と、各基地局の上り干渉量と、基地局所要受信SIRとから、各基地局毎に所要上り送信電力を演算し、所要上り送信電力が最小となる基地局(無線ゾーン)を選択し、その基地局に合わせて上り送信電力を最適化(最小化)することができる。
このように、本システムによれば、とまり木チャネル送信電力値が各基地局間で異なる場合でも、移動局における上り送信出力を最適化することが可能になる。
1)FACH、下りSDCCH
MSは、RACHで移動局とまり木CH受信SIR値を網(BTS)に通知する。また、網(BTS)は、移動局とまり木CH受信SIR値、及び、網(BTS)内運用情報のとまり木CH送信電力値、MSにおけるFACH(SDCCH)所要受信SIR値、レート補正値から下り 初期送信電力値を設定する。
網(BTS)は、とまり木CHにおける報知情報(BCCH1)を使用して、とまり木CH送信電力値(補正無し)を報知する。MSが、SDCCHで移動局とまり木CH受信SIR値を網(BSC機能)に通知する。MSが、SDCCHでとまり木CH送信電力値(補正無し)を網(BSC機能)に通知する。
網(BSC機能)は、基地局に下り初期送信電力を通知する能力を備える。
MSは、通信中のゾーンにおけるとまり木CH送信電力値(補正なし)及びとまり木CH受信SIR値を定期的に網(BSC)に通知する。
また、本システムは、MSが、通信中におけるMS受信品質が基準品質と同一になるように、MSにおける所要受信SIRを増減させる能力を備える。
網は、上記値をもとに基地局の送信電力制御値を算出し、設定する能力を備える。
呼受付制御とは、基地局において測定及び判定可能である上り干渉量、下り送信電力、使用中設備リソースと、各々の許容限界との比較より、空塞情報を生成し、その情報を基に、発着信時、ベアラ変更時、ハンドオーバ実施時の呼受け付けを制限する制御をいう。本制御手順は、MS及び網で実施し、MSにおける制御の実施については、オプションとする。MSで実施することにより、無駄な発信要求、着信時のTCH設定、ベアラ変更要求、ハンドオーバ要求を抑制することが可能となり、網における制御負荷の軽減に寄与する。呼受け付け制御の更新頻度や、トラヒック集中により網において判断しなければならない状況が存在することから、網における本制御は、必須である。
MSでの実施に関して、本システムは以下の能力を備える。
まず、本システムは、網が報知情報(BCCH2)において、呼受付情報を報知する能力を備える。
また、本システムは、MSが、第1呼発信時のランダムアクセス開始時、第2呼発信時のSETUP送信時、着信時のSETUP受信時(TCHは未設定)、ハンドオーバトリガ送出時、ベアラ変更時のSETUP送信時の直前に、TCHの設定候補である基地局における報知情報(BCCH2)を参照する能力を備える。
また、本システムは、MSが、呼受付情報と比較して割り当ての可否を判定する能力を備える。
MSでの実施に関して、本システムは、網が、TCHの起動要求に対して、呼受付情報と比較して割り当ての可否を判定する能力を備える。
待ち受け制御とは、MSが、電源投入時、または、圏外から圏内に移動した場合、発着信が可能である状態に遷移するように制御するという。また、MSの移動により、待ち受けゾーンを変更する手順を待ち受けゾーン移行制御と称する。
待ち受け制御を実行するため、本システムは以下の能力を有する。まず、本システムは、網が、とまり木CHにおける定期報告情報(20msec毎)を使用して、基地局内の伝送損失(ケーブルロス等)を考慮して補正した補正後とまり木CH送信電力値を報知する能力を有する。
また、本システムは、網が、とまり木CHにおける報知情報(BCCH1)を使用して、待ち受け許可レベル、待ち受け劣化レベル、網番号、規制情報等を報知する能力を備える。
また、本システムは、MSが、参照した報知情報(BCCH1)より、待ち受け許可判定を行う能力を備える。
また、本システムは、MSが、参照した報知情報(BCCH1)より、待ち受けるべきPCHを決定する能力をを備える。
また、本システムは、MSが、参照した報知情報(BCCH1)より、使用すべきRACHを決定する能力を備える。
また、本システムは、MSが、参照した報知情報(BCCH1)より、RACH、SDCCHで使用すべき上りロングコードを決定する能力を備える。
また、待ち受けゾーン移行制御を実行するため、本システムは、網が、とまり木CHにおける報知情報(BCCH1)を使用して、周辺ゾーンの下りロングコードを報知する能力を備える。また、本システムは、MSが、参照した報知情報(BCCH1)より、周辺ゾーンの下りロングコードを検索し、ゾーン移行する能力を備える。
モビリティサービスに関するシステム能力について説明する。
(2.3.2.3.1):端末位置登録・更新
移動端末の移動性を保証するために端末位置を網が管理する。このため、端末位置登録は、ユーザが網内で最初に認識された時(最初に電源を投入した時、もしくは他網ユーザが当該網にローミングをしてきた時)に行われる。一方、端末位置更新は、同一網内でロケーションエリアが変わった時に自動的に実施される。これにより、網内の端末位置情報を書き換える。
まず、本システムは。MSが位置情報を認識できるように、網が位置情報をMSへ報知する能力を備える。
また、本システムは、MSが網内を移動した場合に、網内で管理している位置エリアから移動したことを認識し、MSで管理している位置情報の更新を要求する能力を備える。
また、本システムは、網とMSと位置登録手順用の制御信号の送受信を行うために、SDCCHを確立する能力を備える(SDCCH制御参照)。
また、本システムは、網がMSに新たなTMUIを割り当てる能力を備える。
また、本システムは、TMUIを使用した認証が失敗したら、IMUIを用いた認証をMSに対して起動する能力を備える。
また、本システムは、位置登録手順が完了したことを網からMSに通知する能力を備える。
また、本システムは、MSが位置登録・更新結果通知を受信出来ない場合に、MSが再度位置登録/更新手順を起動させる能力を備える。
次に、セキュリティサービスに関するシステム能力について説明する。
(2.3.2.4.1):ユーザ認証
ユーザ認証とは、網へサービス要求をしてくる各々の移動機ユーザが正当であるかを確認することをう。これにより不正移動機による不当な網へのアクセスを防止できる。本手順は、MS発信(第一呼)、着信、位置登録の際に実行される。
また、本システムは、網が生成した認証演算結果とMSからの認証演算結果を照合する能力を備える。
また、本システムは、TMUIを用いて行われた認証が失敗した場合に網がMSにIMUIを問い合わせ、IMUIに基づいた認証関連データを取得し、再度認証手順を実行させる能力を備える。
また、本システムは、IMUIによる網内データにより認証演算に失敗した場合に
、発信、着信、位置登録手順を中止させる能力を備える。
秘匿とは、ユーザから本システムユーザのサービス要求に基づき、網−MS間での制御信号(SDCCH、ACCH)とユーザ情報(TCH)において、不正傍受やデータ改ざんを防ぐために信号を暗号化を行う一連の制御をいう。本制御手順は発信、着信及び位置登録手順において実施される。
また、本システムは、サイファリング(Ciphering)及びデサイファリング(Deciphering)の開始タイミングを網とMSとの間で指示する能力を備える。
TMUIは、(1)エアーインタフェース上の秘密性を確保する(IMUIの隠蔽)目的、(2)エアーインタフェース上での端末識別子の情報量を削減する目的で、エアーインタフェース上で一時的な端末識別子(=ユーザ識別子)として用いられる。
また、本システムは、TMUIを網からMSへ通知する場合に、その内容を不正に傍受されないよう、エアーインタフェース上で秘匿実施後に、TMUIの通知を起動する能力を備える。
また、本システムは、TMUIの二重割り当て等が行われないようにTMUIの使用状態等を管理する能力を備える。
次に、システム管理に関するシステム能力について説明する。
(2.3.2.5.1):システム同期条件
システム同期条件とは、網、及び移動機でダイバーシティハンドオーバを大幅なバッファリング遅延なく行うために必要なシステム内の同期条件をいう。具体的には、例えば、640ms周期である。
次に、制御方式を説明説明する。
(2.4.1):機能網アーキテクチャ
図3に本システムの機能網アーキテクチャを示す。それぞれの機能は、ITU−T勧告に準拠する。
図において、CCAFは、移動機端末上に有り、ユーザにサービスアクセスを提供する、ユーザと網側の呼制御機能(CCF)とのインタフェースである。また、TACAFは、移動機端末上に構成されており、ページングの検出等の移動機端末へのアクセスを制御する。
FE01とFE06の間(CCAF−CCF)はRelationship raと、FE02とFE05の間(TACAF−TACF)はRelationship rbと、E07とFE09の間(LRCF−SSF)はRelationship rcと、FE07 とFE08の間(LRCF−LRDF)はRelationship rdと、FE09とFE10の間(SSF−SRF)はRelationship reと、FE07とFE10の間(LRCF−SRF)はRelationship rfと、FE05とFE07の間(TACF−LRCF)はRelationship rgと、FE05とFE12の間(TACF−SACF)はRelationship rhと、FE05とFE06の間(TACF−CCF)はRelationship riと、FE05とFE04の間(TACF−BCF)はRelationship rjと、FE05とFE04aの間はrjaと、FE05とFE04bの間はrjb と、FE07とFE12の間(LRCF−SACF)はRelationship rkと、FE11とFE12の間(MCF−SACF)はRelationship rlと、FE01とFE02の間(CCAF−TACAF)はRelationship rmと、FE02とFE03の間(TACAF−BCAF)はRelationship rnと、FE13とFE14の間(MRRC−MRTR)はRelationship roと、FE13とFE15の間(MRRC−RRC)はRelationship rpと、FE15とFE16の間(RRC−RFTR)はRelationship rqと、FE03とFE04の間(BCAF−BCF)はRelationship rrと、FE04とFE06の間(BCF−CCF)はRelationship rsと、FE05とFE15の間(TACF−RRC)はRelationship rtと、FE02とFE13の間(TACAF−MRRC)はRelationship ru と、FE02とFE17の間(TACAF−TIMF)はRelationship rvと、FE11とFE17の間(MCF−TIMF)はRelationship rwと、FE01とFE18の間(CCAF −UIMF)はRelationship rxと、FE11とFE18の間(MCF−UIMF)はRelationship ryと、FE04aとFE04bの間(BCFr−BCF)はRelationship r44と、FE06とFE06の間(CCF −CCF)はRelationship r66と、FE07 とFE07の間(LRCF−LRCF)はRelationship r77と、FE05とFE05の間(TACF−TACF)はRelationship r55と、FE08とFE08の間(LRDF−LRDF)はRelationship r88と、各々呼 ばれる。図271は、各機能エンティティの関係をまとめたものである。
(2.4.2.1):発信(第1呼、追加呼)
a)機能モデル(Functional model)
a−1)第1呼(Inital outgoing call)
図5に発信第1呼の機能モデルを示す。なお、無線リソースはセットアップ要求呼を受けた同一のTCAFの制御下にあるBCFrにより選択される。無線リソースの選択により、シナリオ複合FEs網が形成される。
a−2)追加呼(Outgoing call additional)
図6に発信追加呼の機能モデルを示す。なお、無線リソースはセットアップ要求呼を受けた同一のTCAFの制御下にあるBCFrにより選択される。無線リソースの選択により、シナリオ複合FEs網が形成される。
b−1)第1呼(Initial outgoing call)
図7、図8に第1呼の情報ダイアグラムを示す。
b−2)追加呼
図9に追加呼の情報ダイアグラムを示す。
(Definitions of Information Flows,Information Elements,and Functional Entity Actions)
以下、情報フロー等について述べるとともに、対応する情報要素等を表にまとめて示す。ただし、対応する要素がない場合には表を省略する場合がある。
CCAFは移動機による網への端末アクセスのセットアップ要求呼およびCCAFとTACAFとの間の接続のセットアップ要求呼を発信する場合、TA SETUP req.ind.(TAセットアップreq.ind.)を用いる(図272参照)。
TA SETUP req.ind.(TAセットアップreq.ind.)は、例えばTACAFおよびTACF間の接続喚起のような、端末アクセスの確立要求のため、TACAFから送信される(図273参照)。
なお、TMUIはIMUIの信頼確立のために利用されるもので、データの短縮のために、ユーザIDにはTMUIの割当てソースのIDは含まれない。
Reverse Long Code Retrieval req.ind.(上りロングコード検索req.ind.)は上りロングコードの検索のため用いられる(図275参照)。
Reverse Long Code Retrieval req.ind.(上りロングコード検索req.ind.)は上りロングコードの検索のため用いられる(図276参照)。
Reverse Long Code Retrieval resp.conf.(上りロングコード検索resp.conf.)は上りロングコードの検索のため用いられる(図277参照)。
TERMINAL STATUS UPDATE resp.conf.(端末状態更新 resp.conf)は前記要求に対して応答する(図279参照)。
ADD ROUTING INFO resp.conf.(ルーチング情報追加resp.conf.)は前記要求 に対して応答する(図281参照)。
Reverse Long Code Retrieval resp.conf.(上りロングコード検索resp.conf.
)は上りロングコード検索のため用いられる(図283参照)。
TA SETUP resp.conf.(TAセットアップresp.conf.)は端末アクセス、CCAFおよびTACAF間の接続完了のセットアップの確認のため用られる(図285参照)。
TACF Instance ID Indication req.ind.(TACFインスタンスID指示req.ind.)は上りロングコードの検索のため用いられる(図287参照)。
SSFは発信ユーザの認証要求ののためCALL SETUP PERMISSION req.ind.(呼セットアップ許可req. ind.)を発動する(図291参照)。
USER PROFILE RETRIEVAL resp.conf.(ユーザプロファイル検索resp.conf.)は前記要求に対して応答する(図293参照)。
SETUP req.ind.(セットアップreq.ind.)は接続の確立要求のため用いられる
(図295参照)。
PROCEEDING req.ind.(手続きreq.ind.)は所望に応じて受信側の接続セット アップの有効性、認証、ルーチングおよび呼進行の継続を報告する。本情報フローは確認を要求しない(図296参照)。
MRRC−RRC間(=rp)において、網はMeasurement Condition Notification req.ind.(状態検出req.ind.)により、移動機におけるセル選択情報の検出および報告の状態を指示する。移動機が空きモードの場合、網 は定期的に前記Measurement Condition Notification req.ind.(状態検出req.ind.)を指示する。移動機が通信中の場合、網 は状態の変更時に前記Measurement Condition Notification req.ind.(状態検出req.ind.)を指示する。本情報フローは確認を要求しない(図298参照)。
CCAF’−CCF’間(=ra)におけるREPORT req.ind.(報告req.ind.)は網に係る報告状態および/またはその他の種類の情報(例えば注意、保留、保持、解除等)の報告のため用いられる。本情報フローは確認を要求しない(図300参照)。
SETUP resp.conf.(セットアップ resp.conf.)は接続確立の確認のため用い られる(図302参照)。
a)機能モデル(Functional model)
a−1)第一呼(Initial incoming call)
図10に着信第一呼の機能モデルを示す。
a−2)着信追加呼(Incoming additional call)
図11に着信追加呼の機能モデルを示す。
b−1)第1呼(Initial incoming call)
図12は着信第一呼の情報フローダイアグラムである。
図13は着信第一呼の情報フローダイアグラムである。
図14は着信第一呼の情報フローダイアグラムである。
b−2)着信追加呼(Incoming additional call)
図15は着信追加呼の情報フローダイアグラムである。
図16は着信追加呼の情報フローダイアグラムである。
b−3)着信追加呼(Incoming additional call)
以下、情報フロー等について述べるとともに、対応する情報要素等を表にまとめて示す。ただし、対応する要素がない場合には表を省略する場合がある。SETUP req.ind.(セットアップ req.ind)は接続の確立要求のため用いられる(図303参照)。
受信側ユーザ番号、あるいはローミング番号は、受信側ユーザの識別子として用いられる。この場合ローミング番号が用いられる。
TERMINAL ID RETRIEVAL req.ind.(端末ID 検索 req.ind.)はユーザプロファイルの検索要求のため用いられる(図305参照)。
ローミング番号は本情報フローにあって受信側ユーザIDの代わりとして検索対象のユーザ特定のために用いられる。
その選択過程にあって検索対象のデータが特定される。本情報フローにおける本情報要素はユーザIDを特定する。
TERMINAL ID RETRIEVAL resp.conf.(端末 ID 検索 resp.conf.)は端末 ID 検索req.ind.に対して応答する(図306参照)。
その選択過程にあって検索対象のデータが特定される。本情報フローにおける本情報要素はユーザの通信状態を特定する。
TERMINAL STATUS QUERY resp.conf.(端末状態探索resp.conf.)は端末状態探索req.ind.からの要求に対して応答する(図308参照)。
TERMINAL STATUS UPDATE req.ind.(端末状態更新req.ind.)は端末状態の更 新のため用いられる(図309参照)。
TERMINAL STATUS UPDATE resp.conf.(端末状態更新resp.conf.)は端末状態更 新req.ind.からの要求に対して応答する(図310参照)。
その選択過程にあって検索対象のデータが特定される。本情報フローにおける本情報要素はページング領域を特定する。
PAGING AREA QUERY resp.conf.(ページング領域探索resp.conf.)はページン グ領域探索req.ind.からの要求に対して応答する(図312参照)。
LRCFはページング関係IDを作成する。そのページング関係IDは要求および応答を相関させるため、用いられる。
PAGING req.ind.(ページングreq.ind.)は移動機を網中に位置づけて通信の経 路を決定するため、移動機を符号化するために用いられる。本要素は確認を要求する情報フローである(図314参照)。
TACFはページングIDを作成する。ページングは応答の識別のため用いられる。
PAGE resp.conf.(ページresp.conf.)は応答としてページング結果をLRCFに通 知する。LRCFは本情報フローを受信すると同時にユーザへの対応としてユーザ認証のため、SLPを強制的に初期化する(図316参照)。
なお、本情報フローは端末からの応答がない場合にも用いられ、選択する情報要素が不明となった場合、網からのページング要求に対して端末からの応答がなかったものと見なすことになる。
Reverse Long Code Retrieval req.ind.(上りロングコード検索req.ind.)は上りロングコードの検索に用いられる(図318参照)。
Reverse Long Code Retrieval resp.conf.(上りロングコード検索resp.conf.
)は上りロングコードの検索に用いられる(図319参照)。
Cell Condition Measurement resp.conf.(セル状態検出resp.conf.)はCell Condition Measurement req.ind.(セル状態検出req.ind.)からの要求に応じてセル選択情報の検出結果を提供する(図321参照)。
ADD ROUTING INFO. resp.conf.(ルーチング情報追加resp.conf.)は上記 ADD ROUTING INFO. req.ind.(ルーチング情報追加req.ind.)に対する応答である(図324参照)。
Reverse Long Code Retrieval resp.conf.(上りロングコード検索resp.conf.)は上りロングコード検索のため、用いられる(図326参照)。
PAGE AUTHORIZED req.ind.(ページ認証req.ind.)はTACAFへの前記端末の認 証結果の通知のため用いられる。
ROUTING INFO QUERY resp.conf.(ルーチング情報探索resp.conf.)は前記要 求に対して応答する(図327参照)。
Routing address and TACF instance ID(アドレスルーチングおよびTACFインスタンスID)は、この場合、ルーチング情報の特定のため用いられる。アドレスルーチングは基地網におけるルーチングのため用いられる。
TERMINATION ATTEMPT req.ind.(成端試行req.ind.)は、通信継続を要する場合に、ユーザのプロファイルの要求のため用いられる(図329参照)。
USER PROFILE RETRIEVAL req.ind.(ユーザプロファイル検索req.ind.)はLRDFからの、着信側ユーザのプロファイル検索のため用いられる(図330参照)。
USER PROFILE RETRIEVAL resp.conf.(ユーザプロファイル検索resp.conf.)はLRCFからの要求に対して応答する(図331参照)。
TERMINATION ATTEMPT resp.conf.(成端試行resp.conf.)はSSFからの要求に 対して応答する(図332参照)。
SETUP req.ind.(セットアップresp.conf.)は接続の確立のため用いられる(図333参照)。
Proceeding req.ind.(継続req.ind.)は所望に応じて着信側の接続セットアップの有効性、認証を報告するとともに、さらにルーチングおよび呼の状況が継続中であることを報告する。本情報フローは確認を要求しない(図334参照)。
、保留、保持、解除等がある。本情報フローは確認を要求しない情報フローである(図336参照)。
SETUP resp.conf.(セットアップ req.ind)は接続の確立の確認のため用いられる(図337参照)。
CONNECTED req.ind.(接続 req.ind)は送信済みのSETUP resp.conf.(セッ トアップ resp.conf.)の着信および受納の保証のため用いられる。本情報フローは確認を要求しない情報フローである(図338参照)。
(2.4.2.3.1):ユーザ側切断
(a)基本モデル
図17にユーザ側切断の基本モデルを示す。
(b)情報フロー
図18にユーザ側切断の情報フローを示す。
RELEASE req.ind.(解放req.ind.)はcall ID(呼ID)およびチャネルのよう な呼接続に組み込まれたリソースの解放のため用いられる。本情報フローは確認を要求する情報フローである(図339参照)。
RELEASE resp.conf.(解放resp.conf.)はそれまで接続に組み込まれた全リソースの解放の指示のため用いられる(図340参照)。
TACFはSCFに呼解放の試行の検出を通知するためTA RELEASE req.ind.(解放req.ind.)を発動させる。本情報フローは最終呼が解放されるとともに、端末のrelationship(リレーションシップ)統合を解除する場合に発動する(図341参照)。
TERMINAL STATUS MAKE IDLE req.ind.(端末空き状態化req.ind.)は端末の呼状態を空き状態とするため用いられる(図342参照)。
TERMINAL STATUS MAKE IDLE resp.conf.(端末空き状態化resq.ind.)は前記TERMINAL STATUS MAKE IDLE req.ind.(端末空き状態化req.ind.)の要求に対し て応答する(図343参照)。
TA RELEASE resp.conf.(TA解放resp.conf.)は前記TA RELEASE req.ind.(TA解放req.ind.)の確認のため用いられる(図344参照)。
(a)基本モデル
図19に網側切断の基本モデルを示す図を示す。
(b)情報フロー
図20に網側切断の情報フローダイアグラムを示す。
以下、情報フロー等について述べるとともに、対応する情報要素等を表にまとめて示す。ただし、対応する要素がない場合には表を省略する場合がある。
RELEASE req.ind.(解放req.ind.)は呼番号、チャネルのような呼接続に組 み込まれたリソースを解放するため用いられる。本フローは確認を要求するフローである(図345参照)。
RELEASE resp.conf.(解放resp.conf.)はそれまで接続に組み込まれた全リソースの解放の指示のため用いられる(図346参照)。
TACFはLRCFに呼解放の試行の検出を通知するためTA RELEASE req.ind.(解放req.ind.)を発動させる。本情報フローは最終呼が解放されるとともに、端末のrelationship(リレーションシップ)統合を解除する場合に発動する(図347参照)。
TERMINAL STATUS MAKE IDLE resp.conf.(端末空き状態化resq.ind.)は前記TERMINAL STATUS MAKE IDLE req.ind.(端末空き状態化req.ind.)の要求に対し て応答する(図349参照)。
TA RELEASE resp.conf.(TA解放resp.conf.)は前記TA RELEASE req.ind.(TA解放req.ind.)の確認のため用いられる(図350参照)。
(2.4.2.3.3.1):移動機検出によるラジオリンク失敗(Radio
link failure − mobile detected)
(2.4.2.3.3.1.1):モジュール使用による通常手続き(Common Procedure Modules Used)
モジュール使用による通常手続きには、ユーザ側切断(User disconnect)がある。
a)機能モデル(Functional model)
網により検出されたスケルチ解放の機能モデルを図21に示す。
図21に示すモデルは非常解放、すなわち移動機により検出されるラジオリンク失敗の機能モデルである。
b)情報フロー(Information flows)
非常解放、すなわち移動機により検出されるラジオリンクの失敗の場合のCC−Plane情報フローのダイアグラムを図22に示す。
c)情報フローおよび情報要素の定義(Definitions of Information Flows,Information Elements)
RADIO LINK FAILURE req.ind.(ラジオリンク失敗req.ind.)はBCAFまたはBCFrにより検出されたラジオリンク失敗の通知のため用いられる。この手続きにあっては、BCAFが本情報フローを発動する(図351参照)。
RELEASE NOTIFICATION req.ind.(解放通知req.ind.)は網および端末間の接 続解放の報告のために用いられる。本情報フローは確認を要求しない情報フローである(図352参照)。
RADIO LINK FAILURE req.ind.(ラジオリンク失敗req.ind.)はラジオリンク 失敗の検出の通知のため用いられる(図354参照)。
RADIO LINK FAILURE resp.conf.(ラジオリンク失敗resp.conf.)はRADIO LINK FAILURE req.ind.(ラジオリンク失敗req.ind.)に対する確認情報フローである(図355参照)。
TACFはTA RELEASE req.ind.(無線ベアラ解放req.ind.)により端末アクセスの解放を要求する。本情報フローは最終呼の解放の場合にのみ発動する。
TACFはBEARER RELEASE req.ind.(ベアラ解放req.ind.)を発動し、BCFにベアラを解放させる(図357参照)。
BEARER RELEASE resp.conf.(ベアラ解放resp.conf.)は前記要求に対する確 認情報フローである(図358参照)。
TACFはBCFに対してBEARER RELEASE req.ind.(ベアラ解放req.ind.)の発動により、無線ベアラを解放させる(図360参照)。
BEARER RELEASE resp.conf.(ベアラ解放resp.conf.)は前記要求に対する確 認情報フローである(図361参照)。
TACFはBEARER&RADIO BEARER RELEASE req.ind.(ベアラおよび無線ベアラ解放req.ind.)の発動により、ベアラおよび無線ベアラを解放する(図362参照)。
BEARER&RADIO BEARER RELEASE resp.conf.(ベアラおよび無線ベアラ解放resp.conf.)はBEARER&RADIO BEARER RELEASE req.ind.(ベアラおよび無線ベアラ解放req.ind.)の要求によるベアラおよび無線ベアラの解放の確認のため用られる(図363参照)。
BEARER RELEASE resp.conf.(ベアラ解放resp.conf.)は前要求による無線ベアラ解放の完了をTACFに通知する確認情報フローである(図364参照)。
TACFは、LRCFに呼解放の試行の検出を通知するためTA RELEASE req.ind.(TA 解放req.ind.)を発動する(図365参照)。
TERMINAL STATUS MAKE IDLE resp.conf.(端末状態空き化resq.ind.)は前記TERMINAL STATUS MAKE IDLE req.ind.(端末空き状態化req.ind.)の要求に対し て応答する(図367参照)。
(2.4.2.3.3.2):網検出によるラジオリンク失敗(Radio link failure − network detected)
(2.4.2.3.3.2.1):モジュール使用による通常手続き(Common Procedure Modules Used)
モジュール使用による通常手続きには、ユーザ側切断(User disconnect)がある。
(2.4.2.3.3.2.2):情報フローダイアグラム(Information Flow Diagram)
図23に端末により検出されるスケルチ解放の機能モデルを示す。
図23は非常解放、すなわち網によるラジオリンク失敗の検出の場合の機能 モデルである。
図24に移動機呼解放、すなわち網により検出されるラジオリンク失敗のため非常解放の場合におけるCC−Plane情報フローのダイアグラムを示す。
(Definitions of Information Flows,Information Elements)
以下、図24における規定と同様に情報フローおよび情報要素を説明する。
RADIO LINK FAILURE req.ind.(ラジオリンク失敗req.ind.)はBCFrまたはBCFa.よるラジオリンク失敗の検出および報告の通知のため用いられる(図369参照)。
RADIO LINK FAILURE req.ind.(ラジオリンク失敗req.ind.)はジオリンク失 敗の検出の通知のため用いられる(図370参照)。
RADIO LINK FAILURE resp.conf.(ラジオリンク失敗resp.conf.)はRADIO LINK FAILURE req.ind.(ラジオリンク失敗req.ind.)に対する確認情報フローである(図371参照)。
RELEASE NOTIFICATION req.ind.(解放通知req.ind.)は網および端末間の接 続解放の指示のため用いられる。本フローは確認を要求しない情報フローである
(図373参照)。
RADIO BEARER RELEASE resp.conf.(無線ベアラ解放resp.conf.)は前記要求 に対する確認情報フローである(図374参照)。
TA RELEASE resp.conf.(TA解放resp.conf.)は前記要求に対する確認情報フ ローである。
TACFはBCFに対してBEARER RELEASE req.ind.(ベアラ解放req.ind.)の発動により、無線ベアラを解放させる(図375参照)。
BEARER RELEASE resp.conf.(ベアラ解放resp.conf.)は前記要求に対する確 認情報フローである(図376参照)。
アンカTACFはBEARER RELEASE req.ind.(ベアラ解放req.ind.)の送信により 稼働中のTACFに呼解放中にあるベアラの解放を要求する(図377参照)。
TACFはBCFに対してBEARER RELEASE req.ind.(ベアラ解放req.ind.)の発動により、無線ベアラを解放させる(図378参照)。
TACFはBEARER&RADIO BEARER RELEASE req.ind.(ベアラおよび無線ベアラ解放req.ind.)の発動により、ベアラおよび無線ベアラを解放する(図380参照)。
BEARER&RADIO BEARER RELEASE resp.conf.(ベアラおよび無線ベアラ解放resp.conf.)はBEARER&RADIO BEARER RELEASE req.ind.(ベアラおよび無線ベアラ解放req.ind.)の要求によるベアラおよび無線ベアラの解放の確認のため用いられる(図381参照)。
BEARER RELEASE resp.conf.(ベアラ解放resp.conf.)は前要求による無線ベアラ解放の完了をTACFに通知する確認情報フローである(図382参照)。
RADIO BEARER RELEASE resp.conf.(無線ベアラ解放resp.conf.)は前記RADIO BEARER RELEASE req.ind.(無線ベアラ解放req.ind.)の要求による無線ベアラ解放の確認のため用いられる(図384参照)。
TACFは、LRCFに対して呼解放の試行の検出を通知するためTA RELEASE req.ind.(TA解放req.ind.)を発動する(図385参照)。
TERMINAL STATUS MAKE IDLE resp.conf.(端末状態空き化req.ind.)は前記TERMINAL STATUS MAKE IDLE req.ind.(端末空き状態化req.ind.)の要求に対して応答する(図387参照)。
TA RELEASE resp.conf.(TA解放resp.conf.)は前記TA RELEASE req.ind.(TA解放req.ind.)に対する確認のため用いられる(図388参照)。
(2.4.2.3.4.1):情報フローダイアグラム(Information flow diagram)
a)機能モデル(Functional model)
図25にユーザ側切断の機能モデルを示す。
b)情報フロー(Information flows)
図26にユーザ側切断の情報フローダイアグラムを示す。
C)情報フローおよび情報要素の定義(Definitions of Information Flows,Information Elements)
CALL DISCONNECT req.ind.(呼切断req.ind.)は、LRCFへのユーザ側切断の検出通知のため用いられる(図389参照)。
USER PROFILE UPDATE req.ind.(ユーザプロファイル更新req.ind.)はユーザのプロファイルの更新要求のため用いられる。呼解放のため、本情報フローは呼解放の完了を指示するため用いられる(図390参照)。
USER PROFILE UPDATE resp.conf.(ユーザプロファイル更新resp.conf.)は前記USER PROFILE UPDATE resp.conf.(ユーザプロファイル更新resp.conf.)の要求に対して応答する(図391参照)。
CALL DISCONNECT resp.conf.(呼切断resp.conf.)は前記CALL DISCONNECT req.ind.(呼切断req.ind.)の要求に対して応答する(図392参照)。
(2.4.3.1):SDCCH Setup(SDCCHステップアップ)
以下、SDCCH ステップアップの手続きを説明する。
(2.4.3.1.1):モジュール使用による通常手続き(Common Procedure Modules Used)
図27はSDCCH Setup(SDCCHステップアップ)の機能モデルである。
b)情報フロー(Information flows)
図28はSDCCHセットアップの情報フローダイアグラムである。
以下、図28における規定と同様に情報フローおよび情報要素を説明し、対応する情報要素等を表にまとめて示す。ただし、対応する要素がない場合には表を省略する場合がある。
SCMAFは網に対して信号チャネルセットの割当て要求のためSIGNALING CHANNEL SETUP req.ind.(信号チャネルセットアップreq.ind.)を用いる(図394参照)。
SCMFは信号チャネルに対する無線リソースの割当てのためSIGNALING CHANNEL SETUP resp.conf.(信号チャネルセットアップresp.conf.)を用いる(図395参照)。
SIGNALING CHANNEL SETUP REQUESTED req.ind.(信号チャネルセットアップ被要求req.ind.)は移動機端末からの信号チャネル要求の受信(初期アクセスの検 出)の指示のため、および網における信号チャネルに一致するセットアップの要求のため用いられる(図396参照)。
SIGNALING CONNECTION SETUP resp.conf.(信号接続セットアップresp.conf.
)は信号チャネルの確立(ハードウェア上のチャネル、網上のチャネルを含む)の報告のため用いられる(図398参照)。
SCMAFは網に対する信号チャネルのセットアップの報告のためSIGNALING CHANNEL SETUP REQUEST resp.conf.(信号チャネルセットアップ要求resp.conf.)を用いる(図399参照)。
以下、無線リソース選択のためのベアラセットアップ手続き(Bearer Setup procedures)を説明する。
(2.4.3.2.1):モジュール使用による通常手続き(Common Procedure Modules Used)
a)機能モデル(Functional model)
無線リソースは移動機端末から受信したセットアップ要求呼とは異なるBS 下 で選択される。一方BSsは異なるTACFsにより制御される。CCFはTACFのみとリレ ーションシップをもち、TACFv.とはリレーションシップをもたない。TACFa はベアラ選択およびベアラセットアップの両方を制御する。BCFsには、例えばBCF1、BCF2、BCFrのような3種類がある。
図29に無線リソース選択のためのベアラセットアップの機能モデルを示す。
b)情報フロー(Information flows)
図30にベアラセットアップ(無線リソース選択)のためのCC−Plane情報フローダイアグラムを示す。
以下、図30における規定と同様に情報フローおよび情報要素を説明し、対応する情報要素等を表にまとめて示す。ただし、対応する要素がない場合には表を省略する場合がある。
なお、IEsはCCAFからのSETUP req.ind.(セットアップreq.ind.)におけるベアラ容量の部分である。
TACFはBCFに対してアクセスベアラの確立要求のためBEARER SETUP req.ind.(ベアラセットアップreq.ind.)を送信する(図402参照)。
BEARER SETUP req.ind.(ベアラセットアップreq.ind.)はTACFaからTACFvへのアクセスベアラの確立要求のため用いられる(図404参照)。
BCFはTACFに対してアクセスベアラの確立要求のためBEARER SETUP resp.conf.(ベアラセットアップresp.conf.)を送信する(図406参照)。
TACFはBCFrに無線ベアラの確立要求およびBCF相互間でのベアラ確立要求のた めBEARER&RADIO BEARER SETUP req.ind.(ベアラおよび無線ベアラセットアップreq.ind.)を送信する(図407参照)。
新たなアクセスベアラを制御するTACFは新たに承認される無線ベアラを要求するため信号接続を有するTACFにRADIO BEARER SETUP REQUEST req.ind.(無線ベ アラセットアップ要求req.ind.)を発動させる(図409参照)。
TACAFはBCAFに対して無線ベアラの確立要求のためRADIO BEARER SETUP req.ind.(無線ベアラセットアップreq.ind.)を送信する(図411参照)。
BEARER&RADIO BEARER SETUP resp.conf.(ベアラおよび無線ベアラセットアップresp.conf.)は無線ベアラの確立およびBCF相互間のベアラ確立の完了の確認のため、送信される(図413参照)。
BEARER SETUP resp.conf.(ベアラセットアップresp.conf.)はアクセスベアラの確立完了の確認のため用いられる(図415参照)。
(2.4.3.3.1):TACFアンカー接近のための無線ベアラ解放(Radio bearer release for TACF anchor apploach)
(2.4.3.3.1.1):情報フローダイアグラム(Information flow diagram)
a)機能モデル(Functional model)
図31に無線ベアラ解放の機能モデルを示す。
b)情報フロー(Information flows)
図32に無線ベアラ解放のための情報フローダイアグラムを示す。
以下、図32における規定と同様に情報フローおよび情報要素を説明し、対応する情報要素等を表にまとめて示す。ただし、対応する要素がない場合には表を省略する場合がある。
TACFaは無線ベアラの解放要求のためRADIO BEARER RELEASE req.ind.(無線ベアラ解放req.ind.)を用いる。網がRADIO BEARER RELEASE req.ind.(無線ベアラ解放req.ind.)を作成する(図417参照)。
RADIO BEARER RELEASE resp.conf.(無線ベアラ解放resp.conf.)は前記要求 に対する確認情報フローである(図418参照)。
)を発動する。本情報フローは最終呼の解放に対してのみ発動する。
TA RELEASE resp.conf.(TA解放resp.conf.)は前記要求に対する確認情報フローである。
TACFはBCFに対して無線ベアラ解放のためBEARER RELEASE req.ind.(ベアラ解放req.ind.)を発動する(図419参照)。
TACFaはTACFvに対する解放過程にある呼に係るベアラ解放の要求のためBEARER RELEASE req.ind.(ベアラ解放req.ind.)を送信する(図421参照)。
TACFはBCFに対して無線ベアラ解放のためBEARER RELEASE req.ind.(ベアラ解放req.ind.)を発動する(図422参照)。
BEARER RELEASE resp.conf.(ベアラ解放resp.conf.)は前記要求に対する確 認情報フローである(図423参照)。
TACFはベアラおよび無線ベアラ解放のためBEARER&RADIO BEARER RELEASE req.ind.(ベアラおよび無線ベアラ解放req.ind.)を発動する(図424参照)。
BEARER&RADIO BEARER RELEASE resp.conf.(ベアラおよび無線ベアラ解放resp.conf.)は前記BEARER&RADIO BEARER RELEASE req.ind.(ベアラおよび無線ベアラ解放req.ind.)の要求によるベアラおよび無線ベアラ解放の確認のため用いられる(図425参照)。
BEARER RELEASE resp.conf.(ベアラ解放resp.conf.)はTACFに対する、無線 ベアラ解放の前要求の完了の通知のための確認情報フローである(図426参照)。
BEARER RELEASE resp.conf.(ベアラ解放resp.conf.)はCCFに対する、無線ベアラ解放の前要求の完了の通知のための確認情報フローである(図427参照)。
BCAFはRADIO BEARER RELEASE req.ind.(無線ベアラ解放req.ind.)の要求による無線ベアラ解放の確認のためRADIO BEARER RELEASE resp.conf.(無線ベアラ解放resp.conf.)を用いる(図429参照)。
以下、SDCCHの解放手続き(SDCCH Release procedures)を説明する。
(2.4.3.4.1):モジュール使用による通常手続き(Common Procedure Modules Used)
(2.4.3.4.2):情報フローダイアグラム(Information Flow Diagram
)
a)機能モデル(Functional model)
図33にSDCCHセットアップ(SDCCH Setup)の機能モデルを示す。図33はSDCCH解放の機能モデルである。
b)情報フロー(Information flows)
図34にSDCCHは解放のための情報フローダイアグラムを示す。
(2.4.3.4.3):情報フローおよび情報要素の定義(Definitions of Information Flows and Information Elements)
MCFおよびTACFは信号チャネルの解放要求のためSIGNALING CHANNEL RELEASE REQUEST req.ind.(信号チャネル解放要求req.ind.)を用いる(図430参照)。
TACFおよびSACFは信号チャネル(網および無線リソースの両方を含む)の解放要求のためSIGNALING CONNECTION RELEASE req.ind.(信号接続解放req.ind.)を用いる(図431参照)。
SIGNALING CONNECTION RELEASE resp.conf.(信号接続解放resp.conf.)は信 号チャネルの解放報告のため用いられる(図432参照)。
(2.4.3.5.0):ハンドオーバの過程および関連手続きのモジュール(Handover process and relevant procedure modules)
過程1:ハンドオーバ開始原因(Process 1:Handover trigger)
ハンドオーバ開始原因の検出(Detection of handover triggering)を行う
。
過程2:ハンドオーバリソースの登録(Process 2:Handover resource reservation)
ハンドオーバに対する無線リソースの登録(Reservation of radio resources for handoverを行う。
過程3:ハンドオーバの実行(Process 3:Handover execution)
所要に応じ網側の準備(Preparing at network side,if any)を行う。
ハンドオーバ開始原因に示す移動機端末への要求(Request the mobile terminal as indicated by trigger)を行う。
過程4:ハンドオーバの完了(Process 4:Handover completion)
不要な無線ベアラおよびリソースの解放(Release of unneeded radio bearer and resources)行う。
図37にハンドオーバプロセス1におけるノンソフトハンドオーバの実行(non−soft handover excution)を示す情報フローダイアグラムを示す。また、図 38にハンドオーバプロセス1におけるハンドオーバのブランチ追加(handover branch addition)を示す情報フローダイアグラムを示す。また、図39にハンドオーバプロセス1におけるハンドオーバのブランチ削除(handover branch deletion)を示す情報フローダイアグラムを示す。
同一のBCFrの制御下にあるハンドオーバ:(Handover controlled by the same BCFr)
(2.4.3.5.1.1):通常手続きのモジュール(Common Procedure Modules)
(2.4.3.5.1.2):情報フローダイアグラム(Information Flow Diagrams)
a)機能モデル(Functional Model)
図40にセル内セクタ間ブランチ追加の機能モデルを示す。
b)情報フロー(Information Flow)
図41にセル内セクタ間ブランチ追加のCC−Plane情報フローダイアグラムを示す。
(2.4.3.5.1.3):情報フローおよび情報要素の定義(Difinitions of information flows and Information Elements)
TACFaはTACFvに対してアクセスベアラのセットアップのためBEARER SETUP req.ind.(ベアラセットアップreq.ind.)を送信する(図433参照)。
なお、本IEはBCFaおよびBCFv間のベアラを識別する。
端末およびTACFの制御下にあるBCFr間の無線ベアラのセットアップ要求のため RADIO BEARER SETUP REQUEST req.ind.(無線ベアラセットアップ要求req.ind.)を送信する(図436参照)。
なお、*1は端末側ハンドオーバブランチの数だけ繰り返され、*2はTACF側の呼の数だけ繰り返される。
TACAFはBCAFに対して無線ベアラのセットアップ要求のためRADIO BEARER
SETUP req.ind.(無線ベアラセットアップreq.ind.)を送信する(図438参照)。
(2.4.3.5.2.1):通常手続きのモジュール(Common Procedure Modules)
(2.4.3.5.2.2):情報フローダイアグラム(Information Flow Diagrams)
a)機能モデル(Functional Model)
図42にセル間ブランチ追加の機能モデルを示す。
b)情報フロー(Information Flow)
図43はセル間ブランチ追加のCC−Plane情報フローダイアグラムである。
(Difinitions of information flows and Information Elements)
TACFaはBCFaに対してハンドオーバ初期化の通知のためHANDOVER CONNECTION SETUP req.ind.(ハンドオーバ接続セットアップreq.ind.)を送信するとともに、アクセスベアラのセットアップを要求する(図440参照)。
なお、本IEはCCFおよびBCF間のベアラを識別する。
なお、本IEはBCFaおよびBCFv間のベアラを識別する。
TACFaはTACFvに対してアクセスベアラのセットアップのためBEARER SETUP req.ind.(ベアラセットアップreq.ind.)を送信する(図442参照)。
なお、本IEはBCFaおよびBCFv間のベアラを識別する。
なお、本IEはBCFおよびCCF間のベアラを識別する。
なお、本IEはBCFおよびBCFr間のベアラを識別する。
なお、*1は着局セルの数だけ繰り返され、*2はTACFに関する呼の数だけ繰り返される。
TACAFはBCAFに対してRADIO BEARER SETUP req.ind.(無線ベアラセットアップreq.ind.)を送信し、RADIO BEARER SETUP req.ind.(無線ベアラセットアップreq.ind.)は無線ベアラのセットアップを要求する(図449参照)。
TACFaはTACFvに対してアクセスベアラ確立の保証のためBEARER SETUP resp.conf.(ベアラセットアップresp.conf.)を送信する(図451参照)。
同一のBCFrの制御下にあるハンドオーバ
(Handover controlled by the same BCFr)
(2.4.3.5.3.1):通常手続きのモジュール
(Common Procedure Modules)
(2.4.3.5.3.2):情報フローダイアグラム
(Information Flow Diagram)
a)機能モデル(Functional model)
図44にセル内セクタ間ブランチ削除ハンドオーバ(handover branch deletion)の機能モデルを示す。
b)情報フロー(Information Flow)
図45にセル内セクタ間ブランチ削除ハンドオーバのCC−Plane情報フローダイアグラムを示す。
TACFはTACAFに対してHANDOVER BRANCH DELETION req.ind.(ハンドオーバブランチ削除req.ind.)を送信し、HANDOVER BRANCH DELETION req.ind.(ハンドオ ーバブランチ削除req.ind.)は単一または複数のハードウェア的無線チャネルの解放を要求する(図452参照)。
なお、*1は端末に関するハンドオーバブランチの数だけ繰り返してもよい。
*2は端末に関する呼の数だけ繰り返される。
TACFaはTACFv に対してアクセスベアラ解放のためBEARER RELEASE req.ind.(ベアラ解放req.ind.)を送信する(図454参照)。
TACFはBCFrに対して単一または複数のハードウェア的無線チャネルの解放要求のためINTRA BCFr HANDOVER BRANCH DELETION req.ind.(自局BCFrハンドオーバブランチ削除req.ind.)を送信する(図455参照)。
なお、本IEはBCFrがTACFに対して本IFを送信する場合に含まれる。
TACFvはTACFaに対してBEARER RELEASE req.ind.(ベアラ解放req.ind.)の確認のためBEARER RELEASE resp.conf.(ベアラ解放resp.conf.)を送信する(図457参照)。
(2.4.3.5.4.1):通常手続きのモジュール(Common Procedure Modules)
(2.4.3.5.4.2):情報フローダイアグラム(Information Flow Diagram)
a)図46にセル内ブランチ削除ハンドオーバ(handover branch deletion)の機
能モデルを示す。
b)図47にセル内ブランチ削除ハンドオーバのCC−Plane情報フローダイアグラムを示す。
以下、情報フロー等、機能エンティティ動作について述べるとともに、対応する情報要素等を表にまとめて示す。ただし、対応する要素がない場合には表を省略する場合がある。
なお、*1は端末に関するハンドオーバブランチの数だけ繰り返してもよい。
*2は端末に関する呼の数だけ繰り返される。Handover branch ID(ハンドオーバブランチID)はアクセスラジオリンクの搬送ルートの特定(1つのみ)のため用いられる。
TACAFはBCAFに対して無線ベアラの解放要求のためRADIO BEARER RELEASE req.ind.(無線ベアラ解放req.ind.)を送信する(図460参照)。
TACFはBCFに対してダイバーシチハンドオーバ状態における指示されるベアラの削除のためHANDOVER CONNECTION RELEASE req.ind.(ハンドオーバ接続解放req.ind.)を送信する(図462参照)。
TACFaはTACFvに対してアクセスベアラの解放のためBEARER RELEASE req.ind.(ベアラ解放req.ind.)を送信する(図464参照)。
TACFはBCFに対してベアラ解放の要求のためBEARER RELEASE req.ind.(ベアラ解放req.ind.)を送信する(図465参照)。
BCFはTACFに対してBEARER RELEASE req.ind.(ベアラ解放req.ind.)の確認のためBEARER RELEASE resp.conf.(ベアラ解放resp.conf.)を送信する(図466参照)。
なお、本IEはBCFrがTACFに対して本IFを送信する場合に含まれる。
TACFv はTACFaに対して前記BEARER RELEASE req.ind.(ベアラ解放req.ind.)の確認のためBEARER RELEASE resp.conf(ベアラ解放resp.conf.)を送信する(図469参照)。
(2.4.3.5.5.1):通常手続きのモジュール(Common Procedure Modules)
(2.4.3.5.5.2):情報フローダイアグラム(Information Flow Diagrams)
a)機能モデル(Functional Model)
図48に Functional model for セル内ブランチ切替ハンドオーバの機能モデルを示す。
b)情報フロー(Information Flow)
図49にセル内ブランチ切替ハンドオーバのCC−Plane情報フローダイアグラムを示す。
以下、情報フロー等、機能エンティティ動作について述べるとともに、対応する情報要素等を表にまとめて示す。ただし、対応する要素がない場合には表を省略する場合がある。
TACFaはTACFvに対してアクセスベアラのセットアップのためBEARER SETUP req.ind.(ベアラセットアップreq.ind.)を送信する(図470参照)。
なお、本IEはBCFaおよびBCFv.間のベアラを識別する。
局BCFrハンドオーバブランチ切替req.ind.)を送信し、INTRA BCFr HANDOVER BRANCH REPLACEMENT req.ind.(自局BCFrハンドオーバブランチ切替req.ind.)は新たな単一または複数のハードウェア的無線チャネルのセットアップを要求する。
なお、*1はセットアップされるラジオリンクの数だけ繰り返してもよい。
新たに割当てられる無線ベアラを制御する基地TACFはアンカTACFaに対して移 動機端末、および基地TACFの制御下にあるBCFr間のセットアップ要求のためRADIO BEARER SETUP REQUEST req.ind.(無線ベアラセットアップ要求req.ind.)を送信する(図473参照)。
なお、*1は端末に関するハンドオーバブランチの数だけ繰り返され、*2はTACFに関する呼の数だけ繰り返される。
RADIO BEARER SETUP resp.conf.(無線ベアラセットアップresp.conf.)は前記RADIO BEARER SETUP req.ind.(無線ベアラセットアップreq.ind.)に対して 応答し、BCAFはTACAFに対して無線ベアラのセットアップ完了の告知のためRADIO BEARER SETUP resp.conf.(無線ベアラセットアップresp.conf.)を送信する(図476参照)。
RADIO BEARER RELEASE resp.conf.(無線ベアラ解放resp.conf.)は前記RADIO BEARER RELEASE req.ind.(無線ベアラ解放req.ind.)に対して応答し、BCAFはTACAFに対して無線ベアラの解放完了の告知のため送信する(図478参照)。
TACFaはTACFvに対してアクセスベアラの確立確認のためBEARER SETUP resp.conf.(ベアラセットアップresp.conf.)を送信する(図479参照)。
(2.4.3.5.6.1):通常手続きのモジュール(Common Procedures Modules)
(2.4.3.5.6.2):情報フローダイアグラム(Information Flow Diagrams)
a)機能モデル(Functional Model)
図50にセル間ブランチ切替チハンドオーバの機能モデルを示す。
b)情報フロー(Information Flows)
図51にセル間ダイバーシチハンドオーバのCC−Plane情報フローダイアグラムを示す。
(Definitions of Information Flows and Associated Information Elements)以下、情報フロー等について述べるとともに、対応する情報要素等を表にまとめて示す。ただし、対応する要素がない場合には表を省略する場合がある。
なお、本IEは網が1つ以上のハンドオーバモードを有する場合、強制的である。
なお、本IEはBCFaおよびBCFv.間のベアラを識別する。
なお、本IEはBCFaおよびBCFv.間のベアラを識別する。BCFaおよびBCFv間のリ ンク遷移に対して新たなFEを設けてもよい。個別のBCFリンクはFFSと称する。
なお、本IEはBCFaおよびBCFv間のリンクを識別する。BCFaおよびBCFv間のリンク遷移に対して新たなFEを設けてもよい。個別のBCFリンクはFFSと称する。
なお、本IEはBCFおよびBCFr間のリンクを識別する。BCFaおよびBCFv間のリン ク遷移に対して新たなFEを設けてもよい。個別のBCFリンクはFFSと称する。
なお、*1は端末に関するハンドオーバブランチの数だけ繰り返され、*2はTACFに関する呼の数だけ繰り返される。
RADIO BEARER SETUP resp.conf.(無線ベアラセットアップresp.conf.)は前 記RADIO BEARER SETUP req.ind.(無線ベアラセットアップreq.ind.)に対して 応答し、BCAFはTACAFに対してアクセスラジオリンクのセットアップ完了の告知のためRADIO BEARER SETUP resp.conf.(無線ベアラセットアップresp.conf.)を送信する(図490参照)。
RADIO BEARER RELEASE resp.conf.(無線ベアラ解放resp.conf.)は前記RADIO BEARER RELEASE req.ind.(無線ベアラ解放req.ind.)に対して応答し、BCAFはTACAFに対してアクセスラジオリンクの解放完了を告知するためRADIO BEARER RELEASE resp.conf.(無線ベアラ解放resp.conf.)を送信する(図492参照)。
TACFはBCFaに対して指示されたハンドオーバリンクの削除のためHANDOVER CONNECTION RELEASE req.ind.(ハンドオーバ接続解放req.ind.)を送信する(図495参照)。
TACFaはTACFvに対して網側におけるハンドオーバリンクの解放のためBEARER RELEASE req.ind.(ベアラ解放req.ind.)を送信する(図497参照)。
TACFはBCFに対して網側におけるハンドオーバリンクの解放要求のためBEARER RELEASE req.ind.(ベアラ解放req.ind.)を送信する(図498参照)。
BCFはTACFに対してBEARER RELEASE req.ind.(ベアラ解放req.ind.)の確認のためBEARER RELEASE resp.conf.(ベアラ解放resp.conf.)を送信する(図499参照)。
TACFはBCFrに対してアクセスリンクの解放要求のため、またはBCFおよびBCFr 間のハンドオーバリンクの解放要求、BCAFおよびBCF間のハンドオーバリンクの解放要求のためBEARER&RADIO BEARER RELEASE req.ind.(ベアラおよび無線ベアラ解放req.ind.)を送信する(図500参照)。
なお、本IEは、本IFがBCFrからTACFへ送信される場合に含まれる。
TACFvはTACFaに対してconfirm BEARER RELEASE req.ind.(ベアラ解放req.ind.)の確認のためBEARER RELEASE resp.conf.(ベアラ解放resp.conf.)を送信する(図502参照)。
図790は、本システムが想定しているACCH切替の契機の一例を示すものである。この図790において、サービス制御局1は、図示しない公衆回線網に接続されて、複数の(図示の例では2つであるが)交換局2a、2bを統括するものである。交換局2a、2bは、それぞれ対応する基地局制御局3a、3bとの間に複数の回線を有する。基地局制御局3aは、基地局6a〜6dを制御し、基地局制御装置3bは、基地局6e〜6hを制御する。各基地局6a〜6hの各々は、移動局装置6との無線通信が可能な領域である無線ゾーン5a〜5fを形成している。移動局装置7は、これらの無線ゾーンのいずれかに在圏し、基地局との間で交信を行うことができる。
a)機能モデル(Functional Model)
図52にACCH切替に関連した機能エンテイテイを示す。この図52に示されるように、これらの機能エンティティは、移動局装置側に配置する機能エンティティと、基地局を含むネットワーク側に配置される機能エンティティとに大別される。これらの機能エンティティの配置先およびその機能について、以下簡単に説明する。
b)情報フロー(Information Flows)
図53、図54にACCH切替のCC−Plane情報フローダイアグラムを示す。
以下、情報フロー等、機能エンティティについて述べるとともに、対応する情報要素等を表にまとめて示す。ただし、対応する要素がない場合には表を省略する場合がある。
次に、図53および図54のシーケンス図を参照し、ACCHの切替手順について詳細に説明する。
この図53および図54のシーケンス図は、以下のような状況を想定している。
a.当初、移動局装置がトラヒックチャネルTCH1およびTCH2を利用して第1呼および第2呼の各通信を行っていた。
b.その後、トラフィックチャネルTCH1を利用した第1呼の通信が終了した。
c.その際、第1呼の通信に使用していたトラヒックチャネルTCH1と同一無線リソースにACCH1が設定されており、第1呼の通信が終了するまでは、このACCH1を介して、第1呼および第2呼の通信を維持するための制御情報の授受が行われていた。
d.第1呼の通信終了に伴ってトラヒックチャネルTCH1が解放されることとなるが、その後、トラヒックチャネルTCH2を継続使用するためには引き続きACCHが必要である。そこで、ACCHをACCH1から第2呼の通信のためのトラフィックチャネルTCH2に付随したACCH2に切り替える必要がある。
ところで、上述したACCH切替の手順は、アクセス有線リンクを新たに設定して、ACCHを切り替えるものであってが、アクセス有線リンクを新たに設定することなくACCHを切り替えることも可能である。
詳細については図53および図54を用いてすでに説明したので、ここでは簡単に説明することとする。
(2.4.3.5.8.2):情報フローダイアグラム(Information Flow Diagrams)
a)機能モデル(Functional Model)
図55にFunctional model for コード切替の機能モデルを示す。
b)情報フロー(Information Flows)
図56にコード切替のCC−Plane情報フローダイアグラムを示す。
以下、情報フロー等について述べるとともに、対応する情報要素等を表にまとめて示す。ただし、対応する要素がない場合には表を省略する場合がある。
BCFrはTACFに対してコード切替要求のためコード切替req.ind.を送信する(図524参照)。
基地TACFはTACFaに対してコード切替のためコード切替req.ind.を送信する(図525参照)。
TACFはTACAFに対してコード切替のためコード切替req.ind.を送信する(図526参照)。
なお、1は端末側ハンドオーバブランチの数だけ繰り返され、2はTACF側の呼の数だけ繰り返されれる。
コード切替resp.conf.はコード切替req.ind.に対して応答し、BCAFはTACAFに 対してコード切替の完了の告知のためコード切替resp.conf.を送信する(図528参照)。
コード切替resp.conf.はコード切替req.ind.に応答し、TACAFはTACFaに対してコード切替req.ind.の確認のためコード切替resp.conf.を送信する(図529参照)。
TACFaはTACFvに対してコード切替req.ind.の確認のためコード切替resp.conf.を送信する(図530参照)。
TACFはBCFrに対してコード切替req.ind.の確認のためコード切替resp.conf.を送信する(図531参照)。
(2.4.3.6.2):情報フローダイアグラム(Information Flow Diagrams)
a)機能モデル(Functional Model)
図57に送信電力制御の機能モデルを示す。
b)情報フロー(Information Flows)
図58に送信電力制御のCC−Plane情報フローダイアグラムを示す。
以下、情報フロー等について述べるとともに、対応する情報要素等を表にまとめて示す。ただし、対応する要素がない場合には表を省略する場合がある。
MRRCはRRCに対してハンドオーバブランチの各ラジオ状態の通知のため定期的 にCELL CONDITION REPORT req.ind.(セル状態報告req.ind.)を送信する(図532参照)。
TACFaはTACFvに対して送信電力値の通知のため送信電力値設定 req.ind.を送 信する(図533参照)。
TACFはBCFrに対して送信電力値の通知のため送信電力値設定 req.ind.を送信 する(図534参照)。
(2.4.4.1):端末位置更新(Terminal location updating)
(2.4.4.1.1):モジュール使用による通常手続き(Common procedure modules used)
端末位置更新サービス形態の範囲内で用いられる通常手続きのモジュールを以下に示す。
− TMUI調査(TMUI inquiry)
− FPLMTSによるユーザ検索(FPLMTS user ID retrieval)
− ユーザ認証手続き(User authentication procedure)
− 秘匿開始(Start ciphering)
− TMUI割当て(TMUI assignment)
a)機能モデル(Functional Model)
図59に端末位置更新の機能モデルを示す。
b)情報フロー(Information Flows)
図60に端末位置更新の情報フローダイアグラムを示す。また、図61に端末位置更新の情報要素を組み合わせた情報フローダイアグラムを示す。
情報フローおよび関連情報要素について以下に述べるが、全IEsはFFSである。
リレーションシップrd(LRCF−LRDF)(Relationship rd(LRCF−LRDF))
基地SCFはSDFに対してLAI update IF(LAI更新IF)を送信し、LAI update IF(LAI更新IF)は位置エリア情報の更新を求める。
SDFは基地SCFに対して応答確認を返信し、位置エリア情報の更新の完了を保証する(図535参照)。
SACFは基地SCFに対してTerminal location update IF(端末位置更新IF)を送信し、Terminal location update IF(端末位置更新IF)は更新対象である移動 機端末の位置情報の要求のため用いられる。基地SCFはSACFに対して応答確認を返信し、端末位置情報の更新の完了を保証する(図536参照)。
リレーションシップrl(MCF−SACF)(Relationship rl(MCF−SACF))
MCFはSACFに対してTerminal location update IF(端末位置更新IF)を送信し
、Terminal location update IF(端末位置更新IF)は更新対象である移動機端末の位置情報の要求のため用いられる。SACFはMCFに対して応答確認を返信し、端末位置情報の更新の完了を保証する(図537参照)。
1)Relationship ID(リレーションシップID)は要求側と応答側とのリレーションシップを識別する。
2)TMUI and TMUI assignment source ID(TMUIおよびTMUI割当てID)はリレーションシップrlおよびリレーションシップrkに対してFPLMTS user ID(FPLMTSユーザID)として用られるものとする。
3)端末状態は着信可能または着信不可能の状態を示すものとする。
4)TC情報は端末容量を示す端末データ情報とする。
(2.4.5.1):ユーザ認証
a)機能モデル(Functional Model)
図62にユーザ認証のモデルを示す。
b)情報フロー(Information Flows)
図63にユーザ認証の情報フローダイアグラムを示す。
C)情報フロー、情報要素、機能エンティティの動作(Definitions of Information Flows,Information Elements,and Functional Entity Actions)
リレーションシップrd(LRCF−LRDF)(Relationship rd(LRCF−LRDF))
認証情報検索IFは基地LRDFによるユーザ認証に対するセキュリティ情報の要 求のため用いられる(図538参照)。
リレーションシップrg(LRCF−TACF)(Relationship rg(LRCF−TACF))、リレーションシップrk(LRCF−SACF)(Relationship rk(LRCF−SACF))
リレーションシップrb(TACF−TACAF)(Relationship rb(TACF−TACAF))リレーションシップ rl(SACF−MCF)(Relationship rl(SACF−MCF))
リレーションシップrv(UIMF−TACAF)(Relationship rv(UIMF−TACAF))リレー ションシップ ry(UIMF−MCF)(Relationship ry(UIMF−MCF))
(2.4.5.2.1):情報フローダイアグラム(Information flow diagram)
a)機能モデル(Functional model)
図64に秘匿開始タイミングの機能モデルを示す。
b)情報フロー(Information Flows)
図65に秘匿開始タイミングの情報フローダイアグラムを示す。
以下、情報フロー等について述べるとともに、対応する情報要素等を表にまとめて示す。ただし、対応する要素がない場合には表を省略する場合がある。
リレーションシップrb(TACF−TACAF)(Relationship rb(TACF−TACAF))
リレーションシップrg(LRCF−TACF)(Relationship rg(LRCF−TACF))
Start ciphering IF(秘匿開始タイミングIF)により端末は、端末と網との間の情報の暗号化の申請開始を要求する。本フローは確認を要求する情報フローである(図542参照)。
Start ciphering IF(秘匿開始タイミングIF)により端末は、端末と網との間の情報の暗号化の申請開始を要求する。本フローは確認を要求する情報フローである(図543参照)。
リレーションシップrl(SACF−MCF)(Relationship rl(SACF−MCF))
Start ciphering IF(秘匿開始タイミングIF)により端末は、端末と網との間の情報の暗号化の申請開始を要求する。本フローは確認を要求する情報フローである。
(2.4.5.3.1):TMUI割当て(TMUI assignment)
(2.4.5.3.1.1):情報フローダイアグラム(Information flow diagram)
a)機能モデル(Functional Model)
図66にTMUIの割当ての機能モデルを示す。
b)情報フロー(Information Flows)
図67にTMUI割当ての情報フローダイアグラムを示す。なお、
1)MCF−SACFは呼がない場合のユーザ認証、
2)TACAF−TACFは呼がある場合のユーザ認証、
3)基地網に有効なユーザ認証がない場合において、Authentication Info Retrieval req.ind. and resp.conf.(認証情報検索req.ind.および 認証情報検索resp.conf.)を用いる場合である。なお、2)の場合MCF−SACFのリレーションシッ プを用いてもよい。
以下、情報フロー等について述べるとともに、対応する情報要素等を表にまとめて示す。ただし、対応する要素がない場合には表を省略する場合がある。
リレーションシップrb(TACF−TACAF)(Relationship rb(TACF−TACAF))
リレーションシップrd(LRCF−LRDF)(Relationship rd(LRCF−LRDF))
TMUI query IF(TMUI調査IF)は基地LRDFからの新たなTMUIの要求のため用いられる(図545参照)。
TMUI modify IF(TMUI修正IF)は基地LRDFへの、ユーザに対するTMUI情報の修正要求および修正後の確認の送信要求のため用いられる(図546参照)。
リレーションシップrg(LRCF−TACF)(Relationship rg(LRCF−TACF))
リレーションシップrk(LRCF−SACF)(Relationship rk(LRCF−SACF))
TMUI assignment IF(TMUI割当てIF)は網によるユーザの身分証明の後ユーザに対するTMUIの割当ておよび伝達のため用いられる。応答確認はTMUIの割当ての有効性の保証として返信される(図548参照)。
リレーションシップrl(SACF−MCF)(Relationship rl(SACF−MCF))
TMUI assignment IF(TMUI割当てIF)は網によるユーザの身分証明の後ユーザに対するTMUIの割当ておよび伝達のため用いられる。応答確認はTMUIの割当割当てての有効性の保証として返信される(図549参照)。
本手続きはTMUIの、FPLMTSユーザのIMUIへの変換のため用いられる。新たに 基地となる網がTMUI、またはTMUIおよび移動機側からの、FPLMTS user ID(FPLMTSユーザID)となるユーザのTMUI assignment source ID(TMUI割当てソースID)の1組を受信する場合、新たに基地となる網は本手続きを初期化する。
(新たに)基地となるLRCFがTMUI、またはTMUIおよび移動機端末からのTMUI assignment source ID(TMUI割当てソースID)の1組を受信する場合、LRCFは実 行されるべき手続きの選択(下記参照)を分析するものとされる。
ケースB)新たに基地となるLRDFとは異なるLRDFがTMUIを割当てた場合
(*本規定にはケースB)は記述していない。)
2)移動機発呼(Mobile Originating Call)
3)失敗時:新たに基地となる網が例えばTMUIの遺失等によりIMUIの検索に失敗する場合、新たに基地となる網はUIMFからのFPLMTS user’s IMUI(FPLMTSユーザIMUI)の検索を試みる。
図68にユーザIDの検索の情報フローダイアグラムを示す。
(2.4.5.3.2.2):情報フローおよび関連情報要素(Information flows and associated information elements)
リレーションシップrd(LRCF−LRDF)(Relationship rd(LRCF−LRDF))
IMUI retrieval req.ind.(IMUI検索req.ind.)はTMUIによるIMUIの検索のた め用いられる。LRCFは同一の網においてLRDFに対して本情報フローを送信する。IMUI retrieval resp.conf.(IMUI検索resp.conf.)は前記要求に対して応答する(図550参照)。
なお、移動機発呼の場合、本IE(TMUI assignment Source ID)は含まれない。
リレーションシップrl(SACF−LRCF)(Relationship rl(SACF−LRCF))
IMUI retrieval req.ind.(IMUI検索req.ind.)は移動機側からのIMUIの検索のため用いられる。網側がFPLMTSユーザのTMUIをIMUIに変換しない場合にのみ、本情報フローが用いられる。基地網においてSACFはMCFに対して本情報フローを送信する。IMUI retrieval resp.conf.(IMUI検索resp.conf.)が前記要求に対して応答する(図552参照)。
IMUI retrieval req.ind.(IMUI検索req.ind.)は移動機側からのIMUIの検索のため用いられる。網側がFPLMTSユーザのTMUIをIMUIに変換しない場合にのみ、本情報フローが用いられる。基地網においてLRCFはTACFに対して本情報フローを送信する。IMUI retrieval resp.conf.(IMUI検索resp.conf.)が前記要求に対 して応答する(図553参照)。
IMUI retrieval req.ind.(IMUI検索req.ind.)は移動機側からのIMUIの検索のため用いられる。網側がFPLMTSユーザのTMUIをIMUIに変換しない場合にのみ、本情報フローが用いられる。基地網においてTACFはTACAFに対して本情報フローを送信する。IMUI retrieval resp.conf.(IMUI検索resp.conf.)が前記要求に 対して応答する(図554参照)。
各機能エンティティのSDL図は、IMT−2000勧告草案Q.FIFにおけるSDL図に準拠する。但し、アクセスリンク設定手順におけるシナリオ3は本仕様では適用しない。SDL図におけるFE間での情報フロー送受の記述部分に記載されている番号はQ.FIFにおけるFEA番号である。
(2.5.1):参照構成
図69に本実験システムにおける物理ノード構成と機能エンティティの対応を示す。また、本実験システムのプロトコルを規定するためのインタフェースを以下に列記する。
・無線インタフェース
・BTS−MCCシミュレータ間インタフェース
(2.5.2.1):概要
2.5.2章では、無線インタフェースにおけるレイヤ1〜レイヤ3プロトコル仕様について、規定する。
(2.5.2.2):レイヤ1
ここでは説明を省略する。
(2.5.2.3):レイヤ2
(2.5.2.3.1):概要
レイヤ2はLAC(Link Access Control)副層とMAC(Medium Access Control)副 層からなる。更に、LAC副層はLayer3整合副々層およびLLC(Logical Link Control)副々層から構成される。
レイヤ2のユーザ間の可変長サービスデータユニット(SDU)を高信頼度転送する。
(2.5.2.3.1.1.1):Layer3整合副々層
レイヤ3とLLC間のプリミティブ/パラメータマッピング及びレイヤ3 SDUのLLC PDUへの分解・組み立てを行う。
(2.5.2.3.1.1.2):LLC(Logical Link Control)副々層
誤り制御、フロー制御等の機能を用いた高信頼度転送機能を提供する。
(2.5.2.3.1.2):MAC(Medium Access Control)副層
LLC PDUの誤り検出及びLLC PDUの分解・組み立て、レイヤ1フレームへの分解・組み立てを行う。
(2.5.2.3.2.1):LAC(Link Access Control)副層の機能
(2.5.2.3.2.1.1):レイヤ3整合副々層
レイヤ3整合副々層の機能について以下に列記する。
a)信号レイヤ3のPDU 組立および分解
本機能により信号レイヤ3PDUのLLC PDUへの組立または信号レイヤ3PDUのLLC PDUからの分解の機構が提供される。
b)リンク制御
SAPIによってLACのSDUを処理するレイヤ3エンティティを特定する。(用途は今後の検討)
c)符号型
ハイブリッドARQを適応する際に符号型を識別する。
a)シーケンスインテグリティ
本機能により本層の転送効率により決定されるLLCおよびSDUsのオーダーが保持される。
b)選択的再送信による誤り補正
階層構造により、受信側LLCのエンティティが迷走LLC SDUsの捕捉を可能にする。本機能は再送信により逐次的誤りを是正する。
c)フロー制御
本機能によりLLCリシーバによる発信側LLCピアエンティティの情報送信率の制御が可能になる。
d)レイヤ管理への誤り報告機能
本機能はレイヤ管理へ、発生した誤りを指示する。
e)通信保持機能
本機能によりリンクを構成する2つのピアLLCエンティティをデータ転送のな い状態が続いてもリンク接続状態を確立し続けることができる。
f)ローカルデータの検索
本機能によりローカルLLCユーザはLLCエンティティにより解放されていない非連続的SDUsを検索することができる。
g)接続制御
本機能によりLLCリンクの確立、解放、再同期化が達成される。また、デリバ リの保証を要せずユーザ間の可変長情報の伝送が可能になる。
h)ユーザデータの転送
本機能はLLCユーザ間のユーザデータの搬送のため利用される。LLCは保証されるデータであっても保証されないデータであってもデータの転送を支承する。
i)プロトコル誤りの検出および回復
本機能はプロトコルの操作中に生じた誤りを検出するとともに回復する。
j)状態報告
本機能により発信側および受信側のピアエンティティ間で状態情報の交換が可能になる。
MAC副層の機能について以下に列記する。
a)CRC誤りの検出およびその対処
本機能によりCRCを介して LLC PDUの腐食の検出およびその対処が得られる。腐食したLLC PDUは廃棄される。
b)LLC PDU またはBTS レイヤ3の、レイヤ1フレームへの組立またはLLC PDU またはBTS レイヤ3の、レイヤ1フレームからの分解
本機能によりLLC PDU またはBTS レイヤ3の、レイヤ1フレームへの組立機構、またはLLC PDU またはBTS レイヤ3の、レイヤ1フレームからの分解機構が提供される。
本機能には、MAC PDUをレイヤ1フレームの整数倍とするためのパディング機能も含まれる。なお、RACHにおいては、MAC PDUの2重受信排除のためにシーケンス番号を付与する。
c)アドレス制御
RACH/FACHにおける、PIDを用いた論理リンク識別(e.g. Mobile Terminal毎)を行う。
d)信号内容の区別
RACH,FACH,UPCHにおける、ユーザ情報/制御情報の区別を行う。
e)終端ノードの区別
信号が終端されるノード(BTS/BSC機能)の区別を行う。
(2.5.2.3.3.1):LAC副層のフォーマットおよびパラメータ
(2.5.2.3.3.1.1):Layer3整合副々層
a)SAPI(Service Access Point Identifier)
レイヤ3に対して提供されるレイヤ2のサービス種別を識別する(図555参照)。
b)W bit
分解・組み立てビットであり、レイヤ3フレームとレイヤ3整合副々層フレームとの対応をとる(図556参照)。
c)符号型指示子
ハイブリッドARQが適用される際の符号の型を示す。適用の有無はバージョン によって識別する(図557参照)。
d)予約
レイヤ3整合副々層のバージョン等を示す(図558参照)。
(2.5.2.3.3.1.2.1):LLC PDU
図559および図560にプロトコルデータユニット(PDU)のリストを示す。
LLC PDUの定義を以下に示す。
a)BGN PDU(Begin)
BGN PDUは2つのピアエンティティ間でのLLCリンクの確立のため用いられる。BGN PDUはピアトランスミッタのバッファおよびレシーバのバッファの切断を要するとともにピアトランスミッタおよびレシーバの変調状態の初期化を要求する。
b)BGAK PDU(Begin確認)
BGAK PDUはピアエンティティからのレイヤ2のリンクセットアップ要求の受容の確認のため用いられる。
c)BGREJ PDU(Begin拒絶)
BGREJ PDUはピアLLCエンティティからのレイヤ2のリンクセットアップ要求の拒絶のため用いられる。
END PDUは2つのピアエンティティ間でのLLCリンクの解放のため用いられる。e)ENDAK PDU(End Acknowledge)
ENDAK PDUはLLCリンクの解放の確認のため用いられる。
f)RS PDU(再同期化)
RS PDUはバッファおよびデータ転送状態変調の再同期化のため用いられる。
RSAK PDUはピアLLCエンティティの再同期化要求に対する確認のため用いられる。
h)ER PDU(誤り回復)
ER PDUはプロトコルの誤りからの回復のため用いられる。
i)ERAK PDU(誤り回復確認)
ERAK PDUはプロトコルの誤りからの回復の確認のため用いられる。
SD PDUは、連番を付されたPDUであってユーザにより与えられる情報分野を含 むPDUの、LLCリンクに亘る転送のため用いられる。
k)POLL PDU(状態要求)
POLL PDUはLLCリンクに亘り、ピアLLCエンティティの状態情報の要求のため用いられる。
l)STAT PDU(不変状態の応答)
STAT PDUはピアLLCエンティティから受信する状態要求(POLL PDU)に対する応 答のため用いられる。前記要求には、SD、PDU、SDwithPOLL PDUの受信状態、ピアトランスミッタのクレジット情報、POLL PDUまたはSDwithPOLL PDUに付された通し番号[N(PS)]に関する情報が含まれる。
USTAT PDUはSD PDUに付された通し番号の検査に基づく単一または複数の迷走SD PDUの検出について応答する。前記応答にはSD PDUの受信状態、ピアトランスミッタのクレジット情報に関する情報が含まれる。
n)SDwithPOLL PDU(逐次データおよび状態要求)
SDwithPOLL PDUは連番を付されたPDUであってユーザにより与えられる情報分 野を含むPDUの、LLCリンクに亘る転送のため用いられるとともに、ピアLLCエンティティについての状態情報の要求のため用いられる。
o)UD PDU(不特定データ)
UD PDUは2者のLLCユーザ間での不確実なデータの転送のため用いられる。LLCユーザが確認のない情報の転送を要求する場合、UD PDUはそのピアエンティティにLLCの影響を受けない状態で、あるいは可変状態にて情報を送信する。UD PDUは連番を担持せず、従って通知なしにUD PDUを消失させることができる。
MD PDUは2者の管理エンティティ間での、保証のない管理データの転送のため用いられる。管理エンティティが確認のない情報の転送を用杞憂する場合、MD PDUはピア管理エンティティにLLCの影響を受けない状態で、あるいは可変状態にて情報を送信する。UD PDUは連番を担持せず、従って通知なしにUD PDUを消失 させることができる。
a)PDUのコードタイプが判明していない場合、
b)PDUの状態のタイプに対して不適切な長さの場合
無効なPDUは送信主体に通知なしに放棄される。そのようなPDUの結果何らの追加的措置は講ぜられない(上記レイヤ管理にて報告した長さ違反 b)項、a c)項にあたる)
図72から図88までに LLC PDUフォーマットを示す。これには16のタイプのPDUがあり、そのリストを示す。
図72はPDU(SD PDU)のシーケンスデータを、図73は状態要求を含むシーケンスデータPDU(SDwithPOLL PDU)を、図74はPoll PDU(POLL PDU)を、図75は不変状態 PDU(STAT PDU)を、図76は可変状態 PDU(USTAT PDU)を、図77 はユニットデータPDU(UD PDU)管理データ PDU(MD PDU)を、図78はBegin PDU(BGN PDU)を、図79はBegin 確認 PDU(BGAK PDU)を、図80はBegin 拒絶 PDU(BGREJ PDU)を、図81はEnd PDU(END PDU)を、図82はEnd 確認 PDU(ENDAK PDU)を、図83は再同期化PDU(RS PDU)を、図84は再同期化 確認 PDU(RSAK PDU)を、図85は誤り回復 PDU(ER PDU)を、図86は誤り回復 確認PDU(ERAK PDU)を、各々示す。
以下、本フォーマットの特徴について説明する。
LLC、PDUは2.1/I.361 [4].に特定するコード規定により構成される。
なお、LLCはトレーラー配向型である。例えば、プロトコル制御情報は末尾に 送信される。
各PDUには保管領域のビット(すなわちR,Rsvd,Reserved)がある。保管領域の機能の1つは8ビット構成で達成される。一方、他の機能はさらに研究を要する
。8ビット配列以外の機能は定義されておらず、その領域ではコードはゼロとして扱われる。その領域はレシーバにより無視される。
SD,UD,and MD PDUの情報領域の最大長さはk octetsである。kの最大値はoctets [FFS]である。kの値はLLC外のサイズ折衝手続きで確立される。双互的同意があればLLCを用いる他の推奨例により特定してもよい。または、LLCを用いるプロトコルのPDUサイズの最大長さとしてもよい。kの最小値は0 octetsである。
USTAT PDUは2つのリスト要素を有する。STAT PDUはゼロまたはそれより大きいリスト要素を含む。送信されたSTATのメッセージは1つ以上のSTAT PDUに分割してもよい。
STATおよびUSTAT PDUにおけるスパンリストアイテムは奇数または偶数のリストの要素であり、該リスト要素は選択的な再送信の要求のため用いられる。各 奇数要素は失われたギャップ最初のPDUを表現し、各偶数要素は受信した連番の最初のPDUを表現するが例外として、最後の場合もあり得うる。なお、スパンリストのコード化の一例を提供する場合もある。
本項ではピア対ピアのプロトコルの特定例によりLLCエンティティの状態を説 明する。前記状態は観念的なものであり、LLCエンティティの一般的な状態、すなわち一連の信号、またユーザとピアとが各々PDUを交換する場合におけるLLCエンティティの状態を反映するものである。さらに、説明にあっては他の状態も用いられているが、それは付加的状態の主体化をさけるためであり、SDLsの説明にて詳述する。基本的な状態を以下に示す。
各LLCエンティティは観念的に同一のアイドル状態(State 1)にあり、接続を解放するとこの状態に復元する。
LLCエンティティはピアとの接続要求中であり、エンティティはピアからの確 認を受信するまで発呼接続係属状態(State 2)にある。
LLCエンティティはピア対ピアの接続の解放を要求しており、エンティティは発呼非接続係属状態、(State 4)に進行する。その状態はエンティティがピアエンティティの解放の確認を受信し、LLCエンティティがアイドル状態(State 1)へ遷移するまで継続する。アイドル状態への遷移の後は上述と同様である。
LLCエンティティはピアとの接続の再同期を要求しており、エンティティは発 呼再同期係属状態(State 5)にある。
LLCエンティティはピアからの再同期の要求を受信しており、ユーザからの応答待ち状態にある。
LLCエンティティは接続中のピアとの回復を要求しており、エンティティは発 呼回復係属状態(State 7)にある。
LLCエンティティは回復を完了するとともにユーザに通知しており、エンティティは応答待ちであって回復応答係属状態(State 8)にある。
LLCエンティティはピアから回復要求を受信しており、エンティティはユーザからの応答待ちであって着呼回復係属状態(State 9)にある。
接続の確立、再同期、あるいは誤りの回復手続きが成功すると、ピアとLLCエンティティはデータ転送準備状態(State 10)に移行し、保証されたデータ転送の実行が可能となる。
本項ではピア対ピアのプロトコルの特定例により状態変数を説明する。
SDおよびPOLL PDUには各々独立して順次、番号が付され値0からnマイナス1(nの部位はシーケンス番号のモジュールである)。
モジュールは28に等しく、全範囲での番号のサイクルは0から28−1までである。以下に示す、本例に含まれる状態変数およびシーケンス番号に基づく全ての算術操作はモジュール(VT(S)、VT(PS)、VT(A)、VT(PA)、VT(MS)、VR(R)、VR(H)、VR(MR))によって規定される。トランスミッタの変数を算術的に比較 する場合、VT(A)がベースになると考えられる。レシーバの変数を算術的に比較 する場合、VR(R)がベースになると考えられる。さらに可変状態VT(SQ)およびVR(SQ)にはモジュロとして算術数値256があてられる。トランスミッタにあってはLLCは以下に示す状態変数を維持する。
第1回目として(再送信の場合を除く)次に送信されるSD PDUのシーケンス番号である。第1回目の(再送信の場合を除く)SD PDUの送信の後、番号は増加する。
b)VT(PS)ポール送信状態変数(Poll Send state variable)
ポールシーケンス番号の現在値である。次のポールPDUの送信まで増加する。
c)VT(A)確認状態変数(Acknowledge state variable)
不規則に確認が予想されるSD PDUの次のシーケンス番号であリ、そのSD PDUは受容可能な確認のウィンドウの下縁を形成する。VT(A)は非連続的なSD PDUの確認にあって更新される。
受信が予想される次のSTAT PDUのポールシーケンス番号であり、そのSTAT PDU はSTAT PDU.に対し、受容可能なN(PS)のウィンドウの下縁を形成する。無効なN(PS)を含んでSTAT PDUが受信された場合、回復措置として初期化されるか、あるいは解放が実行される。STAT PDUが受容されるとVT(PA)はSTAT.N(PS)にセットされる。
e)VT(MS)送信状態変数の最大値(Maximum Send state variable)
最初のSD PDUがピアレシーバによって拒絶された場合、[例えばレシーバの受 容許可値がVT(MS)ー1以上の場合等]、そのSD PDUのシーケンス番号である。この値はトランスミットウィンドウの上縁を示す。USTAT PDU、STAT PDU、BGN PDU、BGAK PDU、RS PDU、RSAK PDU、ER PDU、またはERAK PDUの受信に基づき、VT(S)、VT(MS)、VT(MS)が更新されるとトランスミッタは新たなSD PDUを送信しない。
確認が未定の場合、状態変数が、POLL PDUの送信の間に送信されたSD PDUの番号、あるいはタイマポールが起動した後、最初のPOLL PDUの送信の前に送信されたSD PDUの番号を示す。VT(PD)はSD PDUの送信に基づき増加するとともに、POLL PDUの送信によりゼロにリセットされる。
確認されないBGN、END、ERまたはRS PDUの番号である。VT(CC)はBGN、END、ERまたはRS PDUの送信に基づき増加する。END PDUがプロトコルエラーの応答として送信されると、SSCOP はENDAK PDUを待たず[例えばSSCOPは直接 状態1(Idle)に移行する]VT(CC)は増加しない。
この状態変数はレシーバに、再送信されたBGN、ER、RS PDUを識別させるため用いられる。この状態変数はSSCOP過程の成立に基づき初期化されるとともに増加し、BGN、RS、ER PDUのいずれかの最初の送信より前にN(SQ)領域に組み込ま れる。
a)VR(R)受信状態変数(Receive state variable)
受信が予測される不規則な次のSD PDUのシーケンス番号である。次の不規則なSD PDUの受信により増加する。
最高値が予測されるSD PDUのシーケンス番号である。以下の2通りの方式で更新される。
1)新たなSD PDUの受信;
2)POLL PDUの受信
Receive state variable)
レシーバに許可されない最初のSD PDUのシーケンス番号である。[例えばレシ ーバの受容許可値がVR(MR)−1以上の場合等]レシーバはN(S)、VR(MR)とともにSD PDUを放棄する。(一例として、そのようなSD PDUがUSTATを送信させる場合). Updating VR(MR)の更新は任意であるが、VR(MR)はVR(H)より低い値にセットすべきではない。一例として、VR(MR)の決定法一例を付記IV内に示す。
この状態変数は再送信されるBGN、ER、RS PDUの識別に用いられる。BGN、ER、またはRS PDUの受信に基づき、この状態変数はN(SQ)の値に比較され、それからN(SQ)の値に割当てられる。値が異なる場合、PDUが検討されるとともに、VR(SQ)がN(SQ)にセットされる。値が等しい場合、PDUは再送信されたものと判定される。
a)N(S)
新たなSDまたはPOLL PDUの生成に関わらずVT(S)はN(S)にマッピングされる。b)情報領域(Information field)
SD、MD、UD PDUの情報領域は各々メッセージユニットパラメータAA−DATA、MAA−UNITDATA、AA−UNITDATAからマッピングされる。情報領域はメッセージユニットパラメータ、AA−DATA、MAA−UNITDATA、AA−UNITDATAに各々マッピングされる。
VT(PS)は(増加した後のVT(PS))POLL PDUの生成時に関わらずN(PS)にマッピングされる。POLL PDUのレシーバは受信したPOLL.N(PS)を領域STAT.N(PS)にマッピングする。さらに、エラー回復手続きの促進のためVT(PS)の現在値はN(PS)に マッピングされるとともにSD PDUがいつ送信されても対応するSD PDUとともにトランスミッタのバッファに保留される。
STATまたはUSTAT PDUの生成時に関わらずVR(R)はN(R)にマッピングされる。
e)N(MR)
STAT、USTAT、RS、RSAK、ER、ERAK、BGN、BGAK PDUの生成時に関わら ずVR(MR)はN(MR)にマッピングされる。これはレシーバによるクレジット承認の基礎になる。
f)SSCOP−UU
BGN,BGAK,BGREJ,END、RS PDU内のSSCOP−UUは、対応するSSCOP信号のパラメータSSCOP−UUからマッピングされるとともに、SSCOP−UUに、マッピングされる。
END PDUにおいて、このビットは解放の原因がSSCOP、SSCOPユーザのいずれかかを担持する。END PDUの送信原因がユーザにある場合、このビットはis bit i にセットされる。END PDUの送信原因がSSCOPにある場合、このビットはにセッ トされる。このビットはAA−RELEASEのソース領域にマッピングされる。
[付記:レイヤとレイヤの通信の様相はさらに研究する必要がある。]
h)N(SQ)
この領域は接続シーケンス値を担持する。BGN,RS,ER PDUの送信に関わらずVT(SQ)はN(SQ)にマッピングされる。この領域はVR(SQ)とともにレシーバによるBGN,RS,ER PDU.の再送信の識別のため用いられる。
i)PDUタイプ領域
タイプ領域のコード化については図539に示した。
タイマについては説明を省略する。
各LLCプロトコルパラメータを以下に示す。
a)MaxCC
状態変数VT(CC)の最大値であり、BGN,END,ER,RS PDU.の送信の最大数に対応している。
b)MaxPD
POLL PDUの送信前であってVT(PD)がゼロにリセットされる前の状態変数 VT(PD)の最大許容値である。
STAT PDUに区分されたリスト要素の中の最大数である。リストアイテムの数がMaxSTATを越える場合、STATのメッセージは分割すべきである。分割されたSTATのメッセージを担持する全てのPDUはおそらくは最後のものを除きMaxSTATのリストアイテムを含む。本パラメータはその長さの問題からSTAT PDUのレシーバには用いられない。STATのメッセージを分割する目的のある送信者のみが利用すると考えられる。本パラメータは3もしくはそれよりも大きい奇数(整数)とするべきである。
なお、無効値によりSTAT PDUはAALタイプの5の通常部分を使う6 ATMセルを充填することになる。さらに、STAT PDUの全長はSD PDUの長さの最大値を越えるべきではない。
本パラメータは接続の確立に基づきセットされる。本パラメータはYes、Noの値のいずれか一方を支持する。本パラメータがYesにセットされるとLLCは接続解放のため送信バッファおよびその他の送信部を解放できる。本パラメータがNoにセットされるとLLCは接続解放のため送信バッファおよびその他の送信部を解放できない。さらに、本パラメータがNoにセットされるとバッファに古いメッセージが残る限り、LLCは送信バッファから確認されたメッセージを選択的に解放することができなくなる。
本パラメータはクレジットの通知をレイヤ管理に調整させるため用いられる。不適正なクレジットに起因してLLCによる新たなSD PDUの送信が妨害された場合
、クレジットはNoの値をとる。LLCによる新たなSD PDUの送信が許可された場合、クレジットはYesの値をとる。クレジットの初期値はYesである。
(2.5.2.3.3.1.2.8.1):クレジットおよびピア対ピアフロー制御
クレジットはLLCレシーバにより承認され、それによりピアLLCトランスミッタによる新たなSD PDUの送信が可能になる。レシーバエンティティによるクレジットの決定プロセスには基準がないが、バッファの有用性、接続の帯域幅、遅延に関係する。
PDUの受信あるいは外部信号、内部信号の受信のような、LLCイベントは通常それ等を生じさせる規制により進行する。しかし、LLCリンク状態の変更に関する現象では、情報がデータ移送に優位する。
実施例として低プロトコル層において混雑を検出する案がある(例として a long queuing delay)。その場合、接続制御メッセージに対して優位を得るためデータ移送を一時的に留保すべきである。LLCエンティティが混雑を判断する手段はプロトコルタイマー値を含めたプロトコル環境に依存し、標準化にはなじまない。
以上のように、LLCを用いたユーザのインターフェースによるローカルフロー制御から優れた効果が得られる。
以下、各論理チャネルのMAC PDUの詳細を図87〜図94に示す。図87はBCCHを、図88はPCHを、図89はRACH−L,Sを、図90はFACH−Lを、図91はFACH−Sを、図92はSDCCHを、図93はACCHを、図94はUPCHを、各々示す。以下、図中の各要素について列記する。
MACサブレイヤフレームの長さをレイヤ1フレーム長の整数倍にするために含まれる(1オクテット単位)。PADのビットは“all 0”とする。
b)Length(PAD) MACサブレイヤフレーム単位内でのPaddingの情報量(オクテット数)を示す。
c)CRC
MACサブレイヤフレーム単位毎に誤り検出符号(CRC)を追加し、誤り検出を行う。その結果に基づき上位レイヤの再送プロトコルでの再送要否判断をする(図561参照)。
d)W bit
分解・組み立てビット。レイヤ1フレーム単位毎に、MACサブレイヤフレームの先頭、継続、終了を示す(図562参照)。
・BI:BCCH識別情報である(図563参照)。
・SFN :上りロングコード位相計算およびスーパーフレーム同期に用いるSystem Frame Number値である。
・上り干渉電力:セクタ毎の最新の上り干渉量測定値。マクロから測定開始を指定されていない場合は、ビットは“all 1”とする(図564参照)。
・PID :RACH/FACHにおいて、送信情報が関連する呼もしくは移動局を識別するための識別子である。なお、情報長は16bitである(図565参照)。
・TN :RACH,FACH,UPCHにおいて、MAC SDUに搭載される情報が基地局側終端ノードを識別するための識別子である(図567参照)。
・Mo S :FACH−Sのモードを識別するためのビットである(図568参照)。
・CRC :レイヤ1フレーム単位毎に誤り検出符号(CRC)追加し、誤り検出を行う
(図569参照)。
)によって起こる同一フレームの重複を防ぐために付与する。
・TA:たたみ込み符号のためのテールビットである。
・D:ダミービットである。
(2.5.2.4):Layer3(レイヤ3)
次にLayer3(レイヤ3)について説明する。なお、以降の説明において、ITU−T勧告Xシリーズ、Iシリーズ、Qシリーズについては、単にX.××、I.××、Q.××と表記することがある。
まず、レイヤ3のプロトコルアーキテクチャについて説明する。
図95は、無線インタフェースプロトコルアーキテクチャ(Radio interface protocol architecture)の一例を概念的に示す図である。以下、図95に示す各プロトコル制御エンティティ(Entity)の概要を列記する。
・CC:Q.2931に準拠し、呼制御及びコネクション制御を行う。
・MM−P:Q.2932に準拠し、ユーザ認証などのユーザに関する移動管理を行う。但し、本システムでは当該MM−Pを使用していない。
・MM−T:端末位置登録/更新、ユーザ認証などの端末に関する移動管理を行う。
・RRC:無線資源割り当て/予約及びハンドオーバの起動/終了の契機を扱う。
・TAC:移動端末と網との間のシグナリングコネクションの設定・解放を行う。
次に、レイヤ3におけるメッセージフォーマットについて説明する。
(2.5.2.4.2.1):CC
まず、CCメッセージについて説明する。図570にCCメッセージのMessage Type(メッセージ種別)の一覧を示す。
、「O」はオプションの情報要素であることを、「OF」は無線区間にATM(Asynchronous Transfer Mode)が適用される場合に用いられる情報要素であることを示している。
まず、ALERTINGメッセージについて説明する。本メッセージは、着信ユーザの呼出が開始されたことを示すために、着信ユーザから網に、そして網から発信ユーザに転送される。本メッセージを構成する各情報要素について図571〜図573に示す。この図に示すように、Message typeはALERTING、Significance(意味)はGlobal(グローバル)、Connection discernment(コネクション識別)はACCH、Direction(方向)はBoth(双方向)である。
次に、CALL PROCEEDINGメッセージについて説明する。本メッセージは、要求された呼設定が開始され、これ以上の呼設定情報は受け付けられないことを示すために、網から発信ユーザにあるいは着信ユーザから網に送信される。本メッセージを構成する各情報要素について図574〜図576に示す。この図に示すように、Message typeはCALL PROCEEDING、SignificanceはLocal(ローカル)、Connection discernmentはSDCCH/ACCH、DirectionはBothである。
次に、CONNECTメッセージについて説明する。本メッセージは、着信ユーザが呼を受け付けたことを通知するために、着信ユーザから網に、また網から発信ユーザに送信される。本メッセージを構成する各情報要素について図577〜図581に示す。この図に示すように、Message typeはCONNECT、SignificanceはGlobal、Connection discernmentはACCH、DirectionはBothである。
次に、CONNECT ACKNOWLEDGEメッセージについて説明する
。本メッセージは、ユーザが呼を与えられたことを示すために網から着信ユーザへ送信される。また、対称な呼制御手順を可能とするために発信ユーザから網に送信される。本メッセージを構成する各情報要素について図582に示す。この図に示すように、Message typeはCONNECT ACKNOWLEDGE、SignificanceはLocal、Connection discernmentはACCH、DirectionはBothである。
次に、PROGRESSメッセージについて説明する。本メッセージは、インターワーキングが生じた時の事象を呼の過程として表示するため、網から、もしくは、ユーザから転送される。本メッセージを構成する各情報要素について図583〜図585に示す。図583〜図585に示すように、Message type はPROGRESS、Significanceはglobal、Connection discernmentはSDCCH/ACCH、Directionはboth(双方向)である。
次に、SETUPメッセージについて説明する。本メッセージは、発信ユーザから網へ、もしくは網から着信ユーザに、呼設定を開始するために送信される。本メッセージを構成する各情報要素について図586〜図594に示す。この図に示すように、Message typeはSETUP、SignificanceはGlobal、Connection discernmentはSDCCH/ACCH、DirectionはBothである。
次に、RELEASEメッセージについて説明する。本メッセージは、ユーザもしくは網のいずれか一方から送信され、本メッセージを送信している装置がFPLMTSコネクションを既に切断したことを示し、もしあればコネクション識別子と呼番号を解放するために送信される。さらに、「解放」(REL(RELEASE))メッセージを受信した装置ではコネクション識別子を解放し、「解放完了」(REL COMP(RELEASE COMPLETE))メッセージを送信した後、呼番号を解放しなければならない。なお、将来無線区間にATMが適用された場合にのみコネクション識別子に関する記述は有効となる。本メッセージを構成する各情報要素について図595に示す。この図に示すように、Message typeはRELEASE、SignificanceはGlobal、Connection discernmentはSDCCH/ACCH、DirectionはBothである。
次に、RELEASE COMPLETEメッセージについて説明する。本メッセージは、メッセージを送信する装置が、呼番号値及び、もしあればコネクション識別子を解放したことを示すために、ユーザもしくは網から送信される。コネクション識別子は解放されれば再利用が可能となる。本メッセージを受信した装置は呼番号値を解放しなければならない。なお、将来無線区間にATMが適用された場合のみコネクション識別子に関する記述は有効となる。本メッセージを構成する各情報要素について図596に示す。この図に示すように、Message typeはRELEASE COMPLETE、SignificanceはLocal(ただし、最初の呼解放メッセージとして使用される時にはグローバルな意味を持つ情報を転送し得る)、Connection discernmentはSDCCH/ACCH、DirectionはBothである。
次に、INFORMATIONメッセージについて説明する。本メッセージは、付加情報を提供するために、ユーザまたは網によって送信される。具体的には、呼設定(例、分割発呼)のための付加情報、あるいは、種々の呼関連情報を送信するために使用され得る。本メッセージを構成する各情報要素について図597に示す。この図に示すように、Message typeはINFORMATION、SignificanceはLocal(ただし、グローバルな意味を持つ情報を転送し得る)、Connection discernmentはSDCCH/ACCH、DirectionはBothである。
次に、MM−Tメッセージについて説明する。
(2.5.2.4.2.2.1):メッセージ
まず、図598にMM−TメッセージType(種別)を示す。
なお、メッセージ種別のコーディングは、上位3ビットが“011”にてQ.2931関連、下位3ビットが“00010”にてQ.2932関連のメッセージであることを表し、その他は、MOBILITY FACILITY(モビリティファシリティ)であることを表す。
次に、MOBILITY FACILITYの構成を図599に示す。この図に示すように、そのMessage typeはMOBILITY FACILITY、Significanceはlocal、Directionはbothである。
次に、MOBILITY FACILITYメッセージにおける機能種別による情報要素の一覧を示す。なお、以降の説明において、移動局をMS、網をnetwork、Network、NETWORK、あるいはNWで表している。また、記号「→」はデータの進行方向を示している。
本機能種別は位置登録エリアの更新時やローミング時に、位置登録の要求のためにMSからNETWORKに送出される。本機能種別における情報要素の一覧を図600,601に示す。この図に示すように、本機能種別では、プロトコル識別子はMM−T、コネクション識別はSDCCH、方向はMS(MCF)→NETWORK(SACF)である。
本機能種別は位置登録エリア更新時、ローミング時に位置登録の要求に対する応答信号としてNETWORKからMSに送出される。本信号はコンポーネント種別により3種類に分類される。以下、本機能種別における情報要素の一覧を各種類別に図602〜図604に示す。なお、これらの図に示すように、本機能種別では、プロトコル識別子はMM−T、コネクション識別はSDCCH、方向はNETWORK(SACF)→MS(MCF)である。
この場合の情報要素の一覧は、図602に示す通りである。
(b−2)コンポーネント種別がReturn Error(リターンエラー)の場合(アプリケーションのエラーなどの準正常が発生した場合)
この場合の情報要素の一覧は、図603に示す通りである。
(b−3)コンポーネント種別がReject(リジェクト)の場合(情報要素の不一致などによる準正常が発生した場合)
この場合の情報要素の一覧は、図604に示す通りである。
この場合の情報要素の一覧は、図606に示す通りである。
(c−2)コンポーネント種別がReturn Errorの場合
この場合の情報要素の一覧は、図607に示す通りである。
(c−2)コンポーネント種別がRejectの場合
この場合の情報要素の一覧は、図608に示す通りである。
本機能種別は、移動局の正当性を交換機が認識するためにNETWORKからMSに送出される。本機能種別における情報要素の一覧を図609、610に示す。この図に示すように、本機能種別では、プロトコル識別子はMM−T、コネクション識別はSDCCH/ACCH、方向はNETWORK(SACF/TACF)→MS(MCF/TACAF)
本機能種別は、認証要求に対する手順の結果を通知するためにMSからNETWORKに送出される。本信号はコンポーネント種別により3種類に分類される。以下、本機能種別における情報要素の一覧を各種類別に図611〜図613に示す。これらの図に示すように、プロトコル識別子はMM−T、コネクション識別はSDCCH/ACCH、方向はMS(MCF/TACAF)→NETWORK(SACF/TACF)である。
この場合の情報要素の一覧は、図611に示す通りである。
(f−2)コンポーネント種別がReturn Errorの場合
この場合の情報要素の一覧は、図612に示す通りである。
(f−3)コンポーネント種別がRejectの場合
この場合の情報要素の一覧は、図613に示す通りである。
本機能種別は、移動局に秘匿開始を通知するためにNETWORKからMSに送出される。本機能種別における情報要素の一覧を図614に示す。この図に示すように、本機能種別では、プロトコル識別子はMM−T、コネクション識別はSDCCH/ACCH、方向はNETWORK(SACF/TACF)→MS(MCF/TACAF)である。
本機能種別は、秘匿開始に対する応答信号としてMSからNETWORKに送出される。本信号はコンポーネント種別により3種類に分類される。以下、本機能種別における情報要素の一覧を各種類別に図615〜図617に示す。これらの図に示すように、プロトコル識別子はMM−T、コネクション識別はSDCCH/ACCH、方向はMS(MCF/TACAF)→NETWORK(SACF/TACF)である。
この場合の情報要素の一覧は、図615に示す通りである。
(h−2)コンポーネント種別がReturn Errorの場合
この場合の情報要素の一覧は、図616に示す通りである。
(h−3)コンポーネント種別がRejectの場合
この場合の情報要素の一覧は、図617に示す通りである。
本機能種別は、移動局にIMUIを問い合わせるためにNETWORKからMSに送出される。本機能種別における情報要素の一覧を図618に示す。この図に示すように、本機能種別では、プロトコル識別子はMM−T、コネクション識別はSDCCH、方向はNETWORK(SACF/TACF)→MS(MCF/TACAF)である。
本機能種別は、IMUI問い合わせに対して交換機へIMUIを通知するためにMSからNETWORKに送出される。本信号はコンポーネント種別により3種類に分類される。以下、本機能種別における情報要素の一覧を各種類別に図619〜図621に示す。これらの図に示すように、プロトコル識別子はMM−T、コネクション識別はSDCCH、方向はMS(MCF/TACAF)→NETWORK(SACF/TACF)である。
この場合の情報要素の一覧は、図619に示す通りである。
(j−2)コンポーネント種別がReturn Errorの場合
この場合の情報要素の一覧は、図620に示す通りである。
(j−3)コンポーネント種別がRejectの場合
この場合の情報要素の一覧は、図621に示す通りである。
次に、RBCメッセージについて説明する。
(2.5.2.4.2.3.1):メッセージ一覧
まず、図622にRBCメッセージの一覧を示す。
次に、RBCメッセージの分類について説明する。RBCメッセージはRBC−IDの状態に影響を与えるもの(生成/削除)と、影響を与えないもの(継続)とで分類できる。ここで、図623にRBCメッセージの分類(MESSAGE TYPE)を示す。
次に、メッセージ構成について説明する。各メッセージは、基本部分と拡張部分から構成される。さらに基本部分はメッセージ固有パラメータと基本構成要素(オプション)から構成される。ここで、図96にメッセージ構成を示し、図中の構成要素について以下に列記する。
・メッセージ固有パラメータ:そのメッセージに特有のパラメータが設定される。
・基本情報要素:手順に応じたパラメータが設定され、手順によってメッセージ内に含まれる基本情報要素は異なる。なお、システム導入時から使用可能である。
・拡張情報要素:システム拡張時に追加される情報要素である。
なお、基本情報要素および拡張情報要素は任意順序で設定可能である。また、「*」が付与されている構成要素(動作指示表示)は、現行では含まれず、将来、機能拡張に伴い、新たにメッセージが追加された場合に有効となる。
次に、情報要素基本構成について説明する。図97にRBC情報基本構成を示す。なお、この図において、メッセージ固有パラメータはメッセージ内で必須のパラメータである。また、各パラメータでは、可変長の場合又は、オプショナルな形態で使用するパラメータの設定値が存在しない場合には、設定が無いことを表示する。(パラメータ長、もしくはパラメータ有無ビットを設定する。)
次に、RBCメッセージフォーマットについて説明する。
(2.5.2.4.2.3.4.1):RADIO BEARER SETUP(無線ベアラ設定)
まず、RADIO BEARER SETUPメッセージについて説明する。本メッセージは、無線ベアラの設定を行うためにNetworkよりMSに送出される。その情報長等は図624に示す通りであり、プロトコル識別子はRBC、コネクション識別はSDCCH/ACCH、方向はNetwork → MSである。
本メッセージは、無線ベアラを解放するためにNetworkよりMS、またはMSよりNetwrokに送出される。その情報長等は図625に示す通りであり、プロトコル識別子はRBC、コネクション識別はACCH、方向はMS→Network,Network→MSである。
本メッセージは、指定された無線ベアラの解放が完了したことを通知するためにMSよりNetwork,NetworkよりMSに送出される。その情報長等は図626に示す通りであり、プロトコル識別子はRBC、コネクション識別はACCH、方向はNetwork→MS,MS→Networkである。
本メッセージは、ハンドオーバー時の無線ベアラの指定を行うためにNetworkよりMSに送出される。その情報長等は図627に示す通りであり、プロトコル識別子はRBC、コネクション識別はACCH、方向はNetwork→MSである。
なお、HANDOVER COMMANDメッセージには必ず1つ以上の基本情報要素が設定されていなければならない。
本メッセージは、HANDOVER COMMAND(DHOブランチ削除起動の単独要求、DHOブランチ追加の単独要求,コード切替の単独要求,及びそれらの任意の組み合わせ)に対する応答を行う為に送出される。その情報長等は図628に示す通りであり、プロトコル識別子はRBC、コネクション識別はACCH、方向はMS→Networkである。
次に、RRCメッセージについて説明する。
(2.5.2.4.2.4.1):メッセージ一覧
まず、図629にRRCメッセージの一覧を示す。
なお、RRCプロトコルへのROSE(Remote Operations Service Element)適用はFFSである。本明細書及び図面はROSE適用に基づいている。
次に、RRCメッセージフォーマットについて説明する。
(2.5.2.4.2.4.2.1):無線リソースファシリティ(RADIO RESOURCE FACELITY)
本メッセージは、RRC手順の起動のために、MS→Networkに送出される。その情報長等は図630に示す通りであり、プロトコル識別子はRRC、コネクション識別はSDCCH/ACCH、方向はMS→Networkである。
次に、TACメッセージフォーマットについて説明する。まず、図631にRRCメッセージ名の一覧を、図632にメッセージ名とインフォメーションフロー名との対応を示す。
以下、各メッセージについて述べる。
本メッセージは、TERMINAL ASSOCIATIONの開始を通知するために、MSからNetworkに送出される。その情報長等は図633に示す通りであり、プロトコル識別子はTAC、コネクション識別はSDCCH、方向はMS(TACAF)→Network(TACF)である。
本メッセージは、TERMINAL ASSOCIATION SETUPに対する応答信号でTERMINAL ASSOCIATIONが正常に行われたことを通知するために、NetworkからMSに送出される。その情報長等は図634に示す通りであり、プロトコル識別子はTAC、コネクション識別はSDCCH、方向はNetwork(TACF)→MS(TACAF)である。
本メッセージは、一斉呼び出しの応答としてMSからNetworkに送出される。その情報長等は図635に示す通りであり、プロトコル識別子はTAC、コネクション識別はSDCCH、方向はMS(TACAF)→Network(TACF)である。
本メッセージは、TERMINAL ASSOCIATIONの解放を要求するためにNetwork,MS双方より送出される。その情報長等は図636に示す通りであり、プロトコル識別子はTAC、コネクション識別はSDCCH/ACCH、方向はNetwork(TACF)→MS(TACAF),MS(TACAF)→Network(TACF)である。
)
本メッセージは、TERMINAL ASSOCIATION RELEASEの応答信号としてNetwork,MS双方より送出される。その情報長等は図637に示す通りであり、プロトコル識別子はTAC、コネクション識別はSDCCH/ACCH、方向はNetwork(TACF)→MS(TACAF),MS(TACAF)→Network(TACF)である。
本メッセージは、TERMINAL ASSOCIATIONが正常に行われたことを通知するためにNetworkからMSに送出される。その情報長等は図638に示す通りであり、プロトコル識別子はTAC、コネクション識別はSDCCH/ACCH、方向はNetwork(TACF)→MS(TACAF)である。
ここでは、RACH,FACH,BCCH及びPCHレイヤ3メッセージにつて説明する。なお、表記方法は上述の方法と同様である。
次に、SIGNALING CHANNEL SETUP REQUESTについて説明する。本メッセージは、SDCCHの設定の要求を行うためにMSからBTSに送出される。その情報長等は図639に示す通りであり、コネクション識別はRACH、方向はMS(SCMAF)→BTS(SCMF)である。
なお、同一セクタ内で同時にランダムアクセスする移動局間は、PID(パケット識別子)によって識別される。このPIDはレイヤ1におけるビットであり、移動局の付与する乱数である。
次に、SIGNALING CHANNEL SETUP RESPONSEについて説明する。本メッセージは、SDCCHの設定の要求を行うためにBTSからMSに送出される。その情報長等は図640に示す通りであり、コネクション識別はFACH、方向はBTS(SCMF)→MS(SCMAF)である。
なお、移動局においては、レイヤ1におけるPIDによって識別される。
本メッセージは、MSからのSDCCH要求に対し、BTSからの拒否応答を返す。その情報長等は図641に示す通りであり、コネクション識別はFACH、方向はBTS(SCMF)→MS(SCMAF)である。
なお、移動局においては、レイヤ1におけるPIDによって識別される。
次に、報知情報について説明する。
まず、報知情報1(BROADCAST INFORMATION1)につ いて説明する。このメッセージは、網からユーザに対して、制御チャネル構造、待ち受けチャネルの決定に関する情報、規制情報等を通知するために報知される。その情報長等は図642に示す通りであり、コネクション識別はBCCH、方向はBTS(BCFr)→MS(BCAF)である。
次に、PAGINGについて説明する。本メッセージは、ユーザに対して第1呼の着信呼び出しを行うためにユーザに送出される。その情報長等は図644に示す通りであり、プロトコル識別子はTAC、コネクション識別はPCH、方向はBTS(BCFr)→MS(TACAF)である。
なお、Paged MS ID(ページドMS ID)には、TMUI又はIMUIが含まれる。また、IMUIかTMUIを識別するI/Tビットを先頭に付与する。本メッセージの最大長は、112bitである。また、図中において、「*」が付与された項目のコーディングについては、FFS,IMUI呼び出しの場合は、PCH群算出番号からIMUIの下桁が認識できるため、IMUIの全値をPaged MS IDに設定する必要はない。
次に、情報要素フォーマットについて説明する。
(2.5.2.4.3.1):CC
まず、CCについて説明する。
(2.5.2.4.3.1.1):共通情報要素
まず、共通情報要素について説明する。
本プロトコル内のメッセージは、次の部分から構成されている。
(a)プロトコル識別子(protocol discriminator)
(b)呼番号(Call reference value)
(c)メッセージ種別(Message types:メッセージ整合性動作指示表示を含む)
(d)可変長情報要素(必要な場合)
この構成を図98に例として示す。最初の3つの情報要素(プロトコル識別子、呼番号、メッセージ種別)は、図98に明記された順序で現れなければならない。なお、図98は、メッセージ構成を示す図である。
次に、プロトコル識別子について説明する。
プロトコル識別子は、本システム内で定義される他のメッセージから、ユーザ・網呼/コネクション制御メッセージを識別する目的で設けられており、他のITU−T勧告/TTC標準および他の標準によりコード化されるOSIネットワークレイヤプロトコルユニットのメッセージから、本システムのメッセージを識別する。
呼番号は、ローカルなユーザ・網インタフェース上で、特定の呼に関連するメッセージを識別する目的で設けられており、B−ISDN(広帯域統合サービスデジタル網:Broadband Aspects of Integrated Services Digital Network)を介してエンド・エンドに使用されるものではない。この呼番号は、各メッセージの2番目に配置され、図100に示すようにコード化される。呼番号長の値は、オクテット1のビット1〜4に示されており、呼番号情報要素長は1オクテットである。
次に、メッセージ種別(メッセージ整合性動作指示表示を含む)について説明する。
メッセージ種別は、送出されるメッセージの機能を識別する目的で設けられている。このメッセージ種別は、各メッセージの3番目に配置され、図102や図646および図647に示すようにコード化される。なお、図102はメッセージ種別のフォーマットを示す図であり、図646および図647は一つの表(メッセージ種別のコーディングを示す表)を構成している。図646および図647において、値“0000 0000”は、国内規定メッセージへのエスケープとして使用される。また、値“1111 1111”は、他の全てのメッセージ種別値が使用済みとなった場合の拡張機構のために予約済みである(図646および図647参照)。
(2.5.2.4.3.1.3.1):コーディング規定
まず、コーディング規定について説明する。
可変長情報要素のコーディングは以下に述べるコーディング規定に従う。これらの規定は、メッセージを処理する各装置が、処理上必要である情報要素を見つけ、必要でないものを無視するように考えられたものである。
(a)広帯域繰り返し識別子情報要素を使用せずに情報要素が繰り返した場合、次の規定が適用される。
・繰り返す情報要素は連続しなければならない。
この規定は、広帯域固定シフト情報要素、広帯域一時シフト情報要素には適用しない。
・広帯域繰り返し識別子は、繰り返された最初の情報要素の直前に先行しなければならない。
・(広帯域繰り返し識別子のすぐ後に続く)繰り返された最初の情報要素は、優先度が一番高いと解釈される。繰り返された情報要素は、優先度が降順と解釈される。
・繰り返す情報要素は連続しなければならない。
広帯域一時シフト情報要素に続く情報要素は、それらの情報要素をまとめて一つの情報要素とみなして、上述の規定を適用する。なお、広帯域繰り返し識別子情報要素によって、情報要素がメッセージ内で一回しか繰り返されない場合にはエラーとはならない。すなわち、広帯域繰り返し識別子は無視される。
なお、本システムで使用される情報要素の記述に予備ビットが含まれる場合、これらの予備ビットは“0”に設定されている。また、情報要素を受信した際、たとえ予備ビットが“0”にセットされていなくても、この予備ビットに関して処理は行われない。
条件:(有効な)情報要素識別子を持ち、情報要素長が0である。
・ビット値“0”はオクテットが次のオクテットへ継続していることを示す。・ビット値“1”はこのオクテットが最終のオクテットであることを示す。
・1つのオクテット(Nb)が存在すれば前のオクテット(NとNa)もまた存在する。
なお、2.5.2.4.3.1.3.5節などの記述では、ビット8は以下のように示されている。
・“0/1拡張”…このオクテットグループの別のオクテットが後に続く場合。
・“1拡張”…これが拡張領域上最後のオクテットである場合。
・“0拡張”…このオクテットグループの別のオクテットが必ず後に続く場合。
(g)情報要素がサブフィールド識別子を使って構造化された場合、これらのサブフィールド識別子は位置に依存しない。即ち、それらは情報要素内で特定の順序で現れる必要はない。
・より大きいビット番号のビットが、より上位のビットを含む。
・特に、整数コーディングの最大ビット番号のビットがMSBを示している。
・特に、整数コーディングの最小ビット番号のビットがLSBを示している。
・ビットのコーディングは、小さいビット番号に詰めて(右詰めで)行われる。
つまり、先行する0の部分は、オクテットあるいは、フィールドの大きいビット番号の側(左側)に現れる。
次に、コード群の拡張について説明する。
2.5.2.4.3.1.3.1節で述べたフォーマットを用いると、情報要素識別子は、複数個の値をとり得る。
・コード群1〜3は、将来のITU−T/TTC使用として予約されている。
・コード群4は、ISO/IEC標準使用として予約されている。
・コード群5は、国内利用の情報要素群として予約されている。
・コード群6は、公衆網もしくは私設網特有の情報要素群として予約されている。
・コード群7は、ユーザ特有の情報要素群として予約されている。
また、2.5.2.4.3.1.3.1節で定めたコーディング規定は、任意の使用中コード群に属する情報要素に適用される。
・一時シフト手順を用いるとコード群4,5,6,7に属する情報要素は、使用中コード群であるコード群0に属する情報要素と一緒に出現し得る。(2.5.2.4.3.1.3.4節参照)
・コード群1〜3は、将来のITU−T/TTC使用に予約されている。
次に、広帯域固定シフト手順について説明する。
広帯域固定シフト手順では、新たな使用中コード群を示すために情報要素を使用する。指定されたコード群は、他のコード群の使用を指定する別の広帯域固定シフト情報要素が現れるまで、継続して使用中とする。例えば、メッセージ内容解析の開始時には、コード群0が使用中であるとする。コード群5の広帯域固定シフトが現れた場合には、次の情報要素からは、他のシフト情報要素が現れるまで、コード群5で割り当てられた情報要素識別子に従って解釈される。
図105および図650は広帯域固定シフト情報要素について説明するための図であり、広帯域固定シフト情報要素は、情報要素フォーマットを使用し、図105及び図650に示すようにコード化される。
次に、広帯域一時シフト手順について説明する。
広帯域一時シフト手順は、より低いあるいはより高い指定されたコード群に対して、一時的にシフトするのに用いられる。この広帯域一時シフト手順では、広帯域一時シフト情報要素を使用して、次の単一の情報要素の解釈に使用するコード群を示す。したがって、次の単一の情報要素の解釈の後、その次に続く任意の情報要素の解釈には、一時シフトする前の使用中コード群が再び使用される。例えば、メッセージ内容解析の開始時には、コード群0が使用中であるとする。コード群6の広帯域一時シフトが現れた場合には、次の情報要素だけがコード群6で割り当てられた情報要素識別子に従って解釈される。この情報要素の解釈の後、その次に続く情報要素の解釈には、再びコード群0が使用される。なお、広帯域一時シフト情報要素が現在のコード群を示す場合であっても、誤りとみなすべきではない。
次に、ATMアダプテーションレイヤ(AAL)パラメータについて説明する。ATMアダプテーションレイヤ(AAL)パラメータは、現在のシステムでは不必要なパラメータであるが、将来無線区間にATMが適用される際、本情報要素は必要となる可能性がある(FFS)。
次に、ATMトラヒック記述子について説明する。ATMトラヒック記述子は
、現在のシステムでは不必要なパラメータであるが、将来無線区間にATMが適用される際、本情報要素は必要となる可能性がある(FFS)。
次に、広帯域伝達能力について説明する。広帯域伝達能力は、現在のシステムでは不必要なパラメータであるが、将来無線区間にATMが適用される際、本情報要素は必要となる可能性がある(FFS)。
なお、図113において、記号「Note」が付されたオクテットは、オクテット5にベアラクラス“X”が表示された場合のみ存在し得る。
次に、着番号について説明する。着番号情報要素(Called party number information element)は、通信相手を表示する目的で設けられている。
次に、着サブアドレスについて説明する。着サブアドレス情報要素(Called party sub−address element)は、通信相手のサブアドレスを示す目的で設けられている。サブアドレスの定義については、ITU−T勧告I.330を参照されたい。
(2.5.2.4.3.1.3.13):発番号(Calling party number)
次に、発サブアドレスについて説明する。発サブアドレス情報要素(Calling party sub−address information element)は、呼の発信元を表示する目的で設けられている。
理由表示情報要素の内容と使用法は、ITU−T勧告Q.2610に定義されている。
次に、コネクション識別子について説明する。コネクション識別子は、現在のシステムでは不必要なパラメータであるが、将来無線区間にATMが適用される際、本情報要素は必要となる可能性がある(FFS)。
次に、エンド・エンド中継遅延について説明する。エンド・エンド中継遅延情報要素(End−to−end transit delay information element)は、呼毎に許容される実質の最大エンド・エンド中継遅延を示すこと、及びバーチャルチャネルコネクションで予期される累計中継遅延を示すことを目的として設定されている。この中継遅延は、発信ユーザと着信ユーザ間でのユーザプレーン上のデータ転送フェーズ中に転送されるユーザデータのエンド・エンドの片方向中継遅延であり、以下のものを含む。
・網転送遅延(例えば、伝搬遅延、ATMレイヤ転送遅延、その他あらゆる網内処理遅延)
本システムにおいては、上述のエンド・エンド中継遅延に加え、QOSパラメータ情報要素(Quality of Service parameter information element)が規定される。QOSパラメータ情報要素は、あるQOSクラスを示すことを目的として設定されている。
次に、広帯域繰り返し識別子について説明する。
広帯域繰り返し識別子情報要素(Broadband repeat indicator information element)は、メッセージに含まれている場合、メッセージの中で繰り返されている情報要素をどのように解釈しなければならないかを示す目的で設定されており、メッセージ中で繰り返される情報要素の最初のものの前に位置する。但し、1つのメッセージ中でただ1回しか存在しない情報要素と広帯域繰り返し識別子情報要素が組み合わされた時もそれ自身をエラーとしてはならない。
次に、初期設定表示について説明する。
初期設定表示の詳細は、将来において定義すべき事項である(FFS)。
初期設定表示情報要素は、初期設定されるファシリティのクラスを識別することを目的として設けられている。
次に、広帯域送信完了について説明する。広帯域送信完了情報要素(Broadband sending complete information element)は、着番号の完了をオプションとして示すことを目的として設けられている(ITU−T勧告Q.2931参照)。
本情報要素は、一括モード手順の場合には必須であるが、この情報要素が無い場合には、“必須情報要素不足”の正規のエラー処理を適用する必要はない。
図125は、広帯域繰り返し識別子情報要素について説明するための図であり、広帯域繰り返し識別子情報要素は、この図に示すようにコード化される。なお、本情報要素長は5オクテットである。
次に、中継網選択について説明する。中継網選択情報要素(Transit network selection information element)は、要求している一つの中継網を示すことを目的として設けられている。中継網選択情報要素は、呼が通過しなければならない中継網の順番を示すため、一つのメッセージの中に繰り返し現れることがある(ITU−T−Q.2931参照)。
次に、通知識別子について説明する。通知識別子情報要素(Notification indicator information element)は、呼に関連した情報を通知することを目的として設けられている。
次に、OAMトラヒック記述子について説明する。OAMトラヒック記述子は、現在のシステムでは不必要なパラメータであるが、将来無線区間にATMが適用される際、本情報要素は必要となる可能性がある(FFS)。
次に、64kbit/sベースの回線交換モードISDNサービスをサポートするための情報要素について説明する。
まず、コーディング規定について説明する。本2.5.2.4.3.1.4節で記述する情報要素は、図103に示したものと同様に、一般的な情報要素フォーマットを用いる。これらの情報要素のコーディングは、ITU−T勧告Q.931/ITU−T−Q.2931のコーディング規定に従う。
次に、狭帯域伝達能力について説明する。狭帯域伝達能力は、現在のシステムでは不必要なパラメータであるが、将来無線区間にATMが適用される際、本情報要素は必要となる可能性がある(FFS)。
狭帯域高位レイヤ整合性情報要素(Narrowband high layer compatibility information element
)は、相手ユーザが通信可能性確認のための手順を提供することを目的として設けられている(ITU−T勧告Q.931参照)。
次に、狭帯域低位レイヤ整合性について説明する。狭帯域低位レイヤ整合性情報要素(Narrowband low layer compatibility information element)は、アドレス指定されたエンティティ(例えば、発信ユーザによって、アドレス指定されたリモートユーザやインタワーキングユニットや網の高位レイヤ機能ノード)との通信可能性確認のための手段を提供することを目的として設けられている。
次に、経過識別子について説明する。経過識別子情報要素(Progress indicator information element)は、呼の生成中に起こったイベントを表すことを目的として設けられており、本情報要素は、メッセージの中で2回まで含まれても良い。
図132は、経過識別子情報要素について説明するための図であり、経過識別子情報要素は、この図に示すようにコード化される。なお、本情報要素の最大長は6オクテットである。
次に、MM−T情報要素フォーマットについて説明する。以下、図672に示すMM−T固有情報要素の一覧に基づいて、各情報要素について順に説明する。
まず、TMUIについて説明する。TMUIは移動局を識別するテンポラリな番号で、位置登録/位置更新時に更新される。発着信時に網側でTMUI不一致を認識した場合を除き、基本的にはTMUIを更新することはない。
なお、図133はTMUIを説明するための図であり、この図において、TMUI=M−SCP識別番号(10bit)+ユニーク識別番号(20bit+2bit)であり、ノーマルバイナリ(Normal Binary)コーディングであるものとする。ただし、上式における「2ビット」は、2重割当回避用ビットを示している。また、M−SCP Identification Number(M−SCP識別番号)は、TMUIを割り当てたM−SCPを識別するために使用されるものであり、0〜999の値をとる。さらに、Unique Identification Number(ユニーク識別番号)は、TMUI割当ノード内で移動局を識別するために使用されるものであり、0〜999999の値をとる。また、Double Assignment Evasion Bit(TMUI2重割当回避用ビット)は、TMUIの2重割当を回避するために使用されるものであり、0〜3の値をとる。
次に、TMUI Assignment Source IDについて説明する。TMUI Assignment Source IDは、図134に示すように、MCC(モバイルカントリコード:Mobile Country Code)、MNC(モバイルネットワークコード:Mobile Network Code)、LAIより構成される。なお、本システムにおいては、BCDコーディングとしている。
次に、図135を参照してIMUIについて説明する。IMUIは、移動局を認識可能な番号であり、ネットワーク内で使用される。なお、本システムにおいては、MCC、MNCを含めて15桁までの可変長であり、BCDコーディングであるものとしている。
次に、図136を参照してExecution Authentication Typeについて説明する。Execution Authentication Typeは、移動局が複数の認証手順を持つ場合に認証手順を指定する情報である。
次に、図137を参照してAuthentication Random Patternについて説明する。Authentication Random Patternは、移動局において認証を行うためのランダムパターンを示すものである。
次に、図138を参照して、Authentication Ciphering Patternについて説明する。Authentication Ciphering Patternは、移動局において認証乱数より求めた暗号化パターンを示すものである。
次に、図140を参照してTC Infoについて説明する。TC Infoは、移動局の種別を識別するために用いられる情報である。
次に、RBCメッセージ情報要素について説明する。
(2.5.2.4.3.3.1):メッセージ種別
まず、メッセージ種別について説明する。メッセージ種別は、図141から明らかなように、送出されるメッセージの機能を識別するために、動作指示表示を含まない形で設けられている。図中の各種別については後述する。
次に、情報要素識別子について図142を参照して説明する。情報要素識別子は、各メッセージに含まれるオプション情報を識別するものであり、1オクテット目が“11111111”の時に、2オクテット以降が有効となる。また、2オクテット目以降に関しては、拡張フラグ(ビット8)により次オクテット目が有効となる。なお、各固有パラメータに関する識別子は設定していない。また、各情報要素識別子については後述する。
図143に、RADIO BEARER SETUPメッセージ固有パラメータの構成を示す。この図において、RBC_IDは、CCプロトコル上でCR+CONN_IDで識別されるコネクションと、1対1に対応するRBCのコネクションを識別する番号であり、CR(呼番号)はCC用呼識別子であり(2.5.2.4.3.1参照)、CONN_IDはCC用コネクション識別子である(2.5.2.4.3.1参照)。
図144に、RADIO BEARER RELEASEメッセージ固有パラメータの構成を示す。この図に示すように、RADIO BEARER RELEASEメッセージ固有パラメータは、RBC_IDと理由表示とから構成されている。
図145に、RADIO BEARER RELEASEメッセージ固有パラメータの構成を示す。この図に示すように、RADIO BEARER RELEASE COMPLETEメッセージ固有パラメータは、RBC_IDのみから構成されている。
図146に、HANDOVER COMMANDメッセージ固有パラメータの構成を示す。この図に示すように、HANDOVER COMMANDメッセージ固有パラメータは、INVOKE_IDのみから構成されている。なお、INVOKE_IDは、HANDOVER COMMANDが起動された場合に、応答信号との対応をとるための識別番号である。
図147に、HANDOVER RESPONSEメッセージ固有パラメータの構成を示す。この図に示すように、HANDOVER RESPONSEメッセージ固有パラメータは、INVOKE_IDのみから構成されている。
図148〜図151に、無線ベアラ設定情報の構成を示す。図148において
、「情報要素識別子」はRADIO BEARER SETUP基本情報要素部(8ビット)、「長さ」は情報要素の長さ、「周波数帯域」は第1Call(コール)で設定された周波数帯域(f1:“00000000”〜f256:“11111111”)、「BTS番号」はネットワーク内のBTS識別番号(1〜)、「セクタ番号」はBTS内のセクタ識別番号(1:“00000001”〜12:“00001100”)、「上りショートコード種別」は上りコード当りの情報転送速度(図150参照)、「上りコード数」は上りマルチコード使用時(1コネクションに対して上りコードとして複数のショートコードを使用する場合)の上りショートコード数(1〜N)、「上りショートコード番号」は上りショートコードの識別番号(0〜2047)、「下りショートコード種別」は下りコード当りの情報転送速度(図150参照)、「下りコード数」は下りマルチコード使用時(1コネクションに対して下りコードとして複数のショートコードを使用する場合)の下りショートコード数(1〜M)を示す。
図152〜図154に、DHO追加の構成を示す。図152において、「情報要素識別子」はDHO追加を表す8ビット、RBC_ID数は同時設定コネクション数(1〜H)を示している。なお、他の構成要素については、前述した通りである。
図155に、DHO削除の構成を示す。図155において、「情報要素識別子
」はDHO削除を表す8ビットであり、他の構成要素については、前述した通りである。
図156に、ACCH切替の構成を示す。図156において、「情報要素識別子」はDHO削除を表す8ビットであり、他の構成要素については、前述した通りである。
図157〜図159に、ブランチ切替の構成を示す。図157において、「情報要素識別子」はブランチ切替を表す8ビットであり、他の構成要素については
、前述した通りである。
図160〜図163に、ユーザレート切替の構成を示す。図160において、「情報要素識別子」はユーザレート切替を表す8ビットであり、他の構成要素については、前述した通りである。
図164〜図165に、コード切替の構成を示す。図164において、「情報要素識別子」はコード切替を表す8ビット、「旧ショートコード数」は、切替(ショートコード再配置)処理を行う旧ショートコード番号の数(1〜N)、「旧ショートコード番号」は、切替(ショートコード再配置)処理以前に使用されていたショートコードの識別番号(0〜2047)、「新ショートコード数」は、切替(ショートコード再配置)処理を行う新ショートコード番号の数(1〜M)、「新ショートコード番号」は、切替(ショートコード再配置)処理以降に使用される新しいショートコードの識別番号(0〜2047)を示しており、他の構成要素については、前述した通りである。
次に、RRCメッセージ情報要素について説明する。
(2.5.2.4.3.4.1):メッセージ種別
まず、メッセージ種別について図166を参照して説明する。メッセージ種別は、送出されるメッセージの機能を識別するためのものである。
次に、ファシリティの構成を図167に示す。図167において、「プロファイル」は4オクテット以降に収納されるPDU(プロトコルデータ単位)の種別(ROSEプロトコル、CMIPプロトコル、ACSEプロトコル)を示し、「PDU」はプロファイルで識別されるASE(アプリケーションサービス要素)のPDUである。なお、「PDU」には、複数のPDUを収納可能であり、本システムにおいては、ROSEプロトコルを用いている。
次に、ROSE PDUの構成を図168および図169に示す。図168において、「コンポーネント種別タグ」は図に示すコンポーネント種別(起動、結果応答(最終)、エラー応答、拒否、結果応答(途中)など)を識別ためのものであり、本情報要素は全てのコンポーネントに必須である。「コンポーネント長」はコンポーネント種別タグ及びコンポーネント長フィールドを除くコンポーネントの長さを示し、「インボーグ識別子タグ」はオペレーション起動をユニークに識別するための参照番号として用いられ、要求と応答の対応付けを行う。また、「インボーグ識別子長」はインボーグ識別子のフィールドの長さ、「インボーグ識別子」はインボーグ識別子(起動ID)を示し、「オペレーション値タグ」は「起動」コンポーネント等に含まれ、起動すべきオペレーション(ローカルオペレーション、グローバルオペレーション)を示すために用いられる。さらに、「オペレーション値」は具体的なオペレーション(発着信候補ゾーン情報、通信中ゾーン情報、DHO追加ゾーン情報、DHO削除ゾーン情報、HHO実行ゾーン情報、アウターループ情報、品質劣化通知情報)を定義する。
次に、オペレーション固有パラメータについて説明する。
(a)発着信候補ゾーン情報
まず、発着信候補ゾーン情報について説明する。
本オペレーションは、MSにおいて測定された発着信時の待受中セクタの無線状態とその周辺セクタの無線状態を網に通知するために、MSからNetworkの方向で起動される。各パラメータについて図673に示す。
なお、上記図において、とまり木CH受信SIR値,とまり木CH送信電力値は,下りの送信電力制御用に使用される。
次に、通信中ゾーン情報について説明する。
本オペレーションは、MSにおいて測定された通信中セクタの無線状態に基づき無線チャネル下り送信電力制御を起動するために、MSからNetworkに送出される。各パラメータについて図674に示す。
次に、DHO追加ゾーン情報について説明する。
本オペレーションは、通信中のダイバーシチリンク追加をMSが網に対して起動するために用いられ、追加候補セクタ,追加候補セクタの無線状態,及び通信中セクタの無線状態の情報を含む。各パラメータについて図675に示す。
なお、通信中在圏セクタと比較して、DHO追加しきい値をこえているセクタのみが設定される。なお,最大ブランチ数で通信中にその候補セクタが、全ての通信中在圏セクタよりも条件が悪いならば、DHO追加ゾーン情報としてDHOトリガは送出されない。
次に、DHO削除ゾーン情報について説明する。
本オペレーションは、MSにおいて測定された通信中セクタの無線状態に基づき、網に対してダイバーシチリンク削除を起動するために用いられる。各パラメータについて図676に示す。
本機能種別には,通信中在圏セクタ内で比較して,DHO削除しきい値を超えているセクタのみが設定される。なお、DHO追加候補が加わることにより入れ替わって削除される(DHO削除しきい値を超えていないにも関わらず)可能性があるセクタに対しては本機能種別を用いない。
次に、HHO実行ゾーン情報について説明する。
本オペレーションは、MSにおいて測定された通信中セクタ、周辺セクタの無線状態に基づき、網に対してブランチ切替ハンドオーバ実行を起動するために用いられる。各パラメータについて図677に示す。
次に、アウターループ情報について説明する。
本オペレーションは、下り無線チャネルのアウターループ送信電力制御をMSが網に対して起動するために用いられる。各パラメータについて図678に示す。
次に、品質劣化通知情報について説明する。
本オペレーションは、MSが下り無線チャネル品質劣化を検出時に、網に対して異周波数チャネルへのブランチ切替ハンドオーバを起動するために用いられる。各パラメータについて図679に示す。
次に、オペレーション固有パラメータ定義について説明する。
(2.5.2.4.3.4.5.1):在圏候補セクタ数,通信中在圏セクタ数,DHO追加候補セクタ数,DHO削除セクタ数,HHO候補セクタ数
まず、在圏候補セクタ数,通信中在圏セクタ数,DHO追加候補セクタ数,DHO削除セクタ数,HHO候補セクタ数の構成について図170に示す。図170中の「セクタ数」は1〜Nをバイナリ表示する。
図171にBTS番号の構成を示す。図171において、「BTS識別子」はネットワーク内でBTSの識別が可能な番号(1〜)である。
図172にセクタ番号の構成を示す。図172において、「セクタ番号」はBTS内でセクタの識別が可能な番号(1〜12)である。
図173にとまり木CH受信SIR値の構成を示す。図173において、「とまり木CH受信SIR」は、MSが測定した在圏セクタや周辺セクタ、通信中セクタのとまり木CHの受信SIRを示す。
図174にとまり木CH送信電力値の構成を示す。
図175にロングコード位相差の構成を示す。図175において、「ロングコード位相差」は、待ち受け中のセクタまたは通信中のセクタと、周辺セクタ(ハンドオーバ先セクタ)とのロングコード位相の差で示し、DHO、発着信の他ゾーン選択時に使用される。なお、128[chip]を越える場合は、拡張ビット(値“1”で拡張)で拡張する。
図176にRBC ID数の構成を示す。図176において、「RBC ID数」はバイナリ表示され、1〜Nの値をとる。
図177にRBC IDの構成を示す。図177において、「RBC_ID」は、CCプロトコル上で「CR+CONN_ID」で識別されるコネクションと、1対1に対応するRBCのコネクションを識別する番号(1〜H)である。
図178に所要SIRの構成を示す。
図179にFER測定値の構成を示す。
次に、TAC情報要素のフォーマットについて説明する。
(2.5.2.4.3.5.1):TAC(Terminal Association Control)メッセージフォーマット概要
(a)protocol discriminator(プロトコル識別子)
(b)Message type(メッセージ種別)
(c)メッセージ固有パラメータ(必要な場合)
(d)基本情報要素(必要な場合)
(e)拡張情報要素(必要な場合)
まず、protocol discriminatorについて説明する。
protocol discriminatorは、本システム内で定義される他のメッセージから、TACメッセージを識別する目的で設けられており、他のITU−T勧告/TTC標準および他の標準によりコード化されるOSIネットワークレイヤプロトコルユニットのメッセージから、TACメッセージを識別する。このprotocol discriminatorは、各メッセージの1番目に配置され、図181に示すようにコード化される。なお、図181は、Protocol discriminatorを説明するための図である。
次に、Message typeについて説明する。Message typeは、送出されるメッセージの機能を識別する目的で設けられている。このMessage typeは、各メッセージの2番目に配置され、図182や図680に示すようにコード化される。なお、図182および図680はMessage typeのフォーマットを示す図である。
メッセージ固有パラメータは、そのメッセージ特有の情報を設定するために使用されるものであり、以下、詳細に説明する。
(2.5.2.4.3.5.4.1):TACメッセージ固有パラメータ
まず、TACメッセージ固有パラメータ名一覧を図681に示す。
TERMINAL ASSOCIATION SETUP message specific parameter情報要素は、図183および図682に示すようにコード化される。
また、TERMINAL ASSOCIATION RELEASE message specific parameter情報要素は、図185および図684に示すようにコード化される。
次に、TACメッセージ固有パラメータのサブフィールドについて説明する。(1)コーディング規定
(a)整数値が2オクテット以上にまたがってコーディングされる場合には、より小さいオクテット番号を持つオクテットがより上位のビットを含む。特に、一番小さいオクテット番号のオクテットがMSBで、一番大きなオクテット番号のオクテットがLSBを含む。
(b)1オクテット内あるいはオクテットの一部分を形成するフィールドについては、以下のことを適用する。
・より大きいビット番号のビットが、より上位のビットを含む。
・特に、整数コーディングの最大ビット番号のビットがMSBを示している。
・特に、整数コーディングの最小ビット番号のビットがLSBを示している。
・ビットのコーディングは、小さいビット番号に詰めて(右詰めで)行われる。
つまり、先行する0の部分は、フィールドの大きいビット番号の側(左側)に現れる。
(c)固定長オクテットに整数値を表現する場合、ビットのコーディングは、大きいオクテット番号に詰めて行われる。つまり先行する0の部分は、小さいオクテット番号の側に現れる。
(d)可変長オクテット整数値を表現する場合には、最小のオクテット数になるようにコーディングする。つまり、先行する内容が全て“0”のオクテットは存在しない。
次に、Causeについて説明する。Cause情報要素は、TERMINAL ASSOCIATION解放時の理由を示すために使用されるものであり、図186および図686に示すようにコード化される。
次に、Mobile station typeについて説明する。Mobile station type情報要素は、移動局の種別を識別するために使用されるものであり、図187および図687に示すようにコード化される。
次に、Paged MS IDについて説明する。Paged MS ID情報要素は、呼出移動局を識別するために使用されるものであり、図188および図688に示すようにコード化される。
次に、Paging IDについて説明する。Paging ID情報要素は、移動局呼出時に呼を管理するために使用されるものであり、移動局一斉呼出時に、一時的に割り当てられる番号である。このPaging ID情報要素は、図189に示すようにコード化される。
次に、TMUIについて説明する。TMUI情報要素は、移動局を識別するために使用されるものであり、位置登録、位置更新時に更新される番号である。このTMUI情報要素は、図190および図689に示すようにコード化される。
次に、拡張情報要素について説明する。TAC拡張情報要素は、本システムでは使用されておらず、将来の拡張のために使用される。このTAC拡張情報要素は、図191に示すようにコード化される。
ここでは、RACH,FACH,BCCH及びPCHレイヤ3メッセージについて規定する。
(2.5.2.4.3.6.1):メッセージ種別
図192にメッセージ種別情報要素の構成を示す。
情報要素長情報要素は、メッセージの情報要素長を設定するものであり、その構成を図193に示す。
とまり木受信SIR情報要素は、MSで測定したとまり木の受信SIRを設定するものであり、その構成を図194に示す。
ショートコード番号情報要素は、上下のSDCCH用のショートコード番号(0〜2047)を設定するものであり、その構成を図195に示す。
フレームオフセット群情報要素は、SDCCH用のフレームオフセット群を設定するものであり、その構成を図196に示す。
スロットオフセット群情報要素は、SDCCH用のスロットオフセット群を設定するものであり、その構成を図197に示す。
網番号情報要素の構成を図198に示す。
ネットワークのVER情報要素は、ネットワークのVERを示すものであり、その構成を図199に示す。
移動局共通パラメータVER情報要素は、移動局共通パラメータのVERを示すものであり、その構成を図200に示す。
BTS番号情報要素は、BTSの識別番号を示すものであり、その構成を図201に示す。
セクタ番号情報要素は、BTS内のセクタ番号(例えば1〜6、あるいは1〜12)を示すものであり、その構成を図202に示す。
位置登録エリア多重数(N)情報要素は、無線ゾーンに多重されている位置登録エリア多重数を表すものであり、その構成を図203に示す。
位置番号情報要素は、移動局が在圏する位置登録エリア(0〜255)を表すものであり、その構成を図204に示す。
位置登録タイマ情報要素の構成を図205に示す。
補正後基地局所要受信電力値情報要素の構成を図206に示す。
将来(FFS)において、RACH、SDCCHの上りロングコード番号を設定するものである。
とまり木LC番号は、将来において使用されるものである(FFS)。
基地局使用周波数帯域数(K)情報要素は、本セクタでTCHの存在する周波数帯域の数を設定するものであり、その構成を図208に示す。
周波数帯域情報要素は、TCHで使用している周波数帯域を設定するものであり、その構成を図209に示す。
規制情報情報要素は、工事中規制、故障規制及びアクセス規制を移動局に対して表示するものであり、将来において使用される(FFS)。
呼受付情報情報要素は、新たな呼を受付可能かどうかの状態を移動局に対して表示するものであり、将来において使用される(FFS)。
BCCH受信区間長情報要素は、本情報要素を含むメッセージを受信後、移動局がBCCHを受信すべき期間を示すものであり、その構成を図210に示す。
呼び出し移動局数情報要素は、1呼出メッセージに含まれる呼び出し移動局数(1〜2)を表すものであり、その構成を図211に示す。
Paged MS ID情報要素は、IMUIまたはTMUIを設定する112ビットの情報要素であり、その構成を図212に示す。なお、詳細なコーディングについては、将来において決定される(FFS)。
Paging ID情報要素の構成を図213に示す。
なお、他の拡張情報要素については、将来において決定される(FFS)。
次に、BTS−MCC間インタフェース仕様について説明する。
(2.5.3.1):概要
まず、概要について説明する。2.5.3章では、BTS−BCC間インタフェースにおけるレイヤ1からレイヤ3までの各プロトコルを規定する。
レイヤ1は、基地局伝送路インタフェースおよび交換局伝送路インタフェースにおいて規定されるものであるので、ここでは、説明を省略する。
上述と同様にATMレイヤは、基地局伝送路インタフェースおよび交換局伝送路インタフェースにおいて規定されるものであるので、ここでは、説明を省略する。
上述と同様にAAL共通部は、基地局伝送路インタフェースおよび交換局伝送路インタフェースにおいて規定されるものであるので、ここでは、説明を省略する。
上述と同様にAAL個別部は、基地局伝送路インタフェースおよび交換局伝送路インタフェースにおいて規定されるものであるので、ここでは、説明を省略する。
以下、レイヤ3について説明する。
まず、本インタフェースにおけるレイヤ3プロトコルアーキテクチャについて説明する。
まず、本システムにおいて定義されているLayer3プロトコル制御エンティティについて述べる。
(1)BTS−MCC間リンク制御手順
・SCMF−TACF/SACF間SDCCH用リンク設定、解放手順
・TACF−BCFr間アクセスリンク設定、解放手順等
(2)Paging手順
・TACFからのPagingをBTSに通知する手順
(3)無線状態管理手順
・RFTR−RRC間での無線チャネル状態測定手順(但し、本手順は、本システムでは使用しない。)
(4)その他のBTSへの情報転送等の手順
(a)BC(Bearer Control:ベアラ制御):TACF〜BCFr間のリンク制御のためのメッセージの形成及び転送を行う。すなわち、上記の手順(1)を扱う。
(b)BSM(BaseStation Management:基地局管理):BTSへのPaging通知、その他のBTS管理のためのメッセージの形成及び転送を行う。上記の手順(2)、(4)を扱う。
(c)RCM(Radio Condition Management:無線状態管理):無線資源の状態測定のためのメッセージの形成及び転送を行う。なお、本プロトコル制御エンティティは、本システムでは使用していない。
次に、メッセージフォーマットについて説明する。
(2.5.3.6.2.1):BCメッセージ
まず、BCメッセージについて説明する。
まず、BCメッセージのメッセージType(種別)一覧を図690に示す。この図に示すように、BCメッセージとして、ベアラ設定メッセージ、ベアラ解放メッセージ、およびその他のメッセージが用意されている。
本システムでは、BCプロトコルのメッセージを以下のように分類している。・TCHまたはSDCCHのためのAALタイプ2リンクの設定/解放のためのメッセージ
・ACCHのためのAALタイプ2リンクの設定/解放に関する要求、及びBTS内における無線チャネルの制御のための要求は、上記メッセージ中の情報要素として含まれる。あるいは、それらの要求と同時にTCH/SDCCH用AALタイプ2リンクの制御が行われない場合には、BCプロトコルエンティティの状態遷移に関係しないメッセージを定義し、本メッセージ中の情報要素として送受する。
このようなルールに基づいたBCメッセージ分類を図691に示す。
各メッセージは、メッセージ共通部と基本情報要素(オプション)とからなる。ここで、図215にメッセージ構成を示す。なお、手順に応じたパラメータが基本情報要素として設定されるので、手順によってメッセージ内に含まれる基本情報要素は異なる。
まず、メッセージ名がLINK SETUP REQUESTEDのメッセージについて説明する。本メッセージは、SDCCH確立開始時、BTSでショートコード及び無線設備を選択した後に、前述のリソースに対応するショートセルコネクションを選択するためにBTSよりMSCNW(BSC機能)に送出される。本メッセージの各情報要素の情報長等について図692に示す。なお、本メッセージのプロトコル識別子はBC、コネクション識別はBTS〜MSCNW(BSC機能)間制御信号、方向はBTS(SCMF)→MSCNW(BSC機能)(SACF/TACF)である。
次に、メッセージ名がLINK SETUP PROCEEDINGのメッセージについて説明する。本メッセージは、第1Call、第2Call、HHO時の無線リソースの選択結果および無線設備の起動結果を通知するためにBTSよりMSCNW(BSC機能)に送出される。本メッセージの各情報要素の情報長等について図694に示す。なお、本メッセージのプロトコル識別子はBC、コネクション識別はBTS〜MSCNW(BSC機能)間制御信号、方向はBTS(BCFr)→MSCNW(BSC機能)(TACF)である。
次に、メッセージ名がLINK SETUP RESPONSEのメッセージについて説明する。本メッセージは、第1Call、第2Call、HHO時の第一無線ブランチであれば無線ベアラの設定が完了したことを通知するために、第2Call、DHO時であれば無線リソースの選択結果および無線設備の起動結果を通知するためにBTSよりMSCNW(BSC機能)に送出される。また、SDCCH確立時の基地局における同期確立結果を通知するためにBTSよりMSCNW(BSC機能)に送出される。本メッセージの各情報要素の情報長等について図695に示す。なお、本メッセージのプロトコル識別子はBC、コネクション識別はBTS〜MSCNW(BSC機能)間制御信号、方向はBTS(BCFr)→MSCNW(BSC機能)(TACF)とBTS(SCMF)→MSCNW(BSC機能)(SACF/TACF)である。
次に、メッセージ名がLINK FACILITYのメッセージについて説明する。本メッセージは、セル内HOSHO時に無線リソース及び無線設備の追加起動/削除起動を要求するために、またはACCH切替起動するためにMSCNW(BSC機能)よりBTSに送出される。本メッセージの各情報要素の情報長等について図696に示す。なお、本メッセージのプロトコル識別子はBC、コネクション識別はBTS〜MSCNW(BSC機能)間制御信号、方向はMSCNW(BSC機能)(TACF)→BTS(BCFr)である。
次に、メッセージ名がLINK FACILITYのメッセージについて説明する。なお、本メッセージは前述のLINK FACILITYとは方向が違う。本メッセージは、セル内HOSHO時に無線リソース及び無線設備の追加起動結果/削除起動結果を通知するため、またはACCH切替起動結果、スケルチを通知するためにBTSよりMSCNW(BSC機能)に送出される。本メッセージの各情報要素の情報長等について図697に示す。なお、本メッセージのプロトコル識別子はBC、コネクション識別はBTS〜MSCNW(BSC機能)間制御信号、方向はBTS(BCFr)→MSCNW(BSC機能)(TACF)である。
次に、メッセージ名がLINK RELEASEのメッセージについて説明する。本メッセージは、無線ベアラを解放するためにMSCNW(BSC機能)よりBTSに送出される。本メッセージの各情報要素の情報長等について図698に示す。なお、本メッセージのプロトコル識別子はBC、コネクション識別はBTS−MSCNW(BSC機能)間の制御信号、方向はMSCNW(BSC機能)(TACF)→BTS(BCFr)とMSCNW(BSC機能)(SACF/TACF)→BTS(SCMF)である。
次に、メッセージ名がLINK RELEASE COMPLETEのメッセージについて説明する。本メッセージは、メッセージを送信する装置がLINK REFERENCEおよびCONNECTION IDENTIFIER(コネクション識別子)を解放したことを示すために、BTSもしくはMSCNW(BSC機能)から送信される。本メッセージを受信した装置はLINK REFERENCEを解放しなければならない。本メッセージの各情報要素の情報長等について図699に示す。なお、本メッセージのプロトコル識別子はBC、コネクション識別はBTS−MSCNW(BSC機能)間の制御信号、方向はBTS(BCFr)→MSCNW(BSC機能)(TACF)とBTS(SCMF)←MSCNW(BSC機能)(SACF/TACF)である。
なお、本メッセージが最初のLINK REFERENCE解放メッセージである場合には、本情報要素は必須である。また、エラー処理条件の結果として本メッセージが送信される場合も本情報要素は本メッセージに含まれる。
次に、BSMメッセージフォーマットについて説明する。
ここでは、まず、メッセージ構成について説明する。各メッセージは、図216に示すように、プロトコル識別子、メッセージ種別、基本情報要素から構成される。
ここで、メッセージ名がPAGINGのメッセージについて説明する。本メッセージは、MSに対して着信呼び出しを行うためにNW(BSC機能)よりBTSに送出される。本メッセージの各情報要素の情報長等について図708に示す
。なお、本メッセージのプロトコル識別子はBSM、コネクション識別はBTS〜NW(BSC機能)制御信号、方向はNW(BSC機能)(TACF)→BTS(BCFr)である。
なお、「位置番号」はBTS内で位置番号を複数設定する場合に必要となり、多層位置登録制御がこれに該当する。また、情報要素の規定上では、IMUI/TMUIをPaged MS IDに統合している。本システムにおいては、必須となっている。
次に、情報要素について説明する。
(2.5.3.6.2.3.1):BC情報要素
まず、BC情報要素について説明する。
(2.5.3.6.2.3.1.1):情報要素基本構成
まず、図218に情報要素基本構成を示す。
次に、LINK ID基本情報要素の情報長等について図709に示す。本基本情報要素は、LINK SETUP、LINK RELEASEメッセージを使用し、その方向はNW(BSC機能)(SACF/TACF)→BTS(SCMF/BCFr)である。
次に、本周波数無指定型TCH設定要求情報要素の情報長等について図710に示す。本基本情報要素は、LINK SETUPメッセージを使用し、その方向はNW(BSC機能)(TACF)→BTS(BCFr)である。
次に、本周波数無指定型TCH設定要求情報要素の情報長等について図711に示す。本基本情報要素は、LINK SETUPメッセージを使用し、その方向はNW(BSC機能)(TACF)→BTS(BCFr)である。
次に、本周波数無指定型TCH設定要求情報要素の情報長等について図712に示す。本基本情報要素は、LINK SETUPメッセージを使用し、その方向はNW(BSC機能)(TACF)→BTS(BCFr)である。
次に、DHO追加要求情報要素の情報長等について図713に示す。本基本情報要素は、LINK SETUPメッセージを使用し、その方向はNW(BSC機能)(TACF)→BTS(BCFr)である。
次に、INTRA BS DHO追加要求情報要素の情報長等について図714に示す。本基本情報要素は、LINK SETUP、LINK FACILITY(NW(BSC機能)→BTS)メッセージを使用し、その方向はNW(BSC機能)(TACF)→BTS(BCFr)である。
次に、ACCH設定要求情報要素の情報長等について図715に示す。本基本情報要素は、LINK SETUP、LINK FACILITY(NW(BSC機能)→BTS)メッセージを使用し、その方向はNW(BSC機能)(TACF)→BTS(BCFr)である。
次に、本周波数無指定型TCH設定受付情報要素の情報長等について図716に示す。本基本情報要素は、LINK SETUP PROCEEDINGメッセージを使用し、その方向はBTS(BCFr)→NW(BSC機能)(TACF)である。
次に、本周波数無指定型TCH設定受付情報要素の情報長等について図717に示す。本基本情報要素は、LINK SETUP PROCEEDINGメッセージを使用し、その方向はBTS(BCFr)→NW(BSC機能)(TACF)である。
次に、本周波数無指定型TCH設定受付情報要素の情報長等について図718に示す。本基本情報要素は、LINK SETUP PROCEEDINGメッセージを使用し、その方向はBTS(BCFr)→NW(BSC機能)(TACF)である。
次に、本周波数無指定型TCH設定応答情報要素の情報長等について図719に示す。本基本情報要素は、LINK SETUP RESPONSEメッセージを使用し、その方向はBTS(BCFr)→NW(BSC機能)(TACF)である。
次に、本周波数無指定型TCH設定応答情報要素の情報長等について図720に示す。本基本情報要素は、LINK SETUP RESPONSEメッセージを使用し、その方向はBTS(BCFr)→NW(BSC機能)(TACF)である。
次に、本周波数無指定型TCH設定応答情報要素の情報長等について図721に示す。本基本情報要素は、LINK SETUP RESPONSEメッセージを使用し、その方向はBTS(BCFr)→NW(BSC機能)(TACF)である。
次に、本DHO追加設定応答情報要素の情報長等について図722に示す。本基本情報要素は、LINK SETUP RESPONSEメッセージを使用し、その方向はBTS(BCFr)→NW(BSC機能)(TACF)である。
次に、本INTRA BS DHO追加設定応答情報要素の情報長等について図723に示す。本基本情報要素は、LINK SETUP RESPONSE、LINK FACILITYメッセージを使用し、その方向はBTS(BCFr)→NW(BSC機能)(TACF)である。
次に、本ACCH設定応答情報要素の情報長等について図724に示す。本基本情報要素は、LINK SETUP RESPONSE、LINK FACILITYメッセージを使用し、その方向はBTS(BCFr)→MSCNW(BSC機能)(TACF)である。
次に、本INTRA BS DHO追加設定要求情報要素の情報長等について図725に示す。本基本情報要素は、LINK FACILITYメッセージを使用し、その方向はNW(BSC機能)(TACF)→BTS(BCFr)である。
次に、本INTRA BS DHO削除設定要求情報要素の情報長等について図726に示す。本基本情報要素は、LINK FACILITYメッセージを使用し、その方向はNW(BSC機能)(TACF)→BTS(BCFr)である。
次に、本INTRA BS HHO設定要求情報要素の情報長等について図727に示す。本基本情報要素は、LINK FACILITYメッセージを使用し、その方向はNW(BSC機能)(TACF)→BTS(BCFr)である。
次に、本ACCH解放要求情報要素の情報長等について図728に示す。本基本情報要素は、LINK FACILITYメッセージを使用し、その方向はNW(BSC機能)(TACF)→BTS(BCFr)である。
次に、本周波数無指定型切替設定要求情報要素の情報長等について図729に示す。本基本情報要素は、LINK FACILITYメッセージを使用し、その方向はNW(BSC機能)(TACF)→BTS(BCFr)である。
次に、本周波数無指定型切替設定要求情報要素の情報長等について図730に示す。本基本情報要素は、LINK FACILITYメッセージを使用し、その方向はNW(BSC機能)(TACF)→BTS(BCFr)である。
次に、本設定完了通知情報要素の情報長等について図731に示す。本基本情報要素は、LINK FACILITYメッセージを使用し、その方向はNW(BSC機能)(TACF)→BTS(BCFr)である。
次に、本INTRA BS HHO削除設定応答情報要素の情報長等について図732に示す。本基本情報要素は、LINK FACILITYメッセージを使用し、その方向はBTS(BCFr)→NW(BSC機能)(TACF)である。
次に、本INTRA BS HHO追加設定応答情報要素の情報長等について図733に示す。本基本情報要素は、LINK FACILITYメッセージを使用し、その方向はBTS(BCFr)→NW(BSC機能)(TACF)である。
次に、本ACCH解放応答情報要素の情報長等について図734に示す。本基本情報要素は、LINK FACILITYメッセージを使用し、その方向はBTS(BCFr)→NW(BSC機能)(TACF)である。
次に、本周波数指定型切替設定応答情報要素の情報長等について図735に示す。本基本情報要素は、LINK FACILITYメッセージを使用し、その方向はBTS(BCFr)→NW(BSC機能)(TACF)である。
次に、本周波数指定型切替設定要求情報要素の情報長等について図736に示す。本基本情報要素は、LINK FACILITYメッセージを使用し、その方向はBTS(BCFr)→NW(BSC機能)(TACF)である。
次に、本周波数無指定型切替設定受付情報要素の情報長等について図737に示す。本基本情報要素は、LINK FACILITYメッセージを使用し、その方向はBTS(BCFr)→NW(BSC機能)(TACF)である。
次に、本周波数無指定型切替設定応答情報要素の情報長等について図738に示す。本基本情報要素は、LINK FACILITYメッセージを使用し、その方向はBTS(BCFr)→NW(BSC機能)(TACF)である。
次に、本コード切替要求情報要素の情報長等について図739に示す。本基本情報要素は、LINK FACILITYメッセージを使用し、その方向はBTS(BCFr)→NW(BSC機能)(TACF)である。
次に、本TCH解放要求情報要素の情報長等について図740に示す。本基本情報要素は、LINK RELEASEメッセージを使用し、その方向はNW(BSC機能)(TACF)→BTS(BCFr)である。
次に、本SDCCH解放要求情報要素の情報長等について図741に示す。本基本情報要素は、LINK RELEASEメッセージを使用し、その方向はNW(BSC機能)(SACF/TACF)→BTS(BCMF)である。
次に、本CAUSEの情報長等について図742に示す。本基本情報要素は、LINK RELEASE COMPLETEメッセージを使用し、その方向はBTS(BCFr)→NW(BSC機能)(TACF)とBTS(SCMF)→NW(BSC機能)(SACF/TACF)である。
次に、本SDCCH設定要求情報要素の情報長等について図743に示す。本基本情報要素は、LINK SETUP REQUESTEDメッセージを使用し、その方向はBTS(SCMF)→NW(BSC機能)(SACF/TACF)である。
次に、本LAI設定要求情報要素の情報長等について図744に示す。本基本情報要素は、LINK SETUP REQUESTEDメッセージを使用し、その方向はBTS(SCMF)→NW(BSC機能)(SACF/TACF)である。
次に、各情報要素の定義を示す。
(2.5.3.6.2.3.1.2.1):プロトコル識別子
まず、プロトコル識別子について説明する。
プロトコル識別子は、本システム内で定義される他のメッセージから、BCメッセージを識別することを目的として設定されている。また、プロトコル識別子は、他のITU−T勧告/TTC標準および他の標準によりコード化されるOSIネットワークレイヤプロトコルユニットのメッセージから、本システム内のメッセージを識別する。
このプロトコル識別子は、各メッセージの1番目に配置され、図219および図745に示すようにコード化される。
次に、メッセージ種別について説明する。メッセージ種別は、送出されるメッセージの機能を識別することを目的として設定されている。このメッセージ種別は、各メッセージの2番目に配置され、図220および図746に示すようにコード化される。
次に、LINK REFERENCEについて説明する。LINK REFERENCEは、TCHまたはSDCCHのためのAAL TYPE2/TYPE5(AALタイプ2/タイプ5)リンク毎に生成するBCプロトコルエンティティの個々のインスタンスを識別することを目的として設定されている。このLINK REFERENCEは、図221に示すようにコード化される。
次に、情報要素識別子について説明する。情報要素識別子は、各メッセージに含まれるオプション情報要素を識別するためのものであり、図222に示すようにコード化される。
次に、情報要素長について説明する。情報要素長は、基本情報要素内に設定される全パラメータの長さを示すものであり、図223に示すようにコード化される。
まず、AAL TYPEについて説明する。AAL TYPEは、AALタイプを表すものであり、図224に示すようにコード化される。なお、ここでは、“0010”でAALタイプ2を、“0101”でAALタイプ5を表している。
次に、伝送品質について説明する。伝送品質は、ATMリンクの品質を指定するものであり、図226に示すようにコード化される。なお、本システムでは、許容遅延3ビット、セル破棄率3ビット、予約2ビットと想定している。
次に、下り伝送速度について説明する。下り伝送速度は、下りの情報転送速度を示すものである。本システムにおける下り伝送速度としては、8kbps/12.8kbps/32kbps/34.4kbps/64kbps/76.8kbps/128kbps/162.4kbps/384kbpsを想定している。
次に、上り伝送速度について説明する。上り伝送速度は、上りの情報転送速度を示すものである。本システムにおける上り伝送速度としては、8kbps/12.8kbps/32kbps/34.4kbps/64kbps/76.8kbps/128kbps/162.4kbps/384kbpsを想定している。
次に、セクタ番号について説明する。セクタ番号は、BIS内でセクタを識別する番号(1〜12)であり、図227に示すようにコード化される。
(2.5.3.6.2.3.1.2.11):情報転送能力(BEARER CAPABILITY)
(2.5.3.6.2.3.1.2.12):周波数帯域選択条件(FREQUENCY SELECTION INFO.)
次に、周波数帯域について説明する。周波数帯域情報要素は、基地局において選択された周波数帯域を示し、移動局内における同時接続コネクションは同一周波数帯域となる。この周波数帯域は、f1〜f256をとるものであり、図230に示すようにコード化される。
次に、フレームオフセット群について説明する。フレームオフセット群は、有線区間の1フレーム時間内におけるトラヒックの均一化のために、移動局が通信する際に下り無線リンクの1無線フレーム内のどのタイムスロットを論理フレームの先頭とするかを示すものであり、0〜15の値をとるものであり、図231に示すようにコード化される。
(2.5.3.6.2.3.1.2.15):スロットオフセット群(FRAME OFFSET GROUP)
次に、ロングコード位相差について説明する。ロングコード位相差は、待ち受け中のとまり木のロングコードカウンタ(SFN)より算出されるロングコードの位相、または、通信中上りロングコード位相と、周辺セクタ(ハンドオーバ先のセクタ)のとまり木のロングコードカウンタ(SFN)より算出されるロングコード位相との差分(chip)であり、DHO、発着信の他ゾーン選択時に使用される。このロングコード位相差はMSによって測定され、NW(BSC機能)へ報告される。なお、本システムでは、0〜2 −1Chipを想定しており、図233に示すようにコード化される。なお、ロングコードの位相差が128Chipを越える場合には、拡張ビットによって拡張して対応する。
(2.5.3.6.2.3.1.2.17):上りロングコード番号(LONG CODE NUMBER(Rvs))
次に、上りショートコード種別について説明する。上りショートコード種別は図235に示すようにコード化される。
次に、上りコード数について説明する。上りコード数は、上りマルチコード(1コネクションに対して上りCHとして複数のショートコードを使用する場合)使用時の上りショートコード数を示すものであり、図236に示すようにコード化される。
次に、上りショートコード番号について説明する。上りショートコード番号は
、上りショートコードを識別するための番号(0〜1023)であり、上りロングコード(MS)内でユニークな番号となる。なお、第1番目にはACCHが設定される。また、BTSでは、VPCI,VCI,UCI(ACCH用)が同時に指定された場合、ACCHの設定が必要であることを認識する。この上りショートコード番号は、図237に示すようにコード化される。
次に、下りショートコード種別について説明する。下りショートコード種別は図238に示すようにコード化される。
次に、下りコード数について説明する。下りコード数は、下りマルチコード(1コネクションに対して下りCHとして複数のショートコードを使用する場合)使用時の下りショートコード数を示すものであり、図239に示すようにコード化される。
まず、ACCH用のAAL TYPEについて説明する。このAAL TYPEは、AALタイプを表すものであり、AALタイプ2(“0010”)固定となっており、図240に示すようにコード化される。
次に、ACCH用のLINK IDENTIFIERのコード化例を図241に示す。なお、LINK IDENTIFIERとTCHは個別の値を使用するようにしてもよい。
次に、ACCH用の伝送品質について説明する。この伝送品質は、ATMリンクの品質を指定するものであり、図242に示すようにコード化される。なお、本システムでは、許容遅延3ビット、セル破棄率3ビット、予約2ビットと想定しており、固定値とすることも想定している。
次に、ACCH用の下り伝送速度について説明する。この下り伝送速度は、下りの情報転送速度を示すものであり、TCHで使用されるコードに制約される。本システムにおける下り伝送速度としては、8kbps/12.8kbps/32kbps/34.4kbps/64kbps/76.8kbps/128kbps/162.4kbps/384kbpsを想定している。
次に、ACCH用の上り伝送速度について説明する。この上り伝送速度は、上りの情報転送速度を示すものであり、TCHで使用されるコードに制約される。本システムにおける上り伝送速度としては、8kbps/12.8kbps/32kbps/34.4kbps/64kbps/76.8kbps/128kbps/162.4kbps/384kbpsを想定している。
次に、下りショートコード番号について説明する。下りショートコード番号は
、下りショートコードを識別するための番号(0〜1023)であり、下りロングコード(MS)内でユニークな番号となる。この下りショートコード番号は、図243に示すようにコード化される。
結果は、結果(OK/NG)を設定するためのものであり、図244に示すようにコード化される。
次に、CAUSEについて説明する。LINK RELEASE COMPLETEメッセージが最初のLINK REFERENCE解放メッセージである場合は本情報要素は必須である。また、エラー処理条件の結果としてLINK RELEASE COMPLETEメッセージが送信される場合にも本情報要素が設定される。このCAUSEは、図245に示すようにコード化される。
次に、初期送信電力について説明する。初期送信電力は、下りの送信電力を指定するものであり、図246に示すようにコード化される。
次に、Location Identityについて説明する。Location Identityは、移動局が在圏する位置登録エリアを識別するために使用されるものであり、0〜255の値をとり、図247に示すようにコード化される。
次に、BSMメッセージの情報要素フォーマットについて説明する。
まず、プロトコル識別子について説明する。プロトコル識別子は、本システム内で定義される他のメッセージから、BSMメッセージを識別することを目的として設定されている。また、プロトコル識別子は、他のITU−T勧告/TTC標準および他の標準によりコード化されるOSIネットワークレイヤプロトコルユニットのメッセージから、本標準のメッセージを識別するためにも使用される。このプロトコル識別子は、各メッセージの1番目に配置され、図248および図747に示すようにコード化される。
次に、メッセージ種別について説明する。メッセージ種別は、送出されるメッセージの機能を識別することを目的として設定されている。このメッセージ種別は、各メッセージの2番目に配置され、図250および図748に示すようにコード化される。
次に、PCH群算出情報について説明する。PCH群算出情報は、BTSにおけるPCH群番号決定のための情報要素であり、例えば、IMUIのbinary表現の下位16bitとなる。すなわち、PCH群算出情報は各MSのIMUIの一部から決定されるものであり、図250に示すようにコード化される。
次に、位置番号について説明する。位置番号は、移動局が在圏する位置登録エリアを識別するための番号(0〜255)であり、図251に示すようにコード化される。
次に、Paged MS IDについて説明する。Paged MS IDは、ページングに用いられるIMUI/TMUIを統合したものであり、番号種別としてTMUIまたはIMUIが設定される。IMUIが設定される場合には、BCD形式のIMUIを変換した整数型IMUIが設定される。Paged MS IDは、図252に示すようにコード化される。
次に、オクテット4以降に設定されている番号種別を図749に示す。
次に、オクテット4以降に設定されている番号のオクテット数(番号長)を図750に示す。なお、オクテット1〜3は番号長に含まれない。
次に、TMUI情報要素について説明する。TMUIは、移動局を識別するために使用されるものである。IMUIは、位置登録、位置更新時に更新され、動的に移動局に割り当てられる番号である。なお、TMUI情報要素は4オクテット固定長である。
次に、整数型IMUIについて説明する。整数型IMUIは、移動局を識別するために使用される。IMUIは、TMUIを用いたPAGINGで網側がMSとのTMUI不一致を認識した場合の再PAGINGで使用される。整数型IMUIは、BCD形式のIMUIを整数型に変換して設定され、可変長で最大7オクテット長になる。
次に、Paging IDについて説明する。Paging IDは、移動局呼び出し時に呼を管理する為に使用されるものであり、移動局一斉呼出時に一時的に割り当てられる番号である。Paging ID情報要素は、図253に示すようにコード化される。
(2.5.3.6.4.1):SDL図(BC)
また、BSM用のSDL図を図254に示す。
本システムは、以上説明した構成およびプロトコル仕様を採用していることから、従来にない特有な制御を実施をすることができる。以下、本システムにおいて提供される特有の制御について説明する。
(3.1.1):本制御方法の導入の背景
上述したように、秘匿された信号(制御信号)の送受信を行う場合に、どのタイミングから秘匿開始が行われたのかが判らないと、秘匿解除を適切に行うことができない。この場合、秘匿解除のタイミングを誤ると、意味不明の信号を取得することになる。
図755に網から移動機に対して秘匿開始要求を通知し、秘匿開始要求通知後は、送信信号及び受信信号の双方に秘匿を実施するように構成した場合の移動機MSと網NWとの間の正常動作時の秘匿処理シーケンス図を示す。初期状態において、移動機MS及び網NWの双方において送受信信号の秘匿は行われていない(秘匿未実施)状態にあるものとする。
そして網NWは、秘匿開始要求の通知後、送受信信号の秘匿を開始することとなる(ステップS22)。
一方移動機MSは、秘匿開始要求の通知を受信すると、それ以後、送受信信号の秘匿を開始することとなり(ステップS23)、以降は送信信号及び受信信号の双方に秘匿を実施した状態で網NWとの間で通信を行うこととなっていた。
そこで、本制御方法は、秘匿開始タイミングがずれた場合でも、信号受信を行うことが可能な移動機、網及び移動通信システムを提供することを目的としている。
まず、具体的な説明に先立ち、本制御方法の概要について説明する。
図757に本実施形態の移動機MSと網NWとの間の正常動作時の秘匿処理シーケンス図を示す。初期状態において、移動機MS及び網NWの双方において送受信信号の秘匿は行われていない(秘匿未実施)状態にあるものとする。
そして網NWは、秘匿開始要求の通知後、送信信号(下り信号)の秘匿を開始することとなる(ステップS32)。
一方、移動機MSは、秘匿開始要求の通知を受信すると、それ以後、受信信号の秘匿を開始することとなり(ステップS33)、以降は受信信号に秘匿を実施した状態で網NWとの間で通信を行う。
そして、移動機MSは、秘匿開始応答の通知後、送信信号(上り信号)の秘匿を開始する(ステップS35)。
つぎにより具体的な動作を図63〜図65を参照して説明する。
図64は、秘匿開始を説明するための機能モデルを示したものである。図に示すように、移動端末(Mobil Terminal)には、UIMF、MCFおよびTACAFが設けられている。UIMFは、移動ユーザに関する情報を保持し、ユーザ認証および秘匿演算を提供する。また、MCFは、非呼関連のサービスにおける網とのインタフェースである。TACAFは、発信,ページングの検出等の移動機端末へのアクセスを制御する。
まず、網側のLRCFから、サイファリングの開始を指示するStart Ciphering req.indが、TACF/SACFを介して移動端末側のTACAF/MCFに通知される。これにより、移動端末は、これ以降、網から送信される信号にはサイファリングが施されることを検知することができる。このため、網側のTACF/SACFは、Start Ciphering resp.conf.を送信すると、これ以降送信する信号は、秘匿キーを用いて秘匿を施して送信するように制御を行う。そして、移動端末側で、秘匿が施された信号を受信すると、受信信号の秘匿解除制御がTACAF/MCFで行われる。なお、秘匿キーは、この処理に先立って、UIMFから取得している。これにより、網側からの送信される送信信号(下り信号)については、秘匿が確保される。
これにより、網側は、これ以降、受信する信号にはサイファリングが施されていることを検知することができる。このため、移動端末側のTACAF/MCFは、Start Ciphering req.confを送信すると、これ以降送信する信号は、秘匿キーを用いて秘匿を施す。そして、網側で、秘匿が施された信号を受信すると、受信信号の秘匿解除がTACF/SACFで制御される。これにより、移動端末側からの送信される送信信号(上り信号)については、秘匿が確保される。
(3.2.1):本制御方法の導入の背景
図759に移動通信システムにおいて固有の秘匿方式を用いて秘匿処理を行う場合の概要シーケンス図を示す。
さらに様々な網の間でローミングを行うような場合には、全ての秘匿処理を共通化しなければならないという問題点が生じることとなる。
つぎに図760ないし図762を参照して本発明の好適な実施形態について説明する。
図760に本制御方法の概要シーケンス図を示す。
まず、移動機MS側から網NW側に対して当該移動機MSで実行可能な秘匿方式の情報である秘匿方式種別の通知とともに、通信要求をなす(ステップS51)。
これにより、網NWは実際に通信を行おうとする秘匿方式種別を選択する(ステップS52)。例えば、図760では、秘匿方式種別として秘匿実施種別Aを選択している。
これにより移動機MS側では、網NWが選択した秘匿方式種別(図760では、秘匿実施種別A)に対応する設定を行う(ステップS54)。一方、網NW側でも、選択した秘匿方式種別(図760では、秘匿実施種別A)による網内装置の、設定を行う(ステップS55)。
この結果、例えば、移動機MS側で要求するセキュリティの度合いに応じ、秘匿方式種別(秘匿実施種別のみあるいは秘匿実施種別及び秘匿キー生成種別)のレベルを選択し、秘匿を実施することが可能となった。
さらに将来的なシステムの拡張時に、新サービスなどを考慮して秘匿を高度化する必要性が生まれた場合に新たな秘匿方式種別の導入が行い易い。
さらにまた、複数の網間で最低限共通な秘匿方式種別をサポートしておけば、ローミング時に全ての秘匿方式種別を共通化しなくても秘匿を実施した通信を行うことが可能となるとともに、共通化した秘匿方式種別以外に網内では独自の秘匿方式種別を用いた秘匿を実行することが可能となる。
つぎにより具体的な動作について、図761及び図762のシーケンス図を参照して説明する。以下の説明においては、秘匿方式種別として、秘匿実施種別及び秘匿キー生成種別の双方を選択する場合について説明する。なお、図761および図762においては、説明の簡略化のため、秘匿に関係するパラメータのみを記述し、認証に必要なパラメータについては図示を省略している。
そして移動機MSのセキュリティ制御部は、網NWのセキュリティ制御部に対し、秘匿方式種別としての秘匿実施種別(A、B、C)及び秘匿キー生成種別(X、Y、Z)並びに優先順位情報を通信設定要求として通知する(ステップS62)。
これにより網NWのセキュリティ制御部は、秘匿実施種別(A、B、C)を記憶する(ステップS63)。
これによりユーザ情報制御部は乱数を生成する(ステップS65)。
そしてステップS65で生成した乱数及びステップS66で選択した秘匿キー生成種別(図761では、秘匿キー生成種別=X)に基づいて、秘匿キーを生成する(ステップS67)。
続いて、網NWのユーザ情報制御部は、生成した乱数、生成した秘匿キー及び選択した秘匿キー生成種別(=X)を認証情報としてセキュリティ制御部に通知する(ステップS68)。
この結果、移動機MSのユーザ情報制御部は、通知された乱数及び選択した秘匿キー生成種別(=X)に基づいて秘匿キーを生成する(ステップS72)。
そして生成した秘匿キーを認証演算応答に含めてセキュリティ制御部に通知する(ステップS74)。
この結果、網NWのセキュリティ制御部は、ステップS69で記憶した秘匿キー及びステップS63で記憶した秘匿実施種別(=A、B、C)の通知とともに、網NW側の無線アクセス制御部に対して秘匿実施要求を行う(ステップS79)。
これにより網NW側の無線アクセス制御部は、通知された秘匿実施種別の中から一つの秘匿実施種別を決定する(ステップS80:図D3では、秘匿実施種別Bに決定)。
この結果、移動機MS側の無線アクセス制御部は、通知された秘匿実施種別(=B)を記憶する(ステップS82)。
そして移動機MSの無線アクセス制御部は、移動機MSのセキュリティ制御部に対し、ステップS75で記憶した秘匿キーの読出を要求する(ステップS83)。
移動機MSのセキュリティ制御部は、記憶していた秘匿キーを無線アクセス制御部に通知する(ステップS84)。
一方、秘匿実施応答を受け取った網NW側の無線アクセス制御部も以降は、秘匿を実施した通信を行うこととなる(ステップS87)。
また、移動機MS側あるいは網NW側で通信サービスが提供するマルチメディアサービス(音声、動画像)に即した秘匿方式種別を選択し、秘匿を実施することも可能となる。
さらに将来的な移動通信システムの拡張時に、新サービスなどを考慮して秘匿を高度化する必要性が生まれた場合にも新たな秘匿方式種別の導入が行い易くなる。
さらにまた、複数の網間で最低限共通な秘匿方式種別をサポートしておけば、ローミング時に全ての秘匿方式種別を共通化しなくても秘匿を実施した通信を行うことが可能となるとともに、共通化した秘匿方式種別以外に網内では独自の秘匿方式種別に対応する秘匿を実行することが可能となる。
(3.3.1):本制御方法の導入の背景
本来、アクセスリンクの設定とダイバーシチハンドオーバの開始は別の手続である。従って、ある移動局が通信を行う場合、その移動局についてアクセスリンクの設定が行われた後、その後、当該移動局の移動等によりダイバーシチハンドオーバを開始すべき状態となった場合にダイバーシチハンドオーバが開始されるのがこれまでの一般的な方法であった。
本制御方法は、以上の問題を解決すべく導入された方法である。
本システムでは、移動局に発呼または着呼が発生し、当該移動局に対してアクセスリンクの設定をしようとするとき、移動局がダイバーシチハンドオーバが可能な状態にある場合には、網側では移動局に対してアクセスリンクを設定すると同時に移動局がダイバーシチハンドオーバを開始できる状態とし、移動局はアクセスリンクの設定と同時にダイバーシチハンドオーバを開始する。すなわち、発呼または着呼を契機として、メインブランチの他、ダイバーシチハンドオーバを行うためのサブブランチをも設定し、移動局の通信開始当初からダイバーシチハンドオーバを開始するものである。図768(a)は本システムにおいて移動局10に対してアクセスリンクが設定されると同時に基地局内ダイバーシチハンドオーバが開始される様子を示すものであり、図768(b)はアクセスリンクが設定されると同時に基地局間ダイバーシチハンドオーバが開始される様子を示している。
図769は移動局10が図768(a)に示す状態となっているときに移動局10に発呼または着呼が発生してアクセスリンクの設定が行われる場合の動作を示すシーケンス図である。
既に説明したように、移動局は常に周辺ゾーンの止まり木チャネルの受信レベルの監視を行っている。従って、図768(a)における移動局10は、無線ゾーン11に在圏している場合には、当該ソーンに隣接する無線ゾーン12の止まり木チャネルの受信レベルの監視を行っている。
また、INTRA BCFr HANDOVER BRANCH ADDITION resp.conf.は、自局内ダイバーシチハンドオーバを行うための無線アクセスリンク41の追加設定を完了した旨の報告であり、その内容は図435に示す通りである。
以上により、移動局10に対するアクセスリンクの設定およびダイバーシチハンドオーバへの移行が終了する。
図770は移動局10が図768(b)に示す状態となっているときに移動局10に対するアクセスリンクの設定が行われる場合の動作を示すシーケンス図である。
図768(b)に示すように、移動局10がダイバーシチハンドオーバゾーン13に進入したときに、移動局10から発呼が行われ、基地局制御装置30では移動局10に対するアクセスリンクの設定要求とダイバーシチハンドオーバへの移行要求とが同時に発生される。そして、これらの要求の発生に伴い、以下の手続が進めれれる。
このメッセージは、無線アクセスリンク41(後に同期確立を行うメインブランチ)および無線アクセスリンク44(ダイバーシチハンドオーバのためメインブランチに追加されるサブブランチ)の両方の設定を要求するものである。
以上により、移動局10に対するアクセスリンクの設定およびダイバーシチハンドオーバへの移行が終了する。
(3.3.3.1):移動局の動作
図786は、前掲図770において、基地局制御装置のTACFaから移動局のTACAFaにHANDOVER BRANCH ADDITION req.ind.およびRADIO BEARER SETUP req.ind.の両方の内容を含むメッセージが送信された後の詳細な動作を示すものである。
そして、受信信号中においてサブブランチの設定をすべきサブブランチ情報がなくなった場合には、信号受信待ちの状態に戻る。
なお、参考のため、従来のアクセスリンク設定後の移動局の動作を図788に、移動局の制御フローを図789に示す。
既に図769を参照して説明したように、本システムでは、アクセスリンクの設定と同時に基地局内ダイバーシチハンドオーバへの移行を行う場合には、BEARER&RADIO BEARER SETUP req.ind.およびINTRA−BCFr HANDOVER BRANCH ADDITION req.ind.の両方の内容を含んだメッセージが基地局へ送られる。
本システムにおける基地局は、このメッセージに含まれた複数のブランチ情報を全て読み出し、各ブランチ情報に従って各ブランチの設定を行う。具体的な制御フローは、移動局の場合の制御フロー(図787)と同様であるので説明を省略する。
(3.4.1):本制御方法の導入の背景
移動局が在圏している無線ゾーンから出て、それまで在圏していた無線ゾーンにおいて使用していた周波数帯域と異なる隣接無線ゾーンに移動するとき、ブランチ切替が実施される。また、ある無線ゾーンに移動局が在圏しており、このとき通信品質が劣化した場合に、その無線ゾーン内において当該移動局の通信周波数を他の周波数帯域に切り替える場合にもブランチ切替が実施される。
本制御方法は、以上の問題を解決すべく導入された方法である。
本システムでは、ブランチ切替の契機が発生したとき、ダイバーシチハンドオーバへの移行が可能である場合には、契機発生前のブランチ構成からダイバーシチハンドオーバを行うためのブランチ構成へ直接切り替える。
図771において、移動局がセル2および3がオーバラップしたダイバーシチハンドオーバゾーンへ進入したとき、セル2および3がダイバーシチハンドオーバの候補として網側へ通知され、これらの候補が網側に認められたとする。
このメッセージは、移動局に対し、セル1に対応したブランチ(周波数f1)からセル2に対応したブランチ(周波数f2;メインブランチ)への切替を要求するとともに、新たなセル3に対応したブランチ(周波数f2;サブブランチ)の設定を行うことを要求するものである。
以上、ブランチ切替後に移動局が基地局間ダイバーシチハンドオーバへの移行が可能な場合(図771)を例に本システムの動作を説明したが、ブランチ切替後に移動局が基地局内ダイバーシチハンドオーバへの移行が可能な場合も基本的に同様な動作が行われる。
ただし、この場合には、基地局制御装置から基地局内ダイバーシチハンドオーバに使用される基地局に対し、ブランチ切り替えを指令する情報とダイバーシチハンドオーバのためのブランチ追加を指令する情報とを含んだ1つのメッセージが送られることとなる。
(3.4.3.1):移動局の動作
既に説明したように、本システムでは、ブランチ切替と同時にダイバーシチハンドオーバへの移行を行う場合には、ブランチ切り替えの指令とダイバーシチハンドオーバのためのサブブランチの追加の指令の両方を含んだメッセージが移動局へ送られる。
既に説明したように、本システムでは、ブランチ切替と同時に基地局内ダイバーシチハンドオーバへの移行を行う場合に、ブランチ切り替えの指令とダイバーシチハンドオーバのためのサブブランチの追加の指令の両方を含んだメッセージが当該基地局へ送られる。
従って、基地局は、網側からのメッセージにブランチ切り替えの指令とダイバーシチハンドオーバのためのサブブランチの追加の指令の両方が含まれている場合には、ブランチ切り替えを行い、さらにダイバーシチハンドオーバの追加設定を行う。
1台で複数の呼に対応した通信を同時に行うことができる移動局装置が提供されている。
従来の技術の下で、この種の移動局においては、各呼に対応した通信のブランチ構成や周波数帯域を同じにする手段が講じられていなかったため、複数呼に対応した通信を行っている場合にブランチ構成や周波数帯域が呼毎に区々となることがあった。このため、呼毎に移動局のハンドオーバ制御や送信電力制御を行う必要があり、網側のオーバヘッドに関する負担が過大であるという問題があった。
本制御方法は、かかる問題を解決すべく導入されたものである。
図774(a)において、BTS1およびBTS2は周波数f1の無線ゾーンを形成している。MSは、BTS1およびBTS2を使用したダイバーシチハンドオーバを行うことにより、call−1に対応した通信を行っている。
この状態において、例えばMSからの発呼等の要因により、MSにおいて新たな呼が発生したとする。
すなわち、図774(a)に示す例では、既存呼call−1に対応した通信は、周波数帯域f1を使用し、かつ、BTS1およびBTS2を経由するダイバーシテイハンドオーバブランチを使用して行われている。従って、MSに新規呼call−2が発生した場合には、図774(b)に示すように、この新規呼call−2に対応した通信も、周波数帯域f1を使用し、かつ、BTS1およびBTS2を経由するダイバーシテイハンドオーバブランチを使用して行われるのである。
図775において、TACAFaは図774(a)および(b)におけるMSの機能エンティティである。TACFaは、基地局制御装置内の機能エンティティであり、MSが通信を開始したときに最初に生成されたものである。また、TACFv1およびTACFv2は、MSの在圏先であるBTS1およびBTS2を制御するための基地局制御装置内の各機能エンティティ、BCFr1およびBCFr2は、MSの在圏先であるBTS1およびBTS2が有している各々の無線リソース制御のための機能エンティティある。
図774(a)に示すようにMSがBTS1およびBTS2を使用したダイバーシチハンドオーバを行ってcall−1の通信を行っているときに、新たな別のcall−2がMSに生じると、基地局制御装置のTACFaは、新規呼call−2に対応したアクセスリンクの設定要求並びに新規呼call−2のブランチ構成を既存呼call−1と同じダイバーシチハンドオーバブランチとすべき旨の要求が発生される。そして、これらの要求の発生に伴い、以下の手続が進められる。
また、HANDOVER BRANCH ADDITION req.ind.は、ダイバーシチハンドオーバを行うためのサブブランチ(ここではBTS2経由のブランチ)の設定を要求するものである。
このメッセージは、BTS1経由の無線アクセスリンク(メインブランチ)およびBTS2経由の無線アクセスリンク(サブブランチ)を新規呼call−2のために設定することをMSに要求するものである。
これにより、MSは、既存呼call−1および新規呼call−2の両方について、BTS1および2を経由したダイバーシチハンドオーバブランチを使用し、かつ、周波数f1を使用して通信を行うこととなる。
上記(3.5)の制御方法では、移動局の通信中に新たな呼が発生した場合に、新規呼の通信のブランチ構成および周波数帯域を既存呼のものに合わせる制御を行った。
しかし、新規呼が発生したときに、既存呼の通信のブランチ構成における一部のブランチの通信が混雑していたり、あるいは既存呼の通信に使用している周波数帯域が混雑している等の理由により、既存呼のブランチ構成や周波数帯域と同一のブランチ構成や周波数帯域を新規呼に割り当てることができない場合がある。このような場合には新規呼が受け付けられず、呼損が生じることとなる。
本制御方法は、かかる問題を解決すべく導入されたものである。
本制御方法では、複数呼の通信が可能な移動局が通信を行っているときに新規呼が発生し、かつ、通信容量の不足等の理由により新規呼の通信のブランチ構成および周波数帯域を既存呼のものに合わせることができない場合に、新規呼を設定するときに、既存呼および新規呼を含んだ全ての呼の通信を維持することができるブランチ構成および周波数帯域を選択し、既存呼のブランチ構成および周波数帯域をこの選択したブランチ構成および周波数帯域に変更する。
図776(a)において、MSは、BTS1との間に設定された周波数f1のブランチを使用し、call−1の通信を行っている。
この状態において、MSからの発呼により新規呼call−2が発生したが、BTS1には新規呼call−2に割り当てることができる通信容量が残っていない。
図777(a)において、MSは、BTS1との間に設定された周波数f1のブランチを使用し、call−1の通信を行っている。この状態において、MSからの発呼により新規呼call−2が発生したが、BTS1には新規呼call−2に割り当てることができる通信容量が残っていない。
図778において、TACAFaは図776(a)および(b)におけるMSの機能エンティティである。TACFaは基地局制御装置内の機能エンティティであり、MSが通信を開始したときに最初に生成されたものである。また、TACFv1−2は、MSの在圏先であるBTS1を制御する基地局制御装置の機能エンティティのインスタンスであって、call−1に対応したもの、TACFv2−1およびTACFv2−2は、MSの在圏先であるBTS2を制御する基地局制御装置の各機能エンティティのインスタンスであって、各々call−1およびcall−2に対応したものである。また、BCFr1−2は、MSの在圏先であるBTS1が有している無線リソース制御のための機能エンティティのインスタンスであって、call−1に対応したもの、BCFr2−1およびBCFr2−2は、MSの在圏先であるBTS2が有している無線リソース制御のための機能エンティティのインスタンスであって、call−1およびcall−2に各々対応するものである。
図776(a)に示すようにMSがBTS1を使用して呼call−1の通信を行っているときに、新たな別の呼call−2がMSに生じたとする。基地局制御装置のTACFaは、MS上に発生している既存呼Call−1によって占有されている無線リソースおよびMSが在圏しているBS(図776(a)の場合、BTS1およびBTS2)における使用可能な無線リソースを求め、その結果に基づき、新規呼を含めたMS上の全ての呼をどのように取り扱うかを決定する。
(1)基地局制御装置のTACFaは、MSの在圏先であるBTS1に対応した基地局制御装置内のTACFv1−2に対し、当該BTS1を経由した新規呼call−2のためのアクセスリンクの設定を要求するBEARER SETUP req.ind.を送信する。
このBEARER&RADIO BEARER SETUP req.ind.は、BTS1からMSまでの新規呼call−2のための無線アクセスリンクおよび当該BTS1から基地局制御装置までの有線アクセスリンクの設定を要求するものである。
上記TACFv1−2からのRADIO BEARER SETUP REQUEST req.ind.(新規呼call−2のためのBTS1経由の無線アクセスリンク設定要求)、
上記TACFv2−1からのRADIO BEARER SETUP REQUEST req.ind.(既存呼call−1のためのBTS2経由の無線アクセスリンク設定要求)および
上記TACFv2−2からのRADIO BEARER SETUP REQUEST req.ind.(新規呼call−2のためのBTS2経由の無線アクセスリンク設定要求)をこれまでに受信しているので、HANDOVER BRANCH ADDITION req.ind.およびRADIO BEARER SETUP req.ind.の両方の内容を含んだ1つのメッセージをMSのTACAFaに送信する。
ここで、RADIO BEARER SETUP req.ind.は、call−2のためのメインブランチ(後に同期確立を行うブランチであって、ここではBTS1経由のブランチ)の設定を要求するものである。
また、HANDOVER BRANCH ADDITION req.ind.は、call−1およびcall−2の両方についてダイバーシチハンドオーバを行うためのサブブランチ(ここではBTS2経由のブランチ)の設定を要求するものである。
これをもってMSは、既存呼call−1および新規呼call−2の両方について、BTS1および2を経由したダイバーシチハンドオーバブランチを使用し、かつ、周波数f1を使用して通信を行うこととなる。
図777(a)に示すようにMSがBTS1を使用してcall−1の通信を行っているときに、新たな別の呼であるcall−2がMSに生じたとする。基地局制御装置のTACFaは、MS上に発生している既存呼call−1によって占有されている無線リソースおよびMSが在圏しているBTS(図777(a)の場合、BTS1およびBTS2)における使用可能な無線リソースを求め、その結果に基づき、新規呼を含めたMS上の全ての呼をどのように取り扱うかを決定する。
(1)基地局制御装置のTACFaは、MSの在圏先であるBTS2を制御する基地局制御装置のTACFv2−1に対し、当該BTS−2を経由した既存呼call−1のためのアクセスリンクを確立するため、BEARER SETUP req.ind.を送信する。
ここで、NON−SOFT HANDOVER BRANCH EXECUTION req.ind.は、既存呼call−1のための既存の無線アクセスリンク(BTS1経由の無線アクセスリンク)をBTS2経由のブランチへ切り替えることを要求するものである。
また、RADIO BEARER SETUP REQUEST req.ind.には新規呼call−2のためのBTS2経由の無線アクセスリンクの設定を要求するものである。
これをもってMSは、既存呼call−1および新規呼call−2の両方について、BTS2を経由したブランチを使用し、かつ、周波数f2を使用して通信を行うこととなる。
(3.7.1):本制御方法の導入の背景
本制御方法も、同時に複数の呼に対応した通信が可能な移動局装置の使用時における問題の解決を図ったものである。
この種の移動局が複数の呼に対応した通信を行っているときにハンドオーバの契機が生じる場合があるが、かかる場合について何等策を講じないとすると、各呼毎に行われるハンドオーバ如何によっては、ブランチ構成や周波数帯域が呼毎に区々となる場合があり得る。かかる場合、呼毎に移動局のハンドオーバ制御や送信電力制御を行う必要があり、網側のオーバヘッドに関する負担が過大となる。
本制御方法は、かかる問題を解決すべく導入されたものである。
本制御方法では、複数呼の通信が可能な移動局が通信を行っているときに当該移動局の移動等によりハンドオーバの契機が発生した場合には、通信中の全ての呼の通信を維持することができる新たなブランチ構成および周波数帯域を決定し、全ての呼に設定されているブランチ構成および周波数帯域を、この新たなブランチ構成および周波数帯域への変更する。
図780(a)において、MSは、BTS1との間に設定された周波数f1のブランチおよびBTS2との間に設定された周波数f1のブランチからなるダイバーシチハンドオーバブランチを使用し、call−1およびcall−2に対応した通信を行っている。
また、この適用例では、BTS3の通信容量には十分な余裕があり、呼call−1およびcall−2の両方についてMSおよびBTS3間で通信を行うことが可能である。
図781(a)において、MSは、BTS1との間に設定された周波数f1のブランチを使用し、call−1およびcal1−2の通信を行っている。
この適用例では、MSがBTS1から遠ざかり、BTS3に近づきつつあるため、MSとBTS3との間のブランチをMSに追加する必要性が生じている。
また、この適用例では、BTS3の通信容量には十分な余裕があり、呼call−1およびcall−2の両方についてMSおよびBTS3間で通信を行うことが可能である。
そこで、この適用例では、図781(b)に示すように、call−1およびcall−2の両方について、通信のためのブランチ構成をBTS3を使用したブランチ構成に変更しているのである。
図782において、TACAFaは図780(a)および(b)におけるMSの機能エンティティである。TACFaは基地局制御装置内の機能エンティティTACFであって、MSが通信を開始するときに最初に生成されたものである。また、TACFv3−1およびTACFv3−2は、MSの在圏先であるBTS3を制御するために基地局制御装置が有している機能エンティティの各インスタンスであり、各々call−1およびcall−2に対応したものである。また、BCFr3−1およびBCFr3−2は、MSの在圏先であるBTS3が有している無線リソース制御のための機能エンティティのインスタンスであり、各々呼call−1およびcall−2に対応している。
図783において、TACAFaは図781(a)および(b)におけるMSの機能エンティティである。TACFaは基地局制御装置内の機能エンティティTACFであって、MSが通信を開始するときに最初に生成されたものである。また、TACFv1−1およびTACFv1−2は、BTS1を制御するために基地局制御装置が有している機能エンティティの各インスタンスであり、各々call−1およびcall−2に対応したものである。また、TACFv3−1およびTACFv3−2は、BTS3を制御するために基地局制御装置が有している機能エンティティの各インスタンスであり、各々call−1およびcall−2に対応したものである。また、BCFr1−1およびBCFr1−2は、BTS1が有している無線リソース制御のための機能エンティティのインスタンスであり、各々call−1およびcall−2に対応している。また、BCFr3−1およびBCFr3−2は、BTS3が有している無線リソース制御のための機能エンティティのインスタンスであり、各々呼call−1およびcall−2に対応している。
これをもってMSは、call−1およびcall−2の両方について、BTS3を経由したブランチを使用して通信を行うこととなる。
(3.8.1):本制御方法の導入の背景
上記(3.7)の制御方法では、移動局が複数の呼に対応した通信を行っているときにハンドオーバの契機が生じた場合に、全ての呼に対応した通信を可能にするブランチ構成および周波数帯域を決定し、その決定に従って全ての呼についてのハンドオーバを実施した。
この制御方法を実施しようとする場合において、移動局の在圏先の基地局の通信容量の不足等の理由により、全ての呼に対して無線資源を割り当てることは不可能である、といった事態が生じ得る。
このような場合、何等策を講じないとすれば、全ての呼を切断せざるを得ない。
かかる場合に、優先度の高い呼の通信を維持できるにも拘わらず、全ての呼を切断してしまうのは甚だ不合理である。
本制御方法は、かかる不合理を解消すべく導入されたものである。
本制御方法では、上記のような、複数呼の通信が可能な移動局が通信を行っているときに当該移動局の移動等によりハンドオーバの契機が発生した場合に以下の手順に従ってハンドオーバの制御を行う。
b.通信中の全ての呼を維持することができるブランチ構成または周波数帯域がない場合には、当該移動局の通信に割り当てることが可能な空き容量を移動局または網側の装置が認識する。
c.上記空き容量に見合う呼を優先度の高いものから選択し、選択しなかった呼は解放する。なお、優先度が同じ呼については、全て解放するか、一定の法則に従って一部を選択し(解放する呼をランダムに選択してもよいし、例えば接続開始時間の長いものから選択してもよい)、他を解放する。
d.選択した呼については、上記空き容量を使用したブランチまたは周波数帯域にハンドオーバさせる。
このような制御により、優先度の高い呼を維持できるよう、優先度の高い呼以外の呼を切断し、優先度の高い呼については各呼のブランチ構成および周波数帯域が同じになるようにハンドオーバを行うのである。
図784(a)において、MSは、BTS1経由の周波数f1のブランチを使用し、call−1およびcall−2に対応した通信を行っている。
この適用例では、MSがBTS1の圏内からBTS3の圏内に移行しつつあり、BTS1からBTS3へのハンドオーバをすべき状態となっている。
また、BTS3の使用周波数はf2であり、BTS1との間でダイバーシチハンドオーバを行うこともできない。
これをもってMSは、優先度の高いcall−1のみについて、BTS3を経由したブランチを使用して通信を行うこととなる。
(3.9.1):本制御方法導入の背景
従来の移動通信システムにおいては、以下の手順により、ハンドオーバを行っていた。
(1)移動局と新たな基地局との間に新たなブランチを設定する。
(2)移動局からの無線信号の同期確立を新たな基地局が確認する。
(3)新たな基地局から基地局制御装置に同期確立を報告する。
(4)ハンドオーバ手順を終了する。
本制御方法は、かかる問題を解決すべく導入されたものである。
本システムでは、ハンドオーバを行う場合に、ブランチについての同期確立の確認を待つのではなく、レイヤ3メッセージの通信の開始により、ハンドオーバ手順を終了する。
すなわち、基地局制御装置は、新たなブランチの設定要求を基地局および移動局に送った場合、新たなブランチについての同期確立が確認されるのを待たずに、ハンドオーバ手順を終了する。
例えば図41は基地局内ダイバーシチハンドオーバを行うためのブランチ追加の動作シーケンス、図43は基地局間ダイバーシチハンドオーバを行うためのブランチ追加の動作シーケンスを表しているが、これらの動作シーケンスにおいて、メインブランチについてのレイヤ1確立が終わると、その時点で移動局は通信が可能になる。そこで、網側では、新たに追加されたサブブランチについての同期確立の確認を待たずにブランチ追加の手続を終了しているのである。
ダイバーシチハンドオーバを行う他の動作例(図775、図778等)についても同様である。)
(3.10.1):本制御方法の導入の背景
一般的なコードリソース管理制御においては、コードリソースの再割当て(呼の再配置)は、呼の生起時及び呼の終了時に行われていた。
呼の生起時に再割当を行う方法では、接続開始時に再配置が行われるため接続開始までの遅延が大きいという問題が生じる。
さらに回線に割当可能なコードリソース(割当可能コードリソースという。)を複数の帯域幅を有するコードリソースに分割し、いずれか一つのコードリソース長を有する未使用のコードリソースを回線に割当可能な移動無線通信システムにおいては、コードリソース空間内でコードリソースの確保(=割当)・解放を繰り返すことにより利用可能な空きコードリソースが散らばる「フラグメント」が生じることが避けられない。
しかしながら、コードリソースの回線への再割当てを呼の生起時に行うことは、呼の接続遅延が発生するという不具合が生じる。
そこで、本制御方法は、コードリソースの回線への再割当を行う契機を最適化し、再割当の頻度を低減させ、かつ、呼の接続遅延を抑制することが可能な移動無線通信システム、基地局装置、基地局制御装置及びそれらの制御方法を提供することを目的としている。
図793にある時点におけるコードリソースの回線への割当状況を示す。
図793に示す回線への割当状況においては、コードリソースCR5−2、CR5−7、CR5−8、CR5−9、CR5−11、CR5−15及びCR5−16のみが未使用(未割当)であり利用可能となっている。
CR1=2×(CR2)
=4×(CR3)
=8×(CR4)
=16×(CR5)
より具体的には、レベル3コードリソースCR3−4を確保できないことを無線基地局が判別すると、基地局制御装置は、レベル3コードリソースCR3−4を確保すべく、レベル5コードリソースCR5−11を未使用の同じリソース長を有するレベル5コードリソースCR5−9に移動し(ステップS1)、さらにレベル4コードリソースCR4−7を未使用の同じリソース長を有するレベル4コードリソースCR4−6に移動する(ステップS2)。
これにより、レベル3コードリソースCR3−4が確保されることとなる。
そこで、本制御方法においては、再割当の契機を予め設定した帯域幅を有する連続した未使用の割当可能コードリソースが存在しなくなった場合をその契機としている。
より具体的には、レベル3コードリソースCR3を基準コードリソース及び割当が可能な最大の帯域幅を有する割当可能コードリソースとし、このレベル3コードリソースCR3に相当する帯域幅を基準帯域幅として、レベル3コードリソースCR3を回線に割り当てることができなくなくなった時点(図793参照)をコードリソースの再割当の契機として用いている。
Claims (5)
- 移動機と、
各々が前記移動機と通信可能な複数の無線基地局と、
前記複数の無線基地局に対し情報を送信する基地局制御装置と、
前記基地局制御装置に対し情報を送信する交換局と
を有し、
前記交換局が、
前記基地局制御装置および前記移動機のそれぞれに秘匿開始の通知を行う相互通知手段
を有し、
前記基地局制御装置が、
交換局から秘匿前情報を受信する制御装置受信手段と、
前記制御装置受信手段により受信された秘匿前情報に対して秘匿処理を施し秘匿化情報を生成する秘匿処理手段と、
前記秘匿処理手段により生成された秘匿化情報を、前記複数の無線基地局に送信する制御装置送信手段と、
を有し、
前記複数の無線基地局の各々が、
前記基地局制御装置から秘匿化情報を受信する基地局受信手段と、
前記基地局受信手段により受信された秘匿化情報を前記移動機に送信する基地局送信手段と
を有し、
前記移動機が、
前記複数の無線基地局から送信された秘匿化情報を受信する移動機受信手段と、
前記移動機受信手段により受信された秘匿化情報をダイバーシチ合成するダイバーシチ合成手段と、
前記ダイバーシチ合成手段によりダイバーシチ合成された秘匿化情報に対し、秘匿解除処理を施す秘匿解除手段と
を有する
ことを特徴とする移動通信システム。 - 前記基地局制御装置が、前記秘匿前情報に再送制御情報を付加する再送制御情報付加手段をさらに有し、
前記秘匿処理手段が、前記再送制御情報付加手段により再送制御情報が付加された秘匿前情報を、再送制御情報も含めて秘匿化する
ことを特徴とする請求項1に記載の移動通信システム。 - 前記基地局制御装置が、前記秘匿処理手段により生成された秘匿化情報に対し、再送制御情報を付加する再送制御情報付加手段をさらに有する
ことを特徴とする請求項1に記載の移動通信システム。 - 前記移動機が、前記交換局から、前記基地局制御装置を介して送信された秘匿開始の通知を受信する通知受信手段をさらに有し、
前記秘匿処理手段が、前記通知受信手段が秘匿開始の通知を受信したことを契機として秘匿処理を開始する
ことを特徴とする請求項1−3のいずれかの項に記載の移動通信システム。 - 移動機と、各々が前記移動機と通信可能な複数の無線基地局と、前記複数の無線基地局に対し情報を送信する基地局制御装置と、前記基地局制御装置に対し情報を送信する交換局とを有する移動通信システムにおける通信制御方法であって、
前記交換局が、前記基地局制御装置および前記移動機のそれぞれに秘匿開始の通知を行うステップと、
前記基地局制御装置が、交換局から秘匿前情報を受信するステップと、
前記基地局制御装置が、前記秘匿前情報に秘匿処理を施し、秘匿化情報を生成するステップと、
前記基地局制御装置が、前記秘匿化情報を、前記複数の無線基地局に送信するステップと
前記複数の基地局の各々が、前記基地局制御装置から秘匿化情報を受信するステップと、
前記複数の基地局の各々が、前記受信された秘匿化情報を前記移動機に送信するステップと
前記移動機が、前記複数の基地局から送信された秘匿化情報を受信するステップと、
前記受信された秘匿化情報をダイバーシチ合成するステップと、
前記ダイバーシチ合成された秘匿化情報に対し、秘匿解除処理を施すステップと
を有する通信制御方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2005208446A JP4386286B2 (ja) | 1997-04-24 | 2005-07-19 | 移動通信システムおよび通信制御方法 |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP12378297 | 1997-04-24 | ||
JP2005208446A JP4386286B2 (ja) | 1997-04-24 | 2005-07-19 | 移動通信システムおよび通信制御方法 |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP1998545482 Division | 1998-04-24 |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2005332100A Division JP4279827B2 (ja) | 1997-04-24 | 2005-11-16 | 移動無線通信システム、無線基地局装置、基地局制御装置および通信制御方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2006020339A JP2006020339A (ja) | 2006-01-19 |
JP4386286B2 true JP4386286B2 (ja) | 2009-12-16 |
Family
ID=35794076
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2005208446A Expired - Lifetime JP4386286B2 (ja) | 1997-04-24 | 2005-07-19 | 移動通信システムおよび通信制御方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP4386286B2 (ja) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8130705B2 (en) * | 2006-09-15 | 2012-03-06 | Qualcomm Incorporated | Method and apparatus for service capability modification |
US8891458B2 (en) | 2007-12-05 | 2014-11-18 | Qualcomm Incorporated | User equipment capability update in wireless communications |
US8588151B2 (en) | 2008-08-08 | 2013-11-19 | Qualcomm Incorporated | Access terminal capability update |
US9232441B2 (en) | 2009-08-31 | 2016-01-05 | Qualcomm Incorporated | Power based rate selection |
-
2005
- 2005-07-19 JP JP2005208446A patent/JP4386286B2/ja not_active Expired - Lifetime
Also Published As
Publication number | Publication date |
---|---|
JP2006020339A (ja) | 2006-01-19 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4279806B2 (ja) | 移動通信方法及び移動通信システム | |
KR100366286B1 (ko) | 이동통신방법 및 이동통신시스템 | |
JP4279805B2 (ja) | アクセスリンク制御方法、移動局、基地局制御装置および基地局 | |
JP4386286B2 (ja) | 移動通信システムおよび通信制御方法 | |
JP4279827B2 (ja) | 移動無線通信システム、無線基地局装置、基地局制御装置および通信制御方法 | |
CA2411999C (en) | Method and system for mobile communications |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080729 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080929 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090310 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090511 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20090924 |
|
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090924 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121009 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131009 Year of fee payment: 4 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
EXPY | Cancellation because of completion of term |