モバイルサブスクライバステーションのためのVOIP呼をサポートする装置および方法
幾らかの実施形態では、ベースステーションは、許可制御モジュールと、許可制御モジュールと通信するデータパス機能モジュールとを含む。データパス機能モジュールは、アクティブ状態の第1のアップリンクサービスフローの第1の動的サービス追加(DSA)要求メッセージを生成して、VoIP(voice over internet protocol)シグナリングを提供する。許可制御モジュールは、許可制御モジュールがVoIP呼用に第2のアップリンクサービスフローをサポートできると判断すると、許可信号を生成するが、第1および第2のアップリンクサービスフローは、実質的にIEEE(米国電気電子学会)802.16規格に準拠している。データパス機能モジュールは、許可信号に呼応して、さらに、第2のアップリンクサービスフローの第2のDSA要求メッセージを生成して、第2のDSAメッセージは、VoIP呼に確保された帯域幅を含む
【発明の詳細な説明】
【技術分野】
【0001】
本発明の実施形態は、電子デバイス分野に係り、特に通信デバイスに係る。
【背景技術】
【0002】
ブロードバンドワイヤレスアクセス(BWA)システムは、ポイントツーマルチポイント通信システムを通信ネットワークに提供する。BWAシステムは通常マイクロ波およびミリメートル波技術を利用して、通信信号をワイヤレスベースステーション(BS)から1以上のサブスクライバステーション(SS)および/またはモバイルサブスクライバステーション(MS)に送信する。BWAシステムは、音声、ビデオ、およびデータサービスを提供するよう設計された集中(converged)ワイヤレスネットワークであってよい。規格の中の802.16ファミリーは、IEEE(米国電気電子学会)が、固定、ポータブル、および/または、モバイルBWAネットワークの提供を目的として開発した(IEEE規格802.16、2004年発行版、および後続の版)。WiMAX(Worldwide Interoperability for Microwave Access)フォーラムにより、IEEE802.16規格に基づくブロードバンドワイヤレスネットワークの配置が促進される。特に、WiMAXフォーラムにより、ブロードバンドワイヤレス機器の互換性および相互利用性が保証される。便宜上、本開示では「802.16」および「WiMAX」という用語を入れ替え可能な形で利用して、エアインタフェース規格のIEEE802.16一式のことを表す場合がある。
【0003】
ダウンリンク送信においては、WiMAXネットワークは、BSから、SSまたはMSへ、データパケットをブロードキャストしうるが、アップリンク送信においては、スケジューリングサービスを設計して、異なるトラフィックの特性およびサービス品質(QoS)要件を有するサービスをサポートすることができる。WiMAXネットワーク等の集中ワイヤレスネットワークの顕著な利点は、異なるサービス間のワイヤレススペクトルという殆どの貴重なリソースを共有できることである。しかし、WiMAXネットワークにおけるワイヤレスネットワークの集中には、多数のSS間でのアップリンク送信の調停、および、異なるサービス間で必要なQoSを有するアップリンク帯域幅の割り当てといった課題も存在する。
【図面の簡単な説明】
【0004】
【図1】本発明の様々な実施形態によるBWAシステムのブロック図である。
【図2】本発明の様々な実施形態による図1のBWAシステムのベースステーションを組み込むアクセスサービスネットワーク(ASN)のブロック図である。
【図3】本発明の様々な実施形態によるMSのアクティブな第1のサービスフローおよび許可された第2のサービスフローを提供する信号図である。
【図4】本発明の様々な実施形態による図1のベースステーションを組み込むASNのブロック図であり、ASNモードのトリガが示されている。
【図5】本発明の様々な実施形態による図1のベースステーションを組み込むASNのブロック図であり、MSモードトリガが示されている。
【図6】本発明の様々な実施形態によるWIMAX接続制御(WCC)モジュールの状態遷移図である。
【図7】本発明の様々な実施形態による、ASNトリガモードを利用するMSに対して確保された帯域幅を第2のサービスフローに提供する信号図である。
【図8】本発明の一実施形態による、ASNトリガモードを利用する呼のセットアップ処理の信号図である。
【図9】本発明の一実施形態による、ASNトリガモードを利用する呼のティアダウン処理の信号図である。
【図10】本発明の様々な実施形態による、MSトリガモードを利用するMSに対して確保された帯域幅を第2のサービスフローを提供する信号図である。
【図11】本発明の一実施形態による、MSトリガモードを利用する呼のセットアップ処理の信号図である。
【図12】本発明の一実施形態による、MSトリガモードを利用する呼のティアダウン処理の信号図である。
【図13】本発明の様々な実施形態を組み込むモバイルステーションシステムのブロック図である。
【発明を実施するための形態】
【0005】
以下の記載においては、説明を行う目的から多数の特定の詳細を述べて、本発明について開示する実施形態の完全な理解を可能とすることに努める。しかし、本発明の実施形態がこれら特定の詳細なく実施可能であることは当業者には明らかである。他の場合には、公知の電気的な構造および回路はブロック図の形式で示して、本発明について開示する実施形態を曖昧にしないよう努める。「連結」という用語は、直接的な接続、間接的な接続、または間接的な通信をも含有する。
【0006】
図1は、本発明の様々な実施形態による、例示的なブロードバンドワイヤレスアクセス(BWA)システム10を示す。BWAシステム10はワイヤレスセルを利用して地理的領域をカバーしてよい。BWAシステム10は、遠隔サイト位置の複数のモバイルサブスクライバステーション(モバイルSS)またはモバイルステーション(MS)14(図1にはMS14は1つだけ示されている)に対して送信する中央サイト位置のベースステーション(BS)12を含んでよい。MS14の例には、ラップトップまたはウルトラモバイルデバイス(UMD)(例えばハンドヘルドデバイス)が含まれうる。BWAシステム10の部材は、IEEE802.16規格の通信プロトコルに応じて互いに通信しあってよい。概して、この802.16規格は、ワイヤレスメトロポリタンエリアネットワーク(MAN)(WiMAXネットワークとも称されうる)の固定および/またはモバイルSS(例えばMS14)へのワイヤレスブロードバンドアクセスを定義してよい。BS12と複数のMS14とは、BS12のワイヤレスセルのワイヤレス媒体(エアインタフェース)16を介して通信する。BS12は、セル内のMS14への、またはMS14からのトラフィックを収集してよい。BS12はインターネット等の有線または無線のバックボーンネットワーク(不図示)へのインタフェースを有する機器を含むことができ、これにより任意のMS14とバックボーンネットワークとの間のリンクを提供する。
【0007】
MS14は、VoIP(voice over Internet Protocol)呼を生成および受信しうる。一実施形態では、BWAシステム10は、VoIP呼セッションについてセッション開始プロトコル(SIP)を利用する。SIPは、1以上のMS14のセッションを作成、修正、および終了させるアプリケーション層制御(シグナリング)プロトコルである(IETF(Internet Engineering Task Force)SIPワーキンググループによるRFC(Request For Comments)3261仕様を参照のこと)。しかし、SIP以外のプロトコルをVoIP呼セッションで利用することもできる。BWAシステムは、MS14が発信する、またはMS14で受信されたVoIPトラフィックを、音声サービス用に用意された特別なサービス品質(QoS)を有するコネクションを介して伝送する。IEEE802.16規格の関連部分の記載および様々な定義を提示して、本発明による様々な実施形態の理解を助ける。
【0008】
IEEE802.16は、「サービスフロー」を、パケット(SSが送信するアップリンクパケットまたはBSが送信するダウンリンクパケット)の一方向トランスポートを提供するメディアアクセスコントロール(MAC)トランスポートサービスとして定義している。サービスフローは、待ち時間、ジッタ、およびスループット保証等のQoSパラメータ一式により特徴付けられる。BSは、サービスフローについて定義されたQoSパラメータセットにおいて任意のQoSを提供する。概してIEEE802.16規格が記載するサービスフローは、(a)準備(Provisioned)‐このサービスフローの状態は、例えばネットワーク管理システムによる準備により既知である、(b)許可(Admitted)‐このサービスフローの状態は、SS用にBSがリソースを確保している、(c)アクティブ(Active)‐このサービスフローの状態は、SS用にBSがリソースを割り当てている、という3つの状態を有することができ、各サービスフローは3つの状態のいずれかへの遷移が可能である。IEEE802.16は、各サービスフロー符号内に、QoSパラメータセット(準備セット、許可セット、および/またはアクティブセット)の正規のアプリケーションを特定するパラメータQoSパラメータセットタイプ(「セットタイプパラメータ」)を含む。802.16規格は、帯域幅等のリソースがまず「許可され」、その後に、ひとたびエンドツーエンドネゴシエーションが完了すると、そのリソースを「起動」する、という、二段階起動モデルを提案している。IEEE802.16はさらに、VoIP呼接続がセットアップされるまたはティアダウンされる際に動的にサービスフローをそれぞれ作成、変更および削除するDSA(Dynamic Service Deletion)メッセージ、DSC(Dynamic service Change)メッセージ、およびDSD(Dynamic Service Deletion)メッセージを定義している。
【0009】
IEEE802.16(WiMAX)はさらに、区別化QoS要件への帯域幅要求/承認処理を用いてアップリンクスケジューリングサービスを定義している。以下は、様々なサービス用のIEEE802.16のサービスクラスである:(a)UGS(要請されていない(Unsolicited)承認サービス):T1/E1エミュレーションおよびサイレンス抑制のないVoIP等のサポートコンスタントビットレート(CBR)またはCBRに類似したサービスフローのサポート、(b)リアルタイムポーリングサービス(rtPS):サイレンス抑制のないVoIPサービス等の、周期的に可変サイズのデータパケットを生成するリアルタイムサービスフロー(SF)のサポート、(c)拡張リアルタイムポーリングサービス(ertPS):サイレンス抑制のないVoIP等の、周期的に可変サイズのデータパケットを生成するリアルタイムサービスフローのサポート、(d)非リアルタイムポーリングサービス(nrtPS):ファイル転送プロトコル(FTP)およびハイパーテキスト転送プロトコル(HTTP)等の、定期的に可変サイズのデータ承認バーストタイプを必要とする非リアルタイムSFのサポート、および(e)ベストエフォートサービス(BE):通常のウェブサーフィングおよび電子メールサービスのサポート。各サービスクラスは、一纏まりのMS14またはBS12が利用するサービスフロー特性または属性(QoSパラメータを含む)を含み、所望のQoSのサービスフローを要求する。
【0010】
アクセスサービスネットワーク(ASN)は、WiMAXサブスクライバ(例えばMS14)への無線アクセス(radio access)を行うのに必要な一式のネットワーク機能として定義される。ASNは以下の機能を提供する:(a)WiMAX MS(MS14等)とのWiMAX層−2(L2)コネクティビティ、(b)AAA(認証、許可、および会計上の)メッセージの、WiMAXサブスクライバのホームネットワークサービスプロバイダ(H−NSP)への、サブスクライバセッションの認証、許可、およびセッション会計を目的とした転送、(c)WiMAXサブスクライバの好適なNSPのネットワークでの発見および選択、(d)WiMAX MSとの層3(L3)の構築に関するリレー機能(つまりIPアドレス割り当て)、および無線リソース管理。上述の機能に加えて、ポータブルおよびモバイルな環境ではASNは以下の機能をサポートしうる:(a)ASNアンカーモビリティ、(b)コネクティビティサービスネットワーク(CSN)アンカーモビリティ、(c)ページング、および(d)ASN−CSNトンネリング(ASN-CSN tunneling)。ASNは、1以上のBS12、および1以上のASNゲートウェイ等のネットワーク部材を含みうる。1つのASNを、1を超える数のCSNが共有してもよい。
【0011】
CSN(Connectivity Service Network)は、インターネットプロトコル(IP)コネクティビティサービスをWiMAXサブスクライバに提供する一式のネットワーク機能として定義される。CSNは以下の機能を提供しうる:(a)ユーザセッションへのMS IPアドレスおよびエンドポイントパラメータ割り当て、(b)インターネットアクセス、(c)AAAプロキシまたはサーバ、(d)ユーザ加入プロフィールに基づくポリシーおよび許可制御(Policy and Admission Control)、(e)ASN−CSNトンネリングサポート、(f)WiMAXサブスクライバへの課金およびオペレータ間の調停(settling)、ローミングに際してのインターCSNトンネリング(inter-CSN tunneling for roaming)、および(h)インターASNモビリティおよびロケーションベースのサービス等のWiMAXサービス、ピアツーピアサービスへのコネクティビティ、法的な傍受サービスをサポートする目的の、IPマルチメディアサービスおよびファシリティへの準備、認証、および/または、コネクティビティ。CSNは、ルータ、AAAプロキシ/サーバ、ユーザデータベース、および相互作用ゲートウェイMS等のネットワーク部材を含みうる。
【0012】
AAA(認証、許可、および会計上の)サービスは、ユーザ認証、ユーザ許可、およびユーザ会計機能を行う。幾らかの実施形態では、遠隔認証ダイアルインユーザサービス(RADIUS)プロトコルを通信プロトコルとして利用して、AAA情報を伝送することができる。RADIUSは、自身のリンクおよび共有AAAまたはAAAプロキシサービスの認証を希望するデバイス間の認証、許可、会計および構成情報を伝送するインターネット標準トラックプロトコル(Internet standard track protocol)である。IEEE802.16eは、供給者と認証者との間の鍵交換において拡張可能認証プロトコル(EAP)を利用しており、多数の鍵を利用しうる。開始点は、認証サーバから来る一対のマスターキー(PMK)であってよい。
【0013】
図1に戻ると、本発明の様々な実施形態によるBWAシステム10のBS12およびMS14のうち1つを表すブロック概略図が示されている。MS14は1つしか示されていないが、BS12は複数のMS14(複数のモバイルSS14)を収容することができる。BS12およびMS14は、構想としてはアップリンク部分20とダウンリンク部分22とに、仮想線24で分割されている。BS12およびMS14の機能ユニットは、メディアアクセスコントロール(MAC)層と物理(PHY)層とを含むオープンシステムインターコネクト(OSI)モデルの層に準拠していてよく、これら層がアップリンク部分20およびダウンリンク部分22に分割されている。故に、MS14は、アップリンクMAC/PHY層部分28、ダウンリンクMAC層部分30、およびダウンリンクPHY層部分32に連結されているパケット分類器26として描くことができる。同様に、BS12は、ダウンリンクMAC/PHY層部分36に連結されるパケット分類器34を有するとして描くことができる。BS12はさらに、アップリンクPHY層部分38およびアップリンクMAC層部分40を含んでよい。後述するように、パケット分類器26および34は、分類規則に基づいて、パケットを適切な仮想接続へルーティングする。
【0014】
図1は、VoIPおよびデータ(例えばインターネットデータ)が、BWAシステム10の集中WiMAXネットワークでトランスポートされうる様子を示す。サービスフローは、エアインタフェース16を介した仮想接続である。より詳しくは、構想上の送信パイプ42が、MS14のアップリンクMAC/PHY層28と、BS12のアップリンクPHY層部分38との間に示されており、このパイプはVoIPシグナリング用の第1のアップリンクサービスフロー44と、VoIP呼(呼のVoIPパケット)用の第2のアップリンクサービスフロー46を有するとして示されているが、この詳細については後述する。同様に、構想上の送信パイプ48は、BS12のダウンリンクMAC/PHY層36と、MS14のダウンリンクPHY層部分22との間に示されており、このパイプはVoIPシグナリング用の第1のダウンリンクサービスフロー50と、VoIP呼(呼のVoIPパケットを伝送するVoIP接続)用の第2のダウンリンクサービスフロー52を有するとして示されている。MS14のパケット分類器26は、アップリンクVoIPパケット54を、BS12に向けたアップリンクの第2のサービスフロー46へと分類およびルーティングしてよく、BS12のパケット分類器34は、MS14に向けた第2のダウンリンクサービスフロー52へとダウンリンクVoIPパケット56を分類およびルーティングしてよい。同様に、アップリンクデータ58はパケット分類器26により分類されて、第1のアップリンクサービスフロー44へルーティングされてよく、ダウンリンクデータ60は第1のダウンリンクサービスフロー50へルーティングされてよい。パケット分類器26および34は、宛先IP/ポートアドレス、QoS属性(Tos(サービスのタイプ))、DSCP(区別化されたサービスコードポイント)等の規則を利用して、パケットを分類する。1つのサービスフローには多数の分類規則があってよい。後述するように、第1のサービスフロー44および50は、本発明の様々な実施形態では、VoIPシグナリングを含んでもよい。
【0015】
BWAシステム10は、本発明の様々な実施形態によると、VoIPサービスをサポートする制御プランのプロトコルおよび手順を含む。より詳しくは以下の通りである:準備および会計を含むVoIPサービス配置シナリオ、VoIP呼が開始される際に、区別化されたQoSをサービスフローに提供する方法、および、VoIP呼が終了する際のサービスフローの解除。VoIPサービスに関しては、1つのセルについて最大数のVoIP呼を良好な音声品質で提供することが望ましい。故に、VoIP呼の際の帯域幅割り当て/割り当て解除スキームは、帯域幅効率性および音声品質目的における重要な特徴でありうる。最も簡単な方法は、この目的にDSA/DSDメッセージを利用することであろう。しかし、呼毎にDSA/DSDを利用することには、以下の大きな問題がある:BSが任意の時点でVoIP呼を開始するのに幾つのMSがDSAメッセージを送信する必要があるのかを知る手立てがない、というのも、MSはBSからBSへローミングしているからである。故に、BSは音声およびデータサービスについて帯域幅割り当てを最適に計画することができない場合もある。この結果、帯域幅が不十分なために多くの呼が拒絶されることからVoIPサービスの保証ができなくなる虞がある。各DSA要求はホームAAAサーバに認証を目的として転送される必要があるので、呼のセットアップ中に重要な遅延が生じる可能性がある。遅延は、MSが外国のネットワーク(foreign networks)にローミングする際に、より長くなる可能性がある。これにより、呼毎にDSA/DSDメッセージを処理する方法では、BSスケジューリングが複雑なものになる虞がある。
【0016】
本発明の様々な実施形態によるBWAシステム10は、BS12が始める2つのサービスフロー手順を用いてWiMAXを介してVoIPを配置する。アップリンクフローに関しては、2つのサービスフローは、第1のアップリンクサービスフロー44および第2のアップリンクサービスフロー46を含み、ダウンリンクフローに関しては、2つのサービスフローは、第1のダウンリンクサービスフロー50および第2のダウンリンクサービスフロー52を含む。本発明の様々な実施形態によると、BWAシステム10の第2のアップリンクサービスフロー46および第2のダウンリンクサービスフロー52を、UGS、rtPSまたはertPSから選択する。幾らかの実施形態では、第1のアップリンクサービスフロー44および第1のダウンリンクサービスフロー50を、nrtPSまたはBEから選択してよい。第1のサービスフロー44および50のVoIPシグナリングには、呼制御メッセージ(例えば図8、9、11、および12に関して後述するSIP信号)を含んでよい。図2に関して詳述するように、BS12は、DSA−要求(DSA−REQ)メッセージを送信して、各第1のサービスフローがアクティブ状態(Active State)であるようなVoIPシグナリング用の第1のサービスフロー44および50を作成する。その後、BSがVoIP呼接続について第2のサービスフロー46および52をサポートすることができる場合、BS12は第2のサービスフローを作成するべくDSA−REQを送信する。後述するように、第2のサービスフロー46および52は、セットアップされると、各々許可状態(Admitted State)になり、これは、VoIPサービスの帯域幅が確保されているが、まだVoIP呼に対して承認されてはいないことを意味する。
【0017】
本発明の様々な実施形態によるBWAシステム10は、第1段階が帯域幅確保であり第2段階が帯域幅起動であるという、二段階呼制御手順を利用している。第1段階の前に、サービスフローをインスタンス化してよく、その準備されたQoSParamSetを、後の第1段階において確保される準備帯域幅を含むように設定してよく、これについては後述する。一つの可能性として、準備帯域幅の量は、ネットワーク管理システム(不図示)が設定してよい。別の可能性としては、準備帯域幅は、接続セットアップの前に、またはその間に、BS12とMS14との間でネゴシエーションされてもよい。インスタンス化された第2のサービスフローの提供は、準備状態(Provisioned State)を有することで特徴付けられ、このインスタンス化段階は、VoIPサービスに加入するMS14の第2のサービスフローの「事前準備(pre-provisioning)」とも称される場合がある。この名称によって、後に行われる帯域幅の確保は、「準備」の一部として称される場合もある。
【0018】
帯域幅確保を行う第1段階では、MS14がBS12のセルに入ると、BS12はVoIPサービスの第2のサービスフロー46および52用に帯域幅を確保する。これらサービスフローは、図6を参照しながら後述するように、許可状態に変化する(QoSパラメータ状態が「許可された(Admitted)」になる)。帯域幅起動を行う第2段階で、VoIP呼が開始されると、QoSパラメータ状態がアクティブ(Active)に設定され、帯域幅(確保された帯域幅割り当て)が、最大維持トラフィックレートパラメータが特定するように、VoIP呼に対して承認される。帯域幅の起動停止(deactivation)の際には、VoIP呼を終了すると、QoSパラメータ状態が、許可状態(Admitted State)に変化する。加えて、VoIPサービスのUDR(利用データ記録)を生成するが、これには、(a)確保されている第2サービスフローの期間および(b)呼期間中にトランスポートされたバイト数が含まれる。
【0019】
図2を参照すると、本発明の様々な実施形態によるBS12における図1のBWAシステム10のBS12はASN70の一部として示されており、MAC層のソフトウェア機能の幾つかが示されている。ASN70はさらに、BS12に連結されたASNゲートウェイ(ASN GW)72を含む。BS12は、サービスフロー管理(SFM)モジュール74を含むとして示されている。幾らかの実施形態では、SFMモジュール74は、許可(admission)制御モジュール76、データパス機能モジュール78、および許可制御モジュール76およびデータパス機能78に連結されたサービスフロー情報(SF info)データベース80を含んでもよい。しかし、全てがBS12のMAC層に存在するこれらモジュールの機能は、異なる分類がなされて異なる名称で称されてもよい。一例としては、SFMモジュール74は図1のBS12のMAC/PHY36の一部であってもよい。幾らかの実施形態では、ASNゲートウェイ72は、認証器82を含んでよい。ASNゲートウェイ72は、AAAサーバ84に連結されてもよいし、AAAサーバに連結されうるAAAプロキシサーバに連結されてもよい。AAAサーバ84はホームCSNであってもよいことは前述の通りである。
【0020】
幾らかの実施形態では、前述のサービスフローQoSパラメータに対する全ての変更は、SFMモジュール74の許可を受けることにしてもよい。これには、新たなサービスフローを作成する全てのDSA−REQメッセージ、および、既存のサービスフローのQoSパラメータセットを変更する全てのDSC−REQメッセージが含まれる。これら変更には、許可制御モジュール76による許可制御決定(例えばAdmittedQosParamSetの設定)、および、データパス機能モジュール78によるサービスフローの起動(例えば、ActiveQosParamSetの設定)が含まれてよい。リソースに関する低減要求も、許可制御モジュール76による許可を受けることにしてもよい。
【0021】
データパス機能モジュール78は、許可制御モジュール76に対して要求を行ってよい。データパス機能モジュール78は、さらに、DSA,DSC,およびDSDメッセージをWiMax接続制御モジュール(後述)に送受信してよい。データパス機能モジュール78はさらに、「BSスケジューラ」と称されるものを含んでよく、これは主に、前述した第1および第2のサービスフローを含むサービスフローに対する帯域幅承認をスケジュールするのに利用されてよい。概して、複数の要因(factor)に基づいて、BSスケジューラは、特定の帯域幅の送信データを選択してよい。スケジュールサービスおよび関連するQoSパラメータを特定することにより、BSスケジューラはアップリンクトラフィックのスループットおよび待ち時間の必要性を予期して、ポールを提供する、および/または、適時に承認することができる。図3に関して記載するように、幾らかの実施形態では、各MS14は、BS12が構築した(VoIPパケットの接続である)VoIPシグナリング用の自身の第1のアップリンクサービスフロー44、およびVoIPシグナリング用の自身の第2のアップリンクサービスフロー46を有する。
【0022】
図1および2を適宜参照しながら図3を参照すると、本発明の幾らかの実施形態によるVoIPサービスフロー準備および確保手順90が示されている。VoIP呼における第2のサービスフローの確保手順は、MS14がネットワークに入ることで(例えば図1におけるBWAシステム10のBS12のセルに入ることで)開始されてよい。処理92でMS14は、ダウンリンク(DL)取得、同期、範囲変更(ranging)を行い、サブスクライバ基本機能(SBC)をBS12との間で交換してよい。処理94で、ASN GW72の認証器82は、秘密鍵管理バージョン2(PMKv2)EAP−転送メッセージに含まれているEAP−ID要求をMS14へ送信してよい。処理96では、MS14は、PMKv2EAP−転送メッセージに含まれているEAP−ID応答を認証器82に返してよい。処理98では、MSのEAPのIDは、認証器82がホームAAAサーバ84に送信するRADIUSアクセス要求(Req)メッセージに含まれていてよい。処理100では、EAP認証プロセスは、MS14とAAAサーバ84との間で行われてよい。処理102で、EAP認証プロセスが完了してよい。処理104で、AAAサーバ84は、以下の表1に示すパラメータを含むRADIUSアクセス応答(Rsp)メッセージを送信してよい。
【表1】
【0023】
処理104で、認証器82は、PMKv2EAP−転送メッセージに含まれているEAP−SuccessをMS14へ送信する。処理106で、認証器82は、MSK(マスターセッションキー)からPMK(対のマスターキー)を生成して、IEEE802.16e推奨版に特定されているアルゴリズムに基づいてPMKからAKを(認証鍵)を生成してよい。認証器82は、AKをBSに送信してよい。処理108で、認証器は、以下の表2のパラメータを含むRR−Reqメッセージを送信してよい。
【表2】
【0024】
処理110で、BS12およびMS14は、PMKv2の3通りのハンドシェーク(SA−TEK−チャレンジ/要求/応答交換)を行い、事前準備サ−ビスフローのセキュリティ連携を構築する。処理112で、BS12およびMS14は、TEK(トラフィック暗号鍵)鍵交換を、PMKv2鍵−要求/返信メッセージを利用して行ってよい。処理114で、MSおよびBSは、登録(REG)メッセージを利用してMS登録を行ってよい。
【0025】
処理116で、BS12のSFMモジュール74(例えば、許可制御モジュール76)は、許可制御を実行して、ネットワーク(BS12のセル)に入っているMS14のVoIPサービスフローをサポートできるか否かを判断してよい。許可制御モジュール76が、VoIPサービスフローをサポートできると判断した場合、許可信号を生成する。処理118で、SFMモジュール74(例えば、許可制御モジュール76)による認証がなされると、BS12のSFMモジュール74(例えば、データパス機能モジュール78)は、DSA−REQメッセージを送信して、図1に示され前述した第1のアップリンク(UL)サービスフロー44および第1のダウンリンク(DL)サービスフロー50を作成する。図1の第1のサービスフロー44および50は、VoIPシグナリングに利用されるが、SIPエージェント(図4および5参照のこと)へ、またはSIPエージェントから、それぞれ提供されてよい。第1のサービスフローもまた、他のデータに利用されうる(図1のデータ58参照のこと)。第1のサービスフローは、許可状態を経て遷移する必要性なく、アクティブ状態に設定される(例えば、ActiveQoSParamSetをヌルではない値に設定する)。
【0026】
処理120で、BS12がVoIP呼接続について図1の第2のULおよびDLサービスフロー46および52をサポートできる場合(例えば、データパス機能モジュール78が許可信号を受信する)、BS12(例えば、データパス機能モジュール78)は、DSA−REQメッセージを送信して、VoIP呼(呼のVoIPパケット)用の第2のサービスフロー46および52を作成する。第2のサービスフロー46および52は、許可状態に設定されるが(例えば、AdmittedQoSParamSetをヌルではない値に設定する)、これは、帯域幅が確保されているがまだ承認されていないことを意味する。処理122で、BS12は、RR−RSPメッセージを認証器82に送信してよい。
【0027】
一実施形態では、VoIPシグナリングの第1のサービスフローは、許可制御モジュール76がVoIP呼接続について第2のサービスフローを許可するか否かという条件にその構築が基づくことなく、許可制御モジュール76の認証に基づいて構築されてよい。別の実施形態では、VoIPシグナリングの第1のサービスフローの構築およびVoIP呼接続の第2のサービスフローの構築は、BS12が第2のサービスフローをサポートすることができるという許可制御モジュール76の決定を条件として行われてよい。
【0028】
図4および5は、呼毎に図1の第2のアップリンクサービスフロー46および第2のダウンリンクサービスフロー52の起動または起動停止をVoIPアプリケーションに行わせる2つのトリガモデルに関している。2つのトリガモードは、ASN70とMS14のトリガポイントにそれぞれ対応するASNトリガモードとMSトリガモードとを含む。以下の記載は、主に、第2アップリンクサービスフロー46の起動または起動停止に関するものであり、第2のダウンリンクサービスフロー52の起動または起動停止は、概ね第2のアップリンクサービスフロー46とともに行われる。
【0029】
図4を参照すると、本発明の幾らかの実施形態によると、図2のASN70は、ASNトリガモードの実装に関している。これら実施形態では、BS12のSFMモジュール74は、新たなコンポーネントである、WiMAX接続制御(WCC)モジュール130(「接続制御モジュール」とも称される)を有してよい。幾らかの実施形態では、BS12における残りのMAC層との通信は、主に、データパス機能モジュール78へ、またはデータパス機能モジュール78からのものである(例えば、DSAおよびDSC要求および応答メッセージの交換)。MS14はさらに、SIPエージェント132を示すよう描かれている。これら実施形態では、ASN70は、BS12のSFMモジュール74に、または、ASNゲートウェイ72に位置するSIPプロキシモジュール134を含みうる。SFMモジュール74は、BS12のMAC層の一部である。識別子R1は、図1のワイヤレス媒体(エアインタフェース)16のことであり、識別子R6は、SFMモジュール74とASNゲートウェイ72との間の通信リンクのことである。つまり、ASNトリガモードについては、WCCモジュール130はASN70内に配置される。
【0030】
概して、WCCモジュール130は、WiMAXサービスフローとともにVoIPストリーミングのマッピングを担う。WCCモジュール130は、MS14の代わりにVoIPサービスフローの起動または起動停止を担う。同様に、SIPプロキシモジュールは、MS14のSIPエージェント132の代わりに動作する。SIPプロキシモジュール134は、SIPサーバおよびSIPクライアントの役割の両方を果たす。SIPサーバとして機能するとき、SIPプロキシモジュール134は、MS14のSIPエージェント132からSIPシグナリングメッセージを受信してよい。SIPプロキシモジュール134は、SIPシグナリングメッセージに呼応して、図1のVoIPサービスフロー44および46を起動または起動停止するように、WCCモジュール130に要求してよい。SIPクライアントとして機能するとき、SIPプロキシモジュール134は、SIPシグナリングメッセージを、ネットワークのSIPサーバ(不図示)に転送してよい。SIPプロキシモジュール134は、後述するようにWCC−アプリケーションインタフェース(API)を介してWCCモジュール130とインタフェースしてよい。ASNトリガモードのVoIP呼のフローの例を図8および9に示すが、これはさらに、WCCプロトコルおよびそのSIPプロキシ134との相互作用を記載する。
【0031】
図5を参照すると、本発明の幾らかの実施形態における図2のMS14は、MSトリガモードの実装に関している。図5のコンポーネントの多くが図4のものと同じであるので、同じ参照番号を残し、説明を省略する。これら実施形態では、前述のWCCモジュール130は、MS14内に配置されてよく、SIPエージェント132と直接通信してよく、これにより、SIPプロキシモジュールは必要がなくなる。WCCモジュール130は、図4におけるASNトリガの実施形態のものと同じ機能を果たしてよい。図11および12はMSトリガモードのVoIP呼のフローの例を示しており、これはWCCプロトコルを、より詳細に説明している。
【0032】
2つのトリガモードの比較を以下の表3に示す。
【表3】
【0033】
図4および5に関しては、WCCモジュール130のWCC APIインタフェースは以下のように定義される。WCC APIインタフェースに関しては、図4のSIPプロキシモジュール134および図5のSIPエージェント132は、総称的に、「呼セッションモジュール」と称される、というのも、WCC APIと交換されたメッセージ(信号)は、図4および5のものと同じであるからである。SIPは呼セッションモジュールを実装するのに利用されるが、他の呼セッションプロトコルを利用することもできる。図4および5の両方におけるWCC APIは、SIPアプリケーションがVoIPサービスフローを起動または起動停止することを、以下のメッセージを利用して可能ならしめる。メッセージは以下の通りである:(a)wccConnReq−VoIPストリーミングをVoIPサービスフローに接続するための呼セッションモジュール(図4のSIPプロキシモジュール134または図5のSIPエージェント132)からの接続要求メッセージ、(b)wccConnRsp−wccConnReqへの接続応答メッセージ、(c)wccDiscReq−VoIPストリーミングのVoIPサービスフローへの接続を停止するための呼セッションモジュール(図4のSIPプロキシモジュール134または図5のSIPエージェント132)からの接続停止要求メッセージ、および(d)wccDiscRsp−wccDiscReqへの応答メッセージ。
【0034】
WCCモジュール130はさらに、サービスフローを制御する目的からIEEE802.16MACメッセージを利用するMAC APIを有してよい。幾らかの実施形態では、WCCモジュール130は以下のIEEE802.16メッセージを利用してよい:(a)DSA−REQ(dynamic service addition Request)−サービスフロー作成する要求、(b)DSA―RSP(dynamic service addition Response)−DSA−REQへの応答、(c)DSC―REQ(dynamic service change Request)−サービスフロー属性を変更する要求、(d)DSC−RSP(dynamic service change Response)−DSC−REQへの応答、(e)DSD−REQ(dynamic service deletion Request)−サービスフローの削除要求、および(f)DSD−RSP(dynamic service deletion Response)−DSD−REQへの応答。
【0035】
図6を参照すると、本発明の様々な実施形態による図4および5のWCCモジュール130の状態遷移図が、上述のAPIメッセージまたは信号を用いて示されている。さらに、状態遷移図は、後に提示する図7−12の概略図を提供している。図6のこの図は以下の状態を有する、(a)初期化状態140−電源投入またはリセット後の初期状態、(b)許可状態142−UL/DLサービスフロー等のリソースが確保された(割り当てられた)たが、起動されていない状態(つまり、アクティブなVoIP呼がない状態)、(c)起動待ち状態144−サービスフロー起動についてのBS応答を待っている状態、(d)アクティブ状態146−少なくとも1つのアクティブなVoIP呼がある状態、および(e)起動停止待ち状態148−サービスフロー起動停止についてのBS応答を待っている状態。
【0036】
許可状態は、上述の二段階呼制御手順の第1段階に対応する。初期化状態140にある間は、BSはWCCモジュールに、要請されていない(non-solicited)DSA−REQメッセージを送信して、幾らかの数のVoIP呼について確保された帯域幅割り当てを提供するよう要求してよい。DSA−RSPメッセージ(不図示)でBSに応答して、BSがサービスフロー削除を要請するDSD−REQメッセージを送信すると、WCCモジュールは、許可142から初期化状態140へ戻る。WCCモジュールは、BSがDSD−REQを送信してサービスフローを削除すると、メッセージ許可状態142から初期化状態140へ遷移して戻る。呼セッションモジュールからwccConnReqメッセージを受信すると、WCCモジュールはDSC−REQメッセージをBSに送信してよく、許可状態から起動待ち状態144へ遷移してよい。DSD−RSPメッセージをBSから受信すると、WCCモジュールは、起動待ち状態144からアクティブ状態146へ遷移してよい。アクティブ状態146は、今はアクティブなVoIP呼があるという点で、上述の二段階呼制御手順の第2段階に対応している。呼セッションモジュールからwccDiscReqメッセージを受信したWCCモジュールによりVoIP呼が終了されると、WCCモジュールは、アクティブ状態146から起動停止待ち状態148へ遷移してよく、ここで、WCCはDSC−REQメッセージをBSに送信してよい。DSC−RSPメッセージをBSから受信すると、WCCは、許可状態142へ遷移してよい。
【0037】
図7から12は、本発明の様々な実施形態による図6に記載したWCC状態図を実装するVoIP呼フローの様々な例を示す。これら例は、区別化されたサービスフローをVoIPサービスに提供するためのSIP、WCC、およびBS/MS MACの統合を示している。これらの例は、最大ビットレートが12.2Kbpsであるアダプティブマルチレート(AMR)codec(不図示)を利用する。これらの例においては、第2のサービスフローの各々が、25Kbpsの最大維持レートを必要としており、これには全てのヘッダオーバヘッドが含まれる。図6の状態に付された参照番号を図7から12でも利用する。図7から9に関しては、呼フローの例が図4に記載されたASNトリガモードについて示されている。ASNトリガモードのこの呼フローの例では、図4のWCCモジュール130はBS12に配置されている。同じ呼フローを、ASNゲートウェイ72に常駐しているWCCモジュール130について利用することもできる。図10から12に関しては、図5に記載するMSトリガモードについて呼フロー例が示されている。MSトリガモードのこの呼フローの例においては、図4のWCCモジュール130はMS14に位置している。
【0038】
図7を参照すると、BSに位置しているWCCモジュール130の初期化が示されており、これは基本的に図3の処理120に対応しており、ここではアップリンク(UL)およびダウンリンク(DL)VoIPトラフィックの2つのサービスフローが生成され、QoSパラメータセットタイプが「許可」に設定される。DSA−REQメッセージに示されているパラメータは、包括的ではなく、可変であってよい。より詳しくは、図7は、上述の二段階呼制御手順の第1段階による帯域幅確保シナリオを示す。IEEE802.16において、各サービスフローは一方向であるので、アップリンクおよびダウンリンクサービスフローが別個にセットアップされる必要がある。この例においては、一例である25Kbps帯域幅がVoIP呼用に確保されうる。特に、これは、図1の第2のULおよびUDサービスフロー46および52に対して確保された帯域幅割り当ての提供を示しており、ここで、許可要求はBS12のWCCモジュール130から発生して、BSの帯域幅を割り当てて、MS14の帯域幅を確保する。
【0039】
WCCモジュール130は、初期化状態から始まる。第一に、処理150で、BSはUL接続用のDSA−REQメッセージを、「許可(Admitted)」に設定されたQosSetTypeと25kbpsに設定された最大維持可能レート(maxSusRate)とともに、送信する。第二に、処理152で、WCCモジュール130は、CC=Succとして、処理152でこの確保された帯域幅割り当てを受けるDSA−RSPメッセージで応答する。第三に、処理155において、BSは、「許可」に設定されたQosSetTypeと25kbpsに設定された最大維持可能レート(maxSusRate)とともに、DL接続用にDSA−REQメッセージを送信する。第四に、処理156で、WCCモジュール130は、CC=Succとしてこの確保された帯域幅割り当てを受けるDSA−RSPメッセージで応答する。
【0040】
図4よび8を参照すると、図4のSIPプロキシモジュール134とともに呼セットアップが示されている。図4を参照すると、図8のヘッダは以下の通りである。発呼側(Caller)の「SIPエージェント」が図4のSIPエージェント132であり、「MSのMAC」がMS14のMACであり(例えば、図1のMAC/PHY層28)、「BSのWCC」が図4のBS12のWCCモジュール130であり、「ASNのSIPプロキシ」が図4のASN70のSIPプロキシモジュール134である。加えて、被呼側(Callee)のSIPエージェント158が示されている。より詳しくは、この発生している呼セットアップは、図7で遷移した、許可状態142にあるWCCモジュール130で開始される。
【0041】
最初の6つの処理160‐170は、VoIP呼をセットアップするSIPプロトコルを記載する。最初の処理160で、SIP INVITEメッセージを、発呼側のSIPエージェント132からSIPプロキシモジュール134へ送信してよい。第2の処理162で、SIPプロキシモジュール134は、被呼側のSIPエージェント158へINVITEを転送してよい。第3の処理164で、SIP100試行信号が、SIPプロキシモジュール134から、発呼側のSIPエージェント132に送信されてよい。第4の処理166で、SIP180呼信号を、被呼側のSIPエージェント158からSIPプロキシモジュール134に送信してよい。第5の処理168で、SIPプロキシモジュール134は、SIP180呼信号を、発呼側のSIPエージェント132に渡してよい。第6の処理170で、被呼側のSIPエージェント158は、SIP200OK信号を送信して、VoIP呼の構築を開始してよい。
【0042】
第7の処理172で、SIP200OK(被呼側のSIPエージェント158が呼に答える)に呼応して、SIPプロキシモジュール134は、VoIP呼について帯域幅を要求するwccConnReqメッセージをWCCモジュール130に送信してよい。加えて、wccConnReqメッセージは、VoIPストリーミングをサービスフローにマッピングするべく以下のパラメータを含む:(a)バイト単位の全ビットレート、(b)ms単位の音声パケット期間、(c)バイト単位の音声パケットサイズ、(d)ソースIPアドレスおよびポート番号、および(e)宛先IPアドレスおよびポート番号。
【0043】
wccConnReqメッセージに呼応して、第8および第9の処理174および176で、WCCモジュール130は、UL/DL用にMS14のMACにDSC−REQメッセージを、qosSetType=activeに設定されたパラメータとともに送信してよく、この後で、WCCモジュール130は、自身の起動待ち状態144に遷移してよい。より詳しくは、WCCモジュール130はDSC−REQメッセージを送信するときに、VoIP呼用にUL/DLサービスフローを起動するべく以下のパラメータを送信する:(a)サービスフロー識別(SFID)(ULまたはDL)、(b)QoSパラメータセットタイプ=「アクティブ」(これは、SFがアクティブであり、BS12がMS14に帯域幅を承認することを示す)、および(c)以下の規則によりSSおよびBSのパケット分類器を構成して、VoIPパケットが適切な第2のサービスフローにルーティングできるようにする(パラメータの例には、IP宛先アドレス/ポートおよびサービス/区別化されたサービスコードポイント(DSCP)のIPタイプが含まれる)。DSC−REQメッセージの送信後、WCCモジュール130は自身の起動待ち状態148へ遷移してよい。
【0044】
第10の処理178で、MS14のMAC層は、CC(Conformation Code)を成功(Succ)にセットして、ULのDSC−RSPメッセージに応答してよい。第11の処理180で、WCCモジュール130は、CCをSuccにセットして、ULのDSC−ACKを送信することで応答してよい。同様に、第12の処理182で、MS14のMAC層は、CC(Conformation Code)を成功(Succ)にセットして、DLのDSC−RSPメッセージで応答してよい。第13の処理184で、WCCモジュール130は、CCをSuccにセットして、DLのDSC−ACKを送信することで応答してよい。その後、WCCモジュール130は、アクティブ状態146に遷移してよい。
【0045】
第14の処理186で、WCCモジュール130は、SIPプロキシモジュール134に対してwccConnRspメッセージを送信して、SIPプロキシモジュール134にサービスフローで音声通信の準備が整ったことを通知してよい。その後、SIPプロトコルは、処理188−192の呼を完了する。より具体的には、第15の処理188で、SIPプロキシモジュール134は、SIP200OK信号を、発呼側のSIPエージェント132に送信してよい。第16の処理190で、発呼側のSIPエージェント132はSIP受領確認(ACK)をSIPプロキシモジュール134に送ってよく、第17の処理192で、SIPプロキシモジュール134は、被呼側のSIPエージェント158にACKを送信してよく、この後の194で音声接続が構築される。
【0046】
処理172は、帯域幅を起動して、MS14がVoIP呼中にデータ利用のため課金されることを示す。前述の利用データ記録(UDR)は、確保されているVoIP帯域幅および実際のデータ利用の期間に対して課金されるVoIPサブスクライバ(MS14)の課金記録を取得してもよい。概して、データパス機能モジュール78は、UDRの会計を管理し、SF情報データベース80にUDRを記憶させてよい。幾らかの実施形態では、VoIPサービスのUDRは、(a)確保されている第2のサービスフロー(UGS,rtPS、またはertPSサービスフロー)の期間、および(b)VoIP呼期間中にトランスポートされたバイト数を含む。
【0047】
図4から9を参照すると、これもASNトリガモードについて、図4のSIPプロキシモジュール134とともに図9に示す呼解除フローが示されている。第1の処理200で、発呼側のSIPエージェント132は、SIP BYEメッセージをSIPプロキシモジュール134に送信して、VoIP呼を解除してよい。第2の処理202で、SIPプロキシモジュール134は、VoIP UL/DLサービスフローに対する接続を停止するべく、以下のパラメータ(a)ソースIPアドレスおよびポート番号、(b)宛先IPアドレスおよびポート番号とともに、wccDiscReqメッセージをWCCモジュール130に送信することで、応答してよい。第3および第4の処理204および206で、WCCモジュール130は、VoIP呼のUL/DLサービスフローの起動停止をするべく以下のパラメータとともにDSCを送信することで、wccDiscReqメッセージに応答してよく、このパラメータとは以下の通りである:(a)SFID(ULまたはDL)、(b)QoSパラメータセットタイプ=許可(「許可」状態に変更することで、アクティブ呼がないことを示す)および(c)「分類器DSCアクション」パラメータをDSC削除分類器に設定する(先に呼に利用された分類器規則を削除する)パラメータ。DSC−REQメッセージの送信後に、WCCモジュール130は自身の起動停止待ち148に遷移してよい。
【0048】
第5の処理208で、MS14のMACは、CC(受領確認コード)(confirmation code)を成功(Succ)に設定してULのDSC−RSPメッセージを送信することで、ULのDSC−REQメッセージに応答してよい。第6の処理210で、WCCモジュール130は、CC=SuccとしてULのDSC−ACKメッセージを送信することで応答してよい。同様に、第7の処理212で、MS14のMACは、DLのDSC−RSPメッセージを送信することでDLのDSC−REQメッセージに応答してよい。第8の処理214で、WCCモジュール130は、CC=SuccとしてDLのDSC−ACKメッセージを送信することで応答してよい。その後、WCCモジュール130は、自身の許可状態142に遷移することで応答してよい。第9の処理216で、WCCモジュール130は、wccDiscRspをSIPプロキシモジュール134に送信して、SIPプロキシモジュール134に対して、サービスフローが起動停止されたことを通知してよい。
【0049】
処理218‐222で、SIPプロトコルは呼を解除する。第10の処理218で、SIPプロキシモジュール134は、被呼側のSIPエージェント158にSIP BYEメッセージを送信することで応答してよく、第11の処理220で、ACKをSIPプロキシモジュール134に送信してよい。第12の処理222で、SIPプロキシモジュール134は、発呼側のSIPエージェント132にACKを送信してよく、これにより224で音声接続がティアダウンされる。
【0050】
図10を参照すると、図5に示すMSトリガモードの呼フローの例が示されている。この例においては、WCCモジュール130はMS14に位置している。図10は、WCCモジュール130の初期化を示しており、これは基本的に図3の処理120に対応しており、ここではアップリンク(UL)およびダウンリンク(DL)VoIPトラフィックの2つのサービスフローが生成され、QoSパラメータセットタイプが「許可」に設定される。DSA−REQメッセージに示されているパラメータは、包括的ではなく、可変であってよい。この例においては、一例である25Kbps帯域幅がVoIP呼用に確保されうる。特に、これは、図1のUL/DLの第2のサービスフロー46および52に対して確保された帯域幅割り当ての提供を示しており、ここで、許可要求はBS12のMACから発生して、BSの帯域幅を割り当ててMS14の帯域幅を確保する。第一に、処理230で、BSは、qosSetTypeを「許可」に設定して、且つ、最大維持可能レート(maxSusRate)を25kbpsに設定して、UL接続のDSA−REQメッセージを送信する。第二に、処理232で、WCCモジュール130は、CC=Succとして、この確保された帯域幅割り当てを受け付けるDSA−RSPメッセージで応答する。第三に、処理234で、BSは、qosSetTypeを「許可」に設定して、且つ、最大維持可能レート(maxSusRate)を25kbpsに設定して、DL接続のDSA−REQメッセージを送信する。第四に、処理236で、WCCモジュール130は、CC=Succとして、この確保された帯域幅割り当てを受け付けるDSA−RSPメッセージで応答する。
【0051】
図5および11を参照すると、図4のSIPプロキシモジュール134による呼セットアップフローが示されている。この発生している呼セットアップのシナリオは、図10で示したように許可状態142になったWCCモジュール130で開始される。最初の三つの処理240−244は、VoIP呼をセットアップするSIPプロトコルを記載する。第1の処理240では、発呼側のSIPエージェント132から被呼側のSIPエージェント158へSIP INVITEメッセージを送信してよい。第2の処理242で、SIP180呼信号を、被呼側のSIPエージェント158から、発呼側のSIPエージェント132へ送信してよい。第3の処理244では、被呼側のSIPエージェント158は、SIP200OK信号を、発呼側のSIPエージェント132に送信して、VoIP呼の構築を開始してよい。第4の処理246で、SIP200OK(被呼側のSIPエージェント158が呼に答える)に呼応して、発呼側のSIPエージェント132は、VoIP呼について帯域幅を要求するwccConnReqメッセージをMS14のWCCモジュール130に送信してよい。加えて、wccConnReqメッセージは、VoIPストリーミングをサービスフローにマッピングするべく以下のパラメータを含む:(a)バイト単位の全ビットレート、(b)ms単位の音声パケット期間、(c)バイト単位の音声パケットサイズ、(d)ソースIPアドレスおよびポート番号、および(e)宛先IPアドレスおよびポート番号。
【0052】
wccConnReqメッセージに呼応して、第5および第6の処理248および250で、WCCモジュール130は、UL/DL用にBS12にDSC−REQメッセージを、qosSetType=activeに設定されたパラメータとともに送信してよく、この後で、WCCモジュール130は、自身の起動待ち状態(WaitForActivation state)144に遷移してよい。より詳しくは、WCCモジュール130はDSC−REQメッセージを送信するときに、VoIP呼用にUL/DLサービスフローを起動するべく以下のパラメータを送信する:(a)サービスフローID(SFID)(ULまたはDL)、(b)QoSパラメータセットタイプ=「アクティブ」(これは、SFがアクティブであり、BS12がMS14に確保された帯域幅を承認することを示す)、および(d)以下の規則によりSSおよびBSのパケット分類器を構成して、VoIPパケットが適切な第2のサービスフローにルーティングできるようにする(パラメータの例には、IP宛先アドレス/ポートおよびサービス/区別化されたサービスコードポイント(DSCP)のIPタイプが含まれる)。DSC−REQメッセージの送信後、WCCモジュール130は自身の起動待ち状態148へ遷移してよい。
【0053】
第7の処理252で、BS12は、CC(Conformation Code)を成功(Succ)にセットして、ULのDSC−RSPメッセージに応答してよい。第8の処理254で、MS14のWCCモジュール130は、CCをSuccにセットして、ULのDSC−ACKを送信することで応答してよい。同様に、第9の処理256で、BS12は、CC=Succとして、DLのDSC−RSPメッセージで応答してよい。第10の処理258で、WCCモジュール130は、CCをSuccにセットして、DLのDSC−ACKを送信することで応答してよい。第11の処理260で、WCCモジュール130は、発呼側のSIPエージェント132に対して、サービスフローにおいて音声通信の準備が整った旨を伝えるwccConnRspメッセージを送信してよい。その後、WCCモジュール130は、アクティブ状態146に遷移してよい。その後、SIPプロトコルは呼を完了する。より具体的には、第12の処理262で、発呼側のSIPエージェント132は、被呼側のSIPエージェント158にSIP ACK信号を送信してよく、その後の264で音声接続が構築される。
【0054】
図5から12を参照すると、図5に示すMSトリガモードとともに図12に示す呼解除フローが示されている。第1の処理270で、被呼側のSIPエージェント158は、SIP BYEメッセージを、発呼側のSIPエージェント132に送信して、VoIP呼を解除してよい。第2の処理272で、発呼側のSIPエージェント132は、VoIP UL/DLサービスフローに対する接続を停止するべく、パラメータ(a)ソースIPアドレスおよびポート番号、(b)宛先IPアドレスおよびポート番号とともにwccDiscReqメッセージをMS14のWCCモジュール130に送信することで応答してよい。 第3および第4の処理274および276で、WCCモジュール130は、VoIP呼のUL/DLサービスフローの起動停止をするべく以下のパラメータとともにDSC−REQメッセージを送信することで、wccDiscReqメッセージに応答してよく、このパラメータとは以下の通りである:(a)SFID(ULまたはDL)、(b)QoSパラメータセットタイプ=許可(「許可」状態に変更することで、アクティブ呼がないことを示す)および(c)「分類器DSCアクション」パラメータをDSC削除分類器に設定する(先に呼に利用された分類器規則を削除する)パラメータ。DSC−REQメッセージの送信後、WCCモジュール130は、起動停止待ち状態(WaitForDeactivation State)148に遷移してよい。
【0055】
第5の処理278で、BS12は、CC=Succとして、ULのDSC−RSPメッセージを送信することで、ULのDSC−REQメッセージに応答してよい。第6の処理280で、WCCモジュール130は、CC=SuccとしてULのDSC−ACKメッセージを送信することで応答してよい。同様に、第7の処理282で、BS12は、CC=Succとして、DLのDSC−RSPメッセージを送信することで、DLのDSC−REQメッセージに応答してよい。第8の処理284で、WCCモジュール130は、CC=SuccとしてDLのDSC−ACKメッセージを送信することで応答してよい。第9の処理286で、WCCモジュール130は、発呼側のSIPエージェント132にwccDiscRspを送信して、SIPエージェント132に、サービスフローが起動停止された旨を通知してよい。その後、WCCモジュール130は、自身の許可状態142に遷移することで応答してよい。処理288で、SIPプロトコルは、発呼側のSIPエージェント132が、SIP200OK信号を、被呼側のSIPエージェント158に送信することで呼を解除してよく、これにより290で音声接続がティアダウンされる。
【0056】
図13を参照すると、WCCモジュール130を含む図5のMS14であってよいシステム310が示されている。MSの例は、大容量記憶デバイスを有するラップトップまたはUMDである。システムは、プロセッサ(集積回路チップ)312およびチップ312搭載用のICチップキャリア314を含んでよい。ICチップキャリア314は、ソケット318を介して基板またはプリント回路基板(PCB)316に搭載されてよい。しかし、他のシステムではICキャリア314がPCB316に直接連結されてもよい。PCB316は、メインメモリ320と、外部デバイスまたは外部バス用に複数の入出力(I/O)モジュールとを有してよく、これら全てが互いに、PCB316上のバスシステム322より連結される。システム310は、さらに、I/Oモジュール326を介してバスシステム322に連結される大容量記憶デバイス324を含んでよい。幾らかの実施形態では、さらなるI/Oモジュール328および330が、それぞれ他の外部または周辺I/Oデバイス332および334について含まれてよい。SIPエージェント132およびWCCモジュール130は、大容量記憶デバイス326からメモリ318に、プロセッサ312の実行を目的として移動させられるソフトウェアモジュールであってよい。呼セッションおよびWCCモジュールはソフトウェアモジュールとして示されているが、他の実施形態では、これらはハードワイヤであってよい。加えて、二段階呼制御手順はMS14に実装されているが、BS12に対してトランスペアレントであってもよい。故に、二段階呼制御手順を含めることで、BS12との相互運用性の問題を引き起こすことなくシステム310に対して付加価値を有するサービスを作成することができる。
【0057】
特定の実施形態を例示および記載してきたが、当業者であれば同じ目的を達成するよう図られた任意の配置で記載されている特定の実施形態を置き換えることができることを理解しよう。本願は、本発明の適用例または変形例をカバーすることを意図している。故に、本発明は請求項およびその均等物によってのみの限定が明白に意図されている。
【技術分野】
【0001】
本発明の実施形態は、電子デバイス分野に係り、特に通信デバイスに係る。
【背景技術】
【0002】
ブロードバンドワイヤレスアクセス(BWA)システムは、ポイントツーマルチポイント通信システムを通信ネットワークに提供する。BWAシステムは通常マイクロ波およびミリメートル波技術を利用して、通信信号をワイヤレスベースステーション(BS)から1以上のサブスクライバステーション(SS)および/またはモバイルサブスクライバステーション(MS)に送信する。BWAシステムは、音声、ビデオ、およびデータサービスを提供するよう設計された集中(converged)ワイヤレスネットワークであってよい。規格の中の802.16ファミリーは、IEEE(米国電気電子学会)が、固定、ポータブル、および/または、モバイルBWAネットワークの提供を目的として開発した(IEEE規格802.16、2004年発行版、および後続の版)。WiMAX(Worldwide Interoperability for Microwave Access)フォーラムにより、IEEE802.16規格に基づくブロードバンドワイヤレスネットワークの配置が促進される。特に、WiMAXフォーラムにより、ブロードバンドワイヤレス機器の互換性および相互利用性が保証される。便宜上、本開示では「802.16」および「WiMAX」という用語を入れ替え可能な形で利用して、エアインタフェース規格のIEEE802.16一式のことを表す場合がある。
【0003】
ダウンリンク送信においては、WiMAXネットワークは、BSから、SSまたはMSへ、データパケットをブロードキャストしうるが、アップリンク送信においては、スケジューリングサービスを設計して、異なるトラフィックの特性およびサービス品質(QoS)要件を有するサービスをサポートすることができる。WiMAXネットワーク等の集中ワイヤレスネットワークの顕著な利点は、異なるサービス間のワイヤレススペクトルという殆どの貴重なリソースを共有できることである。しかし、WiMAXネットワークにおけるワイヤレスネットワークの集中には、多数のSS間でのアップリンク送信の調停、および、異なるサービス間で必要なQoSを有するアップリンク帯域幅の割り当てといった課題も存在する。
【図面の簡単な説明】
【0004】
【図1】本発明の様々な実施形態によるBWAシステムのブロック図である。
【図2】本発明の様々な実施形態による図1のBWAシステムのベースステーションを組み込むアクセスサービスネットワーク(ASN)のブロック図である。
【図3】本発明の様々な実施形態によるMSのアクティブな第1のサービスフローおよび許可された第2のサービスフローを提供する信号図である。
【図4】本発明の様々な実施形態による図1のベースステーションを組み込むASNのブロック図であり、ASNモードのトリガが示されている。
【図5】本発明の様々な実施形態による図1のベースステーションを組み込むASNのブロック図であり、MSモードトリガが示されている。
【図6】本発明の様々な実施形態によるWIMAX接続制御(WCC)モジュールの状態遷移図である。
【図7】本発明の様々な実施形態による、ASNトリガモードを利用するMSに対して確保された帯域幅を第2のサービスフローに提供する信号図である。
【図8】本発明の一実施形態による、ASNトリガモードを利用する呼のセットアップ処理の信号図である。
【図9】本発明の一実施形態による、ASNトリガモードを利用する呼のティアダウン処理の信号図である。
【図10】本発明の様々な実施形態による、MSトリガモードを利用するMSに対して確保された帯域幅を第2のサービスフローを提供する信号図である。
【図11】本発明の一実施形態による、MSトリガモードを利用する呼のセットアップ処理の信号図である。
【図12】本発明の一実施形態による、MSトリガモードを利用する呼のティアダウン処理の信号図である。
【図13】本発明の様々な実施形態を組み込むモバイルステーションシステムのブロック図である。
【発明を実施するための形態】
【0005】
以下の記載においては、説明を行う目的から多数の特定の詳細を述べて、本発明について開示する実施形態の完全な理解を可能とすることに努める。しかし、本発明の実施形態がこれら特定の詳細なく実施可能であることは当業者には明らかである。他の場合には、公知の電気的な構造および回路はブロック図の形式で示して、本発明について開示する実施形態を曖昧にしないよう努める。「連結」という用語は、直接的な接続、間接的な接続、または間接的な通信をも含有する。
【0006】
図1は、本発明の様々な実施形態による、例示的なブロードバンドワイヤレスアクセス(BWA)システム10を示す。BWAシステム10はワイヤレスセルを利用して地理的領域をカバーしてよい。BWAシステム10は、遠隔サイト位置の複数のモバイルサブスクライバステーション(モバイルSS)またはモバイルステーション(MS)14(図1にはMS14は1つだけ示されている)に対して送信する中央サイト位置のベースステーション(BS)12を含んでよい。MS14の例には、ラップトップまたはウルトラモバイルデバイス(UMD)(例えばハンドヘルドデバイス)が含まれうる。BWAシステム10の部材は、IEEE802.16規格の通信プロトコルに応じて互いに通信しあってよい。概して、この802.16規格は、ワイヤレスメトロポリタンエリアネットワーク(MAN)(WiMAXネットワークとも称されうる)の固定および/またはモバイルSS(例えばMS14)へのワイヤレスブロードバンドアクセスを定義してよい。BS12と複数のMS14とは、BS12のワイヤレスセルのワイヤレス媒体(エアインタフェース)16を介して通信する。BS12は、セル内のMS14への、またはMS14からのトラフィックを収集してよい。BS12はインターネット等の有線または無線のバックボーンネットワーク(不図示)へのインタフェースを有する機器を含むことができ、これにより任意のMS14とバックボーンネットワークとの間のリンクを提供する。
【0007】
MS14は、VoIP(voice over Internet Protocol)呼を生成および受信しうる。一実施形態では、BWAシステム10は、VoIP呼セッションについてセッション開始プロトコル(SIP)を利用する。SIPは、1以上のMS14のセッションを作成、修正、および終了させるアプリケーション層制御(シグナリング)プロトコルである(IETF(Internet Engineering Task Force)SIPワーキンググループによるRFC(Request For Comments)3261仕様を参照のこと)。しかし、SIP以外のプロトコルをVoIP呼セッションで利用することもできる。BWAシステムは、MS14が発信する、またはMS14で受信されたVoIPトラフィックを、音声サービス用に用意された特別なサービス品質(QoS)を有するコネクションを介して伝送する。IEEE802.16規格の関連部分の記載および様々な定義を提示して、本発明による様々な実施形態の理解を助ける。
【0008】
IEEE802.16は、「サービスフロー」を、パケット(SSが送信するアップリンクパケットまたはBSが送信するダウンリンクパケット)の一方向トランスポートを提供するメディアアクセスコントロール(MAC)トランスポートサービスとして定義している。サービスフローは、待ち時間、ジッタ、およびスループット保証等のQoSパラメータ一式により特徴付けられる。BSは、サービスフローについて定義されたQoSパラメータセットにおいて任意のQoSを提供する。概してIEEE802.16規格が記載するサービスフローは、(a)準備(Provisioned)‐このサービスフローの状態は、例えばネットワーク管理システムによる準備により既知である、(b)許可(Admitted)‐このサービスフローの状態は、SS用にBSがリソースを確保している、(c)アクティブ(Active)‐このサービスフローの状態は、SS用にBSがリソースを割り当てている、という3つの状態を有することができ、各サービスフローは3つの状態のいずれかへの遷移が可能である。IEEE802.16は、各サービスフロー符号内に、QoSパラメータセット(準備セット、許可セット、および/またはアクティブセット)の正規のアプリケーションを特定するパラメータQoSパラメータセットタイプ(「セットタイプパラメータ」)を含む。802.16規格は、帯域幅等のリソースがまず「許可され」、その後に、ひとたびエンドツーエンドネゴシエーションが完了すると、そのリソースを「起動」する、という、二段階起動モデルを提案している。IEEE802.16はさらに、VoIP呼接続がセットアップされるまたはティアダウンされる際に動的にサービスフローをそれぞれ作成、変更および削除するDSA(Dynamic Service Deletion)メッセージ、DSC(Dynamic service Change)メッセージ、およびDSD(Dynamic Service Deletion)メッセージを定義している。
【0009】
IEEE802.16(WiMAX)はさらに、区別化QoS要件への帯域幅要求/承認処理を用いてアップリンクスケジューリングサービスを定義している。以下は、様々なサービス用のIEEE802.16のサービスクラスである:(a)UGS(要請されていない(Unsolicited)承認サービス):T1/E1エミュレーションおよびサイレンス抑制のないVoIP等のサポートコンスタントビットレート(CBR)またはCBRに類似したサービスフローのサポート、(b)リアルタイムポーリングサービス(rtPS):サイレンス抑制のないVoIPサービス等の、周期的に可変サイズのデータパケットを生成するリアルタイムサービスフロー(SF)のサポート、(c)拡張リアルタイムポーリングサービス(ertPS):サイレンス抑制のないVoIP等の、周期的に可変サイズのデータパケットを生成するリアルタイムサービスフローのサポート、(d)非リアルタイムポーリングサービス(nrtPS):ファイル転送プロトコル(FTP)およびハイパーテキスト転送プロトコル(HTTP)等の、定期的に可変サイズのデータ承認バーストタイプを必要とする非リアルタイムSFのサポート、および(e)ベストエフォートサービス(BE):通常のウェブサーフィングおよび電子メールサービスのサポート。各サービスクラスは、一纏まりのMS14またはBS12が利用するサービスフロー特性または属性(QoSパラメータを含む)を含み、所望のQoSのサービスフローを要求する。
【0010】
アクセスサービスネットワーク(ASN)は、WiMAXサブスクライバ(例えばMS14)への無線アクセス(radio access)を行うのに必要な一式のネットワーク機能として定義される。ASNは以下の機能を提供する:(a)WiMAX MS(MS14等)とのWiMAX層−2(L2)コネクティビティ、(b)AAA(認証、許可、および会計上の)メッセージの、WiMAXサブスクライバのホームネットワークサービスプロバイダ(H−NSP)への、サブスクライバセッションの認証、許可、およびセッション会計を目的とした転送、(c)WiMAXサブスクライバの好適なNSPのネットワークでの発見および選択、(d)WiMAX MSとの層3(L3)の構築に関するリレー機能(つまりIPアドレス割り当て)、および無線リソース管理。上述の機能に加えて、ポータブルおよびモバイルな環境ではASNは以下の機能をサポートしうる:(a)ASNアンカーモビリティ、(b)コネクティビティサービスネットワーク(CSN)アンカーモビリティ、(c)ページング、および(d)ASN−CSNトンネリング(ASN-CSN tunneling)。ASNは、1以上のBS12、および1以上のASNゲートウェイ等のネットワーク部材を含みうる。1つのASNを、1を超える数のCSNが共有してもよい。
【0011】
CSN(Connectivity Service Network)は、インターネットプロトコル(IP)コネクティビティサービスをWiMAXサブスクライバに提供する一式のネットワーク機能として定義される。CSNは以下の機能を提供しうる:(a)ユーザセッションへのMS IPアドレスおよびエンドポイントパラメータ割り当て、(b)インターネットアクセス、(c)AAAプロキシまたはサーバ、(d)ユーザ加入プロフィールに基づくポリシーおよび許可制御(Policy and Admission Control)、(e)ASN−CSNトンネリングサポート、(f)WiMAXサブスクライバへの課金およびオペレータ間の調停(settling)、ローミングに際してのインターCSNトンネリング(inter-CSN tunneling for roaming)、および(h)インターASNモビリティおよびロケーションベースのサービス等のWiMAXサービス、ピアツーピアサービスへのコネクティビティ、法的な傍受サービスをサポートする目的の、IPマルチメディアサービスおよびファシリティへの準備、認証、および/または、コネクティビティ。CSNは、ルータ、AAAプロキシ/サーバ、ユーザデータベース、および相互作用ゲートウェイMS等のネットワーク部材を含みうる。
【0012】
AAA(認証、許可、および会計上の)サービスは、ユーザ認証、ユーザ許可、およびユーザ会計機能を行う。幾らかの実施形態では、遠隔認証ダイアルインユーザサービス(RADIUS)プロトコルを通信プロトコルとして利用して、AAA情報を伝送することができる。RADIUSは、自身のリンクおよび共有AAAまたはAAAプロキシサービスの認証を希望するデバイス間の認証、許可、会計および構成情報を伝送するインターネット標準トラックプロトコル(Internet standard track protocol)である。IEEE802.16eは、供給者と認証者との間の鍵交換において拡張可能認証プロトコル(EAP)を利用しており、多数の鍵を利用しうる。開始点は、認証サーバから来る一対のマスターキー(PMK)であってよい。
【0013】
図1に戻ると、本発明の様々な実施形態によるBWAシステム10のBS12およびMS14のうち1つを表すブロック概略図が示されている。MS14は1つしか示されていないが、BS12は複数のMS14(複数のモバイルSS14)を収容することができる。BS12およびMS14は、構想としてはアップリンク部分20とダウンリンク部分22とに、仮想線24で分割されている。BS12およびMS14の機能ユニットは、メディアアクセスコントロール(MAC)層と物理(PHY)層とを含むオープンシステムインターコネクト(OSI)モデルの層に準拠していてよく、これら層がアップリンク部分20およびダウンリンク部分22に分割されている。故に、MS14は、アップリンクMAC/PHY層部分28、ダウンリンクMAC層部分30、およびダウンリンクPHY層部分32に連結されているパケット分類器26として描くことができる。同様に、BS12は、ダウンリンクMAC/PHY層部分36に連結されるパケット分類器34を有するとして描くことができる。BS12はさらに、アップリンクPHY層部分38およびアップリンクMAC層部分40を含んでよい。後述するように、パケット分類器26および34は、分類規則に基づいて、パケットを適切な仮想接続へルーティングする。
【0014】
図1は、VoIPおよびデータ(例えばインターネットデータ)が、BWAシステム10の集中WiMAXネットワークでトランスポートされうる様子を示す。サービスフローは、エアインタフェース16を介した仮想接続である。より詳しくは、構想上の送信パイプ42が、MS14のアップリンクMAC/PHY層28と、BS12のアップリンクPHY層部分38との間に示されており、このパイプはVoIPシグナリング用の第1のアップリンクサービスフロー44と、VoIP呼(呼のVoIPパケット)用の第2のアップリンクサービスフロー46を有するとして示されているが、この詳細については後述する。同様に、構想上の送信パイプ48は、BS12のダウンリンクMAC/PHY層36と、MS14のダウンリンクPHY層部分22との間に示されており、このパイプはVoIPシグナリング用の第1のダウンリンクサービスフロー50と、VoIP呼(呼のVoIPパケットを伝送するVoIP接続)用の第2のダウンリンクサービスフロー52を有するとして示されている。MS14のパケット分類器26は、アップリンクVoIPパケット54を、BS12に向けたアップリンクの第2のサービスフロー46へと分類およびルーティングしてよく、BS12のパケット分類器34は、MS14に向けた第2のダウンリンクサービスフロー52へとダウンリンクVoIPパケット56を分類およびルーティングしてよい。同様に、アップリンクデータ58はパケット分類器26により分類されて、第1のアップリンクサービスフロー44へルーティングされてよく、ダウンリンクデータ60は第1のダウンリンクサービスフロー50へルーティングされてよい。パケット分類器26および34は、宛先IP/ポートアドレス、QoS属性(Tos(サービスのタイプ))、DSCP(区別化されたサービスコードポイント)等の規則を利用して、パケットを分類する。1つのサービスフローには多数の分類規則があってよい。後述するように、第1のサービスフロー44および50は、本発明の様々な実施形態では、VoIPシグナリングを含んでもよい。
【0015】
BWAシステム10は、本発明の様々な実施形態によると、VoIPサービスをサポートする制御プランのプロトコルおよび手順を含む。より詳しくは以下の通りである:準備および会計を含むVoIPサービス配置シナリオ、VoIP呼が開始される際に、区別化されたQoSをサービスフローに提供する方法、および、VoIP呼が終了する際のサービスフローの解除。VoIPサービスに関しては、1つのセルについて最大数のVoIP呼を良好な音声品質で提供することが望ましい。故に、VoIP呼の際の帯域幅割り当て/割り当て解除スキームは、帯域幅効率性および音声品質目的における重要な特徴でありうる。最も簡単な方法は、この目的にDSA/DSDメッセージを利用することであろう。しかし、呼毎にDSA/DSDを利用することには、以下の大きな問題がある:BSが任意の時点でVoIP呼を開始するのに幾つのMSがDSAメッセージを送信する必要があるのかを知る手立てがない、というのも、MSはBSからBSへローミングしているからである。故に、BSは音声およびデータサービスについて帯域幅割り当てを最適に計画することができない場合もある。この結果、帯域幅が不十分なために多くの呼が拒絶されることからVoIPサービスの保証ができなくなる虞がある。各DSA要求はホームAAAサーバに認証を目的として転送される必要があるので、呼のセットアップ中に重要な遅延が生じる可能性がある。遅延は、MSが外国のネットワーク(foreign networks)にローミングする際に、より長くなる可能性がある。これにより、呼毎にDSA/DSDメッセージを処理する方法では、BSスケジューリングが複雑なものになる虞がある。
【0016】
本発明の様々な実施形態によるBWAシステム10は、BS12が始める2つのサービスフロー手順を用いてWiMAXを介してVoIPを配置する。アップリンクフローに関しては、2つのサービスフローは、第1のアップリンクサービスフロー44および第2のアップリンクサービスフロー46を含み、ダウンリンクフローに関しては、2つのサービスフローは、第1のダウンリンクサービスフロー50および第2のダウンリンクサービスフロー52を含む。本発明の様々な実施形態によると、BWAシステム10の第2のアップリンクサービスフロー46および第2のダウンリンクサービスフロー52を、UGS、rtPSまたはertPSから選択する。幾らかの実施形態では、第1のアップリンクサービスフロー44および第1のダウンリンクサービスフロー50を、nrtPSまたはBEから選択してよい。第1のサービスフロー44および50のVoIPシグナリングには、呼制御メッセージ(例えば図8、9、11、および12に関して後述するSIP信号)を含んでよい。図2に関して詳述するように、BS12は、DSA−要求(DSA−REQ)メッセージを送信して、各第1のサービスフローがアクティブ状態(Active State)であるようなVoIPシグナリング用の第1のサービスフロー44および50を作成する。その後、BSがVoIP呼接続について第2のサービスフロー46および52をサポートすることができる場合、BS12は第2のサービスフローを作成するべくDSA−REQを送信する。後述するように、第2のサービスフロー46および52は、セットアップされると、各々許可状態(Admitted State)になり、これは、VoIPサービスの帯域幅が確保されているが、まだVoIP呼に対して承認されてはいないことを意味する。
【0017】
本発明の様々な実施形態によるBWAシステム10は、第1段階が帯域幅確保であり第2段階が帯域幅起動であるという、二段階呼制御手順を利用している。第1段階の前に、サービスフローをインスタンス化してよく、その準備されたQoSParamSetを、後の第1段階において確保される準備帯域幅を含むように設定してよく、これについては後述する。一つの可能性として、準備帯域幅の量は、ネットワーク管理システム(不図示)が設定してよい。別の可能性としては、準備帯域幅は、接続セットアップの前に、またはその間に、BS12とMS14との間でネゴシエーションされてもよい。インスタンス化された第2のサービスフローの提供は、準備状態(Provisioned State)を有することで特徴付けられ、このインスタンス化段階は、VoIPサービスに加入するMS14の第2のサービスフローの「事前準備(pre-provisioning)」とも称される場合がある。この名称によって、後に行われる帯域幅の確保は、「準備」の一部として称される場合もある。
【0018】
帯域幅確保を行う第1段階では、MS14がBS12のセルに入ると、BS12はVoIPサービスの第2のサービスフロー46および52用に帯域幅を確保する。これらサービスフローは、図6を参照しながら後述するように、許可状態に変化する(QoSパラメータ状態が「許可された(Admitted)」になる)。帯域幅起動を行う第2段階で、VoIP呼が開始されると、QoSパラメータ状態がアクティブ(Active)に設定され、帯域幅(確保された帯域幅割り当て)が、最大維持トラフィックレートパラメータが特定するように、VoIP呼に対して承認される。帯域幅の起動停止(deactivation)の際には、VoIP呼を終了すると、QoSパラメータ状態が、許可状態(Admitted State)に変化する。加えて、VoIPサービスのUDR(利用データ記録)を生成するが、これには、(a)確保されている第2サービスフローの期間および(b)呼期間中にトランスポートされたバイト数が含まれる。
【0019】
図2を参照すると、本発明の様々な実施形態によるBS12における図1のBWAシステム10のBS12はASN70の一部として示されており、MAC層のソフトウェア機能の幾つかが示されている。ASN70はさらに、BS12に連結されたASNゲートウェイ(ASN GW)72を含む。BS12は、サービスフロー管理(SFM)モジュール74を含むとして示されている。幾らかの実施形態では、SFMモジュール74は、許可(admission)制御モジュール76、データパス機能モジュール78、および許可制御モジュール76およびデータパス機能78に連結されたサービスフロー情報(SF info)データベース80を含んでもよい。しかし、全てがBS12のMAC層に存在するこれらモジュールの機能は、異なる分類がなされて異なる名称で称されてもよい。一例としては、SFMモジュール74は図1のBS12のMAC/PHY36の一部であってもよい。幾らかの実施形態では、ASNゲートウェイ72は、認証器82を含んでよい。ASNゲートウェイ72は、AAAサーバ84に連結されてもよいし、AAAサーバに連結されうるAAAプロキシサーバに連結されてもよい。AAAサーバ84はホームCSNであってもよいことは前述の通りである。
【0020】
幾らかの実施形態では、前述のサービスフローQoSパラメータに対する全ての変更は、SFMモジュール74の許可を受けることにしてもよい。これには、新たなサービスフローを作成する全てのDSA−REQメッセージ、および、既存のサービスフローのQoSパラメータセットを変更する全てのDSC−REQメッセージが含まれる。これら変更には、許可制御モジュール76による許可制御決定(例えばAdmittedQosParamSetの設定)、および、データパス機能モジュール78によるサービスフローの起動(例えば、ActiveQosParamSetの設定)が含まれてよい。リソースに関する低減要求も、許可制御モジュール76による許可を受けることにしてもよい。
【0021】
データパス機能モジュール78は、許可制御モジュール76に対して要求を行ってよい。データパス機能モジュール78は、さらに、DSA,DSC,およびDSDメッセージをWiMax接続制御モジュール(後述)に送受信してよい。データパス機能モジュール78はさらに、「BSスケジューラ」と称されるものを含んでよく、これは主に、前述した第1および第2のサービスフローを含むサービスフローに対する帯域幅承認をスケジュールするのに利用されてよい。概して、複数の要因(factor)に基づいて、BSスケジューラは、特定の帯域幅の送信データを選択してよい。スケジュールサービスおよび関連するQoSパラメータを特定することにより、BSスケジューラはアップリンクトラフィックのスループットおよび待ち時間の必要性を予期して、ポールを提供する、および/または、適時に承認することができる。図3に関して記載するように、幾らかの実施形態では、各MS14は、BS12が構築した(VoIPパケットの接続である)VoIPシグナリング用の自身の第1のアップリンクサービスフロー44、およびVoIPシグナリング用の自身の第2のアップリンクサービスフロー46を有する。
【0022】
図1および2を適宜参照しながら図3を参照すると、本発明の幾らかの実施形態によるVoIPサービスフロー準備および確保手順90が示されている。VoIP呼における第2のサービスフローの確保手順は、MS14がネットワークに入ることで(例えば図1におけるBWAシステム10のBS12のセルに入ることで)開始されてよい。処理92でMS14は、ダウンリンク(DL)取得、同期、範囲変更(ranging)を行い、サブスクライバ基本機能(SBC)をBS12との間で交換してよい。処理94で、ASN GW72の認証器82は、秘密鍵管理バージョン2(PMKv2)EAP−転送メッセージに含まれているEAP−ID要求をMS14へ送信してよい。処理96では、MS14は、PMKv2EAP−転送メッセージに含まれているEAP−ID応答を認証器82に返してよい。処理98では、MSのEAPのIDは、認証器82がホームAAAサーバ84に送信するRADIUSアクセス要求(Req)メッセージに含まれていてよい。処理100では、EAP認証プロセスは、MS14とAAAサーバ84との間で行われてよい。処理102で、EAP認証プロセスが完了してよい。処理104で、AAAサーバ84は、以下の表1に示すパラメータを含むRADIUSアクセス応答(Rsp)メッセージを送信してよい。
【表1】
【0023】
処理104で、認証器82は、PMKv2EAP−転送メッセージに含まれているEAP−SuccessをMS14へ送信する。処理106で、認証器82は、MSK(マスターセッションキー)からPMK(対のマスターキー)を生成して、IEEE802.16e推奨版に特定されているアルゴリズムに基づいてPMKからAKを(認証鍵)を生成してよい。認証器82は、AKをBSに送信してよい。処理108で、認証器は、以下の表2のパラメータを含むRR−Reqメッセージを送信してよい。
【表2】
【0024】
処理110で、BS12およびMS14は、PMKv2の3通りのハンドシェーク(SA−TEK−チャレンジ/要求/応答交換)を行い、事前準備サ−ビスフローのセキュリティ連携を構築する。処理112で、BS12およびMS14は、TEK(トラフィック暗号鍵)鍵交換を、PMKv2鍵−要求/返信メッセージを利用して行ってよい。処理114で、MSおよびBSは、登録(REG)メッセージを利用してMS登録を行ってよい。
【0025】
処理116で、BS12のSFMモジュール74(例えば、許可制御モジュール76)は、許可制御を実行して、ネットワーク(BS12のセル)に入っているMS14のVoIPサービスフローをサポートできるか否かを判断してよい。許可制御モジュール76が、VoIPサービスフローをサポートできると判断した場合、許可信号を生成する。処理118で、SFMモジュール74(例えば、許可制御モジュール76)による認証がなされると、BS12のSFMモジュール74(例えば、データパス機能モジュール78)は、DSA−REQメッセージを送信して、図1に示され前述した第1のアップリンク(UL)サービスフロー44および第1のダウンリンク(DL)サービスフロー50を作成する。図1の第1のサービスフロー44および50は、VoIPシグナリングに利用されるが、SIPエージェント(図4および5参照のこと)へ、またはSIPエージェントから、それぞれ提供されてよい。第1のサービスフローもまた、他のデータに利用されうる(図1のデータ58参照のこと)。第1のサービスフローは、許可状態を経て遷移する必要性なく、アクティブ状態に設定される(例えば、ActiveQoSParamSetをヌルではない値に設定する)。
【0026】
処理120で、BS12がVoIP呼接続について図1の第2のULおよびDLサービスフロー46および52をサポートできる場合(例えば、データパス機能モジュール78が許可信号を受信する)、BS12(例えば、データパス機能モジュール78)は、DSA−REQメッセージを送信して、VoIP呼(呼のVoIPパケット)用の第2のサービスフロー46および52を作成する。第2のサービスフロー46および52は、許可状態に設定されるが(例えば、AdmittedQoSParamSetをヌルではない値に設定する)、これは、帯域幅が確保されているがまだ承認されていないことを意味する。処理122で、BS12は、RR−RSPメッセージを認証器82に送信してよい。
【0027】
一実施形態では、VoIPシグナリングの第1のサービスフローは、許可制御モジュール76がVoIP呼接続について第2のサービスフローを許可するか否かという条件にその構築が基づくことなく、許可制御モジュール76の認証に基づいて構築されてよい。別の実施形態では、VoIPシグナリングの第1のサービスフローの構築およびVoIP呼接続の第2のサービスフローの構築は、BS12が第2のサービスフローをサポートすることができるという許可制御モジュール76の決定を条件として行われてよい。
【0028】
図4および5は、呼毎に図1の第2のアップリンクサービスフロー46および第2のダウンリンクサービスフロー52の起動または起動停止をVoIPアプリケーションに行わせる2つのトリガモデルに関している。2つのトリガモードは、ASN70とMS14のトリガポイントにそれぞれ対応するASNトリガモードとMSトリガモードとを含む。以下の記載は、主に、第2アップリンクサービスフロー46の起動または起動停止に関するものであり、第2のダウンリンクサービスフロー52の起動または起動停止は、概ね第2のアップリンクサービスフロー46とともに行われる。
【0029】
図4を参照すると、本発明の幾らかの実施形態によると、図2のASN70は、ASNトリガモードの実装に関している。これら実施形態では、BS12のSFMモジュール74は、新たなコンポーネントである、WiMAX接続制御(WCC)モジュール130(「接続制御モジュール」とも称される)を有してよい。幾らかの実施形態では、BS12における残りのMAC層との通信は、主に、データパス機能モジュール78へ、またはデータパス機能モジュール78からのものである(例えば、DSAおよびDSC要求および応答メッセージの交換)。MS14はさらに、SIPエージェント132を示すよう描かれている。これら実施形態では、ASN70は、BS12のSFMモジュール74に、または、ASNゲートウェイ72に位置するSIPプロキシモジュール134を含みうる。SFMモジュール74は、BS12のMAC層の一部である。識別子R1は、図1のワイヤレス媒体(エアインタフェース)16のことであり、識別子R6は、SFMモジュール74とASNゲートウェイ72との間の通信リンクのことである。つまり、ASNトリガモードについては、WCCモジュール130はASN70内に配置される。
【0030】
概して、WCCモジュール130は、WiMAXサービスフローとともにVoIPストリーミングのマッピングを担う。WCCモジュール130は、MS14の代わりにVoIPサービスフローの起動または起動停止を担う。同様に、SIPプロキシモジュールは、MS14のSIPエージェント132の代わりに動作する。SIPプロキシモジュール134は、SIPサーバおよびSIPクライアントの役割の両方を果たす。SIPサーバとして機能するとき、SIPプロキシモジュール134は、MS14のSIPエージェント132からSIPシグナリングメッセージを受信してよい。SIPプロキシモジュール134は、SIPシグナリングメッセージに呼応して、図1のVoIPサービスフロー44および46を起動または起動停止するように、WCCモジュール130に要求してよい。SIPクライアントとして機能するとき、SIPプロキシモジュール134は、SIPシグナリングメッセージを、ネットワークのSIPサーバ(不図示)に転送してよい。SIPプロキシモジュール134は、後述するようにWCC−アプリケーションインタフェース(API)を介してWCCモジュール130とインタフェースしてよい。ASNトリガモードのVoIP呼のフローの例を図8および9に示すが、これはさらに、WCCプロトコルおよびそのSIPプロキシ134との相互作用を記載する。
【0031】
図5を参照すると、本発明の幾らかの実施形態における図2のMS14は、MSトリガモードの実装に関している。図5のコンポーネントの多くが図4のものと同じであるので、同じ参照番号を残し、説明を省略する。これら実施形態では、前述のWCCモジュール130は、MS14内に配置されてよく、SIPエージェント132と直接通信してよく、これにより、SIPプロキシモジュールは必要がなくなる。WCCモジュール130は、図4におけるASNトリガの実施形態のものと同じ機能を果たしてよい。図11および12はMSトリガモードのVoIP呼のフローの例を示しており、これはWCCプロトコルを、より詳細に説明している。
【0032】
2つのトリガモードの比較を以下の表3に示す。
【表3】
【0033】
図4および5に関しては、WCCモジュール130のWCC APIインタフェースは以下のように定義される。WCC APIインタフェースに関しては、図4のSIPプロキシモジュール134および図5のSIPエージェント132は、総称的に、「呼セッションモジュール」と称される、というのも、WCC APIと交換されたメッセージ(信号)は、図4および5のものと同じであるからである。SIPは呼セッションモジュールを実装するのに利用されるが、他の呼セッションプロトコルを利用することもできる。図4および5の両方におけるWCC APIは、SIPアプリケーションがVoIPサービスフローを起動または起動停止することを、以下のメッセージを利用して可能ならしめる。メッセージは以下の通りである:(a)wccConnReq−VoIPストリーミングをVoIPサービスフローに接続するための呼セッションモジュール(図4のSIPプロキシモジュール134または図5のSIPエージェント132)からの接続要求メッセージ、(b)wccConnRsp−wccConnReqへの接続応答メッセージ、(c)wccDiscReq−VoIPストリーミングのVoIPサービスフローへの接続を停止するための呼セッションモジュール(図4のSIPプロキシモジュール134または図5のSIPエージェント132)からの接続停止要求メッセージ、および(d)wccDiscRsp−wccDiscReqへの応答メッセージ。
【0034】
WCCモジュール130はさらに、サービスフローを制御する目的からIEEE802.16MACメッセージを利用するMAC APIを有してよい。幾らかの実施形態では、WCCモジュール130は以下のIEEE802.16メッセージを利用してよい:(a)DSA−REQ(dynamic service addition Request)−サービスフロー作成する要求、(b)DSA―RSP(dynamic service addition Response)−DSA−REQへの応答、(c)DSC―REQ(dynamic service change Request)−サービスフロー属性を変更する要求、(d)DSC−RSP(dynamic service change Response)−DSC−REQへの応答、(e)DSD−REQ(dynamic service deletion Request)−サービスフローの削除要求、および(f)DSD−RSP(dynamic service deletion Response)−DSD−REQへの応答。
【0035】
図6を参照すると、本発明の様々な実施形態による図4および5のWCCモジュール130の状態遷移図が、上述のAPIメッセージまたは信号を用いて示されている。さらに、状態遷移図は、後に提示する図7−12の概略図を提供している。図6のこの図は以下の状態を有する、(a)初期化状態140−電源投入またはリセット後の初期状態、(b)許可状態142−UL/DLサービスフロー等のリソースが確保された(割り当てられた)たが、起動されていない状態(つまり、アクティブなVoIP呼がない状態)、(c)起動待ち状態144−サービスフロー起動についてのBS応答を待っている状態、(d)アクティブ状態146−少なくとも1つのアクティブなVoIP呼がある状態、および(e)起動停止待ち状態148−サービスフロー起動停止についてのBS応答を待っている状態。
【0036】
許可状態は、上述の二段階呼制御手順の第1段階に対応する。初期化状態140にある間は、BSはWCCモジュールに、要請されていない(non-solicited)DSA−REQメッセージを送信して、幾らかの数のVoIP呼について確保された帯域幅割り当てを提供するよう要求してよい。DSA−RSPメッセージ(不図示)でBSに応答して、BSがサービスフロー削除を要請するDSD−REQメッセージを送信すると、WCCモジュールは、許可142から初期化状態140へ戻る。WCCモジュールは、BSがDSD−REQを送信してサービスフローを削除すると、メッセージ許可状態142から初期化状態140へ遷移して戻る。呼セッションモジュールからwccConnReqメッセージを受信すると、WCCモジュールはDSC−REQメッセージをBSに送信してよく、許可状態から起動待ち状態144へ遷移してよい。DSD−RSPメッセージをBSから受信すると、WCCモジュールは、起動待ち状態144からアクティブ状態146へ遷移してよい。アクティブ状態146は、今はアクティブなVoIP呼があるという点で、上述の二段階呼制御手順の第2段階に対応している。呼セッションモジュールからwccDiscReqメッセージを受信したWCCモジュールによりVoIP呼が終了されると、WCCモジュールは、アクティブ状態146から起動停止待ち状態148へ遷移してよく、ここで、WCCはDSC−REQメッセージをBSに送信してよい。DSC−RSPメッセージをBSから受信すると、WCCは、許可状態142へ遷移してよい。
【0037】
図7から12は、本発明の様々な実施形態による図6に記載したWCC状態図を実装するVoIP呼フローの様々な例を示す。これら例は、区別化されたサービスフローをVoIPサービスに提供するためのSIP、WCC、およびBS/MS MACの統合を示している。これらの例は、最大ビットレートが12.2Kbpsであるアダプティブマルチレート(AMR)codec(不図示)を利用する。これらの例においては、第2のサービスフローの各々が、25Kbpsの最大維持レートを必要としており、これには全てのヘッダオーバヘッドが含まれる。図6の状態に付された参照番号を図7から12でも利用する。図7から9に関しては、呼フローの例が図4に記載されたASNトリガモードについて示されている。ASNトリガモードのこの呼フローの例では、図4のWCCモジュール130はBS12に配置されている。同じ呼フローを、ASNゲートウェイ72に常駐しているWCCモジュール130について利用することもできる。図10から12に関しては、図5に記載するMSトリガモードについて呼フロー例が示されている。MSトリガモードのこの呼フローの例においては、図4のWCCモジュール130はMS14に位置している。
【0038】
図7を参照すると、BSに位置しているWCCモジュール130の初期化が示されており、これは基本的に図3の処理120に対応しており、ここではアップリンク(UL)およびダウンリンク(DL)VoIPトラフィックの2つのサービスフローが生成され、QoSパラメータセットタイプが「許可」に設定される。DSA−REQメッセージに示されているパラメータは、包括的ではなく、可変であってよい。より詳しくは、図7は、上述の二段階呼制御手順の第1段階による帯域幅確保シナリオを示す。IEEE802.16において、各サービスフローは一方向であるので、アップリンクおよびダウンリンクサービスフローが別個にセットアップされる必要がある。この例においては、一例である25Kbps帯域幅がVoIP呼用に確保されうる。特に、これは、図1の第2のULおよびUDサービスフロー46および52に対して確保された帯域幅割り当ての提供を示しており、ここで、許可要求はBS12のWCCモジュール130から発生して、BSの帯域幅を割り当てて、MS14の帯域幅を確保する。
【0039】
WCCモジュール130は、初期化状態から始まる。第一に、処理150で、BSはUL接続用のDSA−REQメッセージを、「許可(Admitted)」に設定されたQosSetTypeと25kbpsに設定された最大維持可能レート(maxSusRate)とともに、送信する。第二に、処理152で、WCCモジュール130は、CC=Succとして、処理152でこの確保された帯域幅割り当てを受けるDSA−RSPメッセージで応答する。第三に、処理155において、BSは、「許可」に設定されたQosSetTypeと25kbpsに設定された最大維持可能レート(maxSusRate)とともに、DL接続用にDSA−REQメッセージを送信する。第四に、処理156で、WCCモジュール130は、CC=Succとしてこの確保された帯域幅割り当てを受けるDSA−RSPメッセージで応答する。
【0040】
図4よび8を参照すると、図4のSIPプロキシモジュール134とともに呼セットアップが示されている。図4を参照すると、図8のヘッダは以下の通りである。発呼側(Caller)の「SIPエージェント」が図4のSIPエージェント132であり、「MSのMAC」がMS14のMACであり(例えば、図1のMAC/PHY層28)、「BSのWCC」が図4のBS12のWCCモジュール130であり、「ASNのSIPプロキシ」が図4のASN70のSIPプロキシモジュール134である。加えて、被呼側(Callee)のSIPエージェント158が示されている。より詳しくは、この発生している呼セットアップは、図7で遷移した、許可状態142にあるWCCモジュール130で開始される。
【0041】
最初の6つの処理160‐170は、VoIP呼をセットアップするSIPプロトコルを記載する。最初の処理160で、SIP INVITEメッセージを、発呼側のSIPエージェント132からSIPプロキシモジュール134へ送信してよい。第2の処理162で、SIPプロキシモジュール134は、被呼側のSIPエージェント158へINVITEを転送してよい。第3の処理164で、SIP100試行信号が、SIPプロキシモジュール134から、発呼側のSIPエージェント132に送信されてよい。第4の処理166で、SIP180呼信号を、被呼側のSIPエージェント158からSIPプロキシモジュール134に送信してよい。第5の処理168で、SIPプロキシモジュール134は、SIP180呼信号を、発呼側のSIPエージェント132に渡してよい。第6の処理170で、被呼側のSIPエージェント158は、SIP200OK信号を送信して、VoIP呼の構築を開始してよい。
【0042】
第7の処理172で、SIP200OK(被呼側のSIPエージェント158が呼に答える)に呼応して、SIPプロキシモジュール134は、VoIP呼について帯域幅を要求するwccConnReqメッセージをWCCモジュール130に送信してよい。加えて、wccConnReqメッセージは、VoIPストリーミングをサービスフローにマッピングするべく以下のパラメータを含む:(a)バイト単位の全ビットレート、(b)ms単位の音声パケット期間、(c)バイト単位の音声パケットサイズ、(d)ソースIPアドレスおよびポート番号、および(e)宛先IPアドレスおよびポート番号。
【0043】
wccConnReqメッセージに呼応して、第8および第9の処理174および176で、WCCモジュール130は、UL/DL用にMS14のMACにDSC−REQメッセージを、qosSetType=activeに設定されたパラメータとともに送信してよく、この後で、WCCモジュール130は、自身の起動待ち状態144に遷移してよい。より詳しくは、WCCモジュール130はDSC−REQメッセージを送信するときに、VoIP呼用にUL/DLサービスフローを起動するべく以下のパラメータを送信する:(a)サービスフロー識別(SFID)(ULまたはDL)、(b)QoSパラメータセットタイプ=「アクティブ」(これは、SFがアクティブであり、BS12がMS14に帯域幅を承認することを示す)、および(c)以下の規則によりSSおよびBSのパケット分類器を構成して、VoIPパケットが適切な第2のサービスフローにルーティングできるようにする(パラメータの例には、IP宛先アドレス/ポートおよびサービス/区別化されたサービスコードポイント(DSCP)のIPタイプが含まれる)。DSC−REQメッセージの送信後、WCCモジュール130は自身の起動待ち状態148へ遷移してよい。
【0044】
第10の処理178で、MS14のMAC層は、CC(Conformation Code)を成功(Succ)にセットして、ULのDSC−RSPメッセージに応答してよい。第11の処理180で、WCCモジュール130は、CCをSuccにセットして、ULのDSC−ACKを送信することで応答してよい。同様に、第12の処理182で、MS14のMAC層は、CC(Conformation Code)を成功(Succ)にセットして、DLのDSC−RSPメッセージで応答してよい。第13の処理184で、WCCモジュール130は、CCをSuccにセットして、DLのDSC−ACKを送信することで応答してよい。その後、WCCモジュール130は、アクティブ状態146に遷移してよい。
【0045】
第14の処理186で、WCCモジュール130は、SIPプロキシモジュール134に対してwccConnRspメッセージを送信して、SIPプロキシモジュール134にサービスフローで音声通信の準備が整ったことを通知してよい。その後、SIPプロトコルは、処理188−192の呼を完了する。より具体的には、第15の処理188で、SIPプロキシモジュール134は、SIP200OK信号を、発呼側のSIPエージェント132に送信してよい。第16の処理190で、発呼側のSIPエージェント132はSIP受領確認(ACK)をSIPプロキシモジュール134に送ってよく、第17の処理192で、SIPプロキシモジュール134は、被呼側のSIPエージェント158にACKを送信してよく、この後の194で音声接続が構築される。
【0046】
処理172は、帯域幅を起動して、MS14がVoIP呼中にデータ利用のため課金されることを示す。前述の利用データ記録(UDR)は、確保されているVoIP帯域幅および実際のデータ利用の期間に対して課金されるVoIPサブスクライバ(MS14)の課金記録を取得してもよい。概して、データパス機能モジュール78は、UDRの会計を管理し、SF情報データベース80にUDRを記憶させてよい。幾らかの実施形態では、VoIPサービスのUDRは、(a)確保されている第2のサービスフロー(UGS,rtPS、またはertPSサービスフロー)の期間、および(b)VoIP呼期間中にトランスポートされたバイト数を含む。
【0047】
図4から9を参照すると、これもASNトリガモードについて、図4のSIPプロキシモジュール134とともに図9に示す呼解除フローが示されている。第1の処理200で、発呼側のSIPエージェント132は、SIP BYEメッセージをSIPプロキシモジュール134に送信して、VoIP呼を解除してよい。第2の処理202で、SIPプロキシモジュール134は、VoIP UL/DLサービスフローに対する接続を停止するべく、以下のパラメータ(a)ソースIPアドレスおよびポート番号、(b)宛先IPアドレスおよびポート番号とともに、wccDiscReqメッセージをWCCモジュール130に送信することで、応答してよい。第3および第4の処理204および206で、WCCモジュール130は、VoIP呼のUL/DLサービスフローの起動停止をするべく以下のパラメータとともにDSCを送信することで、wccDiscReqメッセージに応答してよく、このパラメータとは以下の通りである:(a)SFID(ULまたはDL)、(b)QoSパラメータセットタイプ=許可(「許可」状態に変更することで、アクティブ呼がないことを示す)および(c)「分類器DSCアクション」パラメータをDSC削除分類器に設定する(先に呼に利用された分類器規則を削除する)パラメータ。DSC−REQメッセージの送信後に、WCCモジュール130は自身の起動停止待ち148に遷移してよい。
【0048】
第5の処理208で、MS14のMACは、CC(受領確認コード)(confirmation code)を成功(Succ)に設定してULのDSC−RSPメッセージを送信することで、ULのDSC−REQメッセージに応答してよい。第6の処理210で、WCCモジュール130は、CC=SuccとしてULのDSC−ACKメッセージを送信することで応答してよい。同様に、第7の処理212で、MS14のMACは、DLのDSC−RSPメッセージを送信することでDLのDSC−REQメッセージに応答してよい。第8の処理214で、WCCモジュール130は、CC=SuccとしてDLのDSC−ACKメッセージを送信することで応答してよい。その後、WCCモジュール130は、自身の許可状態142に遷移することで応答してよい。第9の処理216で、WCCモジュール130は、wccDiscRspをSIPプロキシモジュール134に送信して、SIPプロキシモジュール134に対して、サービスフローが起動停止されたことを通知してよい。
【0049】
処理218‐222で、SIPプロトコルは呼を解除する。第10の処理218で、SIPプロキシモジュール134は、被呼側のSIPエージェント158にSIP BYEメッセージを送信することで応答してよく、第11の処理220で、ACKをSIPプロキシモジュール134に送信してよい。第12の処理222で、SIPプロキシモジュール134は、発呼側のSIPエージェント132にACKを送信してよく、これにより224で音声接続がティアダウンされる。
【0050】
図10を参照すると、図5に示すMSトリガモードの呼フローの例が示されている。この例においては、WCCモジュール130はMS14に位置している。図10は、WCCモジュール130の初期化を示しており、これは基本的に図3の処理120に対応しており、ここではアップリンク(UL)およびダウンリンク(DL)VoIPトラフィックの2つのサービスフローが生成され、QoSパラメータセットタイプが「許可」に設定される。DSA−REQメッセージに示されているパラメータは、包括的ではなく、可変であってよい。この例においては、一例である25Kbps帯域幅がVoIP呼用に確保されうる。特に、これは、図1のUL/DLの第2のサービスフロー46および52に対して確保された帯域幅割り当ての提供を示しており、ここで、許可要求はBS12のMACから発生して、BSの帯域幅を割り当ててMS14の帯域幅を確保する。第一に、処理230で、BSは、qosSetTypeを「許可」に設定して、且つ、最大維持可能レート(maxSusRate)を25kbpsに設定して、UL接続のDSA−REQメッセージを送信する。第二に、処理232で、WCCモジュール130は、CC=Succとして、この確保された帯域幅割り当てを受け付けるDSA−RSPメッセージで応答する。第三に、処理234で、BSは、qosSetTypeを「許可」に設定して、且つ、最大維持可能レート(maxSusRate)を25kbpsに設定して、DL接続のDSA−REQメッセージを送信する。第四に、処理236で、WCCモジュール130は、CC=Succとして、この確保された帯域幅割り当てを受け付けるDSA−RSPメッセージで応答する。
【0051】
図5および11を参照すると、図4のSIPプロキシモジュール134による呼セットアップフローが示されている。この発生している呼セットアップのシナリオは、図10で示したように許可状態142になったWCCモジュール130で開始される。最初の三つの処理240−244は、VoIP呼をセットアップするSIPプロトコルを記載する。第1の処理240では、発呼側のSIPエージェント132から被呼側のSIPエージェント158へSIP INVITEメッセージを送信してよい。第2の処理242で、SIP180呼信号を、被呼側のSIPエージェント158から、発呼側のSIPエージェント132へ送信してよい。第3の処理244では、被呼側のSIPエージェント158は、SIP200OK信号を、発呼側のSIPエージェント132に送信して、VoIP呼の構築を開始してよい。第4の処理246で、SIP200OK(被呼側のSIPエージェント158が呼に答える)に呼応して、発呼側のSIPエージェント132は、VoIP呼について帯域幅を要求するwccConnReqメッセージをMS14のWCCモジュール130に送信してよい。加えて、wccConnReqメッセージは、VoIPストリーミングをサービスフローにマッピングするべく以下のパラメータを含む:(a)バイト単位の全ビットレート、(b)ms単位の音声パケット期間、(c)バイト単位の音声パケットサイズ、(d)ソースIPアドレスおよびポート番号、および(e)宛先IPアドレスおよびポート番号。
【0052】
wccConnReqメッセージに呼応して、第5および第6の処理248および250で、WCCモジュール130は、UL/DL用にBS12にDSC−REQメッセージを、qosSetType=activeに設定されたパラメータとともに送信してよく、この後で、WCCモジュール130は、自身の起動待ち状態(WaitForActivation state)144に遷移してよい。より詳しくは、WCCモジュール130はDSC−REQメッセージを送信するときに、VoIP呼用にUL/DLサービスフローを起動するべく以下のパラメータを送信する:(a)サービスフローID(SFID)(ULまたはDL)、(b)QoSパラメータセットタイプ=「アクティブ」(これは、SFがアクティブであり、BS12がMS14に確保された帯域幅を承認することを示す)、および(d)以下の規則によりSSおよびBSのパケット分類器を構成して、VoIPパケットが適切な第2のサービスフローにルーティングできるようにする(パラメータの例には、IP宛先アドレス/ポートおよびサービス/区別化されたサービスコードポイント(DSCP)のIPタイプが含まれる)。DSC−REQメッセージの送信後、WCCモジュール130は自身の起動待ち状態148へ遷移してよい。
【0053】
第7の処理252で、BS12は、CC(Conformation Code)を成功(Succ)にセットして、ULのDSC−RSPメッセージに応答してよい。第8の処理254で、MS14のWCCモジュール130は、CCをSuccにセットして、ULのDSC−ACKを送信することで応答してよい。同様に、第9の処理256で、BS12は、CC=Succとして、DLのDSC−RSPメッセージで応答してよい。第10の処理258で、WCCモジュール130は、CCをSuccにセットして、DLのDSC−ACKを送信することで応答してよい。第11の処理260で、WCCモジュール130は、発呼側のSIPエージェント132に対して、サービスフローにおいて音声通信の準備が整った旨を伝えるwccConnRspメッセージを送信してよい。その後、WCCモジュール130は、アクティブ状態146に遷移してよい。その後、SIPプロトコルは呼を完了する。より具体的には、第12の処理262で、発呼側のSIPエージェント132は、被呼側のSIPエージェント158にSIP ACK信号を送信してよく、その後の264で音声接続が構築される。
【0054】
図5から12を参照すると、図5に示すMSトリガモードとともに図12に示す呼解除フローが示されている。第1の処理270で、被呼側のSIPエージェント158は、SIP BYEメッセージを、発呼側のSIPエージェント132に送信して、VoIP呼を解除してよい。第2の処理272で、発呼側のSIPエージェント132は、VoIP UL/DLサービスフローに対する接続を停止するべく、パラメータ(a)ソースIPアドレスおよびポート番号、(b)宛先IPアドレスおよびポート番号とともにwccDiscReqメッセージをMS14のWCCモジュール130に送信することで応答してよい。 第3および第4の処理274および276で、WCCモジュール130は、VoIP呼のUL/DLサービスフローの起動停止をするべく以下のパラメータとともにDSC−REQメッセージを送信することで、wccDiscReqメッセージに応答してよく、このパラメータとは以下の通りである:(a)SFID(ULまたはDL)、(b)QoSパラメータセットタイプ=許可(「許可」状態に変更することで、アクティブ呼がないことを示す)および(c)「分類器DSCアクション」パラメータをDSC削除分類器に設定する(先に呼に利用された分類器規則を削除する)パラメータ。DSC−REQメッセージの送信後、WCCモジュール130は、起動停止待ち状態(WaitForDeactivation State)148に遷移してよい。
【0055】
第5の処理278で、BS12は、CC=Succとして、ULのDSC−RSPメッセージを送信することで、ULのDSC−REQメッセージに応答してよい。第6の処理280で、WCCモジュール130は、CC=SuccとしてULのDSC−ACKメッセージを送信することで応答してよい。同様に、第7の処理282で、BS12は、CC=Succとして、DLのDSC−RSPメッセージを送信することで、DLのDSC−REQメッセージに応答してよい。第8の処理284で、WCCモジュール130は、CC=SuccとしてDLのDSC−ACKメッセージを送信することで応答してよい。第9の処理286で、WCCモジュール130は、発呼側のSIPエージェント132にwccDiscRspを送信して、SIPエージェント132に、サービスフローが起動停止された旨を通知してよい。その後、WCCモジュール130は、自身の許可状態142に遷移することで応答してよい。処理288で、SIPプロトコルは、発呼側のSIPエージェント132が、SIP200OK信号を、被呼側のSIPエージェント158に送信することで呼を解除してよく、これにより290で音声接続がティアダウンされる。
【0056】
図13を参照すると、WCCモジュール130を含む図5のMS14であってよいシステム310が示されている。MSの例は、大容量記憶デバイスを有するラップトップまたはUMDである。システムは、プロセッサ(集積回路チップ)312およびチップ312搭載用のICチップキャリア314を含んでよい。ICチップキャリア314は、ソケット318を介して基板またはプリント回路基板(PCB)316に搭載されてよい。しかし、他のシステムではICキャリア314がPCB316に直接連結されてもよい。PCB316は、メインメモリ320と、外部デバイスまたは外部バス用に複数の入出力(I/O)モジュールとを有してよく、これら全てが互いに、PCB316上のバスシステム322より連結される。システム310は、さらに、I/Oモジュール326を介してバスシステム322に連結される大容量記憶デバイス324を含んでよい。幾らかの実施形態では、さらなるI/Oモジュール328および330が、それぞれ他の外部または周辺I/Oデバイス332および334について含まれてよい。SIPエージェント132およびWCCモジュール130は、大容量記憶デバイス326からメモリ318に、プロセッサ312の実行を目的として移動させられるソフトウェアモジュールであってよい。呼セッションおよびWCCモジュールはソフトウェアモジュールとして示されているが、他の実施形態では、これらはハードワイヤであってよい。加えて、二段階呼制御手順はMS14に実装されているが、BS12に対してトランスペアレントであってもよい。故に、二段階呼制御手順を含めることで、BS12との相互運用性の問題を引き起こすことなくシステム310に対して付加価値を有するサービスを作成することができる。
【0057】
特定の実施形態を例示および記載してきたが、当業者であれば同じ目的を達成するよう図られた任意の配置で記載されている特定の実施形態を置き換えることができることを理解しよう。本願は、本発明の適用例または変形例をカバーすることを意図している。故に、本発明は請求項およびその均等物によってのみの限定が明白に意図されている。
【特許請求の範囲】
【請求項1】
許可制御モジュールと、前記許可制御モジュールと通信するデータパス機能モジュールとを有するサービスフロー管理モジュールを備える装置であって、
前記データパス機能モジュールは、アクティブ状態の第1のアップリンクサービスフローの第1の動的サービス追加要求メッセージ(DSA要求メッセージ)を生成して、VoIP(ボイス・オーバー・IP)シグナリングを提供し、
前記許可制御モジュールは、前記許可制御モジュールがVoIP呼に対して第2のアップリンクサービスフローをサポートできると判断すると、許可信号を生成し、
前記第1および前記第2のアップリンクサービスフローは、実質的にIEEE(米国電気電子学会)802.16規格に準拠しており、
前記データパス機能モジュールは、前記許可信号に呼応して、さらに、許可状態の前記第2のアップリンクサービスフローの第2のDSA要求メッセージを生成して、前記第2のDSA要求メッセージは、前記VoIP呼に確保された帯域幅を含む
装置。
【請求項2】
前記第2のアップリンクサービスフローは、自発的な承認サービスフロー、リアルタイムポーリングサービスフロー、および拡張リアルタイムポーリングサービスフローのうちから選択される
請求項1に記載の装置。
【請求項3】
前記第1のアップリンクサービスフローは、非リアルタイムポーリングサービスフローおよびベストエフォートサービスフローのうちから選択される
請求項2に記載の装置。
【請求項4】
前記第1および前記第2のアップリンクサービスフローは、それぞれ、前記サービスフローが確保されているが起動されていない前記許可状態、および、前記サービスフローが起動されている前記アクティブ状態にすることができ、
前記第1の動的サービス追加要求メッセージは、前記許可状態に前に設定されることなく前記アクティブ状態に設定された第1のセットタイプのパラメータを含み、
前記第2のDSA要求メッセージは、前記許可状態に設定された第2のセットタイプのパラメータを有する
請求項1に記載の装置。
【請求項5】
前記データパス機能モジュールは、さらに、前記第2のアップリンクサービスフローの利用データ記録を作成し、
前記利用データ記録は、前記第2のアップリンクサービスフローの期間および前記VoIP呼中にトランスポートされたバイト数を含む
請求項1に記載の装置。
【請求項6】
前記許可制御モジュールは、さらに、前記装置のセルにモバイルステーションが入ることに呼応して、前記第2のアップリンクサービスフローをサポートすることができるか否かの前記判断を開始する
請求項1に記載の装置。
【請求項7】
前記サービスフロー管理モジュールは、さらに、前記データパス機能モジュールと通信する接続制御モジュールを含み、
前記接続制御モジュールは、前記第2のDSA要求メッセージの受信に呼応して、DSA応答メッセージを前記データパス機能モジュールに送り、前記第2のアップリンクサービスフローの必要性を確認する
請求項1に記載の装置。
【請求項8】
前記接続制御モジュールは、前記VoIP呼の接続要求メッセージの受信に呼応して、さらに、前記データパス機能モジュールに動的サービス変更要求メッセージ(DSC要求メッセージ)を送信して、前記VoIP呼の前記第2のアップリンクサービスフローを起動する
請求項7に記載の装置。
【請求項9】
前記接続制御モジュールは、前記DSC要求メッセージの送信後に、さらに、前記データパス機能モジュールから、前記確保された帯域幅の起動を示すDSC応答メッセージを受信する
請求項8に記載の装置。
【請求項10】
前記サービスフロー管理モジュールは、さらに、呼セッションモジュールを含み、
前記呼セッションモジュールは前記接続制御モジュールと通信し、前記VoIP呼の前記接続要求メッセージを生成する
請求項9に記載の装置。
【請求項11】
前記呼セッションモジュールは、前記接続要求メッセージの生成後に、さらに、前記VoIP呼の接続停止要求メッセージを生成して、
前記接続制御モジュールは、前記接続停止要求メッセージに呼応して、さらに、前記データパス機能モジュールに、別のDSC要求メッセージを送信することで、先に起動された前記確保された帯域幅を起動停止して、前記データパス機能モジュールから、先に起動された前記確保された帯域幅の起動停止を示す別のDSC応答を受信する
請求項10に記載の装置。
【請求項12】
前記接続制御モジュールは、さらに、前記DSA応答メッセージを送信すると、初期化状態から許可状態に遷移して、
前記接続制御モジュールは、さらに、前記DSC要求メッセージを送信すると、前記許可状態から起動待ち状態へ遷移して、
前記接続制御モジュールは、さらに、前記DSC応答メッセージを受信すると、前記起動待ち状態からアクティブ状態に遷移して、
前記接続制御モジュールは、さらに、別のDSC要求メッセージを送信すると、前記アクティブ状態から起動停止待ち状態に遷移して、
前記接続制御モジュールは、さらに、前記別のDSC応答メッセージを受信すると、前記起動停止待ち状態から前記許可状態に遷移する
請求項11に記載の装置。
【請求項13】
VoIPシグナリング用にアクティブ状態の第1のアップリンクサービスフローを受信して、さらに、VoIP呼用に接続要求メッセージを生成する呼セッションモジュールと、
前記呼セッションモジュールに連結され、許可状態の第2のアップリンクサービスフロー用の動的サービス追加要求メッセージ(DSA要求メッセージ)を受信する接続制御モジュールと
を備え、
前記DSA要求メッセージは、確保された帯域幅を含み、
前記接続制御モジュールは、前記接続要求メッセージに呼応して、さらに、動的サービス変更要求メッセージ(DSC要求メッセージ)を送信して、前記第2のアップリンクサービスフローを起動して、
前記第1および前記第2のアップリンクサービスフローは、実質的にIEEE(米国電気電子学会)802.16規格に準拠している
装置。
【請求項14】
前記第2のアップリンクサービスフローは、自発的な承認サービスフロー、リアルタイムポーリングサービスフロー、および拡張リアルタイムポーリングサービスフローのうちから選択される
請求項13に記載の装置。
【請求項15】
前記第1のアップリンクサービスフローは、非リアルタイムポーリングサービスフローおよびベストエフォートサービスフローのうちから選択される
請求項14に記載の装置。
【請求項16】
前記第1および前記第2のアップリンクサービスフローは、それぞれ、前記サービスフローが確保されているが起動されていない前記許可状態、および、前記サービスフローが起動されている前記アクティブ状態にすることができ、
前記第1のアップリンクサービスフローは前記アクティブ状態にあり、前記第2のアップリンクサービスフローは前記許可状態にある
請求項13に記載の装置。
【請求項17】
前記接続制御モジュールは、前記DSA要求メッセージに呼応して、さらに、前記第2のアップリンクサービスフローの必要性を確認するDSA応答メッセージを送信して、
前記接続制御モジュールは、前記DSC要求メッセージの送信後に、さらに、前記第2のアップリンクサービスフローの起動を示すDSC応答メッセージを受信する
請求項13に記載の装置。
【請求項18】
前記呼セッションモジュールは、前記接続要求メッセージの生成後に、さらに、前記VoIP呼の接続停止要求メッセージを生成して、
前記接続制御モジュールは、前記接続停止要求メッセージに呼応して、さらに、別のDSC要求メッセージを送信することで、先に起動された前記確保された帯域幅を起動停止して、先に起動された前記確保された帯域幅の起動停止を示す別のDSC応答を受信する
請求項17に記載の装置。
【請求項19】
前記接続制御モジュールは、さらに、前記DSA応答メッセージの送信において、初期化状態から許可状態に遷移して、
前記接続制御モジュールは、さらに、前記DSC要求メッセージの送信において、前記許可状態から起動待ち状態へ遷移して、
前記接続制御モジュールは、さらに、前記DSC応答メッセージの受信において、前記起動待ち状態からアクティブ状態に遷移して、
前記接続制御モジュールは、さらに、前記別のDSC要求メッセージの送信において、前記アクティブ状態から起動停止待ち状態に遷移して、
前記接続制御モジュールは、さらに、前記別のDSC応答メッセージの受信において、前記起動停止待ち状態から前記許可状態に遷移する
請求項18に記載の装置。
【請求項20】
前記接続制御モジュールは、さらに、ベースステーションから前記DSA要求メッセージを受信して、前記ベースステーションに前記DSC要求メッセージを送信する
請求項12に記載の装置。
【請求項21】
ベースステーションのサービスフロー管理プログラムの命令を含む機械可読媒体を備える物品であって、前記サービスフロー管理プログラムがベースステーションに実行されると、前記ベースステーションに、
VoIPシグナリング用にアクティブ状態の第1のアップリンクサービスフローを提供させる段階と、
VoIP呼用に第2のアップリンクサービスフローをサポートできることを判断させる段階であって、前記第1のアップリンクサービスフローおよび前記第2のアップリンクサービスフローが実質的にIEEE(米国電気電子学会)802.16規格に準拠している段階と、
前記第2のアップリンクサービスフローをサポートできると判断すると、前記第2のアップリンクサービスフローに確保された帯域幅を確保させる段階と、
前記VoIP呼の接続要求メッセージに呼応して、前記第2のアップリンクサービスフローを起動させる段階とを含む処理を行わせる
物品。
【請求項22】
前記第2のアップリンクサービスフローは、自発的な承認サービスフロー、リアルタイムポーリングサービスフロー、および拡張リアルタイムポーリングサービスフローのうちから選択される
請求項21に記載の物品。
【請求項23】
前記第1のアップリンクサービスフローは、非リアルタイムポーリングサービスフローおよびベストエフォートサービスフローのうちから選択される
請求項22に記載の物品。
【請求項24】
前記処理は、さらに、前記第2のアップリンクサービスフローの利用データ記録を作成し、
前記利用データ記録は、前記第2のアップリンクサービスフローの期間および前記VoIP呼中にトランスポートされたバイト数を含む
請求項21に記載の物品。
【請求項25】
モバイルステーションシステムであって、
互いに連結されたメモリ、大容量記憶デバイス、およびプロセッサと、
互いに連結された呼セッションモジュールおよび接続制御モジュールと
を備え、
前記呼セッションモジュールおよび前記接続制御モジュールの各々は、前記大容量記憶デバイスに記憶されて、前記プロセッサにより前記メモリへ移動させられ、
前記プロセッサは前記呼セッションモジュールおよび前記接続制御モジュールを実行し、
前記呼セッションモジュールは、VoIPシグナリング用に、アクティブ状態の第1のアップリンクサービスフローを受信して、さらに、VoIP呼に接続要求メッセージを生成して、
前記接続制御モジュールは、許可状態の第2のアップリンクサービスフローの動的サービス追加要求メッセージ(DSA要求メッセージ)を受信して、前記DSA要求メッセージは、確保された帯域幅を含み、
前記接続制御モジュールは、前記接続要求メッセージに呼応して、さらに、動的サービス変更要求メッセージ(DSC要求メッセージ)を送信して、前記第2のアップリンクサービスフローを起動して、前記第1および前記第2のアップリンクサービスフローは、実質的にIEEE(米国電気電子学会)802.16規格に準拠している
モバイルステーションシステム。
【請求項26】
前記第2のアップリンクサービスフローは、自発的な承認サービスフロー、リアルタイムポーリングサービスフロー、および拡張リアルタイムポーリングサービスフローのうちから選択される
請求項25に記載のモバイルステーションシステム。
【請求項27】
前記第1のアップリンクサービスフローは、非リアルタイムポーリングサービスフローおよびベストエフォートサービスフローのうちから選択される
請求項26に記載のモバイルステーションシステム。
【請求項28】
前記第1および前記第2のアップリンクサービスフローは、それぞれ、前記サービスフローが確保されているが起動されていない許可状態、および、前記サービスフローが起動されているアクティブ状態にすることができ、
前記第1のアップリンクサービスフローは前記アクティブ状態にあり、前記第2のアップリンクサービスフローは前記許可状態にある
請求項27に記載のモバイルステーションシステム。
【請求項29】
前記接続制御モジュールは、前記DSA要求メッセージに呼応して、さらに、前記第2のアップリンクサービスフローの必要性を確認するDSA応答メッセージを送信して、
前記接続制御モジュールは、前記DSC要求メッセージの送信後に、さらに、前記第2のアップリンクサービスフローの起動を示すDSC応答メッセージを受信して、
前記呼セッションモジュールは、前記接続要求メッセージの生成後に、さらに、前記VoIP呼の接続停止要求メッセージを生成して、
前記接続制御モジュールは、前記接続停止要求メッセージに呼応して、さらに、別のDSC要求メッセージを送信することで、先に起動された前記確保された帯域幅を起動停止して、先に起動された前記確保された帯域幅の起動停止を示す別のDSC応答を受信する
請求項25に記載のモバイルステーションシステム。
【請求項30】
前記接続制御モジュールは、さらに、前記DSA応答メッセージを送信すると、初期化状態から許可状態に遷移して、
前記接続制御モジュールは、さらに、前記DSC要求メッセージを送信すると、前記許可状態から起動待ち状態へ遷移して、
前記接続制御モジュールは、さらに、前記DSC応答メッセージを受信すると、前記起動待ち状態からアクティブ状態に遷移して、
前記接続制御モジュールは、さらに、前記別のDSC要求メッセージを受信すると、前記アクティブ状態から起動停止待ち状態に遷移して、
前記接続制御モジュールは、さらに、前記別のDSC応答メッセージを受信すると、前記起動停止待ち状態から前記許可状態に遷移する
請求項29に記載のモバイルステーションシステム。
【請求項1】
許可制御モジュールと、前記許可制御モジュールと通信するデータパス機能モジュールとを有するサービスフロー管理モジュールを備える装置であって、
前記データパス機能モジュールは、アクティブ状態の第1のアップリンクサービスフローの第1の動的サービス追加要求メッセージ(DSA要求メッセージ)を生成して、VoIP(ボイス・オーバー・IP)シグナリングを提供し、
前記許可制御モジュールは、前記許可制御モジュールがVoIP呼に対して第2のアップリンクサービスフローをサポートできると判断すると、許可信号を生成し、
前記第1および前記第2のアップリンクサービスフローは、実質的にIEEE(米国電気電子学会)802.16規格に準拠しており、
前記データパス機能モジュールは、前記許可信号に呼応して、さらに、許可状態の前記第2のアップリンクサービスフローの第2のDSA要求メッセージを生成して、前記第2のDSA要求メッセージは、前記VoIP呼に確保された帯域幅を含む
装置。
【請求項2】
前記第2のアップリンクサービスフローは、自発的な承認サービスフロー、リアルタイムポーリングサービスフロー、および拡張リアルタイムポーリングサービスフローのうちから選択される
請求項1に記載の装置。
【請求項3】
前記第1のアップリンクサービスフローは、非リアルタイムポーリングサービスフローおよびベストエフォートサービスフローのうちから選択される
請求項2に記載の装置。
【請求項4】
前記第1および前記第2のアップリンクサービスフローは、それぞれ、前記サービスフローが確保されているが起動されていない前記許可状態、および、前記サービスフローが起動されている前記アクティブ状態にすることができ、
前記第1の動的サービス追加要求メッセージは、前記許可状態に前に設定されることなく前記アクティブ状態に設定された第1のセットタイプのパラメータを含み、
前記第2のDSA要求メッセージは、前記許可状態に設定された第2のセットタイプのパラメータを有する
請求項1に記載の装置。
【請求項5】
前記データパス機能モジュールは、さらに、前記第2のアップリンクサービスフローの利用データ記録を作成し、
前記利用データ記録は、前記第2のアップリンクサービスフローの期間および前記VoIP呼中にトランスポートされたバイト数を含む
請求項1に記載の装置。
【請求項6】
前記許可制御モジュールは、さらに、前記装置のセルにモバイルステーションが入ることに呼応して、前記第2のアップリンクサービスフローをサポートすることができるか否かの前記判断を開始する
請求項1に記載の装置。
【請求項7】
前記サービスフロー管理モジュールは、さらに、前記データパス機能モジュールと通信する接続制御モジュールを含み、
前記接続制御モジュールは、前記第2のDSA要求メッセージの受信に呼応して、DSA応答メッセージを前記データパス機能モジュールに送り、前記第2のアップリンクサービスフローの必要性を確認する
請求項1に記載の装置。
【請求項8】
前記接続制御モジュールは、前記VoIP呼の接続要求メッセージの受信に呼応して、さらに、前記データパス機能モジュールに動的サービス変更要求メッセージ(DSC要求メッセージ)を送信して、前記VoIP呼の前記第2のアップリンクサービスフローを起動する
請求項7に記載の装置。
【請求項9】
前記接続制御モジュールは、前記DSC要求メッセージの送信後に、さらに、前記データパス機能モジュールから、前記確保された帯域幅の起動を示すDSC応答メッセージを受信する
請求項8に記載の装置。
【請求項10】
前記サービスフロー管理モジュールは、さらに、呼セッションモジュールを含み、
前記呼セッションモジュールは前記接続制御モジュールと通信し、前記VoIP呼の前記接続要求メッセージを生成する
請求項9に記載の装置。
【請求項11】
前記呼セッションモジュールは、前記接続要求メッセージの生成後に、さらに、前記VoIP呼の接続停止要求メッセージを生成して、
前記接続制御モジュールは、前記接続停止要求メッセージに呼応して、さらに、前記データパス機能モジュールに、別のDSC要求メッセージを送信することで、先に起動された前記確保された帯域幅を起動停止して、前記データパス機能モジュールから、先に起動された前記確保された帯域幅の起動停止を示す別のDSC応答を受信する
請求項10に記載の装置。
【請求項12】
前記接続制御モジュールは、さらに、前記DSA応答メッセージを送信すると、初期化状態から許可状態に遷移して、
前記接続制御モジュールは、さらに、前記DSC要求メッセージを送信すると、前記許可状態から起動待ち状態へ遷移して、
前記接続制御モジュールは、さらに、前記DSC応答メッセージを受信すると、前記起動待ち状態からアクティブ状態に遷移して、
前記接続制御モジュールは、さらに、別のDSC要求メッセージを送信すると、前記アクティブ状態から起動停止待ち状態に遷移して、
前記接続制御モジュールは、さらに、前記別のDSC応答メッセージを受信すると、前記起動停止待ち状態から前記許可状態に遷移する
請求項11に記載の装置。
【請求項13】
VoIPシグナリング用にアクティブ状態の第1のアップリンクサービスフローを受信して、さらに、VoIP呼用に接続要求メッセージを生成する呼セッションモジュールと、
前記呼セッションモジュールに連結され、許可状態の第2のアップリンクサービスフロー用の動的サービス追加要求メッセージ(DSA要求メッセージ)を受信する接続制御モジュールと
を備え、
前記DSA要求メッセージは、確保された帯域幅を含み、
前記接続制御モジュールは、前記接続要求メッセージに呼応して、さらに、動的サービス変更要求メッセージ(DSC要求メッセージ)を送信して、前記第2のアップリンクサービスフローを起動して、
前記第1および前記第2のアップリンクサービスフローは、実質的にIEEE(米国電気電子学会)802.16規格に準拠している
装置。
【請求項14】
前記第2のアップリンクサービスフローは、自発的な承認サービスフロー、リアルタイムポーリングサービスフロー、および拡張リアルタイムポーリングサービスフローのうちから選択される
請求項13に記載の装置。
【請求項15】
前記第1のアップリンクサービスフローは、非リアルタイムポーリングサービスフローおよびベストエフォートサービスフローのうちから選択される
請求項14に記載の装置。
【請求項16】
前記第1および前記第2のアップリンクサービスフローは、それぞれ、前記サービスフローが確保されているが起動されていない前記許可状態、および、前記サービスフローが起動されている前記アクティブ状態にすることができ、
前記第1のアップリンクサービスフローは前記アクティブ状態にあり、前記第2のアップリンクサービスフローは前記許可状態にある
請求項13に記載の装置。
【請求項17】
前記接続制御モジュールは、前記DSA要求メッセージに呼応して、さらに、前記第2のアップリンクサービスフローの必要性を確認するDSA応答メッセージを送信して、
前記接続制御モジュールは、前記DSC要求メッセージの送信後に、さらに、前記第2のアップリンクサービスフローの起動を示すDSC応答メッセージを受信する
請求項13に記載の装置。
【請求項18】
前記呼セッションモジュールは、前記接続要求メッセージの生成後に、さらに、前記VoIP呼の接続停止要求メッセージを生成して、
前記接続制御モジュールは、前記接続停止要求メッセージに呼応して、さらに、別のDSC要求メッセージを送信することで、先に起動された前記確保された帯域幅を起動停止して、先に起動された前記確保された帯域幅の起動停止を示す別のDSC応答を受信する
請求項17に記載の装置。
【請求項19】
前記接続制御モジュールは、さらに、前記DSA応答メッセージの送信において、初期化状態から許可状態に遷移して、
前記接続制御モジュールは、さらに、前記DSC要求メッセージの送信において、前記許可状態から起動待ち状態へ遷移して、
前記接続制御モジュールは、さらに、前記DSC応答メッセージの受信において、前記起動待ち状態からアクティブ状態に遷移して、
前記接続制御モジュールは、さらに、前記別のDSC要求メッセージの送信において、前記アクティブ状態から起動停止待ち状態に遷移して、
前記接続制御モジュールは、さらに、前記別のDSC応答メッセージの受信において、前記起動停止待ち状態から前記許可状態に遷移する
請求項18に記載の装置。
【請求項20】
前記接続制御モジュールは、さらに、ベースステーションから前記DSA要求メッセージを受信して、前記ベースステーションに前記DSC要求メッセージを送信する
請求項12に記載の装置。
【請求項21】
ベースステーションのサービスフロー管理プログラムの命令を含む機械可読媒体を備える物品であって、前記サービスフロー管理プログラムがベースステーションに実行されると、前記ベースステーションに、
VoIPシグナリング用にアクティブ状態の第1のアップリンクサービスフローを提供させる段階と、
VoIP呼用に第2のアップリンクサービスフローをサポートできることを判断させる段階であって、前記第1のアップリンクサービスフローおよび前記第2のアップリンクサービスフローが実質的にIEEE(米国電気電子学会)802.16規格に準拠している段階と、
前記第2のアップリンクサービスフローをサポートできると判断すると、前記第2のアップリンクサービスフローに確保された帯域幅を確保させる段階と、
前記VoIP呼の接続要求メッセージに呼応して、前記第2のアップリンクサービスフローを起動させる段階とを含む処理を行わせる
物品。
【請求項22】
前記第2のアップリンクサービスフローは、自発的な承認サービスフロー、リアルタイムポーリングサービスフロー、および拡張リアルタイムポーリングサービスフローのうちから選択される
請求項21に記載の物品。
【請求項23】
前記第1のアップリンクサービスフローは、非リアルタイムポーリングサービスフローおよびベストエフォートサービスフローのうちから選択される
請求項22に記載の物品。
【請求項24】
前記処理は、さらに、前記第2のアップリンクサービスフローの利用データ記録を作成し、
前記利用データ記録は、前記第2のアップリンクサービスフローの期間および前記VoIP呼中にトランスポートされたバイト数を含む
請求項21に記載の物品。
【請求項25】
モバイルステーションシステムであって、
互いに連結されたメモリ、大容量記憶デバイス、およびプロセッサと、
互いに連結された呼セッションモジュールおよび接続制御モジュールと
を備え、
前記呼セッションモジュールおよび前記接続制御モジュールの各々は、前記大容量記憶デバイスに記憶されて、前記プロセッサにより前記メモリへ移動させられ、
前記プロセッサは前記呼セッションモジュールおよび前記接続制御モジュールを実行し、
前記呼セッションモジュールは、VoIPシグナリング用に、アクティブ状態の第1のアップリンクサービスフローを受信して、さらに、VoIP呼に接続要求メッセージを生成して、
前記接続制御モジュールは、許可状態の第2のアップリンクサービスフローの動的サービス追加要求メッセージ(DSA要求メッセージ)を受信して、前記DSA要求メッセージは、確保された帯域幅を含み、
前記接続制御モジュールは、前記接続要求メッセージに呼応して、さらに、動的サービス変更要求メッセージ(DSC要求メッセージ)を送信して、前記第2のアップリンクサービスフローを起動して、前記第1および前記第2のアップリンクサービスフローは、実質的にIEEE(米国電気電子学会)802.16規格に準拠している
モバイルステーションシステム。
【請求項26】
前記第2のアップリンクサービスフローは、自発的な承認サービスフロー、リアルタイムポーリングサービスフロー、および拡張リアルタイムポーリングサービスフローのうちから選択される
請求項25に記載のモバイルステーションシステム。
【請求項27】
前記第1のアップリンクサービスフローは、非リアルタイムポーリングサービスフローおよびベストエフォートサービスフローのうちから選択される
請求項26に記載のモバイルステーションシステム。
【請求項28】
前記第1および前記第2のアップリンクサービスフローは、それぞれ、前記サービスフローが確保されているが起動されていない許可状態、および、前記サービスフローが起動されているアクティブ状態にすることができ、
前記第1のアップリンクサービスフローは前記アクティブ状態にあり、前記第2のアップリンクサービスフローは前記許可状態にある
請求項27に記載のモバイルステーションシステム。
【請求項29】
前記接続制御モジュールは、前記DSA要求メッセージに呼応して、さらに、前記第2のアップリンクサービスフローの必要性を確認するDSA応答メッセージを送信して、
前記接続制御モジュールは、前記DSC要求メッセージの送信後に、さらに、前記第2のアップリンクサービスフローの起動を示すDSC応答メッセージを受信して、
前記呼セッションモジュールは、前記接続要求メッセージの生成後に、さらに、前記VoIP呼の接続停止要求メッセージを生成して、
前記接続制御モジュールは、前記接続停止要求メッセージに呼応して、さらに、別のDSC要求メッセージを送信することで、先に起動された前記確保された帯域幅を起動停止して、先に起動された前記確保された帯域幅の起動停止を示す別のDSC応答を受信する
請求項25に記載のモバイルステーションシステム。
【請求項30】
前記接続制御モジュールは、さらに、前記DSA応答メッセージを送信すると、初期化状態から許可状態に遷移して、
前記接続制御モジュールは、さらに、前記DSC要求メッセージを送信すると、前記許可状態から起動待ち状態へ遷移して、
前記接続制御モジュールは、さらに、前記DSC応答メッセージを受信すると、前記起動待ち状態からアクティブ状態に遷移して、
前記接続制御モジュールは、さらに、前記別のDSC要求メッセージを受信すると、前記アクティブ状態から起動停止待ち状態に遷移して、
前記接続制御モジュールは、さらに、前記別のDSC応答メッセージを受信すると、前記起動停止待ち状態から前記許可状態に遷移する
請求項29に記載のモバイルステーションシステム。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【公表番号】特表2010−530666(P2010−530666A)
【公表日】平成22年9月9日(2010.9.9)
【国際特許分類】
【出願番号】特願2010−511301(P2010−511301)
【出願日】平成20年6月4日(2008.6.4)
【国際出願番号】PCT/US2008/065795
【国際公開番号】WO2008/151244
【国際公開日】平成20年12月11日(2008.12.11)
【出願人】(591003943)インテル・コーポレーション (1,101)
【Fターム(参考)】
【公表日】平成22年9月9日(2010.9.9)
【国際特許分類】
【出願日】平成20年6月4日(2008.6.4)
【国際出願番号】PCT/US2008/065795
【国際公開番号】WO2008/151244
【国際公開日】平成20年12月11日(2008.12.11)
【出願人】(591003943)インテル・コーポレーション (1,101)
【Fターム(参考)】
[ Back to top ]