P-GW は、Cisco ASR 5500 および仮想化プラットフォームで実行される StarOS アプリケーションです。プラットフォームの詳細については、該当する『System Administration Guide』[英語] を参照するか、シスコのアカウント担当者にお問い合わせください。

P-GW は、シスコのライセンス製品です。別のセッションおよび機能ライセンスが必要になる場合があります。特定のライセンス要件の詳細については、シスコのアカウント担当者にお問い合わせください。ライセンスのインストールと確認の詳細については、『システム管理ガイド』の「ソフトウェア管理操作」の「ライセンスキーの管理」の項を参照してください。

次の図は、P-GW でサポートされる特定のネットワーク インターフェイスを示しています。各インターフェイスの詳細については、サポートされる論理ネットワーク インターフェイス（参照ポイント）を参照してください。

次の図は、P-GW のネットワーク展開の例を示しています。これには、他の 3GPP Evolved-UTRAN/Evolved Packet Core ネットワークデバイスとのすべてのインターフェイス接続が含まれています。

次の図は、eHRPD ネットワーク内の P-GW でサポートされる特定のネットワーク インターフェイスを示しています。各インターフェイスの詳細については、サポートされる論理ネットワーク インターフェイス（参照ポイント）を参照してください。

次の図は、eHRPD ネットワーク内の P-GW のネットワーク展開の例を示しています。これには、他の 3GPP Evolved-UTRAN/Evolved Packet Core ネットワークデバイスとのすべてのインターフェイス接続が含まれています。

この 3GPP R9 拡張機能は、Gx を介した累積使用量追跡とも呼ばれ、P-GW と PCRF 間の使用量クォータに基づいて、TS 29.212 で定義されている通信量と課金の制御機能のサブセットを提供します。クォータは、デフォルトのベアラーまたは PDN 接続の任意の専用ベアラーに割り当てることができます。

この機能により、Gx を介した通信量レポートが可能になります。これにより、IP-CAN セッションまたはサービスデータフローベースでのネットワークリソースの累積使用量の監視とレポートが提供されます。PCRF は、PCEF に必要な情報を提供することにより、セッションレベルまたはフローレベルでの使用量モニタリングに登録します。PCEF は、条件が満たされると、PCRF に使用量をレポートします。リアルタイムの合計ネットワーク使用量に基づいて、PCRF は動的なポリシー決定を行うための情報を入手します。

累積通信量レポートは、PCRF の要求に応じて、合計通信量、アップリンク通信量、またはダウンリンク通信量で測定できます。報告された使用量を PCEF から受信すると、PCRF は、該当する IP-CAN セッション、使用量モニタリングキー、または該当する場合はその両方に対して、許容される合計使用量から使用量レポートの値を差し引きます。

E-RAB またはデータセッションがドロップされたとき、通信事業者は場合により、詳細な RAN および/または NAS リリース原因コード情報と、アクセスネットワークからの ULI 情報を取得して、P-GW および S-GW CDR に追加する必要があります。これらの情報は、コールパフォーマンス分析、ユーザー QoE 分析、適切な請求調整に必要となります。通信事業者は、IMS セッションの P-CSCF で前記情報の取得が必要になる場合もあります。

S1 経由の E-RAB リリースコマンドおよび E-RAB リリース通知メッセージでは、「Per E-RAB Cause」を受信していました。ただし、RAN および NAS の原因は P-GW および S-GW に転送されず、P-GW によって PCRF に通知されてはいませんでした。

AS および/または NAS の原因を示す「RAN/NAS リリース原因」情報要素（IE）がセッション削除要求およびベアラー削除コマンドに追加されました。MME によって提供される「RAN/NAS リリース原因」は、S-GW によって P-GW に透過的に送信されます（P-GW へのシグナリングがある場合）。これにより、PCRF へとさらに伝達されます。

後方互換性のために、S-GW は引き続き、S4/S11 メッセージ内の CC IE から原因コードを受信します。また、一部のお客様のプライベート拡張機能からの原因コードも引き続き受信します。

企業または MVNO のお客様向けに VPN サービスのプロビジョニングを可能にする付加価値機能です。法人のお客様が、それぞれ固有の設定可能なパラメータとカスタムディクショナリを使用して、独自の AAA サーバーを維持できます。

この機能は最大 800 の AAA サーバーグループと 800 の NAS IP アドレスを単一のコンテキスト内またはシャーシ全体でプロビジョニングできるようサポートします。1 つのサーバーグループには合計 128 台のサーバーを割り当てることができます。シャーシあたり最大 1,600 のアカウンティングサーバー、認証サーバー、仲介サーバーがサポートされます。

重要	AAA アプリケーションは間接的に接続されたホストをサポートしないため、直接的に接続されたホストのみを設定します。

ANSI T1.276 は、ネットワーク要素（NE）のセキュリティ対策を規定しています。特に、パスワードの強度、保管、およびメンテナンスのセキュリティ対策に関するガイドラインを規定しています。

これらの対策は、ASR 5500 と要素管理システムに適用できます（両方ともパスワード認証を必要とするため）。これらのガイドラインのサブセットが各プラットフォームに適用可能である場合、それらが実装されます。どちらの製品にも適用されないガイドラインの既知のサブセットがあります（証明書認証など）。さらに、プラットフォームは、外部要素に依存するさまざまな認証方法（RADIUS や SSH など）をサポートしています。そのような場合の ANSI T1.276 準拠は、外部要素の領域になります。ANSI T1.276 ガイドラインは、ローカルで設定された通信事業者についてのみ導入されます。

StarOS v12.x 以前では、最大 1024 の APN を P-GW で設定できます。StarOS v14.0 以降では、最大 2048 の APN を P-GW で設定できます。APN は、任意のタイプの PDP コンテキスト（つまり、PPP、IPv4、IPv6、または IPv4 と IPv6 の両方）に設定できます。APN ごとに多数のパラメータを個別に設定できます。

APN が P-GW によって決定された後、サブスクライバは AAA サーバーで認証/承認されます。P-GW により、AAA サーバーは、APN 設定の一部またはすべてをオーバーライドする VSA（ベンダー固有属性）を返すことができます。そのため、さまざまなサブスクライバ階層のプロファイルを AAA サーバーで設定し、サブスクライバの認証/承認中に P-GW に渡すことができます。

重要	APN 設定の詳細については、このガイドの「PDN ゲートウェイの設定」の章を参照してください。

現在の実装では、PCEF は、Diameter ベースの Gy インターフェイスを使用して OCS と対話し、各サブスクライバのデータセッション用のクォータを取得します。PCEF は、設定された量のクォータが使用された後、または設定された量の時間が経過した後に、OCS を再試行できるようになりました。クォータ値は DCCA サービス設定の一部になり、この DCCA サービスを使用するすべてのサブスクライバに適用されます。一時クォータはボリューム（MB）や時間（分）で指定され、両方のクォータ追跡メカニズムを個別にまたは同時に適用できます。

障害処理シナリオで使用するために設定された暫定合計クォータまたは時間をユーザーが消費すると、PCEF は OCS サーバーを再試行して、機能が復旧されたかどうかを判断します。サービスが復旧された場合、クォータの割り当てと追跡は、標準の使用状況レポート手順に従って続行されます。障害中に使用されたデータが OCS に報告されます。OCS サービスが復旧されていない場合、PCEF は、ユーザーに割り当てられた設定済みの量のクォータと時間を再割り当てする必要があります。OCS がオンラインに戻ると、PCEF は集積されたすべての使用済みデータを OCS に報告する必要があります。複数の再試行と暫定的な割り当てが発生した場合、PCEF はすべての割り当て期間中に使用されたクォータを報告します。

Gy インターフェイスを使用できない場合、P-GW は「ポジティブ想定」モードを開始します。各サブスクライバタイプに固有の処理が施されます。各機能アプリケーションには、Gx インターフェイスの PCRF からのコマンドレベルの AVP に基づいて、一意の一時クォータボリュームの量と期間が割り当てられます。さらに、PCRF によって Gx インターフェイスで送信されるコマンドレベルの AVP によって識別されるサブスクライバグループに対して、ポジティブ想定機能を無効にする設定が可能なオプションが追加されました。

egtpinmgr の再起動中の停止時間を最適化するため、egtpinmgr の非同期コア転送のサポートが追加されました。

これまでは、egtpinmgr が再起動すると、まずコアダンプファイルの作成および転送を完了させ、それからリカバリプロセスを開始していました。しかし、コアファイルの転送にはかなりの時間がかかります。egtpinmgr の再起動時の停止時間は、egtpinmgr のリカバリ時間とコアファイル転送時間とを合算した時間でした。

非同期コア転送がサポートされるようになったことで、リカバリプロセスに egtpinmgr が含まれるようになります。今後は、egtpinmgr プロセスがクラッシュすると、カーネルによるコアダンプファイルの転送とリソースの解放を待たずにリカバリが開始されます。その結果、egtpinmgr の再起動時の停止時間は、egtpinmgr のリカバリ時間のみに等しくなります。

この機能拡張により、egtpinmgr の再起動時の停止時間が短縮されます。停止時間は、egtpinmgr の回復に必要な時間のみとなり、コアファイルの作成と転送にかかる時間による影響を受けなくなります。

Gx インターフェイス

S2a インターフェイスでは、P-GW は、CREATE SESSION REQUEST メッセージの TWAN-IDENTIFIER 属性で Wi-Fi アクセスポイントのアイデンティティを受信します。この情報は、AP MAC アドレス、SSID、および CIVIC アドレスで構成されます（AP グループ名などの情報が含まれる場合もある）。

ロケーショントラッキングおよびロケーションベースのポリシーを目的として、上記の情報をポリシーサーバー（Gx）、クォータサーバー（Gy）、課金ゲートウェイ（Gz）、および LI サーバーに伝達する必要があります。この新しい機能によって P-GW が強化され、S2a インターフェイスで受信されるたびに、これらのすべてのインターフェイスに AP SSID、BSSID、およびシビックアドレスが伝播されます。

Gx インターフェイスでは、この情報は、CCR-I/CCR-U および CCR-T メッセージの TWAN IDENTIFIER 属性で PCRF に送信されます。これには標準 Gx ディクショナリ設定で十分です。

Gy インターフェイスでは、dcca_custom33 ディクショナリがこのインターフェイスに設定されている場合は常に、この情報が、CCR-I/CCR-U および CCR-T メッセージの、「Civic-Addr」という名前のシスコのベンダー固有属性でクォータサーバーに送信されます。

Gz インターフェイスでは、custom53 ディクショナリがこのインターフェイスに設定されている場合は常に、この情報が、CDR（課金データレコード）の TWANUserLocationInformation 属性で課金ゲートウェイに送信されます。

LI インターフェイスでは、この情報は、IRI イベントの「twan_identifier」フィールドで LI サーバーに送信されます。これには特定のディクショナリの変更は必要ありません。

重要	PGW は、信頼できる WLAN ネットワークから（SaMOG を介して）s2a インターフェイスでこの SSID/BSSID/シビックアドレス情報を受信します。Cisco SaMOG が使用されている場合は、この情報を SaMOG から PGW に送信する機能を、設定によって制御できます（これについては、SaMOG の機能を参照）。この機能により、ベースライン AAAmgr メモリ使用率が 3 ～ 4% 増加します。

主要な KPI 統計のバックアップとリカバリ機能が導入される前は、統計はバックアップされず、SessMgr タスクの再起動後に統計を回復できませんでした。この制限により、GGSN、P-GW、SAEGW、および S-GW ではタスクの再起動が発生するたびに統計が失われるため、KPI のモニタリングが問題でした。

KPI の計算では、2 つの時間間隔のカウンタ値間の差分を取得し、その時間間隔で特定の手順が正常に処理された割合を決定します。SessMgr がクラッシュしてから回復すると、GGSN、P-GW、SAEGW、および S-GW はカウンタ値を失い、ゼロにリセットされます。そのため、次の間隔で KPI を計算すると、その間隔については負の値になります。その結果、KPI 値を使用してプロットされたグラフが表示されなくなり、運用チームがネットワークパフォーマンスの一貫したビューを取得して、本当に問題があるかどうかを判断することが困難になります。

この機能により、SessMgr の再起動が発生した場合でも信頼性の高い KPI 計算を実行できます。

重要	主要な KPI 統計のバックアップとリカバリに関する詳細は、このガイドの「主要な KPI 統計のバックアップとリカバリ」の章を参照してください。

この機能により、より一貫性のある動作が実現され、ベアラーに正しい帯域幅が確実に割り当てられます。

さまざまなインターフェイスによって提供されるビットレートの細分性は、3GPP 仕様では調整されていませんでした。たとえば、PCRF は Gx でビット/秒を使用し、GTP はキロビット/秒を使用していました。bps から kbps への変換が原因で、丸め処理のために MBR/GBR 値の割り当てが正しくなくなる場合がありました。

この機能により、bps（Gx から受信）から kbps への変換が小数点以下の値になる場合、GTP インターフェイスで送信されるビットレート値が切り上げられます。ただし、ビットレート値（AMBR、MBR、GBR）の適用は同じであるままになります。アクセス側に送信される値（kbps 単位）がある場合、切り上げる必要があります。

この機能（ビットレートを kpbs で切り上げる）は、デフォルトで有効になっています。ただし、P-GW サービスでの CLI コマンド [ no ] egtp bitrates-rounded-down-kbps は、切り上げの動作を制御します。この CLI コマンドは、以前の切り捨ての動作を有効または無効にします。デフォルトでは、この CLI コマンドは、切り上げられたビットレート値を使用するように設定されています。CLI の設定に応じて、切り上げ（Ceil）ビットレート値または切り捨てビットレート値が GTP インターフェイスでアクセス側に送信されます。この CLI コマンド が有効になっている場合は、以前の動作になります。また、show subscribers pgw-only full all では、APN-AMBR が bps 単位で表示されます。以前は、 show subscribers pgw-only full all は、kpbs 単位で表示するために使用されていました。

CR（C4-132189）は、P-GW による GTP 変換のために TS 29.274 で定義されています。

システムがバルク統計をサポートしているため、オペレータは自身にとって重要な統計を表示するだけでなく、その統計の表示形式を設定することもできます。これにより、外部のバックエンドプロセッサで解析できるように統計データをフォーマットすることが可能になるため、統計データの後処理が簡素化されます。

要素管理システム（EMS）とともに使用すると、データを解析、アーカイブ、グラフ化できます。

システムは、最大 4 セット（プライマリ/セカンダリ）のレシーバーの設定をサポートします。各セットは、さまざまなスキーマから特定の統計セットを収集するように設定できます。統計は、システムから手動で取得することも、設定された間隔で送信することも可能です。バルク統計はレシーバにファイルで保存されます。

バルク統計データファイルの形式はユーザーが設定できます。ユーザーは、ファイル名、ファイルヘッダー、フッターの形式を指定して、日付、システムホスト名、システム稼働時間、統計を生成するシステムの IP アドレス（ヘッダーとフッターでのみ使用可能）、ファイルが生成された時刻などの情報を含めることができます。

EMS がレシーバとして使用されている場合、EMS では XML 解析、アーカイブ、グラフ化によって統計データをさらに処理できます。

EMS のバルク統計サーバーのコンポーネントは、収集された統計を解析し、その情報を PostgreSQL データベースに保存します。XML ファイルを生成して転送する必要がある場合は、この要素が XML 出力を生成し、さらなる処理のためにノースバウンド NMS か代替のバルク統計サーバーに送信できます。

さらに、収集された統計をアーカイブする必要がある場合は、バルク統計サーバーにより、サーバー上の代替ディレクトリにファイルを書き込むことができます。管理ユーザーが専用のディレクトリを設定することも、デフォルトディレクトリを使用することもできます。いずれの場合も、ディレクトリは、ローカルファイルシステム上、または EMS サーバーの NFS マウントファイルシステム上に配置できます。

重要	バルク統計の設定の詳細については、『システム アドミニストレーション ガイド』の「バルク統計の設定と維持」の章を参照してください。

輻輳制御機能により、ポリシーとしきい値を設定して、高負荷状態に直面した場合のシステムの対応方法を指定できます。

輻輳制御は、システムに高い負荷がかかっている場合にパフォーマンスを低下させる可能性のある条件についてシステムをモニターします。通常、これらの条件は一時的なものであり（CPU 使用率やメモリ使用率が高い場合など）、すぐに解決されます。ただし、こうした条件が特定の時間間隔で継続している場合や、いくつも発生した場合、システムがサブスクライバセッションにサービスを提供する能力に影響を与える可能性があります。輻輳制御は、このような条件を特定し、状況に対応するためのポリシーを呼び出すのに役に立ちます。

輻輳制御の動作は、次の設定に基づいています。

重要	輻輳制御の詳細については、『システム アドミニストレーション ガイド』の「軋轢制御」の章を参照してください。

コミットされた帯域幅リソース、ジッター、および遅延の要件に従って、さまざまなサービスやアプリケーションクラスの確定的なエンドツーエンド転送とスケジューリング処理を可能にすることで、Quality of User Experience（QoE）の向上に貢献するための基盤を提供します。その結果、各アプリケーションが、ユーザーが期待するサービス処理を受け取ります。

StarOS 9.0 リリース以降、Cisco EPC コアプラットフォームは、1 つ以上の EPS ベアラー（デフォルトと専用）をサポートします。EPS ベアラーは、GTP ベースの S5/S8 インターフェイスの場合は UE と P-GW の間で、PMIP ベースの S2a インターフェイスの場合は UE と HSGW（HRPD Serving Gateway ）の間で実行される 1 つ以上のサービスデータフロー（SDF）の論理的な集約です。GTP が S5/S8 プロトコルとして使用されるネットワークでは、EPS ベアラーは、P-GW にアンカーされた無線ベアラー、S1-U ベアラー、および S5/S8 ベアラーの組み合わせで構成されます。PMIPv6 が使用される場合、EPS ベアラーは、HSGW と P-GW 間の IP 接続を使用して、UE と HSGW の間で連結されます。

重要	P-GW は GTP ベースの S5/S8 および PMIPv6 S2a 機能をサポートしますが、PMIPv6 S5/S8 の商用サポートはありません。

EPS ベアラーは、GTP ベースの S5/S8 設計では UE と P-GW の間で、PMIPv6 S2a アプローチでは UE と HSGW の間で、共通の QoS 処理を受信するトラフィックフローを一意に識別します。サービスデータフロー間で異なる QoS スケジューリングの優先順位が必要な場合は、別々の EPS ベアラーに割り当てる必要があります。パケットフィルタは NAS 手順でシグナリングされ、PDN 接続ごとに一意のパケットフィルタ ID に関連付けられます。

1 つの EPS ベアラーは、UE が PDN に接続するときに確立され、PDN 接続のライフタイム全体にわたって確立されたままになり、その PDN への常時接続の IP 接続が UE に提供されます。このベアラーは、デフォルトベアラーと呼ばれます。PDN 接続は、モバイルアクセス端末と、IMS ネットワーク、ウォールド ガーデン アプリケーション クラウド、バックエンド企業ネットワークなどの外部パケットデータネットワーク（PDN）との間のトラフィックフロー集約を表します。同じ PDN に対して確立された追加の EPS ベアラーは、専用ベアラーと呼ばれます。EPS ベアラーのトラフィック フロー テンプレート（TFT）は、特定の EPS ベアラーに関連付けられたすべての 5 タプルパケットフィルタのセットです。EPC コア要素により、確立された EPS ベアラーごとに個別のベアラー ID が割り当てられます。ある時点で、UE は 1 つ以上の P-GW 上にある複数の PDN 接続を持つことができます。

P-GW は、次の標準規格で定義されているように、Dynamic Host Control Protocol（DHCP）を使用した、サブスクライバ IP PDN コンテキストへのダイナミック IP アドレス割り当てをサポートします。

IP アドレスを PDN コンテキストに割り当てる方法は、APN ごとに設定されます。各 APN テンプレートは、スタティックアドレスとダイナミックアドレスのどちらをサポートするかを決定します。サブスクライバ PDN コンテキストに動的に割り当てられる IP アドレスは、DHCP を使用して割り当てることができます。

P-GW は、UE に対して DHCP サーバーとして、外部 DHCP サーバーに対して DHCP クライアントとして機能します。P-GW の DHCP サーバー機能と DHCP クライアント機能は互いに完全に独立しています。一方は他方なしで存在できます。

DHCP は、IPv4 アドレスと IPv6 アドレスの両方をサポートします。

P-GW は DHCP リレーをサポートしていません。

遅延 IPv4 アドレス割り当て

初期アクセスシグナリング時に IP アドレスを取得するのとは別に、UE は、デフォルトベアラー確立後の DHCP を介した IP アドレスおよび関連設定の取得を選択することを PCO オプションを使用して示すことができます。これは遅延アドレス割り当てとも呼ばれます。

IPv4 アドレスは、ますます枯渇しつつあるリソースとなっています。LTE などの 4G ネットワークは常にオンになっているため、ECM-IDLE 状態の UE によって IPv4 アドレスなどの不足するリソースを独占することはできませんし、独占すべきでもありません。

PDN タイプ IPv4v6 では、デュアルスタックの導入が可能です。デフォルトでは、P-GW は IPv4v6 PDN タイプにのみ IPv6 アドレスを割り当てます。UE は、必要に応じて IPv4 アドレスの割り当てを遅延させ、割り当てられた IPv4 アドレスをグローバルプールに放出します。P-GW は、IPv4 アドレスをオンデマンドで提供するときに、任意の IPv4 アドレス方式（ローカルプールまたは外部 DHCP サーバー）を採用できます。

P-GW は UE の IPv4 アドレスを取得している間、独立した DHCP サーバーやクライアントとして同時に機能します。UE に対しては DHCP サーバーとして機能し、外部 DHCP サーバーに対しては DHCP クライアントとして機能します。以前のリリースでは、P-GW を介した UE と外部 DHCP サーバー間で特定の DHCP オプションを交換できるようになりました。これには、IP-Addralloc プロキシモードで遅延アドレスの割り当てが設定された場合に、特定の外部 DHCP サーバーが提供するオプション（1、3、6、28、43）を IPv4 アドレスとともに UE にリレーするためのサポートが含まれています。

この機能により、DHCP サーバーから DHCP OFFER メッセージで受信するオプション 26 のサポートが追加されます。

P-GW では、UE と外部 DHCP サーバー間で交換される DHCP オプション 26 が保持されています。P-GW はこのオプションをリレーして、UE と外部 DHCP サーバー間の今後のメッセージ交換に対応します。P-GW の外部 DHCP サーバーコンポーネントは、外部 DHCP サーバーが提供する DHCP オプションを予約して保持するため、UE が DHCP リースを更新または再バインドしたときに、P-GW は保存されている値で応答できます。

この機能により、更新要求に関する動作が変更されます。以前は、ASR5500 が DHCP プロキシモードで設定され、DHCP サーバーが更新要求に応答しなかった場合、時間 T2（.85 * リース時間）での再送信には、設定された両方の DHCP サーバーが含まれませんでした。RENEW 状態で一定回数の再試行後に、DHCP リースが期限切れになりました。

この機能で再送信回数が 2 に設定されているとすると、RENEW 状態で DHCP 要求メッセージに対して最大 2 回の再試行が実行されます。DHCP サーバーから応答が受信されず、REBIND 状態に変わった場合、DHCP 要求メッセージも 2 回再試行されます。

以前の動作：以前は、「再送信回数」の値が小さい場合（たとえば 2 以下）、DHCP 要求メッセージは REBIND 状態で再試行されませんでした。

新しい動作：DHCP 要求メッセージは、RENEW 状態と REBIND 状態の両方で設定されている回数だけ再試行されるようになりました。

IPv6 の Dynamic Host Configuration Protocol（DHCP）では、IPv6 ネットワークアドレスなどの設定パラメータを DHCP サーバーから IPv6 ノードに渡すことができます。これにより、再利用可能なネットワークアドレスの割り当て機能や追加機能が自動的に提供されます。

DHCPv6 サポートは、アドレス割り当てを提供するだけでなく、ネットワーク層の IP パラメータの要件も満たします。これらの標準的な使用モードとは別に、DHCPv6 のプレフィックス委任（DHCP-PD）も「UE 背後のネットワーク」シナリオのために 3GPP（Rel 10）で標準化されています。

P-GW は、IPv4 アドレスを管理するのと同様にして IPv6 プレフィックスのライフサイクルを管理します。したがって、セッションのライフタイム中でのこれらのプレフィックスの割り当て、更新、およびリリースは P-GW が行います。IPv6 プレフィックスは主に P-GW に接続された UE のセッションで使用され、委任されたプレフィックスは UE の背後にあるネットワークとデバイスで使用されます。IPv6 プレフィックスの場合、対応する設定に基づいて、ローカルプール、AAA（RADIUS/DIAMETER）サーバー、または外部 DHCPv6 サーバーのいずれかから P-GW が取得されます。委任 IPv6 プレフィックス割り当ての場合では、P-GW が設定に基づいて外部 DHCPv6 サーバーからこれを取得しました。

ユニキャスト アドレス サポート機能：要求された UE の IPv6 プレフィックス委任は、ローカルに割り当てられるか、P-GW、GGSN、SAEGW がこれらのノードの設定に基づいて外部 DHCPv6 サーバーから割り当てます。これらの DHCP メッセージは、宛先アドレスにマルチキャストアドレスを使用し、外部 DHCPv6 サーバーに送信されます。P-GW サーバーが多数存在するが、DHCP サーバーの数は少ないネットワークでは、マルチキャストアドレスの DHCPv6 メッセージはネットワーク全体を通過する必要があり、ネットワークの負荷が増加します。ユニキャスト アドレス サポート機能により、通信事業者は、DHCP サービスで DHCPv6 サーバーの設定済みアドレスを使用して、ユニキャストアドレスのすべての DHCPv6 メッセージを外部サーバーに送信できます。この機能は CLI で制御されており、通信事業者は、DHCP サーバーに対するクライアントユニキャストの動作をサポートするように CLI を設定する必要があります。

重要	DHCPv6 サービスの設定の詳細については、「PDN ゲートウェイの設定」の章の「DHCPv6 設定」セクションを参照してください。

プレリリース SGSN との Gn/Gp インターワーキングが有効になっている場合、P-GW 上の GGSN サービスはダイレクトトンネル機能をサポートします。

ダイレクトトンネルでは、ユーザープレーンからの SGSN トンネルの「スイッチング」遅延が排除されることで、ユーザーエクスペリエンスが向上します（Web ページの迅速な配信、会話型サービスのラウンドトリップ遅延の短縮など）。運用コストおよび資本コストの観点から見たダイレクトトンネルの他の利点は、ダイレクトトンネルでは、SGSN でのユーザープレーン処理の要件を排除することにより、ユーザープレーンリソースの使用が最適化されることです。

ダイレクト トンネル アーキテクチャにより、SGSN をバイパスして、RAN と GGSN の間で直接ユーザープレーントンネルを確立できます。SGSN は、引き続きコントロール プレーン シグナリングを処理し、通常は PDP コンテキストのアクティブ化でダイレクトトンネルの確立を決定します。ダイレクトトンネルは、PDP コンテキストのアクティブ化で SGSN によって実現されます。SGSN は、（GGSN への PDP コンテキスト更新要求を使用して）RNC と GGSN の間で直接ユーザープレーン（GTP-U）トンネルを確立します。

ダイレクトトンネル展開の主要な結果として、パケットコアの SGSN コンポーネントと GGSN コンポーネントの両方で、コントロールプレーンの負荷が大幅に増加します。そのため、展開された GGSN が、ダイレクトトンネル展開の一環として導入された追加のコントロールプレーンの負荷を処理できることを確認することがワイヤレスオペレータにとって最も重要です。Cisco GGSN および SGSN は、大規模なコントロール プレーン トランザクション機能を提供し、ダイレクトトンネルが展開された後、システム コントロール プレーンのキャパシティがキャパシティ制限要因にならないようにします。

重要	ダイレクトトンネルのサポートに関する詳細については、このガイドの「4G（LTE）ネットワークのダイレクトトンネル」の章を参照してください。

StarOS リリース 15.0 では、この機能により、PDN タイプ IPv4v6 用の機能が P-GW に追加されます。以前は、MS が IPv4 DNS アドレスを要求した場合、P-GW は IPv4 DNS アドレスを送信しませんでした。

MS は、PDP タイプ IPv4、IPv6、または IPv4v6 の PDP コンテキストアクティブ化プロシージャでプロトコル設定オプション IE を使用して（コンテナまたは IPCP プロトコル設定要求の一部として）、DNS サーバーの IPv4 または IPv6 アドレスを要求する場合があります。その場合、P-GW は、PDP コンテキストアクティブ化応答メッセージで PCO IE 内の 1 つ以上の DNS サーバーの IP アドレスを返すことができます。DNS アドレスは、3GPP TS 24.008 で規定されているとおりに PCO にコード化されます。

PDP タイプ IPv4v6 の場合、MS が DNS サーバーの IPv4 アドレスを要求すると、IPv4 アドレスが返されませんでした。MS によって要求されたアドレスで応答するためのサポートが追加されました。

AAA サーバーは、Access-Accept 認証応答で DNS サーバーの IP アドレスを提供する場合もあります。このような場合、AAA が提供する DNS サーバーの IP は、APN で設定された IP よりも優先されます。

PCO 設定で DNS サーバーのアドレスが要求される場合は、次の優先順位に従います。

このソリューションにより、DNS 応答をスヌーピングすることで、地理的に適切で正確なサーバーの IP エントリを取得する際の柔軟性と精度が向上します。

現在のところ、ドメイン（m.google.com）に基づいてフィルタリングするように L7 ルールを設定できます。複数のサーバーがドメインにサービスを提供し、それぞれが独自の IP アドレスを持つ場合があります。HTTP ルールの代わりに IP ルールを使用すると、複数の IP ルールが作成されます。ドメインの「背後」にある各サーバーに対して 1 つの IP ルールが作成されるため、ドメインベースのフィルタのために IP アドレスのリストを維持するのに手間がかかる可能性があります。

このソリューションでは、ホスト名（ドメイン名）とホスト名（ドメイン名）の一部を指定する ruledef を作成できます。ホスト名やドメイン名、またはそれらの一部の定義に応じて、P-GW は、UE に送信されたすべての DNS 応答をモニターし、ルールで指定されている q-name または a-name を持つ DNS 応答のみをスヌーピングして、DNS 応答から得られたすべての IP アドレスを特定します。DNS スヌーピングは、すべてのサブスクライバのライブトラフィックに対して実行されます。

DSCP マーキングの精度の高い設定サポートが提供されます。

双方向トラフィッククラスの場合、P-GW は現在の優先順位に加えて、割り当てや保持の優先順位に基づいて、アップリンクおよびダウンリンク方向に対するゲートウェイごとのサービスや、APN ごとに設定可能な DSCP マーキングをサポートします。

次のマトリックスを使用すると、設定されたトラフィッククラスや割り当て/保持の優先順位に基づいて使用される Diffserv マーキングを決定できます。

さらに、P-GW では DSCP 値を使用した Diameter パケットおよび GTP-C/GTP-U エコーの設定が可能です。

RAT タイプベースの DSCP マーキング

通信事業者は、RAT タイプに基づいて、P-GW、SAE-GW、GGSN などのゲートウェイで DSCP マーキングを実行できます。これにより、通信事業者はさまざまな QoS サービスを設定し、RAT タイプ（EUTRAN、GERAN、UTRAN）に基づいてトラフィックを最適化できます。

RAT タイプベースの DSCP マーキングには次のものがあります。

• すべての QCI および ARP 値をサポートします。

• 標準および非標準 QCI をサポートします。

• 特定の RAT タイプが設定されていない場合、DSCP マーキング機能はすべての RAT タイプに適用されます。

• 仮想 APN に適用されます。

• RAT 間のハンドオフ時に、現在のハンドオフの RAT タイプに基づき DSCP マーキングが実行されます。

• RAT タイプごとの DSCP マーキングは、ユーザーデータトラフィックにのみ適用され、制御トラフィック（GTP-C パケット）には適用されません。

重要	既存の DSCP マーキングおよび IP-ToS 機能については、下位互換性が維持されています。

動的 GTP エコータイマーを使用すると、eGTP および GTP-U サービスで、ネットワーク輻輳時の GTP パスをより適切に管理できます。固定の間隔と再送信タイマーを使用するデフォルトのエコータイマーとは対照的に、動的エコータイマーは、完全な要求/応答手順が完了すると生成される、計算されたラウンドトリップタイマー（RTT）を追加します。輻輳期間中の追加サポートのために、計算に乗数を追加できます。

重要	詳細については、「PDN ゲートウェイの設定」の 章の「P-GW でのオプション機能の設定」にある「GTP エコータイマーの設定」を参照してください。

ダイナミックポリシーおよび課金制御は、IMS マルチメディア アプリケーションを実現するための主要な構成要素となります。静的にプロビジョニングされたアーキテクチャとは対照的に、ダイナミック ポリシー フレームワークは、すべてのアクセス側ネットワーク要素のグローバルな認識を、一元化されたサービス制御レイヤに提供します。一元化されたポリシー決定要素により、複数のアクセスゲートウェイにグローバルなポリシーをプロビジョニングするプロセスが簡素化されます。ダイナミックポリシーは、常時稼働の導入モデルで特に有用です。これは、使用パラダイムが短期からより長いオンラインセッションに移行する際に、消費されるデータ量が大量になる可能性があるためです。このような条件では、ダイナミックポリシー管理により動的な即時リソース割り当てが可能になり、ネットワークの容量とリソースをより効率的に保護できます。

ダイナミックポリシー制御とは、P-GW のポリシー課金適用機能（PCEF）と PCRF 間で、サービスおよびアプリケーションフローを動的に許可および制御する機能を表します。ポリシー制御により、一元化された分割サービス制御アーキテクチャが可能になり、ベアラーリソースレイヤでサービスがプロビジョニングおよび割り当てられる方法を管理できます。

StarOS 9.0 リリースには、3GPP TS 29.212 および 29.230 の機能に準拠するための拡張機能が含まれています。Gx 参照インターフェイスは、Diameter トランスポートと IPv6 アドレッシングを使用します。サブスクライバは、Subscription-ID AVP 内の IMSI ベースの NAI を使用して、セッション確立時に PCRF へと識別されます。さらに、Equipment-Info AVP 内の IMEI は、ポリシーサーバーに対するサブスクライバアクセス端末の識別に使用されます。Gx 参照インターフェイスは、以下の機能をサポートしています。

Enhanced Charging Service は、サブスクライバのデータパケットを検査して詳細レコードを生成するための統合型インラインサービスを提供します。これにより、使用量やトラフィックパターンに基づく課金が可能になります。その他の特長には次のようなものがあります。

Enhanced Charging Service（ECS）は、システム内に統合されるインラインサービス機能です。ECS はモバイルキャリアの機能を強化し、バックエンド課金仲介システムとの統合機能を備えたレイヤ 3 からレイヤ 7 のディープ パケット インスペクション（DPI）を使用して、サブスクライバに柔軟で差別化された詳細な課金情報を提供します。

ECS はアクティブ状態の仲介システムと連携して、リアルタイムの完全な前払いおよびアクティブな課金機能を提供します。このとき、アクティブな仲介システムがさまざまなアプリケーションの料金設定機能や請求機能を提供します。

さらに、ECS に組み込まれた広範なレコード生成機能は、ユーザーセッションを細部まで把握して後払い課金にも対応します。詳細については、複数の詳細レコードタイプのサポートを参照してください。

仲介と課金の方法

課金仲介システムと統合する際の柔軟性を最大限に高めるため、ECS は課金インターフェイスと承認インターフェイスを全範囲に渡ってサポートしています。

重要	Enhanced Charging Service 機能には、サービスライセンスが必要です。 ECS ライセンスは P-GW セッション使用ライセンスに含まれています。ECS の詳細については、『ECS Administration Guide』を参照してください。

Framed-Route 属性は、このネットワーク アクセス サーバー（NAS）上のユーザーに対して設定するルーティング情報を提供します。Framed-Route 情報は、Access-Accept メッセージで RADIUS サーバーに返されます。

モバイルルータは、P-GW が RADIUS サーバーを使用して許可する PDN セッションをルータが作成できるようにします。RADIUS サーバーはこのルータを認証し、access-accept 応答パケットに Framed-Route 属性を含めます。また、Framed-Route 属性は「モバイルルータ」用に P-GW にインストールされるサブネットルーティング情報も指定します。P-GW は、宛先アドレスが Framed-Route と一致するパケットを受信すると、関連付けられた PDN セッションを介してモバイルルータに転送されます。詳細については、「APN 上のモバイルステーション背後のルーティング」の章を参照してください。

この機能の統合されたサポートには、P-GW と GGSN の両方に有効なセッション使用ライセンスキーがインストールされている必要があります。ライセンスの入手方法の詳細については、シスコの営業またはサポート担当者にお問い合わせください。

LTE 展開では、3G/2G ネットワークと LTE ネットワーク間でのスムーズなハンドオーバーのサポートが必要です。Evolved Packet Core（EPC）は、さまざまなアクセステクノロジーに共通のパケットコアとして設計されています。P-GW は、ユーザー機器（UE）が異なるアクセステクノロジーに移行するときに、ハンドオーバーをサポートします。

シスコの P-GW は、4G アクセスと 3G/2G アクセス間のテクノロジー間モビリティハンドオーバーをサポートします。4G と 2G/3G SGSN の間のインターワーキングがサポートされており、このインターワーキングでは、Gn および Gp インターフェイスのみが提供され、S3、S4 または S5/S8 インターフェイスは提供されません。これらの Gn/Gp SGSN では、Evolved Packet System（EPS）のために導入された機能や、E-UTRAN との相互運用のために特に導入された機能は提供されません。これらのハンドオーバーは、GTP ベース S5/S8 でのみサポートされ、P-GW は、GTPv2 ベース S5/S8 と GTPv1 ベース Gn/Gp トンネル接続の間のハンドオフをサポートします。このシナリオでは、P-GW は EPC の IP アンカーとして機能します。

重要	GGSN と P-GW 間のセッションのシームレスなハンドオーバーをサポートするには、2 つの独立したサービスを同じノードに配置し、同じコンテキスト内で設定して、最適な相互運用性を実現する必要があります。

重要	Gn/GP ハンドオフの詳細については、「Gn/Gp インターフェイス」を参照してください。

StarOS リリース 20.0 では、GTP-C パス障害機能を最適化し、GTP-C パス障害の問題に対するシステムのデバッグ機能を向上させるための機能拡張が追加されました。これらの機能拡張は、オペレータとエンジニアがシステムのさまざまな側面をデバッグし、ネットワーク内の GTP-C パス障害の根本原因を特定するのに役立ちます。これらの機能拡張は、S5、S8、S2b、および S2a インターフェイスを介したパス障害検出に影響を及ぼします。

この機能の一部として、次の拡張機能が追加されました。

• 誤ったメッセージや偽のメッセージが原因で低い値のリスタートカウンタを受信した場合、パス障害を検出しないようにノードを設定でき、コールの損失を防げます。エコー要求/応答メッセージや制御メッセージ要求/応答メッセージによるパス障害を無効にするオプションも使用できるため、パス障害の誤検出が発生した場合にコールの損失を防げます。

• ネットワーク内の問題の根本原因をより迅速に診断できるように、GTP-C パス障害の統計情報の精度が向上しました。

• ピアごとに最後の 5 つのパス障害に関するパス障害履歴を、ネットワーク内のパス障害のデバッグに使用できます。

• シームレスなパス障害処理が実装されているため、冗長性イベント中のコールの損失が回避されます。

誤ったパス障害検出を回避するためのサポート

誤ったパス障害検出を回避するノードの機能を促進するために、いくつかの機能強化が加えられました。

• ピアからのスプリアスメッセージや不正確なメッセージによるパス障害検出を回避するために、ソフトウェアの機能が強化されました。これらのメッセージにより、サービスの非アクティブ化とアクティブ化の数が原因でネットワークトラフィックの大規模なバーストが引き起こされ、ネットワーク輻輳が発生する可能性があります。この問題を解決するために、eGTP-C サービス コンフィギュレーション モードの gtpc コマンドが拡張されました。誤ったパス障害検出が GTP-C パス障害として検出されないようにするために、max-remote-restart-counter-change キーワードが追加されました。たとえば、max-remote-restart-counter-change が 10 に設定されており、現在のピアの再起動カウンタが 251 の場合は、新しい再起動カウンタが 252 ～ 255 または 0 ～ 5 の場合にのみ、eGTP はピアの再起動を検出します。同様に、保存された再起動カウンタが 1 の場合は、新しい再起動カウンタが 2 ～ 11 の場合にのみ、eGTP はピアの再起動を検出します。

• また、この機能強化の一環として、パス障害検出を有効または無効にするための新しいキーワードが eGTP-C サービス コンフィギュレーション モードの path-failure detection-policy コマンドに追加されました。

• EXEC モードの show egtp-service all コマンドが拡張され、ノードでエコー要求/エコー応答再起動カウンタの変更と制御メッセージ再起動カウンタの変更が有効か無効かが示されるようになりました。

GTP-C パス障害統計の改善

オペレータ/エンジニアが障害の原因をより迅速に特定できるように、GTP-C パス障害の品質を向上させるいくつかの改善が行われました。

• show egtpc statistics path-failure-reasons の出力が拡張され、demuxmgr および sessmgr での制御メッセージ再起動カウンタ変更の数とタイプが表示されるようになりました。このコマンドの出力が強化され、eGTP-C レイヤで無視された検出済みパス障害の数を追跡できるようになりました。

• show egtpc peers path-failure-history コマンドの出力が追加され、ピアごとに最後の 5 つのパス障害に関する詳細情報が提供されるようになりました。

• show egtp-service all name コマンドと show configuration コマンドの出力が拡張され、パス GTP-C パス障害検出ポリシーに固有の現在の設定が表示されるようになりました。

このサポートにより、UE は、緊急 PDN に接続して Enhanced 911（E911）コールを行いながら、必要なロケーション情報を公安アクセスポイント（PSAP）に提供することが可能になります。

E911 は、緊急事態が発生している人とそれを支援できる公共のリソースを結び付けるために設計された、電気通信ベースのシステムです。この機能は、LTE および IMS ネットワークを介した E911 ベースのコールをサポートしています。Voice over LTE のシナリオでは、サブスクライバは、PSAP への Voice over IP 接続を確立するために、「EPDN」（緊急 PDN）と呼ばれる専用のパケットデータネットワーク（PDN）にアタッチします。シグナリングがデフォルトの緊急ベアラーで発生するか、シグナリングと RTP メディアのフローが個別の専用緊急ベアラーを介して発生します。さらに、コールの確立を AAA および PCRF コンポーネントに依存する通常の PDN 接続とは異なり、EPDN 属性は P-GW でローカルに設定されるため、それらのシステムのいずれかが使用できないことで緊急コールが失敗する可能性がありません。

IMS 緊急セッションをサポートするために緊急ベアラーサービスが提供されます。緊急ベアラーサービスとは、緊急サービスをサポートするようにネットワークが設定されている場合に、サービスを提供しているネットワークによって提供される機能を指します。緊急ベアラーサービスは、通常どおりにアタッチされた UE のほかに、サービスが制限されている（現地のサービス規制、ポリシー、および制限に応じて）UE に提供されます。限定的なサービス状態での緊急サービスの受信には、サブスクリプションは不要です。

標準規格（3GPP TS 23.401 を参照）では、サポートされている次の 4 つの動作が特定されています。

緊急サービスを要求する際、UE には次の 2 つのオプションがあります。

IP アクセス制御リストを使用すると、さまざまな IP パケットパラメータに基づいて、システムに出入りするパケットのフローを制御するルールを設定できます。

IP アクセスリスト（一般にアクセス制御リスト（ACL）と呼ばれます）は、システムに出入りするパケットのフローを制御するために使用されます。これらはコンテキストごとに設定され、フィルタ基準に一致するパケットに対して実行されるアクションを制御する「ルール」（ACL ルール）またはフィルタで構成されます。設定が完了すると、ACL を次のいずれかに適用できます。

このサブスクライバレベルの CLI は、アドレス隔離とも呼ばれ、以前に割り当てられた IP アドレスを IP アドレスプールから一時的にバッファリングして、新しいサブスクライバセッションにリサイクルされて再割り当てされるのを防ぎます。この機能は、モバイルデータセッションの一時的な喪失につながることがある、RAT 間ハンドオーバー時に特に役立ちます。

この機能により、リモートホストサーバーがモバイルデバイスに到達する必要があるロケーションベースのサービスでのより高品質なユーザーエクスペリエンスが可能になります。

重要	現在、P-GW は、IPv4 アドレスを使用したアドレスホールドタイマーのみをサポートしています。

アドレス効率を向上させ、急速に枯渇に近づいている IPv4 アドレスの問題に対応するプレッシャーを軽減します。

P-GW は、次の IPv6 機能を提供します。

アタッチされたエレメントへの IPv6 接続

RFC-4861 には、ルータアドバタイズメント（RA）メッセージで最大伝送ユニット（MTU）を送信するよう規定されています。P-GW は、IPv6 および IPv4v6 PDN タイプの RA で IPv6 MTU オプションを UE に送信することをサポートするようになりました。その結果、UE は、設定された MTU に基づいてアップリンクデータパケットを送信し、必要に応じて送信元でデータのフラグメンテーションを実行することが可能になりました。また、この機能により、ユーザーのネットワーク内の ICMPv6 Packet Too Big Error メッセージの数も減少します。

MTU サイズは、GGSN および P-GW のコマンド ライン インターフェイス（CLI）を使用して設定できます。

サポートされる機能

RA メッセージ機能で IPv6 MTU オプションをサポートするために、P-GW/GGSN は、次の機能と動作をサポートしています。

• APN コンフィギュレーション モードで ipv6 initial-router-advt option mtu value コマンドを使用して、APN ごとにこの機能を有効または無効にすることができます。デフォルトでは、この機能は、すべての APN について有効になっています。

  • P-GW および SAEGW では、IPv6 初期ルータ アドバタイズメント オプションの MTU 値は、オクテット（整数 1280 ～ 2000） で設定する必要があります。設定された値は、データトンネルの MTU ではなく、RA パケットで送信されます。

    重要	この値は、RA パケットのアドバタイズメントにのみ使用され、ゲートウェイはこの値を強制する必要はありません。この CLI の「default」オプションと「no」オプションの動作は同じであるままになります。

  • P-GW および SAEGW では、セッションマネージャは、APN コンフィギュレーション モードで CLI コマンド data-tunnel mtu 1280-2000 を介して設定された MTU 値を送信します。

  • GGSN では、Framed-MTU 属性値ペア（AVP）で RADIUS から返される値が、APN コンフィギュレーション モードで ppp mtu 100-2000 CLI コマンドを介して設定された値よりも優先されます。

• GGSN では、RADIUS から返される MTU 値が最小 IPv6 MTU 未満の場合、1280 の最小 IPv6 MTU 値が RA メッセージの IPv6 MTU オプションフィールドで送信されます。

• GGSN では、ppp mtu100-2000 CLI コマンドが 1280 未満の MTU 値で設定されている場合、最小 IPv6 MTU 値は、RA メッセージの IPv6 MTU オプションフィールドで送信されます。

• RADIUS サーバーから MTU 値が取得されず、上記の両方の CLI コマンドが設定されていない場合、MTU にはデフォルト値の 1500 が使用されます。

• RA メッセージの MTU オプションは、GGSN/P-GW/SAEGW でサポートされています。

• この機能は、s2a/s2b/s5/s8 などのインターフェイスとは無関係に、P-GW でサポートされます。

• RA メッセージの MTU オプションは、IPv6 と IPv4v6 の両方の PDN タイプでサポートされています。

• RA メッセージの MTU オプションは、monitor protocol コマンドの出力で使用できます。

• ゲートウェイにより、コールの初期および定期 RA メッセージで同じ MTU 値が送信されます。

• PDN コールの RA の IPv6 MTU オプションを送信する動作は、セッションリカバリおよび ICSR スイッチオーバー後も維持されます。

• GGSN/P-GW/SAEGW での既存の MTU 関連データパスの動作は変更されません。

制約事項/制限

この機能には、次の制約事項/制限があることに注意してください。

• GGSN/P-GW/SAEGW では、RA の IPv6 MTU オプションで送信される MTU 値を計算するときに、GTP-U トンネルのオーバーヘッドが考慮されません。そのため、通信事業者は、トンネルのオーバーヘッドを考慮して data-tunnel mtu を設定する必要があります。『3GPP TS 23.060』の「Annex-C」の「Link MTU Considerations」を参照してください。

• GGSN/P-GW/SAEGW の既存 MTU 関連データパスの動作は変更されていません。

• Gn/Gp ハンドオーバーが発生し、その後にセッションリカバリが実行される場合、通信事業者は、「ステートレス IPv6 セッションが、ハンドオーバー後に現在の GGSN/P-GW サービスに設定された MTU 値でリカバリされる」という動作を確認できます。これは、この機能が設定されていない場合の既存の動作です。この機能を有効にすると、そのようなハンドオーバーが発生し、その後にセッションリカバリが実行される場合、回復された同じ MTU 値が定期的な RA メッセージで送信されます。

• この機能は、eHRPD ではサポートされていません。その結果、LTE から eHRPD へのハンドオーバー、または eHRPD から LTE へのハンドオーバーが発生するシナリオでは、新しいステートレス IPv6 セッションが、最新の APN 設定を使用して再作成されます。

• この機能が有効になっている場合、S6b インターフェイスを介してゲートウェイが受信する MTU 値はサポートされません。

特定顧客の一部の UE デバイスでは、Wi-Fi の RAT 間テスト中に、LTE から Wi-Fi へのハンドオフが失敗していました。これらの UE デバイスは、ステートレスアドレス自動設定を使用していました。この問題は、ハンドオフ中にセッション作成応答（CSResp）メッセージで変更された IPv6 アドレスを UE が送信している場合に、特定の UE デバイスでのみ確認できます。別のベンダーのデバイスでは、P-GW からのセッション作成応答（CSResp）中に最初に割り当てられた IPv6 アドレスを送信していたため、LTE から Wi-Fi へのハンドオフの問題は発生しませんでした。

P-GW が、完全な IPv6 128 ビットアドレス（プレフィックス + インターフェイス ID）に基づいて既存の LTE セッションの IPv6 ルックアップを実行すると、そのハンドオーバーは、エラー EGTP_CONTEXT_NOT_FOUND で失敗します。

現在、P-GW は、LTE から Wi-Fi へのハンドオフ中に IPv6 プレフィックス（64 ビット）のみを使用して、既存の LTE セッションの IPv6 ルックアップを実行します。ステートレスアドレス自動設定により、通信事業者には、UE デバイスに対するこれらのコールでシームレスなハンドオーバーが見られるようになりました。P-GW は、UE が、PDN タイプ IPv6 および IPv4v6 のハンドオフ中のコール作成時に提供されるインターフェイス ID とは異なるインターフェイス ID を使用する場合、ハンドオフ要求を拒否しません。

重要	外部インターフェイスに変更はありません。この機能に含まれる唯一の変更点は、ハンドオフ時に 64 ビット IPv6 プレフィックスを使用して既存のセッションを検索する内部検索が実行されることです。

制約事項/制限

ステートレス自動設定が使用されるのは、UE が、P-GW によって提供されるものとは異なるインターフェイス ID を使用する場合です。その場合、UE は、後で別のロケーションに移動します。これにより、S-GW が変更される S1/X2 ハンドオーバーが発生します。その結果、S-GW は、同じ UE で、PDN について、P-GW によって維持されている IPv6 アドレス（つまり、初期アタッチ時に提供された IP アドレス）とは異なる IPv6 アドレスを持つ場合があります。これにより、P-GW と S-GW で CDR の servedPDPPDNAddress 要素に相違が生じる可能性があります。

この制限は、ベアラー変更変更/ベアラー変更応答などの 3GPP 変更手順における既存の制限（S1/X2 ハンドオーバー時に、P-GW および S-GW の間で、変更された UE IPv6 アドレスを交換できない）によるものです。

メディエーションデバイスは、ステートレス自動設定デバイスについて、CDR の IPv6 アドレスの 64 ビットプレフィックスを調べることが想定されています。

この機能は、LTE 事業者が、他のモバイル通信事業者とのローミング契約に基づいて訪問先のサブスクライバからのトラフィックを受け入れることにより、追加の収益を生み出すことを可能にする、標準ベースの手順を提供します。

ローカルブレークアウトは、LTE サービス プロバイダー ネットワーク間のプロバイダー間ローミングで重要な役割を果たすポリシーベースの転送機能です。ローカルブレークアウトは、訪問先ネットワークとホームネットワーク間のローミングコールの処理に関する SLA によって決定されます。場合によっては、ホームネットワークにトラフィックをバックホールするための追加の転送コストを発生させるより、外部ネットワーク上のローミングコールを訪問先 P-W にローカルにブレークアウトする方が有益です。

2 つのモバイル通信事業者がローミング契約を締結している場合、ローカルブレークアウトにより、訪問先ユーザーは、V-PLMN ネットワークに接続し、訪問先ネットワーク内のローカル P-GW によってアンカーされることが可能になります。このローミングアーキテクチャは、ホームネットワークの HSS に依存しており、H-PLMN の H-PCRF と V-PLMN の V-PCRF の間に S9 ポリシー シグナリング インターフェイスの概念も導入します。ユーザーが訪問先ネットワークの EUTRAN セルと MME（モビリティ マネージメント エンティティ）にアタッチすると、S6a NAS シグナリングで要求された APN 名が H-PLMN の HSS によって使用され、ローカル S-GW（サービングゲートウェイ）と訪問先 EPC ネットワークの P-GW が選択されます。

Voice over LTE（VoLTE）シナリオでは、P-GW は LTE ビデオコール（LVC）をサポートします。この機能をサポートするために必要な追加の設定はありません。

P-GW は、ビデオコールのセットアップ時およびアクティブなビデオ通話中に定期的に、サブスクライバのデータ使用量クォータをチェックします。以下の機能が、データ使用量が制御される後払いサブスクライバに適用されます。

クォータチェック：コールセットアップ

クォータチェック：アクティブビデオコール中

セッションマネージャがアップグレードされ、コアを共有せず、また CPU 負荷のボトルネックを発生させずに、複数の高スループットセッションを管理できるようになりました。

ゲートウェイ（S-GW、SAEGW、または P-GW）は、セッション作成要求の IE（FLAGS FOR USER PLANE FUNCTION（UPF）SELECTION INDICATION）にある DCNR フラグに基づいて、セッションを高スループットセッションに分類します。この DCNR フラグは、ゲートウェイによってチェックポイントとして扱われ、リカバリが行われます。

高スループットセッションは、他の高スループットセッションがないセッションマネージャに配置されます。すべてのセッションマネージャが高スループットセッションを処理している場合、これらのセッションはラウンドロビン方式を使用して割り当てられます。

（注）	高スループットではないセッションの場合のセッションマネージャの選択は、既存の設定と同じままです。 高スループットではないセッションは、同じセッションマネージャの高スループットセッションとともに配置されます。

制限事項

セッションマネージャでの高スループットセッションの管理には、次の制限があります。

• 次のシナリオでは、セッションマネージャに 2 つの高スループットセッションが配置される可能性があります。

  • 最初に eHRPD/2G/3G セッションから接続した。

  • IP アドレス（IPv4 と IPv6 の両方）が、同じセッションマネージャに配置された。

  • S-GW で、UE からの 2 番目のセッション作成要求（PDN）が、同じ UE の最初の PDN を持つセッションマネージャに直接到達した。

  • 折りたたまれたコールにおいて、UE からの 2 番目のセッション作成要求（PDN）が、同じ UE の最初の PDN を持つセッションマネージャに直接到達した。

  • DCNR 対応の UE からのマルチ PDN コール内。たとえば、VoLTE と、DCN 対応のインターネットは、同じセッションマネージャに配置されます。

• DCNR フラグは Wi-Fi の 3GPP では定義されていません。したがって、DCNR フラグがセットされている状態での Wi-Fi から LTE へのハンドオーバー中に、セッションをセッションマネージャに割り当てることはできません。

• この機能は、セッションマネージャでの高スループットセッションの分散を管理およびサポートしますが、サブスクライバでの高スループットを保証するものではありません。

• 場合によっては、ラウンドロビンメカニズムにより、他の高スループットセッションがすでに配置されているセッションマネージャに高スループットセッションが配置されることがあります。

802.1p マーキングと同様に、MPLS EXP ビットマーキングは、P-GW の SGi インターフェイスで MPLS トンネリングを使用するエンタープライズ APN でサポートされています。LTE/EPC ネットワークで使用される QoS マーキング（EPS ベアラーごとの QCI）は、P-GW と L2/EPC スイッチや MPLS/PE ルータ間の 802.1p および MPLS EXP ビットマーキングにマッピングされます（これは P-GW からネットワークへのアップストリーム方向に適用されます）。QCI-QOS 設定テーブルの一部を、MPLS EXP マーキング関連の設定に使用できます。MPLS EXP マーキングは、そのパケットが属するベアラーの QCI に基づいて選択されます。

重要	有効なライセンスキーがインストールされていない場合、P-GW は非標準の QCI 値をサポートしません。 QCI 値 1 ～ 9 は、3GPP TS 23.203 で定義されている標準値です。P-GW はこれらの標準値をサポートします。 3GPP リリース 8 以降では、通信事業者固有/非標準の QCI がサポートされ、キャリアは QCI 128- 254 を定義できます。詳細については、非標準 QCI のサポートを参照してください。

通常、UE は IP 通信にハードコードされた MTU サイズを使用します。このハードコードされた値がサポートされているネットワーク値と同期していない場合、UE によって送信されるパケットに不要なフラグメントが発生する可能性があります。したがって、不要なフラグメントを回避するために、この機能は、UE でハードコードされた MTU の代わりにネットワークが提供する MTU サイズを使用できるようにします。

3GPP は、ネットワークが UE に IPv4 MTU サイズを提供できるように、リリース 10 仕様で新しい PCO オプションを定義しました。P-GW では、APN プロファイルで IPv4 リンク MTU サイズを設定するオプションがサポートされています。

初期接続または PDN 接続要求中に UE が PCO オプションで IPv4 リンク MTU サイズを要求した場合、P-GW は APN に基づいて事前設定された値を提供します。

APN で MTU サイズの設定が変更された場合、新しい MTU サイズは新規の PDN 接続と初期接続に対してのみ有効になります。P-GW は既存の PDN 接続は更新しません。

UE が IPv4 リンク MTU サイズを要求しない場合、P-GW には IPv4 リンク MTU サイズは含まれません。

UE がアウトバウンドローミング中の場合は、APN コンフィギュレーション モードで pco-options コマンドを使用して、リンク MTU サイズを柔軟に設定できます。詳細については、該当するリリースの『Command Line Interface Reference, Modes A - B』の「pco-options」の項を参照してください。

IMS、インターネット、ウォールドガーデンサービス、オフデッキ コンテンツ サービスなど、さまざまなサービスに個別の接続を割り当てることができる APN ベースのユーザーエクスペリエンスを実現します。

S-GW の MAG 機能は、同じユーザーセッションに対して複数の PDN または APN 接続を維持できます。MAG は、P-GW の LMA 機能へのすべてのユーザーセッションに対し、シングルノードレベルのプロキシモバイル IPv6 トンネルを実行します。ユーザーが複数の PDN 接続を確立する場合、MAG は、同じ PMIPv6 セッションを介して 1 つ以上の P-GW LMA への複数の PDN 接続を確立します。次に、P-GW は、各 PDN 接続に個別の IP アドレス（ホーム ネットワーク プレフィックス）を割り当て、それぞれが 1 つまたは複数の EPC デフォルトおよび専用ベアラーを実行できます。さまざまな PDN 接続を要求するために、MAG には共通の MN-ID と個別のホーム ネットワーク プレフィックス、APN、および PMIPv6 バインディングアップデートのものに等しいハンドオーバー指示値が含まれます。

重要	最大 11 の複数 PDN 接続がサポートされます。

この機能は、通信する 2 つの GTP ノードの機能を交換するのに役立ち、他方のノードでサポートされているかどうかに基づいて新しい機能を使用します。

この機能により、S-GW は、ピアエンティティと機能（MABR、PRN、NTSR）をエコーメッセージを介して交換できます。この機能により、両方のピアノードがいくつかの共通の機能をサポートしている場合、新しいメッセージを使用して相互に通信できます。

エコー要求/応答メッセージでの新しい「ノード機能」の IE サポートにより、各ノードは、サポート対象の機能（MABR、PRN、NTSR）を送信できます。この方法で、S-GW はピアノードでサポートされている機能を学習できます。S-GW でサポートされている機能は、いくつかの設定をサービスレベルで行うことで設定できます。

S-GW が P-GW 再起動通知などの新しいメッセージを使用する場合、S-GW は、ピアノードがこの新しい機能をサポートしているかどうかを確認する必要があります。ピアがサポートしていない場合、S-GW は古い動作にフォールバックする必要があります。

S-GW がピアノードから新しいメッセージを受信した場合に、S-GW がこの新しいメッセージをサポートしていなければ、S-GW はそのメッセージを無視する必要があります。S-GW が特定の機能をサポートしている場合は、仕様に従って新しいメッセージを処理する必要があります。

この機能により、デュアルモード e-HRPD/e-UTRAN アクセス端末をサポートするシームレスなテクノロジー間ローミング機能が実現されます。

非最適化テクノロジー間モビリティ手順は、デュアル無線テクノロジー e-HRPD/E-UTRAN アクセス端末のハンドオーバーをサポートするためのモビリティアンカーポイントとしての P-GW に基づいています。このタイプのコールハンドオーバーをサポートするために、P-GW は、GTP ベースの S5/S8（GTPv2-C/GTPv1-U）と PMIPv6 S2a トンネル接続間のハンドオフをサポートしています。また、共通アドレスプールから IPv4、IPv6、またはデュアルスタック IPv4/IPv6 PDN 接続をプロビジョニングし、テクノロジー間ハンドオーバー中に UE に割り当てられる IP アドレスを保持します。現在のリリースでは、ネイティブ LTE（GTP ベース）P-GW サービスアドレスは IPv4 ベースですが、e-HRPD（PMIP）アドレスは IPv6 サービスアドレスです。

UE が接続する各 APN の初期ネットワークアタッチ時に、HSS は、その APN の P-GW の FQDN を返します。MME は、DNS を使用して P-GW アドレスを解決します。PDN 接続が P-GW で確立されると、P-GW は、S6b 認証プロセスによって PDN が確立された時点で、P-GW の IP アドレスを使用して HSS を更新します。モバイルユーザーが e-HRPD ネットワークにローミングすると、HSS は、STa インターフェイスを介して P-GW 識別子で P-GW の IP アドレスを返し、そのコールは同じ P-GWで終了します。また、P-GW は、ターゲットネットワークへのコールハンドオーバー後に、サービス提供アクセス接続でセッション終了を開始する役割も担います。

ハンドオーバー手順中に、すべての専用 EPS ベアラーを再確立する必要があります。ターゲット e-HRPD アクセスネットワークへの LTE ハンドオーバー時には、専用ベアラーが、モバイルアクセス端末によって開始されます。対照的に、e-HRPD から LTE アクセスネットワークへの反対方向のハンドオーバーでは、専用ベアラーは、PCRF サーバーとの Gx ポリシー相互作用を通じてネットワークによって開始されます。

3 つのタイプのセッションはすべて、コールハンドオーバー中に維持されます。ベアラーバインドは、e-HRPD アクセス時に HSGW によって実行され、LTE アクセス時に P-GW によって実行されます。そのため、ベアラー バインド イベント レポート（BBERF）機能は、ハンドオーバー中に P-GW と HSGW の間を移行する必要があります。HSGW は、ベアラーバインドのために e-HRPD アクセス中に Gxa セッションを確立し、LTE アクセス中にセッションをリリースします。また、HSGW は、e-HRPD <-> LTE ハンドオーバー中に制限されたコンテキストを維持し、LTE RAN から e-HRPD ネットワークへのクイックハンドオーバーが発生した場合の遅延を減らします。

重要	ハンドオフインターフェイスの詳細については、「サポートされる論理ネットワーク インターフェイス（参照ポイント）」を参照してください。

Cisco EPC プラットフォームは、外部 OCS や CGF/CDF サーバーとのオンラインおよびオフライン課金の連携動作をサポートします。

ソフトウェアは、egtpinmgr タスクの再起動時にリカバリ停止期間を最適化するように機能拡張されました。この最適化は、egtpinmgr リカバリの内部アルゴリズムを最適化し、必要なデータ構造を最適化することによって実現されています。さらに、リカバリ時間は、IMSI のセッション数ではなく、一意の IMSI の数によってのみ決まるようになりました。

Wi-Fi 統合のための GTP ベース S2b インターフェイスの P-CSCF 検出をサポートする、仕様ベースのメカニズムをサポートします。これは Voice over Wi-Fi サービスに必要です。

P-GW は、AAA への初期登録時に受信した P-CSCF FQDN を保存できます。MME/S-GW から P-CSCF 復元フラグを受信すると、P-GW は、既存の P-CSCF FQDN を使用して新しい DNS クエリを実行し、PCO を使用して 3 つの P-CSCF IP アドレスの更新済みリストを提供します。

通信事業者はピアのタイプやピアの IP アドレスに基づいて、GTP-C と合法的傍受用を柔軟に設定することができます。

ピアプロファイル機能により柔軟なプロファイルベースの設定が可能になるため、P-GW のピアノードのデフォルト値やアクションを使用して、カスタマイズ可能なパラメータの増え続ける要件に対応できます。この機能を使用すると、定義されたルールに基づいて MCC/MNC または IP アドレスごとに、GTP-C パラメータの設定や合法的傍受の無効化/有効化を実行できます。

ピアプロファイルとピアマップの新しいフレームワークが導入されました。ピアプロファイル設定では、GTP-C 固有の設定や合法的傍受の有効化/無効化の設定がキャプチャされます。GTP-C 設定の対象には、GTP-C 再送信（最大再試行回数と再送信タイムアウト）および GTP エコーの設定が含まれています。ピアマップ設定は、特定の基準に適用されるピアプロファイルと照合されます。ピアマップでは、ピアの MCC/MNC（PLMN-ID）やピアの IP アドレスなどの基準がサポートされます。さらに、ピアマップを P-GW サービスに関連付けることができます。

この機能の目的は、通信事業者が特定のピアのセットに適用可能なプロファイルを柔軟に設定できるようにすることです。たとえば、外部ピアにはホームピアと異なる再送信タイムアウトを設定できます。

プロキシモバイル IPv6（PMIPv6）は、PMIPv6 モビリティ関連のシグナリングへのモバイルノードの参加を必要とせずにモビリティを提供する、ネットワークベースのモビリティ管理プロトコルです。コア機能エンティティであるモバイル アクセス ゲートウェイ（MAG）とローカルモビリティアンカー（LMA）は、モバイルノードのモビリティを管理するためにトンネルを動的に設定します。

MAG と LMA 間のハートビートメッセージによる経路管理メカニズムは、ピアの到達可能性を認識し、障害を検出し、ノード障害から回復した場合にピアに迅速に通知し、ピアが適切なアクションを実行できるようにするために重要です。

HSGW から P-GW への PMIP ハートビートは、RFC 5847 に従ってサポートされています。このハートビートを有効にし、ハートビートの変数を設定するには、LMA サービスモードまたは MAG サービスモードの heartbeat コマンドをそれぞれ参照してください。

重要	PMIPv6 ハートビートのサポートの詳細については、このガイドの「PMIPv6 ハートビート」の章を参照してください。

サブスクライバがネイティブ EUTRAN と非ネイティブ e-HRPD アクセスネットワーク間をローミングするときに、単一の LTE-EPC コアネットワークがユーザーセッションのコールアンカーポイントを提供できるようにするモビリティ管理プロトコルを提供します。

S2a は、LTE-EPC コアネットワークと HSGW にアンカーされた evolved HRPD ネットワーク間の信頼された非 3GPP インターフェイスを表します。e-HRPD ネットワークでは、ネットワークベースのモビリティは、ホストが関与せずに IPv6 ノードのモビリティを提供します。Proxy Mobile IPv6 は、Mobile IPv6 シグナリングメッセージを拡張し、P-GW で HA 機能（現在は LMA と呼ばれる）を再利用します。このアプローチでは、モバイルノードが自身とホームエージェントとの間のシグナリングメッセージの交換に関与する必要はありません。ネットワーク内のプロキシ モビリティ エージェント（HSGW 上の MAG 機能など）はホームエージェントとのシグナリングを実行し、ネットワークに接続されたモバイルノードに代わってモビリティ管理を行います。

S2a インターフェイスは、制御とデータの両方に IPv6 を使用します。PDN 接続の確立手順中に、P-GW は Proxy Mobile IPv6 シグナリングを介して IPv6 ホーム ネットワーク プレフィックス（HNP）を HSGW に割り当てます。HSGW はルーターアドバタイズメントで、または UE からのルータ要請リクエストに基づいて HNP を返します。PDN 接続の解放イベントは、UE、HSGW、または P-GW のいずれかによってトリガーできます。

Proxy Mobile IPv6 アプリケーションでは、HSGW（MAG 機能）と P-GW（LMA 機能）が単一の共有トンネルを維持し、個々のサブスクライバセッションを区別するために PMIP バインディング更新メッセージおよび確認応答メッセージに個別の GRE キーが割り当てられます。Proxy Mobile IP シグナリングに Protocol Configuration Options（PCO）が含まれている場合、シグナリングは P-CSCF または DNS サーバーアドレスの転送にも使用できます。

コミットされた帯域幅リソース、ジッター、および遅延の要件に従って、さまざまなサービスやアプリケーションクラスの確定的なエンドツーエンド転送とスケジューリング処理を可能にすることで、Quality of User Experience（QoE）の向上に貢献するための基盤を提供します。その結果、各アプリケーションが、ユーザーが期待するサービス処理を受け取ります。

EPS ベアラーは、GTP ベースの S5/S8 の場合は UE と P-GW の間で、PMIP ベースの S2a 接続の場合は UE と HSGW の間で実行される 1 つ以上のサービスデータフロー（SDF）の論理的な集約です。EPS ベアラーは、EPC/E-UTRAN でのベアラーレベルの QoS 制御の精度レベルです。Cisco P-GW は、インバウンドのサービスデータフロー（SDF）を EPS ベアラーにマッピングするために、ダウンリンク方向の 1 つ以上のトラフィック フロー テンプレート（TFT）を維持します。P-GW は、ダウンリンク TFT に基づいてトラフィックを S5/S8 ベアラーにマッピングします。Cisco PDN GW は、次のベアラーレベルの集約構造をすべて提供します。

QoS クラス識別子（QCI）：ベアラーレベルのパケット転送処理を制御する、通信事業者によるプロビジョニング値（スケジューリング重み、アドミッションしきい値、キュー管理しきい値、リンク層プロトコルの設定など）。Cisco EPC ゲートウェイは、QCI 値を S5/S8 接続の外側 GTP トンネルヘッダーの DiffServ コードポイントにマッピングする機能もサポートしています。さらに、このプラットフォームには、カプセル化されたペイロードから外側 GTP トンネルヘッダーに DSCP マーキングをコピーするための設定可能なパラメータも用意されています。

パケットをさまざまなトラフィッククラスにグループ化する際に使用される 802.1p ネットワークトラフィックの優先順位付けをサポートするために、P-GW では、通信事業者は QCI 値をアップリンクおよびダウンリンクパケットの 802.1p 優先度にマッピングできます。

重要	有効なライセンスキーがインストールされていない場合、P-GW は非標準の QCI 値をサポートしません。 QCI 値 1 ～ 9 は、3GPP TS 23.203 で定義されている標準値です。P-GW はこれらの標準値をサポートします。 3GPP リリース 8 以降では、通信事業者固有/非標準の QCI がサポートされ、キャリアは QCI 128- 254 を定義できます。詳細については、非標準 QCI のサポートを参照してください。

保証ビットレート（GBR）：GBR ベアラーは専用の EPS ベアラーと関連付けられ、確定的な低遅延サービス処理を必要とする自動音声などのアプリケーションに固定ビットレートサービスを提供するために、保証された最小伝送レートを提供します。

最大ビットレート（MBR）：MBR 属性は、GBR ベアラーによって提供されることが期待されるビットレートを制限する設定可能なバーストレートを提供します（たとえば、過剰なトラフィックがレートシェーピング機能によって破棄される可能性があります）。MBR は、特定の専用 EPS ベアラーの GBR 以上である場合があります。

集約最大ビットレート（AMBR）：AMBR は、特定の PDN を宛先とするベアラーグループのトラフィックのビットレートを示します。集約最大ビットレートは通常、デフォルト EPS ベアラーを介してベストエフォート サービス データ フローのグループに割り当てられます。つまり、これらの EPS ベアラーのそれぞれが AMBR 全体を利用する可能性があります。たとえば、他の EPS ベアラーがトラフィックを伝送しない場合などです。AMBR は、AMBR を共有する EPS ベアラーによって提供されることが予想される集約ビットレートを制限します（たとえば、超過トラフィックがレートシェーピング機能によって破棄される場合があります）。AMBR は、同じ PDN 接続に属するすべての非 GBR ベアラーに適用されます。GBR ベアラーは AMBR の範囲外です。

ポリシング：Cisco P-GW は、さまざまなトラフィック調整機能と帯域幅管理機能を提供します。これらのツールを使用すると、サブスクライバごと、EPS ベアラーごと、または PDN/APN ごとに使用量制御を適用できます。APN ごとの AMBR キャパシティに帯域幅制御を適用することもできます。これらのアプリケーションは、シャロー L3/L4 分析または L7 でのハイタッチ ディープ パケット インスペクションを使用して、ユーザーセッションまたはユーザーセッション内のサービスデータフロー（SDF）の状態の検査および維持を可能にします。アウトオブプロファイルのフローまたはセッションの計測により、パケットが破棄されたり、ベストエフォート優先度に対する DSCP マーキングが削減されたりする可能性があります。

次の標準規格に基づいて、サブスクライバの PDP コンテキストの承認、認証、およびアカウンティング（AAA）を実行するためのメカニズムを提供します。

Remote Authentication Dial-In User Service（RADIUS）プロトコルは、サブスクライバの PDP コンテキストに AAA 機能を提供するために使用されます（GTPP も使用できるため、RADIUS アカウンティングはオプションです）。

システムに設定されているコンテキスト内に、設定可能な AAA および RADIUS プロトコル固有のパラメータがあります。RADIUS プロトコル固有のパラメータは、RADIUS 認証サーバーと RADIUS アカウンティングサーバーの連携でさらに区別されます。

設定可能な RADIUS パラメータは次のとおりです。

1 つのサーバーが到達不能になった場合、システムは設定されている他のサーバーとの通信を試みます。システムには、すべての RADIUS AAA サーバーが到達不能になった場合の動作を指定する設定可能なパラメータも用意されています。

システムは RADIUS サーバー構成グループをサポートすることで、柔軟性を向上させます。この機能により、通信事業者は PDP コンテキストを促進するために使用される APN に基づいて、サブスクライバの AAA サービスを区別できます。

一般に、システム上でコンテキストあたり 128 の AAA サーバー IP アドレス/ポートを設定でき、サーバー選択アルゴリズム（ラウンドロビン、最初のサーバー）に従ってこのリストからサーバーが選択されます。コンテキストごとにサーバーのリストを 1 つ用意する代わりに、この機能では複数のサーバーグループを設定できます。また、各サーバーグループは、サーバーのリストで構成されます。

この機能は次のように動作します。

APN の設定では、使用する RADIUS サーバーグループだけでなく、アドレスを割り当てる IP アドレスプールを指定できるため、一部のインバンド RADIUS サーバー（通信事業者のネットワークではなく企業のネットワーク内にある RADIUS サーバー）の導入をサポートするメカニズムがシステムに実装されます。このとき、NAS-IP アドレスはサブスクライバプールの一部になります。これらのシナリオでは、P-GW は、RADIUS NAS-IP アドレスとして使用するために、サブスクライバプールの最初の IP アドレスの設定をサポートしています。

重要	StarOS 12.3 以前のリリースを使用している場合、RADIUS AAA 設定の詳細については、『AAA and GTPP Interface Administration and Reference』[英語] を参照してください。StarOS 14.0 以降のリリースを使用している場合は、『AAA Interface Administration and Reference』を参照してください。

StarOS リリース 21.0 より前では、Cisco P-GW および S-GW は、非 3GPP プライベート拡張情報要素（IE）と 3GPP インジケーション IE の両方を介して過課金保護データの送受信をサポートしていました。

ただし、過課金保護データを交換する 3GPP サポートが存在するため、通信事業者は過課金プライベート拡張（OCP）ベースのソリューションを使用していませんでした。また、P-GW によって送信される過課金保護データを伝送するプライベート拡張 IE が、他のベンダーの S-GW での問題につながることが一部の通信事業者によって報告されていました。

その結果、プライベート拡張ベースの過課金機能のサポートが Cisco P-GW および S-GW から削除されています。これには、他のベンダーの P-GW/S-GW で、過課金保護データを伝送するプライベート拡張 ID のデコードが原因により予期しないシナリオが発生するのを防ぐメリットがあります。

P-GW の以前の動作と新しい動作

S-GW の以前の動作と新しい動作

次の表では、プライベート拡張 IE の過課金サポートの削除による、ベアラー変更応答（MBRsp）メッセージの S-GW での以前の動作と新しい動作について説明します。

重要	現在のリリースでは、S-GW は一時停止/課金開始プロシージャのインジケーション IE のみを含む MBReq メッセージを送信します。プライベート拡張 IE は送信されません。

重要	S-GW が CSRsp/MBRsp メッセージで P-GW からプライベート拡張 IE のみを受信する場合、S-GW はプライベート拡張 IE を無視します。その結果、S-GW は、P-GW に対して過課金保護が無効になっていると想定します。したがって、このシナリオでは、S-GW で過課金の条件が満たされている場合でも、S-GW は P-GW に課金一時停止の MBReq メッセージを送信しません。

S-GW 復元機能は、EPC ネットワークで発生した S-GW 障害に対応するのに役立ちます。影響を受けた PDN にサービスを提供する別の S-GW を選択することで、S-GW が原因の障害で影響を受けた PDN を復元できます。これにより、PDN のクリーンアップのためにシグナリングの不要なフラッディングが発生するのを回避できます。

GTP-C シグナリングのリカバリ IE 中にパス障害が検出された場合や S-GW の再起動が検出された場合、P-GW はセッションを維持します。P-GW はこのシナリオでドロップされたパケットが課金されないようにします。また、P-GW は S-GW 障害検出後に維持された PDN 接続で受信したベアラーの追加要求や変更要求を拒否します。これは、PDN が復元されるまで行われます。

MME によってセッションが復元され、P-GW が再起動された S-GW または別の S-GW からベアラー変更要求を受信すると、P-GW は受信したダウンリンクデータの転送を続行し、課金を開始します。

サブスクライバが S-GW 復元フェーズにある場合、すべての RAR（セッション終了を予測）は PCEF を拒否します。P-GW は、PCRF に対して CCR-U をトリガーできる内部更新をすべて拒否します。S-GW が復元時に変更された場合、P-GW は復元された PDN の AN-GW の変更を含む CCR-U をトリガーします。

MME/S4-SGSN は、同じ PLMN の P-GW が S-GW 復元機能をサポートしていることを認識するようにローカルで設定されます。この機能が P-GW で有効になっている場合、すべての S-GW/MME でサポートされます。

重要	MME/S4-SGSN によってトリガーされた S-GW 復元手順のみがサポートされます。 GTP-U パスの障害に基づく S-GW 復元の検出は、このリリースでは考慮されません。この機能を有効にするには、GTP-C パス障害検出を有効にする必要があります。

GTP-U パスの障害に基づく S-GW 復元の検出は、このリリースでは考慮されません。この機能を有効にするには、GTP-C パス障害検出を有効にする必要があります。

P-GW 再起動通知は、ピア P-GW に障害が発生し、再起動していないことを通知するために使用することもできます。この場合、P-GW 再起動通知には「P-GW not responding」という理由値が含まれます。PRN の送信中、S-GW はエコー応答に応じて、この新しい理由値を追加します。

重要	この機能の詳細については、本ガイドの「S-GW 復元サポート」の章を参照してください。

望ましくないスプーフィングや中間者攻撃の可能性を軽減することにより、接続されたサブスクライバ端末と PDN ゲートウェイ間の完全性を確保します。

P-GW には、PDN 単位で UE に IP アドレスを割り当てるためのローカル IPv4/IPv6 アドレスプールが存在します。P-GW は認識しているホストアドレスからのトラフィック受信を保証することで、プロビジョニングされたアドレスのバインディングを保護します。許可されていないホストからトラフィックを受信した場合に備えて、P-GW には許可されていないトラフィックをブロックする機能が組み込まれています。P-GW は IPv4 送信元アドレスを使用して、送信者と IPv6 送信元プレフィックス（IPv6 の場合）を確認します。

この機能は、音声ベアラーの削除時に PCC ルールが非アクティブ化された正確な理由を PCRF に通知するために役立ちます。この正確な理由は、その後に PCRF が適切に追加のアクションを実行するために役立ちます。

この機能により、SRVCC への完全な準拠（音声ベアラーがリリースされたときの PS から CS へのハンドオーバー指示のサポートを含む）が保証されます。SRVCC 機能のサポートは、StarOS リリース 12.2 で最初に追加されました。

LTE の SRVCC サービスは、IMS アンカー音声コールサービスにアクセスする単一の無線ユーザー機器（UE）が LTE ネットワークから回線交換ドメインに切り替わるときに、特定の時点で、その機器が、それらのアクセスネットワークのいずれかでのみ送受信できるようになる場面で登場します。これにより、UE が複数の無線アクセス技術（RAT）機能を備える必要がなくなります。

PS セッションをターゲットにハンドオーバーした後に、送信元 MME は、S-GW/P-GW に対する音声ベアラーを非アクティブ化し、ベアラー削除コマンドメッセージ（TS 29.274 v9.5.0）で Bearer Flags IE に VB（音声ベアラー）フラグを設定することにより、音声ベアラーを削除します。

IP-CAN ベアラーの終了が、PS から CS へのハンドオーバーによって発生する場合、PCEF は、PS_TO_CS_HANDOVER（TS 29.212 v10.2.0 および TS 23.203 v10.3.0）の値に設定された Rule-Failure-Code AVP を含めることによって、この IP-CAN ベアラーに関連する PCC ルールを報告することができます。

課金ルールインストール内の新しい AVP PS-to-CS-Session-Continuity（3GPP リリース 11 で追加）のサポート（PS から CS への連続性のためにベアラーが選択されているかどうかを示す）は、追加されていません。

コールのデバッグ、新しい機能のテスト、そして LTE 環境におけるアクセス端末向けに、3GPP 標準規格に準拠したセッションレベルのトレース機能を提供します。

重要	トレースがプロビジョニングされると、さまざまなシグナリング インターフェイスを介したアクセスクラウドを使用してプロビジョニングできるようになります。

セッションレベルのトレース機能では、トレースのアクティブ化の後にトリガーが実行されます。2 つのイベント間の時間は、合法的傍受と同様に扱われます。このとき、EPC ネットワーク要素はキャッチオンモニタリングを使用して、メモリ内でプロビジョニングされたサブスクライバのトレースアクティベーション命令をバッファリングします。アクティブコールのトレースファイルは、ASR 5500 プラットフォームのローカルデュアル冗長ハードドライブ上の不揮発性メモリを使用して XML ファイルとしてバッファリングされます。トレースの深さにより、トレース対象のデータの精度が定義されます。最大、最小、中を含む 6 つのレベルが定義され、ベンダー拡張機能に基づいて追加のレベルを設定できます。

アクティブなセッションと録音されたセッションに関するすべてのコール制御アクティビティは、FTP またはセキュア FTP（SFTP）接続を介して、標準ベースの XML 形式でオフラインのトレース収集エンティティ（TCE）に送信されます。

パフォーマンス目標：サブスクライバレベルのトレースは CPU に高い負荷がかかるアクティビティであるため、同時にモニターされる Cisco P-GW ごとのトレースセッションの最大数は 32 です。既存のサービスへの影響を最小限に抑えるために、実稼働ネットワークでの使用を制限する必要があります。

3GPP トレース機能は、StarOS リリース 15.0 で強化され、同時トレース数が 1000 に増えました。「プッシュ」モードが有効になっている場合、生成されたトレースファイルは (S)FTP を介して定期的に外部のトレース収集エンティティに転送されます。プッシュモードを使用しない場合、ファイルはローカルハードドライブに保存され、FTP または SFTP を使用して TCE によってプルされる必要があります。

重要	生成されるセッショントレースファイルの数は、使用可能なハードディスクのキャパシティによって制限されます。

お客様のビジネス要件と実稼働予測に基づき StarOS のサポートが強化され、1 つの S-GW で 100 万の S1-U 接続に対応できるようになりました。

S1-U インターフェイスは、端末から受信したユーザーデータを eNodeB と S-GW の間で伝送するユーザー プレーン インターフェイスです。StarOS では、VPN コンテキストごとに S1-U ピアの数を 100 万まで拡張できるようになりました。

通信事業者は追加された新しい CLI コマンドを使用して、統計を収集する S1-U ピアの数を設定できます。StarOS のメモリ制限により、100 万ピア（128k）未満で設定する必要があります。

機能の仕組み

gtpumgr は次のガイドラインに従って、ピアを割り当てます。

• セッションインストールがセッションマネージャから実行されると、ピアが作成されます。統計情報がセッションマネージャで維持管理されている場合、gtpumgr は統計情報を含むピアレコードも作成します。

• ピアレコードはサービス単位で保持されます。

• ピアの数は、gtpumgr インスタンスレベルで維持されます。S1-U ピアの数の上限は gtpumgr インスタンスごとに 100 万です。

• 上限の 100 万ピアを超えると、ピアの作成に失敗します。これにより、gtpumgr ではコールのインストールに失敗し、監査がトリガーされると監査に失敗します。

機能の変更は、GGSN/S4-SGSN/SGW/PGW/SAEGW/ePDG/SaMOG/HNB-GW/HeNB-GW などの gtpu-service を使用する次のインターフェイス/サービスのすべてに影響します。

• General Packet Radio Service（GPRS）の Gn および Gp インターフェイス

• UMTS システムの Iu、Gn、および Gp インターフェイス

• Evolved Packet System（EPS）の S1-U、S2a、S2b、S4、S5、S8、および S12 インターフェイス。

リカバリ/ICSR の考慮事項

• セッションマネージャ/gtpumgr のリカバリ後、または ICSR スイッチオーバー後に、統計情報の収集用に設定された一連のピアが回復されます。

  • セッション数が 0 で統計情報がないピアは回復されません。

  • セッション数が 0 で統計情報があるピアは回復されます。

  • 拡張ヘッダーのサポートが無効になっているピアは回復されます。

• 以前のリリースからアップグレードする場合は、新しいリリースのシャーシ gtpu peer statistics threshold が以前のリリース以上であることを確認してください。これにより、GTPU ピアの統計情報がアップグレード時に保持されます。たとえば、リリース 19.0 から 20.2 にアップグレードする場合、19.0 のシステムに 17,000 の GTPU セッションがある場合は、20.2 のシャーシのしきい値も 17,000 に設定します。

設定/制限事項

• StarOS に接続される GTP-U エンティティの数が多いため、GTP-U パス管理機能を無効にすることを推奨します。

• 分散型のシステムであるため、統計情報の割り当てに関して設定するしきい値に厳しい上限はありません。統計情報を含む GTP-U ピアの合計数が、設定されたしきい値を若干超える可能性があります。

• 100 万個のピアすべてがポイントツーポイントでノードに接続されていないことを前提としています。ピアはルータを介して接続されます。

• StarOS がこの機能をサポートするために ARP のテーブルサイズが変更されることはありません。

重要	この機能は、このリリースでは完全には認定されていません。テスト目的でのみ使用できます。詳細については、シスコのアカウント担当者にお問い合わせください。

通信事業者は、すべてのダウンリンク TCP パケットの実効ウィンドウ サイズを制限できます。この機能を有効にするために、新しい CLI コマンド window-size がルールベース コンフィギュレーション モードに追加されました。

P-GW は、実効ウィンドウサイズが設定されたウィンドウサイズよりも大きい場合、設定された値で TCP パケットを更新します。それ以外の場合、P-GW はパケットのウィンドウサイズを変更しません。

P-GW は（SYN フラグとともに送信される）ウィンドウ スケール オプションを制御できないため、新しく更新されたウィンドウサイズは設定されたウィンドウ サイズと同じではない場合があります。したがって、更新されたウィンドウサイズは、ウィンドウスケールのオプションによって計算された値に最も近い値に丸められます。

非 SYN フローにはウィンドウスケールのオプションがないため、この機能は適用されません。

TCP ウィンドウサイズが有効になっている場合、ルールベースの変更と設定の変更は、新しく作成されたフローと既存のフローの両方に適用されます。これらのフローに対して TCP ウィンドウサイズ機能が有効になっていない場合、変更は適用されません。

（注）	PGW は指定されたルールベースのすべてのダウンリンクパケットを更新するため、設定されたウィンドウサイズがパケット内の実効ウィンドウサイズよりも小さくなり、パフォーマンスに影響が及びます。

システムでのしきい値設定は、エラーや停止を引き起こす可能性のある条件についてシステムをモニターするために使用されます。通常、これらの条件は一時的なものであり（高い CPU 使用率や、ネットワークでのパケットコリジョンなど）、すぐに解決されます。ただし、特定の時間間隔内にこれらのエラー状態が継続的に発生するか多数発生する場合は、より大きく、より重大な問題を示している可能性があります。しきい値設定の目的は、潜在的な重大状態の特定を容易にすることです。これにより、即時に対処して、システムのダウンタイムを最小限に抑えるか回避することが可能になります。

システムは、特定の主要リソース（CPU、メモリ、IP プールアドレスなど）に関するしきい値超過アラートをサポートしています。この機能により、通信事業者は、これらのリソースのしきい値を設定できます。それにより、リソースの枯渇が設定されたしきい値を超えると、SNMP トラップが送信されます。

システムでは、次のしきい値設定モデルがサポートされています。

重要業績評価指標（KPI）では、PDN セッションのアクティブ化および非アクティブ化における成功と失敗が区別されていませんでした。さらに、KPI は Voice-over-LTE（VoLTE）サービスに関する情報を提供しませんでした。

1 秒あたりのセッションイベント（SEPS）KPI は、上記の問題に対処するために実装されました。これらの KPI は、P-GW や ePDG のシグナリング負荷を測定します。さらに、VoLTE コールのセットアップと切断のイベントレートを測定するために、ネットワークにより開始されたセットアップまたはティアダウン KPI が追加されました。これらの測定値を合わせて使用すると、通信事業者が P-GW または ePDG ノードにおいてネットワークを測定および計画する際に役立ちます。

P-GW の場合、S5、S8、S2a、S2b の各インターフェイスで両方のタイプの KPI がサポートされます。また、P-GW では、関連付けられているすべての eHRPD と PMIP サービスで SEPS KPI がサポートされています。

具体的には、次の KPI が導入されました。

1 秒あたりのセッションイベント（SEPS）

1 秒あたりのネットワークが開始したセットアップおよび切断イベント

操作

P-GW と ePDG には、1 秒あたりのセッションイベント KPI と 1 秒あたりのネットワークが開始したセットアップおよび切断イベント KPI の両方のトランザクションレート統計収集用に 8 つのバケットが含まれています。バケットは、設定可能な 1 ～ 20 分のバケット間隔に基づいています。設定された時間間隔中、バケット間隔全体の平均が計算されて保存されます。

最初の 8 バケットの間隔が経過して統計が収集された後、P-GW は 8 バケット間隔で順番に処理を続け、最終的に元の 8 バケット間隔をより新しいデータで上書きします。つまり、8 つのバケット間隔は、KPI が計算された最後の 8 バケット間隔の現行値を提供します。統計は最終的に新しい値で上書きされますが、すべての統計の合計は履歴統計に追加され、上書きされることはありません。

この機能により、スーパーオフピークの請求プランなど、特定のサービス料金について時間ベースの課金が可能になります

UE のタイムゾーンは、UE の場所（トラッキング領域やルーティング領域）に関連付けられています。UE タイムゾーン情報要素は、MME がトラッキングエリアリストに基づいて追跡する属性であり、S11 および、S5 または S8 シグナリングを介して P-GW に伝達されます。

タイムゾーンのレポートは、請求レコードに含めるか、外部 PCRF および OCS サーバーへの Gx または Gy シグナリングで伝達できます。

ユーザー情報変更レポート機能は、GPRS 固有のイベントトリガーと GPRS 固有のクレジット再承認トリガーによって、PCRF を介して GGSN で有効になります。レポートの対象になるユーザー情報には、ロケーション変更レポート（ULI）と Closed Subscriber Group 情報変更レポート（UCI）が含まれます。

GGSN によって要求されたサブスクライバセッションのロケーション変更レポートについては、MS が GERAN、UTRAN、GAN の RAT タイプのいずれかにある場合、SGSN にはユーザロケーション情報（ULI）が含まれます。また、MS がセル、サービス、ルーティングエリアに存在するかに応じて、CGI、SAI、RAI もそれぞれ含まれます。SGSN には、他の RAT タイプのユーザーロケーション情報を必要に応じて含めることができます。

Closed Subscriber Group（CSG）は、CSG のメンバーとして PLMN の 1 つ以上の CSG セルにアクセスできるサブスクライバグループを識別します。CSG ID は PLMN の範囲内にある一意の識別子であり、CSG セルまたは CSG セルのグループに関連付けられた PLMN の CSG を識別します。GGSN によって要求されたサブスクライバセッションの CSG 情報変更レポートについては、MS が CSG セルまたはハイブリッドセル内にある場合、SGSN にはユーザー CSG 情報が含まれます。

リリース 20.0 以降では、PDN（ゼロ以外の TEID や IMSI + NSAPI）を識別するための有効な情報、および適切な ULI や UCI 情報とともに受信した MS 情報の変更通知を処理するための機能が追加されています。MS 情報変更メッセージと NRUPC が競合した場合、GGSN は最初に MS 情報変更要求を処理し、MS 情報変更応答を送信します。その後に、NRUPC が再試行されます。

重要	CSG レポートは、GGSN、P-GW、SAEGW ではまだサポートされていません。

制限事項

仮想 APN は、単一の APN 内におけるサービスの差別化を可能にします。

仮想 APN 機能により、キャリアは単一の APN を使用して差別化されたサービスを設定できます。MME によって提供される APN は、複数の設定可能パラメータを用いて P-GW により評価されます。次に、P-GW は、指定された APN とそれらの設定可能パラメータに基づいて APN 設定を選択します。

重要	詳細については、『Command Line Interface Reference』の「Context Configuration Mode Commands」に記載の virtual-apn preference コマンドを参照してください。

Cisco P-GW は、ネットワーク制御コンテンツフィルタリングとペアレント コントロール サービスの 2 つのバリエーションを提供しています。各アプローチでは、プラットフォームのネイティブの DPI 機能を利用して、HTTP URL または WAP/MMS URI 要求に基づきモバイルサブスクライバから関心を持たれているイベントを検出およびフィルタリングします。

ヘッダーの拡張機能は、アプリケーションサーバーへの HTTP 要求にサブスクライバ固有の情報を含めて、サブスクライバ インテリジェンスを収益化する、付加価値のある機能をモバイル通信事業者に提供します。

拡張ヘッダー（X-Header）フィールドは、特定の目的でプロトコルのヘッダーに追加できるフィールドです。拡張ヘッダーでは、プロトコルを変更せずに追加の entity-header フィールドを定義できますが、entity-header フィールドは受信者が認識できるフィールドとは想定されていません。認識されないヘッダーフィールドは、受信者によって無視されて、トランスペアレントプロキシによって転送される必要があります。

拡張ヘッダーは、HTTP/WSP の GET および POST 要求パケットでサポートできます。P-GW の Enhanced Charging Service（ECS）には、HTTP/WSP GET および POST 要求パケットに x-Header を挿入するための APN ベースの設定とルールが用意されます。ルールに関連付けられた課金アクションには、パケットに挿入される X-Header のリストが含まれます。サポートされているプロトコルは、HTTP、WAP 1.0 および WAP 2.0 の GET メッセージと POST メッセージです。

重要	ECS の詳細については、『ECS Administration Guide』[英語] を参照してください。

挿入された HTTP ヘッダー属性で渡されるデータは、エンド アプリケーション サーバー（アップセルサーバーとも呼ばれる）によって、サブスクライバおよびセッション情報を識別するために使用されます。このサーバーは、その特定のサブスクライバに合わせてカスタマイズされた情報を提供します。

Cisco P-GW は、HTTP ヘッダーに次の情報を含めることができます。

• ユーザーがカスタマイズ可能な任意のテキスト文字列

• サブスクライバの電話番号（クリアテキストの RADIUS calling-station-id）

• サブスクライバの IMSI

• サブスクライバの IP アドレス

• S-GW の IP アドレス（クリアテキスト）

X-Header の暗号化により X-Header の挿入機能が強化されます。サポートされるフィールド数が増えるのに加え、フィールド挿入前の暗号化も可能になります。

WSP ヘッダーに X-Header フィールドを挿入する際、次の制限が適用されます。

• X-Header フィールドは、StarOS v14.0 より前のフラグメント化された IP パケットには挿入されません。

• 連結要求の場合、X-Header フィールドは最初の GET 要求または POST 要求にのみ挿入されます（ルールが同じ要求で一致する場合）。連結要求の 2 番目以降の GET/POST 要求には X-Header フィールドは挿入されません。たとえば、パケットに ACK+GET がある場合、GET パケットに X-Header が挿入されます。ただし、GET1+GET2 がパケット内に存在し、ルールが GET2 で一致し、GET1 で一致しない場合、X-Header は引き続き GET2 に挿入されます。GET+POST の場合も、POST に X-Header は挿入されません。

• CO の場合、WTP パケットが誤った順序で受信された場合でも（適切に順序変更された後でも）X-Header フィールドは挿入されません。

• MMS へのルートが存在する場合、X-Header は挿入されません。

• ヘッダーがセグメント化されている場合、WSP POST パケットに X-Header は挿入されません。POST には、X-Header ヘッダーの追加後に変更が必要なヘッダー長フィールドが含まれているためです。セグメント化された WSP ヘッダーでは、ヘッダー長フィールドが 1 つのパケットに存在し、ヘッダーが別のパケットで完了することがあります。

ヘッダー機能拡張のためのハッシュ値のサポート

ハッシュ値文字列は、ヘッダー機能拡張の一部として実装されます。P-GW は、各サブスクライバの PCRF から受信したハッシュ値を保存するように拡張されています。保存されたハッシュ値は HTTP/WSP ヘッダーに挿入され、通信事業者がサブスクライバプロファイルを処理する際に使用できます。

一部のモバイル広告プラットフォームでは、サブスクライバの MSISDN 値に基づいてハッシュ文字列が生成されます。ハッシュ文字列がコンテンツプロバイダーに送信されると、コンテンツプロバイダーはサブスクライバのプロファイル情報を識別し、ユーザーのプロファイルに基づいてサブスクライバのブラウザに広告を挿入します。

PCRF からハッシュ値を受信するには、データ型がオクテット文字列の新しい AVP の Hash-Value を Gx インターフェイスに実装します。この AVP は、最大 80 文字をサポートします。最大長を超えると、P-GW はハッシュされた文字列を無視します。PCRF から受信したハッシュ値は、サブスクライバの HTTP ヘッダーの機能拡張が有効になっている場合にのみ、HTTP/WSP ヘッダーに挿入されます。

X-Header フィールドは、HTTP/WSP ヘッダーにハッシュ値を挿入するために使用されます。ハッシュ値は、X-Header フィールドの既存の暗号化メカニズムに基づいて暗号化できます。これらのハッシュ値（暗号化されているかどうかにかかわらず）は、課金アクションで設定した X-Header 形式に基づいて HTTP/WSP ヘッダーに挿入されます。

（注）	ハッシュ値には、サブスクライバのセッション情報の一部としてチェックポイントが付けられます。PCRF からハッシュ値が受信されるとすぐにチェックポイントが付けられます。

P-GW は、IP Network Enabler（IPNE）サービスをサポートしています。IPNE は、セッション情報とネットワーク情報を収集して MINE サーバーに配信する、Mobile and IP Network Enabler（MINE）クライアントコンポーネントです。MINE クラウドサービスは、ワイヤレス通信事業者とパートナーがセッションおよびネットワークの情報を共有および交換してインテリジェントなサービスを実現するための、一元化されたポータルを提供します。IPNE の詳細については、このガイドの「IP Network Enabler」の章を参照してください。

NAT では、ルーティング不可能なプライベート IP アドレスが、NAT 用に指定されているパブリック IP アドレスのプールからのルーティング可能なパブリック IP アドレスに変換されます。この変換により、外部ネットワークとの通信に必要なパブリック IP アドレスの数を節約でき、内部ネットワークの IP アドレススキームが外部ホストからマスクされ、各送受信パケットがこの変換プロセスを通過するため、セキュリティが保証されます。

NAT は、着信と発信両方の IP データグラムを検査し、必要に応じて、発信データグラム用に設定された NAT アドレスマッピングを反映するように IP ヘッダーの送信元 IP アドレスとポート番号を変更することによって機能します。逆 NAT 変換は着信データグラムに適用されます。

NAT は、簡易 IP とモバイル IP のアドレス変換を実行するために使用できます。NAT は、フローの L3/L4 の特性（送信元 IP、送信元ポート、接続先 IP、接続先ポート、およびプロトコル）に基づいて、サブスクライバから発信されるさまざまなフロー（5 タプル接続）に選択的に適用したり、適用を拒否したりすることができます。

NAT は次のマッピングをサポートしています。

重要	NAT の詳細については、『NAT Administration Guide』[英語] を参照してください。

通信事業者はネットワーク内の P2P トラフィックを識別し、適切な制御機能を適用して、すべてのサブスクライバに帯域幅を公平に分配できます。

ピアツーピア（P2P）とは、2 つのわずかに異なるコンテキストで使用される用語です。機能レベルでは、クライアントサーバー方式とは対照的に、ピアリング方式で対話するプロトコルを意味します。ノードの機能の間に明確な区別はありません。どのノードもクライアント、サーバー、またはその両方として機能できます。プロトコルはこの 2 つを明確に区別しない場合があります。たとえば、ピアリング交換には、クライアントとサーバーの機能や情報の送受信が同時に含まれることがあります。

ピアツーピアプロトコルを検出するには、プロトコルを一意に識別する特性をリアルタイムで認識する必要があります。一般的なパケット分類では、特定のプロトコルを実行しているパケットストリームのヘッダーに入力された一意の情報のみを識別する必要があります。実際、多くのピアツーピアプロトコルは、単純なパケット ヘッダー インスペクションで検出できます。ただし、一部の P2P プロトコルは異なるため、従来の方法では検出できません。これは、意図的に検出を回避するために一部の P2P プロトコルに組み込まれています。これらのプロトコルの作成者は、意図的に仕様を公開しません。スモールクラスの P2P プロトコルはよりステルス性が高く、検出がより困難になります。一部のプロトコルでは、固定マーカーのセットをプロトコル固有のものとして確実に識別できません。

通信事業者は、一部の P2P アプリケーション（Bittorrent、Skype、eDonkey など）の動作のために P2P トラフィックについて注意を払う必要があります。ほとんどの P2P アプリケーションは、20% の P2P ユーザーが残りの 80% の非 P2P ユーザーと同等の量のトラフィックを生成できるように、ネットワーク帯域幅を占有できます。これにより、P2P ユーザーが帯域幅を過剰に使用するため、非 P2P ユーザーが正当に使用するための十分なネットワーク帯域幅を取得できない状況が発生する可能性があります。通信事業者はネットワーク帯域幅やトラフィックを動的に管理する機能を配置し、すべてのユーザー間でネットワーク帯域幅を公平に分配する必要があります。これには、ネットワーク内の P2P トラフィックを識別し、適切な制御機能を適用することが含まれます（コンテンツベースのプレミアム課金、QoS の変更、その他の同様の処理など）。

シスコの P2P 検出テクノロジーでは、革新的で高精度なプロトコル動作検出技術が活用されています。

重要	ピアツーピア検出の詳細については、『ADC Administration Guide』を参照してください。

パーソナル ステートフル ファイアウォールは、サブスクライバトラフィックを検査し、個々のサブスクライバセッションに対する IP セッションベースのアクセス制御を実行するインラインサービス機能で、サブスクライバを悪意のあるセキュリティ攻撃から保護します。

パーソナル ステートフル ファイアウォールは、設定に基づくステートレスおよびステートフル インスペクションとフィルタリングをサポートします。

ステートレス インスペクションでは、ファイアウォールがパケットを検査して、パケットに含まれる 5 タプル（送信元および宛先 IP アドレスとポート、およびプロトコル情報）を判定します。この静的情報を設定可能なルールと比較して、パケットを許可するかドロップするかを決定します。ステートレス インスペクションでは、ファイアウォールは各パケットを個別に検査します。その前に通過したパケットを認識せず、特定のパケットが既存の接続の一部であるか、新しい接続を確立しようとしているか、または不正なパケットであるかは一切把握できません。

ステートフル インスペクションでは、ファイアウォールがアプリケーション レイヤ/レイヤ 7 までパケットを検査して、パケットのヘッダー情報とデータコンテンツを確認するだけでなく、接続の状態をモニターし追跡を継続します。ファイアウォールを経由するすべてのアクティブな接続について、状態情報（関連する IP アドレスとポート、接続を通過するパケットのシーケンス番号と確認応答番号、TCP パケットフラグなどを含む）が状態テーブルで維持されます。フィルタリングの決定は、ルールだけでなく、該当する接続での先行パケットによって確立された接続状態にも基づいています。この仕様により、さまざまな DoS、DDoS、およびその他のセキュリティ違反を防止することができます。接続が切断されるか、タイムアウトになると、状態テーブルのエントリは破棄されます。

Enhanced Charging Service（ECS）/Active Charging Service（ACS）インラインサービスは、パケット検査および課金を実行するための主な手段です。ECS の詳細については、『ECS Administration Guide』[英語] を参照してください。

重要	パーソナル ステートフル ファイアウォールの詳細については、『PSF Administration Guide』[英語] を参照してください。

ePDG と P-GW により、3GPP リリース 13 に従って、P-GW の信頼できない Wi-Fi を介した緊急通話の確立がサポートされます。IMS 緊急セッションをサポートするために緊急ベアラーサービスが提供されます。緊急ベアラーサービスとは、緊急サービスをサポートするようにネットワークが設定されている場合に、サービスを提供しているネットワークによって提供される機能を指します。緊急ベアラーサービスは、通常どおりにアタッチされた UE のほかに、現地の規制に応じてサービスが制限されている UE に提供されます。限定的なサービス状態での緊急サービスの受信には、サブスクリプションは不要です。

Diameter への認証承認要求（AAA）が、信頼できない Wi-Fi 緊急通話用の新しい Emergency-Indication AVP を伝送するようになりました。緊急サービス用の PDN 接続に関連する Diameter 要求が最も優先されます。地域/国の要件やネットワーク通信事業者のポリシーに応じて、これらの Diameter 要求は、3GPP AAA サーバーでトラフィックの削減を適用する必要がある場合に最後にスロットルされます。詳細については、「ePDG および P-GW での 3GPP R13 緊急コールのサポート」の項を参照してください。

この機能を使用するには、有効なライセンスキーがインストールされている必要があります。ライセンスの入手方法の詳細については、シスコのアカウントまたはサポート担当者にお問い合わせください。

現在 DHCP サーバーでは、割り当てられた IPv6（/64）プレフィックスを特定のサブスクライバに関連付けるメカニズムが DHCPv6 に実装されていません。この機能は、PDN 接続の設定時に、AAA サーバーから割り当てられたデフォルトのプレフィックスを、外部 DHCPv6 サーバーから割り当てられた委任済みプレフィックスに関連付けます。

DHCP クライアントプロファイルのコンフィギュレーション モードには、委任済みプレフィックスの設定時に、P-GW から外部 DHCPv6 サーバーに DHCPv6 メッセージの USER_CLASS_OPTION を送信するためのオプションがあります。

以前は、P-GW で遅延耐性または優先順位の低いデバイスからのシグナリングトラフィック（優先順位の低いマシン間トラフィックなど）が区別されませんでした。

UE は、NAS や接続要求メッセージを介して MME にデバイスプロファイルを示すことができました。MME は、S5 インターフェイスのシグナリング優先順位表示情報要素（IE）を介して、この情報を P-GW に渡すことができました。一部の UE は、P-GW への S5 インターフェイスでのシグナリング優先順位表示 IE の提供をサポートしていなかった可能性があります。その結果、P-GW はシグナリングタイプを区別できませんでした。現在のリリースでは、P-GW はこれらのシグナリングタイプを区別できます。

また、過負荷状態のとき、P-GW は LAP デバイスからの新しいセッションを許可し、Low Access Priority Indicator（LAPI）デバイスからのトラフィックを通常の UE と同じ優先順位で処理していました。現在の StarOS リリースでは、過負荷状態のときに、P-GW が LAPI として識別されたトラフィックをバックオフするように設定できます。APN 設定またはシグナリング優先順位表示 IE のいずれかに基づいて、この識別が行われます。

バックオフ タイマー アルゴリズムと R12 GTP-C 負荷/過負荷制御アルゴリズムが連携するようになりました。この機能のメリットは、優先順位の低いコールが拒否されることです。その結果、優先順位の高いコールの帯域幅を増やすことができます。

詳細については、本ガイドの「APN バックオフタイマーのサポート」の章を参照してください。

eMPS セッション/メッセージのバルク統計が追加されました。

ピギーバックメッセージ

ピギーバックメッセージの場合、いずれかのメッセージが一致する ARP を含む場合、または最終的に非 eMPS セッションが eMPS セッションに変換される場合、両方のメッセージが eMPS メッセージとしてカウントされ、両方のメッセージに対応する統計が増分されます。

ベアラー変更要求が S-GW の S11 インターフェイスでベアラー作成応答と共にピギーバックされ、ベアラー作成応答が最終的に非 eMPS セッションから eMPS セッションに変換される場合、ベアラー変更応答の統計は増分されません。

バルク統計の収集とリセット

バルク統計は、eGTP-C スキーマと pgw-egtpc-s5s8 スキーマに追加されます。eGTP-C スキーマおよび pgw-egtpc-s5s8 スキーマのこれらの eMPS バルク統計は、次のバルク統計までの間のみ値を保持します。つまり、これらのバルク統計の値は、次のバルク統計までに交換された eMPS メッセージの数を示します。

詳細については、「ARP 値別の GTP-C メッセージのバルク統計」の項を参照してください。

共通ゲートウェイアクセスのサポートは、HA、P-GW、および GGSN の論理サービスをサポートする共通ゲートウェイに 3G および 4G アクセステクノロジーを組み合わせた統合ソリューションであり、利用可能なアクセステクノロジーに関係なく、同じユーザーエクスペリエンスを得ることができます。

現代のシナリオでは、オペレータは、複数のアクセスネットワーク（CDMA、eHRPD、LTE）に加えて、国際ローミングのための GSM/UMTS ソリューションを用意する必要があります。そのため、オペレータは、アクセステクノロジー（3G または 4G）に関係なく、同じ IP アドレッシング動作でサービスにアクセスし、共通の出力インターフェイスセットを使用できるようにするソリューションを必要としています。

このソリューションにより、静的なお客様は、接続のタイプ（CDMA、eHRPD/LTE、または GSM/UMTS）に関係なく、ワイヤレスデータに割り当てられた同じ IP アドレッシング空間でネットワークサービスにアクセスできます。静的 IP アドレッシングを使用するサブスクライバは、アクセステクノロジーに関係なく、同じ IP アドレスを取得できます。

ダイナミック RADIUS 拡張機能（CoA および PoD）を使用するには、有効なライセンスキーがインストールされている必要があります。ライセンスの入手方法の詳細については、シスコのアカウント担当者にお問い合わせください。

ダイナミック RADIUS 拡張機能のサポートにより、データトラフィックを動的にリダイレクトしたり、PDP コンテキストを切断したりする機能が提供され、通信事業者はサブスクライバの PDP コンテキストのより詳細な制御が可能になります。

この機能は、RFC 3576「Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)」（2003 年 7 月）標準に基づいています。

上記の拡張機能を使用して、プロビジョニングやアカウントのセットアップなどの機能を実行するために、サブスクライバの PDP コンテキストを代替アドレスに動的にリダイレクトできます。この機能は、セッションリダイレクト、またはホットラインと呼ばれます。

セッションリダイレクトは、既存または新しいサブスクライバセッションのトラフィックに ACL ルールを適用することにより、サブスクライバのトラフィックを外部サーバーにリダイレクトする手段を提供します。サブスクライバからの TCP/IP または UDP/IP パケットの宛先アドレスと宛先ポート（オプション）が書き換えられ、パケットが指定のリダイレクトアドレスに転送されます。

サブスクライバに戻るトラフィックでは、送信元アドレスとポートが元の値に書き換えられます。リダイレクト ACL は、RADIUS 認可変更（CoA）拡張機能によって動的に適用されます。

重要	ダイナミック RADIUS 拡張機能のサポートの詳細については、このガイドの「CoA、RADIUS DM、セッションのリダイレクト（ホットライン）」の章を参照してください。

National Security/Emergency Preparedness（NS/EP）Next Generation Network（NGN）Priority Services（NGN-PS）（旧称 NGN Government Emergency Telecommunications Service（GETS））とは、パブリックパケット交換サービスプロバイダーから利用可能なサービスに基づく一連の音声、動画、およびデータのサービスです。NS/EP NGN-PS は、サービスユーザーの NS/EP 通信に関する優先処理を提供するものであり、サービスプロバイダーのネットワークで、輻輳を原因とする障害が発生したり、自然災害（洪水、地震、ハリケーンなど）による損傷が発生したり、人為的な災害（物理攻撃、サイバー攻撃、または他の形態のテロ攻撃など）が発生したりした場合に特に必要です。

eMPS セッションに属する制御メッセージ、または eMPS プロファイルに関連付けられている割り当ておよび保持プライオリティ（ARP）を含む制御メッセージの場合、DSCP マーキングは eMPS プロファイルで設定された DSCP 値に基づいています。

この機能拡張の一部として、Government Industry Requirements（GIR）NS/EP NGN で定義されている優先処理のために、P-GW および S-GW で特定の GTP-C メッセージをマーキングするためのサポートも追加されています。詳細については、「VoLTE/緊急コールの拡張優先順位付け」を参照してください。

この機能の目的は、PGW が通信事業者の PCO で ePDG の IP アドレスを送信できるようにして、Wi-Fi ネットワークへの接続時に UE が地理的に最も近い ePDG に接続されるようにすることです。これにより、最も近い ePDG への IPSEC トンネルのセットアップが容易になり、VoWIFI やその他の機能の遅延が減少します。

ネットワーク内の PCO オプションをカスタマイズするために、新しい CLI が導入されました。

重要	これはライセンスで制御される機能です。ライセンスの詳細については、シスコのアカウント担当者またはサポート担当者にお問い合わせください。

重要	ePDG PCO は、S5-S8 インターフェイスで受信される CS 要求に対してのみサポートされます。この機能は、GGSN コールには適用されません。

この機能の詳細については、本ガイドの「PCO を使用した ePDG の選択」の 章を参照してください。

GRE インターフェイス トンネリングを使用するには、有効なライセンスキーがインストールされている必要があります。ライセンスの入手方法の詳細については、シスコの営業またはサポート担当者にお問い合わせください。

P-GW は、RFC 2784：Generic Routing Encapsulation（GRE）に従って、GRE 汎用トンネルインターフェイスをサポートします。GRE プロトコルにより、モバイルユーザーは、GRE トンネルを介して企業ネットワークに接続できます。

企業顧客は、GRE トンネルを使用して、1）APN に対応する AAA パケットを、GRE トンネルを介して企業 AAA サーバーに転送し、2）企業サブスクライバパケットを、GRE トンネルを介して企業ゲートウェイに転送することができます。

企業サーバーはプライベート IP アドレスを持つことができるため、異なる企業に属するアドレスが重複する可能性があります。各企業は、「VRF」と呼ばれる一意の仮想ルーティングドメイン内に存在する必要があります。同じローカルエンドとリモートエンドのセット間のトンネルを区別するために、GRE キーが区別要因として使用されます。

GRE トンネリングは、単一プロトコルバックボーン上でマルチプロトコル ローカル ネットワークを有効にし、非隣接ネットワークを接続して、WAN 間の仮想プライベートネットワークを有効にするための一般的な手法です。このメカニズムでは、別のプロトコル内の 1 つのプロトコルからのデータパケットをカプセル化し、外部ネットワークでデータパケットを変更せずに転送します。（IPsec などのように）暗号化が含まれていないため、GRE トンネリングでは、カプセル化されたプロトコルが保護されないことに注意してください。

重要	GRE プロトコルインターフェイスのサポートの詳細については、このガイドの「GRE プロトコルインターフェイス」の章を参照してください。

S2a インターフェイスは、SAEGW のスタンドアロン P-GW と P-GW を eHRPD の HSGW に接続します。

GTP ベース S2a インターフェイスのサポートは、P-GW および SAEGW で利用できます。WLAN が通信事業者によって信頼されていると見なされると、信頼できる WLAN アクセスネットワーク（TWAN）が、P-GW への S2a インターフェイスを介して、信頼できる非 3GPP アクセスとして EPC とインターフェイス接続されます。SAEGW サービスの Make と Break を使用して、Wi-Fi から LTE へのハンドオーバーのサポートが拡張されました。マルチ PDN ハンドオーバーも、この機能の一部としてサポートされています。

SAEGW に展開している通信事業者は、この機能を使用して信頼できる Wi-Fi ネットワーク機能を統合できるようになりました。

以下のような機能がサポートされています。

• 初回アタッチ

• Wi-Fi から LTE へのハンドオーバー

• LTE から WiFi へのハンドオーバー

• マルチ PDN ハンドオーバー

Wi-Fi 統合機能を使用するには、有効なライセンスキーがインストールされている必要があります。ライセンスの入手方法の詳細については、シスコの営業またはサポート担当者にお問い合わせください。

このセクションでは、P-GW での GTP ベース S2b インターフェイスの導入について説明します。S2b インターフェイスでは、P-GW が ePDG に接続されます。UE は、ホームネットワークが同時接続をサポートしている場合にのみ、異なるアクセスネットワーク経由で異なる APN への同時接続を試みます。UE は、APN 単位のシステム間ルーティングポリシーでプロビジョニングされているか、このポリシーを受信済みの場合に、ネットワークが複数のアクセスでのこのような同時接続をサポートしていると判断します。したがって、UE は、複数のアクセスタイプによる個別の PDN 接続を確立できます。サポートされるアクセスタイプは 4G と Wi-Fi です。

S2b インターフェイスの導入では、次の要素がサポートされます。

重要	Wi-Fi 統合機能の詳細については、このガイドの「P-GW および SAEGW での GTP ベース S2b インターフェイスのサポート」の章を参照してください。

GTP および Diameter インターフェイス スロットリングを使用するには、有効なライセンスキーがインストールされている必要があります。ライセンスの入手方法の詳細については、シスコのアカウント担当者にお問い合わせください。

この機能は、P-GW と GGSN での着信および発信メッセージのレートを制御するのに役立ちます。これは、P-GW と GGSN が GTP 制御プランのメッセージによって過負荷にならないようにするのに役立ちます。さらに、P-GW と GGSN が、GTP コントロール プレーン メッセージでピア GTP-C ピアを過負荷にしないようにするのに役立ちます。

この機能を使用するには、Gn または Gp インターフェイスおよび S5 または S8 インターフェイスを介した GTP（v1 および v2）制御メッセージのシェーピングおよびポリシングが必要です。この機能は、P-GW および GGSN ノードとそれが通信する他の外部ノードの過負荷保護を行います。スロットリングは、セッションレベルの制御メッセージに対してのみ実行されます。パス管理メッセージはレート制限されません。

外部ノードの過負荷は、P-GW または GGSN が他のノードで処理できるレートよりも高いレートでシグナリング要求を生成するシナリオで発生する可能性があります。受信メッセージレートが、設定されたメッセージレートよりも高い場合、余分なメッセージが通知なしにドロップされます。また、実際のコールセットアップレートが、設定されたメッセージレートよりも低くなる可能性もあります。これは、低速なピアノードや SM の過負荷といった多くの理由により、セッションのセットアップが遅延している場合に発生する可能性があります。さらに、このスロットリングの一部として実行されるドロップはどこにも通知されないため、非エコーメッセージがパス障害であると設定されている場合、パス障害と見なされる可能性があります。

P-GW または GGSN 制御シグナリングにより外部ノードが過負荷にならないよう保護するために、フレームワークを使用して、外部インターフェイスへのアウトバウンド制御メッセージのシェーピングおよびポリシングを処理します。

P-CSCF 復元を使用するには、有効なライセンスキーがインストールされている必要があります。ライセンスの入手方法の詳細については、シスコのアカウントまたはサポート担当者にお問い合わせください。

重要	この機能の詳細については、このガイドの「HSS および PCRF ベースの P-CSCF 復元のサポート」の章を参照してください。

シャーシ間セッションリカバリを使用するには、有効なライセンスキーがインストールされている必要があります。ライセンスの入手方法の詳細については、シスコの営業またはサポート担当者にお問い合わせください。

ASR 5500 は、業界をリードするキャリアクラスの冗長性を実現します。システムは、すべてのシングルポイント障害（ハードウェアおよびソフトウェア）から保護され、複数の障害が同時に発生した場合、動作状態を回復しようとします。

シスコはこれら 2 つのスキームによる優れたシャーシ内冗長性を提供していますが、IP ルーティングの障害、ライン切断、電力損失、シャーシの物理的破壊など、シャーシ全体の停止を引き起こす可能性のある特定の致命的な障害をこの方法で保護することはできません。こうした状況では、MME シャーシ間セッションリカバリ機能がサイト間の地理的冗長性を提供します。この機能には、致命的な障害が発生してもサブスクライバのエクスペリエンスが向上するという利点がありますが、RAN などの他のシステムをサブスクライバの再アクティブ化ストームから保護することも可能にします。

シャーシ間セッションリカバリ機能は、サブスクライバのサービスを中断することなく継続的なコール処理を可能にします。回復は冗長シャーシを使用して達成されます。シャーシはプライマリとバックアップとして設定されます。1 つはアクティブで、もう 1 つはリカバリモードになります。チェックポイントの期間タイマーは、アクティブシャーシから非アクティブシャーシにサブスクライバデータが送信されるタイミングの制御に使用されます。コールトラフィックを処理しているアクティブシャーシがサービス停止になると、非アクティブシャーシはアクティブ状態に移行し、サブスクライバセッションを中断せずにコールトラフィックの処理を続行します。シャーシは、冗長性リンクと呼ばれる適切な TCP ベースの接続を介して、どちらがアクティブであるかを判別します。このリンクは、プライマリシャーシとバックアップシャーシの間で Hello メッセージを交換するために使用されるもので、適切なシステム運用のために維持する必要があります。

ネットワーク ドメイン セキュリティを使用するには、有効なライセンスキーがインストールされている必要があります。ライセンスの入手方法の詳細については、シスコの営業またはサポート担当者にお問い合わせください。

IPSec 暗号化により、すべての IP パケット交換 LTE-EPC ネットワークでドメイン セキュリティが可能になり、機密性、整合性、認証、およびアンチリプレイ保護を提供できるようになります。これらの機能は、暗号技術によって守られます。

Cisco P-GW は、IPv4 アドレッシングを使用した IKEv1 および IPSec 暗号化をサポートしています。IPSec により、次の 2 つのユースケースを実現できます。

この機能により、RADIUS サーバーまたは GGSN/P-GW/SAEGW で設定されたローカルプールから DHCPv6 プレフィックス委任を取得するためのサポートが追加されます。RADIUS サーバーからのインターフェイス ID の割り当てもこの機能でサポートされています。

ユーザー機器（UE）または顧客宅内機器（CPE）がプレフィックス委任を要求します。次に、P-GW または GGSN は、RADIUS サーバーまたはローカルプールからこのプレフィックスを取得します。P-GW と GGSN は、RADIUS サーバーまたはローカルプールのいずれかから取得されたプレフィックスを UE クライアントまたは CPE にアドバタイズします。

重要	IPv6 プレフィックス委任の詳細については、「RADIUS サーバーおよびローカルプールからの IPv6 プレフィクスの委任」を参照してください。

L2TP LAC を使用するには、有効なライセンスキーがインストールされている必要があります。ライセンスの入手方法の詳細については、シスコの営業またはサポート担当者にお問い合わせください。

レイヤ 2 トンネリング プロトコル アクセス コンセントレータ（LAC）として設定されたシステムでは、L2TP ネットワークサーバー（LNS）との通信が可能になり、オペレータとサブスクライバの社内ネットワークまたはホームネットワークとの間にセキュアな仮想プライベートネットワーク（VPN）トンネルを確立できます。

VPN ネットワークでの L2TP の使用は、企業が認証と IP アドレスの割り当てをより詳細に制御できるようにするために頻繁に使用されます。オペレータは最初のレベルの認証を実行できますが、ユーザー名とパスワードの交換には PPP を使用し、アドレスの要求には IPCP を使用する場合があります。P-GW と企業間の PPP ネゴシエーションをサポートするには、LAC サービスを実行している P-GW で L2TP トンネルをセットアップする必要があります。

L2TP は、サブスクライバの PPP 接続を L2TP セッションとしてトンネリングする前に、LAC と LNS の間に L2TP 制御トンネルを確立します。LAC サービスは、P-GW と同じアーキテクチャに基づいており、動的なリソースの割り当て、メッセージとデータの分散処理のメリットを利用できます。

また、LAC セッションを冗長に設定することで、ハードウェアまたはソフトウェアの問題の影響を軽減することもできます。トンネル状態は、プロセッサカード間で情報をコピーすることによって保持されます。

重要	この機能のサポートに関する詳細については、本ガイドの「L2TP アクセスコンセントレータ」の章を参照してください。

P-GW の合法的傍受機能の使用ライセンスは、P-GW セッション使用ライセンスに含まれています。

シスコの合法的傍受機能は、P-GW でサポートされています。合法的傍受は、ライセンス対応の標準ベースの機能であり、法執行機関が疑わしい個人の潜在的な違法行為を監視するのを支援するメカニズムを、電気通信サービスプロバイダーに提供します。合法的傍受機能の詳細とマニュアルについては、シスコのアカウント担当者にお問い合わせください。

レイヤ 2 トラフィック管理を使用するには、有効なライセンスキーがインストールされている必要があります。ライセンスの入手方法の詳細については、シスコの営業またはサポート担当者にお問い合わせください。

仮想 LAN（VLAN）は、コンテキストおよびサービスの設定と使用の柔軟性を高めます。

VLAN はポートごとに「タグ」として設定され、より複雑な設定を実装することができます。VLAN タグを使用すると、1 つの物理ポートを複数の論理インターフェイスにバインドして、それぞれを異なるコンテキストに設定できます。したがって、VLAN タグが使用されている場合、各イーサネットポートに多くの論理ポートが含まれているように表示されることがあります。

重要	VLAN のサポートの詳細については、『System Administration Guide』の「VLANs」の章を参照してください。

ローカルポリシー意思決定エンジンを使用するには、有効なライセンスキーがインストールされている必要があります。ライセンスの入手方法の詳細については、シスコの営業またはサポート担当者にお問い合わせください。

ローカルポリシーエンジンは、Gx と同様な QoS とポリシー制御を提供するイベント駆動型のルールエンジンであり、ユーザーまたはアプリケーションの権限付与を可能にします。名前が示すように、通信事業者が PCRF を使用しないことを選択した場合、または外部 PCRF への接続が中断されたシナリオの場合に、PCRF のサブセットを提供するように設計されています。ローカルポリシーは、QoS、データ使用量、サブスクリプション プロファイル、サーバー使用量など、セッションのさまざまな側面をローカルに定義されたポリシーに従って制御するために使用されます。P-GW システムでは、最大 1,024 のローカルポリシーをプロビジョニングできます。

ローカルポリシーは、特定のイベントが発生したり、関連する条件が満たされたりした場合にトリガーされます。たとえば、新しいコールが開始されたときに、コールに適用される QoS は、IMSI、電話番号、および APN に基づいて決定できます。

重要	ローカルポリシー意思決定エンジンの設定の詳細については、このガイドの「PDN ゲートウェイの設定」の章の「ローカル QoS ポリシーの設定」を参照してください。

P-GW サービスでは、課金 ID、課金 FQDN または課金ゲートウェイアドレス、および MSISDN をベアラー変更応答に含めるための設定可能なパラメータが提供されます。S-GW の再配置や GnGp から LTE へのハンドオーバーといったシナリオとは無関係に、CLI が有効になっている場合には、すべてのベアラー変更応答メッセージでこれらのパラメータが送信されます。この機能はライセンス制御されておらず、CLI を使用して動作が制御されます。

この機能の詳細については、このガイドの「制御されたパラメータを使用したベアラー変更応答」の章を参照してください。

MPLS を使用するには、有効なライセンスキーがインストールされている必要があります。ライセンスの入手方法の詳細については、シスコの営業またはサポート担当者にお問い合わせください。

マルチ プロトコル ラベル スイッチング（MPLS）とは、利用可能なネットワークパスをより有効に利用することで、ネットワークのトラフィックのフローを高速化するために使用される操作スキームまたはメカニズムです。BGP や OSPF などのルーティングプロトコルと連携して動作するので、ルーティングプロトコルではありません。

MPLS は固定長のラベルを生成し、IP パケットのヘッダーに付加またはバインドして、データのフローおよび宛先を制御します。IP パケットへのラベルのバインドは、Label Distribution Protocol（LDP; ラベル配布プロトコル）によって行われます。転送等価クラス（FEC）内のすべてのパケットは、MPLS ノードとも呼ばれるラベルスイッチングルータ（LSR）によって転送されます。LSR は ラベルスイッチングパス（LSP）の確立のために、LDP を使用して転送先ネイバーに信号を送り、ラベルを配布します。

展開されると、MPLS バックボーンは、IP パケットにバインドされたラベルを使用して自動的にルートをネゴシエートします。LSR である Cisco P-GW は、接続されたプロバイダーエッジ（PE）からデフォルトルートを学習し、PE は P-GW によって提供されるルートをルーティングテーブルに入力します。

重要	MPLS のサポートの詳細については、このガイドの「マルチプロトコル ラベル スイッチング（MPLS）のサポート」の章を参照してください。

NEMO を使用するには、有効なライセンスキーがインストールされている必要があります。ライセンスの入手方法の詳細については、シスコの営業またはサポート担当者にお問い合わせください。

P-GW は、ネットワークモビリティ（NEMO）サービスを有効または無効にするように設定できます。

有効にすると、システムには、P-GW プラットフォームにおけるモバイル IPv4 ネットワークモビリティ（NEMO-HA）の NEMO サポートが含まれ、エンタープライズ PDN に接続するモバイルルータ（MR）からのモバイル IPv4 ベースの NEMO 接続が終端されます。NEMO 機能により、MR の背後にいるユーザーと固定ネットワークサイト上のユーザーまたはリソース間で、アプリケーションに依存しない双方向の通信が可能になります。

同じ NEMO4G-HA サービスとそのバインドされたループバック IP アドレスが、 NEMO 接続をサポートします。NEMO 接続の基盤となる PDN 接続は、GTP S5（4G アクセス）または PMIPv6 S2a（eHRPD アクセス）を介して行われます。

重要	NEMO サポートの詳細については、このガイドの「 ネットワークモビリティ（NEMO）」の章を参照してください。

NPLI を使用するには、有効なライセンスキーがインストールされている必要があります。ライセンスの入手方法の詳細については、シスコのアカウントまたはサポート担当者にお問い合わせください。

この機能により、P-GW は、3GPP-User-Location-Info AVP、User-Location-Info-Time AVP（使用可能な場合）、および/または 3GPP-MS-TimeZone AVP（PCRF によって要求される場合）内の PCRF に必要なアクセスネットワーク情報を提供できます。P-GW は、Event-Trigger AVP 内の ACCESS_NETWORK_INFO_REPORT イベントトリガーも提供します。

ベアラーの非クティブ化または UE 切断手順中に、P-GW は、3GPP-User-Location-Info AVP 内の PCRF へのアクセスネットワーク情報と、User-Location-Info-Time AVP 内のその位置で UE が最後に認識された日時に関する情報を提供します。PCRF が Required-Access-Info AVP の一部としてユーザー位置情報を要求しており、その情報が P-GW にない場合、P-GW は、3GPP-SGSN-MCC-MNC AVP 内のサービング PLMN 識別子を提供します。

以前は、P-GW は、値が変更された場合にのみ ULI/MS-TimeZone/PLMN-ID を ECS/IMSA/PCRF に通知していました。この機能により、値が変更されたかどうかに関係なく、P-GW は ECS によって送信されたルールで NetLoc 通知を受信し、これを ECS/IMSA/PCRF に送信します。P-GW は NetLoc を「1」と受信すると、MS-Timezone に通知します。P-GW は NetLoc を「0」と受信すると、ULI および ULI タイムスタンプを通知します。このケースで ULI が使用できない場合は、PLMN-ID が送信されます。更新の NetLoc 通知を受信した場合、P-GW は RetLoc Indication フラグを使用して、この情報を UBReq でアクセス側に示します。

これは VoLTE に必要であり、IMS ドメインの課金および LI 機能を支援します。この機能により、EPC コアはサブスクライバの ULI およびタイムゾーン情報を IMS コアネットワークに報告する効率的な方法をサポートできます。

古いセッションに対して新しいコールポリシーを使用するには、有効なライセンスキーがインストールされている必要があります。ライセンスの入手方法の詳細については、シスコのアカウントまたはサポート担当者にお問い合わせください。

新しいコールポリシーが reject release-existing-session に設定され、セッション作成要求で受信した IMSI/IMEI の既存のセッションがある場合、それらは削除されます。これにより、新しいコール ポリシーでリリース拒否が設定されていてもノードでセッションがハングしません。GGSN/P-GW/SAEGW/S-GW が既存のコールをリリースすると、アカウンティング終了の送信、PCRF/OCS への CCR-T の送信、CDR の生成という適切なリリースプロセスに従います。

（注）	reject release-existing-session CLI は、S-GW や P-GW サービス中に緊急 APN コールで接続されたサブスクライバをサポートしません。

非標準 QCI を使用するには、有効なライセンスキーがインストールされている必要があります。ライセンスの入手方法の詳細については、シスコのアカウントまたはサポート担当者にお問い合わせください。

通常、GGSN/P-GW/SAEGW/S-GW/ePDG では、1 ～ 9 の標準ベース QCI 値のみがサポートされます。3GPP リリース 8 以降では、通信事業者固有/非標準の QCI が P-GW/GGSN（スタンドアロン GGSN ではない）でサポートされ、キャリアは QCI 128-254 を定義して、キャリアがネットワーク内のエンドユーザーに提供するさまざまなサービス/アプリケーションを区別できます。

重要	非標準 QCI のサポートの詳細については、このガイドの「拡張 QCI のオプション」の章を参照してください。

この機能により、IMS ネットワークは WLAN アクセスネットワークから UE の位置情報を取得できます。これにより、通信事業者のための位置関連の機能が向上します。この機能は、位置情報に基づいてサブスクライバに課金する場合にも有用です。

LTE NetLoc は以前のリリースからすでサポートされていることに注意してください。このリリースでは、NetLoc のサポートが WLAN アクセスに拡張されています。SM、IMSA、および ECS などのさまざまな内部モジュールに、必要なパラメータを渡すための基本的な実装はすでにサポートされています。詳細については、「Wi-Fi EPC の NetLoc」セクションを参照してください。

過充電保護を使用するには、有効なライセンスキーがインストールされている必要があります。ライセンスの入手方法の詳細については、シスコのアカウント担当者にお問い合わせください。

過課金保護は、UE がアイドルモードの間にドロップされたダウンリンクパケットのサブスクライバへの課金を回避するのに役立ちます。一部の国では、このような過課金を避けることが規制上の要件となっているため、そのような国の通信事業者には必須の機能となります。全体として、この機能は、サブスクライバがアイドルモードのときにサブスクライバが過課金にならないようにするのに役立ちます。

P-GW は UE の状態（アイドルまたは接続モード）を認識しません。ダウンリンクデータの課金は、UE がアイドルモードの場合でも、P-GW で適用されます。バッファオーバーフローまたはページングの遅延が原因で、UEがアイドルモードになっている場合、UE のダウンリンクデータが S-GW でドロップされることがあります。したがって、P-GW は、ドロップされたパケットの料金をサブスクライバに課金しますが、これは望ましくありません。この問題に対処するために、過課金保護機能を有効にすることで、S-GW は、S-GW でドロップされたパケットおよび UE のアイドル状態からアクティブ状態への遷移に基づいて、課金を停止または再開するよう P-GW に通知します。

「課金停止」をシグナリングする基準が満たされると、S-GW は、ベアラー変更要求（MBReq）を P-GW に送信します。PDN に対して MBReq が送信され、S-GW でドロップされるパケットが指定されます。MBReq には、「課金停止」および「課金開始」通知を P-GW に送信するための新しいプライベート拡張 IE があります。

PDN の S-GW から課金停止を含む MBReq を受信すると、P-GW はダウンリンクパケットの課金を停止しますが、S-GW へのパケットの送信は続行します。

P-GW は、次のいずれかの条件が満たされると、「課金停止」要求を受信した後に、ダウンリンクパケットの送信を再開します。

重要	過課金保護機能が P-GW サービスと APN の両方で設定されている場合、APN での設定が優先されます。

この機能を使用するには、有効なライセンスキーがインストールされている必要があります。ライセンスの入手方法の詳細については、シスコのアカウントまたはサポート担当者にお問い合わせください。

S-GW/P-GW は、ユーザーデータグラム パケットと外部 IP パケット（GTP-U トンネル IP ヘッダー）の DSCP 値を変更するための設定制御を提供します。DSCP マーキングは、設定に応じてさまざまなレベルで実行されます。ただし、ページングポリシー差別化（PPD）機能が有効になっている場合、ユーザーデータグラム パケット DSCP（トンネル化 IP パケット）のマーキングは変更されません。

現在、標準規格では、外部 GTP-U ヘッダーの QCI から DSCP へのマーキングのみが規定されています。ユーザーデータグラム パケットの DSCP 値を変更する ECS、P-GW、および S-GW のすべての設定は非標準です。標準ベースの PPD 機能では、P-CSCF または同様の Gi エンティティによって、ユーザーデータグラム パケットの DSCP がマーキングされます。このユーザーデータグラム パケットの DSCP 値は、S-GW によって MME/S4-SGSN に DDN メッセージで送信されます。MME/S4-SGSN は、この DSCP 値を使用してページング優先順位を付けます。

重要	P-GW と S-GW は、デフォルトと専用の両方のベアラーに PPD 機能を適用する必要があります。仕様に従って、P-GW はユーザーデータグラム パケットを透過的に S-GW に渡します。つまり、PPD 機能が有効になっている場合、通信事業者はデフォルトベアラーと専用ベアラーに異なる動作を適用できません。

重要	ページングポリシー差別化の詳細については、このガイドの「ページングポリシー差別化」の章を参照してください。

QCI および ARP の可視性のサポート

StarOS リリース 20.2 では、ソフトウェアの機能が強化されており、Quality of Service Class Index（QCI）および Allocation and Retention Priority（ARP）ベースの QoS 統計の表示がサポートされています。

ARP は、ネットワークが輻輳した状況で優先順位の低いベアラーをドロップまたはダウングレードするための 3GPP メカニズムです。ネットワークは ARP を確認し、新しい専用ベアラーを無線ベースステーションを介して確立できるかどうかを判断します。QCI は通信事業者のプロビジョニング値であり、ベアラーレベルのパケット転送処理を制御します。

この機能が拡張されたため、通信御者は、同じ QCI 値で実行されている複数のサービスを識別する QoS 統計情報をモニターできるようになりました。さらに、Enhanced Charging Service（ECS）がパケットをドロップした具体的な理由を提供するためのパケットドロップカウンタが導入されました。パケットドロップカウンタは、ARP ごとに出力されます。これにより、通信事業者はサービスに影響を与える可能性のあるネットワーク問題の特定とトラブルシュートを行う際に使用できる追加情報を得ることができます。

重要	ARP 値については、Allocation/Retention Priority（ARP）情報要素（IE）の優先度レベル値のみが考慮されます。ARP IE のプリエンプション脆弱性（PVI）およびプリエンプション機能（PCI）フラグは考慮されません。

既存の show apn statistics name apn-name および show apn statistics Exec Mode CLI コマンドが強化されました。これらのコマンドの出力で、QCI/ARP ベースの QoS 統計情報が可視化されるようになりました。

重要	詳細については、このガイドの「拡張 QCI のオプション」の章を参照してください。

ライセンス

QCI レベルカウンタの ARP 精度はライセンス制御機能です。QCI ごとのパケットドロップカウンタ機能にはライセンスは必要ありません。ライセンスの詳細については、シスコのアカウント担当者またはサポート担当者にお問い合わせください。

この機能は、S2b インターフェイスを介した ePDG および P-GW での「セッション作成応答」メッセージと「ベアラー作成要求」メッセージのピギーバックをサポートしています。セッション作成要求で ePDG によってピギーバックフラグが設定されると、P-GW は、セッション作成応答とベアラー作成要求を一緒に ePDG に送信できるようになり、これらのメッセージの順序が変更される可能性が排除されます。

GTP-C の負荷制御機能はライセンス方式のオプション機能です。この機能により、GTP コントロールプレーンノードはピアの GTP コントロールプレーンノードに負荷情報を送信できます。受信側の GTP コントロールプレーンノードは、この情報を使用して GW と S-GW で既存の GW 選択プロシージャを強化します。負荷情報には、発信元の GTP コントロールプレーンノードのリソースの動作ステータスが反映されます。

GTP コントロールプレーンのシグナリングを使用するノードは、ピアノードで実行されるアクションを通じてノードの過負荷状態を軽減するために、過負荷制御情報の通信をサポートする場合があります。この機能は、GTPv2 コントロール プレーン プロトコルを介して S5 および S8 インターフェイスでサポートされます。

GTP-C ノードが公称容量を超えて動作している場合に、そのノードは過負荷状態になっていると見なされ、結果としてパフォーマンスが低下します（着信トラフィックや発信トラフィック処理への影響もあります）。過負荷制御情報には、発信元ノードがそのような状況に達した日時が示されます。この情報が GTP-C ノード間で送信されると、これらのノード間の GTP-C シグナリングトラフィック量を削減またはスロットリングするために使用できます。このように過負荷制御情報によって、受信ノードがアクションを決定するためのガイダンスが提供されるため、情報の送信側の負荷軽減につながります。

負荷制御と過負荷制御を簡単に説明すると、次のようになります。

最大 64 の異なる負荷プロファイルおよび過負荷プロファイルを設定できます。

重要	R12 負荷および過負荷制御機能を使用するには、有効なライセンスキーがインストールされている必要があります。ライセンスの入手方法の詳細については、シスコのアカウントまたはサポート担当者にお問い合わせください。

R12 負荷および過負荷係数の計算機能の拡張

キャパシティテストおよびお客様のご利用環境において、sessmgr カードの CPU 使用率が高い場合でも、R12 の負荷および過負荷サポート機能が誤ったシャーシの負荷係数値を提供することが確認されました。根本原因は、sessmgr カードと demux カードの CPU 使用率の平均を取得して負荷係数が計算される際、demux カードの CPU 使用率が sessmgr カードの CPU 使用率を上回らないためです。そのため、sessmgr カードの CPU 使用率が高くても、システムは過負荷状態に移行しませんでした。

R12 負荷/過負荷制御プロファイル機能が強化され、CPU 負荷とメモリでは、同タイプのカードの大きいほうの値に基づいて負荷係数が計算されるようになりました。demux カードの CPU 使用率の値が sessmgr カードの CPU 使用率の値よりも高い場合、負荷係数の計算には demux カードの CPU 使用率の値が使用されます。

リソースマネージャに複数のポーリング間隔を設定するための新しい CLI コマンドが導入されました。これにより、demuxmgr はさまざまなシステム要件に基づいて負荷係数を計算できます。

重要	この機能の詳細については、本ガイドの「P-GW、SAEGW および S-GW での GTP-C 負荷および過負荷制御のサポート」の章を参照してください。

現在の実装では、最初のアタッチの際に、P-GW は、モバイルディレクトリ番号（MDN）またはモバイルステーション国際サブスクライバディレクトリ番号（MSISDN）を S6b インターフェイスから選択します。その後、コールが P-GW から eHRPD/信頼 Wi-Fi/非信頼 WiFi などの他のサービスにハンドオフされるか、これらのサービスから P-GW へのハンドオフが実行されると、セッション作成（CS）要求から MDN/MSISDN が選択され、S6b で承認された MDN/MSISDN が失われます。その結果、異なる値の MDN/MSISDN が Rf レコードで送信されます。通常、オペレータは MDN を使用してサブスクライバに請求するため、収益の損失が発生します。

この機能では、最初のアタッチの際に、また P-GW と eHRPD/信頼 Wi-Fi/非信頼 Wi-Fi 間のハンドオフでも、S6b インターフェイスまたは CS 要求からの MDN/MSISDN 値が保持されます。MDN/MSISDN の値は、コールの有効期間中は変更されません。そのため、セッションのすべての Rf レコードには同じ MDN/MSISDN の値が含められます。

新しいキーワード retain-mdn が CLI コマンド authorize-with-hss に追加されました。この CLI コマンドキーワードを設定すると、MDN/MSISDN 値が保持されます。この CLI コマンドキーワードが設定されていない場合、MDN/MSISDN 値は S6b インターフェイスから受信されません。この場合、CS 要求で受信した MDN/MSISDN の値が使用されます。

重要	この機能は、GnGp ハンドオフには適用されません。

この機能の詳細については、このガイドの「S6b から MDN を取得する」の章を参照してください。

P-GW のセッションリカバリ機能の使用ライセンスは、P-GW セッション使用ライセンスに含まれています。

セッションリカバリ機能は、システム内のハードウェアまたはソフトウェアに障害が発生した場合に、サブスクライバセッション情報のシームレスなフェールオーバーと再構築を行い、完全に接続されたユーザーセッションが切断されるのを防ぎます。

電気通信業界では、すべての機器の障害の 90% 以上がソフトウェアに関連しています。堅牢なハードウェア フェールオーバーと冗長性保護により、システム上のカードレベルのハードウェア障害を迅速に修正できます。ただし、さまざまな理由でソフトウェアの障害が発生する可能性があり、多くのの場合、何の前触れもありません。StarOS リリース 9.0 では、P-GW セッションのステートフルシャーシ内セッションリカバリをサポートする機能が追加されています。

ソフトウェアパッチのアップグレードアクティビティには、セッションリカバリも役立ちます。ソフトウェアパッチのアップグレード中にセッションリカバリが有効になっている場合、アップグレードプロセス中にアクティブな PSC/PSC2 で既存のセッションを保持できます。

重要	セッションリカバリのサポートに関する詳細については、『System Administration Guide』の「Session Recovery」の章を参照してください。

スマートフォンテザリング検出を使用するには、有効なライセンスキーがインストールされている必要があります。ライセンスの入手方法の詳細については、シスコの営業またはサポート担当者にお問い合わせください。

P-GW では、インラインヒューリスティック検出メカニズムを使用して、モバイルデバイスからのトラフィックと、モバイルデバイスに接続されているテザリング中のデバイスを検出して、区別できるようになりました。

サブスクライバ単位のトラフィックポリシングを使用するには、有効なライセンスキーがインストールされている必要があります。ライセンスの入手方法の詳細については、シスコの営業またはサポート担当者にお問い合わせください。

トラフィックポリシングにより、ネットワーク上の帯域幅の使用状況を管理し、サブスクライバへの帯域幅の許容範囲を制限できます。

トラフィックポリシングにより、3GPP/3GPP2 サービスの特定のトラフィッククラスの個々のサブスクライバや APN の帯域幅制限を設定して適用できます。

帯域幅の適用は、ダウンリンクとアップリンクの方向で個別に設定および適用されます。

トークンバケットアルゴリズム（trTCM の修正版）[RFC2698] を使用して、トラフィックポリシング機能が導入されます。使用されるアルゴリズムは、パケットのマーキング方法を決定する際に、次の基準を測定します。

システムは、超過または違反と判断されたパケットに対して、次のいずれかのアクションを実行するように設定できます。

重要	トラフィックポリシングの詳細については、このガイドの「トラフィックのポリシングとシェーピング」の章を参照してください。

トラフィックシェーピングは、トラフィックポリシングと同様のレート制限方法ですが、設定された制限を超えるパケットに対してバッファ機構を提供します。パケットが data-rate を超過すると、パケットはバッファ内のキューに入れられ、後で配信されます。

帯域幅の適用は、ダウンリンクとアップリンクの方向で個別に実行できます。サブスクライバデータに使用できるバッファスペースがなくなった場合、パケットをドロップするか、次にスケジュールされているトラフィックセッション用に保持するかを、システムで設定できます。

トラフィックは設定された APN-AMBR 値にシェーピングされます。これまでは、GBR 以外のベアラーで伝送されるデータは、設定された APN-AMBR レートでポリシングされていました。APN-AMBR ポリシングにより、設定された APN-AMBR と一致しないデータがドロップされました。APN-AMBR トラフィックシェーピングでは、設定された APN-AMBR レートと一致しない GBR 以外のデータがバッファされます。十分なメモリトークンが使用可能になると、データが送信されます。さらに、通信事業者は、バッファ制限に達したときに、通信事業者がデータをドロップまたは送信することを可能にするオプションを使用できます。

重要	トラフィックシェーピングの詳細については、このガイドの「トラフィックのポリシングとシェーピング」の章を参照してください。

ベアラー更新要求（UBR）抑制機能は、ライセンス制御機能です。詳細については、シスコのアカウント担当者またはサービス担当者にお問い合わせください。

ビットレートは Gx では bps 単位、GTP では kbps 単位で表されるため、P-GW は、Gx 要求を GTP 要求に変換するための丸め処理を行います。P-GW が最小限のビットレート変更（bps 単位）で PCRF から RAR を受信すると、ベアラーに同じ QoS（Kbps 単位）がすでに設定されている場合でも、UBR が送信されます。UBR 抑制機能により、P-GW は、ベアラーのパラメータのいずれにも更新がない UBR を抑制できます。

UBR 抑制を有効にするために、新しい CLI コマンド suppress-ubr no-bitrate-change が P-GW サービス設定に追加されました。この CLI が設定されると、P-GW は、丸め処理の後もビットレートが同じである場合、UBR を抑制します。

UBR に複数のベアラーコンテキストがある場合、丸め処理の後のビットレート変更が 1 kbps 未満になるベアラーコンテキストが抑制されます。UBR をトリガーする可能性のある他のパラメータ（QCI、ARP、TFT など）が変更される場合、丸め処理の後もビットレートに変更がないときは、UBR は抑制されません。UBR 抑制は、CCA-I、RAR、およびベアラー変更コマンドによってトリガーされる UBR に適用されます。

要約すると、UBR 抑制のライセンスが有効になっており、CLI コマンド suppress-ubr no-bitrate-change が設定されている場合、丸め処理の後も kbps 単位のビットレートが同じであり、UBR をトリガーする可能性のある他のすべてのパラメータ（QCI、ARP、TFT など）も変更されていないときは、UBR が抑制されます。

ユーザーロケーション情報（ULI）レポートを使用するには、有効なライセンスキーがインストールされている必要があります。ライセンスの入手方法の詳細については、シスコの営業またはサポート担当者にお問い合わせください。

ULI レポートにより、P-GW から要求されたときに、eNodeB が UE のロケーションを MME に報告できます。

UE のロケーションレポートの開始/停止トリガーは、S-GW によって S11 インターフェイスを介して MME に報告されます。この目的のために、変更レポートアクション（CRA）情報要素（IE）が使用されます。MME は、ユーザーロケーション情報（ULI）IE を使用して S-GW へのロケーションを更新します。

重要	ユーザーロケーション情報（ULI）レポートサポートの設定については、『MME Administration Guide』の「Mobility Management Entity Configuration」 の章にある「Configuring Optional Features on the MME」の項を参照してください。

この機能強化により、P-GW および GGSN において、MME または SGSN がセッション作成要求または PDP 作成要求で PDN タイプを IPv4v6 に設定し、かつデュアルアドレスフラグ（DAF）を False に設定した場合に、次の 4 つのオプションを有効にする新しい CLI 設定が提供されました。

CLI が設定されていない場合、デフォルトの動作はオプション 1 です。ゲートウェイでは、同じ APN に対して複数の PDN 接続をサポートし、オプション 1、オプション 2、および 2 番目の PDN 接続を試みる UE の処理を実行します。APN ごとに異なる CLI を設定できます。

以前は、P-GW および GGSN で DAF False の IPv4v6 PDN に対してセッション作成要求または CPC を受信すると、割り当てられた PDN タイプに対するサポートは設定できず、セッション作成要求または PDP 作成要求で原因コードが返されていました。

この項では次のトピックについて説明します。

この項では次のトピックについて説明します。