202 is associated with one or more network slices, which all use the same AMF. A Single Network Slice Selection Assistance Information (S-NSSAI) function operates to identify a network slice. Slice selection is triggered by the AMF, which receives a wireless device registration request. In response, the AMF retrieves permitted network slices from the UDM 208 and then requests an appropriate network slice of the NSSF 226.

The UDM 208 introduces a User Data Convergence (UDC) that separates a User Data Repository (UDR) for storing and managing subscriber information. As such, the UDM 208 can employ the UDC under 3GPP TS 22.101 to support a layered architecture that separates user data from application logic. The UDM 208 can include a stateful message store to hold information in local memory or can be stateless and store information externally in a database of the UDR. The stored data can include profile data for subscribers and/or other data that can be used for authentication purposes. Given a large number of wireless devices that can connect to a 5G network, the UDM 208 can contain voluminous amounts of data that is accessed for authentication. Thus, the UDM 208 is analogous to a Home Subscriber Server (HSS) and can provide authentication credentials while being employed by the AMF 210 and SMF 214 to retrieve subscriber data and context.

The PCF 212 can connect with one or more Application Functions (AFs) 228. The PCF 212 supports a unified policy framework within the 5G infrastructure for governing network behavior. The PCF 212 accesses the subscription information required to make policy decisions from the UDM 208 and then provides the appropriate policy rules to the control plane functions so that they can enforce them. The SCP (not shown) provides a highly distributed multi-access edge compute cloud environment and a single point of entry for a cluster of NFs once they have been successfully discovered by the NRF 224. This allows the SCP to become the delegated discovery point in a datacenter, offloading the NRF 224 from distributed service meshes that make up a network operator's infrastructure. Together with the NRF 224, the SCP forms the hierarchical 5G service mesh.

The AMF 210 receives requests and handles connection and mobility management while forwarding session management requirements over the N11 interface to the SMF 214. The AMF 210 determines that the SMF 214 is best suited to handle the connection request by querying the NRF 224. That interface and the N11 interface between the AMF 210 and the SMF 214 assigned by the NRF 224 use the SBI 221. During session establishment or modification, the SMF 214 also interacts with the PCF 212 over the N7 interface and the subscriber profile information stored within the UDM 208. Employing the SBI 221, the PCF 212 provides the foundation of the policy framework that, along with the more typical QoS and charging rules, includes network slice selection, which is regulated by the NSSF 226.

Dedicated Bearer Failure Resiliency

When a dedicated bearer fails either during initial call setup or during a call, the call can terminate. However, in some cases, the default bearer can still be available and can allow call setup to continue or a call in progress to continue.

FIG. 3 is a diagram that illustrates a dedicated bearer setup failure during call setup according to some implementations. The process 300 can be implemented on an evolved packet core (EPC) network. At step 302, a proxy call session control function (PCSCF) 310 transmits an authorization-authentication-request (AAR) to a policy and charging rules function (PCRF) 312 over an Rx connector 316. At step 304, the PCRF 312 sends an authorization-authentication-answer (AAA) to the PCSCF 310 via the Rx connector 316. At step 306, the PCRF 312 sends a re-authorization request (RAR) to a packet data network gateway (PGWY) 314 via a Gx connector 318. In the process 300, setup of the dedicated bearer fails at the PGW 314, and at step 308, the PGWY 314 sends a re-authorization answer (RAA) to the PCRF 312 via the Gx connector 318. In response, the PCRF 312 can determine that no action should be taken (e.g., based on an allow/deny list of errors) and the call can continue on a default bearer.

FIG. 4 is a flowchart that illustrates an example process for handling dedicated bearer setup failure during call setup according to some implementations. The process 400 can be implemented on an EPC network. At step 402, the method includes attempting to setup a dedicated bearer for a call (which can be a voice call, video call, etc.). At step 404, the dedicated bearer setup fails. At step 406, a PGWY sends an RAA error or no response to a policy control function (PCF) or PCRF. At step 408 the PCF or PCRF uses the error (or no response) to determine if a call session should be released. At step 410, the method includes determining if a default bearer is still active. If so, the call can continue on the default bearer at step 412. If not, the call can fail at step 414.

In some cases, setting up a dedicated bearer can succeed, but the dedicated bearer can later fail, for example during a call. FIG. 5 is a diagram that illustrates an example process for handling dedicated bearer failure during a call (“mid-call”). The process 500 can be carried out on an EPC network.

At step 502, a PCSCF 520 sends an AAR to a PCRF 522 via an Rx connector 526. At step 504, the PCRF 522 sends an AAA to the PCSCF 520. At steps 506 and 508, dedicated bearer setup can occur. At step 506, the PCRF 522 sends an RAR to a PGWY 524 via a Gx connector 528. At step 508, the PGWY 524 sends an RAA to the PCRF 522 via the Gx connector 528.

During the call, a dedicated bearer failure can occur. At step 510, the PGWY 524 sends an update message (credit-control-request (CCR) update) to the PCRF 522 via the Gx connector 528 indicating a failure of the dedicated bearer. At step 512, the PCRF 522 sends an acknowledgement (credit-control-answer (CCA)) to the PGWY 524 via the Gx connector 528. In some implementations, the call can continue on the default bearer.

FIG. 6 is a flowchart that illustrates an example process for handling mid-call dedicated bearer failure according to some implementations. At step 602, the method 600 includes attempting to setup a dedicated bearer. At step 604, the dedicated bearer setup succeeds, and the call continues on the dedicated bearer instead of a default bearer (or in addition to the default bearer, for example if an SIP session continues on the default bearer and an RTP session continues on the dedicated bearer). At step 606 the evolved packet core (EPC) indicates a failure of the dedicated bearer to a PCF or PCRF. At step 608, the PCF or PCRF determines, using error code information, if the session should be released, for example by checking an allow/deny list. At decision point 610, the method includes determining if the call can continue. If so, at step 612, the call can continue on the default bearer. If not, the call can fail at step 614.

FIGS. 3-6 relate to wireless networks that use an evolved packet core (EPC) and diameter protocol. In any of the example implementations described above, in some cases, a user equipment can receive a notification of dedicated bearer setup failure or dedicated bearer failure. Similar approaches can be implemented in fifth generation core network (5GC). Instead of the diameter-based protocols used in FIGS. 3-6, message-based protocols (e.g., service-based interfaces) can be in used a 5GC network.

FIG. 7 is a diagram that illustrates a process for handling dedicated bearer setup failure in a 5GC network according to some implementations. At step 702 of the process 700, the process includes a PCSCF 710 sending a request (e.g., Npfc_PolicyAuthorization_Create) to a PCF 712 via an N5 interface 716. At step 704, the PCF 712 sends a HTTP 201 “Created” acknowledgement to the PCSCF 710. At step 706, the PCF 712 sends an update (e.g., NpcsfSMPolicyControl_UpdateNotify) to a session management function (SMF) 714 via an N7 interface 718 requesting a dedicated bearer. In FIG. 7, setup of the dedicated bearer fails. At step 708, the SMF 714 sends a response (e.g., UpdateNotify response=error) to the PCF 712 via the N7 interface 718. In response, the PCF 712 can determine that no action is to be taken, and the call can proceed on the default bearer.

FIG. 8 is a flowchart that illustrates an example process for handling dedicated bearer setup failure during call setup. The process 800 can be implemented on a 5GC network. At step 802, the method includes attempting to set up a dedicated bearer for a call (which can be a voice call, video call, etc.). At step 804, the dedicated bearer setup fails. At step 806, an SMF sends an error message or no response to a PCF. At step 808, the PCF uses the error information (or lack of response in a threshold time) to determine if the session should be released. For example, an error message may indicate that the call is not recoverable or can indicate that the call may be recoverable. At decision point 810, the method includes determining if the default bearer is still active. If the default bearer is not active, the call fails at 814 as the call cannot continue on the default bearer. If, at decision point 810, the default bearer is still active, the method includes, at step 812, continuing the call on the default bearer.

As discussed above in the context of EPC networks, in some cases, setting up a dedicated bearer can succeed, but the dedicated bearer can later fail, for example during a call. FIG. 9 is a diagram that illustrates an example process for handling mid-call dedicated bearer failure. The process 900 can be carried out on a 5GC network.

At step 914, a PCSCF 902 sends a policy authorization create request to a PCF 904 via an N5 interface 912. At step 916, the PCF 904 sends a response (e.g., “201 Created”) to the PCSCF 902 via the interface 912. At step 918, the PCF 904 sends a policy control update notify message to an SMF 906 via an N7 interface 910. At step 920, the SMF 906 sends a response to the PCF 904 via the interface 910 (e.g., “200 OK”). Subsequently, the dedicated bearer can fail, and at step 922, the SMF 906 can send a policy control update to the PCF 904 via the interface 910. At step 924, the PCF 904 can send a response or acknowledgement (e.g., “200 OK”) to the SMF 906 via the interface 910.

FIG. 10 is a flowchart that illustrates an example process for handling mid-call dedicated bearer failure on a 5GC network according to some implementations. At step 1002, the process 1000 includes attempting to set up a dedicated bearer, for example as described above with reference to FIG. 9. At step 1004, the dedicated bearer setup succeeds and a call continues on the dedicated bearer. For example, a real-time protocol (RTP) portion of the call can transition to the dedicated bearer. At step 1006, the 5GC can indicate failure of the dedicated bearer to the PCF. For example, an SMF can indicate dedicated bearer failure to the PCF. At step 1008, the PCF uses the error information to determine if the session should be released, for example by consulting an allow/deny list. While an error code is described in FIG. 10, in some cases a failure of the dedicated bearer can be determined if the dedicated bearer is unresponsive or non-functional for more than a threshold period of time. At decision point 1010, the process includes determining if the call can continue on the default bearer. If so, at step 1012, the call can transition to the default bearer and continue on the default bearer. If not, the call can fail at step 1014.

In some implementations, a RAN can request setup of a dedicated bearer (e.g., from MME to eNB or from AMF to gNB). If there is a failure between a UE and the RAN, the error can be propagated back to the PCRF/PCF. The PCRF/PCF can then determine handling as described herein. At the UE, the call can continue on a default bearer in some implementations. In any of the above example implementations, in some cases, a notification can be sent to the UE indicating dedicated bearer setup failure and/or dedicated bearer failure. In some implementations, the UE may not receive a notification. In some implementations, the UE can determine dedicated bearer failure based on, for a example, a timer.

FIG. 11 illustrates an example of dedicated bearer setup failure handling according to an implementation. The process 1100 can be applied to both EPC and 5GC networks, as well as other networks using different technologies that implement similar functionality. At circle (1), user equipment 1102 can be on a default bearer and can start a call on the default bearer by communicating with IP multimedia subsystem (IMS) 1104. At circle (2), the IMS 1104 requests a dedicated bearer from a network core (e.g., EPC or 5GC) 1106. At circle (3), the network core experiences a fault, resulting in failure to setup the dedicated bearer. At circle (4), a PCF in the network core 1106 does not inform the IMS 1104 of the failed resource. At circle (5), the IMS 1104 maintains the call session, and at circle (6), the user equipment 1102 continues the call on the default bearer.

FIG. 12 illustrates an example of mid-call dedicated bearer failure handling according to an implementation. The process 1200 can be applied to both EPC and 5GC networks, as well as other networks using different technologies that implement similar functionality. At circle (1), user equipment 1202 can be on a default bearer and can start a call on the default bearer by communicating with the IMS 1204. At circle (2), the IMS 1204 requests a dedicated bearer from the network core 1206. At circle (3), setup of the dedicated bearer succeeds. At circle (4), the network core 1206 can have a fault resulting in failure of the dedicated bearer. At circle (5), a PCF in the network core