Understanding Pool Spanning

Each User Data Repository is configured with a pool network that contains a list of other User Data Repository across which pools can span. This configuration data will include an identifying tag for each OCUDR, along with other details needed in order to be able to signal information between the systems. The OCUDR GUI will support the ability to define the ranges of PoolIDs that are associated with each UDR in the network. This data will be used in determining whether the UDR is a Pool Host UDR or Non-Pool Host UDR whenever a new pool is created.

An insert request is used to create the pool, followed by AddPoolMember/DelPoolMember requests to add or remove individual subscribers from the pool.

If a network is comprised of more than one User Data Repository, subscribers are partitioned between the User Data Repository based on either IMSI or MSISDN range. If a shared quota pool is intended to include subscribers from more than one User Data Repository, then the provisioning OSS shall generate an insert request to create the pool on each User Data Repository that contains pool subscribers. When processing the insert request, UDR applies the configuration data to determine whether it is the Pool Host UDR (PHO) or the Non-Pool Host UDR (NPHO) for the pool. One of the following results will occur:

• If the User Data Repository is the PHO, then the pool profile is created as it normally is, including any fields specified for the pool profile. The OSS may associate entity data as it normally would with the pool profile on the PHO, including PoolQuota, PoolState, and Pool DynamicQuota.
• If the UDR is the NPHO, then the pool profile is created, including any fields specified for the pool profile. However, entity data may not be associated with the pool profile on the NPHO. If any entity data is provided by the OSS, then the entity data is ignored.

For Example, See the Figure 1. In this example, two UDRs are in the pool network, and identifying information for each is configured on each UDR. This information stipulates that poolIDs starting with 2 are hosted on UDR1, and poolIDs starting with 3 are hosted on UDR2. The subscribers are partitioned based on MSISDN, with 919 subscribers on UDR1 and 617 subscribers on UDR2. A PSO 22233 is created, with UDR1 as the PHO and UDR2 as the NPHO. The respective subscribers from each UDR are added to the pool. The message sequence chart outlines the provisioning requests that are created by the OSS in order to create the Pool Spanning and how subscribers from each of the UDRs in the pool network are associated with it.

Pool quota management only occurs if the pool has been properly configured on the PHO. Whenever the AddPoolMember request is used to add a subscriber to a pool on the NPHO, data for the subscriber is internally updated to identify the pool to which it belongs. Whenever that particular member (say 6178879911 in the figure above) creates a new session, the UDR hosting the subscriber (say UDR2 in the Figure 1) interacts with the UDR hosting the pool (UDR1 in Figure 1) to ensure that the pool exists on UDR1 and to be sure that any updates to pool quota, state, or dynamic quota on UDR1 are provided to UDR2 for the UDR2 pool members that have active sessions. If any data discrepancies are detected in the data between the UDRs (perhaps the pool has not been created on UDR1), then UDR2 manages the subscriber quota and ignores the association to the pool.

The following additional pool provisioning requests are available for Pool Spanning:

• DelPoolMember

  This request removes the subscriber or list of subscribers from the specified pool. This request must be sent to the UDR that hosts the subscriber (in the same way that AddPoolMember requests must be sent to the UDR that hosts the pool). Existing processing logic applies to scenarios where either the pool or one or more subscribers does not exist on the UDR that receives the request.

• GetPoolID

  This request contains the identity of a subscriber, and returns the poolID (if any) associated with the subscriber. This request must be sent to the UDR that hosts the subscriber profile. If the specified subscriber does not exist on the UDR that receives the GetPoolID request, then an error is returned.

• GetPoolMembers

  The request is processed just as it currently is. Whenever a UDR receives this request, it returns all members hosted by the UDR that are associated with the specified pool. It does not include any PSO members that are hosted on other UDRs in the pool network.

• GetAllPoolMembers

  This is a new provisioning request that can be generated by the OSS in order to get a complete list of all members associated with a pool, including any members from other UDRs in the pool network if the pool happens to be a PSO. A GetAllPoolMembers request to get all pool members across all UDR instances can be sent to any UDR in the pool network, and provides the same result regardless of if it is processed by the PHO or NPHO. If a GetAllPoolMembers request is received for a normal pool that does not span UDRs, provides results that are consistent with the GetPoolMembers request.

Figure 2, Figure 3, Figure 4, and Figure 5 provide examples of each of these commands. These examples assume the successful creation of the pool shown in Figure 1.

Pool Spanning does not alter the existing behavior associated with pools when all members associated with the pool are on the same UDR as the pool. It is possible, though, to convert an existing pool to a Pool Spanning by creating a pool profile on the NPHO, and adding new members to the pool on the NPHO. In the following example, assume PoolID 33344 already exists on UDR2 and contains subscribers 6178879911 and 6178879922.

With the introduction of this feature, the pool network is configured on both UDR1 and UDR2. If you want to add UDR1 subscriber 9195640001 to the pool, this can be accomplished by creating a pool profile for the Pool Spanning on UDR1, followed by an AddPoolMember request to UDR1 in order to add subscriber 9195640001 to the pool.

Following the completion of the upgrade to the release that contains this feature, each UDR within the pool network is configured with the identities of the other UDRs in the pool network, along with the PoolID ranges that are associated with the other UDRs in the pool network. All UDRs in the pool network must be upgraded to the release that contains the Pool Spanning feature before any Pool Spanning are provisioned. Although the validation of this feature is limited to a pool network of two UDRs in the initial release, the implementation does not limit the ability to expand the pool network in the future to support additional UDRs.

• UDR request is received

  The UDR returns all subscriber data entities requested for the subscriber, including pool data entities if the subscriber has been associated with a pool. This provides consistent behavior with existing Sh interactions and is done transparently without regard to the UDR that hosts the pool that is associated with the subscriber.

• SNR (subscribe) request is received

  The UDR subscribes to all ServiceIndications for the subscriber, including pool service indications if applicable. This is done transparently without regard to the UDR that hosts the pool that is associated with the subscriber. If the subscriber data is requested as a part of the SNR, then the UDR returns all subscriber data entities requested for the subscriber, including pool data entities if the subscriber has been associated with a pool. This provides consistent behavior with existing Sh interactions and is done transparently without regard to the UDR that hosts the pool that is associated with the subscriber.

• PUR request is received

  The UDR updates the subscriber and pool data entities provided in the request. This is done transparently without regard to the UDR that hosts the pool that is associated with the subscriber. When the PUR is processed, data associated with the pool profile and associated entities are processed first, followed by data associated with the subscriber profile and associated entities. If some entities are not successfully updated, then a diameter UNABLE_TO_COMPLY response is delivered to the PCRF.

• SNR (un-subscribe) request is received

  The UDR unsubscribes from all ServiceIndications for the subscriber, including pool service indications if applicable. If the subscriber data is to be included in the SNR response, then the UDR returns all subscriber data entities requested for the subscriber, including pool data entities if the subscriber has been associated with a pool. This provides consistent behavior with existing Sh interactions and is done transparently without regard to the UDR that hosts the pool that is associated with the subscriber.

• PNR request is generated (due to updated data)

  The UDR generates a PNR for each subscriber that has an active subscription for notifications if any entity associated with that subscriber is updated. This applies to both subscriber entities (profile, Quota, and State), as well as pool entities (profile, PoolQuota, PoolState). In some Pool Spanning scenarios, the pool data and subscriber data may be hosted on different UDRs. In this case, if both pool and subscriber data are updated by a single request or <tx> transaction, then the resulting number of PNR messages is based on whether NotifEff is set.

  • If NotifEff is set, then a single PNR is generated for the subscriber that includes both the pool and subscriber updates.
  • If NotifEff is not set, then a separate PNR is generated for each updated entity.

Table 4-1 Pool Spanning Configuration Insert Window Fields

Field	Description
UDR Name	Indicates a Unique Name Identifier for the User Data Repository, which is a case-insensitive string. The default value is n/a. you can enter a maximum of 15 character string. Note: Valid characters are alphanumeric and underscore. Note: . Important: The string must contain at least one alpha and must not start with a digit. It is a mandatory field.
UDR ID	Indicates a non-zero and, unique UDR Instance ID. The default value is n/a. Range is 1to 4294967295.] [A value is required.]
Type	The flag indicates if UDR ID is Host or Remote. Self for Host UDR and Remote for Remote UDR. This is set to Self only for Host UDR. By default, the value is remote.