APN に明示的に設定された UP グループがない場合、デフォルトの UP グループに属していると見なされます。デフォルトの UP グループはコンシューマトラフィックに主に使用され、APN が大規模すぎるため、多数のサブスクライバに対応し、大規模な IP プールで動作する 大きすぎる

特定の APN のトラフィックを選択的に一部の UP に転送するには、特定の UP グループを使用します。たとえば、APN と IP プールが小規模な（256 程度の）企業サブスクライバのケースを考えてみます。この場合、プールをチャンクに分割するのではなく、APN 全体を 1 つの UP のみで構成される UP グループ専用にするのが得策です。では次に、大規模な APN と 20 以上の UP で構成されるきわめて大規模な展開を考えてみます。この場合も、サービスを提供するために 20 の UP すべてを必要とする大規模な APN はありません。IP プールのチャンク分割メカニズムをより効果的に活用するため、これらの UP と APN をいくつかの特定の UP グループに分割します。

たとえば、UP の数が 20 で、それぞれが 100,000 のサブスクライバにサービスを提供する必要があるとします。また、それぞれプールサイズが 16,000、チャンクサイズが 1,000 の APN が 25、プールサイズが 64,000、チャンクサイズが 1,000 の APN が 6 あるとします。この場合、IP プールをより効率的に使用するため、2 つの UP グループを作成できます。UP group-1 は 4 つの UP で 25 の小規模 APN に対応し、UP group-2 は 16 の UP と 6 つの大規模 APN で構成されます。

CP は、すべての UP との間でチャンクを定期的にプッシュまたは削除します。周期性は、chunk-threshold-timer を使用して設定されます。プールから割り当てられたアドレスの 70% を超えるチャンクが UP で使用されている場合、新しいチャンクが UP にプッシュされます。 同様に、UP で IP プールリソースが十分に活用されていない場合、CP は未使用のチャンクを UP からプルバックします。チャンクの削除は、「チャンクの取り消し」で説明されている他の要因にも左右されます。

CP の空きチャンクが min-chunks-threshold-per-pool 未満の場合、CP は定期的にそのプールの使用率が低い UP からチャンクを取り消します。UP が使用しているのがプールの割り当て済み IP アドレスの 40% 未満の場合、UP に 2 つを超える使用可能な空きチャンクがあれば、1 つのチャンクがプールから取り消されます。

各 UP にプッシュされる最初のチャンクは、cups max-user-plane キーワードを使用して制御できます。このキーワードはコンテキストレベルで機能します。最初のチャンクは、次の要因に応じてプッシュされます。

• プール内の空きチャンクの合計数（show ip pool コマンドでこの値が表示されます）

• プール内の合計チャンク（cups max-user-planes CLI で設定された値）。デフォルトでは、max-user-planes の値は 10 に設定されます。

• 3 つのチャンク

例 1:

CUPS の max-user-plane CLI コマンドは、登録時に UP にプッシュされる初期チャンクの数を決定するために使用されます。プッシュされる初期チャンクの数は、次の要因によって異なります。

• チャンクが max-user-plane 値未満の場合、1 つのチャンクがプッシュされます。

• チャンクがそれより多い場合、最小値は（chunks/max-user-plane, 3）です。

  max-user-plane のデフォルト値は 10 です。

8 つのチャンクプールがあり、展開で 4 つの UP を使用するとします。すべてのチャンクをすべての UP に直接割り当てることができます。max-user-plane を 4 に設定すると、同じ処理を実行できます。同様に、8 つの UP を展開する場合は、値を 8 に設定すると、1 つのチャンクだけが UP にプッシュされます。

さらに、サブスクライバの急増に対応するためのバッファとして機能できる追加のチャンクを提供します。このサブスクライバの急増により、通常のしきい値のチャンク補充レートを超える可能性があります。32 個のチャンクと 2k サイズの 4 つの UP から構成される 1 つのプールがあり、着信サブスクライバレートが 1 分あたり 2k であるとします。追加のバッファチャンクを確保したい場合、つまり、短い期間に着信サブスクライバがチャンクの補充レートを上回り、負荷の不均衡が発生するのを回避するためにチャンクを保護するには、max-user-plane CLI を使用します。この CLI を使用しない場合は、1000 に設定すると、常に 1 つのチャンクがプッシュされます。

チャンクサイズは、UP グループ内の UP の数に関して、CEPS とチャンクの均等性の両方を考慮して計画する必要があります。設定するチャンクが大きすぎると、UP 間で IP アドレスが不均一になる可能性があります。ただし、チャンクが小さすぎる場合、チャンクの補充レートが着信サブスクライバよりも低くなる可能性があります。チャンクの補充率が低いと、UP のオーバーライドや負荷の不均衡が発生します。

チャンクは、UP グループの規模を考慮して計画する必要があります。チャンクサイズが大きすぎるまたは小さすぎると、それに関連した影響が出るため、適切なバランスを維持することが重要です。

• チャンクサイズが小さいほど、UP 間のチャンク分散の不均衡が減少します。ただし、チャンクサイズが非常に小さいと、UP でのチャンクの枯渇が速くなり、CEPS レートに悪影響を及ぼします。

• チャンクサイズが非常に大きいと、UP 間でチャンクが不均等に分散される可能性があります。この問題により、IP アドレスが別の UP で引き続き使用可能であるにもかかわらず、特定の UP で UP のオーバーライドや負荷の不均衡が発生して、使用可能な IP がない状態に陥る可能性があります。

適切な IP プールリソースプランニングが推奨される設定例を以下に示します。

• IPv6 プール：Poolv6_example_1 pool_group_example1 x:x:x:x::/48 chunk_size = 8192

• IPv6 プール：Poolv6_example_1 pool_group_example1 x:x:x:x::/48 chunk_size = 8192

• APN に関連付けられた UP：UP1、UP2、UP3、UP4、UP5

• しきい値タイマー：60 秒

• UP あたりの着信サブスクライバレート：6,000 サブスクライバ/分

（この UP グループがサービスを提供している APN に接続されている IP プールグループは 1 つだけであることを前提としています）

これで、両方の IP プールには 65536 個の IP アドレスがあります。

チャンクサイズが大きすぎる場合：アドレスが 8 つのチャンクに分割され、5 つの UP に分配されるとします。つまり、すべての UP が同等の数の IP リソースを取得できるわけではなく、一部の UP は他の UP よりも早く IP リソースを使い果たします。

IP リソースが枯渇すると、そのような UP で UP オーバーライドや負荷の不均衡が発生します。この例では、プールあたり約 40960 のアドレスまたは IP プールグループレベルで約 81920 のアドレスが使用された後に、このような状況が発生する可能性があります。

• Pool1：（UP1 = 8192 + 8192, UP2 = 8192 + 8192, UP3 = 8192 + 8192, UP4=8192, UP5=8192）

• Pool2：（UP1 = 8192 + 8192, UP2 = 8192 + 8192, UP3 = 8192 + 8192, UP4=8192, UP5=8192）

チャンクサイズが小さすぎる場合：前の項と同じプールが、チャンクサイズ 512、チャンク数 128 で設計されているとします。この場合は、次のようになります。

• Pool1：（UP1 = 26 *512, UP2 =26*512, UP3 = 26*512, UP4=25*512, UP5=25*512）

• Pool2：（UP1 = 26 *512, UP2 =26*512, UP3 = 26*512, UP4=25*512, UP5=25*512）

この場合、チャンクの不均衡による UP オーバーライドまたは負荷の不均衡は、128000（50 チャンク * 512 サイズ * 5 UP）のアドレスが使用された後に発生します。各 UP には各 UP から 1 分あたり 1k アドレスしかありません。しきい値タイマーは 60 秒ですが、着信サブスクライバレートは 6k であるため、各 UP では 5k のサブスクライバの負荷の不均衡が発生します。

正しい設計の場合：IP プールをチャンクサイズ（4096 個の IP アドレスなど）に分割すると、適切な設計になります。この設計では、5 つの UP に配布するための 16 のチャンクが CP に提供されます。

Pool1：（UP1 = 4096 + 4096 + 4096 + 4096, UP2 = 4096 + 4096 + 4096, UP3 = 4096 + 4096 + 4096, UP4= 4096 + 4096 + 4096, UP5= 4096 + 4096 + 4096）

この場合、チャンクの不均衡による UP オーバーライドまたは負荷の不均衡は、122880（6 チャンク *4096 サイズ *5 UP）のアドレスが使用された後に発生します。各 UP には各 UP から 1 分あたり 8k アドレスしかありませんが、しきい値タイマーが 60 秒で着信サブスクライバレートが 6k であるため、UP はすべてのサブスクライバに対応できます。

この例から明らかなように、チャンクサイズが 4096 の場合は、チャンクサイズが 8096 の場合よりも UP 間で IP リソースが分散されます。IP リソースが枯渇すると、そのような UP で UP オーバーライドや負荷の不均衡が発生します。この例では、プールごとに約 61440 のアドレスが使用された後に発生し始めます。また、プールグループには同時に 2 つの IP プールがあるため、チャンクの補充は pool1 からの 4k と pool2 からの 4k となり、必要なレートである 6k よりも大きくなります。

コンシューマカスタマーとエンタープライズカスタマーは、それぞれの IP プールサイズやルーティング要件が異なるため、異なる UP グループに分ける必要があります。デフォルトの UP グループは、コンシューマカスタマーに使用されます。エンタープライズカスタマーには特定のユーザーグループを作成し、エンタープライズ APN と関連付けることを推奨します。チャンクメカニズムは、大きなプールの効率的な IP アドレス管理を提供しますが、プールサイズが小さい場合（たとえば、IP プールサイズが 4k 未満の場合）は避ける必要があります。小さい IP プールは特定の UP 専用にすることを推奨します。これを実現するには、特定の UP グループに単一の UP を設定し、APN に関連付けます。

5 つの UP があり、256 アドレスの 40 の小規模エンタープライズ APN と、それぞれ 64k アドレスの 8 つの大規模コンシューマ APN にサービスを提供する場合について考えます。この場合、2 つの UP グループを作成します。1 つの UP と 40 の小規模エンタープライズ APN で構成される UPGroup1 と、4 つの UP と 8 つの大規模コンシューマ APN で構成される UPGroup2 です。

オペレータは、UP グループに新しい UP を追加する前に、すべての APN に使用可能な空きチャンクが CP にあることを確認する必要があります。チャンクは、UP 登録時に割り当てることができます。その結果、ある APN にこの UP に使用可能な IP アドレスがない場合でも、この UP がコール分配用に選択されるため、不均等な負荷分散がなくなります。

• プール使用率のしきい値アラームを使用して、IP プールリソースの補充に関する警告を受けます。適切なアクションを実行します。つまり、プールグループに新しいプールを追加します。

• ダイナミック v4v6 アドレス割り当ての場合の IPv4v6 セッションでは、UE に割り当てる必要がある IPv4 アドレスと IPv6 アドレスは両方とも同じ UP に属します。IP プールの計画では、v4v6 コールが予想される UP ごとにそれぞれ十分な v4 および v6 IP アドレスを使用可能にしておく必要があります。

  「poolv4」という名前の IPv4 プール（x.x.x.x/17 という表記のアドレス 32,000 個）と、「poolv6」という名前の IPv6 プール（x:x:x:x:/48 という表記のアドレス 64,000 個）を例に考えてみましょう。2 つの APN があるとします。APN1 は v4v6 コールを実行し、「poolv4」と「poolv6」の両方で動作します。

  ip pool poolv4 209.165.200.224/17 – APN1 で使用される 32,000 個のアドレス

  ipv6 pool poolv6 prefix 2003::/48 - APN2 で使用される 64,000 個のアドレス

  APN2 が使用する IPv6 アドレスが 32,000 個を超えてしまった場合、APN の計画が不十分であるために、APN1 の v4v6 に対応できるだけの十分な IPv6 アドレスが残らない可能性があります。この場合、poolv6 の 64,000 個のアドレスを、APN1 で使用する 32,000 個のアドレス（poolv6_1）と APN2 で使用する 32,000 個のアドレス（poolv6_2）に分けます。より多くの IP アドレスが必要なのであれば、APN1 に正当に割り当てられたアドレスを枯渇させるのではなく、必要に応じて APN2 に IPv6 プールを追加する必要があります。