JP2003274437A - 無線制御装置および移動端末の呼接続方法 - Google Patents
無線制御装置および移動端末の呼接続方法Info
- Publication number
- JP2003274437A JP2003274437A JP2002070333A JP2002070333A JP2003274437A JP 2003274437 A JP2003274437 A JP 2003274437A JP 2002070333 A JP2002070333 A JP 2002070333A JP 2002070333 A JP2002070333 A JP 2002070333A JP 2003274437 A JP2003274437 A JP 2003274437A
- Authority
- JP
- Japan
- Prior art keywords
- call
- radio
- wireless
- mobile terminal
- priority
- 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.)
- Pending
Links
Landscapes
- Mobile Radio Communication Systems (AREA)
Abstract
(57)【要約】
【課題】 ソフトハンドオーバ時のマルチコール要求に
おいて、呼損率の低い呼接続方法を提供する。 【解決手段】 無線制御装置が、すでに複数の無線リン
クを用いて呼接続中（ソフトハンドオーバ中）である移
動端末に対するマルチコールの要求を受け付け、前記複
数の無線リンクのうち、少なくとも一つの無線リンクを
接続中の呼と受け付けた追加の呼をともに接続するよう
に再設定し、無線リソースの足りないその他の無線リン
クを解放するように制御する。
おいて、呼損率の低い呼接続方法を提供する。 【解決手段】 無線制御装置が、すでに複数の無線リン
クを用いて呼接続中（ソフトハンドオーバ中）である移
動端末に対するマルチコールの要求を受け付け、前記複
数の無線リンクのうち、少なくとも一つの無線リンクを
接続中の呼と受け付けた追加の呼をともに接続するよう
に再設定し、無線リソースの足りないその他の無線リン
クを解放するように制御する。
Description
【０００１】
【発明の属する技術分野】本発明は、ＣＤＭＡ移動端末
と基地局が複数の無線リンクにより呼を接続しているソ
フトハンドオーバ状態において、マルチコール要求があ
った場合の呼接続方法に関する。
と基地局が複数の無線リンクにより呼を接続しているソ
フトハンドオーバ状態において、マルチコール要求があ
った場合の呼接続方法に関する。
【０００２】
【従来の技術】従来、Ｗ−ＣＤＭＡ通信システムにおい
ては、一つの移動端末が音声通信を行ないながら、さら
にデータ通信を行なうなど、複数の異なった無線アクセ
スベアラ（Radio Access Bearer，ＲＡＢ）を同時に設
定し複数の呼を接続するマルチコールサービスが提供さ
れている。このマルチコールを実現する手順として、3r
d Generation Partnership Project（３ＧＰＰ）では、
無線制御装置（Radio Network Controller，ＲＮＣ）と
移動端末（User Equipment，ＵＥ）間のプロトコルであ
るRadio Resource Control（ＲＲＣ，勧告番号ＴＳ25.3
31）、ＲＮＣと基地局（ＢＴＳ）間のプロトコルである
Node B Application Part（ＮＢＡＰ，勧告番号ＴＳ25.
433）を規定している。マルチコールを実現する方法の
従来技術として、上記ＲＲＣ及びＮＢＡＰプロトコルを
用いたシグナリング手順例が３ＧＰＰのＴＲ25.931に示
されている。以下、この従来技術を説明する。
ては、一つの移動端末が音声通信を行ないながら、さら
にデータ通信を行なうなど、複数の異なった無線アクセ
スベアラ（Radio Access Bearer，ＲＡＢ）を同時に設
定し複数の呼を接続するマルチコールサービスが提供さ
れている。このマルチコールを実現する手順として、3r
d Generation Partnership Project（３ＧＰＰ）では、
無線制御装置（Radio Network Controller，ＲＮＣ）と
移動端末（User Equipment，ＵＥ）間のプロトコルであ
るRadio Resource Control（ＲＲＣ，勧告番号ＴＳ25.3
31）、ＲＮＣと基地局（ＢＴＳ）間のプロトコルである
Node B Application Part（ＮＢＡＰ，勧告番号ＴＳ25.
433）を規定している。マルチコールを実現する方法の
従来技術として、上記ＲＲＣ及びＮＢＡＰプロトコルを
用いたシグナリング手順例が３ＧＰＰのＴＲ25.931に示
されている。以下、この従来技術を説明する。
【０００３】図１４はＷ−ＣＤＭＡ通信システムのシス
テム構成図であり、移動端末がソフトハンドオーバを行
なっている状態の概要を示している。ソフトハンドオー
バとは、受信品質の向上、無瞬断通信の実現のために、
移動端末が同時に複数のセルと（すなわちこれらのセル
を管理するＢＴＳと）無線リンクを接続して通信を行な
うことをいう。
テム構成図であり、移動端末がソフトハンドオーバを行
なっている状態の概要を示している。ソフトハンドオー
バとは、受信品質の向上、無瞬断通信の実現のために、
移動端末が同時に複数のセルと（すなわちこれらのセル
を管理するＢＴＳと）無線リンクを接続して通信を行な
うことをいう。
【０００４】図において、１はシステム全体の呼制御、
サービス制御等を統率するコアネットワーク、２は関門
ノードであるＧＧＳＮ（Gateway GPRS Support Nod
e）、３は加入者ノードであるＳＧＳＮ（Serving GPRS
Support Node）である。４は無線制御装置（ＲＮＣ）で
あり、無線リソースの管理、基地局（ＢＴＳ）の制御等
を行なう。５および６は、ＲＮＣ４に制御される基地局
（ＢＴＳ）であり、ＢＴＳ５はセル８および９を管理
し、ＢＴＳ６はセル１０を管理する。１１〜１３は移動
端末（User Equipment，ＵＥ)７とＢＴＳ５または６と
を接続する無線リンク（Radio Link，ＲＬ）であり、Ｕ
Ｅ７はＲＬ１１〜１３によってＢＴＳ５および６に対す
るソフトハンドオーバを行なっている。また、１４はＲ
Ｌ１１〜１３を用い、ＵＥ７のユーザにデータ通信サー
ビスを提供する無線アクセスベアラ（ＲＡＢ）である。
サービス制御等を統率するコアネットワーク、２は関門
ノードであるＧＧＳＮ（Gateway GPRS Support Nod
e）、３は加入者ノードであるＳＧＳＮ（Serving GPRS
Support Node）である。４は無線制御装置（ＲＮＣ）で
あり、無線リソースの管理、基地局（ＢＴＳ）の制御等
を行なう。５および６は、ＲＮＣ４に制御される基地局
（ＢＴＳ）であり、ＢＴＳ５はセル８および９を管理
し、ＢＴＳ６はセル１０を管理する。１１〜１３は移動
端末（User Equipment，ＵＥ)７とＢＴＳ５または６と
を接続する無線リンク（Radio Link，ＲＬ）であり、Ｕ
Ｅ７はＲＬ１１〜１３によってＢＴＳ５および６に対す
るソフトハンドオーバを行なっている。また、１４はＲ
Ｌ１１〜１３を用い、ＵＥ７のユーザにデータ通信サー
ビスを提供する無線アクセスベアラ（ＲＡＢ）である。
【０００５】次に動作を説明する。ＵＥ７はＲＬ１１〜
１３の３つの無線リンクを接続して、ＢＴＳ５および６
に対しソフトハンドオーバ状態となっており、ＲＡＢ１
４を用いてデータ通信を行なっている。ここで、ＵＥ７
が上記データ通信サービスを受けながら新たに音声通信
サービスを受けるよう音声通信用ＲＡＢの設定を要求す
る（マルチコールの要求を行なう）と、ＲＮＣ４は無線
リソースを確保し、ＮＢＡＰプロトコルを用いてＢＴＳ
５および６に対し現在接続中であるＲＬ１１〜１３全て
の無線リンクを要求されたマルチコール用に再設定す
る。そして、これらの無線リンクの再設定が完了した
後、ＲＮＣ４はＲＲＣプロトコルを用いてＵＥ７に対し
物理チャネルの再設定を行なうことで新規の音声通信用
ＲＡＢを設定し、要求されたマルチコールの接続を完了
する。
１３の３つの無線リンクを接続して、ＢＴＳ５および６
に対しソフトハンドオーバ状態となっており、ＲＡＢ１
４を用いてデータ通信を行なっている。ここで、ＵＥ７
が上記データ通信サービスを受けながら新たに音声通信
サービスを受けるよう音声通信用ＲＡＢの設定を要求す
る（マルチコールの要求を行なう）と、ＲＮＣ４は無線
リソースを確保し、ＮＢＡＰプロトコルを用いてＢＴＳ
５および６に対し現在接続中であるＲＬ１１〜１３全て
の無線リンクを要求されたマルチコール用に再設定す
る。そして、これらの無線リンクの再設定が完了した
後、ＲＮＣ４はＲＲＣプロトコルを用いてＵＥ７に対し
物理チャネルの再設定を行なうことで新規の音声通信用
ＲＡＢを設定し、要求されたマルチコールの接続を完了
する。
【０００６】具体的な手順について、図１５を用いて説
明する。図１５はソフトオーバ時のマルチコール接続手
順を示すシーケンス図である。初期状態として、前述の
とおり、ＲＮＣ４の制御によってＵＥ７はＢＴＳ５およ
び６に対しソフトハンドオーバ状態にあり、すでに呼接
続されＲＡＢ１４を用いてデータ通信を行なっている。
明する。図１５はソフトオーバ時のマルチコール接続手
順を示すシーケンス図である。初期状態として、前述の
とおり、ＲＮＣ４の制御によってＵＥ７はＢＴＳ５およ
び６に対しソフトハンドオーバ状態にあり、すでに呼接
続されＲＡＢ１４を用いてデータ通信を行なっている。
【０００７】この状態で、まず、１５００においてＲＮ
Ｃ４は新規ＲＡＢの設定要求を受け付ける。すでにＲＡ
Ｂ１４が設定されているので、これはマルチコール要求
の受け付けとなる。ＲＮＣ４は新規ＲＡＢを設定する為
に必要な無線リソースを確保し、ＢＴＳ５および６に対
してそれぞれ"Radio Link Reconfiguration Prepare"メ
ッセージ１５０１、１５０２を送信して、ＲＬ１１〜１
３を要求されたマルチコール用に再設定する準備を行な
う。"Radio Link Reconfiguration Prepare"メッセージ
１５０１、１５０２を受信したＢＴＳ５および６は、Ｒ
ＮＣ４に対し"Radio Link Reconfiguration Ready"メッ
セージ１５０３および１５０４を送信して、無線リンク
を再設定する準備が完了したことを通知する。
Ｃ４は新規ＲＡＢの設定要求を受け付ける。すでにＲＡ
Ｂ１４が設定されているので、これはマルチコール要求
の受け付けとなる。ＲＮＣ４は新規ＲＡＢを設定する為
に必要な無線リソースを確保し、ＢＴＳ５および６に対
してそれぞれ"Radio Link Reconfiguration Prepare"メ
ッセージ１５０１、１５０２を送信して、ＲＬ１１〜１
３を要求されたマルチコール用に再設定する準備を行な
う。"Radio Link Reconfiguration Prepare"メッセージ
１５０１、１５０２を受信したＢＴＳ５および６は、Ｒ
ＮＣ４に対し"Radio Link Reconfiguration Ready"メッ
セージ１５０３および１５０４を送信して、無線リンク
を再設定する準備が完了したことを通知する。
【０００８】"Radio Link Reconfiguration Ready"メッ
セージ１５０３、１５０４を受信したＲＮＣ４は、ＢＴ
Ｓ５および６がＲＬ１１〜１３を再設定する準備を完了
したことを知り、ＢＴＳ５および６に対してそれぞれ"R
adio Link ReconfigurationCommit"メッセージ１５０
５、１５０６を送信して、ＲＬ１１〜１３を要求された
マルチコール用に再設定する。
セージ１５０３、１５０４を受信したＲＮＣ４は、ＢＴ
Ｓ５および６がＲＬ１１〜１３を再設定する準備を完了
したことを知り、ＢＴＳ５および６に対してそれぞれ"R
adio Link ReconfigurationCommit"メッセージ１５０
５、１５０６を送信して、ＲＬ１１〜１３を要求された
マルチコール用に再設定する。
【０００９】次に、ＲＮＣ４はＵＥ７に対し"Physical
Channel Reconfiguration"メッセージ１５０７を送信し
て、物理チャネルの再設定を行なう。"Physical Channe
l Reconfiguration"メッセージ１５０７を受信したＵＥ
７は、所定の手順で物理チャネルを再設定して、ＲＮＣ
４に対し"Physical Channel Reconfiguration Complet
e"メッセージ１５０８を送信する。これにより、データ
通信に加え新規ＲＡＢを用いた音声通信が始められ、マ
ルチコール接続が完了する（１５０９）。
Channel Reconfiguration"メッセージ１５０７を送信し
て、物理チャネルの再設定を行なう。"Physical Channe
l Reconfiguration"メッセージ１５０７を受信したＵＥ
７は、所定の手順で物理チャネルを再設定して、ＲＮＣ
４に対し"Physical Channel Reconfiguration Complet
e"メッセージ１５０８を送信する。これにより、データ
通信に加え新規ＲＡＢを用いた音声通信が始められ、マ
ルチコール接続が完了する（１５０９）。
【００１０】
【発明が解決しようとする課題】上記のように従来技術
においては、ソフトハンドオーバ状態時にマルチコール
の要求を受けた場合、設定されている複数の無線リンク
をすべてマルチコール用に再設定するように制御してい
たので、これら複数の無線リンクのうち一部にでも再設
定するための無線リソースが確保できない場合には、新
規に要求された無線アクセスベアラの設定は失敗とな
り、マルチコールの要求は拒否され呼損になってしまう
（移動端末ユーザに対するサービスが低下する）という
問題があった。
においては、ソフトハンドオーバ状態時にマルチコール
の要求を受けた場合、設定されている複数の無線リンク
をすべてマルチコール用に再設定するように制御してい
たので、これら複数の無線リンクのうち一部にでも再設
定するための無線リソースが確保できない場合には、新
規に要求された無線アクセスベアラの設定は失敗とな
り、マルチコールの要求は拒否され呼損になってしまう
（移動端末ユーザに対するサービスが低下する）という
問題があった。
【００１１】本発明は上記のような問題を解消するため
になされたものであり、請求項１の発明の目的は、ソフ
トハンドオーバ時のマルチコール要求に対する呼損率の
低い無線制御装置の呼接続方法を提供することである。
になされたものであり、請求項１の発明の目的は、ソフ
トハンドオーバ時のマルチコール要求に対する呼損率の
低い無線制御装置の呼接続方法を提供することである。
【００１２】また、請求項２の発明の目的は、ソフトハ
ンドオーバ時のマルチコール要求に対する呼損率が低
く、かつ不要な受信品質の低下を防ぐ無線制御装置の呼
接続方法を提供することである。
ンドオーバ時のマルチコール要求に対する呼損率が低
く、かつ不要な受信品質の低下を防ぐ無線制御装置の呼
接続方法を提供することである。
【００１３】また、請求項３の発明の目的は、ソフトハ
ンドオーバ時のマルチコール要求に対する呼損率が低
く、かつ不要な受信品質の低下をさらに防ぐ無線制御装
置の呼接続方法を提供することである。
ンドオーバ時のマルチコール要求に対する呼損率が低
く、かつ不要な受信品質の低下をさらに防ぐ無線制御装
置の呼接続方法を提供することである。
【００１４】また、請求項４、５および６の発明の目的
は、ソフトハンドオーバ時のマルチコール要求に対する
呼損率が低く、かつ無線リソースを有効利用可能な無線
制御装置の呼接続方法を提供することである。
は、ソフトハンドオーバ時のマルチコール要求に対する
呼損率が低く、かつ無線リソースを有効利用可能な無線
制御装置の呼接続方法を提供することである。
【００１５】また、請求項７の発明の目的は、ソフトハ
ンドオーバ時のマルチコール要求に対する呼損率が低
く、かつリソースを有効利用可能な無線制御装置の呼接
続方法を提供することである。
ンドオーバ時のマルチコール要求に対する呼損率が低
く、かつリソースを有効利用可能な無線制御装置の呼接
続方法を提供することである。
【００１６】また、請求項８および９の発明の目的は、
ソフトハンドオーバ時の優先度の高いマルチコール要求
に対する呼損率の低い無線制御装置の呼接続方法を提供
することである。
ソフトハンドオーバ時の優先度の高いマルチコール要求
に対する呼損率の低い無線制御装置の呼接続方法を提供
することである。
【００１７】また、請求項１０の発明の目的は、ソフト
ハンドオーバ時の優先度の高いマルチコール要求に対す
る呼損率が低く、かつ不要な受信品質の低下を防ぐ無線
制御装置の呼接続方法を提供することである。
ハンドオーバ時の優先度の高いマルチコール要求に対す
る呼損率が低く、かつ不要な受信品質の低下を防ぐ無線
制御装置の呼接続方法を提供することである。
【００１８】また、請求項１１の発明の目的は、ソフト
ハンドオーバ時のマルチコール要求に対し、優先度の高
い呼の呼損率が低い無線制御装置の呼接続方法を提供す
ることである。
ハンドオーバ時のマルチコール要求に対し、優先度の高
い呼の呼損率が低い無線制御装置の呼接続方法を提供す
ることである。
【００１９】また、請求項１２の発明の目的は、ソフト
ハンドオーバ時のマルチコール要求に対し、優先度の高
い呼の呼損率が低く、かつ不要な受信品質の低下を防ぐ
無線制御装置の呼接続方法を提供することである。
ハンドオーバ時のマルチコール要求に対し、優先度の高
い呼の呼損率が低く、かつ不要な受信品質の低下を防ぐ
無線制御装置の呼接続方法を提供することである。
【００２０】さらに、請求項１３および１４の発明の目
的は、ソフトハンドオーバ時のマルチコール要求に対す
る呼損率が低く、かつ無線リソースを容易に有効利用可
能な移動端末の呼制御方法を提供することである。
的は、ソフトハンドオーバ時のマルチコール要求に対す
る呼損率が低く、かつ無線リソースを容易に有効利用可
能な移動端末の呼制御方法を提供することである。
【００２１】
【課題を解決するための手段】請求項１の発明に係る無
線制御装置の呼接続方法は、一つの移動端末と基地局と
の間に一つの呼を接続する複数の無線リンクを設定する
第１ステップ、前記呼に追加される追加呼の接続要求を
受付ける第２ステップ、前記複数の無線リンクのうち、
少なくとも一つの無線リンクを前記呼と前記追加呼をと
もに接続するように再設定し、その他の無線リンクを解
放する第３ステップを含む。
線制御装置の呼接続方法は、一つの移動端末と基地局と
の間に一つの呼を接続する複数の無線リンクを設定する
第１ステップ、前記呼に追加される追加呼の接続要求を
受付ける第２ステップ、前記複数の無線リンクのうち、
少なくとも一つの無線リンクを前記呼と前記追加呼をと
もに接続するように再設定し、その他の無線リンクを解
放する第３ステップを含む。
【００２２】また、請求項２の発明に係る無線制御装置
の呼接続方法は、前記移動端末と前記基地局間における
無線リソースの空きを検知する第４ステップをさらに含
み、前記第４ステップで検知された前記無線リソースの
空きが所定量に足りない場合、前記第３ステップにおい
て当該空きの足りない無線リソースを使用する無線リン
クを解放する。
の呼接続方法は、前記移動端末と前記基地局間における
無線リソースの空きを検知する第４ステップをさらに含
み、前記第４ステップで検知された前記無線リソースの
空きが所定量に足りない場合、前記第３ステップにおい
て当該空きの足りない無線リソースを使用する無線リン
クを解放する。
【００２３】また、請求項３の発明に係る無線制御装置
の呼接続方法は、前記第４ステップで検知された前記無
線リソースの空きが所定量に足りない場合、前記第３ス
テップにおいて当該空きの足りない無線リソースを使用
する無線リンクのみを解放し、それ以外の無線リンクを
すべて前記呼と前記追加呼をともに接続するように再設
定する。
の呼接続方法は、前記第４ステップで検知された前記無
線リソースの空きが所定量に足りない場合、前記第３ス
テップにおいて当該空きの足りない無線リソースを使用
する無線リンクのみを解放し、それ以外の無線リンクを
すべて前記呼と前記追加呼をともに接続するように再設
定する。
【００２４】また、請求項４の発明に係る無線制御装置
の呼接続方法は、前記第３ステップが無線リンクの解放
を前記移動端末へ指示するステップを含み、解放する無
線リンク情報を含む物理チャネル設定用メッセージの通
知により前記指示を行なう。
の呼接続方法は、前記第３ステップが無線リンクの解放
を前記移動端末へ指示するステップを含み、解放する無
線リンク情報を含む物理チャネル設定用メッセージの通
知により前記指示を行なう。
【００２５】また、請求項５の発明に係る無線制御装置
の呼接続方法は、前記第３ステップが無線リンクの解放
を前記移動端末へ指示するステップを含み、再設定する
無線リンクのみに対応する物理チャネル情報を含む物理
チャネル設定用メッセージの通知により前記指示を行な
う。
の呼接続方法は、前記第３ステップが無線リンクの解放
を前記移動端末へ指示するステップを含み、再設定する
無線リンクのみに対応する物理チャネル情報を含む物理
チャネル設定用メッセージの通知により前記指示を行な
う。
【００２６】また、請求項６の発明に係る無線制御装置
の呼接続方法は、前記第３ステップが無線リンクの解放
を前記移動端末へ指示するステップを含み、再設定する
無線リンクのみに対応するトランスポートチャネル情報
を含むトランスポートチャネル設定用メッセージの通知
により前記指示を行なう。
の呼接続方法は、前記第３ステップが無線リンクの解放
を前記移動端末へ指示するステップを含み、再設定する
無線リンクのみに対応するトランスポートチャネル情報
を含むトランスポートチャネル設定用メッセージの通知
により前記指示を行なう。
【００２７】また、請求項７の発明に係る無線制御装置
の呼接続方法は、前記第３ステップが無線リンクの解放
を前記移動端末へ指示するステップを含み、非同期手順
により前記指示を行なう。
の呼接続方法は、前記第３ステップが無線リンクの解放
を前記移動端末へ指示するステップを含み、非同期手順
により前記指示を行なう。
【００２８】また、請求項８の発明に係る無線制御装置
の呼接続方法は、前記追加呼の優先度を判断する第４ス
テップをさらに含み、前記第４ステップで前記追加呼の
優先度が高いと判断された場合、前記第３ステップにお
いて前記複数の無線リンクのうち、少なくとも一つの無
線リンクを前記呼と前記追加呼をともに接続するように
再設定し、その他の無線リンクを解放する。
の呼接続方法は、前記追加呼の優先度を判断する第４ス
テップをさらに含み、前記第４ステップで前記追加呼の
優先度が高いと判断された場合、前記第３ステップにお
いて前記複数の無線リンクのうち、少なくとも一つの無
線リンクを前記呼と前記追加呼をともに接続するように
再設定し、その他の無線リンクを解放する。
【００２９】また、請求項９の発明に係る無線制御装置
の呼接続方法は、前記第４ステップが前記呼の優先度と
相対的に前記追加呼の優先度を判断する。
の呼接続方法は、前記第４ステップが前記呼の優先度と
相対的に前記追加呼の優先度を判断する。
【００３０】また、請求項１０の発明に係る無線制御装
置の呼接続方法は、前記移動端末と前記基地局間におけ
る無線リソースの空きを検知する第５ステップをさらに
含み、前記第５ステップで検知された前記無線リソース
の空きが所定量に足りない場合に前記第４ステップにお
いて追加呼の優先度を判断し、前記追加呼の優先度が高
いと判断された場合、前記第３ステップにおいて当該空
きの足りない無線リソースを使用する無線リンクを解放
する。
置の呼接続方法は、前記移動端末と前記基地局間におけ
る無線リソースの空きを検知する第５ステップをさらに
含み、前記第５ステップで検知された前記無線リソース
の空きが所定量に足りない場合に前記第４ステップにお
いて追加呼の優先度を判断し、前記追加呼の優先度が高
いと判断された場合、前記第３ステップにおいて当該空
きの足りない無線リソースを使用する無線リンクを解放
する。
【００３１】また、請求項１１の発明に係る無線制御装
置の呼接続方法は、一つの移動端末と基地局との間に呼
を接続する複数の無線リンクを設定する第１ステップ、
前記呼に追加される追加呼の接続要求を受付ける第２ス
テップ、前記呼と前記追加呼の優先度を比較する第３ス
テップ、前記第３ステップで当該追加呼の優先度が相対
的に高いと判断された場合、前記呼を切断し前記追加呼
を接続するように無線リンクを再設定する第４ステップ
を含む。
置の呼接続方法は、一つの移動端末と基地局との間に呼
を接続する複数の無線リンクを設定する第１ステップ、
前記呼に追加される追加呼の接続要求を受付ける第２ス
テップ、前記呼と前記追加呼の優先度を比較する第３ス
テップ、前記第３ステップで当該追加呼の優先度が相対
的に高いと判断された場合、前記呼を切断し前記追加呼
を接続するように無線リンクを再設定する第４ステップ
を含む。
【００３２】また、請求項１２の発明に係る無線制御装
置の呼接続方法は、前記移動端末と前記基地局間におけ
る無線リソースの空きを検知する第４ステップをさらに
含み、前記第４ステップで検知された前記無線リソース
の空きが所定量に足りない場合、前記第３ステップにお
いて追加呼の優先度を判断する。
置の呼接続方法は、前記移動端末と前記基地局間におけ
る無線リソースの空きを検知する第４ステップをさらに
含み、前記第４ステップで検知された前記無線リソース
の空きが所定量に足りない場合、前記第３ステップにお
いて追加呼の優先度を判断する。
【００３３】また、請求項１３の発明に係る移動端末の
呼接続方法は、基地局との間に一つの呼を接続する複数
の無線リンクを設定する第１ステップ、前記呼に追加さ
れる追加呼の接続を要求する第２ステップ、前記複数の
無線リンクのうち再設定する無線リンクに対応するチャ
ネル情報を含むチャネル設定用メッセージを受信する第
３ステップ、前記第３ステップで受信したメッセージに
基づき、前記複数の無線リンクのうち少なくとも一つの
無線リンクを前記呼と前記追加呼をともに接続するよう
に再設定し、その他の無線リンクを解放する第４ステッ
プを含む。
呼接続方法は、基地局との間に一つの呼を接続する複数
の無線リンクを設定する第１ステップ、前記呼に追加さ
れる追加呼の接続を要求する第２ステップ、前記複数の
無線リンクのうち再設定する無線リンクに対応するチャ
ネル情報を含むチャネル設定用メッセージを受信する第
３ステップ、前記第３ステップで受信したメッセージに
基づき、前記複数の無線リンクのうち少なくとも一つの
無線リンクを前記呼と前記追加呼をともに接続するよう
に再設定し、その他の無線リンクを解放する第４ステッ
プを含む。
【００３４】さらに、請求項１４の発明に係る移動端末
の呼接続方法は、前記チャネル情報が物理チャネル情報
またはトランスポートチャネル情報である。
の呼接続方法は、前記チャネル情報が物理チャネル情報
またはトランスポートチャネル情報である。
【００３５】
【発明の実施の形態】実施の形態１．以下、本発明の実
施の形態１を、図を用いて説明する。図１は本発明の実
施の形態１に係るＷ−ＣＤＭＡ通信システムのシステム
構成図である。図において、１はシステム全体の呼制
御、サービス制御等を統率するコアネットワーク、２は
関門ノードであるＧＧＳＮ（Gateway GPRS Support Nod
e）、３は加入者ノードであるＳＧＳＮ（Serving GPRS
Support Node）である。
施の形態１を、図を用いて説明する。図１は本発明の実
施の形態１に係るＷ−ＣＤＭＡ通信システムのシステム
構成図である。図において、１はシステム全体の呼制
御、サービス制御等を統率するコアネットワーク、２は
関門ノードであるＧＧＳＮ（Gateway GPRS Support Nod
e）、３は加入者ノードであるＳＧＳＮ（Serving GPRS
Support Node）である。
【００３６】４は無線制御装置（ＲＮＣ）であり、無線
リソースの管理、基地局（ＢＴＳ）の制御等を行なう。
すなわち、ソフトハンドオーバの制御、マルチコール接
続の制御はＲＮＣにおいて行なわれる。５および６は、
ＲＮＣ４に制御される基地局（ＢＴＳ）であり、ＢＴＳ
５はセル８および９を管理し、ＢＴＳ６はセル１０を管
理する。１１〜１３は移動端末（User Equipment，Ｕ
Ｅ)７がＢＴＳ５および６に対しソフトハンドオーバを
行なっている状態において、ＵＥ７とＢＴＳ５または６
とを接続している無線リンク（Radio Link，ＲＬ）であ
る。ＲＬ１１〜１３のうちＲ１１および１２は、マルチ
コール接続時に削除されている。
リソースの管理、基地局（ＢＴＳ）の制御等を行なう。
すなわち、ソフトハンドオーバの制御、マルチコール接
続の制御はＲＮＣにおいて行なわれる。５および６は、
ＲＮＣ４に制御される基地局（ＢＴＳ）であり、ＢＴＳ
５はセル８および９を管理し、ＢＴＳ６はセル１０を管
理する。１１〜１３は移動端末（User Equipment，Ｕ
Ｅ)７がＢＴＳ５および６に対しソフトハンドオーバを
行なっている状態において、ＵＥ７とＢＴＳ５または６
とを接続している無線リンク（Radio Link，ＲＬ）であ
る。ＲＬ１１〜１３のうちＲ１１および１２は、マルチ
コール接続時に削除されている。
【００３７】また１４は、マルチコール接続前にはＲＬ
１１〜１３を用い、マルチコール接続以降はＲＬ１３を
用いてＵＥ７のユーザにサービス（例えばデータ通信サ
ービス）を提供する無線アクセスベアラ（ＲＡＢ）であ
る。１５は、マルチコールの接続により新規に設定され
るＲＡＢであり、マルチコール接続以降ＲＬ１３を用い
てＵＥ７のユーザに追加のサービス（例えば音声通信サ
ービス）を提供する。
１１〜１３を用い、マルチコール接続以降はＲＬ１３を
用いてＵＥ７のユーザにサービス（例えばデータ通信サ
ービス）を提供する無線アクセスベアラ（ＲＡＢ）であ
る。１５は、マルチコールの接続により新規に設定され
るＲＡＢであり、マルチコール接続以降ＲＬ１３を用い
てＵＥ７のユーザに追加のサービス（例えば音声通信サ
ービス）を提供する。
【００３８】次に動作を説明する。ＵＥ７はＲＬ１１〜
１３の３つの無線リンクを接続して、ＢＴＳ５および６
に対しソフトハンドオーバ状態となっており、ＲＡＢ１
４を用いてデータ通信を行なっている。まず、ＵＥ７が
上記データ通信サービスを受けながら新たにサービスを
受けるべく、新規ＲＡＢの設定を要求する（マルチコー
ルの要求を行なう）。このマルチコール要求を受け付け
たＲＮＣ４は、ＲＬ１１〜１３それぞれをマルチコール
用に再設定するために、無線リソースの空きを検知す
る。
１３の３つの無線リンクを接続して、ＢＴＳ５および６
に対しソフトハンドオーバ状態となっており、ＲＡＢ１
４を用いてデータ通信を行なっている。まず、ＵＥ７が
上記データ通信サービスを受けながら新たにサービスを
受けるべく、新規ＲＡＢの設定を要求する（マルチコー
ルの要求を行なう）。このマルチコール要求を受け付け
たＲＮＣ４は、ＲＬ１１〜１３それぞれをマルチコール
用に再設定するために、無線リソースの空きを検知す
る。
【００３９】その結果、ＢＴＳ５のセル８とＵＥ７間、
ＢＴＳ５のセル９とＵＥ７間およびＢＴＳ６のセル１０
とＵＥ７間それぞれで使用可能な無線リソースには、Ｒ
Ｌ１１〜１３をそれぞれ再設定可能な空きがあるとす
る。この場合、ＮＢＡＰプロトコルを用いて、ＢＴＳ５
および６に対し現在接続中であるＲＬ１１〜１３全ての
無線リンクを要求されたマルチコール用に再設定する。
そして、これらの無線リンクの再設定が完了した後、Ｒ
ＮＣ４はＲＲＣプロトコルを用いてＵＥ７に対し物理チ
ャネルの再設定を行なうことでＲＬ１１〜１３に新規Ｒ
ＡＢを設定し、要求されたマルチコールの接続を完了す
る。
ＢＴＳ５のセル９とＵＥ７間およびＢＴＳ６のセル１０
とＵＥ７間それぞれで使用可能な無線リソースには、Ｒ
Ｌ１１〜１３をそれぞれ再設定可能な空きがあるとす
る。この場合、ＮＢＡＰプロトコルを用いて、ＢＴＳ５
および６に対し現在接続中であるＲＬ１１〜１３全ての
無線リンクを要求されたマルチコール用に再設定する。
そして、これらの無線リンクの再設定が完了した後、Ｒ
ＮＣ４はＲＲＣプロトコルを用いてＵＥ７に対し物理チ
ャネルの再設定を行なうことでＲＬ１１〜１３に新規Ｒ
ＡＢを設定し、要求されたマルチコールの接続を完了す
る。
【００４０】一方、ＲＮＣ４の検知の結果、ＢＴＳ６の
セル１０とＵＥ７間で使用可能な無線リソースには、Ｒ
Ｌ１３を再設定可能な空きがあり、ＢＴＳ５のセル８と
ＵＥ７間、ＢＴＳ５のセル９とＵＥ７間それぞれで使用
可能な無線リソースには、ＲＬ１１、ＲＬ１２を再設定
可能な空きがないとする。この場合、ＲＮＣ４は、ＲＲ
Ｃプロトコルを用いてＵＥ７に対し、ＮＢＡＰプロトコ
ルを用いてＢＴＳ５に対し、現在接続中であるＲＬ１１
および１２を解放するように指示する。また、ＢＴＳ６
に対しては、ＮＢＡＰプロトコルを用いて現在接続中で
あるＲＬ１３を要求されたマルチコール用に再設定す
る。そして、ＲＬ１３の再設定が完了した後、ＲＮＣ４
はＲＲＣプロトコルを用いてＵＥ７に対し物理チャネル
の再設定を行なうことでＲＬ１３に新規ＲＡＢを設定
し、要求されたマルチコールの接続を完了する。
セル１０とＵＥ７間で使用可能な無線リソースには、Ｒ
Ｌ１３を再設定可能な空きがあり、ＢＴＳ５のセル８と
ＵＥ７間、ＢＴＳ５のセル９とＵＥ７間それぞれで使用
可能な無線リソースには、ＲＬ１１、ＲＬ１２を再設定
可能な空きがないとする。この場合、ＲＮＣ４は、ＲＲ
Ｃプロトコルを用いてＵＥ７に対し、ＮＢＡＰプロトコ
ルを用いてＢＴＳ５に対し、現在接続中であるＲＬ１１
および１２を解放するように指示する。また、ＢＴＳ６
に対しては、ＮＢＡＰプロトコルを用いて現在接続中で
あるＲＬ１３を要求されたマルチコール用に再設定す
る。そして、ＲＬ１３の再設定が完了した後、ＲＮＣ４
はＲＲＣプロトコルを用いてＵＥ７に対し物理チャネル
の再設定を行なうことでＲＬ１３に新規ＲＡＢを設定
し、要求されたマルチコールの接続を完了する。
【００４１】ここで、無線リソースとＲＬの関係につい
て詳しく説明する。Ｗ−ＣＤＭＡ通信システムにおける
具体的な無線リソースとしては、チャネライゼーション
コードが挙げられ、このチャネライゼーションコードの
拡散率（Spreading Factor，SF）により、コードを割り
当てられたＲＬにおいて送信できるデータの伝送速度が
決まる。例えば、ダウンリンク（ＤＬ）の個別物理チャ
ネル（ＤＰＣＨ）の場合、ＳＦ値６４であれば９０ｋｂ
ｐｓ、ＳＦ値３２であれば２１０ｋｂｐｓが最大伝送速
度として規定されている。また、チャネライゼーション
コードは有限な資源であり、各ＳＦにおいてＳＦ個（Ｓ
Ｆ値６４であれば６４個）のチャネライゼーションコー
ドが存在する。
て詳しく説明する。Ｗ−ＣＤＭＡ通信システムにおける
具体的な無線リソースとしては、チャネライゼーション
コードが挙げられ、このチャネライゼーションコードの
拡散率（Spreading Factor，SF）により、コードを割り
当てられたＲＬにおいて送信できるデータの伝送速度が
決まる。例えば、ダウンリンク（ＤＬ）の個別物理チャ
ネル（ＤＰＣＨ）の場合、ＳＦ値６４であれば９０ｋｂ
ｐｓ、ＳＦ値３２であれば２１０ｋｂｐｓが最大伝送速
度として規定されている。また、チャネライゼーション
コードは有限な資源であり、各ＳＦにおいてＳＦ個（Ｓ
Ｆ値６４であれば６４個）のチャネライゼーションコー
ドが存在する。
【００４２】本実施の形態１において、ＵＥ７がＲＬ上
での伝送速度６４ｋｂｐｓのデータ通信を行なっている
場合、ＲＬ１１〜１３には、それぞれＳＦ値が６４のチ
ャネライゼーションコードが割り当てられている。この
状態から、例えば、ＲＬ上での伝送速度６４ｋｂｐｓの
音声通信を追加するマルチコールを行なおうとすると、
ＲＬの伝送速度として１２８ｋｂｐｓ以上（データ通信
６４ｋｂｐｓ＋音声通信６４ｋｂｐｓ＋シグナリング
用）が要求される。しかし、既に設定されているＲＬ１
１〜１３に許容される伝送速度は９０ｋｂｐｓであるの
で、伝送速度１２８ｋｂｐｓのデータを送信するために
は、各ＲＬに伝送速度の高いチャネライゼーションコー
ド、この場合ＳＦ値３２（最大伝送速度２１０ｋｂｐ
ｓ）のコードを割り当ててＲＬを再設定する必要があ
る。
での伝送速度６４ｋｂｐｓのデータ通信を行なっている
場合、ＲＬ１１〜１３には、それぞれＳＦ値が６４のチ
ャネライゼーションコードが割り当てられている。この
状態から、例えば、ＲＬ上での伝送速度６４ｋｂｐｓの
音声通信を追加するマルチコールを行なおうとすると、
ＲＬの伝送速度として１２８ｋｂｐｓ以上（データ通信
６４ｋｂｐｓ＋音声通信６４ｋｂｐｓ＋シグナリング
用）が要求される。しかし、既に設定されているＲＬ１
１〜１３に許容される伝送速度は９０ｋｂｐｓであるの
で、伝送速度１２８ｋｂｐｓのデータを送信するために
は、各ＲＬに伝送速度の高いチャネライゼーションコー
ド、この場合ＳＦ値３２（最大伝送速度２１０ｋｂｐ
ｓ）のコードを割り当ててＲＬを再設定する必要があ
る。
【００４３】チャネライゼーションコードには、図２の
コードツリーに示すような上下依存関係がある。図２
は、一つのＲＬ、例えばＲＬ１１に対応する基地局（Ｂ
ＴＳ５のセル８）と移動端末（ＵＥ７）間の無線リソー
スの一例を表わしており、Ｃｘ ，ｙはＳＦ値ｘのｙ番目
（ｙ＝０，１，・・・，ｘ−１）のチャネライゼーショ
ンコードを示す。データ通信のみを行なっているＲＬ１
１にＣ６４，０が割り当てられているとすると、コード
ツリーにおいてＣ６４，０に連なる上位のコード（Ｃ
１６，０、Ｃ３２，０等）や下位のコード（Ｃ
１２８，０、Ｃ１２８，１等）も使用していることとな
り、他で使用することができない。
コードツリーに示すような上下依存関係がある。図２
は、一つのＲＬ、例えばＲＬ１１に対応する基地局（Ｂ
ＴＳ５のセル８）と移動端末（ＵＥ７）間の無線リソー
スの一例を表わしており、Ｃｘ ，ｙはＳＦ値ｘのｙ番目
（ｙ＝０，１，・・・，ｘ−１）のチャネライゼーショ
ンコードを示す。データ通信のみを行なっているＲＬ１
１にＣ６４，０が割り当てられているとすると、コード
ツリーにおいてＣ６４，０に連なる上位のコード（Ｃ
１６，０、Ｃ３２，０等）や下位のコード（Ｃ
１２８，０、Ｃ１２８，１等）も使用していることとな
り、他で使用することができない。
【００４４】そこで、上記マルチコールの要求によりＳ
Ｆ値３２のコードを割り当てるために、まずＣ６４，１
の使用状況を確認する。Ｃ６４，１が空いている場合、
現在使用中であるＣ６４，０を解放してＣ３２，０を空
き状態とし、Ｃ３２，０を割り当てることでＲＬ１１を
再設定することができる。一方、Ｃ６４，１が使用中の
場合（Ｃ１２８，２またはＣ１２８，３が使用中の場合
を含む）は、Ｃ６４， ０を解放してもＣ３２，０を使用
できないので、これ以外のＳＦ値３２のコードであるＣ
３２，１の使用状況を確認する。Ｃ３２，１が空いてい
る場合はこれを割り当てることでＲＬ１１を再設定する
ことができるが、使用中の場合はＲＬ１１を再設定でき
ない。すなわち無線リソースの空きが、ＲＬ１１を再設
定可能な所定量に足りないこととなる。
Ｆ値３２のコードを割り当てるために、まずＣ６４，１
の使用状況を確認する。Ｃ６４，１が空いている場合、
現在使用中であるＣ６４，０を解放してＣ３２，０を空
き状態とし、Ｃ３２，０を割り当てることでＲＬ１１を
再設定することができる。一方、Ｃ６４，１が使用中の
場合（Ｃ１２８，２またはＣ１２８，３が使用中の場合
を含む）は、Ｃ６４， ０を解放してもＣ３２，０を使用
できないので、これ以外のＳＦ値３２のコードであるＣ
３２，１の使用状況を確認する。Ｃ３２，１が空いてい
る場合はこれを割り当てることでＲＬ１１を再設定する
ことができるが、使用中の場合はＲＬ１１を再設定でき
ない。すなわち無線リソースの空きが、ＲＬ１１を再設
定可能な所定量に足りないこととなる。
【００４５】さらに、図３を用いて、マルチコールを受
け付けた後、無線リソースの足りないＲＬ１１および１
２を解放し、無線リソースの足りているＲＬ１３を再設
定する具体的な手順について図３を用いて説明する。無
線リソースが十分にあり、全てのＲＬ１１〜１３を再設
定する具体的な手順については、従来の手順である図１
５に示すものと同じであるため説明を省略する。
け付けた後、無線リソースの足りないＲＬ１１および１
２を解放し、無線リソースの足りているＲＬ１３を再設
定する具体的な手順について図３を用いて説明する。無
線リソースが十分にあり、全てのＲＬ１１〜１３を再設
定する具体的な手順については、従来の手順である図１
５に示すものと同じであるため説明を省略する。
【００４６】図３は、ソフトハンドオーバ時のマルチコ
ール接続手順の一例を示すシーケンス図である。初期状
態として、前述のとおり、ＲＮＣ４の制御によってＵＥ
７はＢＴＳ５および６に対しソフトハンドオーバ状態に
あり、すでに呼接続されＲＡＢ１４を用いてデータ通信
を行なっている。
ール接続手順の一例を示すシーケンス図である。初期状
態として、前述のとおり、ＲＮＣ４の制御によってＵＥ
７はＢＴＳ５および６に対しソフトハンドオーバ状態に
あり、すでに呼接続されＲＡＢ１４を用いてデータ通信
を行なっている。
【００４７】まず、この状態において、ＲＮＣ４は新規
ＲＡＢの設定要求を受け付ける（３００）。すでにＲＡ
Ｂ１４が設定されているので、これは追加される呼であ
りマルチコール要求の受け付けとなる。ＲＮＣ４は無線
リソースの空きを検知した結果、ＲＬ１３に対して新規
ＲＡＢを設定する為に必要な無線リソースを確保する。
前提のとおり、ＲＬ１１および１２に対しては無線リソ
ースの空きが不足しているので、無線リソースを確保で
きない。
ＲＡＢの設定要求を受け付ける（３００）。すでにＲＡ
Ｂ１４が設定されているので、これは追加される呼であ
りマルチコール要求の受け付けとなる。ＲＮＣ４は無線
リソースの空きを検知した結果、ＲＬ１３に対して新規
ＲＡＢを設定する為に必要な無線リソースを確保する。
前提のとおり、ＲＬ１１および１２に対しては無線リソ
ースの空きが不足しているので、無線リソースを確保で
きない。
【００４８】次に、ＲＮＣ４はＵＥ７に対し"Active Se
t Update"メッセージ３０１を送信して、ＲＬ１１およ
び１２の削除を要求する。"Active Set Update"メッセ
ージ３０１は、図４に示す情報要素で構成されており、
ＵＥ７はこのうち"Radio link removal information"４
００を受信することで、これに含まれる"Primary scram
bling code"情報で特定されるＲＬ１１および１２の削
除動作を行ない、"Active Set Update Complete"メッセ
ージ３０２をＲＮＣ４へ送信して完了したことを通知す
る。
t Update"メッセージ３０１を送信して、ＲＬ１１およ
び１２の削除を要求する。"Active Set Update"メッセ
ージ３０１は、図４に示す情報要素で構成されており、
ＵＥ７はこのうち"Radio link removal information"４
００を受信することで、これに含まれる"Primary scram
bling code"情報で特定されるＲＬ１１および１２の削
除動作を行ない、"Active Set Update Complete"メッセ
ージ３０２をＲＮＣ４へ送信して完了したことを通知す
る。
【００４９】また次に、ＲＮＣ４はＢＴＳ５に対し"Rad
io Link Deletion Request"メッセージ３０３を送信し
て、ＲＬ１１および１２の削除を要求する。ＢＴＳ６に
対しては、"Radio Link Reconfiguration Prepare"メッ
セージ３０４を送信して、ＲＬ１３を要求されたマルチ
コール用に再設定する準備を行なう。"Radio Link Dele
tion Request"メッセージ３０３を受信したＢＴＳ５
は、ＲＬ１１および１２の削除動作を行ない、"Radio L
ink Deletion Response"メッセージ３０５をＲＮＣ４へ
送信して完了したことを通知する。"Radio Link Reconf
iguration Prepare"メッセージ３０４を受信したＢＴＳ
６は、ＲＮＣ４に対し"Radio Link Reconfiguration Re
ady"メッセージ３０６を送信して、無線リンクを再設定
する準備が完了したことを通知する。
io Link Deletion Request"メッセージ３０３を送信し
て、ＲＬ１１および１２の削除を要求する。ＢＴＳ６に
対しては、"Radio Link Reconfiguration Prepare"メッ
セージ３０４を送信して、ＲＬ１３を要求されたマルチ
コール用に再設定する準備を行なう。"Radio Link Dele
tion Request"メッセージ３０３を受信したＢＴＳ５
は、ＲＬ１１および１２の削除動作を行ない、"Radio L
ink Deletion Response"メッセージ３０５をＲＮＣ４へ
送信して完了したことを通知する。"Radio Link Reconf
iguration Prepare"メッセージ３０４を受信したＢＴＳ
６は、ＲＮＣ４に対し"Radio Link Reconfiguration Re
ady"メッセージ３０６を送信して、無線リンクを再設定
する準備が完了したことを通知する。
【００５０】さらに、"Radio Link Reconfiguration Re
ady"メッセージ３０６を受信したＲＮＣ４は、ＢＴＳ６
がＲＬ１１〜１３を再設定する準備を完了したことを知
り、ＢＴＳ６に対して"Radio Link Reconfiguration Co
mmit"メッセージ３０７を送信して、ＲＬ１３を要求さ
れたマルチコール用に再設定する。ＵＥ７に対して
は、"Physical Channel Reconfiguration"メッセージ３
０８を送信して、ＲＬ１３で用いられる物理チャネルの
再設定を行なう。"Physical Channel Reconfiguration"
メッセージ３０８を受信したＵＥ７は、所定の手順で物
理チャネルを再設定して、ＲＮＣ４に対し"Physical Ch
annel Reconfiguration Complete"メッセージ３０９を
送信する。これにより、データ通信に加え新規ＲＡＢを
用いたサービス、例えば音声通信が始められ、マルチコ
ール接続が完了する（３１０）。
ady"メッセージ３０６を受信したＲＮＣ４は、ＢＴＳ６
がＲＬ１１〜１３を再設定する準備を完了したことを知
り、ＢＴＳ６に対して"Radio Link Reconfiguration Co
mmit"メッセージ３０７を送信して、ＲＬ１３を要求さ
れたマルチコール用に再設定する。ＵＥ７に対して
は、"Physical Channel Reconfiguration"メッセージ３
０８を送信して、ＲＬ１３で用いられる物理チャネルの
再設定を行なう。"Physical Channel Reconfiguration"
メッセージ３０８を受信したＵＥ７は、所定の手順で物
理チャネルを再設定して、ＲＮＣ４に対し"Physical Ch
annel Reconfiguration Complete"メッセージ３０９を
送信する。これにより、データ通信に加え新規ＲＡＢを
用いたサービス、例えば音声通信が始められ、マルチコ
ール接続が完了する（３１０）。
【００５１】上記により、ソフトハンドオーバ状態にあ
るＵＥに対しマルチコールの要求が発生した際、接続中
の複数のＲＬのうち、一部のＲＬについて再設定する無
線リソースを確保できない場合でも、他のＲＬを再設定
することによりマルチコールの接続が可能となり、マル
チコールに対する呼損率を低くすることができる。
るＵＥに対しマルチコールの要求が発生した際、接続中
の複数のＲＬのうち、一部のＲＬについて再設定する無
線リソースを確保できない場合でも、他のＲＬを再設定
することによりマルチコールの接続が可能となり、マル
チコールに対する呼損率を低くすることができる。
【００５２】また、ソフトハンドオーバ状態において、
接続中のＲＬを減らすと受信品質が低下する場合がある
が、マルチコール要求の受け付け時に無線リソースの空
きを検知し、空きが足りない無線リソースに対応するＲ
Ｌを解放するようにしたので、無線リソースの空きに応
じ、不要な受信品質の低下を防ぐことができる。
接続中のＲＬを減らすと受信品質が低下する場合がある
が、マルチコール要求の受け付け時に無線リソースの空
きを検知し、空きが足りない無線リソースに対応するＲ
Ｌを解放するようにしたので、無線リソースの空きに応
じ、不要な受信品質の低下を防ぐことができる。
【００５３】尚、少なくとも一つのＲＬをマルチコール
用に再設定すれば、解放するＲＬは、空きが足りない無
線リソースに対応するＲＬのみとしても、それ以外のＲ
Ｌを含んでいてもよい。空きが足りない無線リソースに
対応するＲＬのみを解放し、それ以外のＲＬをすべてマ
ルチコール用に再設定するようにした場合は、ソフトハ
ンドオーバ状態を維持できる可能性が高くなり、不要な
受信品質の低下をさらに防ぐことができる。
用に再設定すれば、解放するＲＬは、空きが足りない無
線リソースに対応するＲＬのみとしても、それ以外のＲ
Ｌを含んでいてもよい。空きが足りない無線リソースに
対応するＲＬのみを解放し、それ以外のＲＬをすべてマ
ルチコール用に再設定するようにした場合は、ソフトハ
ンドオーバ状態を維持できる可能性が高くなり、不要な
受信品質の低下をさらに防ぐことができる。
【００５４】さらに、無線リソースの空きを検知するこ
となく、すなわち再設定が可能であっても一部のＲＬを
解放するような設定にしてもよい。この場合、例えば、
使用される移動端末が多く常に無線リソースが不足しが
ちであって、かつ電波環境が良く受信品質には問題がな
いようなサービスエリアにおいて、一つの移動端末にお
ける無線リソースの使用を削減し、他の移動端末の呼損
率を低下させることができるという効果を生じる。
となく、すなわち再設定が可能であっても一部のＲＬを
解放するような設定にしてもよい。この場合、例えば、
使用される移動端末が多く常に無線リソースが不足しが
ちであって、かつ電波環境が良く受信品質には問題がな
いようなサービスエリアにおいて、一つの移動端末にお
ける無線リソースの使用を削減し、他の移動端末の呼損
率を低下させることができるという効果を生じる。
【００５５】実施の形態２．次に、本発明の実施の形態
２を説明する。本実施の形態２は、マルチコールを受け
付けた後、無線リソースの足りないＲＬ１１および１２
を解放し、無線リソースの足りているＲＬ１３を再設定
する手順について、実施の形態１と異なる方法を示すも
のである。
２を説明する。本実施の形態２は、マルチコールを受け
付けた後、無線リソースの足りないＲＬ１１および１２
を解放し、無線リソースの足りているＲＬ１３を再設定
する手順について、実施の形態１と異なる方法を示すも
のである。
【００５６】この方法を実現するために、物理チャネル
の再設定の為に送信する"PhysicalChannel Reconfigura
tion"メッセージに対し、情報要素"Radio link removal
information"を追加する。この情報要素は、従来の"Ac
tive Set Update"メッセージに含まれている情報要素と
同様の内容である。これにより、ＲＮＣ４は削除対象と
なるＲＬの情報を"Physical Channel Reconfiguration"
メッセージでＵＥ７へ通知することが可能となり、"Act
ive Set Update"手順が不要となる。具体的な手順につ
いて以下に説明する。
の再設定の為に送信する"PhysicalChannel Reconfigura
tion"メッセージに対し、情報要素"Radio link removal
information"を追加する。この情報要素は、従来の"Ac
tive Set Update"メッセージに含まれている情報要素と
同様の内容である。これにより、ＲＮＣ４は削除対象と
なるＲＬの情報を"Physical Channel Reconfiguration"
メッセージでＵＥ７へ通知することが可能となり、"Act
ive Set Update"手順が不要となる。具体的な手順につ
いて以下に説明する。
【００５７】図５は、本実施の形態２のソフトハンドオ
ーバ時のマルチコール接続手順を示すシーケンス図であ
る。初期状態として、前述のとおり、ＲＮＣ４の制御に
よってＵＥ７はＢＴＳ５および６に対しソフトハンドオ
ーバ状態にあり、すでに呼接続されＲＡＢ１４を用いて
データ通信を行なっている。
ーバ時のマルチコール接続手順を示すシーケンス図であ
る。初期状態として、前述のとおり、ＲＮＣ４の制御に
よってＵＥ７はＢＴＳ５および６に対しソフトハンドオ
ーバ状態にあり、すでに呼接続されＲＡＢ１４を用いて
データ通信を行なっている。
【００５８】まず、この状態において、ＲＮＣ４は新規
ＲＡＢの設定要求を受け付ける（５００）。すでにＲＡ
Ｂ１４が設定されているので、これは追加される呼であ
りマルチコール要求の受け付けとなる。ＲＮＣ４は無線
リソースの空きを検知した結果、ＲＬ１３に対して新規
ＲＡＢを設定する為に必要な無線リソースを確保する。
ＲＬ１１および１２に対しては無線リソースの空きが不
足しているので、無線リソースを確保できない。
ＲＡＢの設定要求を受け付ける（５００）。すでにＲＡ
Ｂ１４が設定されているので、これは追加される呼であ
りマルチコール要求の受け付けとなる。ＲＮＣ４は無線
リソースの空きを検知した結果、ＲＬ１３に対して新規
ＲＡＢを設定する為に必要な無線リソースを確保する。
ＲＬ１１および１２に対しては無線リソースの空きが不
足しているので、無線リソースを確保できない。
【００５９】次に、ＲＮＣ４はＢＴＳ５に対し"Radio L
ink Deletion Request"メッセージ５０１を送信して、
ＲＬ１１および１２の削除を要求する。ＢＴＳ６に対し
ては、"Radio Link Reconfiguration Prepare"メッセー
ジ５０２を送信して、ＲＬ１３を要求されたマルチコー
ル用に再設定する準備を行なう。"Radio Link Deletion
Request"メッセージ５０１を受信したＢＴＳ５は、Ｒ
Ｌ１１および１２の削除動作を行ない、"Radio Link De
letion Response"メッセージ５０３をＲＮＣ４へ送信し
て完了したことを通知する。"Radio Link Reconfigurat
ion Prepare"メッセージ５０２を受信したＢＴＳ６は、
ＲＮＣ４に対し"Radio Link Reconfiguration Ready"メ
ッセージ５０４を送信して、無線リンクを再設定する準
備が完了したことを通知する。
ink Deletion Request"メッセージ５０１を送信して、
ＲＬ１１および１２の削除を要求する。ＢＴＳ６に対し
ては、"Radio Link Reconfiguration Prepare"メッセー
ジ５０２を送信して、ＲＬ１３を要求されたマルチコー
ル用に再設定する準備を行なう。"Radio Link Deletion
Request"メッセージ５０１を受信したＢＴＳ５は、Ｒ
Ｌ１１および１２の削除動作を行ない、"Radio Link De
letion Response"メッセージ５０３をＲＮＣ４へ送信し
て完了したことを通知する。"Radio Link Reconfigurat
ion Prepare"メッセージ５０２を受信したＢＴＳ６は、
ＲＮＣ４に対し"Radio Link Reconfiguration Ready"メ
ッセージ５０４を送信して、無線リンクを再設定する準
備が完了したことを通知する。
【００６０】また次に、"Radio Link Reconfiguration
Ready"メッセージ５０４を受信したＲＮＣ４は、ＢＴＳ
６がＲＬ１１〜１３を再設定する準備を完了したことを
知り、ＢＴＳ６に対して"Radio Link Reconfiguration
Commit"メッセージ５０５を送信して、ＲＬ１３を要求
されたマルチコール用に再設定する。
Ready"メッセージ５０４を受信したＲＮＣ４は、ＢＴＳ
６がＲＬ１１〜１３を再設定する準備を完了したことを
知り、ＢＴＳ６に対して"Radio Link Reconfiguration
Commit"メッセージ５０５を送信して、ＲＬ１３を要求
されたマルチコール用に再設定する。
【００６１】さらに、ＵＥ７に対し"Physical Channel
Reconfiguration"メッセージ５０６を送信する。この"P
hysical Channel Reconfiguration"メッセージ５０６に
は、前述のとおり情報要素"Radio link removal inform
ation"が追加されている。ＵＥ７は、"Physical Channe
l Reconfiguration"メッセージ５０６を受信すると、情
報要素"Radio link removal information"に含まれる"P
rimary scrambling code"情報で特定されるＲＬ１１お
よび１２を削除する動作を行なうとともに、所定の手順
でＲＬ１３で用いられる物理チャネルを再設定する。そ
して、ＲＮＣ４に対し"Physical Channel Reconfigurat
ion Complete"メッセージ５０７を送信する。これによ
り、データ通信に加え新規ＲＡＢを用いたサービスが始
められ、マルチコール接続が完了する（５０８）。
Reconfiguration"メッセージ５０６を送信する。この"P
hysical Channel Reconfiguration"メッセージ５０６に
は、前述のとおり情報要素"Radio link removal inform
ation"が追加されている。ＵＥ７は、"Physical Channe
l Reconfiguration"メッセージ５０６を受信すると、情
報要素"Radio link removal information"に含まれる"P
rimary scrambling code"情報で特定されるＲＬ１１お
よび１２を削除する動作を行なうとともに、所定の手順
でＲＬ１３で用いられる物理チャネルを再設定する。そ
して、ＲＮＣ４に対し"Physical Channel Reconfigurat
ion Complete"メッセージ５０７を送信する。これによ
り、データ通信に加え新規ＲＡＢを用いたサービスが始
められ、マルチコール接続が完了する（５０８）。
【００６２】上記により、ソフトハンドオーバ状態にあ
るＵＥに対しマルチコールの要求が発生した際、接続中
の複数のＲＬのうち、一部のＲＬについて再設定する無
線リソースを確保できない場合でもマルチコールの接続
が可能となり、マルチコールに対する呼損率を低くする
ことができる。
るＵＥに対しマルチコールの要求が発生した際、接続中
の複数のＲＬのうち、一部のＲＬについて再設定する無
線リソースを確保できない場合でもマルチコールの接続
が可能となり、マルチコールに対する呼損率を低くする
ことができる。
【００６３】また、ＲＮＣ４とＵＥ７間の手順におい
て、"Active Set Update"手順を不要とすることによ
り、ＲＮＣ４からＵＥ７への"Active Set Update"メッ
セージ、ＵＥ７からＲＮＣ４への"Active Set Update C
omplete"メッセージが送信されないので、無線リソース
の有効利用が図れる。
て、"Active Set Update"手順を不要とすることによ
り、ＲＮＣ４からＵＥ７への"Active Set Update"メッ
セージ、ＵＥ７からＲＮＣ４への"Active Set Update C
omplete"メッセージが送信されないので、無線リソース
の有効利用が図れる。
【００６４】実施の形態３．次に、本発明の実施の形態
３を説明する。本実施の形態３は、マルチコールを受け
付けた後、無線リソースの足りないＲＬ１１および１２
を解放し、無線リソースの足りているＲＬ１３を再設定
する手順について、実施の形態１および２と異なる方法
を示すものである。
３を説明する。本実施の形態３は、マルチコールを受け
付けた後、無線リソースの足りないＲＬ１１および１２
を解放し、無線リソースの足りているＲＬ１３を再設定
する手順について、実施の形態１および２と異なる方法
を示すものである。
【００６５】この方法を実現するために、ＵＥ７に対し
以下の機能を追加する。すなわち、ＵＥ７は、図６に示
す情報要素で構成されている"Physical Channel Reconf
iguration"メッセージをＲＮＣ４から受信すると、情報
要素"Downlink Informationper radio link list"情報
６００を読み取る。そして、接続中のＲＬのうち、こ
の"Downlink Information per radio link list"情報６
００にその情報が含まれていないＲＬを削除する動作を
行なう。これにより、ＲＮＣ４は削除対象となるＲＬの
情報を"Physical Channel Reconfiguration"メッセージ
でＵＥ７へ通知することが可能となり、"Active Set Up
date"手順が不要となる。具体的な手順について以下に
説明する。
以下の機能を追加する。すなわち、ＵＥ７は、図６に示
す情報要素で構成されている"Physical Channel Reconf
iguration"メッセージをＲＮＣ４から受信すると、情報
要素"Downlink Informationper radio link list"情報
６００を読み取る。そして、接続中のＲＬのうち、こ
の"Downlink Information per radio link list"情報６
００にその情報が含まれていないＲＬを削除する動作を
行なう。これにより、ＲＮＣ４は削除対象となるＲＬの
情報を"Physical Channel Reconfiguration"メッセージ
でＵＥ７へ通知することが可能となり、"Active Set Up
date"手順が不要となる。具体的な手順について以下に
説明する。
【００６６】図７は、本実施の形態３のソフトハンドオ
ーバ時のマルチコール接続手順を示すシーケンス図であ
る。初期状態として、前述のとおり、ＲＮＣ４の制御に
よってＵＥ７はＢＴＳ５および６に対しソフトハンドオ
ーバ状態にあり、すでに呼接続されＲＡＢ１４を用いて
データ通信を行なっている。
ーバ時のマルチコール接続手順を示すシーケンス図であ
る。初期状態として、前述のとおり、ＲＮＣ４の制御に
よってＵＥ７はＢＴＳ５および６に対しソフトハンドオ
ーバ状態にあり、すでに呼接続されＲＡＢ１４を用いて
データ通信を行なっている。
【００６７】まず、この状態において、ＲＮＣ４は新規
ＲＡＢの設定要求を受け付ける（７００）。すでにＲＡ
Ｂ１４が設定されているので、これは追加される呼であ
りマルチコール要求の受け付けとなる。ＲＮＣ４は無線
リソースの空きを検知した結果、ＲＬ１３に対して新規
ＲＡＢを設定する為に必要な無線リソースを確保する。
ＲＬ１１および１２に対しては無線リソースの空きが不
足しているので、無線リソースを確保できない。
ＲＡＢの設定要求を受け付ける（７００）。すでにＲＡ
Ｂ１４が設定されているので、これは追加される呼であ
りマルチコール要求の受け付けとなる。ＲＮＣ４は無線
リソースの空きを検知した結果、ＲＬ１３に対して新規
ＲＡＢを設定する為に必要な無線リソースを確保する。
ＲＬ１１および１２に対しては無線リソースの空きが不
足しているので、無線リソースを確保できない。
【００６８】次に、ＲＮＣ４はＢＴＳ５に対し"Radio L
ink Deletion Request"メッセージ７０１を送信して、
ＲＬ１１および１２の削除を要求する。ＢＴＳ６に対し
ては、"Radio Link Reconfiguration Prepare"メッセー
ジ７０２を送信して、ＲＬ１３を要求されたマルチコー
ル用に再設定する準備を行なう。"Radio Link Deletion
Request"メッセージ７０１を受信したＢＴＳ５は、Ｒ
Ｌ１１および１２の削除動作を行ない、"Radio Link De
letion Response"メッセージ７０３をＲＮＣ４へ送信し
て完了したことを通知する。"Radio Link Reconfigurat
ion Prepare"メッセージ７０２を受信したＢＴＳ６は、
ＲＮＣ４に対し"Radio Link Reconfiguration Ready"メ
ッセージ７０４を送信して、無線リンクを再設定する準
備が完了したことを通知する。
ink Deletion Request"メッセージ７０１を送信して、
ＲＬ１１および１２の削除を要求する。ＢＴＳ６に対し
ては、"Radio Link Reconfiguration Prepare"メッセー
ジ７０２を送信して、ＲＬ１３を要求されたマルチコー
ル用に再設定する準備を行なう。"Radio Link Deletion
Request"メッセージ７０１を受信したＢＴＳ５は、Ｒ
Ｌ１１および１２の削除動作を行ない、"Radio Link De
letion Response"メッセージ７０３をＲＮＣ４へ送信し
て完了したことを通知する。"Radio Link Reconfigurat
ion Prepare"メッセージ７０２を受信したＢＴＳ６は、
ＲＮＣ４に対し"Radio Link Reconfiguration Ready"メ
ッセージ７０４を送信して、無線リンクを再設定する準
備が完了したことを通知する。
【００６９】また次に、"Radio Link Reconfiguration
Ready"メッセージ７０４を受信したＲＮＣ４は、ＢＴＳ
６がＲＬ１１〜１３を再設定する準備を完了したことを
知り、ＢＴＳ６に対して"Radio Link Reconfiguration
Commit"メッセージ７０５を送信して、ＲＬ１３を要求
されたマルチコール用に再設定する。
Ready"メッセージ７０４を受信したＲＮＣ４は、ＢＴＳ
６がＲＬ１１〜１３を再設定する準備を完了したことを
知り、ＢＴＳ６に対して"Radio Link Reconfiguration
Commit"メッセージ７０５を送信して、ＲＬ１３を要求
されたマルチコール用に再設定する。
【００７０】さらに、ＲＮＣ４は、"Downlink Informat
ion per radio link list"情報６００にＲＬ１３の情報
が設定されていてＲＬ１１および１２の情報が設定され
ていない"Physical Channel Reconfiguration"メッセー
ジ７０６をＵＥ７に対し送信する。ＵＥ７はこの"Physi
cal Channel Reconfiguration"メッセージ７０６を受信
すると、前述のとおり情報要素"Downlink Information
per radio link list"情報６００を読み取る。そして、
接続中のＲＬ１１〜１３のうち、この"Downlink Inform
ation per radio link list"情報６００にその情報が含
まれていないＲＬ１１および１２を削除する動作を行な
うとともに、所定の手順でＲＬ１３で用いられる物理チ
ャネルを再設定する。そして、ＲＮＣ４に対し"Physica
l Channel Reconfiguration Complete"メッセージ７０
７を送信する。これにより、データ通信に加え新規ＲＡ
Ｂを用いたサービスが始められ、マルチコール接続が完
了する（７０８）。
ion per radio link list"情報６００にＲＬ１３の情報
が設定されていてＲＬ１１および１２の情報が設定され
ていない"Physical Channel Reconfiguration"メッセー
ジ７０６をＵＥ７に対し送信する。ＵＥ７はこの"Physi
cal Channel Reconfiguration"メッセージ７０６を受信
すると、前述のとおり情報要素"Downlink Information
per radio link list"情報６００を読み取る。そして、
接続中のＲＬ１１〜１３のうち、この"Downlink Inform
ation per radio link list"情報６００にその情報が含
まれていないＲＬ１１および１２を削除する動作を行な
うとともに、所定の手順でＲＬ１３で用いられる物理チ
ャネルを再設定する。そして、ＲＮＣ４に対し"Physica
l Channel Reconfiguration Complete"メッセージ７０
７を送信する。これにより、データ通信に加え新規ＲＡ
Ｂを用いたサービスが始められ、マルチコール接続が完
了する（７０８）。
【００７１】上記により、ソフトハンドオーバ状態にあ
るＵＥに対しマルチコールの要求が発生した際、接続中
の複数のＲＬのうち、一部のＲＬについて再設定する無
線リソースを確保できない場合でもマルチコールの接続
が可能となり、マルチコールに対する呼損率を低くする
ことができる。
るＵＥに対しマルチコールの要求が発生した際、接続中
の複数のＲＬのうち、一部のＲＬについて再設定する無
線リソースを確保できない場合でもマルチコールの接続
が可能となり、マルチコールに対する呼損率を低くする
ことができる。
【００７２】また、ＲＮＣ４とＵＥ７間の手順におい
て、"Active Set Update"手順を不要とすることによ
り、ＲＮＣ４からＵＥ７への"Active Set Update"メッ
セージ、ＵＥ７からＲＮＣ４への"Active Set Update C
omplete"メッセージを送信しないので、無線リソースの
有効利用が図れる。
て、"Active Set Update"手順を不要とすることによ
り、ＲＮＣ４からＵＥ７への"Active Set Update"メッ
セージ、ＵＥ７からＲＮＣ４への"Active Set Update C
omplete"メッセージを送信しないので、無線リソースの
有効利用が図れる。
【００７３】さらに、移動端末にソフトウエアの変更で
実現可能な機能を追加するだけなので、実施が容易であ
る。
実現可能な機能を追加するだけなので、実施が容易であ
る。
【００７４】実施の形態４．次に、本発明の実施の形態
４を説明する。本実施の形態４は、マルチコールを受け
付けた後、無線リソースの足りないＲＬ１１および１２
を解放し、無線リソースの足りているＲＬ１３を再設定
する手順について、さらに異なる方法を示すものであ
る。上記実施の形態３では、ＲＮＣ４はＵＥ７に対する
ＲＬの再設定を、物理チャネルの再設定を指示する"Phy
sical Channel Reconfiguration"手順を用いて行なって
いるが、本実施の形態４は、"Transport Channel Recon
figuration"手順を用いて行なう。この場合、ＵＥ７に
は、図８に示す情報要素で構成されている"Transport C
hannel Reconfiguration"メッセージをＲＮＣ４から受
信すると、接続中のＲＬのうち、情報要素"Downlink In
formation per radio link list"情報８００にその情報
が含まれていないＲＬを削除するという機能を追加す
る。
４を説明する。本実施の形態４は、マルチコールを受け
付けた後、無線リソースの足りないＲＬ１１および１２
を解放し、無線リソースの足りているＲＬ１３を再設定
する手順について、さらに異なる方法を示すものであ
る。上記実施の形態３では、ＲＮＣ４はＵＥ７に対する
ＲＬの再設定を、物理チャネルの再設定を指示する"Phy
sical Channel Reconfiguration"手順を用いて行なって
いるが、本実施の形態４は、"Transport Channel Recon
figuration"手順を用いて行なう。この場合、ＵＥ７に
は、図８に示す情報要素で構成されている"Transport C
hannel Reconfiguration"メッセージをＲＮＣ４から受
信すると、接続中のＲＬのうち、情報要素"Downlink In
formation per radio link list"情報８００にその情報
が含まれていないＲＬを削除するという機能を追加す
る。
【００７５】具体的な手順は図９に示すシーケンス図の
とおりであり、符号９００、９０１、・・・、９０５で示
す手順またはメッセージは、それぞれ図７の７００、７
０１、・・・、７０５と同様であるので説明を省略する。
ＲＮＣ４はメッセージ９０５を送信した後、"Downlink
Information per radio link list"情報８００にＲＬ１
３の情報が設定されていてＲＬ１１および１２の情報が
設定されていない"Transport Channel Reconfiguratio
n"メッセージ９０６をＵＥ７に対し送信する。ＵＥ７は
この"Transport Channel Reconfiguration"メッセージ
９０６を受信すると、前述のとおり接続中のＲＬ１１〜
１３のうち、情報要素"Downlink Information per radi
o link list"情報８００にその情報が含まれていないＲ
Ｌ１１および１２を削除する動作を行なうとともに、所
定の手順でＲＬ１３で用いられるトランスポートチャネ
ルを再設定する。そして、ＲＮＣ４に対し"Transport C
hannel Reconfiguration Complete"メッセージ９０７を
送信する。これにより、データ通信に加え新規ＲＡＢを
用いたサービスが始められ、マルチコール接続が完了す
る（９０８）。
とおりであり、符号９００、９０１、・・・、９０５で示
す手順またはメッセージは、それぞれ図７の７００、７
０１、・・・、７０５と同様であるので説明を省略する。
ＲＮＣ４はメッセージ９０５を送信した後、"Downlink
Information per radio link list"情報８００にＲＬ１
３の情報が設定されていてＲＬ１１および１２の情報が
設定されていない"Transport Channel Reconfiguratio
n"メッセージ９０６をＵＥ７に対し送信する。ＵＥ７は
この"Transport Channel Reconfiguration"メッセージ
９０６を受信すると、前述のとおり接続中のＲＬ１１〜
１３のうち、情報要素"Downlink Information per radi
o link list"情報８００にその情報が含まれていないＲ
Ｌ１１および１２を削除する動作を行なうとともに、所
定の手順でＲＬ１３で用いられるトランスポートチャネ
ルを再設定する。そして、ＲＮＣ４に対し"Transport C
hannel Reconfiguration Complete"メッセージ９０７を
送信する。これにより、データ通信に加え新規ＲＡＢを
用いたサービスが始められ、マルチコール接続が完了す
る（９０８）。
【００７６】上記により、ソフトハンドオーバ状態にあ
るＵＥに対しマルチコールの要求が発生した際、接続中
の複数のＲＬのうち、一部のＲＬについて再設定する無
線リソースを確保できない場合でもマルチコールの接続
が可能となり、マルチコールに対する呼損率を低くする
ことができる。
るＵＥに対しマルチコールの要求が発生した際、接続中
の複数のＲＬのうち、一部のＲＬについて再設定する無
線リソースを確保できない場合でもマルチコールの接続
が可能となり、マルチコールに対する呼損率を低くする
ことができる。
【００７７】また、ＲＮＣ４とＵＥ７間の手順におい
て、"Active Set Update"手順を不要とすることによ
り、ＲＮＣ４からＵＥ７への"Active Set Update"メッ
セージ、ＵＥ７からＲＮＣ４への"Active Set Update C
omplete"メッセージを送信しないので、無線リソースの
有効利用が図れる。
て、"Active Set Update"手順を不要とすることによ
り、ＲＮＣ４からＵＥ７への"Active Set Update"メッ
セージ、ＵＥ７からＲＮＣ４への"Active Set Update C
omplete"メッセージを送信しないので、無線リソースの
有効利用が図れる。
【００７８】さらに、移動端末にソフトウエアの変更で
実現可能な機能を追加するだけなので、実施が容易であ
る。
実現可能な機能を追加するだけなので、実施が容易であ
る。
【００７９】実施の形態５．次に、本発明の実施の形態
５を説明する。本実施の形態５は、マルチコールを受け
付けた後、無線リソースの足りないＲＬ１１および１２
を解放し、無線リソースの足りているＲＬ１３を再設定
する手順のうち、特にＲＮＣ−ＢＴＳ間の手順について
異なる方法を示すものである。上記実施の形態１乃至４
では、ＲＮＣ４−ＢＴＳ６間のＮＢＡＰによるＲＬ再設
定手順として同期手順を用いているが、これを非同期手
順を用いて行なう。例えば、上記実施の形態３の手順に
おいて本非同期手順を用いた場合の具体的な手順を、図
１０に示すシーケンス図を用いて説明する。
５を説明する。本実施の形態５は、マルチコールを受け
付けた後、無線リソースの足りないＲＬ１１および１２
を解放し、無線リソースの足りているＲＬ１３を再設定
する手順のうち、特にＲＮＣ−ＢＴＳ間の手順について
異なる方法を示すものである。上記実施の形態１乃至４
では、ＲＮＣ４−ＢＴＳ６間のＮＢＡＰによるＲＬ再設
定手順として同期手順を用いているが、これを非同期手
順を用いて行なう。例えば、上記実施の形態３の手順に
おいて本非同期手順を用いた場合の具体的な手順を、図
１０に示すシーケンス図を用いて説明する。
【００８０】図において、符号１０００、１００１、１
００３、１００５〜１００７で示す手順またはメッセー
ジは、それぞれ図７の７００、７０１、７０３、７０６
〜７０８と同様であるので説明を省略する。ＲＮＣ４は
ＢＴＳ６に対しＲＬの再設定を指示する際、"Radio Lin
k Reconfiguration Request"メッセージ１００２を送信
する。ＢＴＳ６はこのメッセージ１００２を受信する
と、指定されたＲＬの再設定を行ない、"Radio Link Re
configuration Response"メッセージ１００４をＲＮＣ
４へ送信する。
００３、１００５〜１００７で示す手順またはメッセー
ジは、それぞれ図７の７００、７０１、７０３、７０６
〜７０８と同様であるので説明を省略する。ＲＮＣ４は
ＢＴＳ６に対しＲＬの再設定を指示する際、"Radio Lin
k Reconfiguration Request"メッセージ１００２を送信
する。ＢＴＳ６はこのメッセージ１００２を受信する
と、指定されたＲＬの再設定を行ない、"Radio Link Re
configuration Response"メッセージ１００４をＲＮＣ
４へ送信する。
【００８１】非同期手順を用いた場合、同期手順と比較
して設定できるＲＬのパラメータが少なくなるが、本発
明のマルチコール接続を行なう情報は設定でき問題は生
じない。したがって、上記の非同期手順を用いることに
より、ＲＮＣ４とＢＴＳ６間の手順においてＲＮＣ４か
らＢＴＳ６へ送信するメッセージが削減され、リソース
の有効利用が図れるという効果を生じる。
して設定できるＲＬのパラメータが少なくなるが、本発
明のマルチコール接続を行なう情報は設定でき問題は生
じない。したがって、上記の非同期手順を用いることに
より、ＲＮＣ４とＢＴＳ６間の手順においてＲＮＣ４か
らＢＴＳ６へ送信するメッセージが削減され、リソース
の有効利用が図れるという効果を生じる。
【００８２】実施の形態６．次に、本発明の実施の形態
６を、図を用いて説明する。本実施の形態６に係るＷ−
ＣＤＭＡ通信システムのシステム構成は、図１に示すも
のと同一であるため説明を省略する。
６を、図を用いて説明する。本実施の形態６に係るＷ−
ＣＤＭＡ通信システムのシステム構成は、図１に示すも
のと同一であるため説明を省略する。
【００８３】図１において、１４はＵＥ７のユーザに対
し、すでに接続されているＲＬ１１〜１３を用いてサー
ビスを提供しているＲＡＢであり、１５は追加で要求さ
れたサービスを提供するＲＡＢである。これらのＲＡＢ
は、提供するサービス、保証する品質等により決定され
るトラヒッククラスを属性として有している。トラヒッ
ククラスは例えば、"Conversational"、"Streaming"、"
Background"に分類され、それぞれ「音声通信サービ
ス」、「映像などの配信サービス」等、「ウェブアクセ
ス（データ通信サービス）」等のサービスが対応する。
このうち、"Streaming"と"Background"の違いは、保証
レートの有無であり、"Background"では、レート保証を
行なわない。このようなトラヒッククラスの性質に基づ
き、それぞれの優先度を図１１に示すように定める。す
なわち、"Conversational"を優先度「高」、"Streamin
g"を優先度「中」、"Background"を優先度「低」とす
る。
し、すでに接続されているＲＬ１１〜１３を用いてサー
ビスを提供しているＲＡＢであり、１５は追加で要求さ
れたサービスを提供するＲＡＢである。これらのＲＡＢ
は、提供するサービス、保証する品質等により決定され
るトラヒッククラスを属性として有している。トラヒッ
ククラスは例えば、"Conversational"、"Streaming"、"
Background"に分類され、それぞれ「音声通信サービ
ス」、「映像などの配信サービス」等、「ウェブアクセ
ス（データ通信サービス）」等のサービスが対応する。
このうち、"Streaming"と"Background"の違いは、保証
レートの有無であり、"Background"では、レート保証を
行なわない。このようなトラヒッククラスの性質に基づ
き、それぞれの優先度を図１１に示すように定める。す
なわち、"Conversational"を優先度「高」、"Streamin
g"を優先度「中」、"Background"を優先度「低」とす
る。
【００８４】次に動作を、図１２を用いて説明する。Ｕ
Ｅ７はＲＬ１１〜１３の３つの無線リンクを接続して、
ＢＴＳ５および６に対しソフトハンドオーバ状態となっ
ており、ＲＡＢ１４を用いて通信を行なっている。ま
ず、ステップＳＴ１０１において、ＵＥ７が既に設定さ
れたＲＡＢ１４によるサービスを受けながら新たに追加
サービスを受けるべく、新規ＲＡＢの設定を要求する
（マルチコールの要求を行なう）。このマルチコール要
求を受け付けたＲＮＣ４は、無線リソースの空きを検知
し、ＲＬ１１〜１３すべてをマルチコール用に再設定す
るための無線リソースを確保できるか判断する（ステッ
プＳＴ１０２）。
Ｅ７はＲＬ１１〜１３の３つの無線リンクを接続して、
ＢＴＳ５および６に対しソフトハンドオーバ状態となっ
ており、ＲＡＢ１４を用いて通信を行なっている。ま
ず、ステップＳＴ１０１において、ＵＥ７が既に設定さ
れたＲＡＢ１４によるサービスを受けながら新たに追加
サービスを受けるべく、新規ＲＡＢの設定を要求する
（マルチコールの要求を行なう）。このマルチコール要
求を受け付けたＲＮＣ４は、無線リソースの空きを検知
し、ＲＬ１１〜１３すべてをマルチコール用に再設定す
るための無線リソースを確保できるか判断する（ステッ
プＳＴ１０２）。
【００８５】その結果、ＲＬ１１〜１３をすべて再設定
可能な無線リソースを確保できると判断すると、ＲＮＣ
４はＮＢＡＰプロトコルを用いて、ＢＴＳ５および６に
対し現在接続中であるＲＬ１１〜１３全ての無線リンク
を要求されたマルチコール用に再設定し、ＲＲＣプロト
コルを用いてＵＥ７に対し物理チャネルの再設定を行な
う（ステップＳＴ１０３）。そしてＲＬ１１〜１３に新
規ＲＡＢを設定し、要求されたマルチコールの接続を完
了する（ステップＳＴ１０９）。
可能な無線リソースを確保できると判断すると、ＲＮＣ
４はＮＢＡＰプロトコルを用いて、ＢＴＳ５および６に
対し現在接続中であるＲＬ１１〜１３全ての無線リンク
を要求されたマルチコール用に再設定し、ＲＲＣプロト
コルを用いてＵＥ７に対し物理チャネルの再設定を行な
う（ステップＳＴ１０３）。そしてＲＬ１１〜１３に新
規ＲＡＢを設定し、要求されたマルチコールの接続を完
了する（ステップＳＴ１０９）。
【００８６】一方、無線リソースの空き検知の結果、Ｒ
Ｌ１１〜１３のすべてを再設定するだけの無線リソース
は確保できないと判断すると、ステップＳＴ１０４へ進
み、追加で要求されたＲＡＢのトラヒッククラスを検知
してその優先度が「中」以上かを判断する。そして、検
知されたトラヒッククラスが"Conversational"または"S
treaming"であり、優先度が前述のとおり「高」または
「中」と判断されるとステップＳＴ１０５へ進み、ま
た、検知されたトラヒッククラスが"Background"であ
り、優先度が「低」と判断されるとステップＳＴ１０６
へ進む。ステップＳＴ１０６へ進んだ場合は、マルチコ
ールの受け付けをＮＧとし、新規ＲＡＢの設定を行なわ
ず処理を終了する（ステップＳＴ１０７）。
Ｌ１１〜１３のすべてを再設定するだけの無線リソース
は確保できないと判断すると、ステップＳＴ１０４へ進
み、追加で要求されたＲＡＢのトラヒッククラスを検知
してその優先度が「中」以上かを判断する。そして、検
知されたトラヒッククラスが"Conversational"または"S
treaming"であり、優先度が前述のとおり「高」または
「中」と判断されるとステップＳＴ１０５へ進み、ま
た、検知されたトラヒッククラスが"Background"であ
り、優先度が「低」と判断されるとステップＳＴ１０６
へ進む。ステップＳＴ１０６へ進んだ場合は、マルチコ
ールの受け付けをＮＧとし、新規ＲＡＢの設定を行なわ
ず処理を終了する（ステップＳＴ１０７）。
【００８７】ステップＳＴ１０５では、１つ以上のＲＬ
を再設定するだけの無線リソースが確保できるかを判断
する。１つのＲＬを再設定する無線リソースをも確保で
きないとの否定的判断をした場合は、ステップＳＴ１０
６、ステップＳＴ１０７と進み、新規ＲＡＢの設定を行
なわず処理を終了する。ステップＳＴ１０５において、
肯定的判断がなされた場合、例えば、ＢＴＳ６のセル１
０とＵＥ７間で使用可能な無線リソースには空きがあ
り、ＲＬ１３を再設定するだけの無線リソースを確保で
き、ＢＴＳ５のセル８とＵＥ７間、ＢＴＳ５のセル９と
ＵＥ７間それぞれで使用可能な無線リソースには空きが
なく、ＲＬ１１、ＲＬ１２を再設定するだけの無線リソ
ースを確保できないと判断した場合は、ステップＳＴ１
０８へ進み、本発明におけるマルチコール処理を実施す
る。すなわち、ＲＮＣ４は、ＲＲＣプロトコルを用いて
ＵＥ７に対し、ＮＢＡＰプロトコルを用いてＢＴＳ５に
対し、現在接続中であるＲＬ１１および１２を解放する
ように指示する。また、ＢＴＳ６に対しては、ＮＢＡＰ
プロトコルを用いて現在接続中であるＲＬ１３を要求さ
れたマルチコール用に再設定する。そして、ＲＬ１３の
再設定が完了した後、ＲＮＣ４はＲＲＣプロトコルを用
いてＵＥ７に対し物理チャネルの再設定を行なうことで
ＲＬ１３に新規のＲＡＢ１５を設定し、要求されたマル
チコールの接続を完了する（ステップＳＴ１０９）。
を再設定するだけの無線リソースが確保できるかを判断
する。１つのＲＬを再設定する無線リソースをも確保で
きないとの否定的判断をした場合は、ステップＳＴ１０
６、ステップＳＴ１０７と進み、新規ＲＡＢの設定を行
なわず処理を終了する。ステップＳＴ１０５において、
肯定的判断がなされた場合、例えば、ＢＴＳ６のセル１
０とＵＥ７間で使用可能な無線リソースには空きがあ
り、ＲＬ１３を再設定するだけの無線リソースを確保で
き、ＢＴＳ５のセル８とＵＥ７間、ＢＴＳ５のセル９と
ＵＥ７間それぞれで使用可能な無線リソースには空きが
なく、ＲＬ１１、ＲＬ１２を再設定するだけの無線リソ
ースを確保できないと判断した場合は、ステップＳＴ１
０８へ進み、本発明におけるマルチコール処理を実施す
る。すなわち、ＲＮＣ４は、ＲＲＣプロトコルを用いて
ＵＥ７に対し、ＮＢＡＰプロトコルを用いてＢＴＳ５に
対し、現在接続中であるＲＬ１１および１２を解放する
ように指示する。また、ＢＴＳ６に対しては、ＮＢＡＰ
プロトコルを用いて現在接続中であるＲＬ１３を要求さ
れたマルチコール用に再設定する。そして、ＲＬ１３の
再設定が完了した後、ＲＮＣ４はＲＲＣプロトコルを用
いてＵＥ７に対し物理チャネルの再設定を行なうことで
ＲＬ１３に新規のＲＡＢ１５を設定し、要求されたマル
チコールの接続を完了する（ステップＳＴ１０９）。
【００８８】上記ステップＳＴ１０８の具体的手順とし
ては、本発明の実施の形態１において図３を用いて説明
した手順、実施の形態２において図５を用いて説明した
手順、実施の形態３において図７を用いて説明した手
順、または実施の形態４において図９を用いて説明した
手順などを採用することができる。
ては、本発明の実施の形態１において図３を用いて説明
した手順、実施の形態２において図５を用いて説明した
手順、実施の形態３において図７を用いて説明した手
順、または実施の形態４において図９を用いて説明した
手順などを採用することができる。
【００８９】上記により、ソフトハンドオーバ状態にあ
るＵＥに対しマルチコールの要求が発生した際、接続中
の複数のＲＬのうち、一部のＲＬについて再設定する無
線リソースを確保できない場合でも、優先度の高いサー
ビスの追加を要求するマルチコールに対する呼損率を低
くすることができる。
るＵＥに対しマルチコールの要求が発生した際、接続中
の複数のＲＬのうち、一部のＲＬについて再設定する無
線リソースを確保できない場合でも、優先度の高いサー
ビスの追加を要求するマルチコールに対する呼損率を低
くすることができる。
【００９０】また、接続中の複数のＲＬのうち、一部の
ＲＬについて再設定する無線リソースを確保できず、か
つマルチコールで追加要求されるサービスの優先度が低
い場合には、マルチコールの接続を行なわないことで接
続中のサービスの受信品質が不要に低下することを防止
できる。
ＲＬについて再設定する無線リソースを確保できず、か
つマルチコールで追加要求されるサービスの優先度が低
い場合には、マルチコールの接続を行なわないことで接
続中のサービスの受信品質が不要に低下することを防止
できる。
【００９１】実施の形態７．次に、本発明の実施の形態
７を、図を用いて説明する。本実施の形態７に係るＷ−
ＣＤＭＡ通信システムのシステム構成は、図１に示すも
のと同一であるため説明を省略する。
７を、図を用いて説明する。本実施の形態７に係るＷ−
ＣＤＭＡ通信システムのシステム構成は、図１に示すも
のと同一であるため説明を省略する。
【００９２】図１において、１４はＵＥ７のユーザに対
し、すでに接続されているＲＬ１１〜１３を用いてサー
ビスを提供しているＲＡＢであり、１５は追加で要求さ
れたサービスを提供するＲＡＢである。これらのＲＡＢ
は、提供するサービス、保証する品質等により決定され
るトラヒッククラスを属性として有している。トラヒッ
ククラスは例えば、"Conversational"、"Streaming"、"
Background"に分類され、それぞれ「音声通信サービ
ス」、「映像などの配信サービス」等、「ウェブアクセ
ス（データ通信サービス）」等のサービスが対応する。
このうち、"Streaming"と"Background"の違いは、保証
レートの有無であり、"Background"では、レート保証を
行なわない。このようなトラヒッククラスの性質に基づ
き、それぞれの優先度を図１１に示すように定める。す
なわち、"Conversational"を優先度「高」、"Streamin
g"を優先度「中」、"Background"を優先度「低」とす
る。
し、すでに接続されているＲＬ１１〜１３を用いてサー
ビスを提供しているＲＡＢであり、１５は追加で要求さ
れたサービスを提供するＲＡＢである。これらのＲＡＢ
は、提供するサービス、保証する品質等により決定され
るトラヒッククラスを属性として有している。トラヒッ
ククラスは例えば、"Conversational"、"Streaming"、"
Background"に分類され、それぞれ「音声通信サービ
ス」、「映像などの配信サービス」等、「ウェブアクセ
ス（データ通信サービス）」等のサービスが対応する。
このうち、"Streaming"と"Background"の違いは、保証
レートの有無であり、"Background"では、レート保証を
行なわない。このようなトラヒッククラスの性質に基づ
き、それぞれの優先度を図１１に示すように定める。す
なわち、"Conversational"を優先度「高」、"Streamin
g"を優先度「中」、"Background"を優先度「低」とす
る。
【００９３】次に動作を、図１３を用いて説明する。Ｕ
Ｅ７はＲＬ１１〜１３の３つの無線リンクを接続して、
ＢＴＳ５および６に対しソフトハンドオーバ状態となっ
ており、ＲＡＢ１４を用いて通信を行なっている。ま
ず、ステップＳＴ２０１において、ＵＥ７が既に設定さ
れたＲＡＢ１４によるサービスを受けながら新たに追加
サービスを受けるべく、新規ＲＡＢの設定を要求する
（マルチコールの要求を行なう）。このマルチコール要
求を受け付けたＲＮＣ４は、無線リソースの空きを検知
し、ＲＬ１１〜１３すべてをマルチコール用に再設定す
るための無線リソースを確保できるか判断する（ステッ
プＳＴ２０２）。
Ｅ７はＲＬ１１〜１３の３つの無線リンクを接続して、
ＢＴＳ５および６に対しソフトハンドオーバ状態となっ
ており、ＲＡＢ１４を用いて通信を行なっている。ま
ず、ステップＳＴ２０１において、ＵＥ７が既に設定さ
れたＲＡＢ１４によるサービスを受けながら新たに追加
サービスを受けるべく、新規ＲＡＢの設定を要求する
（マルチコールの要求を行なう）。このマルチコール要
求を受け付けたＲＮＣ４は、無線リソースの空きを検知
し、ＲＬ１１〜１３すべてをマルチコール用に再設定す
るための無線リソースを確保できるか判断する（ステッ
プＳＴ２０２）。
【００９４】その結果、ＲＬ１１〜１３をすべて再設定
可能な無線リソースを確保できると判断すると、ＲＮＣ
４はＮＢＡＰプロトコルを用いて、ＢＴＳ５および６に
対し現在接続中であるＲＬ１１〜１３全ての無線リンク
を要求されたマルチコール用に再設定し、ＲＲＣプロト
コルを用いてＵＥ７に対し物理チャネルの再設定を行な
う（ステップＳＴ２０３）。そしてＲＬ１１〜１３に新
規ＲＡＢを設定し、要求されたマルチコールの接続を完
了する（ステップＳＴ２１２）。
可能な無線リソースを確保できると判断すると、ＲＮＣ
４はＮＢＡＰプロトコルを用いて、ＢＴＳ５および６に
対し現在接続中であるＲＬ１１〜１３全ての無線リンク
を要求されたマルチコール用に再設定し、ＲＲＣプロト
コルを用いてＵＥ７に対し物理チャネルの再設定を行な
う（ステップＳＴ２０３）。そしてＲＬ１１〜１３に新
規ＲＡＢを設定し、要求されたマルチコールの接続を完
了する（ステップＳＴ２１２）。
【００９５】一方、無線リソースの空き検知の結果、Ｒ
Ｌ１１〜１３のすべてを再設定するだけの無線リソース
は確保できないと判断すると、追加で要求された新規Ｒ
ＡＢのトラヒッククラスを検知して、その優先度が接続
中の既存ＲＡＢ１４の優先度にくらべ高いかを判断する
（ステップＳＴ２０４）。そして、例えば検知された新
規ＲＡＢのトラヒッククラスが"Conversational"で優先
度「高」、または"Streaming"で優先度「中」であり、
既存ＲＡＢのトラヒッククラスが"Background"で優先度
「低」であれば、肯定的判断がなされステップＳＴ２０
５へ進む。また、新規ＲＡＢの優先度が既存ＲＡＢの優
先度と同じ、もしくは低い場合は、否定的判断がなされ
ステップＳＴ２０６へ進む。ステップＳＴ２０６へ進ん
だ場合は、マルチコールの受け付けをＮＧとし、新規Ｒ
ＡＢの設定を行なわず処理を終了する（ステップＳＴ２
０７）。
Ｌ１１〜１３のすべてを再設定するだけの無線リソース
は確保できないと判断すると、追加で要求された新規Ｒ
ＡＢのトラヒッククラスを検知して、その優先度が接続
中の既存ＲＡＢ１４の優先度にくらべ高いかを判断する
（ステップＳＴ２０４）。そして、例えば検知された新
規ＲＡＢのトラヒッククラスが"Conversational"で優先
度「高」、または"Streaming"で優先度「中」であり、
既存ＲＡＢのトラヒッククラスが"Background"で優先度
「低」であれば、肯定的判断がなされステップＳＴ２０
５へ進む。また、新規ＲＡＢの優先度が既存ＲＡＢの優
先度と同じ、もしくは低い場合は、否定的判断がなされ
ステップＳＴ２０６へ進む。ステップＳＴ２０６へ進ん
だ場合は、マルチコールの受け付けをＮＧとし、新規Ｒ
ＡＢの設定を行なわず処理を終了する（ステップＳＴ２
０７）。
【００９６】ステップＳＴ２０５では、１つ以上のＲＬ
を再設定するだけの無線リソースが確保できるかを判断
する。ステップＳＴ２０５において、肯定的判断がなさ
れた場合は、ステップＳＴ２０８へ進み、本発明におけ
るマルチコール処理を実施する。すなわち、無線リソー
スを確保できずマルチコール用に再設定できないＲＬを
解放し、無線リソースを確保できたＲＬを要求されたマ
ルチコール用に再設定する。そして、新規ＲＡＢを設定
し、要求されたマルチコールの接続を完了する（ステッ
プＳＴ２１２）。
を再設定するだけの無線リソースが確保できるかを判断
する。ステップＳＴ２０５において、肯定的判断がなさ
れた場合は、ステップＳＴ２０８へ進み、本発明におけ
るマルチコール処理を実施する。すなわち、無線リソー
スを確保できずマルチコール用に再設定できないＲＬを
解放し、無線リソースを確保できたＲＬを要求されたマ
ルチコール用に再設定する。そして、新規ＲＡＢを設定
し、要求されたマルチコールの接続を完了する（ステッ
プＳＴ２１２）。
【００９７】上記ステップＳＴ２０８の具体的手順とし
ては、本発明の実施の形態１において図３を用いて説明
した手順、実施の形態２において図５を用いて説明した
手順、また、実施の形態３において図７を用いて説明し
た手順、または実施の形態４において図９を用いて説明
した手順などを採用することができる。
ては、本発明の実施の形態１において図３を用いて説明
した手順、実施の形態２において図５を用いて説明した
手順、また、実施の形態３において図７を用いて説明し
た手順、または実施の形態４において図９を用いて説明
した手順などを採用することができる。
【００９８】一方、ステップＳＴ２０５において、１つ
のＲＬを再設定する無線リソースをも確保できないとの
否定的判断をした場合は、ステップＳＴ２０９へ進む。
そして、接続中の既存ＲＡＢ１４を切断してＲＬを解放
した場合に、無線リソースを確保して要求されている新
規ＲＡＢを設定することが可能かを判断する。ここで、
否定的判断をした場合は、ステップＳＴ２０６、ステッ
プＳＴ２０７と進み、新規ＲＡＢの設定を行なわず処理
を終了する。肯定的判断をした場合は、既存ＲＡＢ１４
を切断してＲＬ１１〜１３を一旦解放し（ステップＳＴ
２１０）、ＲＬ１１〜１３を新規に接続して新規ＲＡＢ
１５を設定し（ステップＳＴ２１１）、処理を完了する
（ステップＳＴ２１２）。
のＲＬを再設定する無線リソースをも確保できないとの
否定的判断をした場合は、ステップＳＴ２０９へ進む。
そして、接続中の既存ＲＡＢ１４を切断してＲＬを解放
した場合に、無線リソースを確保して要求されている新
規ＲＡＢを設定することが可能かを判断する。ここで、
否定的判断をした場合は、ステップＳＴ２０６、ステッ
プＳＴ２０７と進み、新規ＲＡＢの設定を行なわず処理
を終了する。肯定的判断をした場合は、既存ＲＡＢ１４
を切断してＲＬ１１〜１３を一旦解放し（ステップＳＴ
２１０）、ＲＬ１１〜１３を新規に接続して新規ＲＡＢ
１５を設定し（ステップＳＴ２１１）、処理を完了する
（ステップＳＴ２１２）。
【００９９】尚、本実施の形態７では、接続中の既存Ｒ
ＡＢはＲＡＢ１４のみであったが、複数ある場合はＳＴ
２０４において、それぞれと新規ＲＡＢの優先度を輸画
する。そして、少なくとも１つの既存ＲＡＢより優先度
が高ければ、ＳＴ２０５へ進む。また、ＳＴ２１０で解
放する既存ＲＡＢは、優先度の一番低いものとすればよ
い。
ＡＢはＲＡＢ１４のみであったが、複数ある場合はＳＴ
２０４において、それぞれと新規ＲＡＢの優先度を輸画
する。そして、少なくとも１つの既存ＲＡＢより優先度
が高ければ、ＳＴ２０５へ進む。また、ＳＴ２１０で解
放する既存ＲＡＢは、優先度の一番低いものとすればよ
い。
【０１００】上記により、ソフトハンドオーバ状態にあ
るＵＥに対しマルチコールの要求が発生した際、接続中
の複数のＲＬをマルチコール用に再設定する無線リソー
スを確保できない場合でも、接続中のサービスと新規に
要求されたサービスのうち優先度の高いサービスを優先
的に接続し、ユーザの利便性を向上することが可能にな
る。
るＵＥに対しマルチコールの要求が発生した際、接続中
の複数のＲＬをマルチコール用に再設定する無線リソー
スを確保できない場合でも、接続中のサービスと新規に
要求されたサービスのうち優先度の高いサービスを優先
的に接続し、ユーザの利便性を向上することが可能にな
る。
【０１０１】また、接続中の全てのＲＬをマルチコール
用に再設定する無線リソースを確保できず、かつマルチ
コールで追加要求されるサービスの優先度が接続中のサ
ービスの優先度より低い場合には、マルチコールの接続
を行なわないことで接続中の優先度が高いサービスの受
信品質が不要に低下することを防止できる。
用に再設定する無線リソースを確保できず、かつマルチ
コールで追加要求されるサービスの優先度が接続中のサ
ービスの優先度より低い場合には、マルチコールの接続
を行なわないことで接続中の優先度が高いサービスの受
信品質が不要に低下することを防止できる。
【０１０２】尚、上記実施の形態１乃至７において、マ
ルチコールの要求はＵＥから行なわれているが、これに
限らずネットワーク側から行なわれる場合も同様の方法
を実施でき、かつ同様の効果を得ることができる。
ルチコールの要求はＵＥから行なわれているが、これに
限らずネットワーク側から行なわれる場合も同様の方法
を実施でき、かつ同様の効果を得ることができる。
【０１０３】
【発明の効果】以上のように、この発明の請求項１に係
る無線制御装置の呼接続方法は、少なくとも一つの無線
リンクをマルチコール用に再設定し、その他の無線リン
クを解放するようにしたので、ソフトハンドオーバ時の
マルチコール要求に対する呼損率を低くすることでき
る。
る無線制御装置の呼接続方法は、少なくとも一つの無線
リンクをマルチコール用に再設定し、その他の無線リン
クを解放するようにしたので、ソフトハンドオーバ時の
マルチコール要求に対する呼損率を低くすることでき
る。
【０１０４】また、この発明の請求項２に係る無線制御
装置の呼接続方法は、無線リソースの空きが足りない場
合にその無線リソースを使用する無線リンクを解放する
ようにしたので、ソフトハンドオーバ時のマルチコール
要求に対する呼損率を低くでき、かつ不要な受信品質の
低下を防ぐことができる。
装置の呼接続方法は、無線リソースの空きが足りない場
合にその無線リソースを使用する無線リンクを解放する
ようにしたので、ソフトハンドオーバ時のマルチコール
要求に対する呼損率を低くでき、かつ不要な受信品質の
低下を防ぐことができる。
【０１０５】また、この発明の請求項３に係る無線制御
装置の呼接続方法は、無線リソースの空きが足りない場
合にその無線リソースを使用する無線リンクのみを解放
し、それ以外の無線リンクをすべて再設定するようにし
たので、ソフトハンドオーバ時のマルチコール要求に対
する呼損率を低くでき、かつ不要な受信品質の低下をさ
らに防ぐことができる。
装置の呼接続方法は、無線リソースの空きが足りない場
合にその無線リソースを使用する無線リンクのみを解放
し、それ以外の無線リンクをすべて再設定するようにし
たので、ソフトハンドオーバ時のマルチコール要求に対
する呼損率を低くでき、かつ不要な受信品質の低下をさ
らに防ぐことができる。
【０１０６】また、この発明の請求項４、５および６に
係る無線制御装置の呼接続方法は、無線リンクの解放を
移動端末へ指示する手順を減らしたので、ソフトハンド
オーバ時のマルチコール要求に対する呼損率を低くで
き、かつ無線リソースを有効利用することができる。
係る無線制御装置の呼接続方法は、無線リンクの解放を
移動端末へ指示する手順を減らしたので、ソフトハンド
オーバ時のマルチコール要求に対する呼損率を低くで
き、かつ無線リソースを有効利用することができる。
【０１０７】また、この発明の請求項７に係る無線制御
装置の呼接続方法は、無線リンクの解放を基地局へ指示
する手順を非同期手順としたので、ソフトハンドオーバ
時のマルチコール要求に対する呼損率を低くでき、かつ
無線制御装置−基地局間のリソースを有効利用すること
ができる。
装置の呼接続方法は、無線リンクの解放を基地局へ指示
する手順を非同期手順としたので、ソフトハンドオーバ
時のマルチコール要求に対する呼損率を低くでき、かつ
無線制御装置−基地局間のリソースを有効利用すること
ができる。
【０１０８】また、この発明の請求項８および９に係る
無線制御装置の呼接続方法は、追加呼の優先度が高い場
合に、少なくとも一つの無線リンクをマルチコール用に
再設定し、その他の無線リンクを解放するようにしたの
で、ソフトハンドオーバ時の優先度の高いマルチコール
要求に対する呼損率を低くすることができる。
無線制御装置の呼接続方法は、追加呼の優先度が高い場
合に、少なくとも一つの無線リンクをマルチコール用に
再設定し、その他の無線リンクを解放するようにしたの
で、ソフトハンドオーバ時の優先度の高いマルチコール
要求に対する呼損率を低くすることができる。
【０１０９】また、この発明の請求項１０に係る無線制
御装置の呼接続方法は、無線リソースの空きが足りな
く、かつ追加呼の優先度が高い場合に、その無線リソー
スを使用する無線リンクを解放するようにしたので、ソ
フトハンドオーバ時の優先度の高いマルチコール要求に
対する呼損率を低くでき、かつ不要な受信品質の低下を
防ぐことができる。
御装置の呼接続方法は、無線リソースの空きが足りな
く、かつ追加呼の優先度が高い場合に、その無線リソー
スを使用する無線リンクを解放するようにしたので、ソ
フトハンドオーバ時の優先度の高いマルチコール要求に
対する呼損率を低くでき、かつ不要な受信品質の低下を
防ぐことができる。
【０１１０】また、この発明の請求項１１に係る無線制
御装置の呼接続方法は、接続中の呼より追加呼の優先度
が高い場合に、接続中の呼を切断し追加呼を接続するよ
うにしたので、ソフトハンドオーバ時のマルチコール要
求に対し、優先度の高い呼の呼損率を低くすることがで
きる。
御装置の呼接続方法は、接続中の呼より追加呼の優先度
が高い場合に、接続中の呼を切断し追加呼を接続するよ
うにしたので、ソフトハンドオーバ時のマルチコール要
求に対し、優先度の高い呼の呼損率を低くすることがで
きる。
【０１１１】また、この発明の請求項１２に係る無線制
御装置の呼接続方法は、無線リソースの空きが足りな
く、かつ接続中の呼より追加呼の優先度が高い場合に、
接続中の呼を切断し追加呼を接続するようにしたので、
ソフトハンドオーバ時のマルチコール要求に対し、優先
度の高い呼の呼損率を低くでき、かつ不要な受信品質の
低下を防ぐことができる。
御装置の呼接続方法は、無線リソースの空きが足りな
く、かつ接続中の呼より追加呼の優先度が高い場合に、
接続中の呼を切断し追加呼を接続するようにしたので、
ソフトハンドオーバ時のマルチコール要求に対し、優先
度の高い呼の呼損率を低くでき、かつ不要な受信品質の
低下を防ぐことができる。
【０１１２】さらに、この発明の請求項１３および１４
に係る移動端末の呼接続方法は、チャネル設定用メッセ
ージに基づき、少なくとも一つの無線リンクをマルチコ
ール用に再設定し、その他の無線リンクを解放するよう
にしたので、ソフトハンドオーバ時のマルチコール要求
に対する呼損率を低くでき、かつ容易に無線リソースを
有効利用することができる。
に係る移動端末の呼接続方法は、チャネル設定用メッセ
ージに基づき、少なくとも一つの無線リンクをマルチコ
ール用に再設定し、その他の無線リンクを解放するよう
にしたので、ソフトハンドオーバ時のマルチコール要求
に対する呼損率を低くでき、かつ容易に無線リソースを
有効利用することができる。
【図１】 本発明の実施の形態１に係る通信システムの
システム構成図である。
システム構成図である。
【図２】 チャネライゼーションコードの依存関係を示
すコードツリー図である。
すコードツリー図である。
【図３】 本発明の実施の形態１のマルチコール接続手
順を示すシーケンス図である。
順を示すシーケンス図である。
【図４】 本発明の実施の形態１に係るメッセージの情
報要素を示す図である。
報要素を示す図である。
【図５】 本発明の実施の形態２のマルチコール接続手
順を示すシーケンス図である。
順を示すシーケンス図である。
【図６】 本発明の実施の形態３に係るメッセージの情
報要素を示す図である。
報要素を示す図である。
【図７】 本発明の実施の形態３のマルチコール接続手
順を示すシーケンス図である。
順を示すシーケンス図である。
【図８】 本発明の実施の形態４に係るメッセージの情
報要素を示す図である。
報要素を示す図である。
【図９】 本発明の実施の形態４のマルチコール接続手
順を示すシーケンス図である。
順を示すシーケンス図である。
【図１０】 本発明の実施の形態５のマルチコール接続
手順を示すシーケンス図である。
手順を示すシーケンス図である。
【図１１】 本発明の実施の形態６に係るトラヒックク
ラスの優先度を示す図である。
ラスの優先度を示す図である。
【図１２】 本発明の実施の形態６の動作を示すフロー
チャートである。
チャートである。
【図１３】 本発明の実施の形態７の動作を示すフロー
チャートである。
チャートである。
【図１４】 従来の通信システムのシステム構成図であ
る。
る。
【図１５】 従来のマルチコール接続手順を示すシーケ
ンス図である。
ンス図である。
４ ＲＮＣ（無線制御装置）
５、６ ＢＴＳ（基地局）
７ ＵＥ（移動端末）
１１〜１３ ＲＬ（無線リンク）
１４、１５ ＲＡＢ（無線アクセスベアラ）
５０６ 物理チャネル設定用メッセージ（Physical Cha
nnel Reconfiguration） ６００ 物理チャネル情報 ７０６ 物理チャネル設定用メッセージ（Physical Cha
nnel Reconfiguration） ８００ トランスポートチャネル情報 ９０６ トランスポートチャネル設定用メッセージ（Tr
ansport Channel Reconfiguration）
nnel Reconfiguration） ６００ 物理チャネル情報 ７０６ 物理チャネル設定用メッセージ（Physical Cha
nnel Reconfiguration） ８００ トランスポートチャネル情報 ９０６ トランスポートチャネル設定用メッセージ（Tr
ansport Channel Reconfiguration）
─────────────────────────────────────────────────────
フロントページの続き
Ｆターム(参考） 5K067 AA11 AA25 BB04 BB21 DD11
DD57 EE02 EE10 EE16 EE24
HH01 HH07 JJ04 JJ11 JJ31
Claims (14)
- 【請求項１】 一つの移動端末と基地局との間に一つの
呼を接続する複数の無線リンクを設定する第１ステッ
プ、 前記呼に追加される追加呼の接続要求を受付ける第２ス
テップ、 前記複数の無線リンクのうち、少なくとも一つの無線リ
ンクを前記呼と前記追加呼をともに接続するように再設
定し、その他の無線リンクを解放する第３ステップを含
む無線制御装置の呼接続方法。 - 【請求項２】 前記移動端末と前記基地局間における無
線リソースの空きを検知する第４ステップをさらに含
み、 前記第４ステップで検知された前記無線リソースの空き
が所定量に足りない場合、前記第３ステップにおいて当
該空きの足りない無線リソースを使用する無線リンクを
解放することを特徴とする請求項１に記載の無線制御装
置の呼接続方法。 - 【請求項３】 前記第４ステップで検知された前記無線
リソースの空きが所定量に足りない場合、前記第３ステ
ップにおいて当該空きの足りない無線リソースを使用す
る無線リンクのみを解放し、それ以外の無線リンクをす
べて前記呼と前記追加呼をともに接続するように再設定
することを特徴とする請求項２に記載の無線制御装置の
呼接続方法。 - 【請求項４】 前記第３ステップは、無線リンクの解放
を前記移動端末へ指示するステップを含み、解放する無
線リンク情報を含む物理チャネル設定用メッセージの通
知により前記指示を行なうことを特徴とする請求項１に
記載の無線接続装置の呼接続方法。 - 【請求項５】 前記第３ステップは、無線リンクの解放
を前記移動端末へ指示するステップを含み、再設定する
無線リンクのみに対応する物理チャネル情報を含む物理
チャネル設定用メッセージの通知により前記指示を行な
うことを特徴とする請求項１に記載の呼接続方法。 - 【請求項６】 前記第３ステップは、無線リンクの解放
を前記移動端末へ指示するステップを含み、再設定する
無線リンクのみに対応するトランスポートチャネル情報
を含むトランスポートチャネル設定用メッセージの通知
により前記指示を行なうことを特徴とする請求項１に記
載の無線接続装置の呼接続方法。 - 【請求項７】 前記第３ステップは、無線リンクの解放
を前記基地局へ指示するステップを含み、非同期手順に
より前記指示を行なうことを特徴とする請求項１に記載
の無線接続装置の呼接続方法。 - 【請求項８】 前記追加呼の優先度を判断する第４ステ
ップをさらに含み、 前記第４ステップで前記追加呼の優先度が高いと判断さ
れた場合、前記第３ステップにおいて前記複数の無線リ
ンクのうち、少なくとも一つの無線リンクを前記呼と前
記追加呼をともに接続するように再設定し、その他の無
線リンクを解放することを特徴とする請求項１に記載の
無線接続装置の呼接続方法。 - 【請求項９】 前記第４ステップは、前記呼の優先度と
相対的に前記追加呼の優先度を判断することを特徴とす
る請求項８に記載の無線接続装置の呼接続方法。 - 【請求項１０】 前記移動端末と前記基地局間における
無線リソースの空きを検知する第５ステップをさらに含
み、 前記第５ステップで検知された前記無線リソースの空き
が所定量に足りない場合に前記第４ステップにおいて追
加呼の優先度を判断し、前記追加呼の優先度が高いと判
断された場合、前記第３ステップにおいて当該空きの足
りない無線リソースを使用する無線リンクを解放するこ
とを特徴とする請求項８に記載の無線制御装置の呼接続
方法。 - 【請求項１１】 一つの移動端末と基地局との間に呼を
接続する複数の無線リンクを設定する第１ステップ、 前記呼に追加される追加呼の接続要求を受付ける第２ス
テップ、 前記呼と前記追加呼の優先度を比較する第３ステップ、 前記第３ステップで当該追加呼の優先度が相対的に高い
と判断された場合、前記呼を切断し前記追加呼を接続す
るように無線リンクを再設定する第４ステップを含む無
線制御装置の呼接続方法。 - 【請求項１２】 前記移動端末と前記基地局間における
無線リソースの空きを検知する第４ステップをさらに含
み、 前記第４ステップで検知された前記無線リソースの空き
が所定量に足りない場合、前記第３ステップにおいて追
加呼の優先度を判断することを特徴とする請求項１１に
記載の無線制御装置の呼接続方法。 - 【請求項１３】 基地局との間に一つの呼を接続する複
数の無線リンクを設定する第１ステップ、 前記呼に追加される追加呼の接続を要求する第２ステッ
プ、 前記複数の無線リンクのうち再設定する無線リンクに対
応するチャネル情報を含むチャネル設定用メッセージを
受信する第３ステップ、 前記第３ステップで受信したメッセージに基づき、前記
複数の無線リンクのうち少なくとも一つの無線リンクを
前記呼と前記追加呼をともに接続するように再設定し、
その他の無線リンクを解放する第４ステップを含む移動
端末の呼接続方法。 - 【請求項１４】 前記チャネル情報は、物理チャネル情
報またはトランスポートチャネル情報であることを特徴
とする請求項１３に記載の移動端末の呼接続方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002070333A JP2003274437A (ja) | 2002-03-14 | 2002-03-14 | 無線制御装置および移動端末の呼接続方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002070333A JP2003274437A (ja) | 2002-03-14 | 2002-03-14 | 無線制御装置および移動端末の呼接続方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2003274437A true JP2003274437A (ja) | 2003-09-26 |
Family
ID=29200934
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002070333A Pending JP2003274437A (ja) | 2002-03-14 | 2002-03-14 | 無線制御装置および移動端末の呼接続方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2003274437A (ja) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2005079097A1 (ja) * | 2004-02-13 | 2005-08-25 | Mitsubishi Denki Kabushiki Kaisha | 通信システム、通信装置、通信端末並びに通信方法 |
| JP2008532412A (ja) * | 2005-03-03 | 2008-08-14 | ノキア コーポレイション | デュアル転送モード時における移動局の専用および共用リソースのハンドオーバ方法 |
| WO2009041649A1 (ja) * | 2007-09-28 | 2009-04-02 | Ntt Docomo, Inc. | 無線通信システム及び無線通信方法 |
| WO2009113622A1 (ja) * | 2008-03-13 | 2009-09-17 | 京セラ株式会社 | 通信端末、通信システム、ハンドオーバ処理方法、および、プログラム |
-
2002
- 2002-03-14 JP JP2002070333A patent/JP2003274437A/ja active Pending
Cited By (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2005079097A1 (ja) * | 2004-02-13 | 2005-08-25 | Mitsubishi Denki Kabushiki Kaisha | 通信システム、通信装置、通信端末並びに通信方法 |
| US7352698B2 (en) | 2004-02-13 | 2008-04-01 | Mitsubishi Denki Kabushiki Kaisha | Communications system, communications apparatus, communications terminal and communications method |
| US8699331B2 (en) | 2004-02-13 | 2014-04-15 | Blackberry Limited | Communications system, communications apparatus, communications terminal and communications method |
| JP2008532412A (ja) * | 2005-03-03 | 2008-08-14 | ノキア コーポレイション | デュアル転送モード時における移動局の専用および共用リソースのハンドオーバ方法 |
| WO2009041649A1 (ja) * | 2007-09-28 | 2009-04-02 | Ntt Docomo, Inc. | 無線通信システム及び無線通信方法 |
| CN101810032A (zh) * | 2007-09-28 | 2010-08-18 | 株式会社Ntt都科摩 | 无线通信系统以及无线通信方法 |
| US8300604B2 (en) | 2007-09-28 | 2012-10-30 | Ntt Docomo, Inc. | Radio communication system and radio communication method |
| RU2489807C2 (ru) * | 2007-09-28 | 2013-08-10 | Нтт Докомо, Инк. | Система и способ радиосвязи |
| WO2009113622A1 (ja) * | 2008-03-13 | 2009-09-17 | 京セラ株式会社 | 通信端末、通信システム、ハンドオーバ処理方法、および、プログラム |
| JP5160633B2 (ja) * | 2008-03-13 | 2013-03-13 | 京セラ株式会社 | 通信端末、通信システム、ハンドオーバ処理方法、および、プログラム |
| US8594045B2 (en) | 2008-03-13 | 2013-11-26 | Kyocera Corporation | Communication terminal, communication system, handover process method, and program |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP1234415B1 (en) | Dynamic upgrade of quality of service in a packet switched network | |
| US6738625B1 (en) | Rehoming and resource sharing in communications networks | |
| JP5221526B2 (ja) | システム間ハンドオーバの場合に端末のｐｄｐコンテキストを転送する装置及び方法 | |
| JP4268634B2 (ja) | ワイヤレス通信システムにおいてｔｄｄとｆｄｄとの間でのリソース割り当てを統合する方法及びシステム | |
| RU2420041C2 (ru) | Передача управляющей информации в системе мобильной связи | |
| US6944452B2 (en) | Apparatus and method for hard handoff of data packet transmissions | |
| EP1677563A1 (en) | Channel assignment based on service type and wireless communication environment | |
| US7613461B2 (en) | Station side apparatus, resource allocating method in station side apparatus and mobile communication system | |
| US20070298803A1 (en) | Radio network system, radio base station and handover control method used for the same | |
| US7308271B2 (en) | Mobile communication control method and radio network controller | |
| JP2004502378A (ja) | 通信システムにおける無線アクセス・ベアラーの再構成方法 | |
| JP4597385B2 (ja) | 同方向通話をセットアップする方法と装置 | |
| KR20070015572A (ko) | 구성 메시지를 이용하여 무선 통신망에 있어서의 데이터전송을 위한 서비스 품질의 제어 | |
| EP1868395A1 (en) | Network selection | |
| CN101583165B (zh) | 保证分组交换域数据无损传输的制式间切换方法及装置 | |
| WO2012152130A1 (zh) | 承载处理方法及装置 | |
| CN101795442A (zh) | 移动通信系统中承载建立的方法 | |
| CN1640177B (zh) | 蜂窝移动无线系统中改进服务质量管理的方法和设备 | |
| KR100790074B1 (ko) | 휴대단말기의 호 연결방법 | |
| JP4737459B2 (ja) | 移動通信システム、無線ネットワーク制御装置、および負荷分散方法 | |
| JP2007507180A (ja) | 無線通信システムにおいてｔｄｄとｆｄｄとの間でリソース配分を統合するための方法およびシステム | |
| JP2003274437A (ja) | 無線制御装置および移動端末の呼接続方法 | |
| EP1718099A2 (en) | Method for controlling service priority in radio communication network, radio communication system, radio control apparatus, terminal unit and core network | |
| WO2006037664A2 (en) | Method for managing communication sessions and related devices | |
| JP2002354533A (ja) | 基地局装置、無線ネットワーク制御装置、および呼設定制御方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20040706 |