JP4168030B2 - 話し中の移動局への呼通知および配信のための方法並びに装置 - Google Patents

Description

（関連出願）
本出願は３５U.S.C.§１１９（ｅ）の下、下記の米国仮出願に対して優先権を主張する：出願連番第６０／４０９，１５５、２００２年９月９日出願。この出願内容は此処に参照することによりその全てを組み入れられている。
本発明は一般的に通信ネットワーク内での呼処理に関わり、更に詳細には同時サービスがサポートされていない場合の話し中移動局に対する呼処理に関する。

発展する無線通信ネットワークは、従来の回線交換サービスと共に高度パケット・サービスを提供する。パケット・データ・サービスは例えば、ウェブ検索、メディアのストリーミング、および電子メールを含む一方、回線交換サービスは、例えば従来型低ビット速度音声およびファクシミリ・サービスを含み、これは通常公衆電話交換網（ＰＳＴＮ）の加入者と無線通信ネットワーク内で動作している加入者との間の呼に関連している。

例えば一群のＩＳ−２０００ ＣＤＭＡ規格の様ないくつかの現行無線通信規格は、現行のパケット・データおよび回線交換サービスの提供を含む。ネットワークと個々の移動局の両方が同時サービスをサポートしている同時サービス環境の中で、移動局の使用者はネットワークと、実行中のパケット・データ接続を維持しながら、音声呼の送受信を行うことができる。

規格ではその様な用意がなされているにもかかわらず、非常に多数の既存の無線ネットワークは同時サービスをサポートするように更新されておらず、また更に多くの既存移動局も同時サービスをサポートしていないし（するつもりもない）。同時サービスが無いと言うことは、話し中の移動局に対して呼の終了および開始事象の取り扱いが困難となることを表している。

一般的に、移動局は多くの理由で話し中の場合がある。移動局が別の音声呼で話し中であったり、パケット・データ・セッションで話し中、または厳密な意味でパケット・データ呼とは言えない他の非音声呼で話し中の場合もある。例えば、移動局が位置決定（Position Location Determination : PLD）情報の送信または受信で話し中の場合も、ショート・メッセージ・サービス（Short Messaging Service : SMS）テキストの送信または受信、または同様のメッセージ活動に従事することで話し中である場合がある。これらのサービスが接続チャンネルでは無く専用トラヒック・チャンネルに割り当てられている場合、その移動局はその移動局使用者がその状態を意識して居なくても話し中である。

話し中の移動局は、同時サービスがサポートされていないところで潜在的なサービス問題を提起する。非同時サービス・シナリオの中に存在する問題の解決を試みる中で、ある種の規格、例えばTIA-935基準は回線交換呼をパケット・データ呼に対して高い優先順位を付けるための手順を定義している。これらの手順は、ＣＤＭＡパケット・データ・セッションに対する回線交換呼優先（Circuit-Switched Call Precedence Over CDMA Packet Data Session : CPOP）と呼ばれ、（移動局の）使用者がパケット・データ呼に関与している時に、その使用者に対して入力音声呼が受信されると、ネットワークは単にパケット・データ接続を切り離し、その入力音声呼に対して新たな接続を確立する。別の参照例はIS-2001cdma2000接続ネットワーク・インタフェースに対する相互運用性規格であって、これは標準化機関で考慮されるその様な優先順位付け手法の詳細を定めている。

この強制的なやり方は入力音声呼の配信は提供するが、少なくとも使用者の観点からは、その移動局で入力音声呼の受け入れを優先してデータ接続を単に切断するという、洗練されていないステップを含んでいる。その他の型式の通信ネットワーク、例えば広帯域ＣＤＭＡは非同時サービス・シナリオの中で同様の呼処理問題を有している。

本発明は非同時サービス・シナリオに対する無線通信ネットワーク内での呼処理を改善する方法並びに装置を含む。一般的に本発明は入力音声呼通知を、データ呼に関わっている移動局に送る。１つの実施例において、その様な通知は移動局に対して、現在データ呼に割り当てられているトラヒック・チャンネルを用いて送られ、入力音声呼は音声メールに回送されるか、または他の所望の呼取り扱いに基づいて処理される。従って、このネットワークはその移動局使用者が入力音声呼を受け損ねたことを直ちに表示するが、これは移動局の既存のトラヒック・チャンネルを用いてそのデータ呼を散乱させないやり方で行われる。移動局へ送られる呼通知は発呼者情報、例えば発呼者ＩＤを含むことができる。移動局はその情報を格納し、後ほど使用者が検索して受け損ねた呼に対して応答するように構成可能である。

別の例として示す実施例では、ネットワークが入力音声呼を既にデータ呼に割り当てられている通信資源を再利用して配信し、これによりシグナリング・オーバーヘッドが削減できるように構成されている。その様な実施例において、ネットワークは移動局の既存のトラヒック・チャンネルが音声トラヒックをサポートするように再構成し、必要な関連する音声処理を追加して、再構成／再調整されたトラヒック・チャンネルを用いて入力音声呼を移動局に配信することが出来る。

その様な再調整はその移動局の使用者が、現在のデータ呼を優先して入力音声呼を受け取りたいと希望するか否かが鍵である。従って、ネットワークはその移動局がパケット・データ呼に接続されていることを判別可能であり、通知メッセージをその移動局にデータ呼のトラヒック・チャンネル上の制御シグナリングを経由して送り、移動局に対して使用者に催促させる。移動局から、音声呼を所望する旨を示す応答が戻ると、ネットワークはトラヒック・チャンネルを調整してパケット・データ呼を終了するかまたは一時中断する。

一方、そのデータ呼が回線交換データ呼、例えば位置決定、ＳＭＳ等の場合もあり、それらは使用者によって開始されたものではなく、実際その使用者は移動局が話し中状態であることを認識していないはずである。その様な状況下で、ネットワークは単にトラヒック・チャンネルが音声呼配信をサポートするように使用者に催促することなく調整する。

従って、無線通信ネットワーク内で呼を処理する方法の例は、データ呼で話し中の移動局に対する入力音声呼を受信し、入力呼通知を移動局にそのデータ呼に割り当てられた既存のトラヒック・チャンネル上でのシグナリングを経由して送ることを含む。このネットワークは入力音声呼を、呼通知を移動局に送ると共に音声メールに回送するように構成し、移動局に送られる入力呼通知の中に発呼者識別子を含むように構成することも可能である。

更に、ネットワークがトラヒック・チャンネルを、回線交換データ呼のサポートから入力音声呼のサポートに再構成する場合、このネットワークはそれにも関わらず、そのデータ呼処理を再構成されたトラヒック・チャンネル上の制御シグナリングを経由して継続することが出来る。すなわち、このネットワークは関連するシグナリングを音声呼トラヒック内に含めることで、データ処理を継続することができる。これと対照的に、そのデータ呼がパケット・データ呼であった場合、ネットワークはそのデータ呼に関連するデータ処理を終了または一時中止する。

１つまたはいくつかの実施例において、本発明は種々の無線通信ネットワーク基準に基づいて、ネットワークおよび移動局の中に実現出来る。その様な基準は、これらに限定するわけではなく、ＩＳ−２０００ ＣＤＭＡ基準、そして非同時サービスが種々の話し中移動体呼の発信および終了シナリオが調停される必要のある他の基準を含む。

いくつかの展開中の無線ネットワーク規格は同時サービスに対するサポートを提供しており、ここで指定された移動局は同時に音声およびパケット・データ接続をその無線ネットワークに対して有する。一般的に、回線交換音声呼は移動局に基本チャンネル（fundamental channel : FCH）に割り当てることでサポートされており、１つまたは複数のパケット・データ接続は１つまたは複数の補助チャンネル（supplemental channel : SCH）を割り当てることでサポートされている。

同時サービスはネットワークおよび移動局でサポートされていなければならない。従って、多くの実例では同時サービスは利用できないが、それは多くの既存のネットワークおよび移動局がそれをサポートしていないからである。同時サービスがサポートされている所でさえも、ある種の呼取り扱いシナリオの中で、同時サービスを常に使用できず、またそれが望ましいのではない。

例えば、同時サービスの最新の定義は、１つの基本チャンネルと１つまたは複数の補助チャンネルを同時に割り当てることを規定しており、これは暗黙の内に同時音声ならびにパケット・データの同時サービスを制限している。すなわち、回線交換音声サービスは基本チャンネルの割り当てを必要とし、移動局への同時割り当て可能なようにデータ指向補助チャンネルのみを残している。

しかしながら、回線交換サービスと考えられ、従って基本（トラヒック）チャンネルの割り当てを必要とする非音声データ呼が存在する。これは非音声回線交換データ呼に接続されている従来型移動局は入力音声呼の同時配信を行えないことを意味しており、何故ならば要求された音声接続をサポートするために別の基本チャンネルを割り当てることが出来ないためである。その様な非音声データ呼の例として、位置決定（ＰＬＤ）、ショート・メッセージ・サービス（ＳＭＳ）、放送サービス提供（Over-The-Air Service Provisioning）および放送パラメータ管理（Over-The-Air Parameter Administration）（OTASPおよびOTAPA、TIA/EIA/IS-725-A規格参照）に関連する呼があげられる。これらの型式の非音声データ呼の別の興味有る特徴は、多くの場合その様なサービスで話し中の移動局の使用者は、自分の移動局がネットワークと呼のやり取りをしていることを気づかないことである。

一般的に、読者はたとえ同時サービスがネットワークおよび対象としている個々の移動局でサポートされていたとしても、同時サービスが或るシナリオの下では可能でないことを理解しなければならない。同時サービスがサポートされていないかまたは所望されていない場合、ある種の呼取り扱いジレンマが存在する。例えば、移動局がパケット・データ呼で話し中の場合、ネットワークは入力音声呼をそのパケット・データ呼を中断することなく配信することが出来ない。先に述べた規格、cdma2000接続ネットワーク・インタフェースに対するIS-2001相互運用性、は音声呼に優先順位を与えネットワークに対して、その移動局に宛てられた入力（移動体宛）音声呼の受信に応答する移動局との既存非音声接続を切断するように指示する。

本発明は、呼シナリオの中、および同時サービスが不可能であるかまたは望ましくない場合に、改善された呼の取り扱いを提供する。図１は無線通信ネットワーク１０の例を示し、これは非同時サービス・シナリオの中で改善された呼の取り扱いを提供するように構成されている。ネットワーク１０は一群のIS-2000規格、または必要に応じて他のネットワーク基準に基づいて構築できる。当業者には図示されたネットワーク・エンティティーの専門用語がその機能から逸脱することなく、個別の規格に基づいて変わりうることは理解されよう。

ネットワーク１０は基地局（ＢＳ）１２を含み、これは基地局制御器（ＢＳＣ）１４および無線基地局（ＲＢＳ）１６を含む。実際は、各々のＢＳＣ１４は１つまたは複数のＲＢＳ１６をサポートし、ネットワーク１０は所望する１つまたは複数のサービス領域をサポートするために複数のＢＳ１２を含む。しかしながら、本発明の理解にはその様に詳細な図示は必要無く、またＢＳ１２は本発明に影響を与えることなく異なるように構成できることを理解されたい。

例として示すＢＳＣ１４は、呼処理兼インタフェース回路１８、例えば回線並びにパケット交換回路ならびに関連する信号回送および処理回路（マイクロプロセッサなど）、および通知プロセッサ２０を含む。その様な処理回路は、例えば音声符号器／復号器（「ボコーダ」）を含み、これは放送される音声の符号化および復号化を行う。更に、実施例において通知プロセッサ２０はマイクロプロセッサまたはその他の論理回路を含み、これはコンピュータ読み取り可能媒体内に格納されているプログラム命令を実行する。通知プロセッサ２０は、ＢＳＣ１４内の独立したマイクロプロセッサおよびメモリ・サブシステムとして実現することも出来るし、または共有処理およびメモリ資源を用いて実現することも可能である。

ＢＳＣ１４は１つまたは複数の移動局２２と、ＲＢＳ１６を通して通信し制御している。次に、ＢＳＣ１４は移動局２２を１つまたは複数の外部ネットワーク（およびネットワーク１０内のその他の移動局２２）と通信可能なように結合している。例えば、ＢＳＣ１４は移動局２２を回線交換コア・ネットワーク（Circuit Switched Core Network : OSCN）２４を通して、公衆電話交換網（ＰＳＴＮ）２６に結合している。

ＯＳＣＮ２４は移動体交換センタ（ＭＳＣ）２８を含み、これは回線交換入力および出力呼回送を提供する。ＭＳＣ２８は呼処理、交換、およびインタフェース回路を含み、ＢＳＣ１４に定義されたシグナリング／データ・インタフェース（IS-2000規格参照）を通して結合し、これによりＭＳＣ２８およびＢＳＣ１４はエンティティー相互シグナリングを提供し、同様にそれらの間でデータの搬送が可能となる。ＯＳＣＮ２４は、図を簡単にする目的で図示されていないが別のエンティティー、例えば本拠地レジスタ（ＨＬＲ）、訪問先レジスタ（ＶＬＲ）等を含むことが可能である。

更にフレキシビリティーを与えるために、ＢＳＣ１４は移動局２２をパケット交換コア・ネットワーク（ＰＳＣＮ）３０を通してインターネット３２，またはその他の公衆データ・ネットワーク（ＰＤＮ）、私的パケット・ネットワークなどに、必要に応じて結合する。ＰＳＣＮ３０はパケット・データ取り扱いノード（Packet Data Serving Node : PDSN）３４をパケット・データ通信をサポートするために含み、また必要に応じて他のエンティティーを含む場合もある。ＢＳＣ１４の呼処理兼インタフェース回路１８はパケット制御機能（ＰＣＦ）を含み、これはＢＳＣ１４とＰＳＣＮ３０との間で回送される通信間の無線パケット（ＲＰ）インタフェースを提供する。ＢＳＣ１４は個別のＰＣＦとIS-200で指定されたＡ８／Ａ９経由で通信するように構成することが出来る。

ネットワーク１０は、移動局２２に対する音声およびその他の回線交換呼サポートを提供し、また付加的に移動局２２に対してパケット交換呼サポートを提供する。本説明の中で、「呼」という用語は広い範囲で与えられており、ネットワーク１０へのデータおよび非データ接続の両方を含む。従って、特に指定されない限り、呼という用語は移動局２２がネットワークと何らかの型式の接続を行っていることを意味しており、それらは回線交換音声、回線交換非音声、パケット・データ、またはその他の可能性がある。

同時サービスがネットワークおよび移動局のいずれでもサポートされていないか、または特定呼事象の中で同時サービスが所望されていないかまたは不可能であると想定すると、ネットワーク１０は本発明の１つまたは複数の実施例に基づく改善された呼処理を実現するプログラム・ロジックを実行するように構成できる。その様な処理ロジックは、例えばＭＳＣ２８内、またはＢＳＣ１４内、またはＭＳＣ２８とＢＳＣ１４とを組み合わせたものの中に、エンティティー相互シグナリングに基づいて実現できる。加えて、後ほど説明されるように移動局２２は本発明の１つまたは複数の実施例に基づく処理ロジックで構成することが可能である。

図２Ａおよび図２Ｂは本発明の１つの実施例に基づくプログラム・ロジック並びに方法例を図示する。図２Ａはネットワークの観点から移動局に宛てられた呼の処理例の詳細を示し、図２Ｂは移動局端末の観点から移動体で発信された呼の処理例の詳細を示している。

移動局に宛てられた呼の取り扱い処理は、ＭＳＣ２８が移動局２２への入力音声呼の受信に応答して開始される（ステップ１００）。移動局２２が待機状態の場合（ステップ１０２）、ネットワーク１０は呼配信処理を実行し、此処で移動局２２への呼を終了しようと試みる（ステップ１０４）。

ＭＳＣ２８は移動局２２が話し中であるか否かを、関連するＶＬＲ情報または他のデータを検査することで判定できる。移動局２２が音声呼で話し中の場合、ＭＳＣ２８は所望通りに呼処理を提供する（ステップ１０８）。例えば、移動局２２に関連する加入者プロファイルが呼待機機能を有効とするかを示すはずである。もしそうであれば、呼待機処理が実行される。それ以外の場合、その呼は音声メールに配信され、発呼者に対して話し中または利用不能指示などが戻される。

移動局２２が非音声呼で話し中の場合、ＭＳＣ２８は呼配信を試みるか否かの判断をしなければならない（ステップ１１０）。この動作は明示的なプログラム・ロジック動作では無いことに注意されたい：例えば、ＭＳＣ２８は、非音声で話し中の移動局に対して常に呼配信を試みるように構成することが可能であり、またはＢＳＣ１４がその様な配信の試みをサポートするように構成されているか否かを識別するデータを提供することにより、またはＢＳＣ１４からそれがその様に構成されているという指示を受け取ることに基づいて、その様な試みを選択的に行うように構成することも可能である。

いずれの呼配信も試みられない場合、ＭＳＣ２８は単に情報付き速報（Flash-With-Information : FWI）メッセージ、または同様のものをＢＳＣ１４に対して生成し、移動局２２に対してその移動局に現在割り当てられているトラヒック・チャンネル上のシグナリングを介して配信する（ステップ１１２）。このメッセージは、例えば発呼者識別情報を含むことも可能であるし、または単に移動局２２に対して入力呼が失われたとの警告のみを提供することも可能である。一方、ネットワーク１０はどの様な呼処理がその入力呼に所望されても提供できる。すなわち、ＭＳＣ２８はその入力呼を音声メールに転送することも出来るし、または話し中表示を発呼者に戻してその呼を切断することも可能である（ステップ１１２）。

従って、移動局２２が非音声呼で話し中の時に呼配信を試みないという実施例において、使用者にはそれにも関わらず、誰かが彼または彼女の移動局に呼を試みているとの警告がリアルタイムに与えられる。先に述べたように、ネットワーク１０から送られた警告メッセージは発呼者情報を含むことが可能であり、そのデータは移動局２２の中に格納されて返信呼を出す際に使用することが可能である。これはまた使用者が誰かが電話接続を試みており、発呼者が再び試みた場合に、彼の電話機を解放することを認識できる。

本発明のこの実施例において、移動局使用者は非音声呼、例えばパケット・データ呼を継続することが可能であり、入力音声呼があるとの警告を受けることができる。使用者がその様な呼を知らないでいるか、またはその様な呼によってデータ呼が切断されるような従来の方法とは対照的に、本発明のこの実施例は直ちに呼通知を行い、この使用者がその失われた音声呼に応答するかまたいつ行うかを判断することが可能である。

別の実施例において、ネットワーク１０は入力音声呼の配信を試みるように構成されている（ステップ１１０）。その場合、ネットワーク１０は移動局２２が現在行っている非音声呼の性質を判別するように構成できる。移動局２２がＰＬＤ，ＳＭＳ，ＯＴＡＰＡ、またはその他の回線交換データ呼を行っている場合、おそらくその使用者はその移動局が話し中状態であることを知らないはずである。これらの型式の非音声サービスを此処では「タイプ１」データ・サービスと呼ぶ。それに引き替え、「タイプ２」データ・サービスは、例えばウェブ・ブラウジング、音声メール、ストリーミング媒体などの様なパケット・データ・サービスであり、此処で使用者は自分がネットワーク１０にほとんど確実に接続していることを知っている。

呼をどの様に配信するかの試みは、移動局２２がタイプ１またはタイプ２データ呼のいずれかに依存して行われる。ＢＳＣ１４は呼型式を、例えば移動局２２のサービス・オプション（ＳＯ）接続を検査することにより判定できる。ＢＳＣ１４が、移動局２２がタイプ１データ呼を行っていると判定すると（ステップ１１４）、これは移動局のＳＯ接続を再構成して、音声呼の移動局２２への配信をサポートする。ＢＳＣ１４は必要に応じてボコーディング資源を追加し、ＭＳＣ２８に対してそれらとの間で音声呼トラヒックを搬送するデータ接続を確立する様に信号通知を行う。ひとたび音声呼が設定されると、ＢＳＣ１４は移動局２２に警告する。

これらの全てはこれ以降に更に詳細に説明されるが、これらの動作はネットワーク１０および移動局２２が、トラヒック・チャンネルを含む、音声呼で使用されるタイプ１データ呼に割り当てられた、通信資源の一部または全てを保持し、これによってシグナリングが大幅に削減される。すなわち、移動局の現在の接続を切断するのではなくむしろ、その接続を必要に応じて再使用し、入力音声呼をサポートする。

加えて、移動局のサービス接続をデータから音声に再構築し、既存のトラヒック・チャンネルを保持（再使用）することで、呼設定が削減され（ページングもチャンネル割り当ての必要も無い）、呼設定の信頼性および安全性が増す。これらの後者の利益は増加するがそれは、本発明により呼通知および呼配信に関連するシグナリング・メッセージが移動局の既存の専用トラヒック・チャンネル上で発生し、これは信頼性が高く、おそらく安全な通信リンクだからである。従来型ネットワークでは、その様なシグナリングは共通ページング／接続チャンネル上で生じ、これは共有化され電力制御されておらず、エアーインタフェース上でメッセージ衝突／失敗を生じがちである。

別の特長として、ネットワーク１０は多くの事象において、データ呼でサポートされていた動作を継続することが可能であり、これは例えば音声呼を搬送するために使用される同一トラヒック・チャンネル上で、ブランク・アンド・バースト（blank-and-burst）またはディム・アンド・バースト(dim-and-burst)シグナリングを使用することで行われる。すなわち、既存トラヒック・チャンネルが音声サービスに切り替えられても、ネットワーク１０は、適切な場合には従前のデータ・トランザクションを音声チャンネル上で継続するように構成できる。

ロジック・フローに戻ると、移動局２２がタイプ２データ呼で話し中の場合（ステップ１１４）ほとんどの場合使用者はネットワーク１０への接続を開始すると思われるし、少なくともそれに気づく。その場合、移動局２２に対して信号を送り、その使用者にその入力音声呼の受け入れを希望するか否かを促すのが好適である。拒否応答を受信するかまたは応答が無い場合、呼配信は試みられず、実行中のタイプ２データ呼が外乱を受けることなく残され、所望の呼処理がその入力音声呼に対して適用される（ステップ１２２）。例えば、音声呼を音声メールに転送したり、または話し中表示を発呼者に戻したりすることが可能である。肯定応答が受信されると、例えば移動局２２がタイムリーに応答メッセージを戻すと、移動局のサービス接続は音声サービスに再構成され、移動局２２には音声呼が設定された時に注意が喚起される（ステップ１１６）。

上記のネットワークに基づく処理ロジックとは対照的に、図２Ａは移動体から発せられた呼を処理するために移動局２２内に組み込むことが可能な処理方法例を追加的に図示している（ステップ１２４）。此処で、移動局２２の使用者は移動局が話し中の時に、音声呼を開始しようと試みていると仮定している。実際的には、これは使用者が気づいていないタイプ１データ呼で移動局２２が話し中であったことを意味し、すなわち使用者はその移動局がタイプ２のデータ呼、すなわちウェッブ・ブラウジングなどを使用している場合、または既に音声呼を使用している場合には、単純に外部発信ダイアルを開始することはないと想定している。

従って、図２Ｂの説明を続けると、移動局２２はダイアル入力（例えば数値と「送信」命令）をその使用者から受け取り、タイプ１データ呼で話し中か否かを判定する（ステップ１２６）。そうでない場合（かつ、そうでなければ待機中であると想定される場合）、移動局２２は従来の移動局がそうするように、呼の開始を実行する（ステップ１２８）。しかしながら、移動局２２がタイプ１データ呼で話し中であることを認識する場合、そのダイアル情報をＦＷＩメッセージまたは同様のものとして、現在その実行中のデータ呼に割り当てられているトラヒック・チャンネル上に送信する（ステップ１３０）。

すなわち、移動局の処理ロジックは既存の接続を切断することなく、従来の呼発信をダイアル情報をシグナリング情報としてその現在割り当てられているトラヒック・チャンネル上に送信するように構成し、続いてネットワーク１０が音声接続を既存のチャンネルを用いて確立するのを待つように構成されている（ステップ１３２）。もちろん、移動局２２は使用者に、従来（正常）呼の発信中に提供されるものと同一または類似のダイアル表示を提供し、データ呼で話し中の時にダイアルすることが、使用者の観点から従来のダイアル処理と同様に見えるように構築することもできる。すなわち、移動局２２はその使用者に移動局２２が話し中で従来型移動局発信の呼が開始された時に、使用者がダイアル出力を行った場合に起きたであろうものと同一または類似の呼ダイアリングを提供するように構築できる。

図３Ａおよび３Ｂは、それぞれＭＳＣ２８および移動局２２での処理ロジック例を図示しており、図２Ａのステップ１１２で導入された呼発信を意図しないロジックに対応している。説明されたように、非発信処理オプションはＭＳＣ２８またはネットワーク１０内の何処かで適切な提供情報を経由するようにも構成できるし、またはＭＳＣ２８で動的に選択することも可能である。いずれの場合も、図３ＡはＭＳＣ２８において、ハードウェア、ソフトウェア、またはそれらの組み合わせとして実現できるロジックを図示する。

処理はＭＳＣ２８が移動局２２宛の入力音声呼を受信した時点で開始し（ステップ１４０）、その移動局２２が待機中であるか否かの判断を行う（ステップ１４２）。先に説明したように、ＭＳＣ２８は話し中／話し中で無いかの判定を、ＶＬＲ記録を検証することで行うように構成できる。移動局２２が待機中の場合、従来型呼配信が試みられる（ステップ１４４）。しかしながら、移動局２２が待機中では無く音声通話で話し中の場合（ステップ１４６）、ＭＳＣ２８は呼処理を所望の通りに提供する（ステップ１４８）。先に説明したように、その様な呼処理には音声メール配信、呼待ち配信を含んだり、または単に話し中表示を発呼者に戻すだけというのも含まれる。どの処理が提供されるかは、加入者プロファイル情報、提供初期設定などに依存する。

移動局２２が音声以外で話し中（タイプ１または２データ呼）の場合、ＭＳＣ２８は、好適に発呼者表示情報を含むＦＷＩメッセージをＢＳＣ１４に送信し、所望の呼処理、例えば音声メール、話し中などを提供する（ステップ１５０）。ＢＳＣ１４はＦＷＩメッセージを移動局２２に対して、移動局に現在割り当てられているトラヒック・チャンネル上の制御シグナリング経由で配信することに注意されたい。

図３Ｂは対応する移動局ロジックを図示する。移動局２２はＦＷＩ入力を現在割り当てられているトラヒック・チャンネル上の制御シグナリング経由で受信する（ステップ１６０）。移動局２２は通知メッセージ情報を格納し（ステップ１６２）使用者に対して警告し（テキスト表示、音響など）、現在のデータ呼を継続する（ステップ１６４）ように構築可能である。後ほど使用者の裁量により、格納されている情報が移動局２２によって、先の発呼者に対し呼を開始する際に使用される（ステップ１６６）。

図３Ａおよび３Ｂは非配信ロジック例を図示していたが、図４および５はそれぞれＭＳＣ２８およびＢＳＣ１４での、呼配信が移動局２２に対して試みられる場合の処理例を図示する。図４において、処理はＭＳＣ２８が入力音声呼をＰＳＴＮから、別のＭＳＣなどから受信した所から始まる（ステップ１７０）。

ＭＳＣ２８はその移動局が待機中か否かを判断する（ステップ１７２）。その様な判断は、例えばＶＬＲ記録を検証して行うことができる。移動局が待機中の場合、ＭＳＣ２８は移動局宛の呼配信処理を開始する（ステップ１７４）。移動局が話し中の場合、例えばトラヒック・チャンネル（待機中ではない）上で、ＭＳＣ２８はＦＷＩメッセージをＢＳＣ１４へ送り、呼入力通知と予定された配信を開始する（ステップ１７６）。これと同時に、ＭＳＣ２８は入力音声呼を「一時滞留」させ内部タイマ、ＴＰＡＴＫを起動し、これはＢＳＣ１４からの返信シグナリングを待つ一方で、時間切れの時に呼配信を試みるために使用される。呼滞留中に、ＭＳＣ２８は呼び出し音またはその他の表示を発呼者に与えるように構成することが可能である。

ＢＳＣ１４からの返信シグナリングの前にＴＰＡＲＫの時間が切れると（ステップ１７８）ＭＳＣ２８は所望の呼処理を入力呼に対して提供する、例えば音声メールなど（ステップ１８０）。その一方で、ＦＷＩメッセージがＴＰＡＲＫの時間が切れる前にＢＳＣ１４から返信される場合（ステップ１８２）、これは移動局が音声通話で話し中であったことを示しており、従ってＭＳＣ２８は呼待ち、呼協議、またはその他の処理を加入者プロファイルまたは提供情報で示されたように実行する（ステップ１８０）。

従って、呼配信が試みられる場合には、ＭＳＣ２８はＦＷＩメッセージをＢＳＣ１４に送り、移動局２２への呼通知のきっかけを作る。移動局２２が既に音声呼中の場合、ＭＳＣ２８は適切なＦＷＩ返信メッセージをＢＳＣ１４から受け取る。しかしながら、移動局が非音声通話で話し中（タイプ１または２データ呼）、ＭＳＣ２８はＢＳＣ１４から、返信ＦＷＩメッセージではなく、付加サービス要求（Additional Service Request : ASR）メッセージを受け取る（ステップ１８４）。返信ＡＳＲメッセージが要求されるのは、移動局の既存ＳＯ接続が非音声であり、移動局の既存トラヒック・チャンネルを入力音声呼用に再使用するためには変更または再構築しなければならないからである。従って、ＡＳＲメッセージはＭＳＣ２８へ警告するに際して、音声呼配信の試みを継続し、現在のデータ接続の音声サービスへの切り替えサポートに際して必要な呼資源の追加／再構築を行うという二重の目的がある。

ＡＳＲメッセージが受信されると、ＭＳＣ２８は呼の設定と、移動局の既存データ呼に割り当てられた通信資源を再利用するために必要なサービス交換／再構築を続行する（ステップ１８６）。これを実行するために、ＭＳＣ２８は音声接続を自身とＢＳＣ１４との間に設定し、ＢＳＣ１４でのボコーダ割り当ておよびＳＯ接続を、割り当て要求（Assignment Request : AR）メッセージをＢＳＣ１４に送ることで促す。それに応答して、ＢＳＣ１４は新たなＳＯ接続を移動局２２に対して確立し、音声呼をサポートする。一度ＢＳＣ１４がトラヒック・チャンネルの再調整を行うと、これは割り当て完了（Assignment Complete : AC）メッセージをＭＳＣ２８に送り、移動局２２が音声呼に対する準備が整ったことを示す。（ＢＳＣ１４は警告、例えば呼び出し音を移動局２２に提供できることに留意されたい。）

移動局の使用者がその音声呼に答えると、移動局２２は接続指令をＢＳＣ１４に返却し、ＢＳＣ１４は続いて接続メッセージをＭＳＣ２８へ送信し、移動局２２がその呼に対して返答したことを示す。この時点で、移動局２２は発呼者と音声通話を行う。移動局の従前データ呼の処分はそのタイプに依存し、その詳細をすぐ次にＢＳＣ処理例に基づき説明する。

呼配信の後、ＭＳＣ２８は移動局２２の「呼状態」を、その移動局２２が現在は音声サービス中である事実を記録するように更新する。例えば、ＭＳＣ２８はＶＬＲ記録を更新するように構築できる。呼状態を交信することにより、移動局２２がまだ音声通話で話し中の間に入力される後続の音声呼が、ＭＳＣ２８により、呼待機またはその他の音声指向呼処理に基づき適切に処理されることが保証される。

図５は、移動局２２が話し中の時に、意図された音声呼配信をサポートするＢＳＣ処理例を図示する。ＢＳＣ１４はＭＳＣ２８からＦＷＩメッセージを、入力呼表示として受け取る（ステップ１９０）。ＢＳＣ１４は移動局２２が音声呼で話し中であるか否かを判定し（ステップ１９１）、もしそうである場合、処理は呼待機手順またはその他の音声呼話し中処置例に従って続行される（ステップ１９３）。呼待機では、ＢＳＣ１４は単にＦＷＩメッセージを移動局２２に回送し、全ての返却応答を呼処理用にＭＳＣ２８に中継する。

しかしながら、移動局が音声通話で話し中ではなく、データ呼で話し中の場合、ＢＳＣ１４は移動局２２がタイプ１またはタイプ２データ呼（回線交換データ対パケット・データ）のいずれに従事しているかを判定する（ステップ１９２）。移動局がタイプ１データ呼に従事している場合、呼配信を試みる前に移動局に対して警告を与える必要がないが、それは使用者が話し中状態を知らないと思われるからである。従って、ＢＳＣ１４はＦＷＩを移動局２２へ送らず、代わりに直ちにＡＳＲメッセージをＭＳＣ２８に送って呼設定、例えば必要に応じて音声搬送伝送用ＢＳＣ−ＭＳＣの設定、ＰＳＴＮ接続の設定など、を続行する。

ＢＳＣ１４はまた移動局のサービス・オプションの再構築を、例えば音声処理をサポートるためにボコーダ資源を追加したり、移動局宛音声呼をサポートするための音声呼で使用するために既存のトラヒック・チャンネルを再調整することによって行（ステップ１９４）。ＡＳＲメッセージは移動局に由来するものでもなくまた移動局２２からのページング入力にも依らずＢＳＣ１４によって生成されるものであるため、ＢＳＣ１４はデフォルト音声サービス・オプション、例えばＥＶＲＣ，８Ｋまたは１３Ｋボコーディングを要求するように構築できる。その様なデフォルトは音声呼が接続された後再調整できる。これに代わって、ＭＳＣ２８は使用されるサービス・オプションをその返却割り当て要求の中に、例えば加入者プルファイルまたはその他の情報に基づいて提案できる。

いずれも関係なく、ＢＳＣ１４はＡＳＲメッセージを送った後、呼設定を続行しＭＳＣ２８から対応するＡＲメッセージが戻されるのを待つ。返却メッセージを受け取ると、ＢＳＣ１４は必要に応じてチャンネルを再調整し、移動局２２に対する警告表示を提供することが可能であり、これによってその使用者に入力呼表示、例えば呼び出しベルまたはその他の表示器を提供できる（ステップ１９６）。

ＢＳＣ１４と移動局との間のサービス調整は入力音声呼をサポートするためのサービス形態を確立する。このサービス形態は移動局２２およびＢＳＣ１４で使用され、各々がトラヒック・チャンネル・フレームを解釈することを可能とする、パラメータ並びに属性を識別する。

一度音声呼が移動局の既存トラヒック・チャンネル上で接続されると、ネットワーク１０は従前タイプのデータ呼で実施されているトランザクションを継続することができる。例えば、音声呼が入力された際に移動局２２がＰＬＤまたはＳＭＳに従事していた場合、そのトランザクションに関連するデータは再構成されたトラヒック・チャンネル上の制御シグナリングを経由して継続できる。従って、この様にしてネットワーク１０は従前のデータ呼トランザクションを制御シグナリングに音声トラヒックを混合することで完了するように構成できる。先に説明したようにその様な制御シグナリングは、トラヒック・チャンネル上のブランク・アンド・バースト(blank-and-burst)またはディム・アンド・バースト(dim-and-burst)シグナリングである。

タイプ１データ・サービスではなく、移動局２２がタイプ２データ呼で話し中の場合（ステップ１９２）、移動局使用者に対して入力音声呼が存在するが、そのデータ呼を中断して音声呼を受信するか否かは使用者の裁量である旨の通知を行うのが好適である。従って、ＢＳＣ１４が移動局２２がタイプ２データ呼で話し中であることを検出すると、それはＦＷＩメッセージを移動局２２へ送り（ステップ１９８）、その入力音声呼を受信するという使用者の希望を表示した返答が提示されるべきであることを示す。ＢＳＣ１４は移動局の返答を待つ間に１つまたは複数のタイマを起動することが可能であり（ステップ２００）、その様な応答を時間内に受け取ることに失敗すると、呼配信が所望されていないという表示と取られる。従って、ＢＳＣ１４はその呼配信の意図を時間切れとすることが可能であり（ステップ２０２）、これは先に説明したＭＳＣ２８内のＴＰＡＲＫタイマを時間切れとし、音声呼を見送ったり、音声メールに回送したり、または他の所望の処理に導くことを可能とする。

しかしながら、ＢＳＣ１４が時間内にＦＷＩメッセージを移動局２２から応答として受け取ると、これは呼配信の試みを続行する表示と受け取られる。従って、ＢＳＣ１４は適切に構成されたＡＳＲメッセージをＭＳＣ２８へ送り、先に説明したように再構成等を実行する、ステップ１９４および１９６参照。

しかしながら、タイプ１データ呼とは異なり、タイプ２データ呼は現行のトラヒック・チャンネルが音声呼で使用するために再構築された後は、その上で継続できないことに注意されたい。従って、ＢＳＣ１４は今中断されたパケット・データ呼を休止状態とされるべきかまたは解放されるべきかをＰＣＦに信号を送るように構成できる。すなわち、使用者がそのパケット・データ呼を音声呼が終了した後に再開したいと望む場合、移動局のパケット・データ・セッションをしばらくの間保存することができる。休止状態または解放はＢＳＣのＡ８／Ａ９インタフェースを経由してＰＣＦに信号通知できる。

更に、ネットワーク１０が非音声呼で話し中の移動局に音声呼配信を行うように構成されている場合でも、事前規定またはその他のデータ、例えば加入者プロファイルを用いて、その様な試みを制御することが可能である。例えば、ネットワーク１０は移動局使用者が呼配信を希望するか否かをダイナミックに選択できるように構成することができる。そのやり方の中では、使用者に特に重要なデータ呼の場合、音声呼配信は無効にされるか、または一定期間（時間、日など）無効として使用者により再び有効にされる。これに代わって、移動局２２は呼配信の試みを有効または無効とする処理ロジックを含むように構成することが可能で、無効とする場合はネットワーク１０からの呼配信の試みを無視することで行う。

上記のＭＳＣ／ＢＳＣプログラム・ロジックの補足として、図６はその様な呼配信を試みる方法をサポートする移動局処理ロジックの例を図示する。図６は使用者に注意を促す方式の呼配信を図示しているが、移動局が非音声データ・サービス、例えばＰＬＤまたはＳＭＳ、すなわち非音声回線交換データ・サービスで話し中の場合は、ＢＳＣ１４に送られるＭＳＣのＦＷＩ呼通知メッセージは、ＢＳＣ１４から移動局２２には転送されず、従って使用者には音声呼配信に関して催促がなされないことに注意されたい。

むしろ先に説明したように、ＢＳＣ１４は音声サービスをＭＳＣ２８から要求し、音声サービスに対する移動局のサービスを、移動局２２とのサービス再調整の実行を含めて、再構成する。すなわち、ＢＳＣ１４および移動局２２は必要に応じて互いに信号を送り合って、音声呼をサポートする際に使用されるトラヒック・チャンネルを再調整する。次に、ＢＳＣ１４が移動局２２に対して音声呼が設定されたことを警告すると、移動局２２はその音声呼に対して接続指令または同様の指令をＢＳＣ１４に送ることにより回答する。

図６が図示する処理例は、移動局がパケット・データ呼に従事している場合は異なるが、それは移動局使用者が入力音声呼を受信する代わりに、データ呼の継続を望む場合があり得るからである。従って、パケット・データで話し中の例では、ＢＳＣ１４は移動局使用者が入力音声呼を受信することを望むか否かを、移動局２２へ呼通知を送ることにより、例えばＭＳＣ２８からＦＷＩメッセージを受信したことに応答して、移動局２２へＦＷＩメッセージを送ることにより判断しようと試みる。

従って、処理は移動局２２がパケット・データ呼で話し中であると想定し、かつＦＷＩメッセージをＢＳＣ１４から受け取った所から開始される（ステップ２１０）。ＦＷＩメッセージを受信したことに応答して、移動局２２は使用者に対して音声呼を受信することを所望するか否かを指示するように催促する（ステップ２１２）。使用者が受け入れない場合は（ステップ２１４）移動局２２は現在のデータ・サービスを継続する（ステップ２１６）。ネットワーク１０は呼配信の試みを、移動局２２から返答を受け取らないという理由で時間切れとできることに注意されたい。

使用者が受け入れると、移動局２２はＦＷＩメッセージをＢＳＣ１４に戻し（ステップ２１８）、先に説明したように再調整と呼受け入れを続行する（ステップ２２０）。処理の一部として、移動局２２およびＢＳＣ１４は音声呼用に既存の専用トラヒック・チャンネルを再利用するためのサービス接続を再調整し、続いて移動局２２は音声呼が設定されたことを示す、ＢＳＣ１４からの警告メッセージを待つ。その警告は呼び出しベルまたは他の移動局２２の使用者に対する警告のきっかけとして使用できる。

使用者に催促する際に、移動局２２は音響催促、可視催促、またはその両方を提供して使用者に対して入力音声呼に関する警告を行うように構成できる。例えば、移動局２２はビープ音を鳴らしたり、テキスト・メッセージを表示したり、振動を発生したり、または警告機能の任意の組み合わせを実施することができる。発呼者識別情報が入力ＦＷＩメッセージの中に含まれていた場合、移動局２２はその情報を使用者に表示できる。

図７は本発明のいずれかの実施例をサポートするように構成できる移動局２２の例を図示する。移動局２２は受信機回路３００、送信機回路３０２、信号処理回路３０４、システム制御回路３０６、使用者インタフェース回路３０８、メモリ／格納装置３１０、およびデュプレクサ／スイッチおよび送信／受信アンテナを含む、アンテナ組み立て部品３１２で構成されている。

信号処理回路は、１つまたは複数の信号処理器、例えばＤＳＰ，ＡＳＩＣ，ＦＰＧＡなどを含み、これは受信および送信信号処理機能、例えばエンコーディング／デコーディング、誤り訂正などを提供する。受信機および送信機回路３００および３０２内の回路要素のいくつか、は互いに重複したりまたは信号処理回路３０４と一緒に集積出来ることに注意されたい。

システム制御回路３０６はマイクロプロセッサまたは他の論理回路を含み、信号処理回路３０４と集積することが出来る。システム制御回路３０６は全体の装置制御処理を提供し、表示スクリーン、キーパッド、マイクロフォン、拡声器などを含む、使用者インタフェース回路３０８を管理する。

メモリ／格納装置３１０は１つまたは複数のメモリ回路を含み、これは個別にまたは共有方式で処理および制御回路３０４および３０６に対してプログラム命令またはデータの格納を提供する。これらのメモリ回路は処理回路自身と集積可能なことに注意されたい。

とにかく、移動局処理ロジックの実施例は、メモリ／格納装置３１０内に格納された命令を含む、コンピュータ・プログラムとして実現可能であり、このメモリ／格納装置３１０は本文脈の中で命令を格納するためのコンピュータ読み取り可能媒体として機能する。もちろん、当業者には理解されるように、同様の機能はハードウェアに基づく論理回路、またはハードウェアとソフトウェアの混合として具備することも可能である。更に、当業者には理解できるように此処で使用されている移動局という用語は、広い意味でこれに限定するわけではなくセルラ無線電話を含む、無線通信装置の範囲を含む。

更に、此処で添付図と共に声明し図示してきた呼処理方法例は、ハードウェア、ソフトウェア、それらの何らかの組み合わせとして実現出来ることを理解されたい。１つの実施例において、ＢＳＣ１４は、音声呼通知例を実現する、１つまたは複数のマイクロプロセッサおよび支援回路（例えば、メモリ、インタフェースなど）とコンピュータ読み取り可能媒体内に格納されているコンピュータ・プログラムを含むプログラム命令を実行することに基づく配信方法とを含む。同様に、１つの実施例において、ＭＳＣ２８は１つまたは複数のマイクロプロセッサに基づく回路または、支援メモリ装置を含む同様の処理ロジックを含み、本発明の１つまたは複数の実施例に基づく音声呼通知および処理を実施する、格納されたプログラム命令を実行する。

しかしながら、その様な詳細事項は必要または希望に応じて変化し得ることは理解されよう。実際、本発明はこれらまたは先に例として示した詳細に制限されるものではない、以下の特許請求項およびそれらの道理にかなう等価なものによってのみ制限される。

図１は、その中で本発明を実施することが可能な無線通信ネットワークの例を示す。 図２Ａは本発明の実施例の処理ロジック図である。 図２Ｂは本発明の実施例の処理ロジック図である。 図３Ａは、本発明の１つの実施例に基づき、話し中移動局に対する呼通知配信に関連する、処理ロジック図である。 図３Ｂは、本発明の１つの実施例に基づき、話し中移動局に対する呼通知配信に関連する、処理ロジック図である。 図４は本発明の別の実施例に基づく呼通知およびオプション音声呼配信例に関連する、移動局交換センタおよび基地局処理ロジック図の例を示す。 図５は本発明の別の実施例に基づく呼通知およびオプション音声呼配信例に関連する、移動局交換センタおよび基地局処理ロジック図の例を示す。 図６は、本発明の１つまたはいくつかの実施例に基づく、移動局処理ロジック図例である。 図７は、本発明の１つまたはいくつかの実施例をサポートするように構成された移動局図例である。

Claims (14)

1. 無線通信ネットワーク内の呼処理方法であって：
   データ呼で話し中の移動局へ宛てられた入力音声呼表示を基地局（ＢＳ）で受信し；
   データ呼がパケット交換データ呼かまたは回線交換データ呼であるかを判定し；
   前記データ呼が回線交換データ呼の場合、移動局のサービス接続を、入力音声呼を従前データ呼に割り当てられていた既存トラヒック・チャンネルを用いて配信するように再構成し；
   前記データ呼がパケット交換データ呼の場合、呼通知メッセージを移動局に送り、移動局から確認返却を受信すると、移動局のサービス接続を既存トラヒック・チャンネルを用いて入力音声呼を配信するように再構成することを含む、前記方法。
2. 請求項１記載の方法が更に、前記データ呼が回線交換データ呼の場合、そのデータ呼に関連するデータ・トランザクションを入力音声呼を接続した後に、既存トラヒック・チャンネル上で既存トラヒック・チャンネル上のシグナリングを経由して継続することを含む、前記方法。
3. 請求項１記載の方法が更に、前記データ呼がパケット交換データ呼の場合、そのパケット・データ呼に関連するパケット・データ・サービスを中断することを含む、前記方法。
4. 請求項１記載の方法が更に、前記データ呼がパケット交換データ呼の場合、そのパケット・データ呼に関連するパケット・データ・サービスを解放することを含む、前記方法。
5. 請求項１記載の方法が更に、データ呼が回線交換データ呼であるかまたはパケット交換データ呼であるかを、そのデータ呼に関連する移動局の現行サービス・オプション接続を調べることにより判定することを含む、前記方法。
6. 請求項１記載の方法において、移動局のサービス接続を、入力音声呼を従前データ呼に割り当てられていた既存トラヒック・チャンネルを用いて配信するために再構成することが：
   音声サービス呼設定要求を移動体交換センタ（ＭＳＣ）に送り；
   音声回路割り当てをＭＳＣから受け取り；
   入力音声呼をサポートするためにＢＳで音声サービス・オプション接続を確立し；
   移動局に入力音声呼が設定されたことを情報通知するために移動局に警告することを含む、前記方法。
7. 請求項６記載の方法において、音声サービス呼設定要求メッセージを移動体交換センタ（ＭＳＣ）に送ることが、要求された音声サービス・パラメータを移動局から受け取る代わりに、デフォルト音声サービス・パラメータを生成することを含む、前記方法。
8. 無線ネットワーク内で呼処理を提供する基地局（ＢＳ）であって：
   複数の移動局に対して音声およびデータ呼処理を提供するために構成された、呼処理およびインタフェース回路と；
   データ呼で話し中の移動局を対象としている基地局（ＢＳ）での入力音声呼表示を受け取り；
   そのデータ呼がパケット交換データ呼であるか回線交換データ呼であるかを判定し；
   そのデータ呼が回線交換データ呼の場合、従前データ呼に割り当てられていた既存のトラヒック・チャンネルを用いて入力音声呼を配信するように、移動局のサービス接続を再構成し；
   そのデータ呼がパケット交換データ呼の場合、呼通知メッセージを移動局に送り、移動局から返却肯定確認を受け取ることに応答して、既存のトラヒック・チャンネルを用いて入力音声呼を配信するように、移動局のサービス接続を再構成するように構成された、通知プロセッサとを含む、前記基地局。
9. 請求項８記載のＢＳにおいて、このＢＳが音声呼に接続された後にデータ呼に関連するデータ・トランザクションを、データ呼が回線交換データ呼の場合、既存のトラヒック・チャンネル上でシグナリングすることにより継続するように構成されている、前記ＢＳ。
10. 請求項８記載のＢＳにおいて、このＢＳが音声呼に接続された後にデータ呼に関連するパケット・データ・サービスを、データ呼がパケット交換データ呼の場合に一時停止するように構成されている、前記ＢＳ。
11. 請求項８記載のＢＳにおいて、このＢＳが音声呼に接続された後にデータ呼に関連するパケット・データ・サービスを、データ呼がパケット交換データ呼の場合に解放するように構成されている、前記ＢＳ。
12. 請求項８記載のＢＳにおいて、このＢＳがそのデータ呼が回線交換データ呼であるかまたはパケット交換データ呼であるかを、そのデータ呼に関連する移動局の現行サービス・オプション接続を調べることにより判定するように構成された、前記ＢＳ。
13. 請求項８記載のＢＳにおいて、このＢＳが移動局のサービス接続を、従前データ呼に割り当てられていた既存のトラヒック・チャンネルを用いて配信するように：
    音声サービス呼設定要求を移動体交換センタ（ＭＳＣ）に送り；
    音声回路割り当てをＭＳＣから受け取り；
    入力音声呼をサポートするために音声サービス・オプション接続をＢＳで確立し；
    移動局に入力音声呼が設定されたことを情報通知するために移動局に警告することに基づいて、再構成する前記ＢＳ。
14. 請求項１３記載のＢＳにおいて、このＢＳが音声サービス呼設定要求メッセージを移動体交換センタ（ＭＳＣ）に、要求された音声サービス・パラメータを移動局から受け取るのでは無く、むしろＢＳで生成されたデフォルト音声サービス・パラメータを含む追加サービス要求メッセージとして送るように構成されている、前記ＢＳ。

Images