JP5778853B2 - 共通のｐｄｐコンテキストを共有するためのシステムおよび方法 - Google Patents

Description

本発明は、無線通信に関する。

セルラーデータネットワークに接続するデバイスの数が増え続けているため、所望のレベルのＱｏＳ（quality of service）を保持しながらネットワークリソースをさらに効率よく利用すべきという圧力が高まっている。ＭＴＣ（machine type communication）デバイスは、次世代のセルラーネットワークにアクセスするデバイスのうちのますます大きなシェアを占めることが予想される。セルラーネットワークにアクセスするＭＴＣデバイスの数は、「従来の」デバイス（例えば、携帯電話およびその他のＵＥ（user equipment））よりも数桁多くなる可能性があると予想する人々もいる。ＭＴＣデバイスの多くは、相対的に静的であり、および／または、しばしば突発するトラフィックを生成する量は少ないと言える。しかし、これらのＭＴＣデバイスは、標準的な量のシグナリングを生成する能力を有しており、これが意味しているのは、ネットワークは依然として、これらのデバイスが、より従来的な量のデータをタイムリーな様式で送信および／または受信できるようにすべきであるということである。したがって、システムは、依然として十分なサービスをこれらのデバイスに提供しつつも、ネットワークにおける最適化されたリソース利用との間でバランスを取るように規定されるべきである。

3GPP specification TR 22.368 3GPP TS 33.102

本明細書において開示されているのは、複数のデバイスの間において１つのＰＤＰ（packet data protocol）コンテキストを共有するための方法およびデバイスである。例えば、複数のデバイス間において１つのＰＤＰコンテキストを共有する方法は、ＰＤＰコンテキストを確立または修正したいという要求をＷＴＲＵ（wireless transmit/receive unit）が送信するステップを含むことができる。ＰＤＰコンテキストを確立または修正したいという要求は、ＷＴＲＵが共有コンテキストグループのメンバーであるという表示（indication）を含むことができる。この方法は、ＰＤＰコンテキストを確立または修正したいという要求が受け入れられたことを示す応答をＷＴＲＵが受信するステップを含むこともできる。この方法は、ＷＴＲＵが共有コンテキストグループ内の少なくとも１つの他のデバイスのためのゲートウェイとして機能するステップを含むこともできる。ＰＤＰコンテキストを確立または修正したいという要求は、接続要求とすることができる。ＷＴＲＵが共有コンテキストグループのメンバーであるという表示は、グループＩＤ（identification）とすることができる。

この方法は、ＷＴＲＵが１つまたは複数のコアネットワークノードとの間で認証を行うステップをさらに含むことができる。ＷＴＲＵは、１つまたは複数のコアネットワークノードとの間で認証を行うときに、共有コンテキストグループのメンバーである少なくとも１つの他のデバイスを認証することができる。ＷＴＲＵは、共有コンテキストグループのメンバーである複数の他のデバイスの複数の認証応答に基づいて１つの認証応答を判定することができる。ＰＤＰコンテキストを確立または修正したいという要求は、１つの共通のＰＤＰコンテキストを共有している共有コンテキストグループのメンバーである複数のデバイスに複数のＩＰ（internet protocol）アドレスが割り当てられるよう求める要求を含むことができる。ＷＴＲＵが共有コンテキストグループのメンバーであるという表示は、ＥＰＳ（evolved packet service）接続タイプ情報要素（attach type information element）内に含めることができる。共有コンテキストグループ内の少なくとも１つの他のデバイスは、非３ＧＰＰデバイスとすることができる。

ＷＴＲＵが、ＰＤＰコンテキストを確立または修正したいという要求を送信する。ＰＤＰコンテキストを確立または修正したいという要求は、ＷＴＲＵが共有コンテキストグループのメンバーであるという表示を含むことができる。ＷＴＲＵは、ＰＤＰコンテキストを確立または修正したいという要求が受け入れられたことを示す応答を受信することができる。共有コンテキストグループ内の少なくとも１つの他のデバイスは、ＷＴＲＵとの間でＰＤＰコンテキストを共有することができる。ＷＴＲＵは、共有コンテキストグループ内の少なくとも１つの他のデバイスとの間で１つのＩＰアドレスを共有することができる。ＷＴＲＵが共有コンテキストグループのメンバーであるという表示は、グループＩＭＳＩ（international mobile subscriber identity）とすることができる。ＷＴＲＵは、少なくとも１つのコアネットワークノードとの間で認証を実行することができる。共有コンテキストグループ内のデバイスに関する認証のシーケンスが存在することができる。ＷＴＲＵは、共有コンテキストグループ内のデバイスに関する認証のシーケンスを動的に特定することができる。ＰＤＰコンテキストを確立または修正したいという要求が受け入れられたことを示す応答は、共有コンテキストグループに割り当てられているＩＰアドレスの数と、開始ＩＰアドレスとを示すことができる。ＰＤＰコンテキストを確立または修正したいという要求が受け入れられたことを示す応答は、共有コンテキストグループ内のデバイスに割り当てられるインターネットプロトコルアドレスを明示的に示すことができる。

１つのパケットデータプロトコルコンテキストを共有するためのコアネットワークノードにおける方法およびデバイスを提供する。例えば、１つのＰＤＰコンテキストを共有するための方法は、ＰＤＰ（packet data protocol）コンテキストを確立または修正したいという要求を受信するステップを含むことができる。ＰＤＰコンテキストを確立または修正したいという要求は、ＷＴＲＵが共有コンテキストグループのメンバーであるという表示を含むことができる。この方法は、共有コンテキストグループのメンバーである少なくとも１つの他のデバイスがそれまでにＰＤＰコンテキストを確立していると判定するステップをさらに含むことができる。この方法は、ＷＴＲＵによって使用するために、それまでに確立されているＰＤＰコンテキストから共有デフォルトベアラを割り当てるステップをさらに含むことができる。この方法は、ＰＤＰコンテキストを確立または修正したいという要求が受け入れられたことを示す応答を送信するステップをさらに含むことができる。この方法は、共有デフォルトベアラを現在利用している共有コンテキストグループ内のデバイスの数のカウントを保持するステップをさらに含むことができる。ＰＤＰコンテキストを確立または修正したいという要求は、接続要求とすることができる。コアネットワークノードは、ＷＴＲＵに関するロケーション更新手順を実行するのを差し控えることができる。コアネットワークノードは、ＭＭＥ（mobility management entity）またはＳＧＳＮ（serving gateway support node）の一方とすることができる。この方法は、共有コンテキストグループに関するグループ識別子、およびＷＴＲＵに関する個別の識別子に基づいてＷＴＲＵを認証するステップをさらに含むことができる。ＷＴＲＵは、ＭＴＣ（machine type communications）ゲートウェイとすることができる。

以降の説明から、より詳細な理解を得ることができ、以降の説明は、例として添付の図面とともに与えられている。
１つまたは複数の開示されている実施形態を実施可能な例示的な通信システムのシステム図である。 図１Ａにおいて示されている通信システム内で使用可能な例示的なＷＴＲＵのシステム図である。 図１Ａにおいて示されている通信システム内で使用可能な例示的な無線アクセスネットワークおよび例示的なコアネットワークのシステム図である。 図１Ａにおいて示されている通信システム内で使用可能な別の例示的な無線アクセスネットワークおよび例示的なコアネットワークのシステム図である。 図１Ａにおいて示されている通信システム内で使用可能な別の例示的な無線アクセスネットワークおよび例示的なコアネットワークのシステム図である。 共有ＰＤＰコンテキストが採用されている例示的なＵＭＴＳアーキテクチャを示す図である。 共有ＰＤＰコンテキストが採用されている例示的なＬＴＥアーキテクチャを示す図である。 共有ＰＤＰコンテキストの作成および／またはメンテナンスのための例示的な接続手順を示す図である。 ＬＴＥシステムにおける例示的なユーザプレーンベアラバインディング機能（user-plane bearer binding function）を示す図である。 ＵＭＴＳシステムにおけるバインディングのためのＮＳＡＰＩ（Network layer Service Access Point Identifier）、ＲＢ ＩＤ、および／またはＲＡＢ ＩＤの例示的な使用を示す図である。 Ｅ−ＵＴＲＡＮにおいてセキュリティキーをやり取りする例示的な構成（example E-UTRAN Security Key Exchange configuration）を示す図である。 マシンタイプ通信のための例示的な３ＧＰＰアーキテクチャを示す図である。 ＭＴＣサーバと通信状態にあるＭＴＣゲートウェイデバイスを伴う例示的な展開を示す図である。 ゲートウェイポート転送とともに使用するための例示的な通信プロトコルスタックを示す図である。 ルータとして機能するゲートウェイとともに使用するための例示的な通信プロトコルスタックを示す図である。 共有ＰＤＰコンテキストの作成および／またはメンテナンスのための別の例示的な接続手順を示す図である。 ＭＴＣサーバとコアネットワークとの間においてインターフェースを取るように構成されているＭＴＣ−ＩＷＦを含む例示的なアーキテクチャを示す図である。 例示的なＰＤＰコンテキストアクティブ化手順を示す図である。 例示的なＰＤＰコンテキスト修正手順を示す図である。

例示的な実施形態に関する詳細な説明について、様々な図を参照しながら説明する。この説明は、可能な実施態様の詳細な例を提供するが、それらの詳細は、例示的なものであり、本出願の範囲を限定するものではないという点に留意されたい。

図１Ａは、１つまたは複数の開示されている実施形態を実施可能な例示的な通信システム１００の図である。通信システム１００は、コンテンツ、例えば、音声、データ、ビデオ、メッセージング、放送などを複数の無線ユーザに提供する多元接続方式とすることができる。通信システム１００は、複数の無線ユーザが、無線帯域幅を含むシステムリソースの共有を通じてそのようなコンテンツにアクセスできるようにする。例えば、通信システム１００は、１つまたは複数のチャネルアクセス方法、例えば、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ−ＦＤＭＡ（single-carrier FDMA）などを採用できる。

図１Ａにおいて示されているように、通信システム１００は、ＷＴＲＵ（wireless transmit/receive unit）１０２ａ、１０２ｂ、１０２ｃ、および／または１０２ｄ（全体としてまたは総称してＷＴＲＵ１０２と呼ばれる場合がある）、ＲＡＮ（radio access network）１０３／１０４／１０５、コアネットワーク１０６／１０７／１０９、ＰＳＴＮ１０８、インターネット１１０、並びにネットワーク１１２を含むことができるが、開示されている実施形態では、任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素が考えられるということが分かるであろう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのそれぞれは、無線環境において動作および／または通信を行うように構成されている任意のタイプのデバイスとすることができる。例えば、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、無線信号を送信および／または受信するように構成することができ、ＵＥ、移動局、固定式または移動式のサブスクライバユニット、ページャ、セルラー電話、ＰＤＡ、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、無線センサ、家庭用電化製品などを含むことができる。

通信システム１００は、基地局１１４ａおよび基地局１１４ｂを含むこともできる。基地局１１４ａ、１１４ｂのそれぞれは、コアネットワーク１０６／１０７／１０９、インターネット１１０、および／またはネットワーク１１２などの１つまたは複数の通信ネットワークへのアクセスを容易にするために、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの少なくとも１つと無線でインターフェースを取るように構成されている任意のタイプのデバイスとすることができる。例えば、基地局１１４ａ、１１４ｂは、ＢＴＳ（base transceiver station）、Ｎｏｄｅ−Ｂ、ｅＮｏｄｅ Ｂ、Ｈｏｍｅ Ｎｏｄｅ Ｂ、Ｈｏｍｅ ｅＮｏｄｅ Ｂ、サイトコントローラ、ＡＰ、無線ルータなどとすることができる。基地局１１４ａ、１１４ｂは、それぞれ単一の要素として示されているが、基地局１１４ａ、１１４ｂは、任意の数の相互接続された基地局および／またはネットワーク要素を含むことができるということがわかるであろう。

基地局１１４ａは、ＲＡＮ１０３／１０４／１０５の一部とすることができ、ＲＡＮ１０３／１０４／１０５は、他の基地局および／またはネットワーク要素（図示せず）、例えば、ＢＳＣ（base station controller）、ＲＮＣ（radio network controller）、中継ノードなどを含むこともできる。基地局１１４ａおよび／または基地局１１４ｂは、特定の地理的領域内で無線信号を送信および／または受信するように構成することができ、この地理的領域は、セル（図示せず）と呼ばれることもある。セルは、複数のセルセクタへとさらに分割することができる。例えば、基地局１１４ａに関連付けられているセルは、３つのセクタに分割することができる。したがって一実施形態においては、基地局１１４ａは、３つのトランシーバ、すなわち、セルのそれぞれのセクタごとに１つのトランシーバを含むことができる。別の実施形態においては、基地局１１４ａは、ＭＩＭＯ技術を採用することができ、したがって、セルのそれぞれのセクタごとに複数のトランシーバを利用することができる。

基地局１１４ａ、１１４ｂは、エアインターフェース１１５／１１６／１１７を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの１つまたは複数と通信できる。エアインターフェース１１５／１１６／１１７は、任意の適切な無線通信リンク（例えば、ＲＦ（radio frequency）、マイクロ波、ＩＲ（infrared）、ＵＶ（ultraviolet）、可視光など）とすることができる。エアインターフェース１１５／１１６／１１７は、任意の適切なＲＡＴ（radio access technology）を使用して確立できる。

より具体的には、上述したように、通信システム１００は、多元接続方式とすることができ、１つまたは複数のチャネルアクセス方式、例えば、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ−ＦＤＭＡなどを採用することができる。例えば、ＲＡＮ１０３／１０４／１０５内の基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＵＴＲＡ（UMTS(Universal Mobile Telecommunications System) Terrestrial Radio Access）などの無線技術を実施することができる。この無線技術は、Ｗ−ＣＤＭＡを使用してエアインターフェース１１５／１１６／１１７を確立することができる。Ｗ−ＣＤＭＡは、ＨＳＰＡ（High-Speed Packet Access）および／またはＨＳＰＡ＋（Evolved HSPA）などの通信プロトコルを含むことができる。ＨＳＰＡは、ＨＳＤＰＡ（High-Speed Downlink Packet Access）および／またはＨＳＵＰＡ（High-Speed Uplink Packet Access）を含むことができる。

別の実施形態においては、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、Ｅ−ＵＴＲＡ（Evolved UMTS Terrestrial Radio Access）などの無線技術を実施することができ、この無線技術は、ＬＴＥ（登録商標）（Long Term Evolution）および／またはＬＴＥ−Ａ（LTE-Advanced）を使用してエアインターフェース１１５／１１６／１１７を確立することができる。

他の実施形態においては、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、無線技術、例えば、ＩＥＥＥ ８０２．１６（すなわち、ＷｉＭＡＸ）、ＣＤＭＡ２０００、ＣＤＭＡ２０００ １Ｘ、ＣＤＭＡ２０００ ＥＶ−ＤＯ、ＩＳ−２０００（Interim Standard 2000）、ＩＳ−９５、ＩＳ−８５６、ＧＳＭ（登録商標）（Global System for Mobile communications）、ＥＤＧＥ（Enhanced Data rates for GSM Evolution）、ＧＥＲＡＮ（GSM EDGE）などを実施することができる。

図１Ａにおける基地局１１４ｂは、例えば、無線ルータ、Ｈｏｍｅ Ｎｏｄｅ Ｂ、Ｈｏｍｅ ｅＮｏｄｅ Ｂ、またはアクセスポイントとすることができ、局所的なエリア、例えば、事業所、家庭、乗り物、キャンパスなどにおける無線接続を容易にするために、任意の適切なＲＡＴを利用することができる。一実施形態においては、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ＷＬＡＮ（wireless local area network）を確立するために、ＩＥＥＥ ８０２．１１などの無線技術を実施できる。別の実施形態においては、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ＷＰＡＮ（wireless personal area network）を確立するために、ＩＥＥＥ ８０２．１５などの無線技術を実施できる。さらに別の実施形態においては、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ピコセルまたはフェムトセルを確立するために、セルラーベースのＲＡＴ（例えば、Ｗ−ＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ−Ａなど）を利用できる。図１Ａにおいて示されているように、基地局１１４ｂは、インターネット１１０への直接接続を有することができる。したがって、基地局１１４ｂは、コアネットワーク１０６／１０７／１０９を介してインターネット１１０にアクセスする必要がない。

ＲＡＮ１０３／１０４／１０５は、コアネットワーク１０６／１０７／１０９と通信状態にあることが可能であり、コアネットワーク１０６／１０７／１０９は、音声、データ、アプリケーション、および／またはＶｏＩＰサービスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの１つまたは複数に提供するように構成されている任意のタイプのネットワークとすることができる。例えば、コアネットワーク１０６／１０７／１０９は、呼制御、課金サービス、モバイル位置情報サービス、プリペイド電話、インターネット接続、ビデオ配信などを提供すること、および／またはユーザ認証などのハイレベルセキュリティ機能を実行することができる。図１Ａにおいては示されていないが、ＲＡＮ１０３／１０４／１０５および／またはコアネットワーク１０６／１０７／１０９は、ＲＡＮ１０３／１０４／１０５と同じＲＡＴまたは異なるＲＡＴを採用している他のＲＡＮと直接または間接の通信状態にあることが可能であるということが分かるであろう。例えば、コアネットワーク１０６／１０７／１０９は、Ｅ−ＵＴＲＡ無線技術を利用している可能性があるＲＡＮ１０３／１０４／１０５に接続されていることに加えて、ＧＳＭ無線技術を採用している別のＲＡＮ（図示せず）と通信状態にあることも可能である。

コアネットワーク１０６／１０７／１０９は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄがＰＳＴＮ１０８、インターネット１１０、および／または他のネットワーク１１２にアクセスするためのゲートウェイとして機能することもできる。ＰＳＴＮ１０８は、ＰＯＴＳ（plain old telephone service）を提供する回線交換電話ネットワークを含むことができる。インターネット１１０は、ＴＣＰ／ＩＰインターネットプロトコル群におけるＴＣＰ、ＵＤＰおよびＩＰなど、共通の通信プロトコルを使用する相互接続されたコンピュータネットワークおよびデバイスからなるグローバルシステムを含むことができる。ネットワーク１１２は、他のサービスプロバイダによって所有および／または運営されている有線または無線の通信ネットワークを含むことができる。例えば、ネットワーク１１２は、ＲＡＮ１０３／１０４／１０５と同じＲＡＴまたは異なるＲＡＴを採用している可能性がある１つまたは複数のＲＡＮに接続されている別のコアネットワークを含むことができる。

通信システム１００内のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのいくつかまたは全ては、マルチモード機能を含みうる。すなわち、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、別々の無線リンクを介して別々の無線ネットワークと通信するために複数のトランシーバを含むことができる。例えば、図１Ａにおいて示されているＷＴＲＵ１０２ｃは、セルラーベースの無線技術を採用している可能性がある基地局１１４ａ、およびＩＥＥＥ ８０２無線技術を採用している可能性がある基地局１１４ｂと通信するように構成することができる。

図１Ｂは、例示的なＷＴＲＵ１０２のシステム図である。図１Ｂにおいて示されているように、ＷＴＲＵ１０２は、プロセッサ１１８、トランシーバ１２０、送信／受信要素１２２、スピーカー／マイクロフォン１２４、キーパッド１２６、ディスプレイ／タッチパッド１２８、非リムーバブルメモリ１３０、リムーバブルメモリ１３２、電源１３４、ＧＰＳチップセット１３６、および他の周辺機器１３８を含むことができる。ＷＴＲＵ１０２は、一実施形態との整合性を保持しながら、上述の要素同士の任意の下位組合せを含むことができるということが分かるであろう。また、基地局１１４ａおよび１１４ｂ、並びに／または、基地局１１４ａおよび１１４ｂが相当することができるノード（数ある中でも、ＢＴＳ、Ｎｏｄｅ−Ｂ、サイトコントローラ、ＡＰ、ｈｏｍｅ ｎｏｄｅ−Ｂ、ｅＮｏｄｅＢ、ＨｅＮＢ、ｈｏｍｅ ｅｖｏｌｖｅｄ ｎｏｄｅ−Ｂゲートウェイ、およびプロキシノードなどであるが、それらには限定されない）は、図１Ｂにおいて示され本明細書において説明されている要素のいくつかまたは全てを含むことができるということが複数の実施形態で考えられる。

プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、ＤＳＰ（digital signal processor）、複数のマイクロプロセッサ、ＤＳＰコアと関連付けられている１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、ＡＳＩＣ、ＦＰＧＡ回路、その他の任意のタイプのＩＣ（integrated circuit）、状態マシンなどとすることができる。プロセッサ１１８は、信号コーディング、データ処理、電力制御、入力／出力処理、および／またはＷＴＲＵ１０２を無線環境内で機能できるようにする他の任意の機能を実行できる。プロセッサ１１８は、トランシーバ１２０に結合でき、トランシーバ１２０は、送信／受信要素１２２に結合できる。図１Ｂは、プロセッサ１１８とトランシーバ１２０を別々のコンポーネントとして示しているが、プロセッサ１１８とトランシーバ１２０は、１つの電子パッケージまたはチップ内に統合できるということが分かるであろう。

送信／受信要素１２２は、エアインターフェース１１５／１１６／１１７を介して、基地局（例えば、基地局１１４ａ）に信号を送信するように、または基地局（例えば、基地局１１４ａ）から信号を受信するように構成することができる。例えば、一実施形態においては、送信／受信要素１２２は、ＲＦ信号を送信および／または受信するように構成されているアンテナとすることができる。別の実施形態においては、送信／受信要素１２２は、例えば、ＩＲ信号、ＵＶ信号、または可視光信号を送信および／または受信するように構成されているエミッタ／検知器とすることができる。さらに別の実施形態においては、送信／受信要素１２２は、ＲＦ信号と光信号の両方を送信および受信するように構成することができる。送信／受信要素１２２は、無線信号の任意の組合せを送信および／または受信するように構成できるということが分かるであろう。

また、送信／受信要素１２２は、図１Ｂにおいては単一の要素として示されているが、ＷＴＲＵ１０２は、任意の数の送信／受信要素１２２を含むことができる。より具体的には、ＷＴＲＵ１０２は、ＭＩＭＯ技術を採用することができる。したがって、一実施形態においては、ＷＴＲＵ１０２は、エアインターフェース１１５／１１６／１１７を介して無線信号を送信および受信するために、複数の送信／受信要素１２２（例えば、複数のアンテナ）を含むことができる。

トランシーバ１２０は、送信／受信要素１２２によって送信される信号を変調するように、また、送信／受信要素１２２によって受信される信号を復調するように構成できる。上述したように、ＷＴＲＵ１０２は、マルチモード機能を有することができる。したがってトランシーバ１２０は、ＷＴＲＵ１０２が、例えばＵＴＲＡおよびＩＥＥＥ ８０２．１１など、複数のＲＡＴを介して通信できるようにするために複数のトランシーバを含むことができる。

ＷＴＲＵ１０２のプロセッサ１１８は、スピーカー／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８（例えば、ＬＣＤ（liquid crystal display）ディスプレイユニットまたはＯＬＥＤ（organic light-emitting diode）ディスプレイユニット）に結合することができ、そこからユーザ入力データを受け取ることができる。プロセッサ１１８は、ユーザデータをスピーカー／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８へ出力することもできる。また、プロセッサ１１８は、非リムーバブルメモリ１３０および／またはリムーバブルメモリ１３２など、任意のタイプの適切なメモリの情報にアクセスすること、およびそれらのメモリにデータを格納することができる。非リムーバブルメモリ１３０は、ＲＡＭ、ＲＯＭ、ハードディスク、または他の任意のタイプのメモリストレージデバイスを含むことができる。リムーバブルメモリ１３２は、ＳＩＭ（subscriber identity module）カード、メモリスティック、ＳＤ（secure digital）メモリカードなどを含むことができる。他の実施形態においては、プロセッサ１１８は、サーバまたはホームコンピュータ（図示せず）上など、ＷＴＲＵ１０２上に物理的に配置されていないメモリからの情報にアクセスすること、およびそのメモリにデータを格納することが可能である。

プロセッサ１１８は、電源１３４から電力を受け取ることができ、また、ＷＴＲＵ１０２内の他のコンポーネントへの電力を分配および／または制御するように構成することができる。電源１３４は、ＷＴＲＵ１０２に電力供給するための任意の適切なデバイスとすることができる。例えば、電源１３４は、１つまたは複数の乾電池（例えば、ＮｉＣｄ（nickel-cadmium）、ＮｉＺｎ（nickel-zinc）、ＮｉＭＨ（nickel metal hydride）、Ｌｉ−ｉｏｎ（lithium-ion）など）、太陽電池、燃料電池などを含むことができる。

プロセッサ１１８は、ＧＰＳチップセット１３６に結合することもできる。ＧＰＳチップセット１３６は、ＷＴＲＵ１０２の現在位置に関する位置情報（例えば、経度および緯度）を提供するように構成できる。ＧＰＳチップセット１３６からの情報に加えて、またはその情報の代わりに、ＷＴＲＵ１０２は、基地局（例えば、基地局１１４ａ、１１４ｂ）からエアインターフェース１１５／１１６／１１７を介して位置情報を受信すること、および／または複数の近隣の基地局から受信されている信号のタイミングに基づいて自分の位置を特定することができる。ＷＴＲＵ１０２は、一実施形態との整合性を保持しながら、任意の適切な位置特定方法を通じて位置情報を得ることができるということが分かるであろう。

プロセッサ１１８は、他の周辺機器１３８にさらに結合することができる。他の周辺機器１３８は、さらなる特徴、機能、および／または有線接続若しくは無線接続を提供する１つまたは複数のソフトウェアモジュールおよび／またはハードウェアモジュールを含むことができる。例えば、周辺機器１３８は、加速度計、ｅ−コンパス、衛星トランシーバ、デジタルカメラ（写真またはビデオ用）、ＵＳＢポート、振動デバイス、テレビジョントランシーバ、ハンドフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、ＦＭラジオユニット、デジタルミュージックプレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザなどを含むことができる。

図１Ｃは、一実施形態によるＲＡＮ１０３およびコアネットワーク１０６のシステム図である。上述したように、ＲＡＮ１０３は、エアインターフェース１１５を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するためにＵＴＲＡ無線技術を採用できる。ＲＡＮ１０３は、コアネットワーク１０６と通信状態にあることも可能である。図１Ｃにおいて示されているように、ＲＡＮ１０３は、Ｎｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃを含むことができる。これらのＮｏｄｅ−Ｂはそれぞれ、エアインターフェース１１５を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するために１つまたは複数のトランシーバを含むことができる。Ｎｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃはそれぞれ、ＲＡＮ１０３内の特定のセル（図示せず）に関連付けることができる。ＲＡＮ１０３は、ＲＮＣ１４２ａ、１４２ｂを含むこともできる。ＲＡＮ１０３は、一実施形態との整合性を保持しながら、任意の数のＮｏｄｅ−ＢおよびＲＮＣを含むことができるということが分かるであろう。

図１Ｃにおいて示されているように、Ｎｏｄｅ−Ｂ１４０ａ、１４０ｂは、ＲＮＣ１４２ａと通信状態にあることが可能である。また、Ｎｏｄｅ−Ｂ１４０ｃは、ＲＮＣ１４２ｂと通信状態にあることが可能である。Ｎｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃは、Ｉｕｂインターフェースを介してそれぞれのＲＮＣ１４２ａ、１４２ｂと通信することができる。ＲＮＣ１４２ａ、１４２ｂは、Ｉｕｒインターフェースを介して互いに通信状態にあることが可能である。ＲＮＣ１４２ａ、１４２ｂのそれぞれは、自分が接続されているそれぞれのＮｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃを制御するように構成することができる。また、ＲＮＣ１４２ａ、１４２ｂのそれぞれは、他の機能、例えば、アウターループ電力制御、負荷制御、アドミッション制御、パケットスケジューリング、ハンドオーバ制御、マクロダイバーシティ、セキュリティ機能、データ暗号化などを実行またはサポートするように構成することができる。

図１Ｃにおいて示されているコアネットワーク１０６は、ＭＧＷ（media gateway）１４４、ＭＳＣ（mobile switching center）１４６、ＳＧＳＮ（serving GPRS support node）１４８、および／またはＧＧＳＮ（gateway GPRS support node）１５０を含むことができる。上述の要素のそれぞれは、コアネットワーク１０６の一部として示されているが、これらの要素のいずれかが、コアネットワークオペレータ以外のエンティティによって所有および／または運営されることも可能であるということが分かるであろう。

ＲＡＮ１０３内のＲＮＣ１４２ａは、ＩｕＣＳインターフェースを介してコアネットワーク１０６内のＭＳＣ１４６に接続することができる。ＭＳＣ１４６は、ＭＧＷ１４４に接続することができる。ＭＳＣ１４６およびＭＧＷ１４４は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、従来の地上通信線の通信デバイスとの間における通信を容易にするために、ＰＳＴＮ１０８などの回線交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供することができる。

ＲＡＮ１０３内のＲＮＣ１４２ａは、ＩｕＰＳインターフェースを介してコアネットワーク１０６内のＳＧＳＮ１４８に接続することもできる。ＳＧＳＮ１４８は、ＧＧＳＮ１５０に接続することができる。ＳＧＳＮ１４８およびＧＧＳＮ１５０は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、ＩＰ対応デバイスとの間における通信を容易にするために、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供することができる。

上述したように、コアネットワーク１０６は、ネットワーク１１２に接続することもでき、ネットワーク１１２は、他のサービスプロバイダによって所有および／または運営されている他の有線または無線のネットワークを含むことができる。

図１Ｄは、一実施形態によるＲＡＮ１０４およびコアネットワーク１０７のシステム図である。上述したように、ＲＡＮ１０４は、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するためにＥ−ＵＴＲＡ無線技術を採用できる。ＲＡＮ１０４は、コアネットワーク１０７と通信状態にあることも可能である。

ＲＡＮ１０４は、ｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃを含むことができるが、ＲＡＮ１０４は、一実施形態との整合性を保持しながら、任意の数のｅＮｏｄｅ−Ｂを含むことができるということが分かるであろう。ｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃはそれぞれ、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するために１つまたは複数のトランシーバを含むことができる。一実施形態においては、ｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃは、ＭＩＭＯ技術を実施することができる。したがって、ｅＮｏｄｅ−Ｂ１６０ａは、例えば、ＷＴＲＵ１０２ａに無線信号を送信するために、およびＷＴＲＵ１０２ａから無線信号を受信するために、複数のアンテナを使用することができる。

ｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃのそれぞれは、特定のセル（図示せず）に関連付けることができ、無線リソース管理の決定、ハンドオーバの決定、アップリンクおよび／またはダウンリンクにおけるユーザのスケジューリングなどを取り扱うように構成することができる。図１Ｄにおいて示されているように、ｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃは、Ｘ２インターフェースを介して互いに通信できる。

図１Ｄにおいて示されているコアネットワーク１０７は、ＭＭＥ（mobility management gateway）１６２、サービングゲートウェイ１６４、およびＰＤＮ（packet data network）ゲートウェイ１６６を含むことができる。上述の要素のそれぞれは、コアネットワーク１０７の一部として示されているが、これらの要素のいずれかが、コアネットワークオペレータ以外のエンティティによって所有および／または運営されることも可能であるということが分かるであろう。

ＭＭＥ１６２は、Ｓ１インターフェースを介してＲＡＮ１０４内のｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃのそれぞれに接続することができ、制御ノードとして機能することができる。例えば、ＭＭＥ１６２は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザを認証すること、ベアラのアクティブ化／非アクティブ化、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの最初の接続中に特定のサービングゲートウェイを選択することなどを担当することができる。ＭＭＥ１６２は、ＲＡＮ１０４と、ＧＳＭまたはＷ−ＣＤＭＡなどの他の無線技術を採用している他のＲＡＮ（図示せず）との間における切り替えを行うための制御プレーン機能を提供することもできる。

サービングゲートウェイ１６４は、Ｓ１インターフェースを介してＲＡＮ１０４内のｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃのそれぞれに接続することができる。サービングゲートウェイ１６４は一般に、ユーザデータパケットをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃへ／ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃから回送および転送することができる。サービングゲートウェイ１６４は、他の機能、例えば、ｅＮｏｄｅ Ｂ間でのハンドオーバ中にユーザプレーンを固定すること、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにとってダウンリンクデータが利用可能である場合にページングをトリガーすること、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのコンテキストを管理および記憶することなどを実行することもできる。

サービングゲートウェイ１６４は、ＰＤＮゲートウェイ１６６に接続できる。ＰＤＮゲートウェイ１６６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、ＩＰ対応デバイスとの間における通信を容易にするために、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供することができる。

コアネットワーク１０７は、他のネットワークとの通信を容易にすることができる。例えば、コアネットワーク１０７は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、従来の地上通信線の通信デバイスとの間における通信を容易にするために、ＰＳＴＮ１０８などの回線交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供できる。例えば、コアネットワーク１０７は、コアネットワーク１０７とＰＳＴＮ１０８との間におけるインターフェースとして機能するＩＰゲートウェイ（例えば、ＩＭＳ（IP multimedia subsystem）サーバ）を含むことができ、またはそうしたＩＰゲートウェイと通信できる。また、コアネットワーク１０７は、ネットワーク１１２へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供することができ、ネットワーク１１２は、他のサービスプロバイダによって所有および／または運営されている他の有線または無線のネットワークを含むことができる。

図１Ｅは、一実施形態によるＲＡＮ１０５およびコアネットワーク１０９のシステム図である。ＲＡＮ１０５は、エアインターフェース１１７を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するためにＩＥＥＥ８０２．１６無線技術を採用しているＡＳＮ（access service network）とすることができる。以降でさらに論じるように、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、ＲＡＮ１０５、およびコアネットワーク１０９という別々の機能エンティティの間における通信リンクは、参照点（reference point）として定義することができる。

図１Ｅにおいて示されているように、ＲＡＮ１０５は、基地局１８０ａ、１８０ｂ、１８０ｃ、およびＡＳＮゲートウェイ１８２を含むことができるが、ＲＡＮ１０５は、一実施形態との整合性を保持しながら、任意の数の基地局およびＡＳＮゲートウェイを含むことができるということが分かるであろう。基地局１８０ａ、１８０ｂ、１８０ｃはそれぞれ、ＲＡＮ１０５内の特定のセル（図示せず）に関連付けることができ、エアインターフェース１１７を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するために１つまたは複数のトランシーバを含むことができる。一実施形態においては、基地局１８０ａ、１８０ｂ、１８０ｃは、ＭＩＭＯ技術を実施することができる。したがって、基地局１８０ａは、例えば、ＷＴＲＵ１０２ａに無線信号を送信するために、およびＷＴＲＵ１０２ａから無線信号を受信するために、複数のアンテナを使用することができる。基地局１８０ａ、１８０ｂ、１８０ｃは、モビリティ管理機能、例えば、ハンドオフのトリガリング、トンネルの確立、無線リソース管理、トラフィックの分類、ＱｏＳポリシーの実施などを提供することもできる。ＡＳＮゲートウェイ１８２は、トラフィックアグリゲーションポイントとして機能することができ、ページング、サブスクライバプロファイルのキャッシング、コアネットワーク１０９へのルーティングなどを担当することができる。

ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、ＲＡＮ１０５との間におけるエアインターフェース１１７は、ＩＥＥＥ８０２．１６規格を実施するＲ１参照点として定義できる。また、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのそれぞれは、コアネットワーク１０９との論理インターフェース（図示せず）を確立できる。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、コアネットワーク１０９との間における論理インターフェースは、Ｒ２参照点として定義できる。このＲ２参照点は、認証、許可、ＩＰホスト構成管理、および／またはモビリティ管理のために使用することができる。

基地局１８０ａ、１８０ｂ、１８０ｃのそれぞれの間における通信リンクは、ＷＴＲＵのハンドオーバ、および基地局同士の間におけるデータの転送を容易にするためのプロトコルを含むＲ８参照点として定義できる。基地局１８０ａ、１８０ｂ、１８０ｃと、ＡＳＮゲートウェイ１８２との間における通信リンクは、Ｒ６参照点として定義できる。このＲ６参照点は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのそれぞれに関連付けられているモビリティイベントに基づいてモビリティ管理を容易にするためのプロトコルを含むことができる。

図１Ｅにおいて示されているように、ＲＡＮ１０５は、コアネットワーク１０９に接続できる。ＲＡＮ１０５と、コアネットワーク１０９との間における通信リンクは、例えば、データ転送およびモビリティ管理機能を容易にするためのプロトコルを含むＲ３参照点として定義できる。コアネットワーク１０９は、ＭＩＰ−ＨＡ（mobile IP home agent）１８４、ＡＡＡ（authentication, authorization, accounting）サーバ１８６、およびゲートウェイ１８８を含むことができる。上述の要素のそれぞれは、コアネットワーク１０９の一部として示されているが、これらの要素のいずれかが、コアネットワークオペレータ以外のエンティティによって所有および／または運営されてもよいということが分かるであろう。

ＭＩＰ−ＨＡ１８４は、ＩＰアドレス管理を担当することができ、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃが、別々のＡＳＮおよび／または別々のコアネットワークの間においてローミングできるようにする。ＭＩＰ−ＨＡ１８４は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、ＩＰ対応デバイスとの間における通信を容易にするために、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供することができる。ＡＡＡサーバ１８６は、ユーザ認証と、ユーザサービスをサポートすることとを担当することができる。ゲートウェイ１８８は、他のネットワークと相互作用することを容易にすることができる。例えば、ゲートウェイ１８８は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、従来の地上通信線の通信デバイスとの間における通信を容易にするために、ＰＳＴＮ１０８などの回線交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供することができる。また、ゲートウェイ１８８は、ネットワーク１１２へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供することができ、ネットワーク１１２は、他のサービスプロバイダによって所有および／または運営されている他の有線または無線のネットワークを含むことができる。

図１Ｅにおいては示されていないが、ＲＡＮ１０５は、他のＡＳＮに接続でき、コアネットワーク１０９は、他のコアネットワークに接続できるということが分かるであろう。ＲＡＮ１０５と、他のＡＳＮとの間における通信リンクは、Ｒ４参照点として定義することができる。このＲ４参照点は、ＲＡＮ１０５と、他のＡＳＮとの間においてＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのモビリティをコーディネートするためのプロトコルを含むことができる。コアネットワーク１０９と、他のコアネットワークとの間における通信リンクは、Ｒ５参照点として定義できる。このＲ５リファレンスは、ホームコアネットワークと、訪問先コアネットワークとの間における相互作用を容易にするためのプロトコルを含むことができる。

ＭＴＣデバイスの激増は、データオーバーロードおよびトラフィック混雑を含む様々なネットワーク関連の問題につながる可能性がある。例えば、複数のＭＴＣデバイスのそれぞれが、最小限の信号トラフィックを生成するように個々に構成されている場合でさえ、オペレーション中の非常に多くのそのようなデバイスの影響が重なると、大量のトラフィックボリュームが生成されて、関連付けられているネットワークがオーバーロードになる可能性がある状況に至る場合がある。例えば、ネットワークを介して通信状態にあるＭＴＣデバイスの数は、ＷＴＲＵおよび／またはＵＥなどの「従来の」デバイスよりも数桁多くなる可能性があると予想されている。そのような多数のデバイスがネットワークへの接続を試みている状態で、ネットワークオーバーロードが生じる可能性があるのは、多数のデバイスが、実質的に同じ時点でネットワークへの接続を試みている状況、並びに／または多数のデバイスが、メッセージの送信および／若しくは受信を、実質的に同じ時点および／若しくは周期性（例えば、センサ測定の報告、若しくは他の定期的な報告）で行う状況（それらのメッセージそのものは、少量のデータしか搬送しない場合でさえ）である。

非特許文献１は、少量のデータを送信および／または受信するＭＴＣデバイスのためのＭＴＣ小規模信号送信（MTC small signal transmission）に関する特定の定義を提供する。例えば、関連付けられているシグナリングオーバーヘッドを制限すること、ネットワークリソースの使用を最適化すること、リソースの再割り当てに関する遅延を最小限に抑えることなどによって、ネットワークへの影響を最小限に抑えつつ少量のデータの送信をサポートすることを、ネットワークに関するシステムワイドな目標とすることができる。ネットワークの観点から見て少量のデータを構成するものとは何であるかは、サブスクリプションポリシーおよび／またはネットワークオペレータポリシーに基づいて構成可能とすることができる。

多くのＭＴＣデバイスが、１つのＭＴＣサーバと通信できる。ＭＴＣサーバは、複数のＭＴＣデバイスから受信された通信のための集積ポイントであると言える。例えば、ＭＴＣデバイスは、セルラーネットワークのコアネットワークを介してＭＴＣサーバと通信できる。例えば、ＭＴＣサーバは、コアネットワーク内の１つのノードとすることができる。データ混雑は、多数のＭＴＣデバイスが同時にデータを送信／受信するときに、モバイルコアネットワーク内で、またはＭＴＣサーバへの通信リンク内で生じる可能性がある。例えば、多くのＭＴＣアプリケーションにおいては、単一のＭＴＣユーザに関連付けられているさらに多数のＭＴＣデバイスが、ＭＴＣｉインターフェースを使用してＡＰＮ（access point name）を介してモバイルネットワークオペレータのパケットネットワークに結合されている単一のＭＴＣサーバへ接続することができる。

多数のデバイスの存在下における拡張性を提供するために、利用されるリソースを最適化することによって、およびシグナリングオーバーヘッドを低減することによって、データ混雑を緩和できる。例えば、デバイスのグループが、本明細書に記載されているようにＥＰＳベアラまたはＰＤＰコンテキストを共有するように構成されている。

図２は、ＵＭＴＳネットワーク内の複数のデバイスの間におけるＰＤＰコンテキストの共有を示している。図２において示されているように、ダウンリンク（および／またはアップリンク）通信リンクは、共有ＲＡＢ（radio access bearer）／ＰＤＰコンテキストを使用することによってデータを複数の宛先（例えば、デバイス）へ搬送するように構成することができる。例えば、デバイス１ ２０２、デバイス２ ２０４、およびデバイスＮ ２０６はそれぞれ、ＵＭＴＳセルラーデータネットワークを介してデータを送信および／または受信できる。デバイスは、データチャネルのデータの通信のためにＲＢ（radio bearer）を確立することができる。デバイスのうちの１つまたは複数へ送信されるデータに関連付けられるネットワークオーバーヘッドを最小限に抑えるために、パケットゲートウェイ（例えば、ＧＧＳＮ２１４）から（例えば、ＲＡＮ２１０の基地局における）ポイント２０８まで、共有コンテキストを確立することができる。例えば、ポイント２０８においては、基地局、例えばＮＢ（Ｎｏｄｅ Ｂ）またはｅＮＢ（evolved Node B）は、複数の無線ベアラのそれぞれを単一のＰＤＰコンテキストに関連付けることができる。

ＰＤＰコンテキストは、一意のＰＤＰアドレスに関連付けることができる。ＰＤＰコンテキストには、そのＰＤＰコンテキストに関連付けられているパケットを必ず正しく取り扱うために、指定のＱｏＳを割り振ることもできる。それぞれのＰＤＰコンテキストは、コアネットワークを通じてユーザプレーンデータをゲートウェイへ転送するために、別々のＲＡＢ（Radio Access Bearer）およびＧＴＰ（GPRS Tunneling Protocol）トンネルを有することもできる。例えば、図２において示されているように、ＲＡＢ２１６は、ＲＡＮ２１０からＳＧＳＮ２１２まで確立することができ、ＧＴＰトンネル２１８は、ＳＧＳＮ２１２からＧＧＳＮ２１４まで確立することができる。共有コンテキストは、ユーザデータをＰ−ＧＷ（packet data network gateway）からデバイス１ ２０２、デバイス２ ２０４またはデバイスＮ ２０６のうちの１つまたは複数へルーティングするために使用できる。ダウンリンクＲＡＢ／ＰＤＰコンテキストと同様に、アップリンクにおいても、複数のデバイスから受信されるデータは、（例えば、基地局における）ＲＡＮ内の共有されている／共通のＰＤＰ／ＲＡＢコンテキストへとマップすることができる。

図３は、ＬＴＥネットワーク内の複数のデバイスの間におけるＰＤＰコンテキストの共有を示している。例えば、図３はＥ−ＵＴＲＡＮアーキテクチャを示している。このＥ−ＵＴＲＡＮアーキテクチャでは、それぞれのデバイスは、ＭＭＥ（例えば、ＭＭＥ３２０）への個別のＳ１−ＭＭＥ接続を有している一方で、Ｐ−ＧＷ（例えば、Ｐ−ＧＷ３１４）への共通のＳ１−Ｕインターフェースを共有している。ＭＭＥ３２０は、ＨＬＲ（home location register）／ＨＳＳ（home subscriber server）３２２と通信状態にあることが可能である。図３において示されているように、ダウンリンク（および／またはアップリンク）通信リンクは、共有ＥＰＣ ＲＡＢ／ＰＤＰコンテキストを使用することによってデータを複数の宛先（例えば、デバイス）へ搬送するように構成できる。例えば、デバイス１ ３０２、デバイス２ ３０４、およびデバイスＮ ３０６はそれぞれ、ＬＴＥセルラーデータネットワークを介してデータを送信および／または受信することができる。それぞれのデバイスは、個別のＲＲＣ接続を利用すること、ＮＡＳ接続を確立すること、および／またはＣ−ＲＮＴＩ（cell radio network temporary identifier）に関連付けられることができる。デバイスのうちの１つまたは複数へ送信されるデータに関連付けられるネットワークオーバーヘッドを最小限に抑えるために、パケットゲートウェイ（例えば、Ｐ−ＧＷ３１４）からＲＡＮ３１０（例えば、ｅＮＢ−ＲＡＮ３１０の基地局）まで、共有コンテキストを確立することができる。例えば、ＲＡＮは、複数の無線ベアラ／ＲＲＣ接続のそれぞれを単一のＰＤＰコンテキストに関連付けることができる。図３において示されているように、ＥＰＣ／ＲＡＢ３１６は、ＲＡＮ３１０からＳ−ＧＷ３１２まで確立することができ、ＧＴＰトンネル３１８は、Ｓ−ＧＷ３１２からＰ−ＧＷ３１４まで確立することができる。共有コンテキストは、ユーザデータをＰ−ＧＷからデバイス１ ３０２、デバイス２ ３０４、またはデバイスＮ ３０６のうちの１つまたは複数へルーティングするために使用することができる。ダウンリンクＲＡＢ／ＰＤＰコンテキストと同様に、アップリンクにおいても、複数のデバイスから受信されるデータは、（例えば、基地局／ｅＮＢにおける）ＲＡＮ内の共有されている／共通のＰＤＰ／ＥＰＣ ＲＡＢコンテキストへとマップすることができる。

「コンテキスト」という用語は、本明細書において使用する際には、デフォルトベアラ、１つまたは複数の専用ベアラ、１つまたは複数の関連付けられている静的なまたは動的なＩＰアドレス、ＥＰＳベアラＩＤ、ＲＡＢ識別子、ＵＥ識別子（Ｓ−ＴＭＳＩ（SAE Temporary Mobile Subscriber Identity）、Ｍ−ＴＭＳＩ（MME Temporary Mobile Subscriber Identity）など）、ＥＢＩ（EPS Bearer ID）、ＬＢＩ（Linked EPS Bearer ID）、ＰＤＰコンテキストなど、デバイスに関連付けられているアイテムのうちの１つまたは複数を指すことができる。

Ｅ−ＵＴＲＡＮにおいては、デバイスが接続解除された状態にあるときにデータを送信するために、ＬＴＥネットワークに接続するための接続手順が呼び出される。例えば、ＷＴＲＵは、ＷＴＲＵからＬＴＥコアネットワークの出口ゲートウェイ（例えば、Ｐ−ＧＷ）まで確立されるＥＰＳベアラを利用することができる。例えば、ＷＴＲＵは、ＰＤＮごとに単一のデフォルトベアラに関連付けることができる。デフォルトベアラは、ＱｏＳ処理を含むことができず、また、ユーザデータに関してＴＦＴ（traffic flow template）フィルタを利用することができず、その代わりに、単一のＰＤＮに関してＷＴＲＵとＰ−ＧＷとの間における基本的な接続を提供する。ＷＴＲＵは、典型的には、ＰＤＮごとに単一のＩＰアドレスを有し、ＷＴＲＵは、デフォルト無線ベアラがアクティブ化されるときにＩＰアドレスを得る。デフォルトベアラに割り当てられたＩＰアドレスは、同じＰＤＮ接続内の専用ベアラのために使用できる。多くのケースにおいては、Ｐ−ＧＷは、ＤＨＣＰ（Dynamic Host Configuration Protocol）サーバとして機能し、デフォルトベアラの作成時に動的なＩＰアドレスをＷＴＲＵに割り振る。いくつかのＰ−ＧＷの実施態様においては、Ｐ−ＧＷは、ＷＴＲＵによって使用するためにＩＰアドレスを割り当てる目的でＲＡＤＩＵＳサーバに問合せを行える。動的なＩＰアドレスの割り当ては、デフォルトベアラの割り当て中に実行することができる。割り当てられたＩＰアドレスは、そのＰＤＮに関してその後に追加される他の専用ベアラに対しても依然として変わらず有効でありうる。ＷＴＲＵは、ＰＤＮごとに単一のデフォルトベアラと、ゼロまたは複数の専用ベアラとを有することができる。

小規模な送信に関しては、あるケースにおいては、デバイスが接続解除するときでさえ確立されたままである共通のＥＰＳベアラを有することが有益である場合がある。例えば、ネットワークは、そのＥＰＳベアラをデバイスのグループに事前に割り当てることができ、その共通のＥＰＳベアラおよびＩＰアドレスを、そのグループに関連付けられるデバイスの任意のデバイスから生じる全てのATTACH_REQUESTに割り振ることができる。

図４は、例示的なＥ−ＵＴＲＡＮ接続手順を示している。４１８において、ＷＴＲＵ４０２は、接続要求（attach request）をｅＮＢ４０４へ送信することによって、接続手順を開始することができる。接続要求は、ＩＭＳＩ、古いＧＵＴＩ（global unique temporary identifier）、最後に訪れたＴＡＩ（tracking area ID）、ＷＴＲＵコアネットワークの性能、ＷＴＲＵ固有のＤＲＸパラメータ、接続タイプ、ＥＳＭ（energy savings management）メッセージコンテナ（例えば、要求タイプ、ＰＤＮタイプ、プロトコル構成オプション、暗号化オプション転送フラグ）、キー識別子（ＫＳＩＡＳＭＥ）、ＮＡＳシーケンス番号、ＮＡＳ−ＭＡＣ（NAS message authentication code）、さらなるＧＵＴＩ、および／またはＰ−ＴＭＳＩ署名のうちの１つまたは複数を含むことができる。ｅＮＢ４０４は、接続要求メッセージを、選択されたネットワークおよび古いＧＵＭＭＥＩ（Globally Unique Mobility Management Entity Identifier）を示すＲＲＣパラメータとともに新たなＭＭＥ４０６へ送信／転送できる。ｅＮＢ４０４は、古いＧＵＭＭＥＩおよび示された選択されたネットワークを伝えるＲＲＣパラメータから適切なＭＭＥを特定できる。そのＭＭＥがｅＮＢ４０４に関連付けられていない場合、または古いＧＵＭＭＥＩが利用可能でない場合には、ｅＮＢ４０４はＭＭＥを選択できる。ｅＮＢ４０４は、Ｓ１−ＭＭＥ制御メッセージ（例えば、最初のＵＥメッセージ）を使用して、接続要求メッセージをＭＭＥ４０６へ転送できる。ｅＮＢ４０４は、選択されたネットワーク、ＣＳＧ（closed subscriber group）アクセスモード、ＣＳＧ ＩＤ、Ｌ−ＧＷ（local gateway）アドレス、および、接続要求を受信したセルのＴＡＩ＋ＥＣＧＩ（tracking area identity + E-UTRAN Cell Global Identifier）のうちの１つまたは複数とともに接続要求を伴う転送を行うことができる。

４２０において、ＷＴＲＵ４０２がＧＵＴＩを用いて自分自身の身元を明らかにし、接続解除以降にＭＭＥが変わっている場合には、新たなＭＭＥ４０６は、ＷＴＲＵ４０２から受信されたＧＵＴＩを使用して、古いＭＭＥ／ＳＧＳＮ４０８に関するアドレスを導出すること、およびＩＭＳＩを要求するために、例えば古いＧＵＴＩおよび完全な接続要求メッセージを含む識別要求を古いＭＭＥ／ＳＧＳＮ４０８へ送信することができる。

４２２において、ＷＴＲＵ４０２に関するＵＥ／ＷＴＲＵコンテキストがネットワーク内に存在しない場合、接続要求がインテグリティ保護されていなかった場合、および／またはインテグリティチェックが失敗した場合には、インテグリティ保護およびＮＡＳ暗号化をアクティブ化するための認証およびＮＡＳセキュリティセットアップを実行することができる。例えば、ＷＴＲＵ４０３に関する一時的なＩＤ（例えば、ＧＵＴＩ）が、古いＭＭＥ／ＳＧＳＮ４０８に、および／または新たなＭＭＥ４０６に知られていない場合には、新たなＭＭＥ４０６は、永続的なサブスクリプションＩＤ（例えば、ＩＭＳＩ）を送信するようＷＴＲＵ４０２に要求することができる。ＭＭＥは、ＥＩＲ（Equipment Identity Register）を用いてＭＥ ＩＤをチェックすることができる。ＥＩＲは、例えば、盗まれたＷＴＲＵをブラックリストに載せるために使用することができる。

４２４において、ＭＭＥが変わった場合には、新たなＭＭＥ４０６は、ＷＴＲＵ４０２が移動したことをＨＳＳ４１６に知らせることができる。ＨＳＳ４１６は、新たなＭＭＥ４０６に関するＭＭＥアドレスを格納することができ、ＵＥ／ＷＴＲＵコンテキストをキャンセルするよう古いＭＭＥ／ＳＧＳＮ４０８に指示することができる。４２６においては、デフォルトベアラをＰＣＲＦ４１４によって許可して、サービングＧＷ４１０とＰＤＮ ＧＷ４１２との間において確立することができる。４２８においては、無線インターフェースを介してデフォルトベアラを確立することができ、接続受諾をＷＴＲＵ４０２へ送信することができる。４３０において、新たなＭＭＥ４０６は、サービングＧＷ４１０にｅＮＢのＴＥＩＤ（Tunnel Endpoint Identifier）を知らせることができ、これによって、デフォルトベアラのセットアップを完了することができ、それによって、そのデフォルトベアラは、アップリンクおよびダウンリンクの両方において使用することができる。４３２において、新たなＭＭＥ４０６は、受信されたサブスクリプション情報内のＰＤＮ ＧＷと同じではないＰＤＮ ＧＷを選択した場合には、新たなＰＤＮ ＧＷのＩＤ（例えば、ＰＤＮ ＧＷ４１２のＩＤ）の通知をＨＳＳ４１６へ送信することができる。

ＰＣＣ（policy control and charging）／ＱｏＳルールとベアラとの間における関連付けは、ベアラバインディングと呼ばれる場合がある。ベアラバインディングは、ＢＢＦ（Bearer Binding Function）によって実行できる。ＢＢＦは、（パス上の場合には）ＰＣＥＦ内に、または（パス外の場合には）ＢＢＥＲＦ内に配置することができる。

図５は、ＬＴＥネットワークにおける例示的なユーザプレーンベアラバインディング機能を示している。例えば、ＥＰＳベアラが確立される時に、各々のベアラを識別するためにユーザプレーンデータを取り扱うＥＰＳノード内にベアラコンテキストが作成される。Ｅ−ＵＴＲＡＮ、およびサービングＧＷ５０８とＰＤＮ ＧＷ５１０との間におけるＧＴＰベースのＳ５／Ｓ８インターフェースに関しては、ＷＴＲＵ５０２、ｅＮＢ５０４、ＭＭＥ５０６、サービングＧＷ５０８およびＰＤＮ ＧＷ５１０のそれぞれは、作成されたベアラに関して関連するコンテキストを確立することができる。ＥＰＣ内のコアネットワークノード同士の間においては、ベアラに属するユーザプレーントラフィックは、そのベアラを識別するカプセル化ヘッダ（例えば、トンネルヘッダ）を使用してトランスポートすることができる。カプセル化プロトコルは、ＧＴＰ−Ｕ（GTP User Plane）であってよい。ＥＰＳベアラが確立されると、ＰＤＮ（packet data network）５１２からのＩＰフローは、Ｓ１およびＳ５／Ｓ８インターフェースを横断するＧＴＰトンネルを介してトランスポートされるベアラを使用してＷＴＲＵ５０２へルーティングすることができる。

図６は、ＵＭＴＳにおけるバインディングのためのＮＳＡＰＩ（Network layer Service Access Point Identifier）、ＲＢ ＩＤ（radio bearer Identity）、およびＲＡＢ ＩＤの使用を示している。ＵＭＴＳにおけるＰＤＰコンテキストは、以降で説明するようにＲＡＢとＧＴＰトンネルによって形成することができる。

ＵＭＴＳにおいては、ベアラを確立するための手順は、接続手順およびＰＤＰコンテキストアクティブ化手順という２つのステージへと分割することができる。ＬＴＥにおける接続手順、またはＵＭＴＳにおけるＰＤＰコンテキストアクティブ化手順は、本明細書においては「ＰＤＮ接続確立」手順と呼ばれる場合がある。ＮＳＡＰＩおよびＩＭＳＩは、ネットワークレイヤルーティングのために使用できる。ＮＳＡＰＩ／ＩＭＳＩのペアは、ＴＥＩＤ（Tunnel Endpoint Identifier）を割り振るために使用できる。ＵＭＴＳ ＭＳ（例えば、ＷＴＲＵ）においては、ＮＳＡＰＩは、ＰＤＰ−ＳＡＰ（Service Access Point）を識別できる。ＳＧＳＮおよびＧＧＳＮにおいては、ＮＳＡＰＩは、ＭＭ（mobility management：モビリティ管理）コンテキストに関連付けられているＰＤＰコンテキストを識別できる。本明細書のコンテキストにおいては、ＲＮＣという用語は、ＩｕモードでＷＴＲＵにサービス提供する場合には、ＧＥＲＡＮ ＢＳＣを指すこともできる。

Ｉｕ−ＰＳおよびＵｕインターフェースを介したＲＮＣとの通信においては、ＲＡＢ ＩＤは、無線アクセスベアラを識別するために使用することができ、ＲＡＢ ＩＤを通信するために使用される情報要素は、ＮＳＡＰＩ値と同一に設定することができる。ＲＮＣにおいては、ＲＡＢ ＩＤは、ＲＡＢコンテキストを識別することができる。ＲＢ ＩＤ（Radio Bearer Identity）は、無線アクセスベアラに関連付けられているＵｕインターフェース無線ベアラを識別するために使用できる。ＲＡＢ ＩＤは、特定のＣＮドメインおよび特定のＷＴＲＵに関するＲＡＢを一意に識別することができる。

ＮＳＡＰＩと、無線アクセスベアラと、ＰＤＰコンテキストとの間には、１対１対１の関係が存在しうる。パケットドメインにおいては、無線ベアラＩＤと、ＡＰＩ、無線アクセスベアラ、およびＰＤＰコンテキストとの間に、１対１の関係が存在しうる。ＮＳＡＰＩは、１つのＩＰアドレス、または２つのＩＰアドレス（例えば、ＰＤＰ Ｔｙｐｅ ＩＰｖ４ｖ６がサポートされ使用されている場合には、１つのＩＰｖ４アドレスおよび１つのＩＰｖ６アドレス）のいずれかに関連することができる。

ＷＴＲＵは、ＰＤＰコンテキストのアクティブ化を開始したときに、自分の未使用のＮＳＡＰＩのうちの１つを選択できる。ＳＧＳＮは、ＲＡＢ割り振り手順を開始したときに、ＮＳＡＰＩを、ＲＡＢ ＩＤ情報要素内に含めることができる。

Ｅ−ＵＴＲＡＮにおける相互認証は、ＵＳＩＭカードおよびネットワークの両方が同じシークレットキーＫへのアクセスを有するという事実に基づくことができる。シークレットキーＫは、ＵＳＩＭ上に、およびホームオペレータのネットワーク内のＨＳＳ／ＡｕＣ内に格納される永続的なキーとすることができる。キーＫは、いったん構成されると、ＵＳＩＭまたはＨＳＳ／ＡｕＣ内に格納されたままとなる。

Ｅ−ＵＴＲＡＮにおける認証および／またはキー生成のためのメカニズムは、ＥＰＳ ＡＫＡ（EPS Authentication and Key Agreement）と呼ばれる場合がある。図７は、ＬＴＥネットワークにおける例示的なＥＰＳ ＡＫＡ手順を示している。ＥＰＳ ＡＫＡは、ＷＴＲＵがＥ−ＵＴＲＡＮアクセスを介してＥＰＳに接続した時に実行できる。ＭＭＥ７０２は、接続を試みているＷＴＲＵのＩＭＳＩを特定することができ、またＭＭＥ７０２は、そのＩＭＳＩと、ＥＰＳ ＡＶ（authentication vector）７０６を求める要求とをＨＳＳ／ＡｕＣ７０４へ送信できる。ＥＰＳマスターキー（ＫＡＳＭＥ）、ＸＲＥＳ（expected user response）、ＡＵＴＮ（authentication token）、およびＲＡＮＤ（random number）は、ＥＰＳ ＡＶを構成することができ、そのＥＰＳ ＡＶは、メッセージ７０８内に含めてＭＭＥ７０２へ返される。ＭＭＥ７０２は、ＫＡＳＭＥおよびＸＲＥＳを格納し、ＲＡＮＤおよびＡＵＴＮをＷＴＲＵへ転送することができる。ＲＡＮＤおよびＡＵＴＮの両方は、ＵＳＩＭへ送信して、ＵＳＩＭ内に格納できる。ＡＵＴＮは、シークレットキーＫおよびＳＱＮ（sequence number）に基づいてＨＳＳ／ＡｕＣによって計算されたパラメータとすることができる。ＷＴＲＵ／ＵＳＩＭは、自分自身のキーＫおよびＳＱＮを使用してＡＵＴＮの自分自身のバージョンを計算することができ、その結果を、ＭＭＥから受信されたＡＵＴＮと比較することができる。それらが一致している場合には、ＷＴＲＵ／ＵＳＩＭは、ネットワークが認証されていると判定することができる。次いでＷＴＲＵ／ＵＳＩＭは、入力パラメータとしてキーＫおよびチャレンジＲＡＮＤとともに暗号化関数を使用して、ＲＥＳ（response）を計算することができる。ＷＴＲＵは、（例えば、ＵＳＩＭから）ＲＥＳ、ＣＫ（control key）、およびＩＫ（integrity key）を特定すると、そのＲＥＳをＭＭＥへ返信する。ＭＭＥは、そのＲＥＳがＸＲＥＳに等しいことを検証することによって、端末を認証することができる。そのＲＥＳがＸＲＥＳに等しい場合には、ＭＭＥは、ＷＴＲＵが認証されていると判定することができる。

図８は、マシンタイプ通信のための例示的な３ＧＰＰアーキテクチャを示している。ＭＴＣｓｍｓインターフェース８０４、ＭＴＣｓｐインターフェース８０６およびＭＴＣｉインターフェース８０８は、まだ完全には定義されていない。ＭＴＣｓｍｓ８０４は、ＭＴＣサーバ８１６と、ＳＭＳ−ＳＣ（Short Message Service-Service Center）／ＩＰ−ＳＭ−ＧＷ（IP Short Message Gateway）８１０との間におけるインターフェースを提供することができる。ＭＴＣｓｐ８０６は、ＭＴＣサーバ８１６と、ＭＴＣ間作業機能８１２との間におけるインターフェースを提供することができる。ＭＴＣｉ８０８は、ＭＴＣサーバ８１６と、ＧＧＳＮ／ＰＧＷ／ｅＰＤＧ８１４との間におけるインターフェースを提供することができる。ＷＴＲＵ８０２は、例えばＭＴＣｉ８０８を介して、ＭＴＣサーバ８１６と通信することができる。

（例えば、非３ＧＰＰデバイスを含む）キャピラリーネットワーク（capillary network）からのデバイスは、３ＧＰＰネットワーク内から、またはインターネットなど、他の何らかのネットワークから、ゲートウェイを介してＭＴＣサーバに接続できる。図９は、ＭＴＣサーバへのアクセスをＭＴＣキャピラリーネットワーク内のＭＴＣデバイスに提供するＭＴＣゲートウェイデバイスの例示的なシステムアーキテクチャを示している。しかし、３ＧＰＰネットワークおよび／またはＭＴＣサーバに関するインターフェースを取るためのゲートウェイとしてＷＴＲＵ８０２などのＷＴＲＵを使用する非３ＧＰＰデバイスにＩＰアドレスを割り振ることに関しては、いくつかの難題が存在する場合がある。ここで開示するのは、非３ＧＰＰデバイスをＭＴＣサーバおよび他のデバイスによって一意にアドレス指定することができるように３ＧＰＰコアネットワークによって非３ＧＰＰデバイスにＩＰアドレスを割り当てるためのいくつかの方法である。

例えば、シグナリングオーバーヘッドを低減して潜在的なネットワーク混雑を防止するために、複数の３ＧＰＰデバイスが、単一のＰＤＰコンテキストを共有できる。例えば、複数のＭＴＣデバイス／ＷＴＲＵのそれぞれは、単一のＰＤＰコンテキストを共有することができる。それらの複数のデバイス／ＷＴＲＵのそれぞれは、別々のＰＤＮ接続確立手順を独立して実行できる。それらのＭＴＣデバイス／ＷＴＲＵのそれぞれに別々のＰＤＰ接続確立手順を実行させることによって、下位互換性を促進すること、および提案された変更を効率的なコスト効率のよい様式で実施できるようにすることができる。下位互換性は、さまざまなデバイスがネットワーク内で共存できるようにするために、ＲＡＮ手順並びにＰＤＮ接続確立および解除などの１つまたは複数のネットワーク手順に対する修正を含むこともできる。

それぞれがネットワークに登録している一方で共通のＰＤＰコンテキストを共有している一群のＭＴＣデバイス／ＷＴＲＵをサポートするために、デバイスＰＤＮ接続確立および解除手順を更新して洗練することができる。例えば、ＰＤＮ接続確立および解除手順は、特定のＭＴＣデバイス／ＷＴＲＵが同じコンテキストにマップされている一方で、他のＭＴＣデバイス／ＷＴＲＵの無線ベアラが、他のデバイスとの間で共有されていない単一のＲＡＢにマップされることが依然として可能であるようサポートするように修正することができる。また、ＰＤＮ接続確立および解除手順は、ＭＴＣデバイス／ＷＴＲＵのうちで、モビリティをほとんどまたはまったく経験していない特定のグループをサポートするように修正することができる。例えば、ＭＴＣデバイスのあるグループが、低いモビリティのグループとして設計されている場合、またはそのグループに属するデバイスが、互いに対してあまり動かない場合には、混雑およびシグナリングオーバーヘッドを低減するために、コアネットワーク手順をそれらのデバイスに対して最適化することができる。例えば、ロケーションエリアアップデートおよび／またはトラッキングエリアアップデートなどのロケーションベースの手順を、相対的に静的なデバイス、および／または互いに対して相対的に静的であるデバイス用に最適化することができる。

さらに、図４を参照しながらＬＴＥ接続手順のステップ４１８および４２２に関して述べたように、ＷＴＲＵは、ＩＭＳＩ（International Mobile Subscriber Identity）を使用してネットワークに対して自分自身の身元を明らかにすることができる。ＩＭＳＩは、ＧＳＭおよびＵＭＴＳネットワークのモバイル電話ユーザに関連付けられている一意の番号であると言える。ネットワークリソースの拡張性および効率的な利用の目的から、例えば、「地理的にグループ化された一群のデバイス」のそれぞれが、共通のグループ識別子を共有するように構成されうる。例えば、例示的なグループ識別子は、デバイスのグループの間において共有される共通のＩＭＳＩであると言える。この共通のグループ識別子をグループＩＤと呼ぶことができる。グループＩＤは、デバイスのＵＳＩＭ上に格納できる。グループＩＤは、デバイスがネットワークに対して自分自身の身元を明らかにしている時には、そのデバイスの個別のＩＭＳＩに取って代わることができる。単一のコンテキストを共有しているデバイスのグループが、同じグループＩＤに関連付けられている場合には、ネットワークが、同じ識別子（例えば、グループＩＤ、および／または共通の／グループのＩＭＳＩ）を使用して複数のデバイスからのＰＤＮ接続要求を取り扱えるようにするために、さらなる更新を実施することができる。

適切なベアラバインディングは、それぞれのデバイスが一意のＩＰアドレスを使用する場合に実行することができる。特定の既存のセキュリティ手順は、そのような下位互換性が所望される場合に、同じＩＭＳＩを共有している複数のデバイスを認証できるようにするために更新することができる。

図９において示されているように、３ＧＰＰネットワークを介してインターネットに接続するデバイスの多くは、ゲートウェイを介して接続できる。これらのデバイスは、３ＧＰＰコアネットワークに登録されていないかまたは知られていない場合があり、また、これらのデバイスは、３ＧＰＰ無線機を有していない場合さえある。しかし、ＭＴＣサーバは、３ＧＰＰゲートウェイを使用して３ＧＰＰネットワークを通じてＭＴＣサーバに接続されているデバイスを識別およびアドレス指定するように構成することができる。例えば、ローカルアクセスデバイス９０６、ＭＴＣデバイス９０８、ローカルアクセスデバイス９１０、および／またはＭＴＣデバイス９１２はそれぞれ、例えば、ＭＴＣゲートウェイデバイス９０４を介して、ＭＴＣサーバ９０２と通信することができる。ＭＴＣゲートウェイデバイス９０４、ローカルアクセスデバイス９０６、ＭＴＣデバイス９０８、ローカルアクセスデバイス９１０、および／またはＭＴＣデバイス９１２は、ＭＴＣキャピラリーネットワーク９１４を形成することができる。ＭＴＣゲートウェイデバイス９０４は、３ＧＰＰサブスクライバとすることができ、またＷＴＲＵとすることもできる。ＭＴＣゲートウェイデバイス９０４は、３ＧＰＰネットワークを介したＭＴＣサーバ９０２へのアクセスをローカルアクセスデバイス９０６、ＭＴＣデバイス９０８、ローカルアクセスデバイス９１０、および／またはＭＴＣデバイス９１２に提供するように構成することができる。ローカルアクセスデバイス９０６、ＭＴＣデバイス９０８、ローカルアクセスデバイス９１０、および／またはＭＴＣデバイス９１２は、非３ＧＰＰデバイスとすることができる。ＭＴＣサーバは、ローカルアクセスデバイス９０６、ＭＴＣデバイス９０８、ローカルアクセスデバイス９１０、および／またはＭＴＣデバイス９１２のうちの１つまたは複数を（たとえ、それらが３ＧＰＰネットワークを通じて接続されている非３ＧＰＰデバイスであっても）識別およびアドレス指定するように構成することができる。そのような機能を可能にするために、３ＧＰＰネットワークは、３ＧＰＰゲートウェイの後ろから接続してくるデバイス（例えば、ＭＴＣゲートウェイデバイス９０４など）に一意のＩＰアドレスを割り当てるように構成することができる。

３ＧＰＰゲートウェイを介してインターネットに接続するデバイスをキャピラリーネットワークデバイスと呼ぶことができる。キャピラリーネットワークデバイスは、少量のデータをまれに送信および受信する低リソースデバイスとすることができる。これらの低リソースキャピラリーネットワークデバイスをＤ’（ｄプライム）デバイスと呼ぶことができる。例えば、キャピラリーネットワークデバイスは、より高いデータレートでデータを送信および受信するさらにハイエンドなデバイス（例えば、ビデオをストリーミングするカメラ）とすることができる。キャピラリーネットワークは、３ＧＰＰネットワークに対して秘密にすることができ、または秘密にしなくてもよい。

現在では、それぞれのＩＰ接続ごとに個別のＰＤＰコンテキストが確立される。それぞれのＩＰ接続ごとの個別のＰＤＰコンテキストにおいて確立された少量のデータを移送するＭＴＣデバイスおよび他のデバイスは、次善のものとなる場合がある。例えば、それぞれのＭＴＣデバイスによって生成されるデータの量は、新たなＰＤＰコンテキストを作成するために必要とされるシグナリングの量よりもはるかに少ない場合がある。したがって、現時点で、あらゆる低リソースデバイスにＩＰアドレスを割り振ることに関連するシグナリングオーバーヘッドは、ネットワークの観点からは受け入れられないと言える。

例えば、３ＧＰＰゲートウェイを介して３ＧＰＰネットワークにアクセスする多くの低リソースデバイスが存在するケースを考えていただきたい。３ＧＰＰ ＧＷは、単一のＰＤＰコンテキストを確立して、全てのキャピラリーネットワークアプリケーションからのデータを同じＰＤＰコンテキスト／ＩＰアドレス上にマップすることができる。それぞれのキャピラリーネットワークデバイスは、３ＧＰＰゲートウェイのＩＰアドレスにおける別々のポートにマップすることができる。ＧＷは、それぞれのＩＰパケットを正しい宛先へ導くためにポート転送を使用することができる。図１０は、単一のＰＤＰコンテキストを確立して、ポート転送を用いて全てのキャピラリーネットワークアプリケーションからのデータを同じＰＤＰコンテキスト／ＩＰアドレス上にマップするための複数の通信プロトコルスタックを通じた例示的な信号フローを示している。ゲートウェイにおけるポート転送の利用によって、複数のデバイスの間における単一の共有ＰＤＰコンテキストの使用が容易になる。例えば、３ＧＰＰ ＧＷは、ポート転送機能をサポートできる。ポート転送アプローチを利用している場合には、ＭＴＣサーバは、キャピラリーネットワークデバイスの外部識別子をＩＰアドレスおよびポート番号にマップすることができる。

ＣＮにおいてＩＰｖ６が使用されるシナリオにおいては、ＧＷ／キャピラリーネットワーク内のそれぞれのデバイスに複数のＩＰアドレスを割り振ることが妥当である場合がある。例えば、単一のＧＷ、Ｍ個のキャピラリーネットワーク、およびＮ個のキャピラリーネットワークデバイス（ここでは、ＭおよびＮは整数である）を伴う場合には、コアネットワークは、１＋Ｍ＋Ｎ個のＩＰアドレスをゲートウェイに割り振ることができる。次いでＧＷは、それぞれのキャピラリーネットワークデバイスに別々のＩＰアドレスを関連付けること、および自分の物理インターフェースのうちのそれぞれに関して１つのＩＰアドレスを使用することが可能である。このアプローチを用いれば、ポート転送ルールを確立する必要性が回避され、ひいては、ＭＴＣサーバへのシグナリングが低減されることになる。このようなアプローチは、３ＧＰＰ ＧＷにおける複雑なネットワークアドレス変換機能の使用を回避することもできる。図１１は、１つのキャピラリーネットワークに伴って複数のデバイスに関する複数のＩＰアドレスを確立するための複数の通信プロトコルスタックを通じた例示的な信号フローを示している。

理解できるように、単一のＩＰアドレスがそれぞれのＰＤＰコンテキストに関連付けられている場合には、例えば、１つまたは複数のデバイスが少量のデータを生成するシナリオにおいて、自分自身のＩＰアドレスを割り振られるそれぞれのデバイスごとの個別のＰＤＰコンテキストを３ＧＰＰ ＧＷが確立することは、非常に効率が悪い場合がある。ＰＤＰコンテキストを確立するための関連するシグナリングオーバーヘッドは、送信されるデータよりも大きい場合がある。しかし、１つのＰＤＰコンテキストおよび単一のＩＰアドレスを共有することは、より多くのＮＡＴ機能を必要とする場合がある。したがって、複数のＩＰアドレスが単一のＰＤＰコンテキストに割り振られることを可能にするための方法およびシステムを開示する。

図１０および図１１は、キャピラリーネットワークとＭＴＣゲートウェイの間における接続がＩＥＥＥ８０２．１５．４物理インターフェースを介して提供されうることを示しているという点に留意されたい。ＩＥＥＥ８０２．１５．４インターフェースの使用は、例であり、他の物理インターフェース、例えば８０２．１１を使用することもできる。実際に、キャピラリーネットワークは、ＩＰアドレッシングとは異なるアドレッシングプロトコルを使用できる。例えば、ＧＷは、ＩＰアドレッシングと、キャピラリーネットワークにおいて使用されるアドレッシングスキームとの間におけるマッピングを実行できる。

例示的な一構成においては、別のデバイスとの間でＰＤＰコンテキストを共有する１つまたは複数のデバイス、例えばＭＴＣデバイスおよび／またはＭＴＣゲートウェイデバイスは、ネットワークへの個別のＲＲＣ接続を開始するために下位互換性のあるＲＡＮ手順を使用するように構成することができる。例えば、ＰＤＰコンテキストを共有する複数のデバイスは、個別の接続メッセージをネットワークへ送信できる。ネットワークは、それらのデバイスのうちの１つまたは複数が、共通のＰＤＰコンテキストを共有するデバイスのグループのメンバーであることを認識し、および接続を確立するために適切なアクションを起こすことができる。コアネットワーク手順は、それらのデバイスをグループの一部としてマップするように、および／または個々のデバイス／ＷＴＲＵ無線ベアラを共有コンテキストに関連付けるための適切なベアラバインディングを実行するように構成することができる。

例えば、コアネットワークは、同じグループに属するデバイスの数のカウントを保持することができる。例えば、第１のデバイスがＬＴＥネットワークに接続する場合には、コアネットワークは、ＰＤＮ接続要求を受け入れることができ、並びに／またはセキュリティの確立、認証、および／若しくはデフォルトコンテキストの作成のためのコアネットワーク手順を開始することができる。その後に、やはり同じグループのメンバーである別のデバイスがコアネットワークへの接続を試みる場合には、コアネットワークは、その後に接続するそのデバイスが事前に登録されていることを識別することができ、第２のデバイスのための１つまたは複数のコアネットワーク手順（例えば、セキュリティ、認証、および／またはデフォルトコンテキストの作成）をなしで済ませることができる。例えば、ＬＴＥにおいては、ＭＭＥは、そのデバイスに関する最初のコンテキストを共有ＰＤＰコンテキスト情報（例えば、ＥＰＣコンテキスト情報）とともにｅＮＢへ送信できる。グループ内の第１のデバイスがネットワークへの接続を試みる場合には、ネットワークは、その第１のデバイスに関するデフォルトベアラセットアップを実行できる。その後にネットワークへの接続を試みるグループ内のデバイスのそれぞれに関して、その後に接続するそれらのデバイスへ送信される接続受諾は、そのグループに関して接続された第１のデバイスについて提供されたのと同じＰＤＰコンテキスト情報（例えば、ＥＰＳベアラコンテキスト）を含むことができる。例えば、ロケーションエリア／トラッキングエリア更新手順は、ロケーション更新手順をトリガーするためにグループ内の単一のデバイス（例えば、第１のデバイス）に関して実行できるが、グループ内の他のデバイスに関してはスキップすることができる。例えば、共有ＰＤＰコンテキストを伴うグループ内の最後のデバイスがＰＤＮ接続をネットワークから解除した場合には、ネットワークは、それらのグループリソースを解放することができる。

例えば、共有ＰＤＰコンテキスト（例えば、ＥＰＳベアラおよび／若しくはコンテキスト）に関する、並びに／または所定のサービス要求（例えば、特定のサービスを、事前に構成されたＥＰＳベアラにマップすることができる）に関するグループサブスクリプションが確立される場合には、ＭＴＣグループに関して共有コンテキストを事前に割り当てることができる。その事前に割り当てられた共有コンテキストは、ＭＴＣグループのメンバーから生じるそれぞれの接続要求ごとにｅＮＢによって使用することができる。

例えば、コアネットワーク要素（例えば、ＭＭＥ／ＳＧＳＮ）は、共通のグループ／サービス／トラフィックタイプの一部であるデバイスの数のカウントおよび／またはＩＤを保持することができる。コアネットワーク要素（例えば、ＭＭＥ／ＳＧＳＮ）は、デバイスごとに単一のコンテキストを使用することから、事前に定義された基準に基づいて共有コンテキストを使用することへ動的に遷移することができる。例えば、グループの一部であるデバイスの数のカウントが所定のしきい値を超えた場合には、コアネットワーク要素（例えば、ＭＭＥ／ＳＧＳＮ）は、グループメンバーに関して確立された個別のコンテキストを単一の共有コンテキストへ遷移させることができる。例えば、確立されたデバイスコンテキストは、新たなベアラバインディング情報、ＩＰアドレス情報、および／または、共有コンテキストに関するコンテキスト情報を用いて再構成することができる。

例えば、共通のコンテキストを共有するデバイスのグループへの／そうしたグループからのルーティングをサポートするために、パケットを個々のデバイスへルーティングするための適切な手順を修正することができる。例えば、ＥＰＳデフォルトベアラコンテキストが単一の静的なおよび／または動的なＩＰアドレスに関連付けられている場合にパケットの正しいルーティングおよび／または配信を容易にするために、ベアラバインディングおよびＩＰアドレッシングのための手順を確立／修正することができる。例えば、単一のコンテキスト／デフォルトコンテキストを共有しているそれぞれのデバイスごとに個別のＩＰアドレスの使用を可能にするために、ＲＮＣ／ｅＮＢにおいて、および／またはＧＧＳＮ／Ｐ−ＧＷにおいて、１つまたは複数の変換機能を使用することができる。

例えば、共有コンテキストグループのメンバーをまとめて識別するために、グループＩＭＳＩなどのグループ識別子を確立することができる。そのようなグループ識別子が使用される場合には、グループコンテキストを共有しているデバイスに関する正しい認証および／またはキーのやり取りを確かなものにするために、セキュリティ手順および／または認証手順を更新することができる。

例えば、ＭＴＣゲートウェイデバイスなどのセルラーＧＷは、複数のＩＰアドレスが同じＰＤＰコンテキストに関連付けられるよう要求することができる。それらのＩＰアドレスは、キャピラリーネットワークへおよび／またはキャピラリーネットワークからパケットをルーティングするために使用できる。ＧＷは、キャピラリーネットワークへおよび／またはキャピラリーネットワークから送信されるＩＰパケット上でＬ３（Layer 3）ルーティングを実行することができる。複数のＩＰアドレスを要求するおよび／または割り当てるために、既存のＰＤＰコンテキストアクティブ化および／またはＰＤＰコンテキスト修正情報要素内に含まれているスペアビット（spare bit）を利用することができる。このようなアプローチは、下位互換性を有することができ、既存のデバイスに関する手順に従って利用することができる。

デバイス、例えばＭＴＣゲートウェイデバイスが、単一の共有コンテキストに関して複数のＩＰアドレスを要求できるようにすることによって、コアネットワークは、キャピラリーネットワークを使用して確立された接続を通じて３ＧＰＰネットワークを通る接続を得る非３ＧＰＰデバイスのＩＤ、数、性能、および／またはタイプに関してさらに多くの知識を得ることができる。例えば、ネットワークは、ＧＷを通じて接続するデバイスの数を決定できるようにすることができ、そして（例えば、ＧＷに割り当てられているＩＰアドレスの数に基づいて）得た情報に基づいてゲートウェイに関連付けられているサブスクリプションに課金することができる。

図１２は、それまでに作成された共有コンテキストを使用してネットワークに接続している後続のグループメンバーによって使用可能な例示的な接続手順を示している。例えば、第１のグループメンバーがＰＤＮコンテキストを確立した後にＰＤＮ接続要求を実行する後続のグループメンバーのための接続手順中には、ロケーション更新手順および／またはデフォルトベアラ作成手順（例えば、図４の４２４および／または４２６）を省略することができる。その代わりに、ＭＭＥおよび／またはＳＧＳＮは、それまでに作成された共有コンテキストを使用して後続のデバイスのための接続を確立するために、作成された共有情報を使用することができる。例えば、ＭＭＥおよび／またはＳＧＳＮは、カウンタ（例えば、GROUP_COUNT）を保持することができ、このカウンタは、接続および／または接続解除要求が生じるたびに更新することができる。

例えば、１２１８において、ＷＴＲＵ１２０２は、接続要求をｅＮＢ１２０４へ送信することによって、接続手順を開始することができる。ＷＴＲＵ１２０２は、共通のＰＤＰコンテキストを共有するグループのメンバーとすることができる。ＷＴＲＵ１２０２は、自分がそのグループのメンバーであることを接続要求内で示すことができる。例えば、ＷＴＲＵ１２０２は、コンテキストを共有するグループに関するグループＩＤを接続要求内に含めることができる。例えば、接続要求を区別するために、新たな確立要因、例えば、MTC_ATTACH、GROUP_ATTACH、および／またはSERVICE_ATTACHを利用することができる。例えば、MTC_ATTACH要求は、サポートされているＭＴＣデバイス固有の機能に関する情報を識別および／または提供するさらなるＩＥを含むことができる。例えば、GROUP_ATTACH要求は、接続するデバイスがグループの一部であることを示すことができ、共通のコンテキストおよび／またはＩＭＳＩを共有することができる。

接続要求は、ＩＭＳＩ、古いＧＵＴＩ、最後に訪れたＴＡＩ、ＷＴＲＵコアネットワークの性能、ＷＴＲＵ固有のＤＲＸパラメータ、接続タイプ、ＥＳＭメッセージコンテナ（例えば、要求タイプ、ＰＤＮタイプ、プロトコル構成オプション、暗号化オプション転送フラグ）、ＫＳＩＡＳＭＥ、ＮＡＳシーケンス番号、ＮＡＳ−ＭＡＣ、さらなるＧＵＴＩ、Ｐ−ＴＭＳＩ署名、および／またはグループＩＤのうちの１つまたは複数を含むことができる。ｅＮＢ１２０４は、接続要求メッセージを、選択されたネットワークおよび古いＧＵＭＭＥＩを示すＲＲＣパラメータとともに新たなＭＭＥ１２０６へ送信／転送することができる。ｅＮＢ１２０４は、古いＧＵＭＭＥＩおよび示された選択されたネットワークを伝えるＲＲＣパラメータから適切なＭＭＥを特定できる。そのＭＭＥがｅＮＢ１２０４に関連付けられていない場合、または古いＧＵＭＭＥＩが利用可能でない場合には、ｅＮＢ１２０４は、ＭＭＥを選択することができる。ｅＮＢ１２０４は、Ｓ１−ＭＭＥ制御メッセージ（例えば、最初のＵＥメッセージ）を使用して、接続要求メッセージをＭＭＥ１２０６へ転送できる。ｅＮＢ１２０４は、選択されたネットワーク、ＣＳＧアクセスモード、ＣＳＧ ＩＤ、Ｌ−ＧＷアドレス、および、接続要求を受信したセルのＴＡＩ＋ＥＣＧＩのうちの１つまたは複数とともに接続要求を伴う転送を行うことができる。

１２２０において、ＷＴＲＵ１２０２がＧＵＴＩを用いて自分自身の身元を明らかにし、接続解除以降にＭＭＥが変わっている場合には、新たなＭＭＥ１２０６は、ＷＴＲＵ１２０２から受信されたＧＵＴＩを使用して、古いＭＭＥ／ＳＧＳＮ１２０８に関するアドレスを導出すること、およびＩＭＳＩを要求するために、例えば古いＧＵＴＩおよび完全な接続要求メッセージを含む識別要求を古いＭＭＥ／ＳＧＳＮ１２０８へ送信することが
１２２２において、グループセキュリティに関する最適化を伴う認証／セキュリティ／ＭＥ ＩＤの検索を実行できる。例えば、１つまたは複数のセキュリティ手順、識別手順、および／または認証手順を、共有グループコンテキストの使用を考慮するように修正することができる。具体的な変更については、以降でさらに詳細に論じる。新たなＭＭＥ１２０６は、接続するデバイスのメンバーが共有コンテキストグループのメンバーであることを、例えば接続要求に基づいて認識することができる。例えば、ＷＴＲＵ１２０２に関するＵＥ／ＷＴＲＵコンテキストがネットワーク内に存在しない場合、接続要求がインテグリティ保護されていなかった場合、および／またはインテグリティチェックが失敗した場合には、インテグリティ保護およびＮＡＳ暗号化をアクティブ化するための認証およびＮＡＳセキュリティセットアップを実行することができる。例えば、ＷＴＲＵ１２０２に関する一時的なＩＤ（例えば、ＧＵＴＩ）が、古いＭＭＥ／ＳＧＳＮ１２０８に、および／または新たなＭＭＥ１２０６に知られていない場合には、新たなＭＭＥ１２０６は、永続的なサブスクリプションＩＤ（例えば、ＩＭＳＩ）を送信するようＷＴＲＵ１２０２に要求することができる。ＭＭＥ１２０６は、グループサブスクリプションＩＤ（例えば、グループＩＭＳＩ）を送信するようＷＴＲＵ１２０２に要求することができる。ＭＭＥは、ＥＩＲを用いてＭＥ ＩＤをチェックすることができる。ＥＩＲは、例えば、盗まれたＷＴＲＵをブラックリストに載せるために使用することができる。

１２２４において、新たなＭＭＥ１２０６は、ＷＴＲＵ１２０２が、ＰＤＰコンテキストを共有するグループのメンバーであることを、例えば接続要求内に含まれている情報（例えば、グループＩＤ）に基づいて判定できる。新たなＭＭＥ１２０６は、共通のコンテキストを共有しているデバイスの数を特定するために、カウンタ（例えば、GROUP_COUNT）を保持することができる。例えば、新たなＭＭＥ１２０６は、グループＩＤを含む接続要求を受信すると、そのグループＩＤに関連付けられているGROUP_COUNTをインクリメントすることができる。そのグループＩＤに関連付けられている別のデバイスが、それまでにネットワークに接続されていたならば、ＭＭＥ１２０６は、例えば、それまでに接続されていたそのグループの別のメンバーに関してロケーション更新手順がそれまでにトリガーおよび／または実行されていた場合には、ロケーション更新手順を実行するのを差し控えることを決定することができる。

１２２６において、新たなＭＭＥ１２０６は、ＷＴＲＵ１２０２に関するデフォルトベアラ情報を特定することができる。例えば、新たなＭＭＥ１２０６は、ＷＴＲＵ１２０２を含むグループに関してそれまでに作成されていた共有デフォルトベアラをＷＴＲＵ１２０２が使用できるようにすることができる。例えば、その共有デフォルトベアラは、そのグループの別のメンバーに関して実行されたそれまでに実行された接続手順中にＰＣＲＦ１２１４によってそれまでに許可されていた可能性がある。その共有デフォルトベアラは、サービングＧＷ１２１０と、ＰＤＮ ＧＷ１２１２との間において確立されていた可能性がある。ＭＭＥ１２０６は、接続要求内に含まれている情報に基づいて、例えばグループＩＤに基づいて、その共有デフォルトベアラのＩＤを特定することができる。

１２２８においては、無線インターフェースを介して共有デフォルトベアラを確立することができ、接続受諾をＷＴＲＵ１２０２へ送信することができる。１２３０において、新たなＭＭＥ１２０６は、サービングＧＷ１２１０にｅＮｏｄｅＢのＴＥＩＤ（Tunnel Endpoint Identifier）を知らせることができ、これによって、共有デフォルトベアラのセットアップを完了することができ、それによって、その共有デフォルトベアラは、アップリンクおよびダウンリンクの両方においてＷＴＲＵ１２０２によって使用することができる。１２３２において、新たなＭＭＥ１２０６は、受信されたサブスクリプション情報内のＰＤＮ ＧＷと同じではないＰＤＮ ＧＷを選択した場合には、新たなＰＤＮ ＧＷのＩＤ（例えば、ＰＤＮ ＧＷ１２１２のＩＤ）の通知をＨＳＳ１２１６へ送信することができる。

ＰＣＣ（policy control and charging）／ＱｏＳルールとベアラとの間における関連付けは、ベアラバインディングと呼ばれる場合がある。ベアラバインディングは、ＢＢＦ（Bearer Binding Function）によって実行することができる。ＢＢＦは、（パス上の場合には）ＰＣＥＦ内に、または（パス外の場合には）ＢＢＥＲＦ内に配置できる。

例えば、個々のＰＤＮ接続要求が個別に処理されることになるか、または共通のグループ／サービス／プールの一部として処理されることになるかを区別するために、共有コンテキストグループ内のそれぞれのデバイスは、そのデバイスの個別のＩＭＳＩ、および／または、共有コンテキストグループのグループＩＤを示すさらなるＩＥを送信することができる。グループＩＤは、接続要求および／または他のＰＤＰ接続要求メッセージ内に含めることができる。ＰＤＮ接続要求メッセージ内に含めたグループＩＤの送信を保護するために、さらなるセキュリティ手順を使用することができる。

例示的な一構成においては、ＩＭＳＩと共有コンテキストグループとの関連付けを、ＷＴＲＵに関するサブスクリプション情報とともに、例えばＨＳＳ／ＨＬＲ内に格納することができる。ＭＭＥおよび／またはＳＧＳＮは、所与のデバイスおよび／またはＩＭＳＩが共有コンテキストグループのメンバーであるという表示をＨＳＳ／ＨＬＲから受信することができる。ＭＭＥおよび／またはＳＧＳＮは、１つ若しくは複数のデバイスが、ＨＳＳ／ＨＬＲがそれらのデバイスのうちのそれぞれに関して同じグループＩＤを送信する同じグループであること、および／または、それらのデバイスのそれぞれがＰＤＰ接続要求メッセージ内に同じグループＩＤを含んでいるかどうかを判定することができる。ＭＭＥおよび／またはＳＧＳＮは、それらのデバイスのそれぞれを共有ＥＰＣベアラ（例えば、ＰＤＰコンテキスト）に関連付けるために、それらのデバイスが同じグループＩＤを有しているという表示を使用することができる。

ユーザプレーントラフィックの転送に関しては、ネットワークは、共有コンテキストグループ内のデバイスのうちの全てが同じＩＰアドレスを共有する場合に、ベアラ／コンテキストバインディングを実行することができる。共有コンテキストグループ内のデバイスのうちのそれぞれが単一のＩＰアドレスを共有する場合には、下記の手順のうちの１つまたは複数を任意の組合せで実施することができる。

例えば、グループのうちの１つまたは複数のデバイスがＰＤＮ接続をネットワークに要求した場合には、ＲＮＣ、ＳＧＳＮ、および／またはｅＮＢは、共有コンテキストグループに関する適切な共通の／共有されるコンテキストを特定および入手することができる。ＲＮＣ、ＳＧＳＮ、および／またはｅＮＢは、単一の共有コンテキストに関連付けられている個々の無線ベアラに関するマッピングを作成することができる。共有コンテキストは、共通のＩＰアドレスを共有することができ、その共通のＩＰアドレスは、例えばマルチキャストＩＰアドレスとすることができる。例えば、共通のコンテキストに関連付けられている共有コンテキストグループ内の１つまたは複数のデバイスへ配信されるダウンリンクデータは、共有コンテキストグループ内の全てのデバイスへ送信することができる。例えば、共有コンテキストグループのデバイスにおけるアプリケーションレベルの処理は、ダウンリンクデータが個々のデバイスに向けたものであったかどうかを判定することができる。例えば、それぞれのデバイスを別々のアプリケーションレベル識別子に関連付けることができ、そのアプリケーションレベル識別子は、マルチキャストメッセージなどの受信されたメッセージが個々のデバイスに向けたものであったかどうかを判定するために使用することができる。アップリンクにおいては、共有コンテキストグループ内のデバイスのうちのいずれのデバイスからのデータも、ＲＮＣおよび／またはｅＮＢにとっては、同じソースＩＰアドレスから送信されているように見えることが可能である。ダウンリンクと同様に、アプリケーションレベル識別子は、共有コンテキストグループのどのメンバーがアップリンク送信を行ったかを区別するために使用することができる。

例えば、共有コンテキストグループ内のデバイスのうちのそれぞれは、同じＩＰアドレスを共有することができ、ＲＮＣ、ＳＧＳＮ、および／またはｅＮＢは、１つまたは複数のメッセージを送信および／または受信した共有コンテキストグループメンバーのＩＤを識別するために、さらなるマッピングを実行できる。そのようなマッピングは、Ｐ−ＧＷおよび／またはＧＧＳＮにおいて実行することもできる。例えば、共有コンテキストグループによって共有されているＩＰアドレスに／によってアドレス指定されているメッセージの宛先（例えば、ダウンリンク）および／またはソース（例えば、アップリンク）は、ユーザアカウント番号などの一意のデバイス識別子を伴うメッセージによって示されているポート番号をハッシュすることによって特定することができる。（例えば、アップリンク送信に関しては）ｅＮＢ／ＲＮＣ／ＳＧＳＮ、および／または（例えば、ダウンリンク送信に関しては）Ｐ−ＧＷ／ＧＧＳＮは、個々のデバイスを識別するためにハッシュ関数を使用し、および／またはオリジナルパケットをデバイスへ配信するためにハッシュを除去することができる。

図１３は、３ＧＰＰネットワークにおいて使用するためのＭＴＣ−ＩＷＦ（MTC interworking function）を含む例示的なアーキテクチャを示している。例えば、ＭＴＣ−ＩＷＦは、ＭＴＣサーバ／サーバ管理／制御ＭＴＣオペレーション（an MTC server/a server managing/controlling MTC operation）と、３ＧＰＰコアネットワークとの間におけるインターフェースを形成することができる。例えば、図１３において示されているように、ＭＴＣ−ＩＷＦ１０３２は、ＳＣＳ（Services Capability Server）１３０４とコアネットワークとの間においてやり取りされる制御データのためのインターフェースを提供することができる。ＡＳ１３０８および／またはＡＳ１３１０は、ＭＴＣアプリケーションの例であると言える。ＭＴＣサーバは、ＭＴＣアプリケーションを含むことができる。ＳＣＳ（Services Capability Server）１３０４は、ＭＴＣサーバの一例であると言える。ＳＣＳ１３０４は、コアネットワーク、ＭＴＣ−ＩＷＦ１３０２、ＡＳ１３０８、および／またはＡＳ１３１０の間において、さらなるＭＴＣサービスを提供することができる。

ＭＴＣデバイス１３０６上で実行されるＭＴＣアプリケーションと、外部ネットワーク内のＭＴＣアプリケーション（例えば、ＡＳ１３０８、ＡＳ１３１０、および／またはＳＣＳ１３０４上で実行されるＭＴＣアプリケーション）との間におけるエンドツーエンドの通信は、３ＧＰＰシステムによって提供されるサービス／通信リンク、および／またはＳＣＳ（Services Capability Server）１３０４によって提供されるサービスを使用することができる。図１３は、外部ネットワーク内のＭＴＣアプリケーションが、ＡＳ（Application Server）（例えば、ＡＳ１３０８および／またはＡＳ１３１０）によってホストされていることを示しているが、ＭＴＣアプリケーションは、他のノードまたはサーバ上でホストすることができる。３ＧＰＰシステムは、アーキテクチャ上のさまざまな機能強化を含むトランスポートサービスおよび通信サービスを提供することができる。例えば、ＭＴＣ−ＩＷＦ１３２０および／またはＳＣＳ１３０４は、ＭＴＣ通信のための制御プレーンデバイスのトリガリングを提供することができる。トリガリングとは、３ＧＰＰコアネットワークをアクティブ化するための、または３ＧＰＰコアネットワークへの接続を形成するための表示をＭＴＣデバイスへ送信することを示すことができる。

ＭＴＣ−ＩＷＦ１３０２によって、ＭＴＣアプリケーション同士の間における動作可能な通信が容易になる。例えば、ＭＴＣ−ＩＷＦ１０３２は、グループ識別子のマッピングを実行し、それによって、グループ識別子に関してトリガー要求を行うことができる。トリガー要求は、ＭＴＣデバイス１３０６のグループ、および共通のグループＩＰアドレスまたはＩＰアドレスのグループに関連付けることができる。例えば、ＡＳ１３０８、ＡＳ１３１０、および／またはＳＣＳ１３０４は、ＭＴＣデバイス１３０２のうちの１つまたは複数と通信することを決定することができる。しかし、１つまたは複数のＭＴＣデバイス１３０２が現在ネットワークに接続されていない場合には、ＭＴＣデバイス１３０２は、ＩＰアドレスに関連付けることができず、標準的なＩＰ通信を介して到達することが不可能となる場合がある。ＭＴＣ−ＩＷＦは、ＡＳ１３０８、ＡＳ１３１０、および／またはＳＣＳ１３０４から受信されるグループ識別子に基づいてトリガー要求（例えば、ネットワークへ接続したいという要求）がＭＴＣデバイス１３０２へ送信されるべきであると判定することができる。ＭＴＣ−ＩＷＦ１３０２は、デバイスのグループがＰＤＰコンテキストを共有すべきであることをトリガーメッセージ内で示すことができる。ＭＴＣ−ＩＷＦ１３０２は、受信されたグループ識別子に基づいて共通のグループＩＰアドレスまたはＩＰアドレスのグループを特定することができる。

３ＧＰＰネットワークを使用して、ＭＴＣデバイス１３０６から、およびＳＣＳ１３０４とＡＳ１３０８／１３１０との間において通信されるマシンタイプのトラフィックに関して、いくつかの例示的なモデル／技術が考えられる。例えば、直接モデルにおいては、ＡＳ（例えば、ＡＳ１３１０）は、ＳＣＳ（例えば、ＳＣＳ１３０４）の使用を伴わずにＭＴＣデバイス（例えば、ＭＴＣデバイス１３０６）との直接のユーザプレーン通信を実行するために、直接オペレータネットワークに接続することができる。間接モデルにおいては、ＡＳ（例えば、ＡＳ１３０８）は、ＳＣＳ１３０４のサービスを利用するために、間接的にオペレータネットワークに接続することができる。ＳＣＳ１３０４は、ＭＴＣデバイス（例えば、ＭＴＣデバイス１３０６）との間接的なユーザプレーン通信を容易にすることができ、付加価値のあるさらなるサービス、例えば、制御プレーンデバイスのトリガリングを提供することができる。ＳＣＳ１３０４は、ＭＴＣサービスプロバイダによって、および／または３ＧＰＰネットワークのオペレータによって、制御および／または操作することができる。ＳＣＳがＭＴＣサービスプロバイダによって制御される場合には、ＳＣＳ１３０４は、オペレータドメイン外のエンティティとすることができ、Ｔｓｐは、３ＧＰＰコアネットワークと、サードパーティＭＴＣサービスプロバイダとの間における外部インターフェースとすることができる。ＳＣＳがオペレータドメイン内のエンティティである場合には、Ｔｓｐは、ＰＬＭにとって内部のインターフェースとすることができる。ハイブリッドモデルにおいては、ＡＳ１３０８／１３１０は、さらなるサービスのためにＳＣＳも利用しながらＭＴＣデバイスとの直接のユーザプレーン通信を実行する目的で直接オペレータのネットワークに接続するために、直接モデルおよび間接モデルを同時に使用することができる。

３ＧＰＰネットワークの観点からは、ＡＳからの直接のユーザプレーン通信、およびＳＣＳへの／ＳＣＳからの制御プレーン関連の通信は、独立したものとすることができる。したがって、直接のユーザプレーントラフィックと、ＳＣＳによって提供されるさらなるサービスを利用する間接的な制御プレーントラフィックとを容易にするために、ハイブリッドモデルを利用することができる。別々のモデル（例えば、直接モデル、間接モデル、および／またはハイブリッドモデル）は、相互に排他的ではないものとすることができ、および／または相補的なものとすることができると考えられる。したがって、３ＧＰＰオペレータは、別々のアプリケーションに関するアーキテクチャのうちの１つまたは複数を組み合わせることができると考えられる。そのような組合せは、同じＰＬＭＮと通信する、ＭＴＣサービスプロバイダ、および３ＧＰＰネットワークオペレータによって制御されるＳＣＳの両方の組合せを含むことができる。図１３は、ＭＴＣの通信がＶＰＬＭＮ（visited public land mobile network）とＨＰＬＭＮ（home public land mobile network）との間において行われる例示的なローミングケースを示していると言えるが、理解できるように、非ローミングケースにおいては、ＶＰＬＭＮとＨＰＬＭＮは、同じＰＬＭＮであることが可能である。

いくつかの例示的な構成においては、共通のＰＤＰコンテキストを共有する１つまたは複数のデバイスに、共通のコンテキスト上で使用するための個別のＩＰアドレスを割り振ることができる。言い換えれば、ＩＰアドレス割り振り手順は、ＭＭＥおよび／またはＳＧＳＮが、単一の共有ＰＤＰコンテキストを利用するグループメンバーに個別のＩＰアドレスを割り当てることができるように設計することができる。例えば、ＭＭＥおよび／またはＳＧＳＮは、共有コンテキストグループによって利用される、ＩＰアドレスのリスト、ＩＰアドレスプール、および／またはＩＰクラスを特定または入手することができる。例えば、それらのＩＰアドレスのリスト、ＩＰアドレスプール、および／またはＩＰクラスは、共有コンテキストグループのメンバーによって実行される最初のＰＤＰ接続確立手順中に（例えば、共有コンテキストが初めて確立されるときに）ＭＭＥおよび／またはＳＧＳＮによって特定または入手することができる。例えば、第１のグループメンバーが自分自身をネットワークに接続しようと試みた場合には、ＭＭＥおよび／またはＳＧＳＮは、他の共有コンテキストグループメンバーに関する後続の接続要求のために複数のＩＰアドレスを確保しておくことができる。ユーザプレーントラフィックの転送に関しては、ここで説明されている例のうちの１つまたは複数をベアラ／コンテキストバインディングのために使用することができる。

例えば、ＰＤＮ ＧＷおよび／またはＧＧＳＮは、単一のＧＴＰトンネルへとアグリゲートされるＩＰアドレスのリストを保持することができる。Ｐ−ＧＷおよび／またはＧＧＳＮは、共有コンテキストグループに関するＩＰアドレスのうちのそれぞれを単一のＥＰＣベアラに関連付けるＤＬ ＴＦＴ／ＧＧＳＮマッピング機能を保持することができる。

例えば、共有コンテキストグループに割り当てられるＩＰアドレスファミリーに関して、ベアラバインディング機能は、ＩＰアドレスのグループをその共有コンテキストグループに関連付けるためにワイルドカードを利用することができる。ベアラバインディング機能は、ＰＣＥＦ内に含めることができる。例えば、１０．１０．３５．^＊で始まるクラスＣのＩＰアドレスがＭＴＣグループに割り振られる場合には、クラスＣのトラフィックを共有コンテキストにマップするためにＴＦＴルールを使用することができる。従って、この例においては、共有コンテキストは、１０．１０．３５で始まる任意のＩＰアドレス、例えば、１０．１０．３５．１、１０．１０．３５．２、．．．、１０．１０．３５．^＊などに関連付けることができる。

例えば、ＭＴＣ−ＩＷＦ（例えば、図１３において示されているように、ＭＴＣ−ＩＷＦ１３０２）が利用される場合には、そのＭＴＣ−ＩＷＦは、ＭＴＣサーバ（例えば、ＡＳ１３０８、ＡＳ１３１０、および／またはＳＣＳ１３０４）と、コアネットワークとの間におけるインターフェースを提供することができる。例えば、ＭＴＣ−ＩＷＦ１３０２は、グループ識別子のマッピングを実行することができ、それによって、デバイス（例えば、ＭＴＣデバイス１３０６）のグループに関してトリガー要求を行うことができる。例えば、ＭＴＣ−ＩＷＦは、デバイスのグループがＰＤＰコンテキストを共有すべきであることをトリガーメッセージ内で示すことができる。

あるデバイスが、ネットワークへ接続すること、またはＰＤＮ接続を確立することを試みた場合には、ネットワークおよびそのデバイスは、相互認証および／またはセキュリティ手順を実行することができる。典型的には、デバイスは、例えば個別のＩＭＳＩなどの個別のパラメータを使用して、個別に認証することができる。例えば、たとえ所与のデバイスが共有コンテキストグループのメンバーとして自分自身の身元を明らかにしても、それでもなおそのデバイスを個別に認証することができる。例えば、認証および／またはキー生成（例えば、Ｅ−ＵＴＲＡＮにおけるＥＰＳ ＡＫＡ（EPS Authentication and Key Agreement））は、それぞれの共有コンテキストグループメンバーによって個別に実行することができる。

例えば、共有コンテキストグループ内のそれぞれのデバイスが、個別のＩＭＳＩに関連付けられている場合には、グループメンバーであるデバイスのためのセキュリティを確立するために、およびそれらのデバイスを認証するために、セキュリティおよび認証のための既存の手順を利用することができる。ネットワークは、最初の接続手順（例えば、ＵＭＴＳ）または最初の接続要求（例えば、ＬＴＥ）の後に、それぞれのデバイスごとに認証手順を実行することができる。

例えば、共有コンテキストグループのメンバーのそれぞれを１つの共有グループ識別子に関連付けることができる。このグループ識別子は、グループメンバーの個別のＩＭＳＩに取って代わることができ、または個別のＩＭＳＩに加えて使用することもできる。所与の共有コンテキストグループのメンバーであるデバイスの全てが、やはり１つのグループ識別子を共有する場合、例えば、コアネットワーク要素（例えば、ＭＭＥ／ＳＧＳＮ）は、複数のＷＴＲＵ／デバイスが、同じＩＭＳＩ（例えば、グループ識別子）を含む接続要求を送信する可能性があると判断することができる。例えば、デバイス／ＷＴＲＵは、共有コンテキストグループメンバーである個々のデバイスの接続ステータス／構成をネットワークが識別できるようにするために、第２の識別子を接続要求内に含めて送信することができる。例えば、ＷＴＲＵ／デバイスは、個別の識別子をネットワークに提供することを差し控えることができ、共有コンテキストグループメンバーは、アプリケーションレイヤにおいて識別することができる。この例においては、ネットワークは、接続を試みている共有コンテキストグループメンバーのＩＤを知らなくてもよい。その代わりに、ネットワークは、そのデバイスを、単に共有コンテキストグループのメンバーのうちの１つとして識別することができる。１つのグループ識別子を使用して共有コンテキストを確立することおよび／またはベアラバインディングを実行することを行うためのプロセスは、個別のＩＭＳＩを使用して共有コンテキストを確立することおよび／またはベアラバインディングを実行することを行うプロセスと類似しているが、１つのグループ識別子を用いる複数のデバイスのために使用されるセキュリティ手順は、異なるものとすることができる。

例えば、認証および／またはキー設定手順は、１つのグループ識別子を共有するＭＴＣデバイスなどのデバイス用に修正できる。共有コンテキストグループ内のデバイスはそれぞれ、一意のルートシークレットキー（Ｋｉ）を含むことができる。例えば、共有コンテキストグループ内にｋ個のデバイスが存在する場合には、ｋ番目のデバイスは、ルートシークレットキー（Ｋｉ（ｋ））を含むことができる。例えば、共有コンテキストグループ内のルートシークレットキーのそれぞれは、共有コンテキストグループ内の他のデバイスに関するルートシークレットキーとは異なるものとすることができる（例えば、ルートシークレットキーは一意である）。このケースにおいては、セキュリティセットアップのために、グループメンバーはそれぞれ、同じＩＭＳＩ（例えば、グループＩＭＳＩ（ＩＭＳＩ_Ｇ））を共有しながら一意のルートシークレットキーを使用することができる。

例えば、グループメンバーが、一意のルートシークレットキーおよび共有グループ識別子を含む場合には、デバイスは、認証および／または個別のキーセットアップにおいて使用するための共有接続要求送信シーケンス（shared attach-request transmission sequence）を利用することができる。例えば、共有コンテキストグループメンバーは、既知の順序でネットワークへ接続するよう試みることができ、したがってネットワークは、グループ内のどのデバイスが接続を試みているかを、それまでに接続を試みたデバイスの数に基づいて特定することができる。共有接続要求送信シーケンスは、あらかじめ決定しておくことができ、および／または接続要求を送信する前にデバイスによって決定することもできる。接続シーケンス／順序の知識は、事前確立メッセージ（pre-establishment message）内に含めて共有すること、並びに／またはグループメンバーおよびＨＳＳ／ＨＬＲによってあらかじめ決定しておくことが可能である。

例えば、共通のＩＭＳＩ（例えば、ＩＭＳＩ_Ｇ）を共有している一方で別々のルートシークレットキー（例えば、Ｋｉ（ｋ）｜ｋ＝１，．．．，Ｎ_Ｇ、この場合、Ｎ_ＧはグループＧ内のデバイスの数とすることができる）を利用している共有コンテキストグループの複数のメンバーの複数のＩＤ（例えば、同じグループに属する複数のＭＴＣデバイスの複数のＩＤ）をＨＳＳ／ＨＬＲに知らせることができる。共有コンテキストグループ内のそれぞれのデバイスには、グループ識別子（例えば、ＩＭＳＩ_Ｇ）および個別のルートシークレットキー（例えば、Ｋｉ（ｋ））を事前に供給することができる。ＨＳＳ／ＨＬＲ、および／または、共有コンテキストグループのメンバーであるＭＴＣデバイスのそれぞれは、その同じグループに属するＭＴＣデバイスが接続要求を送信することを許可されるシーケンスの知識を有することもできる。共有コンテキストグループメンバーが接続する順序を決定するために使用されるシーケンスは、疑似ランダムシーケンスとすることができる。例えば、疑似ランダムシーケンスは初期値に基づいて算出できる。その初期値は、デバイスおよびＨＳＳ／ＨＬＲに事前に供給しておくことができる。例えば、疑似ランダムシーケンスは、初期値に基づいて算出することができ、その初期値は、ＨＳＳ／ＨＬＲにおいて決定して、無線で共有コンテキストグループメンバーへ送信できる。共有コンテキストグループ内のそれぞれのデバイスは、いつそのグループメンバーが自分の接続要求を送信すべきかを決定するためのタイマーを保持することができる。そのタイマーによって、共有コンテキストグループメンバーが、上述の接続要求送信シーケンスに従って特定の時間インスタンスにおいて接続要求を送信できるようになる。

例えば、共有コンテキストグループ内の第１のＭＴＣデバイスは、接続要求をＭＭＥおよび／またはＳＧＳＮへ送信することができる。その接続要求は、グループ識別子（例えば、ＩＭＳＩ_Ｇ）を含みうる。ＨＳＳ／ＨＬＲは、共有コンテキストグループ内のどのＭＴＣデバイスが第１の接続要求を送信することになるかを知ることができる。例えば、共有コンテキストグループ内の特定のデバイスは、グループ内のデバイスが接続を試みるたびに第１の接続要求を送信することができ、グループメンバーおよび／またはＨＳＳ／ＨＬＲは、その第１のデバイスのＩＤを知ることができる。ＨＳＳ／ＨＬＲは、他の共有コンテキストグループメンバーが第１のデバイスによる最初の接続要求に続いて接続要求を送信できる時間枠（time period window）を決定するための１つまたは複数のタイマーを保持することができる。例えば、ＭＭＥおよび／またはＳＧＳＮは、どのグループメンバーが接続要求シーケンス内の次なる接続要求を送信しているかを識別するためのもう１つのタイマーを保持することができる。ＭＭＥは、その接続要求をＨＳＳ／ＨＬＲへ転送する際に、その接続要求を送信しているグループメンバーのＩＤを示すことができる。

ＨＳＳ／ＨＬＲは、ある接続要求が、共有コンテキストグループに関する第１の接続要求を送信することを許可されているＭＴＣデバイスからのものであると判定した場合には、第１のＭＴＣデバイスに関するルートシークレットキー（例えば、Ｋｉ（１））を特定することができる。ＨＳＳ／ＨＬＲは、Ｋｉ（１）に対応するＡＫＡ ＡＶ（Authentication Vector）を生成することができ、認証要求を共有コンテキストグループの第１のＭＴＣデバイスへ送信することができる。その認証要求は、ＡＶのＲＡＮＤおよび／またはＡＵＴＮ部分を含むことができる。

共有コンテキストグループの第１のＭＴＣデバイスは、ＡＶのＲＡＮＤおよびＡＵＴＮ部分を受信できる。共有コンテキストグループの第１のＭＴＣデバイスは、ＨＳＳ／ＨＬＲを認証することができ、認証応答を算出することができる。その認証応答は、受信されたＡＶに基づいて共有コンテキストグループの第１のＭＴＣデバイスによって算出されたＲＥＳを含むことができる。共有コンテキストグループの第１のＭＴＣデバイスは、ネットワークに対して自分自身を認証するために、認証応答をＨＬＲ／ＨＳＳへ送信できる。

ＨＳＳ／ＨＬＲは、認証応答内に含まれているＲＥＳに基づいて共有コンテキストグループの第１のＭＴＣデバイスを認証しようと試みることができる。ＨＬＲ／ＨＳＳは、共有コンテキストグループの第１のＭＴＣデバイスの認証に成功した場合には、同じ共有コンテキストグループ内の他のＭＴＣデバイスが認証を試みると予想されるシーケンスＳを入手および／または特定することができる。ＨＳＳ／ＨＬＲは、同じ共有コンテキストグループに属するＭＴＣデバイスの残りを認証する際に使用するためのＡＶのセットを特定することができる。ＨＬＲ／ＨＳＳは、共有コンテキストグループの第１のメンバーの成功した認証に続く単一のインスタンスにおいてＡＶのセットを特定することができ、またはそれぞれの接続要求および／若しくは認証応答を受信する際にＡＶを個別に算出することもできる。例えば、ＨＳＳ／ＨＬＲは、共有コンテキストグループ内の第１のデバイスの認証に成功すると、残りのデバイスに関するＡＶのセットを認証のシーケンスのためにＭＭＥに提供することができる。例えば、ＨＳＳ／ＨＬＲは、グループ内の第１のデバイスに関する認証要求を受信すると、グループメンバーのうちのそれぞれに関するＡＶのセットをそのグループの後続の認証のためにＭＭＥに提供することができる。共有コンテキストグループ内のｋ番目のデバイス（例えば、この場合、ｋ＝１，２，．．，Ｎ_Ｇ）に対応するＡＶは、そのグループ内のｋ番目のＭＴＣデバイスに関するＫｉ（ｋ）を使用してＨＬＲ／ＨＳＳによって算出することができる。

共有コンテキストグループ内の第１のデバイスの認証が成功すると、他の共有コンテキストグループメンバーはそれぞれ、認証要求送信の同じシーケンスＳを入手および／または特定することができる。共有コンテキストグループのメンバーであるそれぞれのデバイスは、自分自身の認証応答送信のタイミングを、シーケンス内の自分の位置に基づいて特定することができる。例えば、他のグループメンバーは、その特定されたタイミングに基づいて、オリジナルの認証要求メッセージ内に含まれているＡＶ、グループ識別子、および／または各自のルートシークレットキー（例えば、Ｋｉ（２），Ｋｉ（３），．．．，Ｋｉ（Ｎ_Ｇ））を使用して、個別の認証応答を送信することができる。別の例においては、それぞれのグループメンバーには、個別のＡＶ、グループ識別子、および／または各自のルートシークレットキー（例えば、Ｋｉ（２），Ｋｉ（３），．．．，Ｋｉ（Ｎ_Ｇ））に基づいて認証応答を計算するための個別のＡＶを送信することができる。

例えば、共有コンテキストグループメンバーのうちのそれぞれは、特定されたシーケンスＳに従って認証を実行できる。例えば、ＨＳＳ／ＨＬＲは、個々の共有コンテキストグループメンバーのそれぞれに関して個別の認証ベクトルを生成できる。例えば、ＨＳＳ／ＨＬＲは、共有コンテキストグループ内のｊ番目のＭＴＣデバイスに対応するＭＭＥから認証要求を受信すると、ｊ番目のＭＴＣデバイスとの間で共有されているＫｉ（ｊ）に対応するＡＶ（ｊ）をそのＭＭＥへ送信できる。ＭＭＥは、ＡＶ（ｊ）のＲＡＮＤおよびＡＵＴＮを、他のパラメータとともにｊ番目のＭＴＣデバイスへ転送できる。ｊ番目のＭＴＣデバイスは、ＡＶ（ｊ）およびＫｉ（ｊ）に対応する特定されたＲＥＳ（ｊ）を含む認証応答をＭＭＥへ送信できる。ＭＭＥは、ＲＥＳ（ｊ）に基づいてｊ番目のＭＴＣデバイスを認証することができ、セッションキーＫｓ（ｊ）を導出できる。ＭＭＥは、認証成功メッセージをｊ番目のＭＴＣデバイスへ送信できる。ｊ番目のＭＴＣデバイスは、認証成功メッセージを受信すると、同じセッションキーＫｓ（ｊ）を特定できる。次いで、このプロセスをシーケンスＳに従って（ｊ＋１）番目のＭＴＣデバイスに関して繰り返すことができる。

例えば、接続要求は、１つの共有コンテキストグループ内のＭＴＣデバイス同士を区別するために使用できるさらなる情報を含むことができる。例えば、グループ識別子（例えば、グループＩＭＳＩ）を共有する個々のＭＴＣデバイスに関する認証および個別のキーセットアップは、共有コンテキストグループ内のＭＴＣデバイスのそれぞれが、同じ共有グループ識別子（例えば、ＩＭＳＩ_Ｇ）に加えて、個々のデバイスを個別に識別するためのさらなる情報を送信する場合には、個別に実行することができる。例えば、ある共有コンテキストグループのメンバーであるデバイスは、その共有コンテキストグループのどのメンバーが接続要求を送信しているかを一意に識別することができるさらなる情報要素をその接続要求内に含めて送信することができる。

例えば、共通のＩＭＳＩ（例えば、ＩＭＳＩ_Ｇ）を共有している一方で別々のルートシークレットキー（例えば、Ｋｉ（ｋ）｜ｋ＝１，．．．，Ｎ_Ｇ、この場合、Ｎ_ＧはグループＧ内のデバイスの数とすることができる）を利用している共有コンテキストグループの複数のメンバーの複数のＩＤ（例えば、同じグループに属する複数のＭＴＣデバイスの複数のＩＤ）をＨＳＳ／ＨＬＲに知らせることができる。共有コンテキストグループ内のそれぞれのデバイスには、グループ識別子（例えば、ＩＭＳＩ_Ｇ）および個別のルートシークレットキー（例えば、Ｋｉ（ｋ））を事前に供給することができる。ある共有コンテキストグループ内のＭＴＣデバイスのうちのそれぞれは、その共有コンテキストグループ内の単一のデバイスを個別に識別するために使用可能なさらなる情報を提供されることが可能であり、および／またはそうした情報を特定することができる。共有コンテキストグループ内のデバイスを個別に識別するために使用可能な情報をＭＴＣデバイス個別識別情報（例えば、ＩＩＩ_ＭＴＣＤ）と呼ぶことができる。ＩＩＩ_ＭＴＣＤの一例は、ＩＭＥＩ（international mobile equipment identity）および／またはＩＭＳＩであると言える。共有コンテキストグループを伴うｋ番目のデバイスに関するＩＩＩ_ＭＴＣＤをＩＩＩ_{ＭＴＣＤ（ｋ）}と示すことができる。

ＨＳＳ／ＨＬＲは、共有コンテキストグループに属するＭＴＣデバイスのそれぞれに関するＩＩＩ_ＭＴＣＤを知ることおよび／または特定することが可能である。ＨＳＳ／ＨＬＲは、共有コンテキストグループ内のＭＴＣデバイスのそれぞれに関する認証ベクトル｛ＡＶ（ｋ）；ｋ＝１，２，．．．Ｎ_Ｇ｝を事前に供給されることが可能であり、および／またはそうした認証ベクトルを個別に特定することができる。ＡＶ（ｋ）は、ＩＭＳＩ_Ｇおよび個別の共有キーＫｉ（ｋ）に基づいてＨＬＲ／ＨＳＳによって特定することができ、その個別の共有キーＫｉ（ｋ）は、共有コンテキストグループのメンバーであるｋ番目のデバイスに固有のものとすることができる。

共有コンテキストグループに属するＭＴＣデバイスは、接続要求メッセージをネットワークへ送信することによって、認証プロセスを開始できる。接続要求を送信している個々のデバイスを識別するために、ＥＰＳ接続タイプ情報要素は、送信を行っているデバイスを、共有コンテキストグループに属するものとして識別できる。送信を行っているデバイスは共有コンテキストグループのメンバーであるという表示を含めることは、ネットワークが、共有コンテキストグループのメンバーではないデバイスのための接続要求の場合とは異なる様式で接続要求メッセージを処理することをトリガーすることができる。テーブル１は、ＥＰＥ接続タイプＩＥのオクテット１におけるＥＰＳ接続タイプ値に関して「０１１」という値を使用することが、その接続要求がＥＰＳグループ接続手順の一部であることをどのようにして示すことができるかを示している。

共有コンテキストグループ内のＭＴＣデバイス、例えばｋ番目のデバイスは、接続要求をＭＭＥへ送信できる。この接続要求は、グループ識別子（例えば、ＩＭＳＩ_Ｇ）と、個別ＭＴＣデバイス識別情報（例えば、ＩＩＩ_{ＭＴＣＤ（ｋ）}）とを含むことができる。この接続要求内には、ＩＭＳＩ_Ｇに加えて、個別ＭＴＣデバイス識別情報（例えば、ＩＩＩ_{ＭＴＣＤ（ｋ）}）を付加することができる。

例えば、グループ識別子（例えば、ＩＭＳＩ_Ｇ）を個別ＭＴＣデバイス識別情報（例えば、ＩＩＩ_{ＭＴＣＤ（ｋ）}）と結合して、共有コンテキストグループメンバー固有の量を導出することができ、その固有の量を、ｋ番目のデバイスに関するＭＴＣデバイス結合ＩＤ情報（ＤＣＩ_{ＭＴＣＤ（ｋ）}）と呼ぶことができる。ｋ番目のデバイスに関するＭＴＣデバイス結合ＩＤ情報（ＤＣＩ_{ＭＴＣＤ（ｋ）}）は、１５桁の長さになるように、および既存の接続要求メッセージのＩＭＳＩフォーマットに準拠するように設計できる。例えば、デバイスおよび／またはネットワークノードは、式（１）に基づいて、ｋ番目のデバイスに関するＭＴＣデバイス結合ＩＤ情報（ＤＣＩ_{ＭＴＣＤ（ｋ）}）を特定できる。
DCI_MTCD(k)=MCC||MNC||ID_G||ConvertDigit{Trunc{HA{IMSI_G||IID_MTCD(k)},12-LenDigits{MNC||ID_G}}}} 式（１）

この場合、ＭＣＣは、３桁のモバイルカントリーコードであり、ＭＮＣは、オリジナルのグループ識別子（例えば、ＩＭＳＩ_Ｇ）の（例えば、ＥＵにおいては）２桁または（例えば、米国においては）３桁のモバイルネットワークコードであり、ＩＤ_Ｇは、グループＩＤの桁表示であり、ＨＡ｛ｘ｝は、暗号化ハッシュ関数（例えば、ＳＨＡ−１および／または他の暗号化ハッシュ関数）であり、Ｔｒｕｎｃ｛ｘ，ｙ｝は、任意のビットシーケンスｘを切り捨ててｙ桁にする関数であり、ＣｏｎｖｅｒｔＤｉｇｉｔ｛ｘ｝は、バイナリシーケンスｘを数字へと変換する関数であり、およびＬｅｎＤｉｇｉｔｓ｛ｘ｝は、入力ｘの桁の長さを出力する関数であると言える。

ＭＭＥは、接続要求を受信すると、ＤＣＩ_{ＭＴＣＤ（ｋ）}を表す値を含む接続要求をＨＳＳ／ＨＬＲへ転送できる。ＨＳＳ／ＨＬＲは、ＭＴＣデバイスグループおよび／または共有コンテキストグループを、例えばＭＮＣおよびＩＤＧに基づいて識別できる。ＨＳＳ／ＨＬＲは、共有コンテキストグループのメンバーであるＭＴＣデバイスに関する｛ＤＣＩ_{ＭＴＣＤ（ｊ）}｜｜ｊ＝１，２，．．．，Ｎ_Ｇ｝の可能な値の知識を有することができる。例えば、ＨＳＳ／ＨＬＲは、ＩＤ_Ｇを表す値を特定した時点で、そのグループのＩＤを特定済みであることが可能であり、ＨＳＳ／ＨＬＲは、個別ＭＴＣデバイス識別情報（例えば、ＩＩＩ_{ＭＴＣＤ（ｋ）}）の値のそれぞれをそれまでに特定および／または格納しておくことができる。従って、ＨＬＲ／ＨＳＳは、ＤＣＩ_{ＭＴＣＤ（ｉ）}を含む認証要求を受信した場合には、認証の目的でどのＡＶ（ｋ）を提供するかを特定できる。ＨＬＲ／ＨＳＳは、ＤＣＩ_{ＭＴＣＤ（ｉ）}によって識別されたデバイスに関するＡＶに対応するＡＶを送信できる。ＤＣＩ_{ＭＴＣＤ（ｉ）}によって識別されたデバイスに関するＡＶに対応するＡＶ（例えば、ＡＶ（ｋ））は、グループ識別子（例えば、ＩＭＳＩ_Ｇ）およびＫｉ（ｋ）に基づいて特定できる。ＨＬＲ／ＨＳＳは、受信されたＤＣＩ_{ＭＴＣＤ（ｋ）}内に含まれているデバイス数ｋに関する識別情報に基づいてＫｉ（ｋ）を特定できる。

ＨＳＳ／ＨＬＲは、ＡＶ（ｋ）をＭＭＥへ送信できる。次いでＭＭＥは、ＡＶ（ｋ）のＲＡＮＤおよびＡＵＴＮ部分を含む認証要求を、共有コンテキストグループのメンバーであるｋ番目のＭＴＣデバイス（例えば、接続要求を送信したデバイス）へ送信できる。共有コンテキストグループのメンバーであるｋ番目のＭＴＣデバイスは、ＡＶ（ｋ）のＲＡＮＤおよびＡＵＴＮ部分を受信し、その受信された情報を使用してＨＳＳ／ＨＬＲを認証することができる。共有コンテキストグループのメンバーであるｋ番目のＭＴＣデバイスは、認証応答を決定して、その認証応答をＭＭＥへ送信できる。その認証応答は、ＡＶ（ｋ）の受信されたＲＡＮＤおよびＡＵＴＮ部分並びに共有キーＫｉ（ｋ）に基づいて、共有コンテキストグループのメンバーであるｋ番目のＭＴＣデバイスによって算出されたＲＥＳ（ｋ）を含むことができる。ＭＭＥは、ＨＬＲ／ＨＳＳがＭＴＣデバイスサブスクリプションを認証できるようにするために、その認証応答をＨＬＲ／ＨＳＳへ転送できる。ＨＳＳ／ＨＬＲは、受信されたＲＥＳ（ｋ）に基づいてＭＴＣデバイスを認証するよう試みることができる。同様の認証手順を、その共有コンテキストグループに属する他のＭＴＣデバイスに関しても繰り返すことができる。その共有コンテキストグループの個々のメンバーに関する個別の識別情報（例えば、ＩＩＩ_{ＭＴＣＤ（ｋ）}）が接続要求内に含まれている場合には、その共有コンテキストグループのメンバーは、任意の時点において任意の順序でネットワークに接続できる。

例えば、ゲートウェイデバイスは、自分自身を共有コンテキストグループの代表として認証するために利用することができ、共有コンテキストグループのメンバーである他の非ゲートウェイデバイスは、デバイスツーデバイス接続に基づいて認証できる。

例えば、グループ識別子（例えば、ＩＭＳＩ_Ｇ）を共有する個々のＭＴＣデバイスに関する認証および個別のキーセットアップは、相互認証を行うことができるゲートウェイを使用して実行することができる。例えば、共有コンテキストグループの一部である他のＭＴＣデバイスのそれぞれとの間で非３ＧＰＰ相互認証および／またはキー導出プロセスを実行するように構成されているＭＴＣゲートウェイデバイスが存在しうる。例えば、図９に関して、ＭＴＣゲートウェイデバイス９０４は、ローカルアクセスデバイス９０６、ＭＴＣデバイス９０８、ローカルアクセスデバイス９１０、および／またはＭＴＣデバイス９１２との間で動作可能な通信を行える３ＧＰＰデバイス（例えば、ＷＴＲＵ）とすることができる。ＭＴＣゲートウェイデバイス９０４は、共有コンテキストグループのメンバーとすることができる。ローカルアクセスデバイス９０６、ＭＴＣデバイス９０８、ローカルアクセスデバイス９１０、および／またはＭＴＣデバイス９１２も、同じ共有コンテキストグループのメンバーとすることができる。ローカルアクセスデバイス９０６、ＭＴＣデバイス９０８、ローカルアクセスデバイス９１０、および／またはＭＴＣデバイス９１２をＭＴＣ非ゲートウェイデバイスと呼ぶことができる。ＭＴＣゲートウェイデバイス９０４は、３ＧＰＰネットワークに対してＭＴＣ非ゲートウェイデバイスを認証するために、デバイスツーデバイス接続を使用できる。例えば、ＭＴＣゲートウェイデバイス９０４は、非ゲートウェイデバイスのそれぞれに関するセッションキーを相互に入手するように構成することができる。非ゲートウェイデバイスのそれぞれは、自分の対応するセッションキーを、例えばゲートウェイデバイスから（例えば、暗号で保護されたメッセージを介して）そのセッションキーを受信することによって入手できる。別の例においては、ＭＴＣゲートウェイデバイス９０４およびＭＴＣ非ゲートウェイデバイスは、ゲートウェイと非ゲートウェイデバイスとの間における共有されているシークレットに基づいてセッションキーをやり取りすることができる。

例えば、ＭＴＣゲートウェイデバイスは、３ＧＰＰネットワークとの間で相互認証を実行し、ネットワークに対してＭＴＣデバイスの「グループ」を認証することができる。例えば、ゲートウェイは、自分自身との間で非ゲートウェイデバイスを認証し、次いで、例えばゲートウェイと非ゲートウェイデバイスとの間において実行された認証手順の中で受信された情報に基づいて、３ＧＰＰネットワークとの間で非ゲートウェイデバイスを認証することができる。ＭＴＣゲートウェイデバイスは、非ゲートウェイデバイスおよび／または共有コンテキストグループデバイスを認証するのと同時に、３ＧＰＰネットワークとの間で自分自身を認証することができる。ＭＴＣゲートウェイデバイスは、グループを認証すると、３ＧＰＰセッションキーを、その後の通信において使用するために非ゲートウェイデバイスに配信することができる。

例えば、ＭＴＣゲートウェイデバイスおよび／またはＭＴＣ非ゲートウェイデバイスは、ＭＴＣ非ゲートウェイデバイスからＭＴＣゲートウェイデバイスへのキーを確立できる。例えば、ＭＴＣゲートウェイデバイスは、自分自身と、１つまたは複数の非ゲートウェイデバイスとの間において非３ＧＰＰ相互認証を実行できる。非３ＧＰＰ相互認証手順は、ゲートウェイデバイスと、非ゲートウェイデバイスとの間における暗号通信をサポートするためのローカルキーを確立することができる。例えば、非３ＧＰＰ相互認証手順／ローカルキーは、さまざまな個々の非ゲートウェイデバイスが３ＧＰＰネットワークとの間で認証された後にそれらの個々の非ゲートウェイデバイスへ配信できる３ＧＰＰネットワークの知っているキーを通信するために使用できる。ＭＴＣゲートウェイデバイスは、例えば既存の３ＧＰＰ／ＬＴＥ ＡＫＡメカニズムを使用して、自分自身とネットワークとの間において（例えば、ＭＭＥおよびＨＳＳ／ＨＬＲとの間で）３ＧＰＰ相互認証を実行できる。３ＧＰＰ相互認証手順の結果、ゲートウェイデバイスは、３ＧＰＰネットワークからゲートウェイキーを特定できるようになる。次いでゲートウェイデバイスは、ネットワークから受信されたゲートウェイキーに基づいて、自分自身に関するデバイス固有キーを特定することができる。

ＭＴＣゲートウェイデバイスは、入手したゲートウェイキーに基づいて、共有コンテキストグループ内の他のＭＴＣデバイスに関するデバイス固有キーを特定できる。ＭＴＣゲートウェイデバイスは、特定されたデバイス固有キーを、例えばローカルの非３ＧＰＰ認証手順中に特定されたローカルキーを使用して、非ゲートウェイデバイスへ配信できる。ＭＴＣゲートウェイデバイスは、非ゲートウェイデバイスに関する個別のデバイス固有キーをＭＭＥへ送信できる。したがって、ＭＴＣゲートウェイデバイスは、ネットワーク（例えば、ＭＭＥおよび／またはＨＬＲ／ＨＳＳ）のために非ゲートウェイデバイスを認証できる。従ってＭＭＥは、共有コンテキストグループ内のＭＴＣデバイスの認証を、それぞれの非ゲートウェイデバイスごとに個別に行ったのではなく、効果的に行ったと言える。また、ＭＭＥは、ゲートウェイデバイスおよび非ゲートウェイデバイスの両方に関する個別のキーへのアクセスを有することができる。

例えば、ゲートウェイデバイスは、個別のデバイス識別情報（例えば、ＩＩＩ_ＭＴＣＤ）を含めることによって、１つまたは複数の非ゲートウェイデバイスの認証を実行できる。ゲートウェイデバイスは、ＭＴＣ非ゲートウェイデバイスからＭＴＣゲートウェイデバイスへのキーを、接続要求が個別識別情報を含んでいないケースと同様の様式で確立できる。例えば、ＭＴＣゲートウェイデバイスは、自分自身と、１つまたは複数の非ゲートウェイデバイスとの間において非３ＧＰＰ相互認証を実行できる。非３ＧＰＰ相互認証手順は、ゲートウェイデバイスと、非ゲートウェイデバイスとの間における暗号通信をサポートするためのローカルキーを確立できる。ゲートウェイデバイスは、接続要求を３ＧＰＰネットワークへ送信できる。その接続要求は、グループ識別子および／または１つ若しくは複数の個別のデバイス識別子を識別できる。例えば、ゲートウェイデバイスは、そのゲートウェイデバイスに関する個別のデバイス識別子を接続要求内に含めることができるが、非ゲートウェイデバイスに関する個別の識別子は含めないことができる。例えば、ゲートウェイデバイスは、そのゲートウェイデバイスに関する個別のデバイス識別子、並びに非ゲートウェイデバイスに関する１つまたは複数の個別の識別子を接続要求内に含めることができる。

ＭＴＣゲートウェイデバイスは、例えば既存の３ＧＰＰ／ＬＴＥ ＡＫＡメカニズムを使用して、自分自身とネットワークとの間において（例えば、ＭＭＥおよびＨＳＳ／ＨＬＲとの間で）３ＧＰＰ相互認証を実行できる。３ＧＰＰ相互認証手順の結果として、ゲートウェイデバイスは、３ＧＰＰネットワークからゲートウェイキーを特定できるようになると言える。次いでゲートウェイデバイスは、ネットワークから受信されたゲートウェイキーに基づいて、自分自身に関するデバイス固有キーを特定できる。

ＭＴＣゲートウェイデバイスは、入手したゲートウェイキーに基づいて、共有コンテキストグループ内の他のＭＴＣデバイスに関するデバイス固有キーを特定できる。ＭＴＣゲートウェイデバイスは、特定されたデバイス固有キーを、例えばローカルの非３ＧＰＰ認証手順中に特定されたローカルキーを使用して、非ゲートウェイデバイスへ配信できる。ＭＴＣゲートウェイデバイスは、非ゲートウェイデバイスに関する個別のデバイス固有キーをＭＭＥへ送信できる。従って、ＭＴＣゲートウェイデバイスは、ネットワーク（例えば、ＭＭＥおよび／またはＨＬＲ／ＨＳＳ）のために非ゲートウェイデバイスを認証できる。従ってＭＭＥは、共有コンテキストグループ内のＭＴＣデバイスの認証を、それぞれの非ゲートウェイデバイスごとに個別に行ったのではなく、効果的に行ったと言える。また、ＭＭＥは、ゲートウェイデバイスおよび非ゲートウェイデバイスの両方に関する個別のキーへのアクセスを有することができる。

例えば、ゲートウェイデバイスは、３ＧＰＰネットワークとの間での認証を、（ゲートウェイデバイスを含む）共有コンテキストグループのデバイスのうちの１つ、複数、および／または全てが、ネットワークによるゲートウェイデバイスの認証中にネットワークに対して認証されうるような方法で実行できる。例えば、認証中にゲートウェイデバイスが３ＧＰＰネットワークへ送信する認証応答（ＲＥＳ）は、１つまたは複数の個別のルートシークレットキーＫｉ（ｋ）に基づいて判定できる。例えば、認証中にゲートウェイデバイスが３ＧＰＰネットワークへ送信する認証応答（ＲＥＳ）は、共有コンテキストグループのメンバーのうちの全て（例えば、非ゲートウェイデバイスの全て、並びにゲートウェイデバイス自身）に関する個別のルートシークレットキーＫｉ（ｋ）の全てに基づいて特定できる。例えば、ゲートウェイデバイス（および／またはＨＳＳ／ＨＬＲ）は、個別のルートシークレットキーの暗号の組合せに基づいて特定される適切なＲＥＳ値（例えば、ＨＳＳ／ＨＬＲのケースにおいてはＸＲＥＳ値）を特定して使用することができる。

例えば、適切なＲＥＳ値および／またはＸＲＥＳ値を、サイズＮの共有コンテキストグループに関して特定することができ、個々のグループメンバーを認証するために使用することができる。例えば、非ゲートウェイデバイス（例えば、ｋ番目のデバイス）は、ノンス（ｋ）を含む認証要求をゲートウェイデバイスから受信できる。その非ゲートウェイデバイスは、応答（例えば、ＲＥＳ（ｋ）、この場合、ｋ＝１，２，．．，Ｎ_Ｇ−１）を送信することによって、ゲートウェイデバイスに対して自分自身を認証することができる。その応答は、式（２）に基づいて特定できる。
RES(k)=hash(Ki(k)||nonce(k)) 式（２）

例示の目的で、ゲートウェイデバイスに関する代表的なインデックスとしてｋ＝Ｎ_Ｇを使用することができ、非ゲートウェイデバイスには、ｋ＝１からｋ＝Ｎ_Ｇ−１までインデックスを付けることができる。例えば３ＧＰＰ ＡＫＡに関するノンス（ｋ）は、ｋ番目のデバイスに関するＲＡＮＤおよびＡＵＴＮ値を含むことができる。

ゲートウェイデバイスは、非ゲートウェイデバイスからの応答（例えば、｛ＲＥＳ（ｋ）｝ｋ＝１，．．，Ｎ_Ｇ−１）を受信すると、ＭＭＥへ送信されることになる自分自身の応答（例えば、ＲＥＳ（Ｎ_Ｇ））を算出することができる。ゲートウェイによって特定される応答値（例えば、ＲＥＳ（Ｎ_Ｇ））は、個別の応答（例えば、ＲＥＳ（１）、ＲＥＳ（２）、．．．、ＲＥＳ（Ｎ_Ｇ−１））のそれぞれ、並びにそれまでにＭＭＥからゲートウェイデバイスへ送信されたノンス（Ｎ_Ｇ）値、および／またはゲートウェイデバイスに関するルートシークレットキー（例えば、Ｋｉ（Ｎ_Ｇ））に基づくことができる。例えば、ゲートウェイデバイスから送信されることになるＲＥＳ（Ｎ_Ｇ）を、ゲートウェイデバイスに関するルートシークレットキー（例えば、Ｋｉ（Ｎ_Ｇ））と、それまでにＭＭＥからゲートウェイデバイスへ送信されたノンス（Ｎ_Ｇ）値と、ゲートウェイデバイスによって非ゲートウェイデバイスから受信された個別の応答とに基づいて特定するために、下記のループを使用することができる。
Temp=hash(Ki(N_G)||nonce(N_G));
For k=1 to N_G-1
Temp=hash(Temp||RES(k));
End;
RES(N_G)=Temp;

したがって、最終的にネットワークへ返される応答（例えば、ＲＥＳ（Ｎ_Ｇ））は、非ゲートウェイデバイスの個別の応答と、ゲートウェイデバイスの個別の応答とに基づいて、ゲートウェイデバイスによって特定される。理解できるように、非ゲートウェイデバイスの１つが、ゲートウェイデバイスによって認証されることに失敗した場合には、ゲートウェイデバイスは、ネットワークへ返されることになる自分自身の認証（これは、共有コンテキストグループ全体に関する認証となることができる）に関する有効なＲＥＳを算出できないと言える。従ってグループは、ＨＳＳ／ＨＬＲに対して認証されることが不可能となる。例えば、（ゲートウェイおよび非ゲートウェイデバイスを含む）共有コンテキストグループデバイスに関する個別のキーを、共有コンテキストグループデバイスの１つ若しくは複数および／またはＭＭＥによって特定することができる。

例えば、キーＫｓ（Ｎ_Ｇ）は、ゲートウェイデバイスに関するセッションキーとすることができる。例えば、キーＫｓ（Ｎ_Ｇ）は、共有コンテキストグループデバイスの１つ若しくは複数および／またはＭＭＥによって、式（３）を使用して特定することができる。
Ks(N_G)=CK(N_G)||IK(N_G) 式（３）

Ｋｓ（Ｎ_Ｇ）は、ＭＭＥおよび／またはゲートウェイデバイスによって、ＵＭＴＳ／ＬＴＥ ＡＫＡセッションキーＫｓの導出と同様の様式で特定できる。例えば、認証ベクトルＡＶ（Ｎ_Ｇ）の一部として、Ｋｉ（Ｎ_Ｇ）およびＲＡＮＤ（Ｎ_Ｇ）を使用することができ、Ｋｉ（Ｎ_Ｇ）は、ＵＭＴＳ ＡＫＡキー導出関数（例えば、非特許文献２に記載されているｆ３ｋおよびｆ４ｋ関数などのＫＤＦ）における暗号情報ソースとして使用できる。

例えば、キー｛Ｋｓ（ｋ）；ｋ＝１，．．．，Ｎ_Ｇ−１｝（例えば、非ゲートウェイデバイスに関するセッションキー）は、非ゲートウェイデバイスに関する個別のルートシークレットキー（例えば、Ｋｉ（ｋ）；ｋ＝１，．．．，Ｎ_Ｇ−１）および認証ベクトルＡＶ（ｋ）のＲＡＮＤ部分の知識に基づいてＭＭＥにおいて特定できる。例えば、グループメッセージおよび／またはマルチキャストメッセージの保護において使用するために、別個の「グループセッションキー」（Ｋｓ（Ｇ）と呼ぶことができる）を特定できる。例えば、Ｋｓ（Ｇ）は、適切に操作／処理されたＫｉ（Ｇ）およびＲＡＮＤ（Ｇ）を使用して、ＵＭＴＳ／ＬＴＥ ＡＫＡセッションキーＫｓの導出と同様の様式で導出できる。

ＰＤＰコンテキストは、３ＧＰＰゲートウェイを通じて通信する複数のキャピラリーネットワークデバイスにわたって共有することができる。キャピラリーネットワークデバイスは、非３ＧＰＰデバイスとすることができる。非３ＧＰＰデバイスとは、３ＧＰＰ通信プロトコルとは異なる通信プロトコルを使用して通信するように構成されているデバイスを示す。例えば、ＩＥＥＥ８０２．１１は、非３ＧＰＰプロトコルの一例であり、ＩＥＥＥ８０２．１１プロトコルを使用して通信するように構成されているデバイスは、非３ＧＰＰデバイスの一例であると言える。例えば、非３ＧＰＰデバイスは、３ＧＰＰプロトコルを使用して通信することができないデバイスであると言える。例えば、非３ＧＰＰデバイスは、３ＧＰＰネットワークに対するサブスクライバではないと言える。

例えば、複数の非３ＧＰＰデバイスにわたってＰＤＰ接続を共有することは、ＰＤＰコンテキストアクティブ化手順を修正することによって実行することができる。図１４は、ＷＴＲＵ／ＭＴＣゲートウェイデバイスによって実行可能な例示的なＰＤＰコンテキストアクティブ化手順を示している。例えば、図１４において示されているように、ＷＴＲＵ／ＭＴＣゲートウェイ１４０２（これは、共有コンテキストグループの一部である１つまたは複数のキャピラリーネットワークデバイスのためのゲートウェイとして機能する３ＧＰＰ ＷＴＲＵとすることができる）は、ＰＤＰコンテキストアクティブ化要求１４１０をＳＧＳＮ１４０６へ送信することができる。ＰＤＰコンテキストアクティブ化要求１４１０は、確立されている新たなＰＤＰコンテキストに関してコアネットワークが複数のＩＰアドレスを割り当てることを求める要求を含むことができる。例えば、ＰＤＰコンテキストアクティブ化要求１４１０内に含まれているプロトコル構成オプションＩＥは、ＷＴＲＵ／ＭＴＣゲートウェイ１４０２によって要求されているＩＰアドレスの数の表示を含むことができる。例えば、ＷＴＲＵ／ＭＴＣゲートウェイ１４０２は、ＩＰアドレスの所望の数を示すために、プロトコル構成オプションＩＥ内のスペアビットを利用できる。ＷＴＲＵ／ＭＴＣゲートウェイ１４０２に関する例示的なプロトコル構成オプションが、テーブル２において示されている。

コアネットワークは、例えばテーブル２において示されているように、プロトコル構成オプションＩＥのオクテット３内の４つのスペアビットに基づいて、要求されているＩＰアドレスの数を特定できる。例えば、要求されているＩＰアドレスの数は、下記の技術のうちの１つまたは複数を使用してエンコードすることができる。

例えば、要求されているＩＰアドレスの数は、スペアビットが、要求されているＩＰアドレスの数−１を表すことができるような方法でエンコードすることができる。例えば、「００００」というスペアビット値は、ＷＴＲＵが単一のＩＰアドレスを要求していることを示すことができる。「１１１１」というスペアビット値は、ＷＴＲＵが１６個のＩＰアドレスを要求していることを示すことができる。このアプローチでは、ＷＴＲＵ／ゲートウェイは、単一のＰＤＰコンテキストアクティブ化要求メッセージを用いて、１個以上１６個以下のＩＰアドレスを要求することができると言える。

例えば、要求されているＩＰアドレスの数は、スペアビットが、要求されたＩＰアドレスの数を特定するための指数関数を表すことが可能な方法でエンコードできる。例えば、ＷＴＲＵ／ゲートウェイによって要求されているＩＰアドレスの数＝２＾（Spare Bits Value）とすることができる。例えば、「００００」というスペアビット値（例えば、Spare Bits Value=0）は、単一のＩＰアドレスを求める要求を表すことができる。「０００１」というスペアビット値（例えば、Spare Bits Value=1）は、２つのＩＰアドレスを求める要求を表すことができる。「００１０」というスペアビット値（例えば、Spare Bits Value=2）は、４つのＩＰアドレスを求める要求を表すことができる。指数関数を使用することにより、ＷＴＲＵ／ゲートウェイは、単一のＰＤＰコンテキストアクティブ化要求メッセージを用いて、１、２、４、８、．．．３２、７６８個のアドレスを使用できる。

例えば、要求されているＩＰアドレスの数を明示的に示すための新たなフィールドを、ＰＤＰコンテキストアクティブ化要求１４１０内のＩＥに付加できる。例えば、この新たなフィールドがＰＤＰコンテキストアクティブ化要求１４１０内に存在するか否かを示すために、プロトコル構成オプションＩＥのスペアビットを使用できる。１４１２において、ＳＧＳＮ１４０６は、ＣＡＭＥＬ ＧＰＲＳコンテキスト確立手順を実行できる。

ＳＧＳＮ１４０６は、ＰＤＰコンテキスト作成要求１４１４をＧＧＳＮ１４０８へ送信できる。ＳＧＳＮ１４０６は、ＰＤＰコンテキスト作成要求１４１４内に含まれているプロトコル構成オプションＩＥ内に含まれているスペアビットを使用して、要求されているＩＰアドレスの数をＧＧＳＮ１４０８に示すことができる。例えば、ＳＧＳＮ１４０６は、複数のＩＰアドレスを求める要求をＰＤＰコンテキストアクティブ化要求１４１０内に含めるためにＷＴＲＵ／ＭＴＣゲートウェイが使用したのと同様の技術を、複数のＩＰアドレスを求める要求をＰＤＰコンテキスト作成要求１４１４内に含めるために使用できる。例えば、スペアビットを使用して、要求されているＩＰアドレスの数を示すことができ、および／または、要求されているＩＰアドレスの数を示すための新たなフィールドを作成することもできる。

ＧＧＳＮ１４０８は、ＷＴＲＵ／ＭＴＣゲートウェイ１４０２に割り振られる／割り当てられるＩＰアドレスの数をＰＤＰコンテキスト作成応答１４１６内で示すことができる。例えば、ＧＧＳＮ１４０８は、ＰＤＰコンテキスト作成応答１４１６内に含まれているプロトコル構成オプションＩＥ内に含まれているスペアビットを使用して、割り当てられるＩＰアドレスの数をＳＧＳＮ１４０６に示すことができる。例えば、ＧＧＳＮ１４０８は、複数のＩＰアドレスを求める要求をＰＤＰコンテキストアクティブ化要求１４１０内に含めるためにＷＴＲＵ／ＭＴＣゲートウェイが使用したのと同様の技術を、割り振られるＩＰアドレスの数の表示をＰＤＰコンテキスト作成応答１４１４内に含めるために使用することができる。例えば、スペアビットを使用して、割り当てられるＩＰアドレスの数を示すことができ、および／または、割り当てられるＩＰアドレスの数を示すための新たなフィールドを作成することもできる。

１４１８においては、ＷＴＲＵ／ＭＴＣゲートウェイ１４０２、ＲＡＮ１４０４、および／またはＳＧＳＮ１４０６の間において無線アクセスベアラセットアップを実行できる。ＢＳＳトレースがアクティブ化される場合には、ＳＧＳＮ１４０６は、呼び出しトレース１４２０をＲＡＮ１４０４へ送信できる。例えば、既存のＰＤＰコンテキストを更新するために使用可能なＰＤＰコンテキスト更新要求１４２２を、ＩＰアドレスを求める更新された要求を示すために使用できる。ＰＤＰコンテキスト更新応答１４２４は、割り当てられるＩＰアドレスの更新された数を（例えば、更新されたＰＤＰコンテキスト要求に基づいて）示すことができる。そうである場合には、１４２６において、ＳＧＳＮ１４０６は、ＣＡＭＥＬ ＧＰＲＳコンテキスト肯定応答手順を実行できる。

（例えば、ＰＤＰコンテキスト作成応答１４１６および／またはＰＤＰコンテキスト更新応答１４２４内の）割り当てられるＩＰアドレスの数に関する表示を受信すると、ＳＧＳＮ１４０６は、ＰＤＰコンテキストアクティブ化受諾１４２８をＷＴＲＵ／ＭＴＣゲートウェイ１４０２へ送信できる。例えば、ＳＧＳＮ１４０６は、ＷＴＲＵ／ＭＴＣゲートウェイ１４０２に割り振られる／割り当てられるＩＰアドレスの数をＰＤＰコンテキストアクティブ化受諾１４２８内で示すことができる。例えば、ＳＧＳＮ１４０６は、ＰＤＰコンテキストアクティブ化受諾１４２８内に含まれているプロトコル構成オプションＩＥ内に含まれているスペアビットを使用して、割り当てられるＩＰアドレスの数をＷＴＲＵ／ＭＴＣゲートウェイ１４０２に示すことができる。例えば、ＳＧＳＮ１４０６は、複数のＩＰアドレスを求める要求をＰＤＰコンテキストアクティブ化要求１４１０内に含めるためにＷＴＲＵ／ＭＴＣゲートウェイが使用したのと同様の技術を、割り振られるＩＰアドレスの数の表示をＰＤＰコンテキストアクティブ化受諾１４２８内に含めるために使用することができる。例えば、スペアビットを使用して、割り当てられるＩＰアドレスの数を示すことができ、および／または、割り当てられるＩＰアドレスの数を示すための新たなフィールドを作成することもできる。

例えば、複数のＩＰアドレスがＷＴＲＵ／ＭＴＣゲートウェイ１４０２に割り振られる場合には、ＷＴＲＵ／ＭＴＣゲートウェイ１４０２は、連続したＩＰアドレスがＧＧＳＮ１４０８によって割り振られたと想定することができる。例えば、ＷＴＲＵ／ＭＴＣゲートウェイ１４０２は、ＰＤＰコンテキストアクティブ化受諾１４２８内に含まれているＰＤＰアドレス内のアドレス情報フィールドから開始ＩＰアドレスを特定できる。割り振られるＩＰアドレスの数に関する表示および開始ＩＰアドレスに基づいて、ＷＴＲＵ／ＭＴＣゲートウェイ１４０２は、自分に割り当てられたＩＰアドレスのそれぞれを特定することができる。コアネットワークは、割り当てられたＩＰアドレスが、ＰＤＰコンテキストがアクティブ化される時点から使用され始めるものと考えることができる。

例えば、ＧＧＳＮ１４０８は、ＩＰアドレスを不連続な様式でＷＴＲＵ／ＭＴＣゲートウェイ１４０３に割り振ることができる。例えば、割り振られるＩＰアドレスは、ＷＴＲＵ／ＭＴＣゲートウェイ１４０２に個別に割り振ること、および個別に示すことが可能である。ＷＴＲＵ／ＭＴＣゲートウェイ１４０２に割り振られたＩＰアドレスに関する値を明示的に示すための１つまたは複数の新たなフィールドを、ＰＤＰコンテキスト作成応答１４１６、ＰＤＰコンテキスト更新応答１４２４、および／またはＰＤＰコンテキストアクティブ化受諾１４２８に付加することができる。

単一のＰＤＰコンテキストとともに使用するために複数のＩＰアドレスを割り当てるということは、ユーザデータをトランスポートするために使用されるＧＴＰトンネルを管理するＳＧＳＮおよび／またはＧＧＳＮに関する機能における変化を意味する場合がある。例えば、複数のＩＰアドレスが、同じＧＴＰトンネルにマップされる場合がある。

所与のＰＤＰコンテキストがアクティブ化された後に、そのＰＤＰコンテキストに関して、より多くのおよび／またはより少ないＩＰアドレスを要求することをＷＴＲＵ／ＭＴＣゲートウェイが決定した場合には、ＷＴＲＵは、ＰＤＰコンテキスト修正手順を利用できる。例えば、図１５は、既存のアクティブＰＤＰコンテキストに関して、より多くのまたはより少ないＩＰアドレスを要求するためにＷＴＲＵ／ＭＴＣゲートウェイデバイスによって使用することができる例示的なＰＤＰコンテキスト修正手順を示している。例えば、図１５において示されているように、ＷＴＲＵ／ＭＴＣゲートウェイ１５０２（これは、共有コンテキストグループの一部である１つまたは複数の非３ＧＰＰデバイスのためのゲートウェイとして機能する３ＧＰＰ ＷＴＲＵとすることができる）は、ＰＤＰコンテキスト修正要求１５１０をＳＧＳＮ１５０６へ送信できる。ＰＤＰコンテキストアクティブ化要求１５１０は、既存のアクティブＰＤＰコンテキストに関するＩＰアドレスの割り当てをコアネットワークが修正することを求める要求を含むことができる。例えば、ＰＤＰコンテキスト修正要求１５１０内に含まれているプロトコル構成オプションＩＥは、ＷＴＲＵ／ＭＴＣゲートウェイ１５０２が、アクティブＰＤＰコンテキストに関して割り振ることをネットワークに望むＩＰアドレスの数の表示を含むことができる。ＷＴＲＵ／ＭＴＣゲートウェイ１５０２が、アクティブＰＤＰコンテキストに関して割り振ることをネットワークに望むＩＰアドレスの数は、現在割り振られているアドレスの数とは異なる場合がある。例えば、ＷＴＲＵ／ＭＴＣゲートウェイ１５０２は、ＩＰアドレスの所望の数を示すために、プロトコル構成オプションＩＥ内のスペアビットを利用できる。ＷＴＲＵ／ＭＴＣゲートウェイ１５０２に関する例示的なプロトコル構成オプションが、テーブル２において示されている。例えば、図１５のＷＴＲＵ／ＭＴＣゲートウェイ１５０２は、複数のＩＰアドレスを求める要求をＰＤＰコンテキストアクティブ化要求１４１０内に含めるために図１４のＷＴＲＵ／ＭＴＣゲートウェイ１４０２が使用したのと同様の技術を、複数のＩＰアドレスを求める要求をＰＤＰコンテキスト修正要求１５１０内に含めるために使用することができる。例えば、スペアビットを使用して、要求されているＩＰアドレスの数を示すことができ、および／または、要求されているＩＰアドレスの数を示すための新たなフィールドを作成することもできる。

ＳＧＳＮ１５０６は、ＰＤＰコンテキスト更新要求１５１４をＧＧＳＮ１５０８へ送信できる。ＳＧＳＮ１５０６は、ＰＤＰコンテキスト更新要求１５１４内に含まれているプロトコル構成オプションＩＥ内に含まれているスペアビットを使用して、要求されているＩＰアドレスの数をＧＧＳＮ１５０８に示すことができる。例えば、ＳＧＳＮ１５０６は、複数のＩＰアドレスを求める要求をＰＤＰコンテキスト修正要求１５１０内に含めるためにＷＴＲＵ／ＭＴＣゲートウェイ１５０２が使用したのと同様の技術を、複数のＩＰアドレスを求める要求をＰＤＰコンテキスト更新要求１５１４内に含めるために使用できる。例えば、スペアビットを使用して、要求されているＩＰアドレスの数を示すことができ、および／または、要求されているＩＰアドレスの数を示すための新たなフィールドを作成することもできる。

ＧＧＳＮ１５０８は、ＷＴＲＵ／ＭＴＣゲートウェイ１５０２に割り振られる／割り当てられるＩＰアドレスの新たな数をＰＤＰコンテキスト更新応答１５１６内で示すことができる。例えば、ＧＧＳＮ１５０８は、ＰＤＰコンテキスト更新応答１５１６内に含まれているプロトコル構成オプションＩＥ内に含まれているスペアビットを使用して、割り当てられるＩＰアドレスの数をＳＧＳＮ１５０６に示すことができる。例えば、ＧＧＳＮ１５０８は、複数のＩＰアドレスを求める要求をＰＤＰコンテキスト更新要求１５１０内に含めるためにＷＴＲＵ／ＭＴＣゲートウェイ１５０２が使用したのと同様の技術を、割り振られるＩＰアドレスの数の表示をＰＤＰコンテキスト更新応答１５１４内に含めるために使用することができる。例えば、スペアビットを使用して、割り当てられるＩＰアドレスの数を示すことができ、および／または、割り当てられるＩＰアドレスの数を示すための新たなフィールドを作成することもできる。

１５１８においては、ＷＴＲＵ／ＭＴＣゲートウェイ１５０２、ＲＡＮ１５０４、および／またはＳＧＳＮ１５０６の間において無線アクセスベアラセットアップを実行できる。例えば、既存のＰＤＰコンテキストを更新するために使用可能なＰＤＰコンテキスト更新要求１５２２を、ＩＰアドレスを求める更新された要求を示すために使用することもできる。ＰＤＰコンテキスト更新応答１５２４は、（例えば、更新されたＰＤＰコンテキスト要求に基づいて）割り当てられるＩＰアドレスの更新された数を示すことができる。

（例えば、ＰＤＰコンテキスト更新応答１５１６および／またはＰＤＰコンテキスト更新応答１５２４内の）割り当てられるＩＰアドレスの数に関する表示を受信すると、ＳＧＳＮ１５０６は、ＰＤＰコンテキスト修正受諾１５２８をＷＴＲＵ／ＭＴＣゲートウェイ１５０２へ送信できる。例えば、ＳＧＳＮ１５０６は、ＷＴＲＵ／ＭＴＣゲートウェイ１５０２に割り振られる／割り当てられるＩＰアドレスの数をＰＤＰコンテキスト更新受諾１５２８内で示すことができる。例えば、ＳＧＳＮ１５０６は、ＰＤＰコンテキスト更新受諾１５２８内に含まれているプロトコル構成オプションＩＥ内に含まれているスペアビットを使用して、割り当てられるＩＰアドレスの数をＷＴＲＵ／ＭＴＣゲートウェイ１５０２に示すことができる。例えば、ＳＧＳＮ１５０６は、複数のＩＰアドレスを求める要求をＰＤＰコンテキスト更新要求１５１０内に含めるためにＷＴＲＵ／ＭＴＣゲートウェイ１５０２が使用したのと同様の技術を、割り振られるＩＰアドレスの数の表示をＰＤＰコンテキスト更新受諾１５２８内に含めるために使用できる。例えば、スペアビットを使用して、割り当てられるＩＰアドレスの数を示すことができ、および／または、割り当てられるＩＰアドレスの数を示すための新たなフィールドを作成することもできる。

例えば、複数のＩＰアドレスがＷＴＲＵ／ＭＴＣゲートウェイ１５０２に割り振られた場合には、ＷＴＲＵ／ＭＴＣゲートウェイ１５０２は、連続したＩＰアドレスがＧＧＳＮ１５０８によって割り振られたと想定することができる。例えば、ＷＴＲＵ／ＭＴＣゲートウェイ１５０２は、オリジナルのＰＤＰコンテキストアクティブ化受諾メッセージ内に含まれているＰＤＰアドレス内のアドレス情報フィールドから開始ＩＰアドレスを特定できる。また、さらなるＩＰアドレスがＷＴＲＵ／ＭＴＣゲートウェイに割り振られた場合には、ＷＴＲＵ／ＭＴＣゲートウェイは、それらのさらなるＩＰアドレスが、前回の割り当てに関連付けられている最後のＩＰアドレスの後に開始することを決定することができる。例えば、割り振られるＩＰアドレスの数に関する表示および開始ＩＰアドレスに基づいて、ＷＴＲＵ／ＭＴＣゲートウェイ１５０２は、自分に割り当てられたＩＰアドレスのうちのそれぞれを特定することができる。

例えば、ＧＧＳＮ１５０８は、ＩＰアドレスを不連続な様式でＷＴＲＵ／ＭＴＣゲートウェイ１５０２に割り振ることができる。例えば、割り振られるＩＰアドレスのうちの１つまたは複数は、ＷＴＲＵ／ＭＴＣゲートウェイ１５０２に個別に割り振ること、および／または個別に示すことが可能である。ＷＴＲＵ／ＭＴＣゲートウェイ１５０２に割り振られたＩＰアドレスに関する値を明示的に示すための１つまたは複数の新たなフィールドを、ＰＤＰコンテキスト更新応答１５１６、ＰＤＰコンテキスト更新応答１５２４、および／またはＰＤＰコンテキスト更新受諾１５２８に付加することができる。

例えば、ＷＴＲＵ／ＭＴＣゲートウェイ１５０２は、特定のＩＰアドレスが自分に割り当てられることを要求するために、ＰＤＰコンテキスト修正要求１５１０を使用することができる。例えば、ＷＴＲＵ／ＭＴＣゲートウェイ１５０２が要求しようと決めているＩＰアドレスを、ＰＤＰコンテキスト修正要求１５１０の新たなフィールド内で明示的に示すことができる。１つまたは複数の特定のＩＰアドレスを求める要求を含む新たなフィールドが存在するか否かを示すために、プロトコル構成オプションＩＥのスペアビットを使用することができる。同様に、要求されている（１つ若しくは複数の）ＩＰアドレスおよび／または割り当てられるＩＰアドレスの値を明示的に示すために、ＰＤＰコンテキスト更新要求１５１４、ＰＤＰコンテキスト更新応答１５１８、ＰＤＰコンテキスト更新要求１５２２、ＰＤＰコンテキスト更新応答１５２４、および／またはＰＤＰコンテキスト修正受諾１５２８のうちの１つまたは複数を更新することができる。

例えば、ＷＴＲＵ／ＭＴＣゲートウェイ１５０２は、１つまたは複数の特定のＩＰアドレスがＷＴＲＵ／ＭＴＣゲートウェイ１５０２によってもはや要求されていないことをネットワークに示すために、ＰＤＰコンテキスト修正要求１５１０を使用できる。例えば、ＷＴＲＵ／ＭＴＣゲートウェイ１５０２が解放したいと望むＩＰアドレスを、ＰＤＰコンテキスト修正要求１５１０内の１つまたは複数の新たなフィールド内で明示的に示すことができる。解放されることになるＩＰアドレスを明示的に示す１つまたは複数の新たなフィールドが存在するかどうかを示すために、プロトコル構成オプションＩＥのスペアビットを使用できる。ＷＴＲＵ／ＭＴＣゲートウェイ１５０２から解放されることになるＩＰアドレスの値を明示的に示すために、ＰＤＰコンテキスト更新要求１５１４、ＰＤＰコンテキスト更新応答１５１８、ＰＤＰコンテキスト更新要求１５２２、ＰＤＰコンテキスト更新応答１５２４、および／またはＰＤＰコンテキスト修正受諾１５２８を更新できる。

単一のＰＤＰコンテキストに対して複数のＩＰアドレスを割り当てることに関して説明したこれらの技術を利用することによって、ＭＴＣゲートウェイとコアネットワークとの間において生み出されるシグナリングオーバーヘッドの量を低減できる。低減されたオーバーヘッドは、多数のデバイスがＭＴＣゲートウェイの後ろから実質的に同時に接続している場合に特に明らかになると言える。例えば、１つのＰＤＰコンテキストを共有しながらそれでもなお非３ＧＰＰデバイスに個別のＩＰアドレスを割り当てることを可能にすることによって、ＭＴＣゲートウェイを使用して３ＧＰＰネットワークを介してＭＴＣサーバに接続する非３ＧＰＰデバイスに対するモニタリングおよび／または課金をコアネットワークが行うための便利な方法を提供できる。個別のＩＰアドレスを割り当てられている非３ＧＰＰデバイス同士の間においてＰＤＰコンテキストを共有することは、一意のＩＰアドレスをキャピラリーネットワークデバイスに割り当てること、ひいては、外部識別子とトランスポートアドレスとの間におけるマッピングを簡略化することを可能にする。

上記では特徴および要素について特定の組合せで説明しているが、それぞれの特徴または要素は、単独で、または他の特徴および要素との任意の組合せで使用できるということを当業者なら理解するであろう。また、本明細書に記載されている方法は、コンピュータまたはプロセッサによって実行するためにコンピュータ可読媒体内に組み込まれているコンピュータプログラム、ソフトウェア、またはファームウェアで実装できる。コンピュータ可読媒体の例としては、（有線接続または無線接続を介して伝送される）電子信号、およびコンピュータ可読記憶媒体が含まれる。コンピュータ可読記憶媒体の例としては、ＲＯＭ、ＲＡＭ、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよび取り外し可能ディスクなどの磁気媒体、光磁気媒体、並びに、ＣＤ−ＲＯＭディスクおよびＤＶＤなどの光学媒体が含まれるが、それらには限定されない。ソフトウェアと関連付けられているプロセッサは、ＷＴＲＵ、ＵＥ、端末、基地局、ＲＮＣ、または任意のホストコンピュータにおいて使用するための無線周波数トランシーバを実装するために使用することができる。

Claims (14)

1. 複数のデバイスの間でパケットデータプロトコル（ＰＤＰ）コンテキストを共有する方法であって、
   前記方法は、
   無線送受信ユニット（ＷＴＲＵ）が前記ＰＤＰコンテキストを確立する第１の要求を送信することと、
   前記ＷＴＲＵが前記ＰＤＰコンテキストを修正する第２の要求を送信することであって、前記ＰＤＰコンテキストを確立する前記第１の要求または前記ＰＤＰコンテキストを修正する前記第２の要求は、前記ＷＴＲＵが共有コンテキストグループのメンバーであるという表示を備えるアタッチ要求である、ことと、
   前記ＷＴＲＵが前記ＰＤＰコンテキストを確立または修正する前記要求が受け入れられたことを示す応答を受信することと、
   前記ＷＴＲＵが前記共有コンテキストグループ内の少なくとも１つの他のデバイスのためにゲートウェイとして機能することであって、前記少なくとも１つの他のデバイスは、前記ＰＤＰコンテキストを前記ＷＴＲＵと共有する、ことと
   を備える方法。
2. 前記ＷＴＲＵが共有コンテキストグループのメンバーであるという前記表示は、グループＩＭＳＩ（international mobile subscriber identity）またはグループ識別（ＩＤ）である、請求項１の方法。
3. 前記ＷＴＲＵが１つまたは複数のコアネットワークノードとの間で認証を行うことをさらに備え、前記ＷＴＲＵは、前記１つまたは複数のコアネットワークノードとの間で認証を行うときに、前記共有コンテキストグループのメンバーである少なくとも１つの他のデバイスを認証する、請求項１の方法。
4. 前記ＷＴＲＵは、前記共有コンテキストグループのメンバーである複数の他のデバイスの認証応答に基づいて認証応答を判定する、請求項３の方法。
5. 前記ＰＤＰコンテキストを修正する前記第２の要求は、共通のＰＤＰコンテキストを共有している前記共有コンテキストグループのメンバーである複数のデバイスに複数のＩＰ（internet protocol）アドレスが割り当てられるよう求める要求を含む、請求項１の方法。
6. 前記ＷＴＲＵが共有コンテキストグループのメンバーであるという前記表示は、ＥＰＳ（evolved packet service）アタッチタイプ情報要素内に含まれる、請求項１の方法。
7. 前記共有コンテキストグループ内の前記少なくとも１つの他のデバイスは、非３ＧＰＰ（non-third generation partnership project）デバイスである、請求項１の方法。
8. パケットデータプロトコル（ＰＤＰ）コンテキストを確立する第１の要求を送信し、
   前記ＰＤＰコンテキストを修正する第２の要求を送信し、前記ＰＤＰコンテキストを確立する前記第１の要求または前記ＰＤＰコンテキストを修正する前記第２の要求は、ＷＴＲＵが共有コンテキストグループのメンバーであるという表示を含むアタッチ要求であり、
   前記ＰＤＰコンテキストを確立または修正する前記要求が受け入れられたことを示す応答を受信し、
   前記共有コンテキストグループ内の少なくとも１つの他のデバイスのためにゲートウェイとして機能し、前記少なくとも１つの他のデバイスは、前記ＷＴＲＵとの間で前記ＰＤＰコンテキストを共有する、
   ように構成されたプロセッサを備えた無線送受信ユニット（ＷＴＲＵ）。
9. 前記ＰＤＰコンテキストを修正する前記第２の要求は、共通のＰＤＰコンテキストを共有している前記共有コンテキストグループのメンバーである複数のデバイスに複数のＩＰ（internet protocol）アドレスが割り当てられるよう求める要求を含む、請求項８のＷＴＲＵ。
10. 前記表示は、グループＩＭＳＩ（international mobile subscriber identity）またはグループ識別子（ＩＤ）を備える、請求項８のＷＴＲＵ。
11. 前記プロセッサは、少なくとも１つのコアネットワークノードとの間で認証を実行するようにさらに構成されており、かつ前記共有コンテキストグループ内のデバイスのための認証のシーケンスが存在する、請求項１０のＷＴＲＵ。
12. 前記プロセッサは、前記共有コンテキストグループ内のデバイスのための認証の前記シーケンスを動的に判定するようにさらに構成される、請求項１１のＷＴＲＵ。
13. 前記ＰＤＰコンテキストを修正する前記第２の要求が受け入れられたことを示す前記応答は、割り当てられているＩＰアドレスの数、および開始ＩＰアドレスを示す、請求項８のＷＴＲＵ。
14. 前記ＰＤＰコンテキストを修正する前記第２の要求が受け入れられたことを示す前記応答は、前記少なくとも１つの他のデバイスに割り当てられるインターネットプロトコルアドレスを明示的に示す、請求項８のＷＴＲＵ。

Images