JP6423439B2 - ＷｅｂＲＴＣマルチメディアクライアントアプリケーションの代わりにクライアントに基づくＷｅｂＲＴＣプロキシによる選択的な到着するＷｅｂＲＴＣトラフィックの多重化および／または出て行くＷｅｂＲＴＣトラフィックの多重分離 - Google Patents

ＷｅｂＲＴＣマルチメディアクライアントアプリケーションの代わりにクライアントに基づくＷｅｂＲＴＣプロキシによる選択的な到着するＷｅｂＲＴＣトラフィックの多重化および／または出て行くＷｅｂＲＴＣトラフィックの多重分離 Download PDF

Info

Publication number
JP6423439B2
JP6423439B2 JP2016542845A JP2016542845A JP6423439B2 JP 6423439 B2 JP6423439 B2 JP 6423439B2 JP 2016542845 A JP2016542845 A JP 2016542845A JP 2016542845 A JP2016542845 A JP 2016542845A JP 6423439 B2 JP6423439 B2 JP 6423439B2
Authority
JP
Japan
Prior art keywords
webrtc
links
qos
link
stream
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2016542845A
Other languages
English (en)
Other versions
JP2016537920A5 (ja
JP2016537920A (ja
Inventor
ギリダハール・ダハティ・マンディヤム
ヴィジャイ・アーナンドラーオ・スリャヴァンシ
キランクマール・ボジャ・アンチャン
Original Assignee
クアルコム，インコーポレイテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by クアルコム，インコーポレイテッド filed Critical クアルコム，インコーポレイテッド
Publication of JP2016537920A publication Critical patent/JP2016537920A/ja
Publication of JP2016537920A5 publication Critical patent/JP2016537920A5/ja
Application granted granted Critical
Publication of JP6423439B2 publication Critical patent/JP6423439B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H04L65/403—Arrangements for multi-party communication, e.g. for conferences
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/256—NAT traversal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1045—Proxies, e.g. for session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1108—Web based protocols, e.g. webRTC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H04L65/403—Arrangements for multi-party communication, e.g. for conferences
    • H04L65/4038—Arrangements for multi-party communication, e.g. for conferences with floor control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H04L65/4061—Push-to services, e.g. push-to-talk or push-to-video
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/50—Allocation or scheduling criteria for wireless resources
    • H04W72/54—Allocation or scheduling criteria for wireless resources based on quality criteria
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0252—Traffic management, e.g. flow control or congestion control per individual bearer or channel
    • H04W28/0257—Traffic management, e.g. flow control or congestion control per individual bearer or channel the individual bearer or channel having a maximum bit rate or a bit rate guarantee

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Quality & Reliability (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

米国特許法第119条に基づく優先権の主張
本特許出願は、本出願の譲受人に譲渡され、参照によりその全体が本明細書に明示的に組み込まれている、対象の出願と同じ発明者による、2013年9月16日に出願した「SELECTIVELY MULTPLEXING INCOMING WEBRTC TRAFFIC AND/OR DE-MULTIPLEXING OUTGOING WEBRTC TRAFFIC BY A CLIENT-BASED WEBRTC PROXY ON BEHALF OF A WEBRTC MULTIMEDIA CLIENT APPLICATION」と題された仮出願第61/878,510号の優先権を主張するものである。
本発明の実施形態は、ウェブリアルタイム通信(WebRTC)マルチメディアクライアントアプリケーションの代わりにクライアントに基づくWebRTCプロキシによる選択的な到着するWebRTCトラフィックの多重化および/または出て行くWebRTCトラフィックの多重分離に関する。
ワイヤレス通信システムは、第1世代アナログワイヤレス電話サービス(1G)、(暫定的な2.5Gおよび2.75Gネットワークを含む)第2世代(2G)デジタルワイヤレス電話サービス、ならびに第3世代(3G)および第4世代(4G)高速データ/インターネット対応ワイヤレスサービスを含む様々な世代を通じて発展してきた。セルラーおよびパーソナル通信サービス(PCS: Personal Communications Service)システムを含む、使用されている多くの異なるタイプのワイヤレス通信システムが、現在存在する。知られているセルラーシステムの例は、セルラーアナログ高度モバイル電話システム(AMPS: Advanced Mobile Phone System)、ならびに符号分割多元接続(CDMA)、周波数分割多元接続(FDMA)、時分割多元接続(TDMA)、TDMAの移動体通信用グローバルシステム(GSM（登録商標）: Global System for Mobile access)のバリエーション、およびTDMA技術とCDMA技術との両方を用いるより新しいハイブリッドデジタル通信システムに基づくデジタル移動通信方法を含む。
より最近では、ロングタームエボリューション(LTE)が、モバイル電話およびその他のデータ端末のための高速なデータのワイヤレス通信のためのワイヤレス通信プロトコルとして開発された。LTEは、GSM（登録商標）に基づき、GSM（登録商標）の進化のための高速化されたデータレート(EDGE: Enhanced Data rates for GSM（登録商標） Evolution)などの様々なGSM（登録商標）に関連するプロトコルおよび高速パケットアクセス(HSPA: High-Speed Packet Access)などのユニバーサル移動体通信システム(UMTS: Universal Mobile Telecommunications System)プロトコルからの寄与を含む。
ワールドワイドウェブコンソーシアム(W3C)は、インターネット技術タスクフォース(IETF: Internet Engineering Task Force)と一緒に、ウェブリアルタイム通信(WebRTC)と呼ばれるウェブ開発者の技術の開発を2011年に開始した。WebRTCは、ブラウザ(またはエンドポイント)がエンドポイントの相対的な位置とは無関係に(たとえば、それぞれのエンドポイントが同じデバイス上にあるか、同じプライベートネットワーク内にあるか、両方とも別々のネットワークアドレス変換(NAT)および/またはファイアウォールの裏にあるかなどに関わりなく)1つまたは複数のその他のエンドポイントとのピアツーピア(P2P)リアルタイム通信に参加することを許すプロトコルである。
WebRTCは、リアルタイムメディアの送信のためにリアルタイムトランスポートプロトコル(RTP)を利用する。RTPは、多くの異なるメディアタイプのためのトランスポートプロトコルとして働くことができる柔軟なプロトコルである。これらのメディアタイプは、オーディオもしくはビデオにマッピングされるように広く分類される可能性があり、または関連するオーディオもしくはビデオコーデック、帯域幅の要件、オーディオもしくはビデオ解像度などの情報を指定することによってより詳細である可能性がある。さらに、メッシュ会議モデル(mesh conferencing model)においては、複数のメディアストリームが、クライアントに基づくオーディオミキシングまたはビデオ合成を可能にするためにP2Pで送信される可能性がある。
WebRTCによって通信するエンドポイントはそれぞれのエンドポイントの間のエンドツーエンド接続の数を制限する1つまたは複数のNATおよび/またはファイアウォールによって分けられる可能性があるので、WebRTCは、単一のIPアドレスおよびポートを通じたRTPストリームの多重化を許す。この制限が1つの原因になって、既存のWebRTCの仕様は、多重化がRTPおよびRTP制御プロトコル(RTCP)通信のために使用されることを推奨する。複数のタイプのストリームが1つのIPアドレスおよびポートを通じて多重化されるとき、異なるタイプのメディアに区別されたサービス品質(QoS)を提供することは、より困難になる。
3GPP TS 23.203
一実施形態において、第1のUE上の第1のWebRTCプロキシモジュールが、第1のUE上の第1のWebRTCマルチメディアクライアントアプリケーションから多重化されたストリームを受信する。第1のWebRTCプロキシモジュールは、少なくとも第1のおよび第2の多重分離されたストリームに多重分離する。第1のWebRTCプロキシモジュールは、QoSを用いるリンクの第1の組を介して第2のUE上の第2のWebRTCプロキシモジュールに第1の多重分離されたストリームを送信し、リンクの第2の組で第2のWebRTCプロキシモジュールに第2の多重分離されたストリームを送信する。第2のWebRTCプロキシモジュールは、第1のおよび第2の多重分離されたストリームを再多重化して、多重化されたストリームの元のバージョンかまたは圧縮されたバージョンかのどちらを取得し、それから、再多重化されたストリームを第2のUE上の第2のWebRTCマルチメディアクライアントアプリケーションに届ける。
本発明の実施形態およびそれに付随する利点の多くのより完全な理解は、本発明の限定ではなく例示のためにだけ示される添付の図面に関連して考慮されるときに下の詳細な説明を参照することによって本発明の実施形態およびそれに付随する利点の多くがより深く理解されるようになるときに容易に得られるであろう。
本発明の実施形態によるワイヤレス通信システムの高レベルのシステムアーキテクチャを示す図である。 本発明の実施形態による1x EV-DOネットワークに関する無線アクセスネットワーク(RAN)およびコアネットワークのパケット交換部分の例示的な構成を示す図である。 本発明の実施形態による3G UMTS W-CDMAシステム内のRANおよび汎用パケット無線サービス(GPRS)コアネットワークのパケット交換部分の例示的な構成を示す図である。 本発明の実施形態による3G UMTS W-CDMAシステム内のRANおよびGPRSコアネットワークのパケット交換部分の別の例示的な構成を示す図である。 本発明の実施形態によるRANおよび進化型パケットシステム(EPS: Evolved Packet System)またはロングタームエボリューション(LTE)ネットワークに基づくコアネットワークのパケット交換部分の例示的な構成を示す図である。 本発明の実施形態によるEPSまたはLTEネットワークに接続された強化された高レートパケットデータ(HRPD: High Rate Packet Data)RANおよびさらにHRPDコアネットワークのパケット交換部分の例示的な構成を示す図である。 本発明の実施形態によるユーザ機器(UE)の例を示す図である。 本発明の実施形態による機能を実行するように構成された論理を含む通信デバイスを示す図である。 本発明の実施形態によるクライアントアプリケーションにより開始される方向性を持ったQoS管理手順のより詳細な実施の例を示す図である。 本発明の実施形態による、図2Aと同様の1x EV-DOネットワーク(レガシーHRPD)または図2Eと同様のeHRPDによってサービスを提供されながら半二重PTTセッションに加わる所与のUEに関する図5のプロセスの例示的な実施を示す図である。 本発明の実施形態による、図2Bまたは図2Cと同様のW-CDMAネットワークによってサービスを提供されながら半二重PTTセッションに加わる所与のUEのための図5のプロセスの例示的な実施を示す図である。 本発明の実施形態による、図2Dと同様のLTEネットワークによってサービスを提供されながら半二重PTTセッションを始める所与のUEに関する図5のプロセスの例示的な実施を示す図である。 本発明の実施形態による、図5と同様であるが、UEのクライアントアプリケーションの代わりにアプリケーションサーバ170において実施される選択的なQoS制御手順を対象とする図である。 本発明の実施形態による、図5と同様であるが、UEのクライアントアプリケーションの代わりにアプリケーションサーバ170において実施される選択的なQoS制御手順を対象とする図である。 本発明の実施形態による半二重PTTセッションに加わる所与のUE(呼の発信側かまたは呼の着信側かのどちらか)に関するLTEネットワーク内での図7Bの例示的な実施を示す図である。 本発明の実施形態によるコアネットワークにより開始される方向性を持ったQoS管理手順のより詳細な実施の例を示す図である。 本発明の実施形態による、それぞれ、LTEに固有のおよびW-CDMAに固有の構成要素およびメッセージがより明示的に参照される図8Aのより一層詳細な実施を示す図である。 本発明の実施形態による何らかのその他のUEによって開始された半二重PTTセッションの呼の着信側である所与のUEに関するW-CDMAネットワーク内での図8Bの例示的な実施を示す図である。 本発明の実施形態による半二重PTTセッションの呼の発信側である所与のUEに関するLTEネットワーク内での図8Bの例示的な実施を示す図である。 本発明の実施形態による、GBRリソースがRANおよびコアネットワークのローカルで管理されるQoS管理手順を示す図である。 本発明の実施形態による、それぞれ、LTEに固有の構成要素およびメッセージがより明示的に参照される図9Aのより一層詳細な実施を示す図である。 本発明の実施形態によるW-CDMAアーキテクチャに関連するRANにより開始されるタイマーに基づく方向性を持ったQoSフロー管理手順を示す図である。 本発明の実施形態によるEV-DOアーキテクチャに関連するRANにより開始されるタイマーに基づく方向性を持ったQoSフロー管理手順を示す図である。 2つのUEの間のウェブリアルタイム通信(WebRTC)セッションに関するトラフィックの通常のフローを示す図である。 本発明の実施形態による同じサービングネットワークによってサービスを提供される2つのUEの間のWebRTCセッションに関するトラフィックのフローを示す図である。 本発明の実施形態による異なるサービングネットワークによってサービスを提供される2つのUEの間のWebRTCセッションに関するトラフィックのフローを示す図である。 本発明の実施形態による、WebRTCセッションに関するQoSリンクを設定し、その後に、WebRTCセッションの発信側のUEにおいて多重分離を行うプロセスを示す図である。 本発明の実施形態によるUEにより開始されるWebRTCセッションに関するサーバに基づくNWにより開始されるQoS手順に基づく図13のプロセスのLTEに固有の実施を示す図である。 本発明の実施形態によるUEにより開始されるQoS手順に基づく図13のプロセスのLTEに固有の実施を示す図である。 本発明の実施形態による別のNWにより開始されるQoS手順に基づく図13のプロセスの一部の例示的な実施を示す図である。 本発明の実施形態による、WebRTCセッションに関するQoSリンクを設定し、その後に、WebRTCセッションの着信側のUEにおいて再多重化を行う高レベルのプロセスを対象とする図である。
本発明の態様が、本発明の特定の実施形態を対象とする以下の説明および関連する図面において開示される。代替的な実施形態が、本発明の範囲を逸脱することなく案出され得る。加えて、本発明のよく知られている要素は、本発明の重要な詳細を曖昧にしないように詳細に示されないかまたは省略される。
語「例示的な」および/または「例」は、本明細書においては「例、具体例、または事例としての役割を果たす」ことを表すために使用される。本明細書において「例示的」および/または「例」と記載されたいずれの実施形態も、必ずしもその他の実施形態よりも好ましいかまたは有利であると解釈されるべきではない。同様に、「本発明の実施形態」という用語は、本発明のすべての実施形態が検討される特徴、利点、または動作のモードを含むことを必要としない。
さらに、多くの実施形態が、たとえば、コンピューティングデバイスの要素によって実行される一連の行為によって説明される。本明細書において説明される様々な行為が特定の回路(たとえば、特定用途向け集積回路(ASIC))、1つもしくは複数のプロセッサによって実行されるプログラム命令、またはこれら両方の組合せによって実行され得ることは、認められるであろう。加えて、本明細書において説明されるこれらの一連の行為は、実行されると関連するプロセッサに本明細書において説明される機能を実行させるコンピュータ命令の対応する組を記憶する任意の形態のコンピュータ可読ストレージ媒体内に完全に具現化されると考えられ得る。したがって、本発明の様々な態様は、いくつかの異なる形態で具現化される可能性があり、それらの異なる形態のすべては、特許請求の対象の範囲内にあると考えられた。さらに、本明細書において説明される実施形態の各々に関して、対応する形態の任意のそのような実施形態は、たとえば、説明される行為を実行する「ように構成された論理」として本明細書において説明される可能性がある。
本明細書においてユーザ機器(UE)と呼ばれるクライアントデバイスは、モバイルであるかまたは固定である可能性があり、無線アクセスネットワーク(RAN)と通信し得る。本明細書において使用されるとき、「UE」という用語は、「アクセス端末」または「AT」、「ワイヤレスデバイス」、「加入者デバイス」、「加入者端末」、「加入者局」、「ユーザ端末」またはUT、「モバイル端末」、「移動局」、およびこれらの変化形と交換可能なように呼ばれる可能性がある。概して、UEは、RANを介してコアネットワークと通信することができ、コアネットワークを通じて、UEは、インターネットなどの外部ネットワークに接続され得る。もちろん、有線アクセスネットワーク、(たとえば、IEEE 802.11などに基づく)WiFiネットワークなどを介するなど、UEのために、コアネットワークおよび/またはインターネットに接続するその他のメカニズムもあり得る。UEは、PCカード、コンパクトフラッシュ（登録商標）デバイス、外付けまたは内蔵モデム、ワイヤレスまたは有線電話などを含むがこれらに限定されないいくつかのタイプのデバイスのいずれかによって具現化され得る。UEがRANに信号を送信することができる通信リンクは、アップリンクチャネル(たとえば、逆方向トラフィックチャネル、逆方向制御チャネル、アクセスチャネルなど)と呼ばれる。RANがUEに信号を送信することができる通信リンクは、ダウンリンクまたは順方向リンクチャネル(たとえば、ページングチャネル、制御チャネル、ブロードキャストチャネル、順方向トラフィックチャネルなど)と呼ばれる。本明細書において使用されるとき、トラフィックチャネル(TCH)という用語は、アップリンク/逆方向かまたはダウンリンク/順方向かのどちらかのトラフィックチャネルを指す可能性がある。
図1は、本発明の実施形態によるワイヤレス通信システム100の高レベルのシステムアーキテクチャを示す。ワイヤレス通信システム100は、UE 1...Nを含む。UE 1...Nは、セルラー電話、携帯情報端末(PDA)、ページャ、ラップトップコンピュータ、デスクトップコンピュータなどを含み得る。たとえば、図1において、UE 1...2は、セルラー通話電話として示されており、UE 3...5は、セルラータッチスクリーン電話またはスマートフォンとして示されており、UE Nは、デスクトップコンピュータまたはPCとして示されている。
図1を参照すると、UE 1...Nは、図1において無線インターフェース104、106、108および/または直接有線接続として示される物理的な通信インターフェースまたはレイヤを介してアクセスネットワーク(たとえば、RAN 120、アクセスポイント125など)と通信するように構成される。無線インターフェース104および106は、所与のセルラー通信プロトコル(たとえば、CDMA、EVDO、eHRPD、GSM（登録商標）、EDGE、W-CDMA、LTEなど)に準拠する可能性があり、一方、無線インターフェース108は、ワイヤレスIPプロトコル(たとえば、IEEE 802.11)に準拠する可能性がある。RAN 120は、無線インターフェース104および106などの無線インターフェースを介してUEにサービスを提供する複数のアクセスポイントを含む。RAN 120のアクセスポイントは、アクセスノードまたはAN、アクセスポイントまたはAP、基地局またはBS、NodeB、eNodeBなどと呼ばれる可能性がある。これらのアクセスポイントは、地上アクセスポイント(もしくは地上局)または衛星アクセスポイントである可能性がある。RAN 120は、RAN 120によってサービスを提供されるUEとRAN 120または異なるRAN全体によってサービスを提供されるその他のUEとの間の回線交換(CS)の呼をブリッジすることを含む様々な機能を実行することができ、インターネット175などの外部ネットワークとのパケット交換(PS)データのやりとりを仲介することもできるコアネットワーク140に接続するように構成される。インターネット175は、(図1には便宜上示されていない)いくつかのルーティングエージェントおよび処理エージェントを含む。図1において、UE Nは、インターネット175に直接接続するものとして示される(つまり、WiFiまたは802.11に基づくネットワークのイーサネット（登録商標）接続を介するなど、コアネットワーク140とは分かれている)。それによって、インターネット175は、コアネットワーク140を介してUE NとUE 1...Nと間のパケット交換データ通信をブリッジするように機能することができる。やはり図1に示されるのは、RAN 120と分かれているアクセスポイント125である。アクセスポイント125は、(たとえば、FiOS、ケーブルモデムなどの光通信システムを介して)コアネットワーク140とは独立してインターネット175に接続され得る。無線インターフェース108は、一例においては、IEEE 802.11などのローカルワイヤレス接続を介してUE 4またはUE 5にサービスを提供する可能性がある。UE Nは、モデムまたはルータへの直接接続などのインターネット175への有線接続を有するデスクトップコンピュータとして示され、モデムまたはルータは、一例においては、(たとえば、有線接続性とワイヤレス接続性との両方を有するWiFiルータの)アクセスポイント125自体に対応する可能性がある。
図1を参照すると、アプリケーションサーバ170が、インターネット175、コアネットワーク140、またはこれら両方に接続されるものとして示される。アプリケーションサーバ170は、複数の構造的に別々のサーバとして実装される可能性があり、または代替的に、単一のサーバに対応する可能性がある。下でより詳細に説明されるように、アプリケーションサーバ170は、コアネットワーク140および/またはインターネット175を介してアプリケーションサーバ170に接続することができるUEに関する1つまたは複数の通信サービス(たとえば、ボイスオーバーインターネットプロトコル(VoIP)セッション、プッシュツートーク(PTT)セッション、グループ通信セッション、ソーシャルネットワーキングサービスなど)をサポートするように構成される。
RAN 120およびコアネットワーク140に関するプロトコルに固有の実装の例が、ワイヤレス通信システム100をより詳細に説明するのを助けるために図2Aから図2Dまでに関連して下で与えられる。特に、RAN 120およびコアネットワーク140の構成要素はパケット交換(PS)通信をサポートすることに関連する構成要素に対応し、それによって、レガシーの回線交換(CS)構成要素もこれらのネットワークに存在し得るが、いかなるレガシーのCSに固有の構成要素も図2A〜図2Dに明示的に示されない。
図2Aは、本発明の実施形態によるCDMA2000 1xエボリューションデータオプティマイズド(EV-DO: Evolution-Data Optimized)ネットワークにおけるパケット交換通信のためのRAN 120およびコアネットワーク140の例示的な構成を示す。図2Aを参照すると、RAN 120は、有線のバックホールインターフェースを介して基地局コントローラ(BSC)215Aに結合される複数の基地局(BS)200A、205A、および210Aを含む。単一のBSCによって制御されるBSのグループは、集合的にサブネットと呼ばれる。当業者に理解されるであろうように、RAN 120は複数のBSCおよびサブネットを含む可能性があり、図2Aにおいては、便宜的に単一のBSCが示される。BSC 215Aは、A9接続を介してコアネットワーク140内のパケット制御機能(PCF: packet control function)220Aと通信する。PCF 220Aは、パケットデータに関連するBSC 215Aのための特定の処理機能を実行する。PCF 220Aは、A11接続を介してコアネットワーク140内のパケットデータサービングノード(PDSN)225Aと通信する。PDSN 225Aは、ポイントツーポイント(PPP)セッションを管理すること、ホームエージェント(HA)および/または外部エージェント(FA: foreign agent)として働くことを含む様々な機能を有し、(下でより詳細に説明される)GSM（登録商標）およびUMTSネットワークのゲートウェイ汎用パケット無線サービス(GPRS)サポートノード(GGSN)と機能的に同様である。PDSN 225Aは、コアネットワーク140をインターネット175などの外部IPネットワークに接続する。
図2Bは、本発明の実施形態による3G UMTS W-CDMAシステム内のRAN 120およびGPRSコアネットワークとして構成されるコアネットワーク140のパケット交換部分の例示的な構成を示す。図2Bを参照すると、RAN 120は、有線のバックホールインターフェースを介して無線ネットワークコントローラ(RNC)215Bに結合される複数のNodeB 200B、205B、および210Bを含む。1x EV-DOネットワークと同様に、単一のRNCによって制御されるNodeBのグループは、集合的にサブネットと呼ばれる。当業者に理解されるであろうように、RAN 120は複数のRNCおよびサブネットを含む可能性があり、図2Bにおいては、便宜的に単一のRNCが示される。RNC 215Bは、コアネットワーク140のサービングGPRSサポートノード(SGSN)220BとRAN 120によってサービスを提供されるUEとの間のシグナリング、ベアラチャネル(すなわち、データチャネル)の確立および破棄を行う役割を担う。リンクレイヤの暗号化が有効化される場合、RNC 215Bは、さらに、無線インターフェースを介した送信のために、コンテンツをRAN 120に転送する前にそのコンテンツを暗号化する。RNC 215Bの機能は、当技術分野でよく知られており、簡潔にするためにさらに検討されない。
図2Bにおいて、コアネットワーク140は、上述のSGSN 220B(およびさらに潜在的にいくつかのその他のSGSN)ならびにGGSN 225Bを含む。概して、GPRSは、IPパケットをルーティングするためにGSM（登録商標）において使用されるプロトコルである。GPRSコアネットワーク(たとえば、GGSN 225Bおよび1つまたは複数のSGSN 220B)は、GPRSシステムの集中化された部分であり、さらに、W-CDMAに基づく3Gアクセスネットワークに関するサポートを提供する。GPRSコアネットワークは、GSM（登録商標）およびW-CDMAネットワークにおいてIPパケットサービスのためのモビリティ管理、セッション管理、および転送を提供するGSM（登録商標）コアネットワーク(すなわち、コアネットワーク140)の統合された部分である。
GPRSトンネリングプロトコル(GTP)は、GPRSコアネットワークの定義に用いるIPプロトコルである。GTPは、GSM（登録商標）またはW-CDMAネットワークのエンドユーザ(たとえば、UE)があたかもGGSN 225Bの1つの位置からであるかのようにインターネット175に接続し続けながらあちこち移動することを可能にするプロトコルである。これは、それぞれのUEのデータをUEの現在のSGSN 220BからそれぞれのUEのセッションを扱っているGGSN 225Bに転送することによって実現される。
GTPの3つの形態、すなわち、(i)GTP-U、(ii)GTP-C、および(iii)GTP'(GTPプライム)が、GPRSコアネットワークによって使用される。GTP-Uは、それぞれのパケットデータプロトコル(PDP)コンテキストのための分けられたトンネルにおけるユーザデータの転送のために使用される。GTP-Cは、制御シグナリング(たとえば、PDPコンテキストの設定および削除、GSNの到達可能性の検証、加入者が1つのSGSNから別のSGSNに移動するときなどの更新または修正など)のために使用される。GTP'は、GSNから課金機能への課金データの転送のために使用される。
図2Bを参照すると、GGSN 225Bは、GPRS基幹ネットワーク(図示せず)とインターネット175との間のインターフェースとして働く。GGSN 225Bは、SGSN 220Bから来るGPRSパケットからパケットデータプロトコル(PDP)フォーマット(たとえば、IPまたはPPP)に関連するパケットデータを抽出し、対応するパケットデータネットワークでパケットを送出する。反対方向で、到着するデータパケットは、UEに接続されたGGSNによって、RAN 120によってサービスを提供される着信側のUEの無線アクセスベアラ(RAB: Radio Access Bearer)を管理し、制御するSGSN 220Bに向けられる。それによって、GGSN 225Bは、着信側のUEの現在のSGSNアドレスおよびその着信側のUEの関連するプロファイルを(たとえば、PDPコンテキストないの)位置レジスタに記憶する。GGSN 225Bは、IPアドレスを割り振る役割を担い、接続されたUEのためのデフォルトルータである。GGSN 225Bは、認証および課金機能も実行する。
SGSN 220Bは、一例において、コアネットワーク140内の多くのSGSNのうちの1つを表す。各SGSNは、関連する地理的サービスエリア内のUEからおよびUEにデータパケットを配信する役割を担う。SGSN 220Bのタスクは、パケットのルーティングおよび転送、モビリティ管理(たとえば、アタッチ/デタッチおよび位置管理)、論理リンク管理、ならびに認証および課金機能を含む。SGSN 220Bの位置レジスタは、たとえば、各ユーザまたはUEに関する1つまたは複数のPDPコンテキスト内に、SGSN 220Bに登録されたすべてのGPRSユーザの位置情報(たとえば、現在のセル、現在のVLR)およびユーザプロファイル(たとえば、IMSI、パケットデータネットワークにおいて使用されるPDPアドレス)を記憶する。したがって、SGSN 220Bは、(i)GGSN 225BからのダウンリンクGTPパケットのトンネリングを解除し、(ii)GGSN 225BへのIPパケットのアップリンクのトンネリングを行い、(iii)UEがSGSNのサービスエリアの間を移動するときにモビリティ管理を行い、(iv)モバイル加入者に料金請求を行う役割を担う。当業者によって理解されるであろうように、(i)〜(iv)の他に、GSM（登録商標）/EDGEネットワークのために構成されたSGSNは、W-CDMAネットワークのために構成されたSGSNと比較してわずかに異なる機能を有する。
RAN 120(たとえば、またはUMTSシステムのアーキテクチャのUTRAN)は、無線アクセスネットワークアプリケーション部(RANAP: Radio Access Network Application Part)プロトコルによってSGSN 220Bと通信する。RANAPは、フレームリレーまたはIPなどの伝送プロトコルによってIuインターフェース(Iu-ps)上で動作する。SGSN 220Bは、SGSN 220Bとその他のSGSN(図示せず)および内部のGGSN(図示せず)との間のIPに基づくインターフェースであり、上で定義されたGTPプロトコル(たとえば、GTP-U、GTP-C、GTP'など)を用いるGnインターフェースを介してGGSN 225Bと通信する。図2Bの実施形態において、SGSN 220BとGGSN 225Bとの間のGnは、GTP-CとGTP-Uとの両方を運ぶ。図2Bに示されていないが、Gnインターフェースは、ドメインネームシステム(DNS)によっても使用される。GGSN 225Bは、直接かまたはワイヤレスアプリケーションプロトコル(WAP)ゲートウェイを通じてIPプロトコルを用いるGiインターフェースを介して公衆データネットワーク(PDN)(図示せず)に接続され、ひいてはインターネット175に接続される。
図2Cは、本発明の実施形態による3G UMTS W-CDMAシステム内のRAN 120およびGPRSコアネットワークとして構成されるコアネットワーク140のパケット交換部分の別の例示的な構成を示す。図2Bと同様に、コアネットワーク140は、SGSN 220BおよびGGSN 225Bを含む。しかし、図2Cにおいては、ダイレクトトンネル(Direct Tunnel)は、SGSN 220BがPSドメイン内のRAN 120とGGSN 225Bとの間の直接的なユーザプレーンのトンネルGTP-Uを確立することを可能にするIuモードの任意の機能である。図2CのSGSN 220Bなどのダイレクトトンネルに対応したSGSNは、SGSN 220Bが直接的なユーザプレーンの接続を使用することができるか否かに関わりなくGGSごとおよびRNCごとに構成され得る。図2CのSGSN 220Bは、制御プレーンのシグナリングを扱い、ダイレクトトンネルをいつ確立すべきかを判断する。PDPコンテキストのために割り振られたRABが解放される(つまり、PDPコンテキストが保存される)とき、ダウンリンクパケットを扱うことができるようにGGSN 225BとSGSN 220Bとの間でGTP-Uトンネルが確立される。
図2Dは、本発明の実施形態によるRAN 120および進化型パケットシステム(EPS)またはLTEネットワークに基づくコアネットワーク140のパケット交換部分の例示的な構成を示す。図2Dを参照すると、図2B〜図2Cに示されたRAN 120と異なり、EPS/LTEネットワークのRAN 120は、図2B〜図2CからのRNC 215Bなしに複数の進化型NodeB(ENodeBまたはeNB)200D、205D、および210Dによって構成される。これは、EPS/LTEネットワークのENodeBがコアネットワーク140と通信するためにRAN 120内の別個のコントローラ(すなわち、RNC 215B)を必要としないからである。言い換えれば、図2B〜図2CからのRNC 215Bの機能の一部は、図2DのRAN 120のそれぞれの各eNodeBに組み込まれる。
図2Dにおいて、コアネットワーク140は、複数のモビリティ管理エンティティ(MME)215Dおよび220D、ホーム加入者サーバ(HSS)225D、サービングゲートウェイ(S-GW)230D、パケットデータネットワークゲートウェイ(P-GW)235D、ならびにポリシーおよび課金規則機能(PCRF: Policy and Charging Rules Function)240Dを含む。これらの構成要素と、RAN 120と、インターネット175との間のネットワークインターフェースが、図2Dに示され、次のようにTable 1(表1)(下)において定義される。
Figure 0006423439
図2DのRAN 120およびコアネットワーク140内に示された構成要素の高レベルの説明が、以下で説明される。しかし、これらの構成要素は、それぞれ、様々な3GPP TSの規格から当技術分野においてよく知られており、本明細書に含まれる説明は、これらの構成要素によって実行されるすべての機能の網羅的な説明であるように意図されていない。
図2Dを参照すると、MME 215Dおよび220Dは、EPSベアラに関する制御プレーンのシグナリングを管理するように構成される。MMEの機能は、非アクセス層(NAS)シグナリング、NASシグナリングのセキュリティ、技術間および技術内ハンドオーバのためのモビリティ管理、P-GWおよびS-GWの選択、ならびにMMEの変更をともなうハンドオーバのためのMMEの選択を含む。
図2Dを参照すると、S-GW 230Dは、RAN 120へのインターフェースを終端するゲートウェイである。EPSに基づくシステムのためのコアネットワーク140に関連する各UEに関しては、所与の時点で、単一のS-GWが存在する。GTPとプロキシモバイルIPv6(PMIP: Proxy Mobile IPv6)との両方に基づくS5/S8のためのS-GW 230Dの機能は、モビリティアンカーポイント、パケットのルーティングおよびフォワーディング、ならびに関連するEPSベアラのQoSクラス識別子(QCI: QoS Class Identifier)に基づくDiffServコードポイント(DSCP: DiffServ Code Point)の設定を含む。
図2Dを参照すると、P-GW 235Dは、パケットデータネットワーク(PDN)、たとえば、インターネット175へのSGiインターフェースを終端するゲートウェイである。UEが複数のPDNにアクセスしている場合、そのUEのための2つ以上のP-GWが存在する可能性があるが、通常、S5/S8接続性とGn/Gp接続性との混合は、そのUEに関して同時にサポートされない。P-GWの機能は、GTPに基づくS5/S8の両方に関して、(ディープパケットインスペクションによる)パケットのフィルタリング、UEのIPアドレスの割り当て、関連するEPSベアラのQCIに基づくDSCPの設定、事業者間の課金のアカウンティング、3GPP TS 23.203において定義されたアップリンク(UL)およびダウンリンク(DL)ベアラのバインディング、3GPP TS 23.203において定義されたULベアラのバインディングの検証を含む。P-GW 235Dは、GSM（登録商標）/EDGE無線アクセスネットワーク(GERAN)/UTRANのみのUEとE-UTRAN、GERAN、またはUTRANのいずれかを用いるE-UTRAN対応UEとの両方にPDN接続性を提供する。P-GW 235Dは、S5/S8インターフェースを介してE-UTRANのみを用いるE-UTRAN対応UEにPDN接続性を提供する。
図2Dを参照すると、PCRF 240Dは、EPSに基づくコアネットワーク140のポリシーおよび課金制御要素である。ローミングしないシナリオでは、UEのインターネットプロトコル接続性アクセスネットワーク(IP-CAN: Internet Protocol Connectivity Access Network)セッションに関連するHPLMN内の単一のPCRFが存在する。PCRFは、RxインターフェースおよびGxインターフェースを終端する。トラフィックがローカルで発生するローミングのシナリオでは、UEのIP-CANセッションに関連する2つのPCRFが存在する可能性があり、ホームPCRF(H-PCRF)が、HPLMN内にあるPCRFであり、訪問先PCRF(V-PCRF)が、訪問先VPLMN内にあるPCRFである。PCRFは、3GPP TS 23.203においてより詳細に説明されており、したがって、簡潔にするためにさらに説明されない。図2Dにおいて、(たとえば、3GPPの用語ではAFと呼ばれる可能性がある)アプリケーションサーバ170は、インターネット175を介してコアネットワーク140に、または代替的にRxインターフェースによってPCRF 240Dに直接接続されるものとして示されている。概して、アプリケーションサーバ170(またはAF)は、コアネットワークによるIPベアラリソース(たとえば、UMTSのPSドメイン/GPRSドメインのリソース/LTEのPSデータサービス)を用いるアプリケーションを提供する要素である。アプリケーション機能の1つの例は、IPマルチメディアサブシステム(IMS)コアネットワークサブシステムのプロキシ-呼セッション制御機能(P-CSCF: Proxy-Call Session Control Function)である。AFは、Rx参照点を用いてPCRF 240Dにセッション情報を提供する。セルラーネットワーク上でIPデータサービスを提供する任意のその他のアプリケーションサーバが、Rx参照点を介してPCRF 240Dにやはり接続され得る。
図2Eは、本発明の実施形態によるEPSまたはLTEネットワーク140Aに接続された強化された高レートパケットデータ(HRPD)RANとして構成されたRAN 120およびさらにHRPDコアネットワーク140Bのパケット交換部分の例を示す。コアネットワーク140Aは、図2Dに関連して上で説明されたコアネットワークと同様のEPSまたはLTEコアネットワークである。
図2Eにおいて、eHRPD RANは、強化型BSC(eBSC)および強化型PCF(ePCF)215Eに接続される複数の無線基地局(BTS)200E、205E、および210Eを含む。eBSC/ePCF 215Eは、S101インターフェースを介してEPSコアネットワーク140A内のMME 215Dまたは220Dのうちの1つに接続し、EPSコアネットワーク140Aのその他のエンティティとインターフェースを取る(たとえば、S103インターフェースを介してS-GW 230Dと、S2aインターフェースを介してP-GW 235Dと、Gxaインターフェースを介してPCRF 240Dと、STaインターフェースを介して3GPP AAAサーバ(図2Dには明示的に示されていない)となど)ためにA10および/またはA11インターフェースを介してHRPDサービングゲートウェイ(HSGW)220Eに接続することができる。HSGW 220Eは、HRPDネットワークとEPS/LTEネットワークとの間の相互接続を提供するために3GPP2において定義される。理解されるであろうように、eHRPD RANおよびHSGW 220Eは、レガシーHRPDネットワークにおいて利用可能でないEPC/LTEネットワークへのインターフェース機能を用いて構成される。
再びeHRPD RANに目を向けると、EPS/LTEネットワーク140Aとインターフェースを取ることに加えて、eHRPD RANは、HRPDネットワーク140BなどのレガシーHRPDネットワークともインターフェースを取ることができる。理解されるであろうように、HRPDネットワーク140Bは、図2AからのEV-DOネットワークなどのレガシーHRPDネットワークの例示的な実装である。たとえば、eBSC/ePCF 215Eは、A12インターフェースを介して認証、認可、およびアカウンティング(AAA)サーバ225Eとインターフェースを取ることができるか、またはA10もしくはA11インターフェースを介してPDSN/FA 230Eとインターフェースを取ることができる。そしてさらに、PDSN/FA 230EがHA 235Eに接続し、HE 235Eを通じてインターネット175がアクセスされ得る。図2Eにおいて、特定のインターフェース(たとえば、A13、A16、H1、H2など)は、明示的に説明されないが、完全にするために示されており、HRPDまたはeHRPDに精通した当業者によって理解されるであろう。
図2B〜図2Eを参照すると、LTEコアネットワーク(たとえば、図2D)ならびにeHRPD RANおよびHSGW(たとえば、図2E)とインターフェースを取るHRPDコアネットワークは、特定の場合、(たとえば、P-GW、GGSN、SGSNなどによる)ネットワークにより開始されるサービス品質(QoS)をサポートし得ることが理解されるであろう。
図3は、本発明の実施形態によるUEの例を示す。図3を参照すると、UE 300Aが、通話電話として示され、UE 300Bが、タッチスクリーンデバイス(たとえば、スマートフォン、タブレットコンピュータなど)として示される。図3に示されるように、UE 300Aの外部ケーシングは、当技術分野で知られているように、構成要素の中でもとりわけ、アンテナ305A、ディスプレイ310A、少なくとも1つのボタン315A(たとえば、PTTボタン、電源ボタン、ボリューム制御ボタンなど)、およびキーパッド320Aを用いて構成される。また、UE 300Bの外部ケーシングは、当技術分野で知られているように、構成要素の中でもとりわけ、タッチスクリーンディスプレイ305B、周辺のボタン310B、315B、320B、および325B(たとえば、電源制御ボタン、ボリュームまたはバイブレーション制御ボタン、機内モードトグルボタンなど)、少なくとも1つのフロントパネルボタン330B(たとえば、ホームボタンなど)を用いて構成される。UE 300Bの一部として明示的に示されていないが、UE 300Bは、WiFiアンテナ、セルラーアンテナ、衛星測位システム(SPS)アンテナ(たとえば、全地球測位システム(GPS)アンテナ)などを含むがこれらに限定されない1つもしくは複数の外部アンテナおよび/またはUE 300Bの外部ケーシングに組み込まれた1つもしくは複数の組み込みアンテナを含む可能性がある。
UE 300Aおよび300BなどのUEの内部の構成要素は、異なるハードウェア構成で具現化される可能性があるが、内部のハードウェア構成要素に関する基本的な高レベルのUEの構成は、図3においてプラットフォーム302として示される。プラットフォーム302は、根本的には、コアネットワーク140、インターネット175、ならびに/またはその他のリモートサーバおよびネットワーク(たとえば、アプリケーションサーバ170、ウェブのURLなど)から来る可能性があるRAN 120から送信されるソフトウェアアプリケーション、データ、および/またはコマンドを受信し、実行することができる。また、プラットフォーム302は、RANのインタラクションなしに、ローカルに記憶されたアプリケーションを独立して実行し得る。プラットフォーム302は、特定用途向け集積回路(ASIC)308、またはその他のプロセッサ、マイクロプロセッサ、論理回路、またはその他のデータ処理デバイスに動作可能なように結合されたトランシーバ306を含み得る。ASIC 308またはその他のプロセッサは、ワイヤレスデバイスのメモリ312内の任意の常駐プログラムとインターフェースを取るアプリケーションプログラミングインターフェース(API)310レイヤを実行する。メモリ312は、読み出し専用もしくはランダムアクセスメモリ(RAMおよびROM)、EEPROM、フラッシュカード、またはコンピュータプラットフォームに共通する任意のメモリからなる可能性がある。また、プラットフォーム302は、メモリ312において活発に使用されないアプリケーションおよびその他のデータを記憶することができるローカルデータベース314を含む可能性がある。ローカルデータベース314は、概して、フラッシュメモリセルであるが、磁気式媒体、EEPROM、光学式媒体、テープ、ソフトまたはハードディスクなどの当技術分野で知られている任意の2次ストレージデバイスである可能性がある。
したがって、本発明の実施形態は、本明細書において説明される機能を実行する能力を含むUE(たとえば、UE 300A、300Bなど)を含み得る。当業者によって理解されるであろうように、様々な論理要素は、ディスクリート要素(discrete element)、プロセッサで実行されるソフトウェアモジュール、または本明細書において開示される機能を実現するためのソフトウェアとハードウェアとの任意の組合せにおいて具現化され得る。たとえば、ASIC 308、メモリ312、API 310、およびローカルデータベース314が、本明細書で開示される様々な機能を協力してロードし、記憶し、実行するためにすべて使用される可能性があり、したがって、これらの機能を実行するための論理が、様々な要素に分散される可能性がある。代替的に、機能は、1つのディスクリート構成要素(discrete component)に組み込まれる可能性がある。したがって、図3のUE 300Aおよび300Bの特徴は、例示的であるに過ぎないと考えられるべきであり、本発明は、示される特徴または構成に限定されない。
UE 300Aおよび/または300BとRAN 120との間のワイヤレス通信は、CDMA、W-CDMA、時分割多元接続(TDMA)、周波数分割多元接続(FDMA)、直行周波数分割多重化(OFDM)、GSM（登録商標）、またはワイヤレス通信ネットワークもしくはデータ通信ネットワークにおいて使用され得るその他のプロトコルなどの異なる技術に基づく可能性がある。上で検討され、当技術分野で知られているように、音声送信および/またはデータは、様々なネットワークおよび構成を用いてRANからUEに送信され得る。したがって、本明細書において与えられる図解は、本発明の実施形態を限定するように意図されておらず、単に本発明の実施形態の態様の説明を助けるためのものである。
図4は、機能を実行するように構成された論理を含む通信デバイス400を示す。通信デバイス400は、UE 300Aまたは300B、RAN 120の任意の構成要素(たとえば、BS 200Aから210A、BSC 215A、NodeB 200Bから210B、RNC 215B、eNodeB 200Dから210Dなど)、コアネットワーク140の任意の構成要素(たとえば、PCF 220A、PDSN 225A、SGSN 220B、GGSN 225B、MME 215Dまたは220D、HSS 225D、S-GW 230D、P-GW 235D、PCRF 240D)、コアネットワーク140および/またはインターネット175に結合された任意の構成要素(たとえば、アプリケーションサーバ170)などを含むがこれらに限定されない上述の通信デバイスのいずれかに対応する可能性がある。したがって、通信デバイス400は、図1のワイヤレス通信システム100を介して1つまたは複数のその他のエンティティと通信する(またはそれらのその他のエンティティとの通信を容易にする)ように構成される任意の電子デバイスに対応する可能性がある。
図4を参照すると、通信デバイス400は、情報を受信および/または送信するように構成された論理405を含む。一例において、通信デバイス400がワイヤレス通信デバイス(たとえば、UE 300Aまたは300B、BS 200Aから210Aのうちの1つ、NodeB 200Bから210Bのうちの1つ、eNodeB 200Dから210Dのうちの1つなど)に対応する場合、情報を受信および/または送信するように構成された論理405は、ワイヤレストランシーバならびに関連するハードウェア(たとえば、RFアンテナ、モデム、変調器および/または復調器など)などのワイヤレス通信インターフェース(たとえば、Bluetooth（登録商標）、WiFi、2G、CDMA、W-CDMA、3G、4G、LTEなど)を含み得る。別の例において、情報を受信および/または送信するように構成された論理405は、有線通信インターフェース(たとえば、シリアル接続、USBまたはFirewire接続、インターネット175がアクセスされ得るイーサネット（登録商標）接続など)に対応する可能性がある。したがって、通信デバイス400がある種のネットワークに基づくサーバ(たとえば、PDSN、SGSN、GGSN、S-GW、P-GW、MME、HSS、PCRF、アプリケーション170など)に対応する場合、情報を受信および/または送信するように構成された論理405は、一例においては、ネットワークに基づくサーバをイーサネット（登録商標）プロトコルによってその他の通信エンティティに接続するイーサネット（登録商標）カードに対応する可能性がある。さらなる例において、情報を受信および/または送信するように構成された論理405は、通信デバイス400がその通信デバイス400のローカルの環境を監視することができる感知または測定ハードウェア(たとえば、加速度計、温度センサー、光センサー、ローカルのRF信号を監視するためのアンテナなど)を含む可能性がある。情報を受信および/または送信するように構成された論理405は、実行されるときに、情報を受信および/または送信するように構成された論理405の関連するハードウェアがその論理の受信および/または送信機能を実行することを可能にするソフトウェアを含む可能性もある。しかし、情報を受信および/または送信するように構成された論理405は、ソフトウェアのみに対応せず、情報を受信および/または送信するように構成された論理405は、その論理の機能を実現するために少なくとも部分的にハードウェアに依拠する。
図4を参照すると、通信デバイス400は、情報を処理するように構成された論理410をさらに含む。一例において、情報を処理するように構成された論理410は、少なくともプロセッサを含み得る。情報を処理するように構成された論理410によって実行され得る処理のタイプの例示的な実装は、判定を行うこと、接続を確立すること、異なる情報の選択肢の間で選択を行うこと、データに関連する評価を行うこと、通信デバイス400に結合されたセンサーとインタラクションして測定動作を実行すること、情報をあるフォーマットから別のフォーマットに(たとえば、.wmvから.aviへなど異なるプロトコルの間で)変換することなどを含むがこれらに限定されない。たとえば、情報を処理するように構成された論理410に含まれるプロセッサは、汎用プロセッサ、デジタル信号プロセッサ(DSP)、ASIC、フィールドプログラマブルゲートアレイ(FPGA)もしくはその他のプログラマブルロジックデバイス、ディスクリートゲート(discrete gate)もしくはトランジスタ論理、ディスクリートハードウェア構成要素(discrete hardware component)、または本明細書で説明される機能を実行するように設計されたこれらの任意の組合せに対応する可能性がある。汎用プロセッサはマイクロプロセッサである可能性があるが、別法として、プロセッサは、任意の通常のプロセッサ、コントローラ、マイクロコントローラ、または状態機械である可能性がある。また、プロセッサは、コンピューティングデバイスの組合せ、たとえば、DSPとマイクロプロセッサとの組合せ、複数のマイクロプロセッサ、DSPコアと連携する1つもしくは複数のマイクロプロセッサ、または任意のその他のそのような構成として実装され得る。情報を処理するように構成された論理410は、実行されるときに、情報を処理するように構成された論理410の関連するハードウェアがその論理の処理機能を実行することを可能にするソフトウェアを含む可能性もある。しかし、情報を処理するように構成された論理410は、ソフトウェアのみに対応せず、情報を処理するように構成された論理410は、その論理の機能を実現するために少なくとも部分的にハードウェアに依拠する。
図4を参照すると、通信デバイス400は、情報を記憶するように構成された論理415をさらに含む。一例において、情報を記憶するように構成された論理415は、少なくとも非一時的メモリおよび関連するハードウェア(たとえば、メモリコントローラなど)を含み得る。たとえば、情報を記憶するように構成された論理415に含まれる非一時的メモリは、RAMメモリ、フラッシュメモリ、ROMメモリ、EPROMメモリ、EEPROMメモリ、レジスタ、ハードディスク、取り外し可能なディスク、CD-ROM、または当技術分野で知られている任意のその他の形態のストレージ媒体に対応する可能性がある。情報を記憶するように構成された論理415は、実行されるときに、情報を記憶するように構成された論理415の関連するハードウェアがその論理の記憶機能を実行することを可能にするソフトウェアを含む可能性もある。しかし、情報を記憶するように構成された論理415は、ソフトウェアのみに対応せず、情報を記憶するように構成された論理415は、その論理の機能を実現するために少なくとも部分的にハードウェアに依拠する。
図4を参照すると、通信デバイス400は、任意で、情報を提示するように構成された論理420をさらに含む。一例において、情報を提示するように構成された論理420は、少なくとも出力デバイスおよび関連するハードウェアを含み得る。たとえば、出力デバイスは、ビデオ出力デバイス(たとえば、ディスプレイスクリーン、USB、HDMI（登録商標）などのビデオ情報を運ぶことができるポート)、オーディオ出力デバイス(たとえば、スピーカ、マイクロホンジャック、USB、HDMI（登録商標）などのオーディオ情報を運ぶことができるポート)、バイブレーションデバイス、および/または情報が出力のためにフォーマットされるか、もしくは通信デバイス400のユーザもしくはオペレータによって実際に出力され得る任意のその他のデバイスを含む可能性がある。たとえば、通信デバイス400が図3に示されたUE 300AまたはUE 300Bに対応する場合、情報を提示するように構成された論理420は、UE 300Aのディスプレイ310AまたはUE 300Bのタッチスクリーンディスプレイ305Bを含み得る。さらなる例において、情報を提示するように構成された論理420は、ローカルユーザのいないネットワーク通信デバイス(たとえば、ネットワークスイッチまたはルータ、リモートサーバなど)などの特定の通信デバイスに関しては省略される可能性がある。情報を提示するように構成された論理420は、実行されるときに、情報を提示するように構成された論理420の関連するハードウェアがその論理の提示機能を実行することを可能にするソフトウェアを含む可能性もある。しかし、情報を提示するように構成された論理420は、ソフトウェアのみに対応せず、情報を提示するように構成された論理420は、その論理の機能を実現するために少なくとも部分的にハードウェアに依拠する。
図4を参照すると、通信デバイス400は、任意で、ローカルユーザ入力を受信するように構成された論理425をさらに含む。一例において、ローカルユーザ入力を受信するように構成された論理425は、少なくともユーザ入力デバイスおよび関連するハードウェアを含み得る。たとえば、ユーザ入力デバイスは、ボタン、タッチスクリーンディスプレイ、キーボード、カメラ、オーディオ入力デバイス(たとえば、マイクロホン、もしくはマイクロホンジャックなどのオーディオ情報を運ぶことができるポート)、および/または情報が通信デバイス400のユーザもしくはオペレータから受信され得る任意のその他のデバイスを含む可能性がある。たとえば、通信デバイス400が図3に示されたUE 300AまたはUE 300Bに対応する場合、ローカルユーザ入力を受信するように構成された論理425は、キーパッド320A、ボタン315Aまたは310Bから325Bのいずれか、タッチスクリーンディスプレイ305Bなどを含み得る。さらなる例において、ローカルユーザ入力を受信するように構成された論理425は、ローカルユーザのいないネットワーク通信デバイス(たとえば、ネットワークスイッチまたはルータ、リモートサーバなど)などの特定の通信デバイスに関しては省略される可能性がある。ローカルユーザ入力を受信するように構成された論理425は、実行されるときに、ローカルユーザ入力を受信するように構成された論理425の関連するハードウェアがその論理の入力受信機能を実行することを可能にするソフトウェアを含む可能性もある。しかし、ローカルユーザ入力を受信するように構成された論理425は、ソフトウェアのみに対応せず、ローカルユーザ入力を受信するように構成された論理425は、その論理の機能を実現するために少なくとも部分的にハードウェアに依拠する。
図4を参照すると、405から425までの構成された論理が図4の別々のまたは異なるブロックとして示されているが、それぞれの構成された論理がその論理の機能を実行するハードウェアおよび/またはソフトウェアは部分的に重なる可能性があることが理解されるであろう。たとえば、405から425の構成された論理の機能を容易にするために使用される任意のソフトウェアが、405から425の構成された論理が情報を記憶するように構成された論理415によって記憶されたソフトウェアの動作に部分的に基づいてその論理の機能(つまり、この場合、ソフトウェアの実行)をそれぞれ実行するように、情報を記憶するように構成された論理415に関連する非一時的メモリに記憶される可能性がある。同様に、構成された論理のうちの1つに直接関連付けられるハードウェアが、その他の構成された論理によって時折借用または使用され得る。たとえば、情報を処理するように構成された論理410のプロセッサは、情報を受信および/または送信するように構成された論理405が情報を処理するように構成された論理410に関連するハードウェア(すなわち、プロセッサ)の動作に部分的に基づいてその論理の機能(つまり、この場合、データの送信)を実行するように、情報を受信および/または送信するように構成された論理405によって送信される前にデータを適切なフォーマットにフォーマットする可能性がある。
概して、別途明示的に示されない限り、本開示の全体を通じて使用される語句「〜ように構成された論理」は、少なくとも部分的にハードウェアで実装される実施形態をもたらすように意図されており、ハードウェアとは独立したソフトウェアのみの実装に当てはまるように意図されていない。また、様々なブロックの構成された論理または「〜ように構成された論理」は、特定の論理ゲートまたは要素に限定されず、概して、(ハードウェアかまたはハードウェアとソフトウェアとの組合せかのどちらかによって)本明細書において説明される機能を実行する能力を指すことが理解されるであろう。したがって、様々なブロックに示される構成された論理または「〜ように構成された論理」は、語「論理」を共有するにもかかわらず、必ずしも論理ゲートまたは論理要素として実装されない。様々なブロックの論理の間のその他のインタラクションまたは協力が、下でより詳細に説明される実施形態を考察することにより当業者に明らかになるであろう。
図2Aの1x EV-DO、図2B〜図2CのUMTSに基づくW-CDMA、図2DのLTE、および図2EのeHRPDなどのネットワーク上で動作するセッションは、サービス品質(QoS)と呼ばれる保証された品質レベルが確保されるチャネル(たとえば、RAB、フローなど)でサポートされ得る。たとえば、特定のチャネルで所与のレベルのQoSを確立することは、そのチャネルにおける最小保証ビットレート(GBR)、最大遅延、ジッタ、レイテンシー、ビット誤り率(BER)などのうちの1つまたは複数を提供する可能性がある。QoSリソースは、ボイスオーバーIP(VoIP)セッション、グループ通信セッション(たとえば、PTTセッションなど)、オンラインゲーム、IP TVなどのリアルタイムまたはストリーミング通信セッションに関するシームレスなエンドツーエンドのパケット転送を保証するのを助けるために、これらのセッションに関連するチャネルのために確保(または設定)され得る。
通常、QoSベアラが、本明細書においてApp*と表記される特定のアプリケーション(たとえば、VoIP、PTTなど)に関連する通信セッションのために設定またはアクティブ化されるとき、QoSは、通信セッションの継続時間全体のためにアップリンクチャネルとダウンリンクチャネルとの両方で設定される。しかし、当業者によって理解されるであろうように、App*通信セッションに参加する所与のUE上のクライアントアプリケーションは、連続的におよび/または同時に通信セッションのためにアップリンクチャネルとダウンリンクチャネルとの両方で送信および/または受信する優先度の高いトラフィックを持たない可能性がある。
たとえば、半二重App*通信セッション(たとえば、1:1もしくは直接通話、またはPTTなどのグループ通話)においては、フロア保持者が、アップリンクチャネルで(つまり、非フロア保持者に)送信する優先度の高いトラフィックを有する可能性があるが、概して、フロア保持者は、App*セッションの半二重の性質が原因で、ダウンリンクチャネルで受信する優先度の高いトラフィックを持たない。同様に、上述の半二重App*通信セッションにおいて、非フロア保持者は、ダウンリンクチャネルで(つまり、フロア保持者から)受信する優先度の高いトラフィックを有する可能性があるが、概して、非フロア保持者は、App*セッションの半二重の性質が原因で、アップリンクチャネルで送信する優先度の高いトラフィックを持たない。さらに、半二重App*セッション中、誰もフロアを保持しない(たとえば、フロア要求を除いて、どちらの方向にも優先度の高いトラフィックがない)ときが存在する。全二重App*通信セッション(たとえば、1:1または直接通話)に目を向けると、通話の所与の参加者が、それらの参加者のセッションをミュートさせる可能性があり、または単純にしゃべっていない可能性があり、したがって、所与の者は、アップリンクチャネルで送信する優先度の高いトラフィックを持たない。理解されるであろうように、上述の半二重または全二重App*セッションの少なくとも一部の間、App*通信セッション全体を通じて連続的に両方向(つまり、アップリンクおよびダウンリンク)でそれぞれのセッション参加者のためにQoSを確保することは、それぞれのQoSの確保がシステム100の全体的なリソース容量を減らすので非効率的である可能性がある。
したがって、本発明の実施形態は、App*通信セッション中に優先度の高いトラフィックが流れると予測される(または実際に流れている)方向(たとえば、アップリンクおよび/またはダウンリンク)に基づいて動的にApp*通信セッションのためのアップリンクチャネルおよび/またはダウンリンクチャネルへのQoSリソースの割り当てを選択的に増やすかまたは減らすことに関する。特に、下で説明される本発明の実施形態は、上の図2Aから図2Eに示されたコアネットワークのうちの1つまたは複数でアプリケーションサーバ170によって調停されるように構成されるQoSに基づく通信セッションを対象とする。
たとえば、QoSに基づくApp*通信セッションが図2Aに示された1x EV-DOコアネットワーク上で1つまたは複数のUEの間で仲介されるVoIPセッションに対応する場合、アプリケーションサーバ170によって管理されるそれぞれのVoIPセッションは、潜在的にQoSを割り当てられる3つのフロー(すなわち、呼設定シグナリングフロー、インコール(incall)シグナリングフロー、およびメディアトラフィックフロー)に関連付けられる可能性がある。1x EV-DOコアネットワークは、EV-DOのために設定されたQoSがRAN 120において実施されるように、GBR QoSを確保可能なパラメータとして認識しない。
別の例において、QoSに基づくApp*通信セッションが図2Bまたは図2Cに示されたUMTSに基づくW-CDMAコアネットワーク上で1つまたは複数のUEの間で仲介されるVoIPセッションに対応する場合、それぞれのVoIPセッションは、「インタラクティブ」トラフィッククラスQoSを用いて構成される可能性があり、MAC-es/MAC-hs GBRを構成し、ULのスケジューリングされない送信の許可(non-scheduled Transmission Grant)を使用することによって、RAN 120(すなわち、UTRAN)において、無線インターフェースを介してGBR QoSを受信する可能性がある。1x EV-DOコアネットワークに関連する上の例と同様に、GBR QoSリソースは、論理接続のみが維持されるように、W-CDMAコアネットワークがGBR QoSを確保可能なパラメータとして認識しないので、「インタラクティブ」トラフィッククラス(RAN 120のみ)のために図2B〜図2CのW-CDMAコアネットワークにおいて確保されず、構成され得ない。代替的に、「会話」トラフィッククラスが「インタラクティブ」トラフィッククラスの代わりに使用されるとき、GBR QoSリソースは、UEとW-CDMAコアネットワークとの両方によってネゴシエーション/修正され得る。概して、VoIPセッションは、W-CDMAの「会話」トラフィッククラスを使用する。
別の例において、QoSに基づくApp*通信セッションが図2Dに示されたLTEコアネットワーク上で1つまたは複数のUEの間で仲介されるVoIPセッションに対応する場合、アプリケーションサーバ170によって管理されるVoIPセッションは、(PDNApp*と表記される)個別のアプリケーションに固有のPDN接続で(QCIApp*と表記される)App*のGBR QoSベアラに関してQoSクラス識別子(QCI)「1」またはアプリケーションに固有のQCIを使用し、S5接続がUEがRRC-Idle状態にあるときでさえも維持されることかまたはRRCのIdleからConnectedへの遷移後に迅速に設定されることかのどちらかを必要とする。したがって、図2Aの1x EV-DOコアネットワークおよび図2B〜図2CのW-CDMAコアネットワークとは異なり、図2DのLTEコアネットワークは、それによって、RAN 120に加えてコアネットワーク140においてGBR QoSをサポートする。
下でより詳細に説明される本発明の実施形態は、次のようにTable 2(表2)(下)にまとめられたように、図2A〜図2Bからのコアネットワークのうちの1つまたは複数内での動作のためにそれぞれ構成される。
Figure 0006423439
図5は、本発明の実施形態によるクライアントアプリケーションにより開始される方向性を持ったQoS管理手順のより詳細な実施の例を示す。Table 2(表2)(上)において説明されたように、クライアントアプリケーションにより開始される方向性を持ったQoS管理手順(すなわち、Table 2(表2)の#1)は、図2Aの1x EV-DOコアネットワーク、図2B〜図2CのW-CDMAコアネットワーク(「会話」トラフィッククラスがセッションのために使用される場合)、図2DのLTEコアネットワーク、および/または図2EのeHRPDコアネットワークにおいて実施され得る。図6A〜図6Cは、図5の手順を個々のコアネットワークのタイプにマッピングするためのより詳細な流れ図を示すが、図5は、これらのコアネットワークのタイプのいずれにも当てはまる。
図5を参照すると、所与のUE上のApp*に関するクライアントアプリケーションが、App*通信セッション(たとえば、VoIPセッション、PTTセッションなど)を開始することを決定する(500)。500の決定は、通信セッションを始めるための所与のUEのオペレータによる要求に基づく可能性があり、その場合、所与のUEは、発信側のUEである。代替的に、500の決定は、何らかのその他のエンティティによって開始されたApp*通信セッションを告知する、所与のUEにおいて受信される呼告知メッセージに基づく可能性があり、その場合、所与のUEは、着信側のUEである。図5の実施形態においては、App*クライアントアプリケーションが所与のUE上で実行されており、App*通信セッション(たとえば、VoIPセッション、PTTセッションなど)に関連するクライアント側の動作を扱うように構成されると仮定する。
505において、App*クライアントアプリケーションが、開始されるApp*通信セッションが半二重であるかまたは全二重であるかを判定する。App*クライアントアプリケーションは、505においてApp*通信セッションが半二重(たとえば、PTT通話)であると判定する場合、App*クライアントアプリケーションは、所与のUEが半二重App*セッションに関するフロアを現在有する(または現在のフロア保持者である)かどうかを判定する(510)。App*クライアントアプリケーションは、510において、所与のUEがフロアを有すると判定する場合、閾値のレベルのアップリンク(UL)のQoSリソース(たとえば、閾値のデータレートまたはkbpsに設定されたGBR)が半二重App*セッションに関する所与のUEによるアップリンクのメディアの送信をサポートするために確立されるかどうかを判定する(515)。理解されるであろうように、半二重App*セッションに関するフロア保持者は、フロア保持者からのULチャネルのQoSが半二重App*セッションに関するセッション品質を向上することができるように、非フロア保持者として半二重App*セッションに参加する着信側のUEへの配信のためにULチャネルで優先度の高いメディアを送信している可能性が高い。図6A〜図6Cに関連して下でより詳細に説明されるように、515のアップリンクのQoSリソースの判定は、(i)所与のUEが図2Aと同様の1x EV-DOネットワークまたは図2Eと同様のeHRPDネットワークによってサービスを提供される場合にULのメディアトラフィックフローに関するQoSが設定されるかどうかを判定すること、(ii)所与のUEが図2B〜図2Cと同様のW-CDMAネットワークまたは図2Dと同様のLTEネットワークによってサービスを提供される場合にULのメディアベアラが半二重セッションをサポートするために少なくとも閾値のGBRを用いて構成されるかどうかを判定することを含み得る。
所与のUE上のApp*クライアントアプリケーションが、515において閾値のULのQoSリソースが半二重App*セッションのためにまだ設定されていないと判定する場合、所与のUEは、520においてULのQoSリソースがアクティブ化されるおよび/または増やされることを要求する。たとえば、所与のUEは、図2Aと同様の1x EV-DOネットワークによってサービスを提供される場合、520においてULのメディアトラフィックフローに関するQoSがアクティブ化されることを要求することができる。別の例において、所与のUEは、図2B〜図2Cと同様のW-CDMAネットワークまたは図2Dと同様のLTEネットワークによってサービスを提供される場合、520においてそのUEのULのメディアベアラ上のそのUEの現在のGBRをより高いGBR(たとえば、XApp* kbps、ここで、XApp* kbpsはApp*通信セッションに関するアプリケーションに固有の動的なデータレートに対応する)に修正することを要求することができる。
さらに、510において所与のUEが半二重App*セッションに関するフロアを有すると判定される場合、所与のUEがダウンリンク(DL)のメディアのためのQoSを必要としない可能性があることが理解されるであろう。したがって、515〜520においてULチャネルに関するQoSを(必要な場合)選択的に設定するかまたは増やすことに加えて、さらに、所与のUEは、525〜530においてApp*ベアラのためのDLチャネルに関する既存のQoSリソースを(必要な場合)選択的に破棄するかまたは減らす。したがって、App*クライアントアプリケーションは、閾値のレベルのDLのQoSリソースが半二重App*セッションに関して所与のUEにおいてDLのメディアの受信をサポートするために確立されるかどうかを判定する(525)。図6A〜図6Cに関連して下でより詳細に説明されるように、525のDLのQoSリソースの判定は、(i)所与のUEが図2Aと同様の1x EV-DOネットワークまたは図2Eと同様のeHRPDネットワークによってサービスを提供される場合にDLのメディアトラフィックフローに関するQoSが設定されるかどうかを判定すること、(ii)所与のUEが図2B〜図2Cと同様のW-CDMAネットワークまたは図2Dと同様のLTEネットワークによってサービスを提供される場合にDLのApp*のメディアベアラが少なくとも閾値のGBRを用いて構成されるかどうかを判定することを含み得る。
所与のUE上のApp*クライアントアプリケーションは、525において閾値のDLのQoSリソースが半二重App*セッションのためにすでに設定されていると判定する場合、所与のUE上のApp*クライアントアプリケーションは、530においてDLのQoSリソースが非アクティブ化されるおよび/または減らされることを要求する。たとえば、所与のUEは、図2Aと同様の1x EV-DOネットワークまたは図2Eと同様のeHRPDネットワークによってサービスを提供される場合、530においてDLのメディアトラフィックフローに関するQoSが非アクティブ化されるかまたはオフにされることを要求することができる。別の例において、所与のUEは、図2B〜図2Cと同様のW-CDMAネットワークまたは図2Dと同様のLTEネットワークによってサービスを提供される場合、所与のUE上のApp*クライアントアプリケーションは、530においてそのUEのDLのメディアベアラ上のそのUEの現在のGBRをより低いGBRに修正することを要求することができる。
引き続き図5を参照し、510の半二重のフロア保持者の判定に再び目を向けると、App*クライアントアプリケーションは、510において所与のUEがフロアを持たないと判定する場合、別のセッション参加者がフロアを保持するかどうか(つまり、何らかのエンティティからのメディアが半二重App*セッションに関してDLチャネルを介して受信されているかどうか)を判定する(535)。理解されるであろうように、半二重App*セッションに関する非フロア保持者(または着信側のUE)は、非フロア保持者または着信側のUEに関するDLチャネルのQoSが半二重App*セッションに関するセッション品質を改善することができるように、DLで優先度の高いメディアを受信している可能性が高い。したがって、App*クライアントアプリケーションは、535において別のエンティティがフロアを保持する(つまり、メディアが半二重App*セッションに関して所与のUEにおいて受信されている)と判定する場合、App*クライアントアプリケーションは、閾値レベルのDLのQoSリソースが半二重セッションに関して所与のUEにおいてDLのメディアの受信をサポートするために確立されるかどうかを判定する(540)(525と同様)。
所与のUE上のApp*クライアントアプリケーションは、540において閾値のDLのQoSリソースが半二重App*セッションのためにまだ設定されていないと判定する場合、所与のUE上のApp*クライアントアプリケーションは、545においてDLのQoSリソースがアクティブ化されるおよび/または増やされることを要求する。たとえば、所与のUEは、図2Aと同様の1x EV-DOネットワークまたは図2Eと同様のeHRPDネットワークによってサービスを提供される場合、所与のUEは、545においてDLのメディアトラフィックフローに関するQoSがアクティブ化されることを要求することができる。別の例において、所与のUEは、図2B〜図2Cと同様のW-CDMAネットワークまたは図2Dと同様のLTEネットワークによってサービスを提供される場合、所与のUE上のApp*クライアントアプリケーションは、545においてそのUEのDLのメディアベアラ上のそのUEの現在のGBRをより高いGBR(たとえば、XApp* kbps)に修正することを要求することができる。
さらに、510において所与のUEが半二重App*セッションに関するフロアを持たないと判定される場合、所与のUEがULのメディアのためのQoSを必要としない可能性があることが理解されるであろう。したがって、540〜545においてDLチャネルに関するQoSを(必要な場合)選択的に設定することに加えて、さらに、所与のUEは、550〜555においてULチャネルに関する既存のQoSリソースを(必要な場合)選択的に破棄するかまたは減らす。したがって、App*クライアントアプリケーションは、閾値のレベルのULのQoSリソースが半二重セッションに関して所与のUEにおいてULのメディアの受信をサポートするために確立されるかどうかを判定する(550)(520と同様)。
所与のUE上のApp*クライアントアプリケーションは、550において閾値のULのQoSリソースが半二重App*セッションのためにすでに設定されていると判定する場合、所与のUEは、555においてULのQoSリソースが非アクティブ化されるおよび/または減らされることを要求する。たとえば、所与のUEが図2Aと同様の1x EV-DOネットワークまたは図2Eと同様のeHRPDネットワークによってサービスを提供される場合、所与のUE上のApp*クライアントアプリケーションは、555においてULのメディアトラフィックフローに関するQoSが非アクティブ化されるかまたはオフにされることを要求することができる。別の例において、所与のUEは、図2B〜図2Cと同様のW-CDMAネットワークまたは図2Dと同様のLTEネットワークによってサービスを提供される場合、所与のUE上のApp*クライアントアプリケーションは、555においてそのUEのULのメディアベアラ上のそのUEの現在のGBRをより低いGBR(たとえば、1 kbpsまたは何らかのその他の名目的なデータレート)に修正することを要求することができる。
引き続き図5を参照し、App*クライアントアプリケーションが510において所与のUE自体がフロアを保持しないと判定した後に別のフロア保持者が存在するかどうかを判定する535の判定に再び目を向けると、App*クライアントアプリケーションは、535において誰もフロアを保持しないと判定する場合、(少なくとも、セッション参加者のうちの1人がフロアを与えられるまで)半二重App*セッションに関するDLとULとの両方のQoSリソースを減らすかまたは非アクティブ化することを決定する(560)。したがって、560の後、プロセスは、DLおよびULのQoSリソースが(必要な場合)減らされるおよび/または非アクティブ化される525〜530と550〜555との両方に進む。
引き続き図5を参照して、505の複信の判定に再び目を向けると、App*クライアントアプリケーションは、通信セッションが半二重ではなく全二重(たとえば、VoIP通話)であると判定する場合、App*クライアントアプリケーションは、オーディオが全二重App*セッションに関してミュートされるかどうかを判定する(565)。理解されるであろうように、オーディオがミュートされる場合、所与のUEのオペレータが、半二重App*セッションでその他のUEを聞いているが、実際には、その他のUEに運ばれるそのオペレータ自身のオーディオを欲していない。App*クライアントアプリケーションが565において全二重App*セッションがミュートされないと判定する場合、全二重App*セッションに関するULとDLとの両方のQoSリソースが、(必要な場合)アクティブ化されるかまたは増やされる(570)。たとえば、570は、例における515〜520および550〜555の実行に対応することができる。そうでなく、App*クライアントアプリケーションが565において全二重App*セッションがミュートされると判定する場合、プロセスは、DLのQoSリソースが(必要な場合)増やされるかまたはアクティブ化され、ULのQoSリソースが(必要な場合)減らされるかまたは非アクティブ化される540〜555に進む。
図6Aは、本発明の実施形態による、図2Aと同様の1x EV-DOネットワーク(レガシーHRPD)または図2Eと同様のeHRPDネットワークによってサービスを提供されながら半二重App* PTTセッションに加わる所与のUEのための図5のプロセスの例示的な実施を示す。図6Aを参照すると、所与のUEがアイドル状態にある間に、App*クライアントアプリケーションが、(たとえば、PTTボタンの押下に応じて)App* PTT通話を始めることを決定し(600A)、App*クライアントアプリケーションが、所与のUEがフロアを有すると判定する(605A)(たとえば、図5の500〜515と同様)。所与のUEがApp* PTT通話に関するそのUEのULのメディアフローのために設定されたQoSをまだ持たないと仮定すると、所与のUE上のApp*クライアントアプリケーションは、App* PTT通話に関するそのUEのULのメディアフローのためのQoSのアクティブ化を要求するが、DLのメディアフローのためのQoSのアクティブ化は要求しない。これが図6Aに示されており、それによって、所与のUEがULのメディアQoSフローを示す(DLのメディアQoSフローは示さない)ReservationOnRequestメッセージを送信する(615A)。したがって、RAN 120は、DLのメディアフローのためのDLのQoSの確保を停止状態にしながらULのメディアフローのためのULのQoSの確保を設定する(620Aから640Aの間のシグナリングによって示され、1x EV-DOに精通した当業者によって容易に理解される)(たとえば、図5の515〜530と同様)。図6Aには明示的に示されていないが、所与のUE上のApp*クライアントアプリケーションは、640Aの後、フロア保持者としてメディアを送信し始めることができる。
図6Aを参照すると、所与のUE上のApp*クライアントアプリケーションは、最終的にフロアを解放し(645A)、App*クライアントアプリケーションは、別のUEがApp* PTTセッションに関するフロアを有すると判定する(650A)(図5の510および535と同様)。したがって、図5の540〜555と同様に、所与のUEは、DLのメディアフローのためのDLのQoSの確保をオンにし(655A〜660A)、ULのメディアフローのためのULのQoSの確保を破棄する(665A〜670A)。
図6Aを参照すると、その他のUEは、最終的にフロアを解放し(675A)、App*クライアントアプリケーションは、いかなるUEもApp* PTTセッションに関するフロアを持たないと判定する(680A)(図5の535および560と同様)。したがって、図5の525〜530および550〜555と同様に、所与のUE上のApp*クライアントアプリケーションは、DLのメディアフローのためのDLのQoSの確保とULのメディアフローのためのULのQoSの確保との両方を破棄する(680A〜690A)。
図6Aは所与のUEがApp* PTT通話の発信側である例を対象とするが、図6Aはその代わりに所与のUEがApp* PTT通話の呼の着信側であるシナリオに対応するように修正され得ることが理解されるであろう。図6Aの呼の着信側の実装において、呼の着信側のUE上のApp*クライアントアプリケーションは、(600Aと同様のPTTボタンの押下の代わりに)呼告知メッセージによってApp* PTT通話を知り、呼の着信側のUEは、(図6Aと同様のフロア保持者の代わりに)非フロア保持者としてApp* PTT通話を開始する。これらの違い以外は、App*のメディアQoSフローに関するULおよびDLのQoSは、図6Aと同様にして呼の着信側のUEのために管理され得る。また、図6Aには明示的に示されていないが、図6Aは、図6Bの半二重セッションの例の代わりに全二重の例などの図5からのさらなる使用事例(たとえば、図5の565、570など)を包含するように拡張され得る。さらに、図6Aは、所与のUEがアイドルしている(つまり、トラフィックチャネル(TCH)がない)ときに600AにおいてApp* PTT通話が開始されるようにして説明されているが、図6Aは、所与のUEがTCHをすでに割り当てられている間に所与のUEにおいてApp* PTT通話が開始される(またはあらかじめ確立されたTCH上で所与のUEに告知される、着信側のUEの実装)ように修正され得ることが理解されるであろう。
図6Bは、本発明の実施形態による、図2Bまたは図2Cと同様のW-CDMAネットワークによってサービスを提供されながら半二重App* PTTセッションに加わる所与のUEに関する図5のプロセスの例示的な実施を示す。図6Bを参照すると、所与のUEは、CELL_PCHまたはURA_PCH状態で動作しており(600B)、App*クライアントアプリケーションは、何らかのその他のUEによって開始されたApp* PTT通話に関連してページを受信し(たとえば、その他のUEにおけるPTTボタンの押下に応じて)(605B)、そのページが、PTT告知メッセージ(図示せず)を受信し、App* PTTセッションのためのRABを設定する(620B)ためにCELL_DCH状態に遷移する(615B)ようにRAN 120とのセル更新手順を実行するように所与のUEに促す(610B)。特に、620Bにおいて、RAN 120は、App* PTTセッションをサポートするメディアRABに関してULとDLとの両方で少なくとも閾値のGBR(たとえば、XApp* kbps)を割り当てる。
図6Bを参照して、App*クライアントアプリケーションが、別のUEがApp* PTTセッションに関するフロアを有すると判定する(625B)(図5の510および535と同様)と仮定する。したがって、620Bにおいて所与のUEが閾値のGBRをすでに割り当てられたので、図5の540〜555と同様に、App* PTTクライアントアプリケーションは、DLのメディアベアラに割り当てられるGBRをXApp* kbpsに保つが、ULのメディアベアラに割り当てられるGBRを(たとえば、1 kbpsまたは何らかのその他の名目的なレベルに)減らすことを決定する。ULのメディアベアラに対するGBRの引き下げは、図6B内では630Bから670Bの間のシグナリングにおいて示されており、このシグナリングは、UMTSおよび/またはW-CDMAに精通した当業者によって容易に理解されるであろう。
図6Bは所与のUEがApp* PTT通話の呼の着信側のUEである例を対象とするが、図6Bはその代わりに所与のUEがApp* PTT通話の呼の発信側であるシナリオに対応するように修正され得ることが理解されるであろう。図6Bの呼の発信側の実装において、呼の発信側のUE上のApp*クライアントアプリケーションは、(605Bと同様のページ/告知手順の代わりに)PTTボタンの押下によってApp* PTT通話を知ることができ、呼の発信側のUEは、(図6Bと同様の非フロア保持者の代わりに)フロア保持者としてApp* PTT通話を開始する。これらの違い以外は、App*のメディアQoSフローに関するULおよびDLのQoSは、図6Bと同様にして呼の着信側のUEのために管理され得る。また、図6Bには明示的に示されていないが、図6Bは、図6Bの半二重セッションの例の代わりに全二重の例などの図5からのさらなる使用事例(たとえば、図5の565、570など)を包含するように拡張され得る。さらに、図6Bは、所与のUEがURA_PCH/CELL_PCH状態にある間に受信されたページに基づいて605BにおいてApp* PTT通話が開始されるようにして説明されているが、図6Bは、所与のUEがすでにCELL_DCH状態にある間にApp* PTTセッションに関する呼の告知が到着する(または発信側のUEの実装に関しては、CELL_DCH状態にある間に所与のUEにおいてApp*に関するPTTボタンの押下が検出される)ように修正され得ることが理解されるであろう。
図6Cは、本発明の実施形態による、図2Dと同様のLTEネットワークによってサービスを提供されながら半二重App* PTTセッションを始める所与のUEに関する図5のプロセスの例示的な実施を示す。図6Cを参照すると、所与のUEは、Radio Resource Connected(RRC)アイドルモードで動作しており(600C)、App*クライアントアプリケーションは、(たとえば、所与のUEにおけるPTTボタンの押下に応じて)半二重App* PTTセッションを開始することを決定する(605C)。そして、所与のUEは、RCC Connected状態に遷移し(615C)、半二重App* PTTセッションのメディアのための非GBR EPSベアラおよび個別のGBR EPSベアラを設定する(620C)ように、RAN 120(つまり、eNodeB 205Dなどの所与のUEにサービスを提供するeNodeB)とのRCC接続設定およびサービス要求手順を実行する(610C)。特に、620Cにおいて、eNodeB 205Dは、MME 215Bから受信されたQoSに基づいてApp* PTTセッションをサポートするApp*のGBRメディアベアラに関してULとDLとの両方で少なくとも閾値のGBR(たとえば、XApp* kbps)を割り当てる。
図6Cを参照して、App*クライアントアプリケーションが、所与のUEがフロアを持って半二重App* PTTセッションを開始すると決定する(625C)(たとえば、図5の500〜515と同様)と仮定する。所与のUEがそのUEのULのメディアベアラに関して設定されたQoS(たとえば、620CにおいてeNodeB 205DによってULのメディアベアラに割り当てられたXApp* kbpsのGBR)をすでに有するので、所与のUE上のApp*クライアントアプリケーションは、XApp* kbpsからGBRの閾値(たとえば、1 kbpsなどの名目的なkbpsのレベル)未満のkbpsのレベルへのDLのメディアベアラに関するQoSの引き下げを要求する。DLのメディアベアラに対するGBRの引き下げは、図6C内では630Cと665Cとの間のシグナリングにおいて示されており、このシグナリングは、LTEに精通した当業者によって容易に理解されるであろう。
図6Cは所与のUEがApp* PTT通話の発信側である例を対象とするが、図6Cはその代わりに所与のUEがApp* PTT通話の呼の着信側であるシナリオに対応するように修正され得ることが理解されるであろう。図6Cの呼の着信側の実装において、呼の着信側のUE上のApp*クライアントアプリケーションは、(605Cと同様のPTTボタンの押下の代わりに)呼告知メッセージによってApp* PTT通話を知り、呼の着信側のUEは、(図6Cと同様のフロア保持者の代わりに)非フロア保持者としてApp* PTT通話を開始する。これらの違い以外は、App*のメディアQoSフローに関するULおよびDLのQoSは、図6Cと同様にして呼の着信側のUEのために管理され得る。また、図6Cには明示的に示されていないが、図6Cは、図6Cの半二重セッションの例の代わりに全二重の例などの図5からのさらなる使用事例(たとえば、図5の565、570など)を包含するように拡張され得る。さらに、図6Cは、所与のUEがRCC-Idle状態にあるときに605CにおいてApp* PTT通話が開始されるようにして説明されているが、図6Cは、RRC-Connected状態にある間に所与のUEにおいてApp* PTT通話が開始される(または着信側のUEの実装に関しては、RRC-Connected状態にある間に所与のUEに告知される)ように修正され得ることが理解されるであろう。
図5〜図6Cは、App*通信セッションのULおよびDLチャネルの選択的なQoS制御のためのUE側のまたはクライアントアプリケーションに基づく手順に関連して説明されているが、図7A〜図7Bは、App*通信セッションに参加するUEの代わりにアプリケーションサーバ170(たとえば、App*通信セッションを調停するように構成されたサーバ)において実施される同様の選択的なQoS制御手順を対象とする。Table 2(表2)(上)において説明されたように、アプリケーションサーバにより支援される方向性を持ったQoS管理手順(すなわち、Table 2(表2)の#2)は、図2DのLTEコアネットワークにおいて実施される可能性があるが、図2Aの1x EV-DOコアネットワーク、または図2B〜図2CのW-CDMAコアネットワーク、または図2EのeHRPDネットワークにおいては規格に準拠した実装ができない可能性がある。
図7Aの説明を要約すると、図7Aの700から770は、以降で述べられることを除いてそれぞれ図5の500から570と同様である。図5は、App*通信セッションに参加する所与のUEにおいてその全体が実施され、一方、図7Aは、App*通信セッションを調停するように構成されたアプリケーションサーバ170において実施される。図5は、1つの特定のUEにおいてApp*クライアントアプリケーションによって実行される手順を表し、一方、図7Aは、通信セッションに参加する各UEのためにアプリケーションサーバ170において実行され得る手順を表す(ただし、少なくとも1つの実施形態において、アプリケーションサーバ170は参加するUEの各々のために図7Aのプロセスを必ずしも実行しない)。図5の所与のUE上のApp*クライアントアプリケーションは、所与のUEにおいてユーザの要求または呼告知メッセージの受信に基づいて図5の500でApp*通信セッションを開始することを決定する可能性があるが、図7Aの700のアプリケーションサーバ170は、発信側のUEからの呼要求メッセージおよび/または告知されたApp*通信セッションの受理を示す着信側のUEからの呼受理メッセージの受信に基づいてApp*通信セッションを開始することを決定する可能性がある。さらに、全二重App*セッションの一部のUEはそれらのUEのセッションをミュートさせる可能性があり、その他のUEはミュートさせない可能性があり、一部のUEは半二重App*セッションのフロア保持者である可能性があり、その他のUEは非フロア保持者である可能性があることが理解されるであろう。したがって、図7Aに示される様々な判断ブロックは、アプリケーションサーバ170によって評価されているUEの各々に関して異なる手順の経路が取られる結果となる可能性がある。最後に、図7Aの手順は、LTEに関連するので、図7Aに示される様々なQoSの評価および修正は、LTEに固有のコアネットワークの要素に当てはまり得る。App*のGBR QoSベアラに関するULのQoSを増やす720における要求は、アプリケーションサーバ170からPCRF 240DまたはP-GW 235Dに発せられる、App*のGBR QoSベアラのULのGBRをXApp* kbpsに上げる要求に対応する可能性があり、App*のGBR QoSベアラのDLのQoSを減らす730における要求は、アプリケーションサーバ170からPCRF 240DまたはP-GW 235Dに発せられる、App*のGBR QoSベアラのDLのGBRをGBRの閾値(たとえば、1 kbpsまたは何らかのその他の名目的なデータレート)未満に減らす要求に対応する可能性があり、以下同様である。これらの違いを別にすると、図7Aの残りの動作は、図5と同様であり、図7AのLTEの実装は、特定の動作が所与のUEからアプリケーションサーバ170に移されること(および潜在的により多くのUEのために実行されること)を除いて図6Cと同様である可能性がある。図7Bの700Bから770Bは図7Aの700から770のさらに詳細な実装をそれぞれ示し、それによって、LTEに固有の構成要素およびメッセージが参照される。
図7Cは、本発明の実施形態による半二重App* PTTセッションに加わる所与のUE(呼の発信側かまたは呼の着信側かのどちらか)に関するLTEネットワーク内での図7Bの例示的な実施を示す。図7Cを参照すると、アプリケーションサーバ170は、所与のUEに関する半二重App* PTT通話を設定することを決定し(700C)(たとえば、図7Bの700Bおよび705Bと同様)、アプリケーションサーバ170は、所与のUEがフロアを有すると判定し、それによって、ULのApp*のGBRベアラに関して最大ビットレート(MBR)を設定し、DLのGBRを1 kbpsなどの低いkbpsに等しく設定する(705C)(たとえば、図7Bの710Bから730Bと同様)。これらの仮定に留意して、710Cから760Cのシグナリングは、ULおよびDLのApp*のGBRベアラの設定がどのようにして実施され得るかのLTEに固有の例を示す。715Cにおいて、たとえば、PCRF 240Dは、アプリケーションサーバ170によって与えられたMBSを、本明細書においてはXApp*と表記される指定されたMBSを実現するための好適なGBR値にマッピングするための論理を実行するLTEコアネットワークの構成要素であることが示される。また、725から750Cの間に示されるシグナリングは、App*のGBRベアラがULおよびDLですでに設定されているシナリオと、さらに、App*のGBRベアラがまだ設定されていないシナリオとを包含する。App*のGBRベアラがすでに設定されている場合、725Cにおいて、ベアラ更新要求メッセージによってDLのApp*のGBRベアラが1 kbps(または何らかのその他の名目的なkbps)に減らされる一方、ULのApp*のGBRベアラはXApp* kbpsに留まる。App*のGBRベアラがまだ設定されていない場合、725Cにおいて、ベアラ作成要求メッセージによってDLのApp*のGBRベアラが名目的なkbpsに設定される一方、ULのApp*のGBRベアラはXApp* kbpsに関して設定される。同様に、App*のGBRベアラがまだ設定されていない場合は、730Cにおいてベアラ設定要求メッセージが使用され、App*のGBRベアラがすでに設定されている場合は、730Cにおいてベアラ修正要求メッセージが使用され
る。同様に、App*のGBRベアラがまだ設定されていない場合は、750Cにおいてベアラ作成応答メッセージが使用され、App*のGBRベアラがすでに設定されている場合は、750Cにおいてベアラ更新応答メッセージが使用される。図7Cに示される残りのシグナリングは、App*のGBRベアラの開始ステータスとは独立しており、LTEに精通した当業者によって容易に理解されるであろう。図7Cは半二重PTTセッションに固有であるが、図7Cがどのようにして全二重セッションまたはPTT以外の半二重セッションに対応するように修正され得るかは容易に理解されるであろう。
図8Aは、本発明の実施形態によるコアネットワークにより開始される方向性を持ったQoS管理手順のより詳細な実施の例を示す。Table 2(表2)(上)において説明されたように、コアネットワークにより開始される方向性を持ったQoS管理手順(すなわち、Table 2(表2)の#3)は、図2B〜図2CのW-CDMAコアネットワーク(「会話」トラフィッククラスがセッションのために使用される場合)および/または図2DのLTEコアネットワークにおいて実施される可能性があるが、図2Aの1x EV-DOコアネットワークまたは図2EのeHRPDネットワークにおいては規格に準拠した実装ができない可能性がある。たとえば、W-CDMAまたはUMTSの実装においては、GGSN 225BまたはSGSN 220Bが、図8Aのプロセスを実行する可能性があり、LTEの実装においては、P-GW 235DまたはS-GW 230Dが、図8Aのプロセスを実行する可能性がある。
図8Aを参照すると、App*通信セッション(たとえば、半二重セッション、全二重セッションなど)のためのGBRメディアベアラの設定の検出に応じて、コアネットワーク140が、App*のGBRメディアベアラ上のULおよびDLトラフィックを監視するデータ無活動タイマー(data inactivity timer)を開始する(800)。どちらの場合も、下で説明されるように、App*のGBRメディアベアラがApp*セッションのためにアクティブ化されると、データ無活動タイマーが、動き始める。
805において、コアネットワーク140が、ULまたはDLトラフィックが通信セッションのためのApp*のGBRメディアベアラ上で検出されるかどうかを判定する。特に、コアネットワーク140は、805において、App*通信セッションのためのアクセスポイント名(APN)に関連するApp*のトラフィック(すなわち、App*APN)がULまたはDL方向で検出されるかどうかを判定する。805においてULまたはDLトラフィックがコアネットワーク140によって検出される場合、トラフィックが検出された各方向(ULおよび/またはDL)に関するトラフィック無活動タイマー(traffic inactivity timer)がリセットされる(810)。815において、トラフィック無活動タイマーがまだ動いている(つまり、まだ切れていない)各方向(ULおよび/またはDL)に関して、コアネットワーク140が、閾値のGBRがそれぞれの方向のApp*のGBRメディアベアラのためにすでに設定されているかどうかを判定する(たとえば、図5の515、525、540、および550と同様)。設定されていない場合、コアネットワーク140は、閾値のGBRをまだ持たない、関連するトラフィック無活動タイマーがまだ動いている各方向(ULまたはDL)のGBRを(たとえば、XApp* kbpsに)増やす(820)。理解されるであろうように、UEは、下で図8Cの855C〜890Cの間および/または図8Dの850D〜865Dの間に示されるように、エンドツーエンド通信によって820のQoSの調整(またはGBRの引き上げ)に関して知らされ得る。
図8Aを参照すると、コアネットワーク140は、ULおよびDLのトラフィック無活動タイマーを監視してULおよびDLのトラフィック無活動タイマーが切れるかどうかを判定する(825)。825において切れたことが検出される場合、コアネットワーク140は、切れたことが検出されるそれぞれの方向のApp*のGBRメディアベアラに関して閾値のGBRがすでに設定されているかどうかを判定する(830)(たとえば、図5の515、525、540、および550と同様)。設定されている場合、コアネットワーク140は、閾値のGBRを有する、切れたことが検出される各方向(ULまたはDL)のGBRを(たとえば、1 kbpsまたは何らかのその他の名目的なレベルに)減らし(835)、その後、コアネットワーク140は、835において減らされた方向性を持ったチャネル上で新しいトラフィックが到着するかどうかを監視し(805)、さらに、コアネットワーク140は、835において減らされなかった他方の方向性を持ったチャネルに関して切れたことが発生するかどうかを監視し続けることができる(825)。理解されるであろうように、UEは、下で図8Cの855C〜890Cの間および/または図8Dの850D〜865Dの間に示されるように、エンドツーエンド通信によって830のQoSの調整(またはGBRの引き下げ)に関して知らされ得る。図8Bの800Bから835Bは、それぞれ、LTEに固有のおよびW-CDMAに固有の構成要素およびメッセージがより明示的に参照される図8Aの800から835のより一層詳細な実施を示す。
図8Cは、本発明の実施形態による何らかのその他のUEによって開始された半二重App* PTTセッションの呼の着信側である所与のUEに関するW-CDMAネットワーク内での図8Bの例示的な実施を示す。図8Cを参照すると、800Cから820Cは、それぞれ、図6Bの600Bから620Bに対応する。825Cにおいて、SGSN 220Bが、ULおよびDLのトラフィック無活動タイマーを開始し、維持する(図8Bの800Bから820Bと同様)。ある時点で、SGSN 220BのULのトラフィック無活動タイマーが切れると仮定する(830C)(たとえば、図8Cの825Bと同様)。したがって、SGSN 220Bは、GGSN 225Bとの835Cおよび840Cのシグナリングによって、App*のULのGBRベアラのそのSGSN 220BのGBRを1 kbpsなどの名目的なレベルに減らす。845Cにおいて、GGSN 225Bが、825CからのSGSN 220Bのタイマーとは独立しているULおよびDLのトラフィック無活動タイマーを(820CにおいてApp*のGBRベアラが立ち上げられた後に)開始し、維持する(図8Bの800Bから820Bと同様)。ある時点で、GGSN 225BのULのトラフィック無活動タイマーが切れると仮定する(850C)(たとえば、図8Cの825Bと同様)。したがって、GGSN 225Bは、855Cから895Cの間のシグナリングによって、App*のULのGBRベアラのGBRを1 kbpsなどの名目的なレベルに減らすようにRAN 120に促す。図8Cは半二重PTTセッションに固有であるが、図8Cがどのようにして全二重セッションまたはPTT以外の半二重セッションに対応するように修正され得るかは容易に理解されるであろう。また、図8Cは呼の着信側のUEに固有であるが、図8Cがどのようにして呼の発信側のUEのために修正され得るかは容易に理解されるであろう(たとえば、805Cにおいてページが受信される代わりに、PTTボタンの押下が検出されるなど)。また、図8Cは、所与のUEがURA_PCH/CELL_PCH状態にある間に805Cにおいてページを受信するところを示すが、代替的な実装において、所与のUEは、代替的に、CELL_DCHにある間にPTT通話の告知を受信する可能性がある。
図8Dは、本発明の実施形態による半二重App* PTTセッションの呼の発信側である所与のUEに関するLTEネットワーク内での図8Bの例示的な実施を示す。図8Dを参照すると、800Dから820Dは、それぞれ、図6Cの600Cから620Cに対応する。825Dにおいて、S-GW 230Dが、ULおよびDLのトラフィック無活動タイマーを開始し、維持する(図8Bの800Bから820Bと同様)。ある時点で、S-GW 230DのDLのトラフィック無活動タイマーが切れると仮定する(830D)(たとえば、図8Cの825Bと同様)。したがって、S-GW 230Dは、App*のDLのGBRベアラのそのS-GW 230DのGBRを1 kbpsなどの名目的なレベルに減らし、GBRの引き下げをP-GW/PCRF 235D/240Dに知らせる(835D)。840Dにおいて、P-GW/PCRF 235D/240Dが、825DからのS-GW 230Dのタイマーとは独立しているULおよびDLのトラフィック無活動タイマーを(820DにおいてApp*のGBRが立ち上げられた後に)開始し、維持する(図8Bの800Bから820Bと同様)。ある時点で、P-GW/PCRF 235D/240Dによって維持されるDLのトラフィック無活動タイマーが切れると仮定する(845D)(たとえば、図8Cの825Bと同様)。したがって、P-GW/PCRF 235D/240Dは、850Dから874Dの間のシグナリングによって、App*のDLのGBRベアラのGBRを1 kbpsなどの名目的なレベルに減らすようにサービングeNodeB 205Dに促す。図8Dは半二重PTTセッションに固有であるが、図8Dがどのようにして全二重セッションまたはPTT以外の半二重セッションに対応するように修正され得るかは容易に理解されるであろう。また、図8Dは呼の発信側のUEに固有であるが、図8Dがどのようにして呼の着信側のUEのために修正され得るかは容易に理解されるであろう(たとえば、805DにおけるPTTボタンの押下の代わりに、PTTのページまたは呼告知メッセージがApp*セッションに関して到着する可能性がある)。また、図8Dは所与のUEがRCC-Idle状態からApp* PTTセッションを始めるところを示すが、代替的な実装において、所与のUEは、すでにRCC-Connected状態にある間にApp* PTTセッションを始める可能性もある。
図9Aは、本発明の実施形態による、GBRリソースがRAN 120およびコアネットワーク140のローカルで管理されるQoS管理手順のより詳細な実施の例を示す。Table 2(表2)(上)において説明されたように、GBRリソースがRAN 120およびコアネットワーク140のローカルで管理されるQoS管理手順(すなわち、Table 2(表2)の#4)は、図2DのLTEコアネットワークにおいて実施される可能性があるが、図2Aの1x EV-DOコアネットワーク、または図2B〜図2CのW-CDMAコアネットワーク、または図2EのeHRPDネットワークにおいては規格に準拠した実装ができない可能性がある。
図9Aを参照すると、App*通信セッション(たとえば、半二重App*セッション、全二重App*セッションなど)のためのApp*のGBRメディアベアラの設定の検出に応じて、通信セッションに参加する特定のUEのためのRAN 120内のサービングeNodeBとコアネットワーク140(たとえば、S-GW 230DおよびP-GW 235D)との両方が、App*のGBRメディアベアラ上のULおよびDLトラフィックを監視するデータ無活動タイマーを開始する(900)。概して、図9Aは、RAN 120がULおよびDLチャネルのQoSリソース(たとえば、GBR)を制御するためにULおよびDLのトラフィック無活動タイマーをやはり維持することを除いて図8Aと同様であるLTEの実装に対応する。言い換えれば、RAN 120およびLTEコアネットワークの構成要素は、RAN 120とLTEコアネットワークとの間の連携(たとえば、シグナリングメッセージ)が異なるエンティティにおいてQoSの調整を実施するために使用される必要がない、つまり、それぞれのLTEの構成要素がその構成要素独自のトラフィック無活動タイマーに基づいて独立してまたは一方的にQoSの判断を行うことができるように、独立してそれらの構成要素のそれぞれのタイマーを実行し、それらの構成要素独自のGBRまたはQoSの調整を行う。理解されるであろうように、これは、UEがRAN 120の無線インターフェースのリソースに関連してそのRAN 120によって実施されるQoSの調整を知らないままであるが、調整されたQoSを用いるベアラが割り振られるUE(またはクライアントデバイス)がコアネットワークにおいて実施されるQoSの調整を知らされる必要がないように、それぞれのLTEの構成要素がGBRまたはQoSを独立して変更することができることを意味する。したがって、デュアルRANおよびコアネットワークの実装を別にすると、図9Aの900〜935は、それぞれ、図8Aの800〜835と同様であり、簡潔にするためにさらに説明されない。図9Bの900Bから935Bは、それぞれ、LTEに固有の構成要素およびメッセージがより明示的に参照される図9Aの900から935のより一層詳細な実施を示す。
図10A〜図10Bは、本発明の実施形態によるW-CDMAアーキテクチャおよびEV-DOアーキテクチャに関連するRANにより開始されるタイマーに基づく方向性を持ったQoSフロー管理手順をそれぞれ示す。Table 2(表2)(上)において説明されたように、RANにより開始されるタイマーに基づく方向性を持ったQoSフロー管理手順(すなわち、Table 2(表2)の#5)は、図2B〜図2CのW-CDMAコアネットワークにおいて実施される可能性があり(図10Aに示される、「インタラクティブ」トラフィッククラスがセッションのために使用される場合)、または図2Aの1x EV-DOコアネットワークにおいて実施される可能性がある(図10Bに示される)が、図2DのLTEネットワークにおいては規格に準拠した実装ができない可能性がある。
W-CDMAに固有の実装を示す図10Aを参照すると、通信セッション(たとえば、半二重App*セッション、全二重App*セッションなど)のためのApp*のデータRABの設定の検出に応じて、RAN 120(すなわち、UTRAN)は、App*のデータRAB上のULおよびDLトラフィックを監視するデータ無活動タイマーを開始する(1000A)。特に、App*のデータRABは、1000Aにおいて、「インタラクティブ」トラフィッククラスを用いて構成され、インジケーション(「はい」)およびARP属性をシグナリングするか、または代替的に、「会話」トラフィッククラスに関連するGBRパラメータが修正され得るように、RAN 120が再構成され得る場合は「会話」トラフィッククラスを用いて構成される可能性がある。
1005Aにおいて、RAN 120は、ULまたはDLトラフィックが通信セッションに関してApp*のデータRAB上で検出されるかどうかを判定する。特に、RAN 120は、1005Aにおいて、App*通信セッションに関するトラフィックがUL方向において検出されるかまたはDL方向において検出されるかを判定する。1005AにおいてULまたはDLトラフィックがRAN 120によって検出される場合、トラフィックが検出された各方向(ULおよび/またはDL)に関するトラフィック無活動タイマーがリセットされる(1010A)。1015Aにおいて、トラフィック無活動タイマーがまだ動いている(つまり、まだ切れていない)各方向(ULおよび/またはDL)に関して、RAN 120が、閾値のGBRがそれぞれの方向のApp*のデータRABのためにすでに設定されているかどうかを判定する(たとえば、図5の515、525、540、および550と同様)。たとえば、1015Aにおいて、RAN 120が、MAC-es/MAC-hsのGBRがデータRABのULおよび/またはDLでXApp* kbpsに設定されるかどうかを調べることができる。設定されていない場合、RNC 215Bが、閾値のGBRをまだ持たない、関連するトラフィック無活動タイマーがまだ動いている各方向(ULまたはDL)のGBRを(たとえば、XApp* kbpsに)増やすようにRAN 120内のサービングNodeBに要求する(1020A)。理解されるであろうように、UEは、QoSの調整が無線インターフェースのリソース(すなわち、UEとRAN 120との間の接続)に関連して実施されるので、1020AのQoSの調整(またはGBRの引き上げ)に関して知らされ得る。
図10Aを参照すると、1025Aにおいて、RAN 120は、ULのデータトラフィックがApp*のデータRAB上で検出されるかどうかをさらに判定し、サービングNodeBは、App*のデータRABがULに関してGBRをサポートするためにスケジューリングされない送信の許可を用いて構成されるかどうかを調べる(1025A)。そうである場合、App*のデータRABに関してサービングNodeBにおいてULのGBRを設定するためにさらなる行為は必要とされない(1030A)。そうでない場合、サービングNodeBが、ULにおいてスケジューリングされない送信の許可のためにApp*のデータRABを再構成する(1035A)。
図10Aを参照すると、RAN 120は、ULおよびDLのトラフィック無活動タイマーを監視してULおよびDLのトラフィック無活動タイマーが切れるかどうかを判定する(1040A)。1040Aにおいて切れたことが検出される場合、RAN 120は、切れたことが検出されるそれぞれの方向のGBRメディアベアラに関して閾値のGBRがまだ設定されていないかどうかを判定する(1045A)(たとえば、図5の515、525、540、および550と同様)。たとえば、1045Aにおいて、RAN 120が、MAC-es/MAC-hsのGBRがApp*のデータRABのULおよび/またはDLでXApp* kbpsに設定されているかどうかを調べることができる。閾値のGBRがタイマーが切れた方向のULまたはDLに関して設定されていない場合、プロセスは1005Aに戻る。そうでなく、閾値のGBRがタイマーが切れた方向のULまたはDLに関して設定されている場合、RNC 215Bが、関連するトラフィック無活動タイマーが切れており、閾値のGBRを有する各方向(ULまたはDL)のGBRを(たとえば、XApp* kbpsに)減らすようにRAN 120内のサービングNodeBに要求する(1050A)。理解されるであろうように、UEは、QoSの調整が無線インターフェースのリソース(すなわち、UEとRAN 120との間の接続)に関連して実施されるので、1050AのQoSの調整(またはGBRの引き下げ)に関して知らされ得る。
図10Aを参照すると、1055Aにおいて、データRABに関して1040AにおいてULのトラフィック無活動タイマーが切れる場合、サービングNodeBは、App*のデータRABがULに関してGBRをサポートするためにスケジューリングされない送信の許可を用いて構成されるかどうかを調べる(1055A)。構成されない場合、さらなる行為は必要とされない(1060A)。そうである場合、サービングNodeBが、ULにおいてスケジューリングされる送信の許可のためにApp*のデータRABを再構成する(1065A)。
1xのEV-DOに固有の実装を示す図10Bに目を向けると、App*通信セッション(たとえば、半二重セッション、全二重セッションなど)のためのメディアQoSフローの設定の検出に応じて、RAN 120が、App*のメディアQoSフローのULおよびDLトラフィックを監視するデータ無活動タイマーを開始する(1000B)。
1005Bにおいて、RAN 120が、ULまたはDLトラフィックが通信セッションのためのApp*のメディアQoSフローで検出されるかどうかを判定する。1005BにおいてULまたはDLトラフィックがRAN 120によって検出される場合、トラフィックが検出された各方向(ULおよび/またはDL)に関するトラフィック無活動タイマーがリセットされる(1010B)。1015Bにおいて、トラフィック無活動タイマーがまだ動いている(つまり、まだ切れていない)各方向(ULおよび/またはDL)に関して、RAN 120が、QoSがそれぞれの方向のApp*のメディアQoSフローのためにすでに設定されているかどうかまたはオンにされているかどうかを判定する(たとえば、図5の515、525、540、および550と同様)。そうである場合、プロセスは、1005Bに戻る。そうでない場合、RAN 120は、活動が検出された方向のApp*のメディアQoSフローをアクティブ化するためにReservationOnMessageを送信する(1020B)。理解されるであろうように、UEは、QoSフローのアクティブ化が無線インターフェースのリソース(すなわち、UEとRAN 120との間の接続)に関連して実施されるので、1020BのQoSフローのアクティブ化に関して知らされ得る。
図10Bを参照すると、RAN 120は、ULおよびDLのトラフィック無活動タイマーを監視してULおよびDLのトラフィック無活動タイマーが切れるかどうかを判定する(1025B)。1025Bにおいて切れたことが検出される場合、RAN 120は、切れたことが検出されるそれぞれの方向のApp*のメディアQoSフローに関してQoSがすでに設定されているかどうかまたはオンにされているかどうかを判定する(1030B)(たとえば、図5の515、525、540、および550と同様)。そうである場合、プロセスは、1005Bに戻る。そうでなく、関連するトラフィック無活動タイマーが切れた方向のApp*のメディアQoSフローに関してQoSが設定されている場合、RAN 120は、切れたことが検出された方向のメディアQoSフローを非アクティブ化するためにReservationOffMessageを送信する(1035B)。理解されるであろうように、UEは、QoSフローの非アクティブ化が無線インターフェースのリソース(すなわち、UEとRAN 120との間の接続)に関連して実施されるので、1035BのQoSフローの非アクティブ化に関して知らされ得る。
ワールドワイドウェブコンソーシアム(W3C)は、インターネット技術タスクフォース(IETF)と一緒に、ウェブリアルタイム通信(WebRTC)と呼ばれるウェブ開発者の技術の開発を2011年に開始した。WebRTCは、ブラウザ(またはエンドポイント)がエンドポイントの相対的な位置とは無関係に(たとえば、それぞれのエンドポイントが同じデバイス上にあるか、同じプライベートネットワーク内にあるか、両方とも別々のネットワークアドレス変換(NAT)および/またはファイアウォールの裏にあるかなどに関わりなく)1つまたは複数のその他のエンドポイントとのピアツーピア(P2P)リアルタイム通信に参加することを許すプロトコルである。
WebRTCは、リアルタイムメディアの送信のためにリアルタイムトランスポートプロトコル(RTP)を利用する。RTPは、多くの異なるメディアタイプのためのトランスポートプロトコルとして働くことができる柔軟なプロトコルである。これらのメディアタイプは、オーディオもしくはビデオにマッピングされるように広く分類される可能性があり、または関連するオーディオもしくはビデオコーデック、帯域幅の要件、オーディオもしくはビデオ解像度などの情報を指定することによってより詳細である可能性がある。さらに、メッシュ会議モデルにおいては、複数のメディアストリームが、クライアントに基づくオーディオミキシングまたはビデオ合成を可能にするためにP2Pで送信される可能性がある。
WebRTCによって通信するエンドポイントはそれぞれのエンドポイントの間のエンドツーエンド接続の数を制限する1つまたは複数のNATおよび/またはファイアウォールによって分けられる可能性があるので、WebRTCは、単一のIPアドレスおよびポートを通じたRTPストリームの多重化を許す。この制限が1つの原因になって、既存のWebRTCの仕様は、多重化がRTPおよびRTP制御プロトコル(RTCP)通信のために使用されることを推奨する。複数のタイプのストリームが1つのIPアドレスおよびポート番号を通じて多重化されるとき、異なるタイプのメディアに区別されたサービス品質(QoS)を提供することは、より困難になる。
たとえば、非WebRTCテレビ会議セッションにおいては、オーディオストリームがビデオストリームと分けられているのが普通であり、それによって、オーディオストリームはQoSリンクに割り当てられ、ビデオストリームは非QoSリンクに割り当てられる。これは、概して、オーディオストリームがビデオストリームよりも少ない帯域幅を消費することと、ビデオストリームが受信機における誤り隠蔽戦略などの手順、前方誤り訂正符号の使用、ビデオ解像度を下げることなどによって助けられ得ることとによる。
WebRTCにおける異なるメディアタイプに関するQoSの区別を得るための通常の手法は、ブラウザ自体において多重化を無効化することである。しかし、これは、ブラウザに対する修正を必要とし、さらに、ブラウザが異なるメディアタイプのための複数のエンドツーエンド接続(つまり、異なるIPアドレスおよびポート番号)を確立することができることを仮定する。
WebRTCにおける異なるメディアタイプに関するQoSの区別を得るためのその他の通常の手法は、3GPPにより定義されたQoSに対応したトラフィックフローがIPパケット差別化サービスコードポイント(DSCP: Differentiated Services Code Point)のマーキングを誘発することを可能にすること、または3GPPにより定義されたQoSに対応したトラフィックフローがRTP同期ソース(SSRC: synchronization source)を誘発することを可能にすることである。しかし、これらの通常の手法の各々は、結果としてパケットフィルタおよびトラフィックフローのテンプレートに影響を与える3GPP規格において変わる。
さらに別の通常の手法は、ブラウザ自体が上述のUEにより開始されるQoSの特徴を利用することであり、それによって、UE上のブラウザが、少なくともオーディオメディアに関してQoSリンクを設定し、多重化を回避しようとする。しかし、この手法は、UEにより開始されるQoSの特徴をトリガするためにアプリケーションタイプによってフローが特定されることを可能にするために、ブラウザに対する変更とWebRTC APTに対する変更との両方を必要とする。
本発明の実施形態は、WebRTCマルチメディアクライアントアプリケーション(たとえば、ブラウザ)および/または3GPPのシグナリングもしくはネットワークの設計に対する修正を必要とせずにWebRTCを利用する通信セッションに関するQoSの区別を得ることを対象とする。高レベルで、下で説明される本発明の実施形態は、WebRTCマルチメディアクライアントアプリケーションから得られた多重化されたRTPストリームから特定のメディアコンポーネントを選択的に多重分離し、さらに、到着するメディアをWebRTCマルチメディアクライアントアプリケーションによって期待される多重化されたフォーマットに選択的に再多重化するプロキシモジュールをUEにプロビジョニングする。
図11は、2つのUEの間のWebRTCセッションに関するトラフィックの通常のフローを示す。図11を参照すると、第1のUE 1100(またはUE 1)が、モバイルブラウジングアプリケーションなどの第1のWebRTCマルチメディアクライアントアプリケーション1105をプロビジョニングされる。WebRTCマルチメディアクライアントアプリケーション1105は、メディア(たとえば、オーディオ、ビデオなど)をWebRTCセッションに関する単一の多重化されたストリーム(「MUX」)に多重化し、それから、1つまたは複数のRTP/RTPCパケット内の多重化されたストリームを単一のIPアドレスおよびポート番号によってサービングネットワーク1110(たとえば、WiFiネットワーク、RAN 120など)に届ける。サービングネットワーク1110は、多重化されたストリームをサービングネットワーク1120に届けるために、NAT/ファイアウォール1115を突き抜けるかまたはNAT/ファイアウォール1115を抜ける接続を開くためのNAT/ファイアウォール横断技法を使用する。サービングネットワーク1120は、UE 1から、別のモバイルブラウジングアプリケーションなどの第2のWebRTCマルチメディアクライアントアプリケーション1130をプロビジョニングされた第2のUE 1125(またはUE 2)に多重化されたストリームを届ける。理解されるであろうように、第1のWebRTCマルチメディアクライアントアプリケーション1105はデフォルトでMUXを生成するので、MUXは、UE 1とUE 2との間の通信がNAT/ファイアウォールを横断することなく可能であるようにUE 1およびUE 2が両方とも同じサービングネットワークによってサービスを提供されているシナリオにおいてやはり使用される。
図12Aは、本発明の実施形態による同じサービングネットワークによってサービスを提供される2つのUEの間のWebRTCセッションに関するトラフィックのフローを示す。図12Aを参照すると、第1のUE 1200(またはUE 1)が、モバイルブラウジングアプリケーションなどの第1のWebRTCマルチメディアクライアントアプリケーション1205(または第1のWebRTCエンドポイント)をプロビジョニングされる。UE 1は、第1のWebRTCプロキシモジュール1210もプロビジョニングされる。下でより詳細に説明されるように、第1のWebRTCプロキシモジュール1210は、第1のWebRTCマルチメディアクライアントアプリケーション1205が送信しようとしている単一の多重化されたストリーム(「MUX」)からメディアの一部を選択的に多重分離し、さらに、別のUE上の別のWebRTCプロキシモジュールによって多重分離された複数の到着するメディアストリームを第1のWebRTCマルチメディアクライアントアプリケーション1205に届けるために単一の多重化されたストリームに「再」多重化するように構成される。
図12Aを参照すると、一例において、第1のWebRTCマルチメディアクライアントアプリケーション1205が、図11のWebRTCマルチメディアクライアントアプリケーション1105と同様に(またはさらにはまったく同じように)構成される可能性がある。言い換えれば、図12Aの実施形態は、動作のために既存のWebRTCマルチメディアクライアントアプリケーションに対するいかなる変更も厳密に必要とせず、WebRTCエンドポイントは、(利用可能な場合)QoSリンクを利用するためにメディアストリームの選択的な多重分離および/または再多重化を実施するためにWebRTCプロキシモジュール1210に依拠しながら「通常通り」動作し続けることができる。
したがって、第1のWebRTCマルチメディアクライアントアプリケーション1205は、メディア(たとえば、オーディオ、ビデオなど)をWebRTCセッションに関する単一の多重化されたストリーム(「MUX」)に多重化し、1つまたは複数のRTP/RTPCパケット内のMUXをサービングネットワーク1110(たとえば、WiFiネットワーク、RAN 120など)に送信しようと試みる。しかし、図12Aにおいては、図11と同様にサービングネットワークにMUXを送信する代わりに、WebRTCプロキシモジュール1210が、特別な処理(つまり、多重分離)のためにMUXを傍受する。
より詳細には、図12Aにおいては、UE 1がQoSリンク(たとえば、図13〜図17に関連して下でより詳細に検討されるプロキシにより開始される、UEにより開始される、および/またはNWによって開始されるQoS獲得手順による)と非QoSリンクとの両方を得ることができると仮定される。本明細書において使用されるとき、「非QoS」リンクという用語は、ゼロQoS(もしくはGBR)を有する任意の接続、ベアラ、もしくはチャネル、または代替的に、ゼロを超えているがQoSリンクが定義されるQoSの閾値未満である「中間」レベルのQoS(またはGBR)を有する接続、ベアラ、またはチャネルを指す可能性がある(それによって、QoSリンクは、閾値以上のレベルのQoSを有する)。
第1のWebRTCプロキシモジュール1210は、第1のWebRTCマルチメディアクライアントアプリケーション1205によって多重化されたストリームへとすでに多重化された優先度のより高いメディアを特定するための1組のQoS規則を適用する。Table 3(表3)(下)は、本発明の実施形態による選択的な多重分離手順の一部として第1のWebRTCプロキシモジュール1210によって施行され得るQoS規則のいくつかの例を提供する。
Figure 0006423439
Table 3(表3)(上)に関して、QoSリンク上で十分なQoSが利用可能である場合は沈黙している期間中またはオーディオの活動期間中に非オーディオデータをQoSリンクに移すなど、特定の非オーディオデータが特定の規則に基づいて非QoSリンクの代わりにQoSリンクにマッピングされる可能性があり、(Table 3(表3)(上)にまとめられた)これらの同じ規則が、非QoSリンクの代わりにQoSリンクにおける送信に関してどのメディアタイプが多重分離されるかを判定するための1組のQoS規則の一部として使用される可能性もあることが理解されるであろう。したがって、QoSリンクで送信されるメディアは、必ずしもオーディオに厳密に限定されず、特定の優先度のより高いタイプのビデオメディアおよび/または非ビデオファイルメディアも含み得る。
再び図12Aに目を向けると、第1のWebRTCプロキシモジュール1210は、1組のQoS規則に基づいて多重化されたストリーム内に存在する優先度のより高いメディアを特定することができる場合、優先度のより低いメディア(たとえば、バルクビデオメディアなど)から優先度のより高いメディア(たとえば、オーディオメディア、および/またはビデオ制御フレーム、Iフレームなどの限られた量のビデオメディア)を多重分離する(または取り去る)。機能的に、第1のWebRTCプロキシモジュール1210が優先度のより高いメディアを含む第1の多重分離されたWebRTCストリーム(「DE-MUX1」)と優先度のより低いメディアを含む第2の多重分離されたWebRTCストリーム(「DE-MUX2」)とを生成する限り、優先度のより低いメディアも、多重化されたストリームから取り去られ得る(または多重分離され得る)ことは理解されるであろう。第1のWebRTCプロキシモジュール1210は、QoSリンクでサービングネットワーク1215にDE-MUX1を送信し、非QoSリンクでサービングネットワーク1215にDE-MUX2を送信する。
さらなる実施形態において、MUXからDE-MUX1およびDE-MUX2を生成する多重分離動作は、コード変換を含む可能性がある。これが当てはまる場合、(たとえば、図14の1435、図15の1540などにおける)提案/返答のやりとりの一部として、WebRTC対応ブラウザによってサポートされるコーデック(たとえば、G.711、Opusなど)が、WebRTCプロキシモジュール1210によって選択され得る。たとえば、スペクトル効率が望ましいとするならば、(基本的に圧伸PCM(companded PCM)である)G.711が、AMR-NBなどのスペクトル効率の高い狭帯域コーデックをコード変換するために選択され得る。一方、スペクトル効率とオーディオ品質との両方が望ましい場合は、広帯域Opusコーデックモードの1つが、AMR-WBへのコード変換のために選択される可能性がある。一例においては、WebRTCセッションをサポートするためにVoLTEが使用される場合、VoLTEベアラのためにOpusがデフォルトで選択される可能性がある。
図12Aを参照すると、第2のUE 1225(またはUE 2)は、第2のWebRTCマルチメディアクライアントアプリケーション1230(または第2のWebRTCエンドポイント)および第2のWebRTCプロキシモジュール1235をプロビジョニングされ、第2のWebRTCマルチメディアクライアントアプリケーション1230(または第2のWebRTCエンドポイント)および第2のWebRTCプロキシモジュール1235は、それぞれ、UE 1の第1のWebRTCマルチメディアクライアントアプリケーション1205および第1のWebRTCプロキシモジュール1210と同様に(またはさらにはまったく同じように)それぞれ構成される可能性がある。UE 1と同様に、UE 2はQoSリンク(たとえば、図13〜図17に関連して下でより詳細に検討されるUEにより開始されるまたはNWによって開始されるQoS獲得手順による)と非QoSリンクとの両方を得ることができるとさらに仮定する。
図12Aの実施形態において、UE 1とUE 2との両方は、DE-MUX1およびDE-MUX2がNAT/ファイアウォール1220を横断する必要がないように同じサービングネットワーク1215によってサービスを提供される。その代わりに、サービングネットワーク1215は、UE 2のQoSリンクでUE 2にDE-MUX1を送信し、UE 2の非QoSリンクでUE 2にDE-MUX2を送信する。第2のWebRTCプロキシモジュール1235は、DE-MUX1およびDE-MUX2を受信し、そして、DE-MUX1とDE-MUX2とを「再」多重化して、第1のWebRTCマルチメディアクライアントアプリケーション1205によって第1のWebRTCプロキシモジュール1210に最初に与えられた多重化されたストリーム(「MUX」)を再構築または再構成する。言い換えれば、第2のWebRTCプロキシモジュール1235は、MUXを再構築するために、第1のWebRTCプロキシモジュール1210によって実行された多重分離手順を元に戻す。それから、第2のWebRTCプロキシモジュール1235は、再構築された(または再多重化された) MUXをWebRTCマルチメディアクライアントアプリケーション1230に与える。
当業者によって理解されるであろうように、UE 1とUE 2とが両方とも同じサービングネットワーク1215によってサービスを提供されており、エンドツーエンドのQoSを得ることができることが1つの理由となって、図12AにおいてWebRTCセッションに関するメディア(たとえば、オーディオメディア、優先度のより高いビデオメディアなど)の一部を転送するためにQoSが使用される。これは、通常、WebRTCマルチメディアクライアントアプリケーションがデフォルトでMUX内の多重化されたメディアの任意の部分に関してQoSを設定することなくMUXをやりとりするので図11においてはあり得ない。
図12Bは、本発明の実施形態による異なるサービングネットワークによってサービスを提供される2つのUEの間のWebRTCセッションに関するトラフィックのフローを示す。図12Bは、図12Aの単一のサービングネットワーク1215が、それぞれUE 1およびUE 2にサービスを提供し、NAT/ファイアウォール1220によって分けられる2つの異なるサービングネットワーク1215Aおよび1215Bによって置き換えられることを除いて図12Aと同様である。
図12Bにおいて、サービングネットワーク1215Aは、UE 2にサービスを提供していないので、DE-MUX1および/またはDE-MUX2をUE 2に直接送信しない。その代わりに、サービングネットワーク1215Aは、DE-MUX1およびDE-MUX2をサービングネットワーク1215Bに届けるために、NAT/ファイアウォール1220を突き抜けるかまたはNAT/ファイアウォール1220を抜ける少なくとも1つの接続を開くためのNAT/ファイアウォール横断技法を使用する。一例において、サービングネットワーク1215Aは、単一のIPアドレスおよびポート番号がDE-MUX1とDE-MUX2との両方をサービングネットワーク1215Bに渡すために使用され得るようにDE-MUX1とDE-MUX2とを単一のストリームにまとめることができ、それによって、そのとき、サービングネットワーク1215Bは、単一のストリームをばらばらにしてDE-MUX1およびDE-MUX2を再構成する。代替的に、サービングネットワーク1215Aは、単純に、DE-MUX1およびDE-MUX2のために2つの異なるIPアドレスおよびポート番号を使用する可能性がある。いずれの場合も、たとえQoSがサービングネットワーク1215Aからサービングネットワーク1215Bへの幹線上で利用不可能であるとしても、QoSは、エンドツーエンドのWebRTCメディア転送の一部がQoSを割り当てられるように少なくともサービングネットワーク内で得られる。
サービングネットワーク1215Bは、UE 2のQoSリンクでUE 2にDE-MUX1を送信し、UE 2の非QoSリンクでUE 2にDE-MUX2を送信する。第2のWebRTCプロキシモジュール1235は、DE-MUX1およびDE-MUX2を受信し、そして、DE-MUX1とDE-MUX2とを「再」多重化して、第1のWebRTCマルチメディアクライアントアプリケーション1205によって第1のWebRTCプロキシモジュール1210に最初に与えられた多重化されたストリーム(「MUX」)を再構築または再構成する。言い換えれば、第2のWebRTCプロキシモジュール1235は、MUX (たとえば、MUXの元のバージョンか、または元のMUXからのメディアコンポーネントの一部もしくはすべての圧縮されたバージョンを含むMUXの圧縮されたもしくは削減された解像度のバージョンなどのMUXの異なるバージョンかのどちらか)を再構築するために、第1のWebRTCプロキシモジュール1210によって実行された多重分離手順を元に戻す。それから、第2のWebRTCプロキシモジュール1235は、再構築された(または再多重化された) MUXをWebRTCマルチメディアクライアントアプリケーション1230に与える。
図12A〜図12BのWebRTCストリームに関連して説明された多重分離および再多重化動作は、UE 1およびUE 2が優先度のより高い多重分離されたWebRTCフローまたはDE-MUX1を運ぶためのQoSリンクを得ることができることに基づく。図12A〜図12Bにおいては、単純に、QoSリンクが利用可能であるが、MUXがバルクビデオコンテンツなどのQoSを通常受信しない構成要素を含むことが1つの理由となり、さらに、WebRTCマルチメディアクライアントアプリケーションがそのそれぞれのUEにおいて利用可能なQoSリソースを特定する能力さえも必ずしも持っていないことが理由となって、概して、WebRTCマルチメディアクライアントアプリケーションは、MUXのためのQoSを獲得しようと試みないと仮定される。
このことを念頭に置いて、図13〜図17は、本発明の実施形態による上で説明された多重分離および/または再多重化動作に関連してWebRTCセッションのためのQoSを選択的に確立するプロセスを示す。特に、図13は、本発明の実施形態による、WebRTCセッションに関するQoSリンクを設定し、その後に、WebRTCセッションの発信側のUEにおいて多重分離を行う高レベルのプロセスを示す。
図13に関しては、所与のUEを含むWebRTCセッションの開始または潜在的な開始を示すシグナリングが、所与のUEにおいてプロビジョニングされたWebRTCマルチメディアクライアントアプリケーション(たとえば、図12Aもしくは図12Bの第1のWebRTCマルチメディアクライアントアプリケーション1205かもしくは第2のWebRTCマルチメディアクライアントアプリケーション1230かのどちらか)、所与のUEにおいてプロビジョニングされたWebRTCプロキシモジュール、所与のUEにサービスを提供しているRAN 120、コアネットワーク140、および/またはアプリケーションサーバ170の間でやりとりされる(1300)。1300からのシグナリングに基づいて、所与のUE上のWebRTCプロキシモジュール、RAN 120、コアネットワーク140、および/またはアプリケーションサーバ170は、それぞれ、1305、1310、1315、または1320において所与のUEにQoSリンクを割り当てるためのQoS設定手順を開始する。
一例においては、1300において、WebRTCセッションは、所与のUEによって開始される可能性があり、その場合、1300のシグナリングは、WebRTCマルチメディアクライアントアプリケーションによって生成され、1305においてUEにより開始されるQoSに関してWebRTCプロキシモジュールによって生成されるセッション開始メッセージを含み得る。この場合、1305は、図5〜図6Cに関連して上で説明されたUEにより開始されるQoS手順といくらか似ており、特に図14のWebRTCの多重分離の実施に関連して下でより詳細に説明される。代替的に、1305のUEにより開始されるQoS手順は、WebRTCセッションが異なるUEによって開始されるシナリオで実施される可能性がある。この場合、WebRTCセッションに関するセッション告知メッセージおよび/またはWebRTCマルチメディアクライアントアプリケーションによって送信されたセッション受理メッセージが、UEによって開始されるQoS手順をトリガするために所与のUEにおいてWebRTCプロキシモジュールによって使用され得る。
さらなる例において、1305は、UEにより開始されるQoS手順として実施される必要がなく、それによって、所与のUEが、そのUEの代わりにQoSを設定するようにRAN 120および/またはコアネットワーク140をトリガする。その代わりに、別のLTEに固有の実施形態においては、他方のエンドポイントがVoLTE互換でありおよび/またはその他方のエンドポイント独自のWebRTCプロキシモジュールを実行している場合、WebRTCプロキシモジュールが、その代わりにエンドツーエンドのVoLTE接続をネゴシエーションする可能性がある。このようにしてエンドツーエンドのVoLTE接続を確立することは、WebRTCのためのQoSベアラのネゴシエーションの柔軟性を制限するが、UEにより開始されるおよび/またはNWにより開始されるQoS手順を実施する必要性をもなくす。本明細書において使用されるとき、QoSの設定のためのエンドツーエンドのVoLTEの実装は、「プロキシにより開始される」QoS手順と呼ばれる。
別の例においては、1300において、WebRTCセッションは、所与のUEによって開始される可能性があり、その場合、1300のシグナリングは、WebRTCマルチメディアクライアントアプリケーションによって生成され、WebRTCプロキシモジュールによって傍受されるセッション開始メッセージを含み得る。そして、WebRTCプロキシモジュールが、アプリケーションサーバ170にメッセージを送信して、所与のUEがQoSリンクを割り当てられる結果となる1320のNWにより開始されるQoS手順を実施するようにアプリケーションサーバ170に促す。この場合、1320は、図7A〜図7Cに関連して上で説明されたサーバに基づくNWにより開始されるQoS手順といくらか似ており、特に図15のWebRTCの多重分離の実施に関連して下でより詳細に説明される。代替的に、1320のサーバに基づくNWにより開始されるQoS手順は、WebRTCセッションが異なるUEによって開始されるシナリオで実施される可能性がある。この場合、WebRTCセッションに関するセッション告知メッセージおよび/またはWebRTCマルチメディアクライアントアプリケーションによって送信されたセッション受理メッセージが、サーバに基づくNWによって開始されるQoS手順を開始するようにアプリケーションサーバ170に促すアプリケーションサーバ170へのメッセージをトリガするために所与のUEにおいてWebRTCプロキシモジュールによって使用され得る。
別の例においては、1300において、所与のUEがWebRTCセッションの発信側であるかどうかに無関係に、RAN 120および/またはコアネットワーク140は、1310および/または1315においてNWにより開始されるQoS手順をトリガするためにアプリケーション特定情報を評価する可能性がありおよび/またはディープパケットインスペクションを実行する可能性がある。たとえば、WebRTCセッションは、App*セッションとして解釈される可能性があり、そのことが、図8A〜図10Bに関連して上で説明されたようにRAN 120および/またはコアネットワークにおけるQoSの設定をトリガする。別の例においては、WebRTCトラフィックのいずれかが、RAN 120および/またはコアネットワーク140によるディープパケットインスペクションによって調べられる可能性がある。この場合、RAN 120および/またはコアネットワーク140は、WebRTCを含むものとしてセッションを特定する場合、所与のUEにQoSリンクを割り当てるためにNWにより開始されるQoS手順をトリガし得る。1310および1315の態様は、図8A〜図10Bに関連して上で説明されたNWにより開始されるQoS手順といくらか似ており、特に図16のWebRTCの多重分離の実施に関連して下でより詳細に説明される。
したがって、1305、1310、1315、および/または1320が実施された後、所与のUEは、QoSリンクと非QoSリンクとの両方を割り当てられる(1325)。WebRTCマルチメディアクライアントアプリケーションは、WebRTCセッション中に送信のための異なるタイプ(たとえば、オーディオ、ビデオなど)のメディアを取得し(1330)、異なるタイプのメディアを多重化ストリーム(「MUX」)に多重化する(1335)。MUXを送信しようと試みる間に、MUXは、その代わりに、所与のUE上のWebRTCプロキシモジュールによって傍受される(1340)。WebRTCプロキシモジュールは、上述の1組のQoS規則を実行して、MUX内に含まれる優先度の高いメディア(たとえば、オーディオメディア、限られた量のビデオメディアなど)を特定する(1345)。そして、WebRTCプロキシモジュールは、1345において特定された優先度のより高いメディアを多重分離して、優先度のより高いメディアを含む第1の多重分離されたWebRTCストリーム(「DE-MUX1」)および任意の残りの優先度のより低いメディアを含む第2の多重分離されたWebRTCストリーム(「DE-MUX2」)を生成する(1350)。WebRTCプロキシモジュールは、QoSリンクを介してRAN 120にDE-MUX1を送信し(1355)、さらに、WebRTCプロキシモジュールは、非QoSリンクでRAN 120にDE-MUX2を送信する(1360)。図13に明示的に示されていないが、そのとき、DE-MUX1およびDE-MUX2は、図12A〜図12Bと同様に、また図17に関連して下でより詳細に説明されるように、着信側のUEに運ばれる可能性がある(図13には示されていない)。
図14は、本発明の実施形態によるUEにより開始されるWebRTCセッションに関するサーバに基づくNWにより開始されるQoS手順に基づく図13のプロセスのLTEに固有の実施を示す。
図14を参照すると、所与のUEは、所与のUE上のWebRTCウェブブラウジングアプリケーション(「ブラウザ」)がWebRTCプロキシモジュールによって傍受される呼開始メッセージを送信するとき(1405)、RRC-Idle状態にある(1400)。呼開始メッセージの受信は、アプリケーションサーバ170がNWにより開始されるQoS手順をトリガすることを要求するアプリケーションサーバ170への独自仕様のメッセージを送信する(1410)ようにWebRTCプロキシモジュールをトリガする。独自仕様のメッセージに応答して、アプリケーションサーバ170は、P-GW 235DおよびPCRF 240DへのRx接続上でベアラのネゴシエーションを開始する(1415)。
再び所与のUEに目を向けると、さらに、呼開始メッセージの受信は、所与のUEをRRC-Idle状態からRRC-Connected状態に遷移させるためにRRC設定手順を実行する(1420)ように所与のUEをトリガする。1420においてRRCの設定が完了するとき、所与のUEはRRC-Connected状態になり(1425)、WebRTCプロキシモジュールはブラウザに接続インジケーションを届ける(1430)。この時点で、所与のUEは、非GBRベアラ(すなわち、非QoSリンク)を有するが、ベアラのネゴシエーションがまだ完了していないのでQoSリンクはまだ持たない(1432)。ブラウザおよびWebRTCプロキシモジュールは、提案/返答のやりとりを実行し(1435)(たとえば、それによって、WebRTCプロキシモジュールが、DE-MUX1および/またはDE-MUX2のために使用されるコード変換コーデックを選択する可能性がある)、その後、ブラウザが、WebRTCセッション中の送信のためのメディアを構成し始める(1440)。
再びネットワークに目を向けると、P-GW 235Dが、MME 215Dにベアラ更新要求を送信し(1445)、MME 215Dが、eNB 205Dにベアラ修正要求を送信し(1450)、そのベアラ修正要求が、RRC接続を再構成するようにeNB 205Dおよび所与のUEに促す(1455)(たとえば、RRC接続再構成/完了)。そして、eNB 205Dが、ベアラ修正応答をMME 215Dに送り返し、MME 215Dが、ベアラ更新応答をP-GW 235Dに送り返す。異なる方法でトリガされるが、1445〜1465は、図7Cの725C〜750Cといくらか似ている。また、WebRTCセッションがApp*セッションである場合、GBRベアラのために確立されるGBRは、図7Cの735Cと同様に、App*(またはこの場合WebRTC)に固有であるQoS構成で構成され得る。
1445〜1465のシグナリングを介してGBRベアラ(またはQoSリンク)を得た後、ブラウザが、MUX(たとえば、送信のための多重化されたメディアコンポーネントを有するRTP/RTCPパケットのストリーム)をWebRTCプロキシに送信し始め(1470)、WebRTCプロキシモジュールが、MUXを多重分離してDE-MUX1およびDE-MUX2を生成し、それから、GBRベアラでDE-MUX1を送信し(1475)、非GBRベアラでDE-MUX2を送信する(1480)。
図15は、本発明の実施形態によるUEにより開始されるQoS手順に基づく図13のプロセスのLTEに固有の実施を示す。
図15を参照すると、所与のUEは、所与のUE上のWebRTCウェブブラウジングアプリケーション(「ブラウザ」)がWebRTCプロキシモジュールによって傍受される呼開始メッセージを送信するとき(1505)、RRC-Idle状態にある(1500)。呼開始メッセージは、所与のUEをRRC-Idle状態からRRC-Connected状態に遷移させるためにRRC設定手順を実行する(1510)ように所与のUEをトリガする。1510においてRRCの設定が完了するとき、所与のUEはRRC-Connected状態になり(1515)、WebRTCプロキシモジュールはブラウザに接続インジケーションを届ける(1520)。この時点で、所与のUEは、非GBRベアラ(すなわち、非QoSリンク)を有するが、ベアラのネゴシエーションがまだ完了していないのでQoSリンクはまだ持たない(1525)。
図15の実施形態においては、WebRTCプロキシモジュールが、QoSリンクを得るためのUEにより開始されるQoS手順を実行することを決定する。一例においては、UEにより開始されるQoS手順が、図14と同様のNWにより開始されるQoS手順がQoSリンクを得ることに失敗する場合にフォールバックメカニズムとして使用され得る。たとえば、図15に示されていないが、WebRTCプロキシモジュールは、図14の1410と同様に独自仕様のメッセージを送信し、次いでタイマーを開始することができ、タイマーが切れる前にQoSリンクが得られない場合、WebRTCプロキシモジュールは、UEにより開始されるQoS手順を実行することができる。代替的に、WebRTCプロキシモジュールは、セッションタイプがWebRTCであることに基づいて、NWにより開始されるQoS手順を初めに試みることを待つことなくUEにより開始されるQoS手順を実行することを自動的に決定する可能性がある。
いずれの場合も、WebRTCプロキシモジュールがUEにより開始されるQoS手順を実施する判断にどのようにして到達するかに関係なく、UEにより開始されるQoS手順は、eNB 205Dを介して所与のUEからMME 215Dにベアラリソース修正要求メッセージを送信することによって実施される(1530)。1530のベアラリソース修正要求メッセージは、WebRTCセッションのオーディオメディアコンポーネント(たとえば、ならびに限られた量のビデオメディアおよび/またはファイルコンテンツなどの潜在的にその他のメディアコンポーネントも)のためのGBRベアラを要求するように構成される。MME 215Dは、ベアラリソース修正要求メッセージを受信し、S-GW 230Dを介してP-GW 235Dにベアラリソースコマンドを届ける(1535)。この時点で、1540〜1585は、1540〜1585が所与のUEによってLTEコアネットワーク140に届けられるメッセージによってトリガされる一方、1435〜1480がアプリケーションサーバ170によってLTEコアネットワーク140に届けられるメッセージによってトリガされることを除いてそれぞれ図14の1435〜1480に実質的に対応する。
図16は、本発明の実施形態による別のNWにより開始されるQoS手順に基づく図13のプロセスの一部の例示的な実施を示す。図16を参照すると、図13の1300においてやりとりされるシグナリングに基づいて、RAN 120および/またはコアネットワーク140が、(図14と同様に)アプリケーションサーバ170または(図15と同様に)所与のUE自体から与えられるそのようにする明示的な要求なしに所与のUEのためのQoSリンクの設定をトリガする。その代わりに、RAN 120および/またはコアネットワーク140が、シグナリング自体を評価して、RAN 120および/またはコアネットワーク140が所与のUEに代わってQoSリンクを先を見越して設定すべきかどうかを検出する(1600)(図13の1310および/または1315と同様)。
特に、RAN 120および/またはコアネットワーク140は、確立されているセッションがWebRTCであることを特定することができ、この特定が、NWにより開始されるQoS手順をトリガするようにRAN 120および/またはコアネットワーク140に促すことができる。WebRTCセッションであるものとしてセッションを特定することは、いくつかの方法で実行され得る。たとえば、WebRTCアプリケーションは、セッションのWebRTCの性質がアプリケーション特定情報(たとえば、APNなど)に基づいて特定され得るように、上で詳細に説明されているApp*に対応する可能性がある。別の例において、RAN 120および/またはコアネットワーク140は、WebRTCセッションの設定中にやりとりされる1つまたは複数のシグナリングパケットに対してディープパケットインスペクションを実行する可能性があり、ディープパケットインスペクションは、セッションがWebRTCセッションであると推測するために使用される可能性がある。1600において評価されるシグナリングは、アップリンクおよび/またはダウンリンクのシグナリングトラフィックに関連付けられる可能性がある。
図13は、WebRTCセッションの発信側のUEにおいて行われる多重分離に焦点を合わせるが、図17は、WebRTCセッションに関するQoSリンクを設定し、その後に、WebRTCセッションの着信側のUEにおいて再多重化を行う高レベルのプロセスを対象とする。もちろん、WebRTCのUEは、図13および図17のプロセスが発信側のUEと着信側のUEとの両方において並列に実施され得るように、双方向または2方向のメディアセッションのための発信側のUEと着信側のUEとの両方である可能性がある。
図17を参照すると、1700〜1725は、1300〜1325に対応し、簡潔にするためにさらに説明されない。1725の後、コアネットワーク140は、(たとえば、図12Aと同様に同じコアネットワーク140によって、または図12Bと同様に異なるサービングネットワークによってサービスを提供される)別のUEからDE-MUX1およびDE-MUX2を得る。1730において、コアネットワーク140は、RAN 120を介して、QoSリンクで所与のUEにDE-MUX1を送信し、非QoSリンクで所与のUEにDE-MUX2を送信する(1730)。WebRTCプロキシモジュールは、WebRTCマルチメディアクライアントアプリケーションへのDE-MUX1およびDE-MUX2の配信の前にそれらのDE-MUX1およびDE-MUX2を傍受し(1735)、WebRTCプロキシモジュールは、DE-MUX1およびDE-MUX2を再多重化してMUXを再構築する(1740)。言い換えれば、上述のように、所与のUE上のWebRTCプロキシモジュールが、他方のUE上のWebRTCマルチメディアクライアントアプリケーションによって最初に準備されたMUXを再び得るために、他方のUE上のWebRTCプロキシモジュールによって実行された多重分離を元に戻すことによってMUXを再構築する。それから、WebRTCプロキシモジュールは、所与のUE上のWebRTCマルチメディアクライアントアプリケーションにMUXを届ける(1745)。
さらに、図14〜図16は、多重「分離」の文脈で所与のUEのためにQoSリンクがどのようにして確立されるのかに関連して図13のプロセスの詳細な実施を示すが、これらの同じQoS設定手順が「再」多重化の文脈に関連して図17の状況で使用され得ることは理解されるであろう。言い換えれば、1700〜1725の間に確立されるQoSリンクは、図14と同様にサーバに基づくNWにより開始されるQoS手順、図15と同様にUEにより開始されるQoS手順、および/または図16と同様にサーバに基づくトリガとは独立しているNWにより開始されるQoS手順によって設定され得る。また、上述のように、所与のUEにおいてプロビジョニングされたWebRTCプロキシモジュールが、図17と同様に別のUEから到着するMUXを再構築するために到着する多重分離されたストリームをやはり再多重化しながら図13と同様に出て行くMUXを多重分離する役割を担うことができるように、同じUEが、図13と図17との両方のプロセスを並列に実行することができる。
さらに、図12A〜図17の実施形態は「元の」または「ソース」MUXおよび「再多重化された」または「再構築された」MUXに言及するが、MUXの元のバージョンおよび再構築されたバージョンは、同一である可能性があり、または代替的にいくらか異なる可能性がある(たとえば、再構築されたMUXは、コード変換またはその他の要因が原因で、元のMUXと比較して特定のメディアコンポーネントに関してより低い解像度を有するように圧縮される可能性があるなど)ことが理解されるであろう。
さらに、図12A〜図17の実施形態は、概して、2つの多重分離されたストリーム(すなわち、DE-MUX1およびDE-MUX2)に言及するが、その他の実施形態は、利用可能なQoSおよび/または非QoSリンクの数に応じて3つ以上の多重分離されたストリーム(たとえば、DE-MUX3、DE-MUX4など)を対象とする可能性があることが理解されるであろう。たとえば、UEが高いQoSを有する第1のQoSリンク、低いQoSを有する第2のQoSリンク、および非QoSリンクにアクセスすることができる場合、WebRTCプロキシモジュールは、優先度の高いメディアによるDE-MUX1、優先度が中程度のメディアによるDE-MUX2、および優先度の低いメディアによるDE-MUX3を生成する可能性がある。そして、WebRTCプロキシモジュールは、第1のQoSリンクでDE-MUX1を送信し、第2のQoSリンクでDE-MUX2を送信し、非QoSリンクでDE-MUX3を送信することができ、以下同様である。
さらなる例において、QoSリンクは、リンクの第1の組に対応する可能性があり、非QoSリンクは、リンクの第2の組に対応する可能性がある。リンクの第1の組は、1つまたは複数のQoSリンクを含む可能性があり、リンクの第2の組は、1つまたは複数の非QoSリンクを含む可能性がある。リンクの第1の組の各リンクは、DE-MUXストリームを運ぶことができ、リンクの第2の組の各リンクも、DE-MUXストリームを運ぶことができる。概して、優先度のより高いメディアは、リンクの第1の組でDE-MUXストリームによって転送され、一方、優先度のより低いメディアは、リンクの第2の組でDE-MUXストリームによって転送される。したがって、UEが複数のQoSリンクおよび/または複数の非QoSリンクにアクセスすることができるシナリオでは、UEは、これらの複数のリンクを利用して複数のDE-MUXストリームを送信することができる(または同じDE-MUXストリームを冗長的に送信することさえもできる)。それによって、実施形態は、さらなるリンク(QoSおよび/または非QoS)が利用可能であるときに単一のDE-MUXストリームがQoSリンクで送信され、単一のDE-MUXストリームが非QoSリンクで送信されることに限定されない。特に、MUXからのさらなる多重分離されたメディアコンポーネントが、上述の「余分な」DE-MUXストリームのいずれかで運ばれ得る。同様に、着信側のUEにおいては、MUXを再構築するために、「余分な」DE-MUXストリームが、DE-MUX1およびDE-MUX2と一緒に再多重化され得る。
本発明の別の実施形態においては、ブラウザにより開始されるマルチメディアトラフィックが多重化されないかまたは部分的に多重化される可能性がある。言い換えれば、WebRTCマルチメディアクライアントアプリケーションからの出力は、必ずしもMUXではなく、非MUX1および非MUX2(すなわち、2つの多重化されていないRTPストリーム)、MUX1およびMUX2(たとえば、2つの部分的に多重化されたRTPストリーム)、または非MUX1およびMUX1(たとえば、多重化されていないRTPストリームおよび多重化されたRTPストリーム)である可能性がある。これらの場合、WebRTCプロキシモジュールは、非QoSおよびQoSリンクへのそれぞれのRTPストリームのマッピングをやはり扱うことができる。例として、ブラウザが1つのRTPストリーム上でオーディオトラフィックを送信/受信し、さらに、別のRTPストリーム上で(ビデオトラックが通話の各参加者に一意である)複数のビデオトラックを送信/受信する参加者が複数いるビデオ通話を仮定する。WebRTCプロキシモジュールは、UEがQoSリンクと非QoSリンクとの両方にアクセスすることができることを知っている可能性があるが、ブラウザ(またはWebRTCマルチメディアクライアントアプリケーション)は、必ずしもこの情報を検出する能力を持たない。したがって、WebRTCマルチメディアクライアントアプリケーションは、RTPストリームを多重分離することを必要としない一方、WebRTCプロキシモジュールは、多重分離動作を実行する代わりに、単純にそれぞれのRTPストリームを適切なリンク(すなわち、QoSリンクおよび非QoSリンク)にマッピングする。
上の実施形態は主にCDMA2000ネットワークの1x EV-DOアーキテクチャ、W-CDMAまたはUMTSネットワークのGPRSアーキテクチャ、および/またはLTEに基づくネットワークのEPSアーキテクチャを参照して説明されたが、その他の実施形態は、その他のタイプのネットワークアーキテクチャおよび/またはプロトコルを対象とする可能性があることが理解されるであろう。
当業者は、情報および信号が様々な異なる技術および技法のうちのいずれかを使用して表され得ることを理解するであろう。たとえば、上の説明全体を通じて言及される可能性があるデータ、命令、コマンド、情報、信号、ビット、シンボル、およびチップは、電圧、電流、電磁波、磁界もしくは磁気的粒子、光場もしくは光学的粒子、またはこれらの任意の組合せによって表され得る。
さらに、当業者は、本明細書において開示された実施形態に関連して説明された様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズムのステップが、電子的なハードウェア、コンピュータソフトウェア、またはこれら両方の組合せとして実装される可能性があることを理解するであろう。ハードウェアとソフトウェアとのこの互換性を明確に示すために、様々な例示的な構成要素、ブロック、モジュール、回路、およびステップが、概してそれらの機能の観点で上で説明された。そのような機能がハードウェアとして実装されるかまたはソフトウェアとして実装されるかは、システム全体に課された特定の用途および設計の制約による。当業者は、説明された機能をそれぞれの特定の用途のために様々な方法で実装し得るが、そのような実装の判断は本発明の範囲からの逸脱をもたらすものと解釈されるべきでない。
本明細書において開示された実施形態に関連して説明された様々な例示的な論理ブロック、モジュール、および回路は、汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)もしくはその他のプログラマブルロジックデバイス、ディスクリートゲートもしくはトランジスタ論理、ディスクリートハードウェア構成要素、または本明細書において説明された機能を実行するように設計されたこれらの任意の組合せを用いて実装または実行され得る。汎用プロセッサはマイクロプロセッサである可能性があるが、別法として、プロセッサは、任意の通常のプロセッサ、コントローラ、マイクロコントローラ、または状態機械である可能性がある。また、プロセッサは、コンピューティングデバイスの組合せ、たとえば、DSPとマイクロプロセッサとの組合せ、複数のマイクロプロセッサ、DSPコアと連携する1つもしくは複数のマイクロプロセッサ、または任意のその他のそのような構成として実装され得る。
本明細書において開示された実施形態に関連して説明された方法、シーケンス、および/またはアルゴリズムは、直接ハードウェアで、プロセッサによって実行されるソフトウェアモジュールで、またはこれら2つの組合せで具現化される可能性がある。ソフトウェアモジュールは、RAMメモリ、フラッシュメモリ、ROMメモリ、EPROMメモリ、EEPROMメモリ、レジスタ、ハードディスク、リムーバブルディスク、CD-ROM、または当技術分野で知られている任意のその他の形態のストレージ媒体に存在する可能性がある。例示的なストレージ媒体は、プロセッサがストレージ媒体から情報を読むことができ、ストレージ媒体に情報を書き込むことができるようにプロセッサに結合される。別法として、ストレージ媒体は、プロセッサに一体化される可能性がある。プロセッサおよびストレージ媒体は、ASIC内に存在する可能性がある。ASICは、ユーザ端末(たとえば、UE)内に存在する可能性がある。別法として、プロセッサおよびストレージ媒体は、ユーザ端末内のディスクリート構成要素として存在する可能性がある。
1つまたは複数の例示的な実施形態において、説明された機能は、ハードウェア、ソフトウェア、ファームウェア、またはこれらの任意の組合せで実装され得る。ソフトウェアにおいて実装される場合、機能は、コンピュータ可読媒体上の1つまたは複数の命令またはコードとして記憶または送信され得る。コンピュータ可読媒体は、ある場所から別の場所へとコンピュータプログラムを転送することを容易にする任意の媒体を含むコンピュータストレージ媒体と通信媒体との両方を含む。ストレージ媒体は、コンピュータによってアクセスされ得る任意の利用可能な媒体である可能性がある。限定ではなく例として、そのようなコンピュータ可読媒体は、RAM、ROM、EEPROM、CD-ROMもしくはその他の光ディスクストレージ、磁気ディスクストレージもしくはその他の磁気ストレージデバイス、または命令もしくはデータ構造の形態で所望のプログラムコードを搬送もしくは記憶するために使用可能であり、コンピュータによってアクセス可能である任意のその他の媒体を含み得る。また、当然、任意の接続がコンピュータ可読媒体と呼ばれる。たとえば、ソフトウェアが、同軸ケーブル、光ファイバケーブル、ツイストペアケーブル、デジタル加入者線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を用いてウェブサイト、サーバ、またはその他のリモートソースから送信される場合、同軸ケーブル、光ファイバケーブル、ツイストペアケーブル、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。本明細書において使用されるとき、ディスク(disk)およびディスク(disc)は、コンパクトディスク(CD: compact disc)、レーザディスク(laser disc)、光ディスク(optical disc)、デジタルバーサタイルディスク(DVD: digital versatile disc)、フロッピー（登録商標）ディスク(floppy disk)、およびブルーレイディスク(Blu-ray（登録商標） disc)を含み、ディスク(disk)が、通常、磁気的にデータを再生する一方、ディスク(disc)は、レーザを用いて光学的にデータを再生する。上記のものの組合せも、コンピュータ可読媒体の範囲に含まれるべきである。
上述の開示は本発明の説明的な実施形態を示すが、添付の請求項で定義される本発明の範囲を逸脱することなしに本明細書において様々な変更および修正がなされ得ることに留意されたい。本明細書において説明された本発明の実施形態による方法の請求項の機能、ステップ、および/または行為は、必ずしもいずれかの特定の順序で実行されない。さらに、本発明の要素が単数形で説明されるか、または特許請求の範囲に記載される可能性があるが、単数への限定が明示的に述べられない限り、複数も想定される。
1...N UE
100 ワイヤレス通信システム
104 無線インターフェース
106 無線インターフェース
108 無線インターフェース
120 RAN
125 アクセスポイント
140 コアネットワーク
140A EPSまたはLTEネットワーク
140B HRPDコアネットワーク
170 アプリケーションサーバ
175 インターネット
200A 基地局
200B NodeB
200D 進化形NodeB
200E 無線基地局
205A 基地局
205B NodeB
205D 進化形NodeB
205E 無線基地局
210A 基地局
210B NodeB
210D 進化形NodeB
210E 無線基地局
215A 基地局コントローラ
215B 無線ネットワークコントローラ
215D モビリティ管理エンティティ
215E 強化型BSCおよび強化型PCF
220A パケット制御機能
220B サービングGPRSサポートノード
220D モビリティ管理エンティティ
220E HRPDサービングゲートウェイ
225A パケットデータサービングノード
225B ゲートウェイGPRSサポートノード
225D ホーム加入者サーバ
230D サービングゲートウェイ
230E PDSN/FA
235A HA
235D パケットデータネットワークゲートウェイ
240D ポリシーおよび課金規則機能
300A UE
300B UE
302 プラットフォーム
305A アンテナ
305B タッチスクリーンディスプレイ
306 トランシーバ
308 特定用途向け集積回路
310 アプリケーションプログラミングインターフェース
310A ディスプレイ
310B 周辺のボタン
312 メモリ
314 データベース
315A ボタン
315B 周辺のボタン
320A キーパッド
320B 周辺のボタン
325B 周辺のボタン
330B フロントパネルボタン
400 通信デバイス
405 論理
410 論理
415 論理
420 論理
425 論理
1100 第1のUE
1105 第1のWebRTCマルチメディアクライアントアプリケーション
1110 サービングネットワーク
1115 NAT/ファイアウォール
1120 サービングネットワーク
1125 第2のUE
1130 第2のWebRTCマルチメディアクライアントアプリケーション
1200 第1のUE
1205 第1のWebRTCマルチメディアクライアントアプリケーション
1210 第1のWebRTCプロキシモジュール
1215 サービングネットワーク
1215A サービングネットワーク
1215B サービングネットワーク
1220 NAT/ファイアウォール
1225 第2のUE
1230 第2のWebRTCマルチメディアクライアントアプリケーション
1235 第2のWebRTCプロキシモジュール

Claims (15)

  1. ウェブリアルタイム通信(WebRTC)セッションに携わっているユーザ機器(UE)においてWebRTCプロキシモジュールを動作させる方法であって、
    リンクの第1の組の各リンクが少なくとも閾値のレベルのサービス品質(QoS)を割り当てられるリンクの前記第1の組、およびリンクの前記第1の組とは異なるリンクの第2の組を取得するステップと、
    前記WebRTCセッション中に、WebRTCマルチメディアクライアントアプリケーションが着信側のUE上の着信側のWebRTCマルチメディアクライアントアプリケーションに届けようと試みている前記WebRTCマルチメディアクライアントアプリケーションからの多重化されたストリームを取得するステップであって、前記多重化されたストリームが、少なくとも第1のメディアコンポーネントおよび第2のメディアコンポーネントを含む、ステップと、
    前記第1のメディアコンポーネントを含む第1の多重分離されたストリームおよび前記第2のメディアコンポーネントを含む第2の多重分離されたストリームを生成するために前記多重化されたストリームを多重分離するステップと、
    前記着信側のUEに届けるためにリンクの前記第1の組からの第1のリンクでサービングネットワークに前記第1の多重分離されたストリームを送信するステップと、
    前記着信側のUEに届けるためにリンクの前記第2の組からの第2のリンクで前記サービングネットワークに前記第2の多重分離されたストリームを送信するステップとを含む、方法。
  2. リンクの前記第2の組の各リンクが、ゼロQoSか、またはゼロQoSを超えており、前記閾値のレベルのQoS未満である中間レベルのQoSかのどちらかを割り当てられるか、または、
    リンクの前記第1の組が、前記第1のリンクのみを含み、リンクの前記第2の組が、前記第2のリンクのみを含む、
    請求項1に記載の方法。
  3. リンクの前記第2の組の少なくとも1つのリンクが、ゼロQoSを割り当てられるか、または、
    リンクの前記第2の組の少なくとも1つのリンクが、前記中間レベルのQoSを割り当てられるか、または、
    前記閾値のレベルのQoSが、リンクの前記第1の組の各リンクに関する少なくとも所与の保証ビットレート(GBR)を含み、
    リンクの前記第2の組の各リンクが、ゼロGBR、および/または前記所与のGBR未満のGBRを有する、
    請求項2に記載の方法。
  4. リンクの前記第1の組が、前記第1のリンクおよび少なくとも1つのさらなるリンクを含み、
    リンクの前記第2の組が、前記第2のリンクのみを含み、
    前記多重化されたストリームが、少なくとも1つのさらなるメディアコンポーネントをさらに含み、多重分離する前記ステップが、前記多重化されたストリームをさらに多重分離して、前記少なくとも1つのさらなるメディアコンポーネントを含む少なくとも1つのさらなる多重分離されたストリームを生成し、前記方法が、
    前記着信側のUEに届けるためにリンクの前記第1の組からの前記少なくとも1つのさらなるリンクで前記サービングネットワークに前記少なくとも1つのさらなる多重分離されたストリームを送信するステップをさらに含む、請求項1に記載の方法。
  5. リンクの前記第2の組が、前記第2のリンクおよび少なくとも1つのさらなるリンクを含み、
    リンクの前記第1の組が、前記第1のリンクのみを含み、
    前記多重化されたストリームが、少なくとも1つのさらなるメディアコンポーネントをさらに含み、多重分離する前記ステップが、前記多重化されたストリームをさらに多重分離して、前記少なくとも1つのさらなるメディアコンポーネントを含む少なくとも1つのさらなる多重分離されたストリームを生成し、前記方法が、
    前記着信側のUEに届けるためにリンクの前記第2の組からの前記少なくとも1つのさらなるリンクで前記サービングネットワークに前記少なくとも1つのさらなる多重分離されたストリームを送信するステップをさらに含む、請求項1に記載の方法。
  6. リンクの前記第1の組が、前記第1のリンクおよび少なくとも1つのさらなるリンクを含み、
    リンクの前記第2の組が、前記第2のリンクおよび1つまたは複数のさらなるリンクを含み、
    前記多重化されたストリームが、少なくとも1つのさらなるメディアコンポーネントをさらに含み、多重分離する前記ステップが、前記多重化されたストリームをさらに多重分離して、前記少なくとも1つのさらなるメディアコンポーネントを含む少なくとも1つのさらなる多重分離されたストリームを生成し、
    前記多重化されたストリームが、1つまたは複数のさらなるメディアコンポーネントをさらに含み、多重分離する前記ステップが、前記多重化されたストリームをさらに多重分離して、前記1つまたは複数のさらなるメディアコンポーネントを含む1つまたは複数のさらなる多重分離されたストリームを生成し、前記方法が、
    前記着信側のUEに届けるためにリンクの前記第1の組からの前記少なくとも1つのさらなるリンクで前記サービングネットワークに前記少なくとも1つのさらなる多重分離されたストリームを送信するステップと、
    前記着信側のUEに届けるためにリンクの前記第2の組からの前記1つまたは複数のさらなるリンクで前記サービングネットワークに前記1つまたは複数のさらなる多重分離されたストリームを送信するステップとをさらに含む、請求項1に記載の方法。
  7. 前記第1のメディアコンポーネントが、前記WebRTCセッションに関するオーディオメディアを含み、前記第2のメディアコンポーネントが、前記WebRTCセッションに関するビデオメディアを含む請求項1に記載の方法。
  8. 前記第1のメディアコンポーネントが、前記WebRTCセッションに関するオーディオメディアおよび優先度のより高いビデオメディアを含み、前記第2のメディアコンポーネントが、前記WebRTCセッションに関する優先度のより低いビデオメディアを含む請求項1に記載の方法。
  9. 前記UEおよび前記着信側のUEが、前記サービングネットワークによってそれぞれサービスを提供され、
    前記UEと前記着信側のUEとの間のエンドツーエンド接続が、前記UEおよび前記着信側のUEが前記サービングネットワークによってそれぞれサービスを提供されていることに基づいてネットワーク間のネットワークアドレス変換(NAT)および/またはネットワーク間のファイアウォールを横断しない、
    請求項1に記載の方法。
  10. 前記着信側のUEが、前記UEにサービスを提供する前記サービングネットワークとは異なる別のサービングネットワークによってサービスを提供され、
    前記UEと前記着信側のUEとの間のエンドツーエンド接続が、前記UEおよび前記着信側のUEが異なるサービングネットワークによってサービスを提供されていることに基づいてネットワーク間のネットワークアドレス変換(NAT)および/またはネットワーク間のファイアウォールを横断する、
    請求項1に記載の方法。
  11. ウェブリアルタイム通信(WebRTC)セッションに携わっているユーザ機器(UE)においてWebRTCプロキシモジュールを動作させる方法であって、
    リンクの第1の組の各リンクが少なくとも閾値のレベルのサービス品質(QoS)を割り当てられるリンクの前記第1の組、およびリンクの前記第1の組とは異なるリンクの第2の組を取得するステップと、
    前記WebRTCセッション中に、リンクの前記第1の組の第1のリンク上のサービングネットワークからの第1のストリームおよびリンクの前記第2の組の第2のリンク上の前記サービングネットワークからの第2のストリームを受信するステップであって、前記第1のストリームおよび前記第2のストリームが、発信側のUEの発信側のWebRTCマルチメディアクライアントアプリケーションが前記UE上のWebRTCマルチメディアクライアントアプリケーションに届けようと試みている多重化されたストリームの多重分離された部分を含む、ステップと、
    前記多重化されたストリームの再構築されたバージョンを生成するために前記第1のストリームおよび前記第2のストリームを再多重化するステップと、
    再多重化されたストリームを前記WebRTCマルチメディアクライアントアプリケーションに届けるステップとを含む、方法。
  12. ウェブリアルタイム通信(WebRTC)セッションに携わっているWebRTCプロキシモジュールを実行するように構成されたユーザ機器(UE)であって、
    リンクの第1の組の各リンクが少なくとも閾値のレベルのサービス品質(QoS)を割り当てられるリンクの前記第1の組、およびリンクの前記第1の組とは異なるリンクの第2の組を取得するための手段と、
    前記WebRTCセッション中に、WebRTCマルチメディアクライアントアプリケーションが着信側のUE上の着信側のWebRTCマルチメディアクライアントアプリケーションに届けようと試みている前記WebRTCマルチメディアクライアントアプリケーションからの多重化されたストリームを取得するための手段であって、前記多重化されたストリームが、少なくとも第1のメディアコンポーネントおよび第2のメディアコンポーネントを含む、手段と、
    前記第1のメディアコンポーネントを含む第1の多重分離されたストリームおよび前記第2のメディアコンポーネントを含む第2の多重分離されたストリームを生成するために前記多重化されたストリームを多重分離するための手段と、
    前記着信側のUEに届けるためにリンクの前記第1の組からの第1のリンクでサービングネットワークに前記第1の多重分離されたストリームを送信するための手段と、
    前記着信側のUEに届けるためにリンクの前記第2の組からの第2のリンクで前記サービングネットワークに前記第2の多重分離されたストリームを送信するための手段とを含む、
    ユーザ機器(UE)。
  13. ウェブリアルタイム通信(WebRTC)セッションに携わっているWebRTCプロキシモジュールを実行するように構成されたユーザ機器(UE)であって、
    リンクの第1の組の各リンクが少なくとも閾値のレベルのサービス品質(QoS)を割り当てられるリンクの前記第1の組、およびリンクの前記第1の組とは異なるリンクの第2の組を取得するための手段と、
    前記WebRTCセッション中に、リンクの前記第1の組の第1のリンク上のサービングネットワークからの第1のストリームおよびリンクの前記第2の組の第2のリンク上の前記サービングネットワークからの第2のストリームを受信するための手段であって、前記第1のストリームおよび前記第2のストリームが、発信側のUEの発信側のWebRTCマルチメディアクライアントアプリケーションが前記UE上のWebRTCマルチメディアクライアントアプリケーションに届けようと試みている多重化されたストリームの多重分離された部分を含む、手段と、
    前記多重化されたストリームの再構築されたバージョンを生成するために前記第1のストリームおよび前記第2のストリームを再多重化するための手段と、
    再多重化されたストリームを前記WebRTCマルチメディアクライアントアプリケーションに届けるための手段とを含む、ユーザ機器(UE)。
  14. ウェブリアルタイム通信(WebRTC)セッションに携わっているWebRTCプロキシモジュールを実行するように構成されたユーザ機器(UE)によって実行されるときに前記UEに請求項1乃至10の何れか1項に記載の方法を実行させる記憶された命令を含む非一時的コンピュータ可読記憶媒体。
  15. ウェブリアルタイム通信(WebRTC)セッションに携わっているWebRTCプロキシモジュールを実行するように構成されたユーザ機器(UE)によって実行されるときに前記UEに請求項11に記載の方法を実行させる記憶された命令を含む非一時的コンピュータ可読記憶媒体。
JP2016542845A 2013-09-16 2014-09-15 ＷｅｂＲＴＣマルチメディアクライアントアプリケーションの代わりにクライアントに基づくＷｅｂＲＴＣプロキシによる選択的な到着するＷｅｂＲＴＣトラフィックの多重化および／または出て行くＷｅｂＲＴＣトラフィックの多重分離 Expired - Fee Related JP6423439B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201361878510P 2013-09-16 2013-09-16
US61/878,510 2013-09-16
US14/484,026 2014-09-11
US14/484,026 US9467480B2 (en) 2013-09-16 2014-09-11 Selectively multiplexing incoming WebRTC traffic and/or de-multiplexing outgoing WebRTC traffic by a client-based WebRTC proxy on behalf of a WebRTC multimedia client application
PCT/US2014/055554 WO2015038997A1 (en) 2013-09-16 2014-09-15 Selectively multplexing incoming webrtc traffic and/or de-multiplexing outgoing webrtc traffic by a client-based webrtc proxy on behalf of a webrtc multimedia client application

Publications (3)

Publication Number Publication Date
JP2016537920A JP2016537920A (ja) 2016-12-01
JP2016537920A5 JP2016537920A5 (ja) 2017-10-12
JP6423439B2 true JP6423439B2 (ja) 2018-11-14

Family

ID=51660604

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016542845A Expired - Fee Related JP6423439B2 (ja) 2013-09-16 2014-09-15 ＷｅｂＲＴＣマルチメディアクライアントアプリケーションの代わりにクライアントに基づくＷｅｂＲＴＣプロキシによる選択的な到着するＷｅｂＲＴＣトラフィックの多重化および／または出て行くＷｅｂＲＴＣトラフィックの多重分離

Country Status (7)

Country Link
US (1) US9467480B2 (ja)
EP (1) EP3047624B1 (ja)
JP (1) JP6423439B2 (ja)
KR (1) KR20160055823A (ja)
CN (1) CN105556923B (ja)
TW (1) TW201521482A (ja)
WO (1) WO2015038997A1 (ja)

Families Citing this family (88)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10111055B2 (en) 2004-11-23 2018-10-23 Kodiak Networks, Inc. Optimized methods for large group calling using unicast and multicast transport bearer for PoC
US10057105B2 (en) 2004-11-23 2018-08-21 Kodiak Networks, Inc. Architecture framework to realize push-to-X services using cloudbased storage services
US10178513B2 (en) 2004-11-23 2019-01-08 Kodiak Networks, Inc. Relay-mode and direct-mode operations for push-to-talk-over-cellular (PoC) using WiFi-technologies
US10116691B2 (en) 2004-11-23 2018-10-30 Kodiak Networks, Inc. VoIP denial-of-service protection mechanisms from attack
US9467480B2 (en) * 2013-09-16 2016-10-11 Qualcomm Incorporated Selectively multiplexing incoming WebRTC traffic and/or de-multiplexing outgoing WebRTC traffic by a client-based WebRTC proxy on behalf of a WebRTC multimedia client application
US9271149B2 (en) * 2013-10-18 2016-02-23 Verizon Patent And Licensing Inc. Managing hidden security features in user equipment
CN104683402B (zh) * 2013-11-29 2019-01-08 华为终端（东莞）有限公司 通信方法和用户设备
US10361585B2 (en) 2014-01-27 2019-07-23 Ivani, LLC Systems and methods to allow for a smart device
KR102279880B1 (ko) * 2014-03-11 2021-07-21 삼성전자 주식회사 무선 통신 시스템에서 베어러의 비트레이트를 동적으로 운영하는 방법 및 장치
WO2015199462A1 (en) * 2014-06-27 2015-12-30 Samsung Electronics Co., Ltd. Method and apparatus for providing quality of service for web-based real-time communication
MX365073B (es) * 2014-10-29 2019-05-22 Kodiak Networks Inc Sistema y metodo para hacer uso de comunicacion web en tiempo real para implementar soluciones de presiona para hablar.
CN107251610B (zh) * 2015-05-20 2020-09-25 松下电器（美国）知识产权公司 通信节点、终端及通信控制方法
CN106506319B (zh) * 2015-09-07 2019-06-25 中国移动通信集团公司 网页实时通信中服务质量会话参数的传递方法及转换网关
US9474042B1 (en) 2015-09-16 2016-10-18 Ivani, LLC Detecting location within a network
US11350238B2 (en) 2015-09-16 2022-05-31 Ivani, LLC Systems and methods for detecting the presence of a user at a computer
US10325641B2 (en) 2017-08-10 2019-06-18 Ivani, LLC Detecting location within a network
US10382893B1 (en) 2015-09-16 2019-08-13 Ivani, LLC Building system control utilizing building occupancy
US11533584B2 (en) 2015-09-16 2022-12-20 Ivani, LLC Blockchain systems and methods for confirming presence
US10665284B2 (en) 2015-09-16 2020-05-26 Ivani, LLC Detecting location within a network
US10455357B2 (en) 2015-09-16 2019-10-22 Ivani, LLC Detecting location within a network
US10321270B2 (en) 2015-09-16 2019-06-11 Ivani, LLC Reverse-beacon indoor positioning system using existing detection fields
WO2017062627A1 (en) * 2015-10-06 2017-04-13 Kodiak Networks, Inc. System and method for improved push-to-talk communication performance
US10129307B2 (en) 2015-10-06 2018-11-13 Kodiak Networks Inc. PTT network with radio condition aware media packet aggregation scheme
FR3043517A1 (fr) * 2015-11-09 2017-05-12 Orange Procede et dispositif de gestion d'une prise de parole depuis un terminal mobile.
US10129853B2 (en) 2016-06-08 2018-11-13 Cognitive Systems Corp. Operating a motion detection channel in a wireless communication network
WO2017215733A1 (en) * 2016-06-14 2017-12-21 Netent Product Services Ltd. Live streaming of media for low-latency applications such as live casino gaming applications
US10785696B2 (en) 2016-06-21 2020-09-22 Huawei Technologies Co., Ltd. Systems and methods for user plane path selection, reselection, and notification of user plane changes
CN107846379B (zh) * 2016-09-18 2021-09-07 中兴通讯股份有限公司 一种视频会议系统中端口复用方法和服务器
US10972552B2 (en) 2016-09-30 2021-04-06 Huawei Technologies Co., Ltd. Method and system for user plane path selection
US10257669B2 (en) 2016-12-01 2019-04-09 Kodiak Networks, Inc. PTX data analytic engine notifying group list of detected risk event
US10630529B2 (en) 2016-12-29 2020-04-21 Kodiak Networks, Inc. System and method for push-to-talk (PTT) in mobile edge computing (MEC)
US10531420B2 (en) * 2017-01-05 2020-01-07 Huawei Technologies Co., Ltd. Systems and methods for application-friendly protocol data unit (PDU) session management
US9743294B1 (en) 2017-03-16 2017-08-22 Cognitive Systems Corp. Storing modem parameters for motion detection
US9927519B1 (en) 2017-03-16 2018-03-27 Cognitive Systems Corp. Categorizing motion detected using wireless signals
US9989622B1 (en) 2017-03-16 2018-06-05 Cognitive Systems Corp. Controlling radio states for motion detection
US10004076B1 (en) 2017-03-16 2018-06-19 Cognitive Systems Corp. Selecting wireless communication channels based on signal quality metrics
US10051414B1 (en) 2017-08-30 2018-08-14 Cognitive Systems Corp. Detecting motion based on decompositions of channel response variations
US11146834B1 (en) 2017-09-28 2021-10-12 Twitch Interactive, Inc. Server-based encoded version selection
US10735783B1 (en) 2017-09-28 2020-08-04 Twitch Interactive, Inc. Intra-rendition latency variation
AU2018352483B2 (en) * 2017-10-19 2023-08-17 Lazar Entertainment Inc. Systems and methods for broadcasting live media streams
US10109167B1 (en) 2017-10-20 2018-10-23 Cognitive Systems Corp. Motion localization in a wireless mesh network based on motion indicator values
US10228439B1 (en) 2017-10-31 2019-03-12 Cognitive Systems Corp. Motion detection based on filtered statistical parameters of wireless signals
US10048350B1 (en) 2017-10-31 2018-08-14 Cognitive Systems Corp. Motion detection based on groupings of statistical parameters of wireless signals
US9933517B1 (en) 2017-11-03 2018-04-03 Cognitive Systems Corp. Time-alignment of motion detection signals using buffers
US10605908B2 (en) 2017-11-15 2020-03-31 Cognitive Systems Corp. Motion detection based on beamforming dynamic information from wireless standard client devices
US10109168B1 (en) 2017-11-16 2018-10-23 Cognitive Systems Corp. Motion localization based on channel response characteristics
US10852411B2 (en) 2017-12-06 2020-12-01 Cognitive Systems Corp. Motion detection and localization based on bi-directional channel sounding
US10264405B1 (en) 2017-12-06 2019-04-16 Cognitive Systems Corp. Motion detection in mesh networks
US10108903B1 (en) 2017-12-08 2018-10-23 Cognitive Systems Corp. Motion detection based on machine learning of wireless signal properties
CN109922472B (zh) 2017-12-13 2021-10-26 华为技术有限公司 用户策略的获取
US10393866B1 (en) 2018-03-26 2019-08-27 Cognitive Systems Corp. Detecting presence based on wireless signal analysis
US11464060B2 (en) * 2018-04-26 2022-10-04 Htc Corporation Device and method of handling a radio resource control reestablishment
FI20185419A1 (en) 2018-05-08 2019-11-09 Telia Co Ab communication Management
US10318890B1 (en) 2018-05-23 2019-06-11 Cognitive Systems Corp. Training data for a motion detection system using data from a sensor device
US11579703B2 (en) 2018-06-18 2023-02-14 Cognitive Systems Corp. Recognizing gestures based on wireless signals
US10986219B2 (en) 2018-06-19 2021-04-20 At&T Intellectual Property I, L.P. LTE fault-tolerant signaling approach
US10455194B1 (en) * 2018-11-27 2019-10-22 Dialogic Corporation Robust handling of sudden changes of bandwidth in selective forwarding unit conferences
US10506384B1 (en) 2018-12-03 2019-12-10 Cognitive Systems Corp. Determining a location of motion detected from wireless signals based on prior probability
US11403543B2 (en) 2018-12-03 2022-08-02 Cognitive Systems Corp. Determining a location of motion detected from wireless signals
US10499364B1 (en) 2019-01-24 2019-12-03 Cognitive Systems Corp. Identifying static leaf nodes in a motion detection system
US10498467B1 (en) 2019-01-24 2019-12-03 Cognitive Systems Corp. Classifying static leaf nodes in a motion detection system
CN109922046B (zh) * 2019-01-30 2021-06-29 广东腾一科技有限公司 一种数据收发系统及方法
JP7316054B2 (ja) * 2019-01-31 2023-07-27 日本無線株式会社 同報配信システム
US10565860B1 (en) 2019-03-21 2020-02-18 Cognitive Systems Corp. Offline tuning system for detecting new motion zones in a motion detection system
US11050800B2 (en) * 2019-04-10 2021-06-29 T-Mobile Usa, Inc. Network assigning QoS for service based on codec exchanged peer-to-peer
US10459074B1 (en) 2019-04-30 2019-10-29 Cognitive Systems Corp. Determining a location of motion detected from wireless signals based on wireless link counting
US10567914B1 (en) 2019-04-30 2020-02-18 Cognitive Systems Corp. Initializing probability vectors for determining a location of motion detected from wireless signals
US10849006B1 (en) 2019-04-30 2020-11-24 Cognitive Systems Corp. Controlling measurement rates in wireless sensing systems
US10600314B1 (en) 2019-04-30 2020-03-24 Cognitive Systems Corp. Modifying sensitivity settings in a motion detection system
US10743143B1 (en) 2019-05-15 2020-08-11 Cognitive Systems Corp. Determining a motion zone for a location of motion detected by wireless signals
US10404387B1 (en) 2019-05-15 2019-09-03 Cognitive Systems Corp. Determining motion zones in a space traversed by wireless signals
US10460581B1 (en) 2019-05-15 2019-10-29 Cognitive Systems Corp. Determining a confidence for a motion zone identified as a location of motion for motion detected by wireless signals
CN114365503A (zh) 2019-07-23 2022-04-15 拉扎尔娱乐公司 实况媒体内容递送系统和方法
WO2021030369A1 (en) 2019-08-12 2021-02-18 Social Microphone, Inc. Optimizing data priority by managing network resources
US11006245B2 (en) 2019-09-30 2021-05-11 Cognitive Systems Corp. Detecting a location of motion using wireless signals and topologies of wireless connectivity
US11570712B2 (en) 2019-10-31 2023-01-31 Cognitive Systems Corp. Varying a rate of eliciting MIMO transmissions from wireless communication devices
CN114599991A (zh) 2019-10-31 2022-06-07 认知系统公司 引发来自无线通信装置的mimo传输
WO2021081635A1 (en) 2019-10-31 2021-05-06 Cognitive Systems Corp. Using mimo training fields for motion detection
US10928503B1 (en) 2020-03-03 2021-02-23 Cognitive Systems Corp. Using over-the-air signals for passive motion detection
US11304254B2 (en) 2020-08-31 2022-04-12 Cognitive Systems Corp. Controlling motion topology in a standardized wireless communication network
CN112423007B (zh) * 2020-11-09 2022-07-08 杭州叙简科技股份有限公司 一种基于组播的webrtc的视频流传输系统
US11070399B1 (en) 2020-11-30 2021-07-20 Cognitive Systems Corp. Filtering channel responses for motion detection
BE1029154B1 (fr) * 2021-03-01 2022-09-27 Selfsun Dispositif et procédé pour une interaction entre un public et des acteurs
CN113613291B (zh) * 2021-08-12 2024-02-02 中国联合网络通信集团有限公司 一种下行gbr业务流传送方法、终端及流量控制单元
JP2023081226A (ja) 2021-11-30 2023-06-09 株式会社リコー 通信管理装置、通信システム、通信管理方法、及びプログラム
US11381628B1 (en) * 2021-12-22 2022-07-05 Hopin Ltd Browser-based video production
CN115037978B (zh) * 2022-07-13 2023-08-25 北京字跳网络技术有限公司 投屏方法及相关设备
CN115442348B (zh) * 2022-11-09 2023-01-24 成都华栖云科技有限公司 一种基于多协议多终端交互的教学实时互动方法及系统

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7552239B2 (en) * 2001-05-14 2009-06-23 Canon Information Systems, Inc. Network device mimic support
US8265069B2 (en) * 2005-06-23 2012-09-11 Nokia Corporation System, terminal, method, and computer program product for establishing a transport-level connection with a server located behind a network address translator and/or firewall
EP2127230A4 (en) 2007-02-09 2014-12-31 Onmobile Global Ltd METHOD AND APPARATUS FOR ADAPTING MULTIMEDIA CONTENT IN TELECOMMUNICATIONS NETWORKS
EP2317733A1 (en) * 2009-10-29 2011-05-04 British Telecommunications public limited company Communications system
US8335192B2 (en) * 2010-04-13 2012-12-18 Qualcomm Incorporated Selectively transitioning between physical-layer networks during a streaming communication session within a wireless communications system
US8553631B2 (en) * 2010-09-30 2013-10-08 Motorola Solutions, Inc. Methods for reducing set up time for communications among multiple user equipment in a long term evolution system
US20120287784A1 (en) * 2011-05-10 2012-11-15 Cisco Technology, Inc. System and method for integrated quality of service in a wireless network environment
US20140044123A1 (en) 2011-05-23 2014-02-13 Twilio, Inc. System and method for real time communicating with a client application
EP2745477B1 (en) * 2011-08-18 2016-04-27 VID SCALE, Inc. Methods and systems for packet differentiation
US9319459B2 (en) * 2011-09-19 2016-04-19 Cisco Technology, Inc. Services controlled session based flow interceptor
WO2013108121A2 (en) * 2012-01-17 2013-07-25 IPalive AB A device, software module, system or business method for global real-time telecommunication
US9578546B2 (en) 2012-08-31 2017-02-21 Qualcomm Incorporated Directional adjustment to quality of service based on predicted traffic activity on a link
US9497659B2 (en) 2012-08-31 2016-11-15 Qualcomm Incorporated Directional adjustment to quality of service based on monitored traffic activity on a link
US9055554B2 (en) * 2012-12-12 2015-06-09 At&T Intellectual Property I, L.P. Management of voice communications over long term evolution networks
US8861692B1 (en) * 2013-05-15 2014-10-14 Verizon Patent And Licensing Inc. Web call access and egress to private network
US9444746B2 (en) 2013-06-25 2016-09-13 Qualcomm Incorporated Selectively transferring high-priority non-audio data over a quality of service channel
US9467480B2 (en) * 2013-09-16 2016-10-11 Qualcomm Incorporated Selectively multiplexing incoming WebRTC traffic and/or de-multiplexing outgoing WebRTC traffic by a client-based WebRTC proxy on behalf of a WebRTC multimedia client application

Also Published As

Publication number Publication date
EP3047624A1 (en) 2016-07-27
EP3047624B1 (en) 2017-07-05
WO2015038997A1 (en) 2015-03-19
CN105556923A (zh) 2016-05-04
JP2016537920A (ja) 2016-12-01
KR20160055823A (ko) 2016-05-18
US9467480B2 (en) 2016-10-11
US20150078295A1 (en) 2015-03-19
TW201521482A (zh) 2015-06-01
CN105556923B (zh) 2018-08-03

Similar Documents

Publication Publication Date Title
JP6423439B2 (ja) ＷｅｂＲＴＣマルチメディアクライアントアプリケーションの代わりにクライアントに基づくＷｅｂＲＴＣプロキシによる選択的な到着するＷｅｂＲＴＣトラフィックの多重化および／または出て行くＷｅｂＲＴＣトラフィックの多重分離
KR102125771B1 (ko) 링크 상의 예측된 트래픽 활성도에 기초한 서비스 품질
EP2891359B1 (en) Adjustment to quality of service based on predicted traffic activity on a link
JP6370810B2 (ja) ウェブクライアントベースセッションのためのサービス品質
KR101832721B1 (ko) 셀룰라를 통한 서비스들에 대한 동적 서비스 품질 (qos)
US9554389B2 (en) Selectively allocating quality of service to support multiple concurrent sessions for a client device
WO2014036334A2 (en) Providing service based on quality of service resources in a long term evolution communications system
WO2016069312A1 (en) Exchanging floor arbitration history information during a communication session

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170901

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20170901

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20180919

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20180921

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20181018

R150 Certificate of patent or registration of utility model

Ref document number: 6423439

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees