JP2008113227A - 無線通信システム、端末、および無線通信方法 - Google Patents

Abstract

【課題】呼制御プロトコルに基づかずＱｏＳ制御を施す技法を提供する。
【解決手段】端末(100)は、第1の無線ネットワークと通信する第1の無線通信手段(112)と、基地局(200)、PDSN(300)からなる第2の無線ネットワークと通信を行う第2の無線通信手段(114)と、無線通信部切替手段(145)と、端末が、第２の無線ネットワークと送受信するRTPパケットを検出するRTPパケット検出手段(120)と、RTPパケットを解析し、RTPパケットが関連するセッションがVoIP通信用のセッションであるか否かを判定するRTPパケット解析手段(130)と、VoIP通信用のセッションであると判定されたセッションに対してVoIP専用の補助セッションを割り当てるように要求する補助セッション割当要求をPDSNに送信する補助セッション割当要求手段(140)とを備える。PDSNは、補助セッション割当要求を受信し、VoIP通信用のセッションであると判定されたセッションに対してVoIP専用補助セッションを割り当てる補助セッション割当手段(310)とを備える。
【選択図】図１

Description

本発明は、無線通信システム、端末、および無線通信方法に関する。

ＩＰベースの無線移動通信基地局（iBURST）において、ＶｏＩＰアプリケーションによる音声通信を実用する場合、ナローバンドで低品質なネットワークにおいてもリアルタイムパケットの伝送を保障するため、第三世代携帯電話に関する標準化団体である「３ＧＰＰ２」では、ＩＳ８３５というマルチセッションを使用したＱｏＳ伝送方式が提案されている。このＩＳ８３５とは、マルチインスタンスを使用したＱｏＳ手法であり、移動ノード(MN)―基地局(BS)−コアネットワーク間において、1つの端末（ＰＰＰセッション）を、使用用途（アプリケーション）に応じた複数の無線セッションに分割することにより、アプリケーション毎のＱｏＳ制御を可能にした規格である。これにより、１人（ＰＰＰ）の無線端末ユーザが、データ通信とＶｏＩＰ通信を併用した場合も、音声品質を劣化することなくＶｏＩＰ通信を行うことが可能になる。なお、現在のところ３ＧＰＰ２においてまだ討議中（草案）の段階であり、仕様はまだ完全に決定されていない。

このＩＳ８３５の草案にて、ＭＮ（移動ノード）がマルチセッションを行うトリガとして、ＳＩＰ(Session initiation protocol)による発信・応答メッセージによって実行することが提案されている（非特許文献１を参照されたい）。図８に、提案技術ＩＳ８３５によるＴＦＴフィルタテーブル取得の処理を説明するシーケンス図を示す。図８に示すように、アクセスターミナルＡＴを構成するクライアントＰＣおよび端末ＵＴは、呼制御であるＳＩＰを使って、補助セッションを成功裏に確立して通信相手であるＳＩＰ端末との間で送受信される音声パケットを確立した補助セッションに流している。このようにして、提案技術ＩＳ８３５では、ＳＩＰによってマルチセッションを確立することが提案されている。
ウェブサイト（http://ftp.3gpp2.org/TSGX/Projects/X.P0011-D%20Wireless%20IP%20Network/PN-3-4732-RV4-chapter3.pdf）

上述したように、ＩＰベースの無線移動通信基地局（iBURST）において、ＶｏＩＰアプリケーションによる音声通信を実用する場合、ナローバンドで低品質なネットワークにおいてもリアルタイムパケットの伝送を保障するため、ＩＳ８３５というマルチセッションを使用したＱｏＳ伝送方式が提案されている。

しかしながら、移動ノード(MN)がモバイルＩＰ(MIP)を使用してＷｉＦｉなど異なるネットワークと併用している場合、iBurst側にＭＩＰハンドオーバーした時にＩＳ８３５の適応トリガの検出ができず、ＱｏＳ制御を適応することが出来ない。また、ＩＳ８３５ではＳＩＰをトリガとしたＱｏＳ制御を基本的に推奨しているが、ＳＩＰ以外の呼制御プロトコルを使用した場合、補助セッションを起動することが出来ないという問題がある。即ち、呼制御プロトコルによって音声セッションを検出するためには、移動ノード(MN)において全ての呼制御プロトコルを網羅しなければならず、実装規模が大きくなり、現実的には対応することが困難である。

ここで、移動ノード、即ち、端末がモバイルＩＰ（ＭＩＰ）クライアントの場合に、ＩＳ８３５を適用すると仮定する。ＭＮ端末がモバイルＩＰによりＷｉＦｉなど別ネットワーク網と併用した場合、ＩＳ８３５のマルチセッションフロー制御を実行できない場合がある。以下に、その典型的は例を説明する。

図９は、提案技術ＩＳ８３５によるマルチセッションが確立できないケースを説明するネットワーク構成図である。図に示すように、初期状態において、ＭＩＰクライアントは、ＷｉＦｉネットワークに接続中であり、ＷｉＦｉネットワーク経由でＳＩＰ電話機とＶｏＩＰ通信を確立している。次に、ＭＩＰクライアント（端末）はＷｉＦｉからｉＢｕｒｓｔ（ＩＳ８３５）にハンドオーバーする。しかしながら、ｉＢｕｒｓｔ（ＩＳ８３５）は、マルチセッションを起動するトリガとなる呼制御プロトコルを検出できず、ＱｏＳ制御を行うことができないという問題がある。
そこで、本発明は、呼制御プロトコルに基づかずに、送受信されるパケットから音声セッション（ＶｏＩＰ通信）を検出し、この音声セッション専用の補助セッションを割り当て、割り当てた補助セッション（音声セッション）に適切なＱｏＳ制御を施す技法を提供することを目的とする。

上述した諸課題を解決すべく、第１の発明による無線通信システム（装置）は、
端末が第１の無線ネットワークと第２の無線ネットワークを介してパケット通信を行う無線通信システムであって、
前記端末は、
前記第１の無線ネットワーク（ＷｉＦｉなどの無線ＬＡＮ）と通信する第１の無線通信手段と、
前記端末と無線で接続する基地局、および、該基地局を介して前記端末と通信を行うＰＤＳＮ（パケットデータサービングノード）からなる前記第２の無線ネットワーク（ｉＢｕｒｓｔなどの携帯電話ネットワーク）と通信を行う第２の無線通信手段と、
前記第１の無線通信手段と前記第２の無線通信手段とを切り替える切替手段と、
前記切替手段により、前記第１の無線通信手段から前記第２の無線通信手段への切り替えが行われると、前記端末が前記第２の無線通信手段により、前記第２の無線ネットワークとメインセッションを介して送受信するＲＴＰパケットを検出するＲＴＰパケット検出手段（回路など）と、
前記ＲＴＰパケット検出手段により検出されたＲＴＰパケットを解析し、該ＲＴＰパケットがＶｏＩＰ通信用のパケットであるか否かを判定するＲＴＰパケット解析手段（回路など）と、
ＶｏＩＰ通信用のパケットであると判定されたＲＴＰパケットに対して、前記第２の無線ネットワークにおいてＶｏＩＰ専用の補助セッションを割り当てるように要求する補助セッション割当要求を、前記基地局を介して前記ＰＤＳＮに送信する補助セッション割当要求手段（回路など）とを備え、
前記ＰＤＳＮは、
前記端末からの前記補助セッション割当要求を受信し、前記端末における前記ＶｏＩＰ通信用のパケットであると判定されたパケットに対して、前記第２の無線ネットワークにおいてＶｏＩＰ専用の補助セッションを割り当てる補助セッション割当手段（回路など）を備える、
ことを特徴とする。

また、第２の発明による無線通信システムでは、
前記端末は、
ＱｏＳ制御手段をさらに備え、
前記端末のＲＴＰパケット解析手段は、
ＶｏＩＰ通信用のパケットであると判定されたＲＴＰパケットのデータに含まれるコーディックタイプおよび当該ＲＴＰパケットの送信間隔を含むＲＴＰ解析結果をＱｏＳ情報として生成し、
前記ＱｏＳ制御手段は、
前記生成したＱｏＳ情報に基づき、前記ＶｏＩＰ専用の補助セッションに対してＱｏＳ制御を行う、
ことを特徴とする。

また、第３の発明による無線通信システムは、
前記端末は、
変調方式とデータレートとの組み合わせと、無線帯域とを対応付けたテーブルを格納する格納手段（メモリなど）と、
前記テーブルを参照して、前記ＱｏＳ情報に基づき算出される当該ＶｏＩＰ通信におけるＲＴＰトラフィックの帯域に基づき、当該ＶｏＩＰ通信の変調方式およびデータレートを固定する変調方式・データレート設定手段とをさらに備える、
ことを特徴とする。

また、第４の発明による無線通信システムは、
前記ＱｏＳ制御手段は、
前記ＱｏＳ情報に基づき、前記ＶｏＩＰ専用の補助セッションにより使用されるチャネルを他のチャネルよりも保持性が高いチャネル（例えば、タイムアウト時間を長くしたチャネルに設定する）に設定するように要求するチャネル設定要求を前記基地局に送信する、
ことを特徴とする。

また、第５の発明による端末は、
第１の無線ネットワーク（ＷｉＦｉなどの無線ＬＡＮ）と通信を行う第１の無線通信手段と、
基地局、および、該基地局を介して通信を行うＰＤＳＮからなる第２の無線ネットワーク（ｉＢｕｒｓｔなどの携帯電話ネットワーク）と通信を行う第２の無線通信手段と、
前記第１の無線通信手段と前記第２の無線通信手段とを切り替える切替手段と、
前記切替手段により、前記第１の無線通信手段から前記第２の無線通信手段への切り替えが行われると、前記第２の無線通信手段により、前記第２の無線ネットワークとメインセッションを介して送受信するＲＴＰパケットを検出するＲＴＰパケット検出手段（回路など）と、
前記ＲＴＰパケット検出手段により検出されたＲＴＰパケットを解析し、該ＲＴＰパケットがＶｏＩＰ通信用のパケットであるか否かを判定するＲＴＰパケット解析手段（回路など）と、
ＶｏＩＰ通信用のパケットであると判定されたＲＴＰパケットに対して、前記第２の無線ネットワークにおいてＶｏＩＰ専用の補助セッションを割り当てるように要求する補助セッション割当要求を、前記ＰＤＳＮに送信する補助セッション割当要求手段（回路など）と、
を備えることを特徴とする。

また、第６の発明による端末は、
変調方式とデータレートとの組み合わせと、無線帯域とを対応付けたテーブルを格納する格納手段（メモリなど）と、
ＶｏＩＰ通信の変調方式およびデータレートを固定する変調方式・データレート設定手段（回路など）とをさらに備え、
前記ＲＴＰパケット解析手段は、
ＶｏＩＰ通信用のパケットであると判定されたＲＴＰパケットに含まれるデータのコーディックタイプおよび当該ＲＴＰパケットの送信間隔を含むＲＴＰ解析結果をＱｏＳ情報として生成し、
前記変調方式・データレート設定手段は、
前記テーブルを参照して、前記生成したＱｏＳ情報に基づき算出される当該ＶｏＩＰ通信におけるＲＴＰトラフィックの帯域に基づき、当該ＶｏＩＰ通信の変調方式およびデータレートを固定する、
ことを特徴とする。

また、第７の発明による端末は、
前記割り当てられたＶｏＩＰ専用の補助セッションを前記ＲＴＰパケット検出手段により監視し、所定期間に亘りパケットの送受信が検出されないとき、前記割り当てられたＶｏＩＰ専用の補助セッションを切断する補助セッション切断手段（回路など）をさらに備える、
ことを特徴とする。

上述したように本発明の解決手段を装置として説明してきたが、本発明はこれらに実質的に相当する方法、プログラム、プログラムを記録した記憶媒体としても実現し得るものであり、本発明の範囲にはこれらも包含されるものと理解されたい。

例えば、本発明を方法として実現させた第８の発明による方法は、
端末が第１の無線ネットワークと第２の無線ネットワークを介してパケット通信を行う無線通信方法であって、
前記第１の無線ネットワーク（ＷｉＦｉなどの無線ＬＡＮ）と通信する第１の無線通信ステップと、
前記端末と無線で接続する基地局、および、該基地局を介して前記端末と通信を行うＰＤＳＮ（パケットデータサービングノード）からなる前記第２の無線ネットワーク（ｉＢｕｒｓｔなどの携帯電話ネットワーク）と通信を行う第２の無線通信ステップと、
前記第１の無縁ネットワークから前記第２の無線ネットワークにハンドオーバーするハンドオーバーステップと、
前記ハンドオーバー後に、前記端末がメインセッションを介して前記第２の無線ネットワークと送受信するＲＴＰパケットを検出するＲＴＰパケット検出ステップと、
前記検出されたＲＴＰパケットを解析し、該ＲＴＰパケットがＶｏＩＰ通信用のパケットであるか否かを判定するＲＴＰパケット解析ステップと、
ＶｏＩＰ通信用のパケットであると判定されたＲＴＰパケットに対して、前記第２の無線ネットワークにおいてＶｏＩＰ専用の補助セッションを割り当てる補助セッション割当ステップと、
を有することを特徴とする。

本発明によれば、呼制御プロトコルに基づかずに、送受信されるパケットに基づき音声セッション（ＶｏＩＰ通信）を検出して、この音声セッション専用の補助セッションを割り当てることが可能になる。音声セッション専用の補助セッションを割り当てることによって、この補助セッションに対してメインセッションとは異なる適切なＱｏＳ制御を施すことが可能となる。

以降、諸図面を参照しながら、本発明の実施態様を詳細に説明する。図１は、本発明の実施態様による無線通信システムのネットワーク構成図である。図１に示すように、本発明が対象とする無線通信システムは、主として端末（ＵＴ）１００、基地局（ＢＳ）２００、およびＰＤＳＮ（パケットデータサービングノード）３００から構成される。また、端末１００がＭＩＰ端末として機能するときは、ＷｉＦｉネットワークＷＮＥＴ（本明細書における第１の無線ネットワークに相当する。）のアクセスポイントＷＦＡＰに接続する。ＷｉＦｉネットワークＷＮＥＴは、フォーレンエージェント（ＦＡ）５００、コアネットワークＣＮＥＴ、ホームエージェント（ＨＡ）４００、ネットワーク（インターネット、或いはＬＡＮなど）ＮＥＴを介してＳＩＰ端末６００に接続している。

端末１００は、無線通信部１１０、ＲＴＰパケット検出部１２０、ＲＴＰパケット解析部１３０、補助セッション割当要求部１４０、および無線通信部切替スイッチ（部）１４５を備える。無線通信部１１０は、ＷｉＦｉネットワークＷＮＥＴのアクセスポイントＷＦＡＰとデータを送受信する第１の無線通信部１１２と、基地局２００側とデータを送受信する第２の無線通信部１１４とを備える。

端末１００の第１の無線通信部１１２は、アクセスポイントＷＦＡＰと接続する機能を持ち、アクセスポイントＷＦＡＰ経由で、ＷｉＦｉネットワークＷＮＥＴ、フォーレンエージェント（ＦＡ）５００、コアネットワークＣＮＥＴ、ホームエージェント（ＨＡ）４００、ネットワーク（インターネット、或いはＬＡＮなど）ＮＥＴを順次に介してＳＩＰ端末６００とセッションを持ち、データを送受信することが可能である。

他方、端末１００の第２の無線通信部１１４は、無線通信を介して基地局（ＢＳ）２００と接続する機能を持ち、基地局２００、ＰＤＳＮ３００、コアネットワークＣＮＥＴ、ホームエージェント４００、およびネットワークＮＥＴを順次に介してＳＩＰ端末６００とＳＩＰ呼制御を使わずに補助セッションを持ち、データ（本実施態様では主として音声パケットを対象とする）を送受信することが可能である。なお、端末１００、基地局２００およびＰＤＳＮ３００による無線ネットワークが、本明細書における第２の無線ネットワークに相当する。無線通信部切替スイッチ１４５は、端末１００がＷｉＦｉネットワークＷＮＥＴと基地局２００側の無線ネットワークとの間でハンドオーバーを実行するにあたり、第１の無線通信部１１２と第２の無線通信部１１４の切り替えを行う。

ＲＴＰパケット検出部１２０は、端末１００がＷｉＦｉネットワークＷＮＥＴから基地局２００側にハンドオーバーした時、即ち、無線通信部切替スイッチ１４５により、無線通信部が第１の無線通信部１１２から第２の無線通信部１１４に切り替えられた時に、第２の無線通信部１１４により、基地局２００を介してＰＤＳＮ３００と送受信するＲＴＰパケットを検出する。ＲＴＰパケット解析部１３０は、ＲＴＰパケット検出部１２０により検出されたＲＴＰパケットを解析し、そのＲＴＰパケットがＶｏＩＰ通信用のパケットであるか否かを判定する（判定の詳細は後でフローチャートを参照して詳述する）。補助セッション割当要求部１４０は、ＶｏＩＰ通信用のパケットであると判定されたＲＴＰパケットに対して、ＶｏＩＰ専用の補助セッションを割り当てるように要求する補助セッション割当要求を、基地局２００を介してＰＤＳＮ３００に送信する。

ＰＤＳＮ３００は、補助セッション割当部３１０を備える。ＰＤＳＮ３００は、端末１００からの補助セッション割当要求を受信し、補助セッション割当部３１０が、端末１００におけるＶｏＩＰ通信用のパケットであると判定されたＲＴＰパケットに対して、当該無線ネットワークにおいてＶｏＩＰ専用の補助セッションを割り当てる。

図２は、図１に示した端末の詳細なブロック図である。図２に示すように、端末（ＵＴ）１００は、無線通信部１１０、ＲＴＰパケット検出部１２０、ＲＴＰパケット解析部１３０、補助セッション割当要求部１４０、および無線通信部切替スイッチ１４５を備える。ＲＴＰパケット検出部１２０は、受信側でＲＴＰパケットをフィリタリング（抽出）するＲＴＰパケットフィルタ１２２、および送信側で同様の処理を行うＲＴＰパケットフィルタ１２４とを含む。ＲＴＰパケット解析部１３０は、ＲＴＰパケットフィルタ１２２、１２４により抽出されたＲＴＰパケットを解析し、ＲＴＰパケットが関連するセッションがＶｏＩＰ通信用のセッションであることを検出する、上りＶｏＩＰセッション検出部１３２、および下りＶｏＩＰセッション検出部１３４を含む。

端末１００は、無線通信部１１０により送受信されるパケット用の送信バッファ１５０、および受信バッファ１５２をさらに備える。また、端末１００は、ＱｏＳ情報ＢＳ通知部１６０、無線ＱｏＳ制御部１６２、変調クラス制御部１６４、マルチセッション制御部１７０、ＶｏＩＰセッション制御部１７２、および無線ＱｏＳ判定スイッチ１７４をさらに備える。なお、補助セッション割当要求部１４０は、マルチセッションの制御を司るマルチセッション制御部１７０の一機能である。

無線ＱｏＳ判定スイッチ１７４は、ＲＴＰパケットに基づき、ＶｏＩＰ用の補助セッションに対して無線ＱｏＳ制御を行うか否かを諸条件（ＲＴＰ帯域、コーディックタイプなど）に基づき判定して、判定結果を含むＱｏＳ情報を生成する。無線ＱｏＳ制御部１６２は、受信電力レベルや上記の無線ＱｏＳ判定スイッチ１７４からの判定情報に基づき、変調クラス制御部１６４を用いて無線無線ＱｏＳを実行する。ＱｏＳ情報ＢＳ通知部１６０は、無線ＱｏＳ判定スイッチ１７４によるＱｏＳ情報を基地局２００に送信するように第２の無線通信部１１４を制御する。

また、端末１００は、送信バッファにキューイングされるＰＰＰパケットを構築するＰＰＰパケット構築部１５４、ＴＦＴパケットをフィルタリング（抽出）するＴＦＴパケットフィルタ１５６、受信バッファ１５２から受けたＰＰＰセッションであることを判定するＰＰＰ判定部１５８、ＰＰＰパケットを抽出するＰＰＰパケット抽出処理部１７６、ＰＰＰパケットを構築するＰＰＰパケット構築部１７８、イーサネット（登録商標）用に変換するＰＰＰｏＥパケット構築部１８０、および、クライアントＰＣとのインターフェイスを行うＰＣ＿Ｉ／Ｆ部１８２をさらに備える。これらの機能は、一般的な機能であるため詳細な説明を省略する。

図３は、図１に示した基地局の詳細なブロック図である。図３に示すように、基地局２００は、図１に示した補助セッション用チャネル割当部２１０以外に、無線通信部（ＵＴ側）２２０、ＵＴ側の受信バッファ２２２、ＵＴ側の送信バッファ２２４、無線ＱｏＳ制御部２３０、無線セッション制御部２３２、変調クラス制御部２３４、ＰＰＰパケット解析部２３６、２３８、およびマルチセッション制御部２４０をさらに備える。なお、補助セッション用チャネル割当部２１０は、マルチセッションの制御を司るマルチセッション制御部２４０の一機能である。

また、基地局２００は、Ａ１０／Ａ１１パケットを構築するＡ１０／Ａ１１パケット構築部２５０、Ａ１０／Ａ１１パケットを解析するＡ１０／Ａ１１パケット解析部２５２、Ａ１０／Ａ１１パケット構築部２５０に供給されるべきセッション制御情報を構築するセッション制御情報構築部２５４、Ａ１０／Ａ１１パケット解析部２５２の解析結果に基づきセッション制御情報を取得するセッション制御情報取得部２５６、ＰＤＳＮと通信を行うＰＤＳＮ通信部２６０、ＰＤＳＮ側の送信バッファ２６２、および受信バッファ２６４をさらに備える。

図４は、図１に示したＰＤＳＮの詳細なブロック図である。図４に示すように、ＰＤＳＮ３００は、図１に示した補助セッション割当部３１０以外に、ＢＳ通信部３２０、ＢＳ側の受信バッファ３２２、送信バッファ３２４、Ａ１０／Ａ１１パケット構築部３３０、Ａ１０／Ａ１１パケット検出部３３２、セッション制御情報取得部３３４、セッション制御情報構築部３３６、マルチセッション制御部３４０、ＰＰＰパケット構築部３４２、ＰＰＰパケット解析部３４６をさらに備える。なお、補助セッション割当部３１０は、マルチセッションの制御を司るマルチセッション制御部３４０の一機能である。

また、ＰＤＳＮ３００は、ＴＦＴ（トラフィックフローテンプレート）情報取得／通信部３４８、ＴＦＴパケットフィルタ３５０、コアネットワークＣＮＥＴと通信するコアネット通信部３６０、コアネットワーク側の受信バッファ３６２、および送信バッファ３６４をさらに備える。ＴＦＴ（トラフィックフローテンプレート）情報取得／通信部３４８は、メインセッション（インスタンス）、補助セッション別に、ＩＰアドレス、ポート番号などを規定するＴＦＴテーブルを構築する。構築されたＴＦＴテーブルを参照して、ＴＦＴ情報取得／通信部３４８およびＴＦＴパケットフィルタ部３５０がパケットのセッション別にパケットのフィルタリング処理を行う。ここで機能を説明したブロック以外の機能は、図２における同様の名称の機能とほぼ同じであるため説明を省略する。

＜移動ノードにおける通話中のＶｏＩＰセッション検出原理＞
以下の条件に当てはまる場合、ＶｏＩＰ通話セッションとして認識し、ＴＦＴマルチセッション制御を行う。検出ロジックは基本的にＲＦＣ１８８９ 付録Ａ．１に沿った検出を行う。図６を参照して、後で詳細に処理ステップを説明するが、ここでは基本的な検出ロジックを説明する。以下の条件を全て、所定の回数連続して満たした場合、ＶｏＩＰ通話セッションとして認識する（※所定の回数は任意に変更可能な数値とする。）。
・ＲＴＰヘッダのバージョン番号（Ｖ）＝２
・ＲＴＰヘッダのペイロードタイプがＩＢｕｒｓｔのＩＳ８３５ ＱｏＳ制御に適応するもので、検出回数ｎ分連続して同じ値であること。（具体的にはＧ．７２９[１８]）
・ＲＴＰペイロードサイズが検出回数n分全て同じサイズであること。
・ＲＴＰヘッダのシーケンス番号が所定の回数だけ連続して１ずつインクリメントされていること。
・ＩＰヘッダの送信元・先アドレスが検出回数n分連続して同じ値であること。
・ＵＤＰヘッダの送信元・先ポート番号が検出回数n分連続して同じ値であること。

＜アップリンク音声セッションのＩＳ８３５適応手順＞
ＶｏＩＰ通話セッションとして認識されたストリームがアップリンクパケット（移動ノード→ＰＤＳＮ方向）の場合、以下の処理を行う（詳細は、図７を参照して後で説明する）。
・iBurst端末は補助セッションを接続する。
・検出したＩＰアドレス、ＵＤＰポート番号に該当するパケットを補助セッションに透過する。

＜ダウンリンク音声セッションのＩＳ８３５適応手順＞
ＶｏＩＰ通話セッションとして認識されたストリームがダウンリンクパケット（ＰＤＳＮ→移動ノード方向）の場合、以下の処理を行う（詳細は図７を参照して後で説明する）。
・ＰＤＳＮにてＴＦＴフロー制御を行う必要があるため、ＰＤＳＮにRSVPメッセージにてＴＦＴ情報を送信する。このためiBurst端末(UT)は、ＰＤＳＮにRSVPメッセージにて検出したＩＰアドレス、ＵＤＰポート番号を送信する。
・RSVPのネゴシエーション成功後、iBurst端末(UT)は補助セッションを接続する。
・ＰＤＳＮはRSVPにて通知されたＩＰアドレス、ＵＤＰポート番号に該当するパケットを補助セッションに透過する。

＜適用ＱｏＳの選択原理＞
ＲＴＰパケットから、使用しているコーディック及びＲＴＰパケットの送信間隔を取得し、ＲＴＰトラフィックの帯域を算出する。iBurst端末（UT）は、上記で求めた帯域に基づいて、アップリンク方向のモッドクラスを固定することで、アプリケーションの品質を一定に保つことが可能となる。下表のように、計算した帯域に対応したアップリンクモッドクラスに固定する。以下例はコーディックタイプがG.729の場合の帯域と、対応（適応）するモッドクラスの一覧である。

＜ＶｏＩＰ ＱｏＳの適応（オプション）＞
iBurstでは、ＶｏＩＰ通信を安定した品質で提供するため、他のチャネルよりも保持性が高いチャネル（例えば、タイムアウト時間を長くしたチャネル）であるパーシスタントチャネルというＱｏＳ手法を採用している。即ち、パーシスタントチャネルとは、BSにおける無線L2制御（ストリーム制御）において、ＶｏＩＰデータの場合はストリームを送受信するデータが無くなってもしばらくの間保持することで、ストリームの再接続処理を抑制し、遅延がないパケットの伝送を実現する方式である（ＶｏＩＰが優先的に処理される）。通常ＲＴＰを使用するアプリケーションにおいて、ＶｏＩＰはリアルタイムにデータを届ける必要があるが、メディアストリームの場合、コーディック種別にもよるが、音声通信ほどシビアなリアルタイム性は追及されない。例えば、Ｈ．２６４の64Kbpsを使用したメディア通信の場合、パケットの送信間隔はアプリケーションの設定に依存するが、一般的に約100ms間隔程度でＶｏＩＰと比較してシビアなリアルタイム性を追及されないため、あえてＶｏＩＰと同様のＱｏＳを行う必要がない。このためＲＴＰパケットのペイロードタイプから、コーディックタイプがメディアのセッションはパーシスタントチャネルの制御を除外し、通常のデータと同様の無線ＱｏＳ制御を行う、という制御指定も可能になる。

＜移動ノード（MN）におけるＶｏＩＰセッション切断の検出＞
ＩＳ８３５によって接続中の補助セッションを監視して、一定期間（検出期間ｎと同様の時間）パケットの通行量がアップリンクまたはダウンリンクにおいて０の場合、補助セッションを切断し、ＴＦＴテーブルから該当ＶｏＩＰセッション情報を削除する。この切断検出と前述のＶｏＩＰセッション検出機能との組み合わせにより、アプリケーションの状態（呼制御プロトコル）に関係なくＩＳ８３５マルチセッションをコントロールすることが可能になる。

図５は、本発明による無線通信システムによる処理の一例を説明するシーケンス図である。図５に示すように、アクセスターミナルＡＴ（図示せず）を構成するクライアント（ＰＣ）８００および端末（ＵＴ）１００は、呼制御であるＳＩＰを使用せずに、補助セッションを成功裏に確立する。はじめに、ステップＳ１０にて、ＩＰアドレス＝Ａ、ＵＤＰポート＝ａを持つクライアント（ＰＣ）８００が、端末（ＵＴ）１００、基地局（ＢＳ）２００を経由するメインサービスインスタンス（ＰＰＰセッションであるメインセッション）をＰＤＳＮ３００と自装置との間で確立する。ステップＳ１２にて、クライアント８００は、確立したメインサービスインスタンスを介してネットワーク７００（最終的にはＳＩＰ端末６００）とＶｏＩＰセッションを確立（通話中）する。ステップＳ１４にて、ＩＰアドレス＝Ａ、ＵＤＰポート＝ａ宛て、即ちクライアント８００に対してＲＴＰパケットが送信される。端末１００は、ステップＳ１６にて、ステップＳ１４のＲＴＰパケットを検出・解析した結果、下りＶｏＩＰセッションを検出する。

下りＶｏＩＰセッションを検出した後、端末１００は、ステップＳ１８にてＲＳＶＰＲｅｓｖメッセージをＰＤＳＮ３００に送信する。ＲＳＶＰＲｅｓｖメッセージを受け、ＰＤＳＮ３００はステップＳ２０にて、ＴＦＴ情報を取得し、取得したＴＦＴ情報を含むＲＳＶＰＲｅｓｖＣｏｎｆメッセージを端末１００に返す。

クライアント８００は、ステップＳ２４にて、ＲＴＰパケットをＩＰアドレス＝Ｂ、ＵＤＰポート＝ｂ宛てに、即ち、ＳＩＰ端末６００に対して送信する。端末１００は、ステップＳ２６にて、ステップＳ２４で送信されたＲＴＰパケットを検出・解析し他結果、上りＶｏＩＰセッションを検出する。このＶｏＩＰセッション検出を受け、クライアント８００は、ステップＳ２８にてＰＤＳＮ３００と自装置との間で、検出した上りＶｏＩＰ通信専用の補助セッションを確立する。次にステップＳ３０にて、端末１００とＰＤＳＮ３００との間でＴＦＴ処理を開始する。

クライアント８００は、ステップＳ３２にて音声パケットをＳＩＰ端末６００宛てに送信する処理を行う。この送信処理によって、クライアント８００がステップＳ３４にて、上記の音声パケットを含むＲＴＰパケットをＩＰアドレス＝Ｂ、ＵＤＰポート＝ｂ宛て、即ち、ＳＩＰ端末６００に向けて送信する。このＲＴＰパケットは、補助セッションを通過してＳＩＰ端末６００に到達する。他方、ステップＳ３６にてＳＩＰ端末６００側も音声パケットをクライアント８００宛てに送信する処理を行う。この送信処理によって、ＳＩＰ端末６００がステップＳ３８にて、上記の音声パケットを含むＲＴＰパケットをＩＰアドレス＝Ａ、ＵＤＰポート＝ａ宛て、即ち、クライアント８００に向けて送信する。このＲＴＰパケットは、補助セッションを通過してクラアント８００に到達する。

音声パケットと異なり、データパケットは、メインセッションを通過して送受信される。クライアント８００がステップＳ４０にて、データパケットをネットワーク７００（最終的な宛先はＳＩＰ端末であるが、ＵＤＰポート番号が異なる）宛てに送信する処理を行う。ステップＳ４２にて、上記のデータパケットはネットワーク７００を介してＳＩＰ端末６００に向けて送信される。このデータパケットは、メインセッション（ＰＰＰセッション）を通過して、ネットワーク７００に到達し、ネットワーク７００から最終の宛先であるＳＩＰ端末６００に送信される。ＳＩＰ端末６００から送信されたデータパケットは、ネットワーク７００からメインセッションを通過してクライアント８００に送信される（ステップＳ４４，Ｓ４６）。

図６は、本発明による端末におけるＲＴＰパケットの検出方法の一例を説明するフローチャートである。図６に示すように、ステップＰ１０にて検出回数ｎ＝０に設定（初期化）する。ステップＰ１１にてＵＤＰパケットを受信した後、ステップＰ１２に進み、受信したＵＤＰパケットのＲＴＰヘッダバージョン＝２であるか否かを判定する。ステップＰ１２にてＲＴＰヘッダバージョン＝２でないと判定した場合は、ステップＰ１３に進み、検出回数ｎ＝０にし、各保存情報もクリアして（ステップＰ１４）、再度ステップＰ１１に戻る。ステップＰ１２にてＲＴＰヘッダバージョン＝２であると判定した場合は、ステップＰ１５にてＲＴＰヘッダペイロードタイプがｉＢｕｒｓｔのＱｏＳ適応にするものか否かを判定する。ステップＰ１５にてｉＢｕｒｓｔのＱｏＳに不適応であると判定した場合は、ステップＰ１３に進む。一方、ステップＰ１５にてｉＢｕｒｓｔのＱｏＳに適応すると判定した場合は、ステップＰ１６に進み、検出回数ｎ＝０か否かを判定する。

最初に検出したときには検出回数ｎ＝０であり、ステップＰ１７に進み、ステップＰ１７−Ｐ２１の初期設定処理を行う。即ち、ステップＰ１７にてＲＴＰヘッダペイロードタイプを（メモリに）保存し、ステップＰ１８にてＲＴＰヘッダペイロードサイズを保存し、ＲＴＰヘッダシーケンス番号SeqNoを１だけ増分する（SeqNo＝SeqNo＋１）。続いてステップＰ２０にて、ＩＰヘッダの送信元、宛先のＩＰアドレスを保存し、同様にＵＤＰヘッダの送信元、宛先のポート番号を保存する（ステップＰ２１）。ステップＰ２１の後はステップＰ２２に進み、検出回数ｎ＝ｎ＋１にする。次にステップＰ２９にて、終了条件である検出回数ｎ≧所定の回数であるか否かを判定し、この終了条件を満たす場合は処理を終える。ステップＰ２９の終了条件を満たさない場合は、ステップＰ１１に戻り、一連の諸ステップを繰り返す。

ステップＰ１６にて検出回数ｎ＝０でないと判定した場合は、ＲＴＰパケットが連続しており、１つのＶｏＩＰセッションであるか否かを判定する一連のステップＰ２３−Ｐ２８の処理を行う。即ち、ステップＰ２３にて、現在のＵＤＰパケットのＲＴＰヘッダペイロードタイプと、ステップＰ１７により保存されているものとが一致するか否かを判定する。一致するときはステップＰ２４にて、現在のＵＤＰパケットのＲＴＰヘッダペイロードサイズとステップＰ１８により保存されているものとが一致するか否かを判定する。一致する場合は、次にステップＰ２５にて、現在のＵＤＰパケットのＲＴＰヘッダSeqNoと、ステップＰ１９により保存されているものとが一致するか否かを判定する。一致する場合は、次にステップＰ２６に進み、SeqNoを１つ増分する。この後、ステップＰ２７、Ｐ２８にて、現在のＵＤＰパケットの送信元／宛先のＩＰヘッダのＩＰアドレス、ＵＤＰヘッダの送信元／宛先のポート番号と、ステップＰ２０，Ｐ２１にて保存されているものとが一致するか否かを判定する。これらステップＰ２７、Ｐ２８の双方とも一致する場合は、ステップＰ２２に進む。ステップＰ２３−２５、Ｐ２７，Ｐ２８にて不一致であると判定した場合は、１つのＶｏＩＰセッションではないと見なし、ステップＰ１３に進む。ステップＰ１３にて、検出回数ｎ＝０に設定し、続いてステップＰ１４にてメモリに格納した各種の保存情報をクリアしてステップＰ１１に戻る。

図７は、本発明による端末におけるＩＳ８３５マルチセッションの適応方法の一例を説明するフローチャートである。図７に示すように、ステップＫ１０にてＶｏＩＰセッションを検出する（図６の処理に相当する）。ステップＫ１０にてＶｏＩＰセッションを検出した後、ステップＫ１１にて、パケットの流れる方向がダウンリンクか否かを判定する。ダウンリンクであると判定した場合は、ステップＫ１２にて、補助セッションを接続する。その後、ステップＫ１３にてＰＤＳＮにＲＳＶＰメッセージを送信する。

ステップＫ１１にてダウンリンクでない、即ち、方向がアップリンクであると判定した場合は、ステップＫ１４に進み、補助セッションを接続する。補助セッションを接続した後、ステップＫ１５にて、検出したＩＰアドレス、ＵＤＰポートをＴＦＴテーブルに設定する。そして、ステップＫ１６にて、アップリンク方向のＴＦＴ処理を開始する、即ち、補助セッションへのパケットフィルタリング処理を開始する。その後、ステップＫ１７にて、ＶｏＩＰセッションの帯域情報などを含むＱｏＳ情報から適応モッドクラス（変調クラス）に固定する。次に、ステップＫ１８にて、ＲＴＰコーディックタイプがオーディオであるか否かを判定し、オーディオ（音声）である場合は、ステップＫ１９に進み、無線ＱｏＳの制御として、パーシスタンスチャネルを適応し、処理を終える。ステップＫ１８にてオーディオでない、即ち、メディア（映像など）と判定された場合も処理を終える。

本発明の利点をまとめると、下記のようになる。移動ノードがモバイルＩＰクライアントとなり、異なるネットワーク網と接続している場合でも、（ハンドオーバー時などに）適正にＩＳ８３５マルチセッションを適用できる。また、呼制御プロトコルの違いを意識せずに、ＩＳ８３５を適用できる。また、ＲＴＰパケットを直接監視することにより、呼制御ネゴシエーション／プロトコルに依存しないでＩＳ８３５マルチセッションを実行することが可能である。検出したＶｏＩＰセッション別に、適正な無線ＱｏＳ制御（Modクラスの選定）をすることで、用途（アプリケーション）に応じたＱｏＳ制御を行うことが出来るようになる。ＷｉＦｉ等の異なる網との併用時も、ＩＳ８３５マルチセッション制御が可能である。ＲＴＰパケットを直接監視するため、既に通話中のＶｏＩＰセッションが異なる網（典型的にはＷｉＦｉ）からiBurstにハンドオーバーした場合においても、ＩＳ８３５制御を実行することが出来る。また、アプリケーションに応じたＱｏＳ制御も可能となる。

さらに、ＲＴＰパケットから、コーディック種別及び１パケットに送信するパケット数（送信間隔）を抽出し、通信に必要な帯域を割り出すことが出来る。本発明では、iBurstの無線特性であるリンクアダプテーション（変調方式とコーディングレートの組み合わせにより異なる帯域の変調クラスを無線状況に応じて選択する機能）を使用して、通信に必要なモッドクラス（変調クラス若しくはモジュレーションクラスのこと）の指定、及びＶｏＩＰＱｏＳ制御のオン／オフ等を適用することで、安定した音声品質を確保できる。さらに、例えばビデオストリームはマルチセッションを行いたくない等、ＲＴＰストリームでもＩＳ８３５5を適用するアプリケーションやコーディック・メディアタイプを指定することが出来る。

本発明を諸図面や実施例に基づき説明してきたが、当業者であれば本開示に基づき種々の変形や修正を行うことが容易であることに注意されたい。従って、これらの変形や修正は本発明の範囲に含まれることに留意されたい。例えば、各部材、各手段、各ステップなどに含まれる機能などは論理的に矛盾しないように再配置可能であり、複数の手段やステップなどを１つに組み合わせたり、或いは分割したりすることが可能である。

本発明の実施態様による無線通信システムのネットワーク構成図である。 図１に示した端末の詳細なブロック図である。 図１に示した基地局の詳細なブロック図である。 図１に示したＰＤＳＮの詳細なブロック図である。 本発明による無線通信システムによる処理の一例を説明するシーケンス図である。 本発明による端末におけるＲＴＰパケットの検出方法の一例を説明するフローチャートである。 本発明による端末におけるＩＳ８３５マルチセッションの適応方法の一例を説明するフローチャートである。 提案技術ＩＳ８３５によるＴＦＴフィルタテーブル取得の処理を説明するシーケンス図である。 提案技術ＩＳ８３５によるマルチセッションが確立できないケースを説明するネットワーク構成図である。

符号の説明

１００ 端末
１１０ 無線通信部
１１２ 第１の無線通信部
１１４ 第２の無線通信部
１２０ パケット検出部
１２２，１２４ ＲＴＰパケットフィルタ
１３０ パケット解析部
１３２ 上りＶｏＩＰセッション検出部
１３４ 下りＶｏＩＰセッション検出部
１４０ 補助セッション割当要求部
１４５ 無線通信部切替スイッチ（部）
１５０ 送信バッファ
１５２ 受信バッファ
１５４ パケット構築部
１５６ パケットフィルタ
１５８ ＰＰＰ判定部
１６０ ＱｏＳ情報ＢＳ通知部
１６２ 無線ＱｏＳ制御部
１６４ 変調クラス制御部
１７０ マルチセッション制御部
１７２ ＶｏＩＰセッション制御部
１７４ 無線ＱｏＳ判定スイッチ
１７６ ＰＰＰパケット抽出処理部
１７８ ＰＰＰパケット構築部
１８０ ＰＰＰｏＥパケット構築部
１８２ ＰＣ＿Ｉ／Ｆ部
２００ 基地局
２１０ 補助セッション用チャネル割当部
２２２ ＵＴ側の受信バッファ
２２４ ＵＴ側の送信バッファ
２３０ 制御部
２３２ 無線セッション制御部
２３４ 変調クラス制御部
２３６ パケット解析部
２４０ マルチセッション制御部
２５０ パケット構築部
２５２ パケット解析部
２５４ セッション制御情報構築部
２５６ セッション制御情報取得部
２６０ ＰＤＳＮ通信部
２６２ ＰＤＳＮ側の送信バッファ
２６４ ＰＤＳＮ側の受信バッファ
３１０ 補助セッション割当部
３２０ ＢＳ通信部
３２２ ＢＳ側の受信バッファ
３２４ ＢＳ側の送信バッファ
３３０ パケット構築部
３３２ パケット検出部
３３４ セッション制御情報取得部
３３６ セッション制御情報構築部
３４０ マルチセッション制御部
３４０ パケット構築部
３４０ マルチセッション制御部
３４２ パケット構築部
３４６ パケット解析部
３４８ 通信部
３５０ パケットフィルタ
３５０ パケットフィルタ部
３６０ コアネット通信部
３６２ コアネットワーク側の受信バッファ
３６４ コアネットワーク側の送信バッファ
４００ ホームエージェント（ＨＡ）
６００ ＳＩＰ端末
７００ ネットワーク
８００ クラアント（ＰＣ）
ＣＮＥＴ コアネットワーク
ＮＥＴ ネットワーク
ＰＤＳＮ ３００
ＷＦＡＰ アクセスポイント
ＷＮＥＴ ＷｉＦｉネットワーク

Claims (8)

1. 端末が第１の無線ネットワークと第２の無線ネットワークを介してパケット通信を行う無線通信システムであって、
   前記端末は、
   前記第１の無線ネットワークと通信する第１の無線通信手段と、
   前記端末と無線で接続する基地局、および、該基地局を介して前記端末と通信を行うＰＤＳＮからなる前記第２の無線ネットワークと通信を行う第２の無線通信手段と、
   前記第１の無線通信手段と前記第２の無線通信手段とを切り替える切替手段と、
   前記切替手段により、前記第１の無線通信手段から前記第２の無線通信手段への切り替えが行われると、前記端末が前記第２の無線通信手段により、前記第２の無線ネットワークとメインセッションを介して送受信するＲＴＰパケットを検出するＲＴＰパケット検出手段と、
   前記ＲＴＰパケット検出手段により検出されたＲＴＰパケットを解析し、該ＲＴＰパケットがＶｏＩＰ通信用のパケットであるか否かを判定するＲＴＰパケット解析手段と、
   ＶｏＩＰ通信用のパケットであると判定されたＲＴＰパケットに対して、前記第２の無線ネットワークにおいてＶｏＩＰ専用の補助セッションを割り当てるように要求する補助セッション割当要求を、前記基地局を介して前記ＰＤＳＮに送信する補助セッション割当要求手段とを備え、
   前記ＰＤＳＮは、
   前記端末からの前記補助セッション割当要求を受信し、前記端末における前記ＶｏＩＰ通信用のパケットであると判定されたパケットに対して、前記第２の無線ネットワークにおいてＶｏＩＰ専用の補助セッションを割り当てる補助セッション割当手段とを備える、
   ことを特徴とする無線通信システム。
2. 請求項１に記載の無線通信システムにおいて、
   前記端末は、
   ＱｏＳ制御手段をさらに備え、
   前記端末のＲＴＰパケット解析手段は、
   ＶｏＩＰ通信用のパケットであると判定されたＲＴＰパケットのデータに含まれるコーディックタイプおよび当該ＲＴＰパケットの送信間隔を含むＲＴＰ解析結果をＱｏＳ情報として生成し、
   前記ＱｏＳ制御手段は、
   前記生成したＱｏＳ情報に基づき、前記ＶｏＩＰ専用の補助セッションに対してＱｏＳ制御を行う、
   ことを特徴とする無線通信システム。
3. 請求項２に記載の無線通信システムにおいて、
   前記端末は、
   変調方式とデータレートとの組み合わせと、無線帯域とを対応付けたテーブルを格納する格納手段と、
   前記テーブルを参照して、前記ＱｏＳ情報に基づき算出される当該ＶｏＩＰ通信におけるＲＴＰトラフィックの帯域に基づき、当該ＶｏＩＰ通信の変調方式およびデータレートを固定する変調方式・データレート設定手段とをさらに備える、
   ことを特徴とする無線通信システム。
4. 請求項２または３に記載の無線通信システムにおいて、
   前記ＱｏＳ制御手段は、
   前記ＱｏＳ情報に基づき、前記ＶｏＩＰ専用の補助セッションにより使用されるチャネルを他のチャネルよりも保持性が高いチャネルに設定するように要求するチャネル設定要求を前記基地局に送信する、
   ことを特徴とする無線通信システム。
5. 第１の無線ネットワークと通信を行う第１の無線通信手段と、
   基地局、および、該基地局を介して通信を行うＰＤＳＮからなる第２の無線ネットワークと通信を行う第２の無線通信手段と、
   前記第１の無線通信手段と前記第２の無線通信手段とを切り替える切替手段と、
   前記切替手段により、前記第１の無線通信手段から前記第２の無線通信手段への切り替えが行われると、前記第２の無線通信手段により、前記第２の無線ネットワークとメインセッションを介して送受信するＲＴＰパケットを検出するＲＴＰパケット検出手段と、
   前記ＲＴＰパケット検出手段により検出されたＲＴＰパケットを解析し、該ＲＴＰパケットがＶｏＩＰ通信用のパケットであるか否かを判定するＲＴＰパケット解析手段と、
   ＶｏＩＰ通信用のパケットであると判定されたＲＴＰパケットに対して、前記第２の無線ネットワークにおいてＶｏＩＰ専用の補助セッションを割り当てるように要求する補助セッション割当要求を、前記ＰＤＳＮに送信する補助セッション割当要求手段と、
   を備えることを特徴とする端末。
6. 請求項５に記載の端末において、
   変調方式とデータレートとの組み合わせと、無線帯域とを対応付けたテーブルを格納する格納手段と、
   ＶｏＩＰ通信の変調方式およびデータレートを固定する変調方式・データレート設定手段とをさらに備え、
   前記ＲＴＰパケット解析手段は、
   ＶｏＩＰ通信用のパケットであると判定されたＲＴＰパケットに含まれるデータのコーディックタイプおよび当該ＲＴＰパケットの送信間隔を含むＲＴＰ解析結果をＱｏＳ情報として生成し、
   前記変調方式・データレート設定手段は、
   前記テーブルを参照して、前記生成したＱｏＳ情報に基づき算出される当該ＶｏＩＰ通信におけるＲＴＰトラフィックの帯域に基づき、当該ＶｏＩＰ通信の変調方式およびデータレートを固定する、
   ことを特徴とする端末。
7. 請求項５または６に記載の端末において、
   前記割り当てられたＶｏＩＰ専用の補助セッションを前記ＲＴＰパケット検出手段により監視し、所定期間に亘りパケットの送受信が検出されないとき、前記割り当てられたＶｏＩＰ専用の補助セッションを切断する補助セッション切断手段をさらに備える、
   ことを特徴とする端末。
8. 端末が第１の無線ネットワークと第２の無線ネットワークを介してパケット通信を行う無線通信方法であって、
   前記第１の無線ネットワークと通信する第１の無線通信ステップと、
   前記端末と無線で接続する基地局、および、該基地局を介して前記端末と通信を行うＰＤＳＮからなる前記第２の無線ネットワークと通信を行う第２の無線通信ステップと、
   前記第１の無縁ネットワークから前記第２の無線ネットワークにハンドオーバーするハンドオーバーステップと、
   前記ハンドオーバー後に、前記端末がメインセッションを介して前記第２の無線ネットワークと送受信するＲＴＰパケットを検出するＲＴＰパケット検出ステップと、
   前記検出されたＲＴＰパケットを解析し、該ＲＴＰパケットがＶｏＩＰ通信用のパケットであるか否かを判定するＲＴＰパケット解析ステップと、
   ＶｏＩＰ通信用のパケットであると判定されたＲＴＰパケットに対して、前記第２の無線ネットワークにおいてＶｏＩＰ専用の補助セッションを割り当てる補助セッション割当ステップと、
   を有することを特徴とする無線通信方法。

Images