Patent ID: 12206714

DETAILED DESCRIPTION

In a typical voice over long term evolution (VOLTE) deployment, the session border controller (SBC), deployed as a P-CSCF, maintains a cache of user registrations for each user and its contact addresses. An IMS user is represented using an AOR, and an IMS user may register multiple contacts with different addresses. Each such contact is referred to herein as a “user contact”.

At the time of a new registration, the SBC receives a SIP REGISTER request and adds an entry into the registration cache that binds an AOR with one or more user contacts. During registration, the SBC also initiates an Rx session with the PCRF to learn the access network information and to subscribe to notifications for bearer modification in the access network. One such subscription is for INDICATION_OF_RELEASE_OF_BEARER. Once the P-CSCF subscribes for the INDICATION_OF_RELEASE_OF_BEARER with the PCRF, the PCRF is required to indicate to the P-CSCF when the bearer corresponding to a user contact is released, or in simple terms, when the connectivity with the user contact is lost.

Loss of connectivity with a user contact could occur because the user turns off the device or roams to a different network. When the P-CSCF receives a notification from the PCRF about the release of bearer for a user contact, it deregisters the user contact, informs the registrar, and deletes the corresponding record from its local registration cache. The subscription and notification flows are depicted inFIG.1.

Referring toFIG.1, in line 1, a user device initiates registration with the network using the IP address IP1 and sends a SIP REGISTER request including the IP address IP1 to a P-CSCF102. In line 2, P-CSCF102initiates an Rx connection with a PCRF104by sending an authorization authentication request (AAR) message to PCRF104. The AAR message includes a specific action attribute value pair (AVP) which may include an INDICATION_OF_RELEASE_OF_BEARER value. The INDICATION_OF_RELEASE_OF_BEARER value instructs PCRF104to notify P-CSCF102when a release of bearer channel for a user contact occurs. In line 3, PCRF104sends an authorization authentication answer (AAA) message to P-CSCF102. P-CSCF102receives the AAA message and, in response to receiving the AAA message, P-CSCF102creates an entry in its registration cache for the user contact that uses IP1.

In line 4, P-CSCF102sends a SIP REGISTER request to a serving/interrogating (S/I)-CSCF106, which functions as the registrar for the IMS network. In line 5, S/I-CSCF106responds to P-CSCF102with a 200 OK message indicating successful completion of the registration. In line 6, P-CSCF102sends a 200 OK message to user device100confirming successful completion of the registration.

In the example illustrated inFIG.1, it is assumed that user device100roams into a new network or disconnects and reconnects to the same network using a different IP address. InFIG.1, the different IP address is IP2. Accordingly, in line 7, PCRF104sends a reauthorization request (RAR) message to P-CSCF102with an INDICATION_OF_RELEASE_OF_BEARER indicating loss of communication with user device100at IP1. In response to the INDICATION_OF_RELEASE_OF_BEARER, P-CSCF102deletes its registration cache entry for the user contact that used IP1. In line 8, P-CSCF102sends a reauthorization answer (RAA) message to PCRF104.

In line 9, P-CSCF102sends a SIP deregister request to S/I-CSCF106to deregister the user contact that used IP1. As stated above, the SIP deregister request may be a SIP REGISTER request with an expires parameter set to zero. In line 10, S/I-CSCF106sends a 200 OK message to P-CSCF102confirming successful deregistration of the contact for user device100corresponding to IP1.

In line 11, PCRF104sends a Diameter session termination request (STR) message to P-CSCF102to terminate the Rx session created for the user contact that used IP1. In line 12, P-CSCF102sends a Diameter session termination answer (STA) message to PCRF104confirming successful termination of the Rx session.

In line 13, user device100sends a SIP REGISTER request including the IP address IP2 to P-CSCF102. In line 14, P-CSCF102initiates an Rx session with PCRF104by sending an AAR message to PCRF104. The AAR message includes the INDICATION_OF_RELEASE_OF_BEARER value. In response to receiving the AAA message, P-CSCF102creates an entry in its registration cache for the user contact that uses IP2. In line 15, PCRF104confirms successful creation of the Rx session by sending an AAA message on the Rx interface to P-CSCF102. In line 16, P-CSCF102sends a SIP REGISTER request to S/I-CSCF106to register the user contact that uses IP2. In line 17, S/I-CSCF106responds to P-CSCF102with a 200 OK message indicating successful completion of the registration. In line 18, P-CSCF102sends a 200 OK message to user device100confirming successful creation of the registration. Thus,FIG.1illustrates the case where a user device connects to one network, disconnects from that network, and connects to another network (or reconnects to the same network using a different IP address). The registration cache entry at P-CSCF102is deleted when the user device disconnects from the network, P-CSCF102receives notification of release of the bearer channel for the user contact that used IP1.

Hereinafter, “SBC” and “P-CSCF” are used interchangeably to refer to the network node that maintains the registration cache and subscribes with the PCRF to receive the INDICATION_OF_RELEASE_OR_BEARER.

In some instances, the PCRF can go out-of-service and lose the Rx session statuses along with the registered subscriptions for user contacts associated with an AOR. Although it is expected of PCRF implementations to ensure sufficient redundancy to prevent such data loss, it is not uncommon for data loss to occur at some PCRF implementations, primarily due to complicated geo-redundancy requirements. The subscription data loss could occur due to any number of reasons, such as a shared database failure or a multi-site data synchronization issue. In such a case, the PCRF will eventually resume its service, but since it lost the subscription information, it would never send any notifications to the P-CSCF for the old user contacts that were registered before the data loss. Because the P-CSCF is not notified of the data loss at the PCRF, the P-CSCF will continue to assume that the user contact is still reachable since the P-CSCF has not received any indication of loss of bearer from the PCRF. In other words, the P-CSCF would unnecessarily continue to hold the stale information for deregistered user contacts until the registration expires, which depends on a registration-expires timeout value that typically ranges from a few hours to a day or more. During this window, the SBC would also try to route mobile terminated (MT) calls to a user contact that is not reachable using the available information in the registration cache. This is the problem addressed by the subject matter described herein. It is to be noted however, that in some cases, the problem would autocorrect for user contacts that send new SIP REGISTER requests, and the SBC is able to correlate the new request with an already registered user contact. The following are scenarios that could occur:1) Case 1:The PCRF restarts without losing the session/subscription database. There are no problems in this scenario because the P-CSCF would reestablish the transport connection to the PCRF, and the old Rx sessions would remain intact.2) Case 2: The PCRF restarts and loses its session/subscription database.a. Case 2a: The user contact stays connected, i.e., there is no release of bearer. This is a non-problematic scenario, assuming that the user contact remains connected until the next registration refresh, resulting in the SBC sending a new AAR (restoring the subscription) to the PCRF. If the user contact loses connectivity before the new AAR request is transmitted to the PCRF, this becomes one of the problematic scenarios mentioned below. The case where the user contact remains connected during and after the PCRF database failure is illustrated inFIG.2. InFIG.2, lines 1-6 are the same as described above with respect toFIG.1in which user device100connects to the network, and P-CSCF102creates a subscription with PCRF104to receive notification of a release of a bearer channel for the user contact that uses IP1, creates an entry in its local registration cache, and registers the new user contact with S/I-CSCF106. It is assumed that PCRF104loses its session/subscription database, and user device100remains connected to the network, and, in line 7, sends a SIP REGISTER request to P-CSCF102to refresh the registration. In response to the SIP REGISTER request, in line 8, P-CSCF102finds a matching entry in its local registration cache for the user contact that uses IP1 and sends an AAR message to PCRF104requesting to be notified of a release of bearer channel for the bearer connection involving IP1. In line 9, PCRF104sends an AAA message to P-CSCF102confirming creation of the subscription. Because the subscription was recreated, the loss of the session/subscription database by PCRF104does not adversely affect communications involving the user contact that uses IP1. In lines 10 and 11, P-CSCF102refreshes the registration with S/I-CSCF106. In line 12, P-CSCF102sends a 200 OK message to user device100.b. Case 2b: A user contact disconnects and then reconnects in the same or a different network. i.e., the old bearer has been released and a new one established. In this scenario, it is expected that the user will re-register with the P-CSCF with a new contact address. There are two possibilities here on how the P-CSCF could handle this:i. If the SBC is able to detect that the new registration pertains to an already registered user contact (e.g., based on the instance-id as specified in IETF RFC 5626), the SBC will update the existing record corresponding to the user contact in the registration cache. According to IETF RFC 5626, the instance-id is a unique identifier for a device that does not change when the device moves to another network. IETF RFC 5626 also specifies that the Contact header of a registration request can include a reg-id parameter that is used to uniquely identify different flows registered by a user agent. Thus, if the registration includes the same instance-id and the same reg-id as a previous registration, the SBC may determine that the registration is a new registration for an existing flow. If the registration includes the same instance-id and a different reg-id from existing flows, the SBC may determine that the registration is a new registration not intended to replace an existing registration. If the SBC detects that the new registration is associated with the same instance-id and reg-id as the old registration, the SBC will clean up the old Rx session and create a new Rx session with the PCRF, which would restore the subscription for the INDICATION_OF_RELEASE_OF_BEARER. Hence, for this user contact, the P-CSCF will return to the state it was in before the PCRF lost this subscription database. This case is depicted inFIG.3. InFIG.3, lines 1-6 are the same as described above with respect toFIG.1in which user device100connects to the network, and P-CSCF102creates a subscription with PCRF104to receive notification of a release of a bearer channel for the user contact that uses IP1, creates an entry in its local registration cache, and registers the new contact with S/I-CSCF106. After line 6, it is assumed that PCRF104loses its session/subscription database, and user device100disconnects from the network, roams, and reconnects with the network using a new IP address IP2. In line 7, user device100sends a SIP REGISTER request to P-CSCF102to register the new user contact that uses IP2 with the network. In response to the SIP REGISTER request, P-CSCF102determines that the contact for user device100has changed because the SIP REGISTER request includes the same instance-id and the same reg-id as the user contact that registered using IP1, updates the record for the user contact in its local registration cache, and, in line 8, P-CSCF102sends an AAR message to PCRF104requesting to be notified of a release of bearer channel for the bearer connection used by the user contact that registered with IP2. In line 9, PCRF104sends an AAA message to P-CSCF102confirming creation of the subscription. After line 9, P-CSCF102frees resources associated with the user contact involving IP1 and creates a new Rx session database entry for the user contact using the IP address IP2. In lines 10 and 11, P-CSCF102registers the new contact with S/I-CSCF106. In line 12, P-CSCF102sends a 200 OK message to user device100.ii. If the SBC is unable to correlate the new registration request with an already registered user contact, the SBC will treat the contact identified in the new registration request as a new user contact and will create a new Rx session by sending an AAR with a new session ID to the PCRF. One of the reasons why the SBC might fail to identify the user contact could be the lack of support for the RFC 5626 instance-id in the user equipment. In this case, the old registration record, along with the old Rx session, will continue to exist in the SBC until the registration expires. This is the problematic scenario depicted inFIG.4. InFIG.4, lines 1-6 are the same as described above with respect toFIG.1in which user device100connects to the network, and P-CSCF102creates a subscription with PCRF104to receive notification of a release of a bearer channel for the user contact that registered using IP1, creates an entry in its local registration cache, and registers the new contact with S/I-CSCF106. After line 6, it is assumed that PCRF104loses its session/subscription database, user device100disconnects from the network, roams, and reconnects with the network using a new IP address IP2. In line 7, user device100sends a SIP REGISTER request to P-CSCF102to register a new user contact with the network. In response to the SIP REGISTER request, because P-CSCF102cannot detect that the user contact in the new REGISTER request is intended to replace the existing user contact, P-CSCF102does not delete the registration cache entry for the user contact involving IP1 and creates a new cache entry for the user contact that uses IP2. The cache entry for the user contact that uses IP1 will be maintained in the registration cache until the registration time expires, even though the contact is stale. In line 8, P-CSCF102sends an AAR message to PCRF104requesting to be notified of a release of bearer channel for the bearer connection involving the user contact that uses IP2. In line 9, PCRF104sends an AAA message to P-CSCF102confirming creation of the subscription. In lines 10 and 11, P-CSCF102registers the new contact with S/I-CSCF106. In line 12, P-CSCF102sends a 200 OK message to user device100. If a call is attempted to the user contact using IP1, the call will fail because user device100no longer uses the user contact involving IP1.c. Case 2c: User switches off the device.

In this scenario, the SBC would not get an indication about the release of bearer, and the stale registration record will be maintained in the local registration cache of the SBC until the registration expiry. This is another potentially problematic scenario that is not addressed by the solution described herein. As mentioned above, Case 2(b) (ii) defines the primary problem that the solution described herein is intended to address. It is to be noted that the above-mentioned problem can have a significant impact since it can potentially manifest for many users that reconnect (due to roaming or reconnection in the same network) during or after the PCRF database failure event.

The solution described herein handles the above-mentioned problematic scenario by using the following approach at the P-CSCF. The SBC/P-CSCF will keep track of transport layer connection failures with the PCRF. As a standard behavior, in the event of a PCRF restart or a switchover, the transport layer connection and the subsequent Diameter connection are reestablished. The SBC will look at the Diameter Origin-State-Id AVP received from the PCRF during the Diameter capabilities exchange request/capabilities exchange answer (CER/CEA) handshake to infer if the PCRF underwent a cold restart and could have possibly lost the subscription database. The Origin-State-Id AVP is a monotonically increasing value that is advanced whenever a Diameter entity restarts with loss of previous state. The AVP may be included in any Diameter message, including the CER. It enables Diameter entities that receive the message to infer from a changed AVP value that sessions associated with a lower value are no longer active.

When the SBC detects a change in the Origin-State-Id value, it shall mark all registered user contacts as “pending verification” in the registration cache. On receipt of a new registration request for a user, if the SBC finds an existing registration with the same AOR as received in the request but is unable to correlate the contact in the request with a registered user contact, the SBC will start a new Rx session with the PCRF and also send a SIP OPTIONS message to all the old contacts for that user (proposed behavior). The second step above would be to confirm if these user contacts are still reachable. If the OPTIONS response is received, the SBC will reset the user contact's “pending verification” status and send an AAR to PCRF to restore the subscription.

If there is no response (i.e., the request times out), the old user contact will be deregistered and deleted from the registration cache. In another scenario, if the SBC receives any SIP request or response from a registered user contact (indicating that the user contact is still connected) that leads SBC to send an AAR to the PCRF, and the SBC will also reset the “pending verification” status for this user contact. Sending an AAR would restore the subscription on the PCRF.

As a further optimization, sending an OPTIONS message could be skipped for user contacts whose registration expiry is near-due. That is, if a user contact is within a predetermined time period of its expiration, the SBC may refrain from sending the SIP OPTIONS message for the user contact. This is because the user contact's registration will be confirmed shortly depending on whether the SBC receives a refresh registration or not before the expiry.

As another optional optimization, if a MT call to a user contact for which “pending-verification” status is set fails before the SBC receives a re-registration request or sends a SIP OPTIONS request to the user contact, the user contact will be deregistered, and the entry for the user contact will be deleted from the registration cache. If the MT call attempt fails because the user contact is not connected to the network, there is no reason to test the user contact for reachability, and the P-CSCF can free the registration cache resources used by the user contact.

The proposed solution is depicted inFIG.5andFIG.6. Referring toFIG.5, in line 1, user device100initiates registration with the network using the IP address IP1 and sends a SIP REGISTER request including the IP address IP1 to P-CSCF102. In line 2, P-CSCF102initiates an Rx session with a PCRF104by sending an AAR message to PCRF104. The AAR message includes a request be to subscribed to an INDICATION_OF_RELEASE_OF_BEARER for the bearer channel of the user contact registering using IP1. In line 3, PCRF104confirms successful creation of the subscription by sending an AAA message on the Rx interface to P-CSCF102. P-CSCF102receives the AAA message, and, in response to receiving the AAA message, P-CSCF102creates an entry in its registration cache for the user contact registered using IP1.

In line 4, P-CSCF102sends a SIP REGISTER request to S/I-CSCF106, and S/I-CSCF106responds to P-CSCF102with a 200 OK message indicating successful completion of the registration. In line 5, P-CSCF102sends a 200 OK message to user device100confirming successful creation of the registration.

After line 5, PCRF104loses all of its subscription data, for example, due to a subscription database failure and loses transport layer and Diameter connectivity with P-CSCF102. P-CSCF102detects the transport layer and/or Diameter layer connection failure. In line 6, P-CSCF102determines, based on a change in the Origin-State-Id in one or more of the Diameter messages that reestablished the Diameter connection with PCRF104that PCRF104may have lost its subscription database and marks all user contacts in the registration cache of P-CSCF102as “pending verification”. It should be noted that detecting a connection failure is not a precondition to detecting a PCRF database failure, as a PCRF database failure may be detected based on a change in Origin-State-Id in any message received from PCRF104.

InFIG.5, it is assumed that user device100disconnects from the original network, roams into a new network or reconnects to the existing network, is assigned a new IP address IP2, connects to the new network or reconnects to the existing network using IP2. In line 7, user device100sends a SIP REGISTER message to P-CSCF102to register the contact that uses IP2 with the network. In line 8, P-CSCF102sends an AAR message to PCRF104requesting to be notified of release of bearer events for the user contact that uses IP2. PCRF104creates a new subscription and session database entry for the user contact that uses IP2. In line 9, PCRF104responds to P-CSCF102with an AAA message confirming successful creation of the subscription.

In line 10, P-CSCF102sends a SIP REGISTER request to S/I-CSCF106, and S/I-CSCF106sends a 200 OK message to P-CSCF102confirming successful registration of the contact for user contact that uses IP2. In line 11, P-CSCF102sends a 200 OK message to user device100in response to the SIP REGISTER request in line 7.

In response to receiving a new SIP register request for an AOR that is of record in the registration cache, P-CSCF initiates testing of all of the user contacts associated with the AOR identified in the SIP REGISTER request to determine if the user contacts are still reachable or stale.FIG.5shows messages exchange to test one of the user contacts. In line 12, P-CSCF102a SIP OPTIONS message to user device100for the contact that used IP1. Since the contact that used IP1 is no longer active, user device100does not respond within the SIP OPTIONS timeout period, and P-CSCF102determines from the timeout that the user contact that used IP1 is no longer active. Accordingly, P-CSCF102cleans up the Rx session and deletes the entry in the local registration cache for the contact that used IP1. Cleaning up the Rx session may include deleting entries in the Rx session database for the contact that used IP1. In line 13, P-CSCF102sends a SIP deregister request to S/I-CSCF106for the user contact that used IP1, and S/I-CSCF responds with a 200 OK message confirming successful deregistration of the contact that used IP1.

FIG.6illustrates operations performed by a P-CSCF when a transport connection failure occurs between the P-CSCF and the PCRF and also how the P-CSCF processes a SIP REGISTER request and frees resources associated with stale registration cache entries. The left hand flow chart inFIG.6illustrates exemplary operations performed by the P-CSCF when a PCRF transport connection failure is detected by the P-CSCF. When a transport failure with the PCRF is detected, in step550, the P-CSCF initiates a new connection with the PCRF. The new connection may be or include a transport layer connection and a Diameter connection. In step552, the P-CSCF determines whether the Origin-State-Id used by the PCRF has changed. If the Origin-State-Id has changed, one or more registrations maintained by the P-CSCF be stale because the PCRF is unable to notify the P-CSCF of release of bearer events. If the Origin-State-Id has changed, control proceeds to step554where the P-CSCF marks all entries in its registration cache as pending verification. In step552, if the P-CSCF determines that the Origin-State-Id has not changed, control proceeds to step556where the P-CSCF continues with existing Rx sessions and reestablishes a Diameter connection with the PCRF.

The right-hand flow chart inFIG.6illustrates operations performed by the P-CSCF when a SIP REGISTER request message is received by the P-CSCF. In step600, when a SIP REGISTER request message is received, the P-CSCF determines whether the user address of record obtained from the SIP REGISTER request is found in the registration cache maintained by the P-CSCF. If the user address of record is not in the registration cache, control proceeds to step602where the P-CSCF initiates the process of registering new user contacts for the AOR. There are no stale entries to delete for this AOR, since the AOR in the SIP REGISTER request is not present in the registration cache.

Returning to step600, if the user address of record identified in the SIP REGISTER request is found in the registration cache, control proceeds to step604where the P-CSCF determines whether the request is for an existing contact. If the instance-id and reg-id are present in the SIP REGISTER request, the P-CSCF may use these parameters to determine if the request is for the same contact or a new contact. If the instance-id and reg-id are not present, the P-CSCF may determine that a change in IP address and/or port indicates a request for a new contact. If the SIP REGISTER request is not for an existing contact, control proceeds to step606, where the P-CSCF registers a new contact for the address of record and IP address identified in the SIP REGISTER request. Control then proceeds to step608where the P-CSCF initiates a new Rx session with the PCRF and sends an AAR message to the PCRF.

In step610, the P-CSCF gets the list of old contacts for the AOR identified in the SIP REGISTER request from the registration cache. In step612, the P-CSCF determines whether there are more contacts in the list. If there are more contacts in the list, control proceeds to step614where the contact verification process ends because there are no more contacts in the list.

If the P-CSCF determines that there are more contacts in the list, control proceeds to step616where the P-CSCF selects the next contact. Control then proceeds to step618where the P-CSCF determines whether the pending verification flag is set for the contact. If the pending verification flag is set for the contact, control proceeds to step620where the P-CSCF sends a SIP OPTIONS request message to the contact to determine whether the contact is still in use and reachable. In step622, the P-CSCF determines whether the SIP OPTIONS request has timed out. If the SIP OPTIONS request has timed out, control proceeds to step624, where the P-CSCF deregisters the contact and removes the cache entry for the contact from the registration cache.

In step622, if the P-CSCF determines that the SIP OPTIONS request did not time out, i.e., because the P-CSCF received a response to the SIP OPTIONS request from the user device within the SIP OPTIONS timeout period, control proceeds to step626where the P-CSCF starts a new Rx session, sends an AAR message to the PCRF, and resets the pending verification flag for the contact. In an alternate implementation, the P-CSCF may reset the pending verification flag for the contact in step620just before sending the SIP OPTIONS request to avoid any race conditions. Control then proceeds to step612where the process of checking the list of contacts begins again for the next contact in the list. Steps612-626are repeated until all of the contacts in the list have been tested. The P-CSCF actively tests contacts, identifies those that are no longer reachable, removes the corresponding cache entries, and deregisters the contacts with the S/I-CSCF.

In step618, if the P-CSCF determines that the pending verification flag is not set for the contact, control returns to step612where it is determined whether there are more contacts to be tested. If there are more contact to be tested, steps616-626are repeated for each contact.

Returning to step604, if the P-CSCF determines that the SIP REGISTER request is for an existing contact, control proceeds to step627where the P-CSCF determines whether the pending verification flag is set for the contact. If the pending verification flag is set, control proceeds to step628where the P-CSCF resets the pending verification flag. The reason for resetting the pending verification flag is that the receipt of the SIP REGISTER request for the contact means that the contact is still active, and there is no need to test the reachability of the contact. Control then proceeds to step608where the P-CSCF starts a new Rx session and sends an AAR message to the PCRF. Steps610through626are then executed to test the remaining contact in the list. It should also be noted that the P-CSCF may reset the pending verification flag for an existing user contact in response to receiving any SIP message from the contact, e.g., a SIP INVITE request, because receiving a SIP message from an existing contact means that the contact is still connected to the network.

Returning to step627, if the P-CSCF determines that the pending verification flag is not set for the contact, control proceeds to step630where the P-CSCF determines whether there has been an IP address and/or port change for the contact. If there has been an IP address and/or port change for the contact, control proceeds to step632where the P-CSCF starts a new Rx session for the contact and sends an AAR message to the PCRF. In step630, if the P-CSCF determines that there has not been an IP address and/or port change for the contact, control proceeds to step634where the P-CSCF uses the existing Rx session for the contact and sends an AAR message to the PCRF.

FIG.7is a block diagram of an exemplary architecture for a P-CSCF that implements the subject matter described herein. Referring toFIG.7, P-CSCF102includes at least one processor700and memory702. P-CSCF102includes a registration cache704stored in memory702that includes cache entries for user contacts registered with the network. P-CSCF102further includes a user contact registration manager706that performs the steps described above with respect toFIGS.5and6. User contact registration manager706may be implemented using computer executable instructions stored in memory702and executed by processor700.

The subject matter described herein thus provides for identification and handling of PCRF subscription loss at the P-CSCF by performing proactive stale registration cleanup and restoration of lost Rx subscriptions at the PCRF. Advantages of the subject matter described herein include early detection of stale registrations at the P-CSCF in the problematic scenarios mentioned above. This not only saves resources (e.g., memory) by deleting such stale records, but also prevents undesired behavior for these users (such as attempting a call to an unavailable contact). A less preferred solution to testing user contacts when a PCRF database failure is detected could be to send AAR messages to the PCRF for all registered user contacts after a PCRF connection failure (without determining whether a PCRF database loss has occurred). However, sending AAR messages for all registered user contacts without determining whether a database failure has occurred would create unnecessary overhead on the network.

The disclosure of each of the following references is hereby incorporated herein by reference in its entirety.

REFERENCES

1. Jennings et al., Managing Client-Initiated Connections in the Session Initiation Protocol (SIP) IETF RFC 5626 October 2009.

It will be understood that various details of the subject matter described herein may be changed without departing from the scope of the subject matter described herein. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation, as the subject matter described herein is defined by the claims as set forth hereinafter.