Patent Description:
In some cases, Internet Protocol (IP) Multimedia Subsystem (IMS) networks can provide services in conjunction with various access technologies. The Multimedia Telephony Service (MMTel) is an IMS-based technology that can provide various services involving multimedia communication, such as voice, real-time video, video, text, file transfer, or the like. An IMS network can be used as an alternative to a Circuit-Switched (CS) network, in various network architectures. <NPL>) is a Standards document pertaining to <NUM> networks. <CIT> describes how to map a new security association to an active Internet Protocol (IP) Multimedia Subsystem (IMS) session subsequent to the occurrence of a connectivity interruption. <CIT> discloses that in response to a timer expiring/timing out, an originating UE may perform a designated "fire" action which may include halting or reattempting the setup of the communication session with new setup procedures.

Accordingly, there is provided a method performed in a User Equipment, UE, according to independent claim <NUM> and a corresponding UE according to independent claim <NUM>. Advantageous features are in the dependent claims.

The systems, devices, and techniques described herein relate to automatically resetting failed network connections using wait times. In particular implementations, the network connections can be associated with core networks and Internet Protocol (IP) Multimedia Subsystem (IMS) networks, such as interfaces between core networks and IMS networks.

Various services requested by mobile devices, and other types of User Equipment (UE), may be associated with a minimum Quality of Service (QoS) level. For instance, some services may be associated with a Guaranteed Bit Rate (GBR). Users may be particularly sensitive to delays in GBR services.

Networks may deliver QoS-sensitive services without significant delays by prioritizing the delivery of the services along particular paths through the networks. In certain cases, the networks may establish dedicated tunnels (also referred to as "dedicated media tunnels" or "dedicated QoS tunnels") by which the QoS-sensitive services are delivered through the networks. Dedicated tunnels may ensure that the services are delivered through the networks at a particular QoS level. In a case of an Evolved Packet System (EPS), these dedicated tunnels may include dedicated bearers. In a case of a 5th Generation (<NUM>) core network, the dedicated tunnels may include preestablished <NUM> QoS Indicator (5QI) data flows.

In situations in which a dedicated tunnel is sought through a core network and an IMS network, interruptions in the core network and/or the IMS network can prevent the dedicated tunnel from being established. In some cases, fallback to a Circuit-Switched (CS) network (e.g., a 2nd Generation (<NUM>) network and/or a 3rd Generation (<NUM>) network) can be initiated. In a CS fallback scenario, the initial call can be dropped and then a new call can be initiated over an available CS network, rather than the previous core network or IMS network.

However, CS networks are not always available. As more network providers begin to prioritize coverage for more advanced technologies, CS networks may become less accessible for CS fallback. In some cases, CS network coverage and/or CS network resources may be unavailable when a dedicated tunnel cannot be established through a 4th Generation (<NUM>) or <NUM> network. In certain examples, CS network coverage is available, but restricted from use by the particular user or type of use associated with an attempt to access the CS network as a part of a fallback process.

When a dedicated tunnel cannot be established through a <NUM> or <NUM> network and CS fallback is unavailable, a device may be unable to receive QoS-sensitive services. In some examples, signaling between a caller and the core network may cause the caller to establish a voice call despite the lack of an established dedicated tunnel. However, because the dedicated tunnel has not been established, the caller may experience the call as a mute call. That is, the caller may be unable to receive voice services from the core network and the IMS network.

Moreover, this problem may persist in subsequent requests for services. For instance, a core network may save and reuse previously established connections in subsequent calls, even when there is a problem with one of the previously established connections. That is, the core network may reuse the same failed connection that prevented the establishment of the dedicated tunnel for the initial call. Accordingly, if the caller redials the same callee using the same core network, the caller will experience a mute call in an initial as well as subsequent calls with the callee. Although, in some cases, the core network may eventually diagnose and repair the offending connection (e.g., through a "self-restore" process), this process can take a significant amount of time. In the meantime, users of the caller and callee devices may be frustrated with the lack of services from the network.

In some cases, tech-savvy users may identify strategies for manually reestablishing (i.e., resetting) the connections through the core network and the IMS network, in order to avoid mute calls. In particular examples, a user may power cycle the caller device (e.g., turn a mobile phone off and on). In certain instances, a user may activate and de-activate "Airplane Mode" of the caller device. Both of these strategies may cause the core network and/or IMS network to "forget" existing connections setup with the core network and/or the IMS network, and to reestablish new network connections for the call. However, users that do not understand these tricks may be unable to avoid the cycle of mute calls due to interruptions associated with the IMS network. Moreover, even if a user understands these tricks, they require a high level of user intervention.

According to various implementations of the present disclosure, a network connection, which may be associated with a core network and/or IMS network, can be automatically reset when a dedicated tunnel has not been established for a particular session (e.g., a call) corresponding to services with a minimum QoS level. The network connection may be reset when CS fallback is unavailable, in some cases. In particular implementations, a caller (e.g., a UE) initiating the session can automatically cause the network connection to be reset when the caller does not receive a confirmation of the dedicated tunnel within a particular wait time. In some examples, the services include voice services and the session corresponds to a voice call.

According to certain implementations, the caller initiates a timer during Session Initiation Protocol (SIP) signaling. The timer may be initiated in response to transmitting or receiving a message (e.g., a SIP INVITE, a <NUM> Response, a Provisional Acknowledgement (PRACK) or the like) for setting up a first call corresponding to services with a minimum QoS level. In particular implementations, the caller can initiate the timer in response to receiving or transmitting at least one Session Description Protocol (SDP) message associated with setting up the first call.

If the timer expires without the caller having received, from the core network, a confirmation that the dedicated tunnel has been established, the caller may automatically cause the core network and/or an IMS network to reset at least one connection associated with the core network and/or the IMS network. In some cases, a connection between the core network and the IMS network may be reset. According to particular implementations, the UE may confirm that CS fallback is unavailable. The first call may end automatically or in response to user input. Subsequently, the caller may initiate a second call with the reset connection(s). Accordingly, the caller may successfully receive the QoS-sensitive services in the second call, despite a malfunctioning interface between the core network and the IMS network (or another interface associated with the core network and/or the IMS network) that was established for the first call and that would otherwise prevent the establishment of a dedicated tunnel. Further, the caller may successfully receive the QoS-sensitive services despite the unavailability of CS fallback. In addition, the QoS-sensitive services may be delivered to the caller without the device power cycling or cycling through airplane mode.

Particular implementations solve specific problems associated with telecommunication networks. Certain implementations enable successful delivery of QoS-sensitive services, even when a connection between a core network and an IMS network fails and/or even when a CS network is unavailable. In addition, particular implementations provide an improved user experience by ensuring that a device can successfully connect to a QoS session without requiring a user to manually power- or airplane-mode-cycle the device after the call initially fails. Accordingly, various implementations relate to specific improvements to various technical problems.

Particular implementations of the present disclosure will now be described with reference to the accompanying drawings.

<FIG> illustrates an example network environment <NUM> for automatically resetting a network connection using a wait time.

A first User Equipment (UE) <NUM> may be connected to a radio network <NUM>. In some implementations, the first UE <NUM> may be connected to the radio network <NUM> via a wireless interface. As used herein, the terms "UE," "user device," "wireless communication device," "wireless device," "communication device," "mobile device," and "client device," can be used interchangeably herein to describe any UE (e.g., the first UE <NUM>) that is capable of transmitting/receiving data wirelessly using any suitable wireless communications/data technology, protocol, or standard, such as Global System for Mobile Communications (GSM), Time Division Multiple Access (TDMA), Universal Mobile Telecommunications System (UMTS), Evolution-Data Optimized (EVDO), Long Term Evolution (LTE), Advanced LTE (LTE+), New Radio (NR), Generic Access Network (GAN), Unlicensed Mobile Access (UMA), Code Division Multiple Access (CDMA), Orthogonal Frequency Division Multiple Access (OFDM), General Packet Radio Service (GPRS), Enhanced Data GSM Environment (EDGE), Advanced Mobile Phone System (AMPS), High Speed Packet Access (HSPA), evolved HSPA (HSPA+), Voice over Internet Protocol (IP) (VoIP), VoLTE, Institute of Electrical and Electronics Engineers' (IEEE) <NUM>. 1x protocols, WiMAX, Wi-Fi, Data Over Cable Service Interface Specification (DOCSIS), digital subscriber line (DSL), and/or any future Internet Protocol (IP)-based network technology or evolution of an existing IP-based network technology.

In general, the first UE <NUM> can be implemented as any suitable type of computing device configured to communicate over a wired or wireless network, including, without limitation, a mobile phone (e.g., a smart phone), a tablet computer, a laptop computer, a Portable Digital Assistant (PDA), a wearable computer (e.g., electronic/smart glasses, a smart watch, fitness trackers, etc.), an Internet-of-Things (IoT) device, an in-vehicle (e.g., in-car) computer, and/or any similar mobile device, as well as situated computing devices including, without limitation, a television (smart television), a Set-Top-Box (STB), a desktop computer, and the like.

The first UE <NUM> may transmit and receive data wirelessly with the radio network <NUM> via one or more radio interfaces. The radio network <NUM> may be a Radio Access Network (RAN). In this manner, the radio network <NUM> can include and/or be substituted for a 3GPP RAN, such a GSM/EDGE RAN (GERAN), a Universal Terrestrial RAN (UTRAN), or an Evolved UTRAN (E-UTRAN), or alternatively, via a "non-3GPP" RAN, such as a Wi-Fi RAN, or another type of wireless local area network (WLAN) that is based on the IEEE <NUM> standards. In some instances, the radio network <NUM> can include a Wi-Fi Access Point (AP). Although not illustrated, the environment <NUM> can further include any number and type of base stations representing any number and type of macrocells, microcells, picocells, or femtocells, for example, with any type or amount of overlapping coverage or mutually exclusive coverage compared to the radio network <NUM>.

The radio network <NUM>, in turn, may be connected to a core network <NUM>. The core network <NUM> may be at least one of a 2nd Generation (<NUM>) core network, a 3rd Generation (<NUM>) core network, a 4th Generation (<NUM>) core network, a 5th Generation (<NUM>) core network, or the like. According to particular implementations, the core network <NUM> is a <NUM> core network, such as an Evolved Packet Core (EPC) network. In certain instances, various components of the EPC can include, but are not limited to, a Mobility Management Entity (MME), a Serving Gateway (SGW), a Packet Data Network (PDN) Gateway (PGW), a Home Subscriber Server (HSS), an Access Network Discovery and Selection Function (ANDSF), and/or an evolved Packet Data Gateway (ePDG). An SGW can include a component that handles user-plane data (SGW-U) and a component that handles control-plane data (SGW-C). A PDN can include a component that handles user-plane data (PDN-U) and a component that handles control-plane data (PDN-C). The core network may further include a Policy and Charging Rules Function (PCRF). Each entity, gateway, server, and function in the <NUM> core network can be implemented by specialized hardware (e.g., one or more devices), general hardware executing specialized software (e.g., at least one virtual machine executed on one or more devices), or the like.

In some examples, the core network <NUM> may be a <NUM> core network. Various components of a <NUM> core network can include, but are not limited to, a Network Exposure Function (NEF), a Network Resource Function (NRF), an Authentication Server Function (AUSF), an Access and Mobility management Function (AMF), a Policy Control Function (PCF), a Session Management Function (SMF), a Unified Data Management (UDM) function, a User Plane Function (UPF), and/or an Application Function (AF).

In general, the NEF can be implemented as a network function including functionality to securely expose services and/or capabilities provided by and amongst the various network functions, as discussed herein. In some instances, the NEF receives information from other network functions in the <NUM> core and can store the received information as structured data using an interface to a data storage network function.

In general, the AUSF can be implemented as a network function including functionality to provide authentication to various devices in the network. For example, the AUSF can request device credentials (e.g., security key(s)), verify that the first UE <NUM> is authorized to connect to a network, and/or control access to the network based on the device credentials.

In general, the NRF can be implemented as a network function including functionality to support service discovery (e.g., receive a network function discovery request and provide information associated with the discovered network function instances to a requesting entity). In some instances, the NRF can receive utilization information, capability information, etc. from various network functions, such as the UPF, to provide such utilization information to the other components discussed herein. Further, the NRF can select, assign, implement, or otherwise determine network functions to be used in a network based at least in part on utilization information, as discussed herein.

In general, the AMF can be implemented as a network function including functionality to provide UE-based authentication, authorization, mobility management, etc., to various UEs. In some instances, the AMF can include functionality to terminate a RAN control plane interface between the first UE <NUM> and other functions on the network. In some instances, the AMF can include functionality to perform registration management of the first UE <NUM> in the network, connection management, reachability management, mobility management, access authentication, access authorization, security anchor functionality (e.g., receiving and/or transmitting security keys during registration/authorization), and the like.

In general, the SMF can be implemented as a network function including functionality to manage communication sessions by and between UEs, and/or to provide IP addresses to the UEs. In some instances, the SMF can select a UPF to provide services to the first UE <NUM> in response to receiving a request for services from the first UE <NUM>.

In general, the PCF can be implemented as a network function including functionality to support unified policy framework to govern network behavior, provide policy rules to control plane functions and/or enforce such rules, and/or implement a front end to access subscription information relevant for policy decisions in a data repository.

In general, the UDM can be implemented as a network function including functionality to process authentication credentials, handle user identification processing, manage registration and/or mobility, manage subscriptions between the first UE <NUM> and a carrier, and/or manage Short Message Service (SMS) data.

In general, the UPF can be implemented as a network function including functionality to control data transfer between the first UE <NUM> and the various components of the environment <NUM>. In some instances, the UPF can include functionality to act as an anchor point for Radio Access Technology (RAT) handover (e.g., inter and intra), external Protocol Data Unit (PDU) session point of interconnect to an external network (e.g., the Internet), packet routing and forwarding, packet inspection and user plane portion of policy rule enforcement, traffic usage reporting, traffic routing, Quality of Service (QoS) handling for user plane (e.g., packet filtering, gating, uplink/downlink rate enforcement), uplink traffic verification, transport level packet marking in the uplink and downlink, downlink packet buffering and downlink data notification triggering, and the like. As can be understood in the context of this disclosure, there may be one or more UPFs, which are associated with the core network <NUM> and/or with the first UE <NUM>.

In general, the AF can be implemented as a network function including functionality to route traffic to/from applications operating on the network, facilitate accessing the NEF, and interact with the policy framework for policy control in connection with the PCF.

The core network <NUM> may be connected to an Internet Protocol (IP) Multimedia Subsystem (IMS) network <NUM>. The IMS network <NUM> may be referred to an "IMS core network," or an "IMS CN Subsystem. " IMS is an architectural framework defined by the 3rd Generation Partnership Project (3GPP) for delivering IP multimedia to a UE, such as the first UE <NUM>. The IMS network <NUM> can be maintained and/or operated by one or more service providers, such as one or more wireless carriers ("carriers"), that provide IMS-based services to users who are associated with UEs, such as the first UE <NUM>. For example, a service provider can offer multimedia telephony services that allow a user to call or message other users via the IMS network <NUM> using his/her UE. A user can also utilize an associated UE to receive, provide, or otherwise interact with various different IMS-based services by accessing the IMS network <NUM>. It is to be appreciated that any number of base stations and/or nodes can be included in the IMS network <NUM>.

Accordingly, an operator of the IMS network <NUM> can offer any type of IMS-based service, such as, telephony services, emergency services (e.g., E911), gaming services, instant messaging services, presence services, video conferencing services, social networking and sharing services, location-based services, push-to-talk services, and so on. In order for a UE (e.g., the first UE <NUM>) to access these services (e.g., telephony services), the UE may be configured to request establishment of a communication session, or another UE (e.g., the second UE <NUM>) may be configured to request establishment of the communication session. In the case of telephony services, the communication session can comprise a voice call (e.g., a voice-based communication session, such as a VoLTE call, or a Wi-Fi call), a video call, or the like.

The radio network <NUM>, the core network <NUM>, and/or the IMS network <NUM> may be managed by the same operator, in some cases. According to various implementations, the first UE <NUM> may be associated with a subscriber account corresponding to an operator of at least one of the radio network <NUM>, the core network <NUM>, or the IMS network <NUM>.

The IMS network <NUM> may be connected to at least one outside network <NUM>. The outside network(s) <NUM> may be used to connect the IMS network <NUM> to a second UE <NUM>. In various implementations, services exchanged in a communication session between the first UE <NUM> and the second UE <NUM> may traverse the radio network <NUM>, the core network <NUM>, the IMS network <NUM>, and the outside network(s) <NUM>. In some cases, the outside network(s) <NUM> may include one or more outside IMS networks, one or more outside core networks, and/or one or more radio networks. The second UE <NUM> may be associated with a subscriber account corresponding to the outside network(s) <NUM>. For instance, the second UE <NUM> may be associated with a subscriber account corresponding to a core network in the outside network(s) <NUM>.

The IMS network <NUM> may also be connected to at least one Wide Area Network (WAN) <NUM>, such as the Internet. In various implementations, various multimedia services can be provided to the first UE <NUM> from one or more content servers in the WAN <NUM> via a pathway through the radio network <NUM>, the core network <NUM>, and the IMS network <NUM>.

In particular implementations, the first UE <NUM> may transmit a request, to the core network <NUM>, for services associated with a particular Quality of Service (QoS) level. These services may be requested as part of a communication session with the second UE <NUM>, for example. As used herein, the terms "communication session," "session," can refer to an exchange of data between two or more communicating nodes or devices. A call (e.g., a voice call, a video call, or the like) may be an example of a communication session. A communication session can be temporary, such that it is established at a first time and ceased at a second time. In various implementations, a communication session includes the transfer of user plane data between two or more nodes. In some examples, a call can be established between a caller and a callee. In certain cases, a session can be established between a UE and a content server. According to particular implementations, a call may be supported by a dedicated tunnel over which the services are delivered in the call. As used herein, the term "caller," can refer to a UE initiating a session. According to some implementations, the session may provide services to and from the caller. The session can be a communication session. In some cases, the caller may initiate a session with a callee. As used herein, the term "callee," can refer to a UE receiving (and, in some cases, confirming) a request to participate in a communication session with a caller.

As used herein, the term "node," can refer to one or more devices that transmit and/or receive data in a network. In some instances, a first node can transmit and/or receive data from a second node. For instance, a UE receiving services from an IMS network may be a node. In some cases, a UPF through which services are exchanged between an IMS network and a UE can also be a node.

The core network <NUM> may establish a pathway through the core network <NUM> and the IMS network <NUM> over which the services can be delivered to the first UE <NUM>. As used herein, the terms "network path, "path," and their equivalents, can refer to a pathway over which data can be transferred between at least two terminal nodes or devices (e.g., a caller and a callee). In some cases, a path may include one or more intermediary nodes and/or one or more interfaces between the terminal nodes. In certain <NUM> core networks, the path may include at least one of an SGW, a PGW, or a PCRF over which the services are delivered. In certain <NUM> networks, the path may include at least one UPF over which the services are delivered.

In various implementations, the first UE <NUM> may register with the IMS network <NUM> via an IMS registration process. In some cases, the IMS registration process occurs in response to the initial request for services. In certain cases, the IMS registration process can occur prior to the first UE <NUM> transmitting the request for services. During the IMS registration process, a path between the core network <NUM> and the IMS network <NUM>, by which the first UE <NUM> can be provided services, may be established. In particular, various interfaces associated with the core network <NUM> and/or the IMS network <NUM> can be allocated for multimedia services destined for or originating from the first UE <NUM>. In various examples in which the core network <NUM> is an EPC, these interfaces can include, for instance, at least one of a Gx interface (e.g., an interface connecting the SGW or PGW to the PCRF), an Rx interface (e.g., an interface connecting the PCRF to the I/S-CSCF in the IMS network), an Sgi interface (e.g., an interface connecting the SGW or PGW to the P-CSCF in the IMS network), or the like. In certain examples in which the core network <NUM> is a <NUM> core network, these interfaces can include an N5 interface between the UPF and the IMS network <NUM>.

The core network <NUM> may also identify that a dedicated tunnel should be established through the core network <NUM> and the IMS network <NUM> for the services requested by the first UE <NUM>. In some cases, the first UE <NUM> may identify that the services are associated with the particular QoS level. As used herein, the term "QoS level," can refer to at least one required (e.g., a minimum or maximum) metric associated with a type of QoS-sensitive data traffic. In a 3GPP LTE network, the QoS level may be associated with a QoS Class Identifier (QCI). In some <NUM> core networks, the QoS level may be associated with a <NUM> QoS Identifier (5QI). A type of services or data traffic associated with a minimum QoS level may be referred to as "QoS-sensitive. " In various implementations, a QoS level can correspond to at least one of a priority of the services as they are transmitted through a delivery network (e.g., as compared to other services transmitted through the core network <NUM>, the IMS network <NUM>, or a combination thereof), a maximum packet delay budget of the services (e.g., maximum allowable delay(s) by one or more nodes and/or interfaces through the delivery network), or a maximum packet error loss rate of the services (e.g., a maximum rate of bit errors added to bits in data packets comprising the services after they are transmitted through the delivery network).

According to particular implementations, a QoS level may be associated with at least one of a priority of the type of data traffic through one or more networks, a maximum packet delay budget of the type of data traffic, a maximum packet delay budget of the type of data traffic, a Guaranteed Bit Rate (GBR) of the type of data traffic, or the like. A minimum QoS level may correspond to a minimal standard of QoS over which the network guarantees the services to be delivered. The minimum QoS level may be predetermined. In certain implementations, a type of data traffic associated with a particular (e.g., a minimum) QoS level is delivered across one or more networks (e.g., a core network and/or an IMS network) via a dedicated tunnel. As used herein, the term "GBR," can refer to a type of data traffic that may be transferred through at least one network by at least a minimum bit rate. In some cases, GBR data traffic corresponds to the type of services associated with the data traffic. According to 3GPP specifications, examples of GBR services can include conversational voice, conversational video (e.g., live streaming), real-time gaming, certain V2X messaging, non-conversational video (e.g., buffered streaming), mission critical user plane Push to Talk (PTT) voice, certain Mission Critical user plane Push to Talk Voice (MCPTT), non-mission-critical user plane, or the like. However, for the purposes of this disclosure, GBR services can include any predefined set of services that are sensitive to network delays and/or any other services that should be prioritized by at least one network (e.g., the radio network <NUM>, the core network <NUM>, and/or the IMS network <NUM>) delivering the services.

In certain examples, the core network <NUM> may identify that the services are associated with the particular QoS level. The core network <NUM> may attempt to establish the dedicated tunnel based on the particular QoS level. As used herein, the term "dedicated tunnel," and its equivalents, can refer to at least one of (i) a pathway through at least one network or (ii) reserved resources allocated to a particular session traversing the network(s). A dedicated tunnel may be established through nodes in one or more of the radio network <NUM>, the core network <NUM>, and the IMS network <NUM>. In particular implementations disclosed herein, the core network <NUM> may attempt to establish the dedicated tunnel through the core network <NUM> and the IMS network <NUM>. According to some examples, a dedicated tunnel may refer to a dedicated bearer (e.g., for data traffic traversing an EPC), a dedicated 5QI flow (e.g., for data traffic traversing a <NUM> core network), or the like.

In particular implementations in which the core network <NUM> includes an EPC, the EPC may establish a dedicated bearer in response to determining that a caller (e.g., the first UE <NUM>) is requesting QoS-sensitive services. The PCRF may transmit, to the PGW, an indication of one or more QoS rules indicating that the dedicated bearer is required. In some cases, the PCRF may transmit the indication in response to receiving, from the caller, a UE-initiated resource request corresponding to the dedicated bearer. The PGW may transmit, to the MME, a request to create the dedicated bearer (e.g., a Create Dedicated Bearer Request). The MME may send, to a corresponding EUTRAN (e.g., the radio network <NUM>), a request to establish a radio bearer to support the dedicated bearer. The MME can transmit, to the SGW, a message (e.g., a Create Dedicated Bearer Response, EPS Bearer Identity, S1-TEID, etc.) acknowledging that the dedicated bearer has been established in the EPC.

In particular implementations in which the core network <NUM> includes a <NUM> core network, the <NUM> core network can establish a 5QI flow in a manner similar to the EPC establishing the dedicated tunnel, wherein various functions within the <NUM> core network can be substituted for various elements in the EPC. For instance, the AMF can perform at least some of the functions of the MME, the SMF can perform at least some of the control plane functions of the SGW, the UPF can perform at least some of the user plane functions of the SGW, the PCF can perform at least some of the functions of the PCRF, and the like. data flow for the delivery of the QoS-sensitive services for the first UE <NUM>.

The process of establishing the dedicated tunnel may also include signaling over one or more of the interfaces established via the IMS registration process. For instance, the core network <NUM> may transmit a message requesting the dedicated tunnel to the IMS network <NUM> and/or the IMS network <NUM> and may transmit a message confirming establishment of the dedicated tunnel through the IMS network <NUM>. In particular examples in which the core network <NUM> is an EPC, the signaling can be transferred over at least one of the Gx interface, the Rx interface, the Sgi interface, or the like. In some examples in which the core network <NUM> is a <NUM> core network, the signaling can be transferred over an N5 interface between the UPF and the IMS network <NUM>. In various implementations, to successfully establish the dedicated tunnel, these interfaces should be intact.

In some cases, at least one component of the IMS network <NUM> is also responsible for setting up a dedicated tunnel. In some cases, the core network <NUM> can transmit, to the IMS network <NUM>, a dedicated tunnel request. In particular cases of a <NUM> core network, an AF in the IMS network <NUM> may transmit, to a PCRF in the core network <NUM>, an indication of one or more characteristics of a dedicated bearer. The PCRF, in turn, can cause the rest of the core network <NUM> to set up the dedicated bearer. The AF may transmit the indication by transmitting a Diameter Authenticate-Authorize-Request (AAR) message to the PCRF over an Rx interface. In particular cases of a <NUM> core network, various components of the <NUM> core network can interact with the IMS network <NUM> similarly to components of the <NUM> core network. For instance, the PCF can perform at least some of the functions of the PCRF.

Simultaneously while the core network <NUM> attempts to establish the dedicated tunnel through the core network <NUM> and the IMS network <NUM>, in some cases, the first UE <NUM> and the core network <NUM> may continue to exchange signaling to set up the communication session. For instance, the first UE <NUM> and the core network <NUM> may exchange multiple Session Initiation Protocol (SIP) messages and/or Session Description Protocol (SDP) messages. As a result of the signaling exchanged between the first UE <NUM> and the core network <NUM>, the communication session may be established. In the case of a voice call, the first UE <NUM> may transition from a "ringing" state to an established call state.

However, in particular implementations, the dedicated tunnel may not be established successfully due to an interruption <NUM> in at least one interface associated with the core network <NUM> and/or the IMS network <NUM>. In certain examples, the interruption <NUM> can occur at a connection between the core network <NUM> and the IMS network <NUM>. In some implementations in which the core network <NUM> is an EPC, the interruption <NUM> can occur at one of various interfaces, such as Gx interface, the Rx interface, the Sgi interface, or the like. In some implementations in which the core network <NUM> is a <NUM> core network, the interruption <NUM> can occur at the N5 interface. In some cases, the interruption <NUM> can occur at some other Nx interface associated with the <NUM> network.

Without the dedicated tunnel being established, the first UE <NUM> may not receive the services associated with the communication session. For example, in the case of a voice call, the first UE <NUM> may experience a mute call. That is, the first UE <NUM> may be in the established call state with the second UE <NUM>, but the first UE <NUM> may not receive signals indicating voice services from the second UE <NUM>.

In some cases, when the first UE <NUM> attempts to reestablish the communication session (e.g., redials the second UE <NUM>), the first UE <NUM> will also experience a subsequent mute call. This is because, without further intervention, the core network <NUM> and the IMS network <NUM> may continue to attempt to establish a dedicated tunnel by reusing the existing connections that have already been established and/or allocated for the first UE <NUM> in the IMS registration process. For example, if the interruption <NUM> is in the Rx interface, the core network <NUM> may reuse the interrupted Rx interface in setting up subsequent communication sessions between the first UE <NUM> and the second UE <NUM>. In some cases, the connection with the interruption <NUM> may be eventually restored by the core network <NUM>. However, this process can take a significant amount of time.

If a new IMS registration process is performed after the failed establishment of the dedicated tunnel, the core network <NUM> and the IMS network <NUM> may establish and/or allocate new connections by which services can be delivered to the first UE <NUM>. The new connections may omit the interruption <NUM>. Accordingly, the dedicated tunnel can be successfully established for subsequent communication sessions associated with the first UE <NUM>.

In various implementations of the present disclosure, the first UE <NUM> may cause the core network <NUM> and/or the IMS network <NUM> to reset the connection with the interruption <NUM>, and thereby enable establishment of the dedicated tunnel. In particular examples, the first UE <NUM> may initiate a timer in response to receiving and/or transmitting a signal with the core network <NUM>. For example, the first UE <NUM> may initiate the timer in response to transmitting an initial SIP INVITE requesting the services to the core network <NUM>. The timer may be count down a wait time. As used herein, the term "wait time," can refer to a time interval by which a device waits before causing a connection associated with at least one network to be reset. In various implementations, a wait time can be predetermined. In some cases, a length of the wait time can depend on various temporary conditions of an associated network (e.g., a congestion level in the core network <NUM> and/or the IMS network <NUM>). In some cases, the wait time can be between about <NUM> second and about <NUM> minute. In particular implementations, the wait time can be between about <NUM> seconds and about <NUM> seconds. In specific examples, the wait time may be about <NUM> seconds. As used herein, the term "about" can refer to a range of ±<NUM>% of an applicable base value. For example, "about <NUM>" can refer to a range of <NUM> to <NUM>, inclusive.

In certain instances, the timer can be stopped prematurely (i.e., before the wait time expires) by the first UE <NUM>. For example, the timer can be stopped when the first UE <NUM> receives a 18X response (e.g., a <NUM> Ringing message, a <NUM> Call is Being Forwarded message, a <NUM> Queued message, a <NUM> Session Progress message, etc.). The 18X message may not require a precondition. In some cases, the first UE <NUM> can stop the timer upon receiving a Non-Access Stratum (NAS) voice dedicated bearer setup request or an NAS voice QoS flow request. The first UE <NUM> may stop the timer when the first UE <NUM> receives a message indicating context of an established dedicated tunnel. In certain instances, the first UE <NUM> may stop the timer when it receives an Activate Dedicated EPS Bearer Context request for voice. In some cases applicable to <NUM> networks, the first UE <NUM> may stop the timer in response to receiving a Protocol Data Unit (PDU) Session Modification Command from the core network <NUM>. In some cases, the first UE <NUM> may stop the timer when the communication session is terminated. When the timer is stopped prematurely, the timer is no longer applicable to the communication session.

In particular implementations, the timer (i.e., the wait time) may expire without the first UE <NUM> having received a confirmation that the dedicated tunnel has been established. For example, the confirmation may correspond to information indicating a context for the dedicated tunnel. The failure to receive the confirmation within the wait time may indicate, to the first UE <NUM>, that the dedicated tunnel was not established for the communication session. In certain cases, the communication session may subsequently end. For instance, the first UE <NUM> may receive an input from a user to hang up the mute voice call. In certain examples, the first UE <NUM> may automatically end the communication session.

The first UE <NUM> may cause (e.g., instruct) the core network <NUM> to reestablish (i.e., reset) the connection with the interruption <NUM>. For example, the first UE <NUM> may instruct the core network <NUM> to perform another IMS registration process for the first UE <NUM>. The IMS re-registration process may cause the connection with the interruption <NUM> to be reset. In some instances, the first UE <NUM> may cause the core network <NUM> to selectively identify and reestablish the connection with the interruption <NUM>. Accordingly, in some cases, IMS re-registration may be unnecessary to reset the connection with the interruption <NUM>. Any of these processes can occur automatically (i.e., without prompting by a user).

The core network <NUM>, in response, may reestablish one or more connections associated with the core network <NUM> and/or the IMS network <NUM>. In particular, at least one connection between the core network <NUM> and the IMS network <NUM> may be reset. The connection(s) may include, for instance, LTE a connection between P/S-GW and PCF when the core network <NUM> is an EPC or between the SMF and the PCF when the core network <NUM> is a <NUM> core network. Accordingly, the connections used by the core network <NUM> and the IMS network <NUM> to establish a dedicated tunnel for the first UE <NUM> may be intact, and may not include the interruption <NUM>.

The first UE <NUM> may initiate another communication session for the same service using the reestablished connection. In some examples, the first UE <NUM> may redial the second UE <NUM> in order to reestablish the voice call with the second UE <NUM>. In some cases, this process can also occur automatically (i.e., without user intervention).

As a result of the absence of the interruption <NUM>, the dedicated tunnel can be successfully established for the communication session. The first UE <NUM> may receive the information indicating the context of an established dedicated tunnel and also receive the requested services via the established dedicated tunnel. The dedicated tunnel may be established, and the first UE <NUM> may receive the QoS-sensitive services, without requiring the first UE <NUM> to power cycle and/or cycle through airplane mode. Accordingly, the first UE <NUM> can efficiently receive the QoS-sensitive services over a dedicated tunnel, despite the interruption <NUM> in the initially established pathway through the core network <NUM> and the IMS network <NUM>.

<FIG> illustrates example signaling <NUM> for establishing a session via a dedicated tunnel when context information for the dedicated tunnel is received within a wait time. The signaling <NUM> may be performed by the first User Equipment (UE) <NUM>, the core network <NUM>, and the Internet Protocol (IP) Media Subsystem (IMS) network <NUM> described above with reference to <FIG>. Although not illustrated in <FIG>, various networks and/or nodes may be present between the first UE <NUM>, the core network <NUM>, and the IMS network <NUM>. For example, the radio network <NUM> may be disposed between the first UE <NUM> and the core network <NUM>, such that at least some signaling between the first UE <NUM> and the core network <NUM> may traverse the radio network <NUM>.

The first UE <NUM> may transmit a services request <NUM> to the core network <NUM>. In particular implementations, the services request <NUM> includes at least one Session Initiation Protocol (SIP) message, at least one Session Description Protocol (SDP) message, or a combination thereof. For instance, the services request <NUM> may be a SIP INVITE message. In some cases, the services request <NUM> can be a Provisional Acknowledgement (PRACK) message. The services request <NUM> may identify the type of services being requested by the first UE <NUM>. In some cases, the services request <NUM> may identify a particular Quality of Service (QoS) level of the requested services. The services request <NUM>, in some cases, may identify that a dedicated tunnel should be established for delivery of the services. In certain implementations, the core network <NUM> may identify that the dedicated tunnel should be established for delivery of the services based on the services request <NUM>.

The core network <NUM> may forward at least a portion of the services request <NUM> to the IMS network <NUM>. An interface between the core network <NUM> and the IMS network <NUM> may be intact. Accordingly, the IMS network <NUM> may receive the services request <NUM> from the core network <NUM>. In response to receiving the services request <NUM>, the IMS network <NUM> may initiate establishment of the dedicated tunnel through the IMS network <NUM>.

The IMS network <NUM> may transmit a dedicated tunnel request <NUM> to the core network <NUM>. The dedicated tunnel request <NUM> may indicate the portion of the dedicated tunnel that has been established through the IMS network <NUM>. In some cases, the dedicated tunnel request <NUM> may further include a request for the core network <NUM> to establish a portion of the dedicated tunnel.

In response to receiving the dedicated tunnel request <NUM>, the core network <NUM> may transmit a dedicated tunnel context message <NUM> to the first UE <NUM>. The dedicated tunnel context message <NUM> may indicate, to the first UE <NUM>, that the dedicated tunnel has been established through the core network <NUM> and/or the IMS network <NUM>. In some cases, another message indicating that the dedicated tunnel has been established may be transmitted from the core network <NUM> to the first UE <NUM>. In various implementations, the first UE <NUM> may receive a message (e.g., a confirmation) confirming that the dedicated tunnel has been established.

The first UE <NUM> may receive the dedicated tunnel context message <NUM> prior to a wait time <NUM> expiring. As illustrated in <FIG>, the wait time <NUM> may begin in response to the first UE <NUM> transmitting the services request <NUM> to the core network <NUM>. However, implementations are not limited thereto. Because the first UE <NUM> receives the dedicated tunnel context message <NUM>, the first UE <NUM> may be aware that the dedicated tunnel has been established before the expiration of the wait time <NUM>.

Subsequently, the first UE <NUM> may transmit a dedicated tunnel response <NUM> to the core network <NUM>, which may be at least partially forwarded to the IMS network <NUM>. The dedicated tunnel response <NUM> may indicate, to the core network <NUM> and the IMS network <NUM>, that the first UE <NUM> has received the dedicated tunnel context message <NUM>. In some cases, the dedicated tunnel response <NUM> may activate the established dedicated tunnel in the core network <NUM> and/or the IMS network <NUM>.

The first UE <NUM> may subsequently exchange the services <NUM> with another entity (e.g., a content server associated with the WAN <NUM>, the second UE <NUM>, or the like) via the dedicated tunnel. The services <NUM> may be delivered to the first UE <NUM> by a QoS level guaranteed by the dedicated tunnel.

<FIG> illustrates example signaling <NUM> for resetting a network connection when context information for a dedicated tunnel is not received within a wait time, and for establishing a session via a dedicated tunnel that utilizes the reset network connection. The signaling <NUM> may be performed by the first User Equipment (UE) <NUM>, the core network <NUM>, and the Internet Protocol (IP) Media Subsystem (IMS) network <NUM> described above with reference to <FIG>. Although not illustrated in <FIG>, various networks and/or nodes may be present between the first UE <NUM>, the core network <NUM>, and the IMS network <NUM>. For example, the radio network <NUM> may be disposed between the first UE <NUM> and the core network <NUM>, such that at least some signaling between the first UE <NUM> and the core network <NUM> may traverse the radio network <NUM>.

The first UE <NUM> may transmit an initial services request <NUM> to the core network. In particular implementations, the initial services request <NUM> includes at least one Session Initiation Protocol (SIP) message, at least one Session Description Protocol (SDP) message, or a combination thereof. For instance, the initial services request <NUM> may be a SIP INVITE message. In some cases, the initial services request <NUM> can be a Provisional Acknowledgement (PRACK) message. The initial services request <NUM> may identify the type of services being requested by the first UE <NUM>. In some cases, the initial services request <NUM> may identify a particular Quality of Service (QoS) level of the requested services. The initial services request <NUM>, in some cases, may identify that a dedicated tunnel should be established for delivery of the services. In certain implementations, the core network <NUM> may identify that the dedicated tunnel should be established for delivery of the services based on the services request <NUM>.

The core network <NUM> may forward at least a portion of the initial services request <NUM> to the IMS network <NUM>. In response to receiving the initial services request <NUM>, the IMS network <NUM> may attempt to transmit a first tunnel request <NUM> to the core network <NUM> over an interface between the IMS network <NUM> and the core network <NUM>. However, the interface between the core network <NUM> and the IMS network <NUM> may be interrupted. For instance, the interface between the core network <NUM> and the IMS network <NUM> may be misconfigured, out-of-sync, or otherwise down. Accordingly, the core network <NUM> may not receive the first tunnel request <NUM> from the IMS network <NUM>. As a result, the core network <NUM> may not be triggered to establish a dedicated tunnel, may be unaware of any portion of the dedicated tunnel established in the IMS network <NUM>, and may not provide the first UE <NUM> with context information about a dedicated tunnel by which the requested services can be delivered.

Although not illustrated in <FIG>, in some implementations, an interface over which the core network <NUM> attempts to transmit the portion of the initial services request <NUM> to the IMS network <NUM> may be interrupted. Accordingly, in these implementations, the IMS network <NUM> may not receive the initial services request <NUM>. As a result, the IMS network <NUM> may not be triggered to transmit, or may have no way of transmitting, the first tunnel request <NUM> to the core network <NUM>.

In any case, the wait time <NUM>, which the first UE <NUM> may be tracking since the transmission of the initial services request <NUM>, may expire without the first UE <NUM> having received a confirmation that an appropriate dedicated tunnel has been established in the core network <NUM> and/or the IMS network <NUM>, such as information indicating a context of a dedicated tunnel for the requested services. In response to the wait time <NUM> expiring, the first UE <NUM> may transmit, to the core network <NUM>, a request to reestablish at least one connection <NUM>.

In response to receiving the request to reestablish connection(s) <NUM>, the core network <NUM> may reset one or more connections associated with the core network <NUM> and/or the IMS network <NUM>. In particular, the core network <NUM> may reestablish a connection between the core network <NUM> and the IMS network <NUM>. Accordingly, the previous interruption between the core network <NUM> and the IMS network <NUM>, which prevented the initial services request <NUM> from reaching the IMS network <NUM>, can be resolved. In some implementations, the core network <NUM> may perform an initial IMS registration process, thereby reestablishing multiple connections throughout and between the core network <NUM> and the IMS network <NUM>.

In some cases, the first UE <NUM> may also transmit, to the core network <NUM>, a second services request <NUM>, which requests the same or similar services as those requested in the initial services request <NUM>. In some cases, the request to reestablish the connection(s) <NUM> may include the second services request <NUM>.

The core network <NUM> may transmit the second services request <NUM> to the IMS network <NUM>. In response to receiving the second services request <NUM>, the IMS network <NUM> may initiate the establishment of at least a portion of the dedicated tunnel through the IMS network <NUM>.

The IMS network <NUM> may transmit a second tunnel request <NUM> to the core network <NUM>. The second tunnel request <NUM> may indicate the portion of the dedicated tunnel that has been established through the IMS network <NUM> and/or may request the core network <NUM> to establish a portion of the dedicated tunnel through the core network <NUM>.

In particular implementations, because the reestablished interface between the core network <NUM> and the IMS network <NUM> may be intact, the second services request <NUM> may successfully be transmitted from the core network <NUM> to the IMS network <NUM>. Accordingly, the IMS network <NUM> may receive the second services request <NUM> from the core network <NUM>. In some cases, the core network <NUM> may successfully receive the second tunnel request <NUM> from the IMS network <NUM> over the reestablished interface.

In response to receiving the second tunnel request <NUM>, the core network <NUM> may transmit a dedicated tunnel context message <NUM> to the first UE <NUM>. The dedicated tunnel context message <NUM> may indicate, to the first UE <NUM>, that the dedicated tunnel has been established. In some cases, the first UE <NUM> may identify that the dedicated tunnel has been established by receiving some other type of message from the core network <NUM>.

The first UE <NUM> may subsequently exchange services <NUM> with another entity (e.g., a content server associated with the WAN <NUM>, the second UE <NUM>, or the like) via the dedicated tunnel. The services <NUM> may be delivered to the first UE <NUM> by a QoS level guaranteed by the dedicated tunnel.

Although <FIG> depicts a scenario in which a connection between the core network <NUM> and the IMS network <NUM> is intact when the core network <NUM> transmits the initial services request <NUM> to the IMS network <NUM>, implementations are not so limited. In some cases, the initial services request <NUM> may be transmitted from the core network <NUM> over an interrupted connection. In various examples, an interrupted connection within the core network <NUM> may prevent the core network <NUM> from establishing the dedicated tunnel, an interrupted connection within the IMS network <NUM> may prevent the IMS network <NUM> from establishing the dedicated tunnel, or the like. In various implementations, for various reasons, the first UE <NUM> may not receive a confirmation that the dedicated tunnel has been established within the wait time <NUM>.

<FIG> and <FIG> illustrate example processes in accordance with embodiments of the present invention. These processes are illustrated as logical flow graphs, each operation of which represents a sequence of operations that can be implemented in hardware, software, or a combination thereof. In the context of software, the operations represent computer-executable instructions stored on one or more computer-readable storage media that, when executed by one or more processors, perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, and the like that perform particular functions or implement particular abstract data types. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations can be combined in any order and/or in parallel to implement the processes.

<FIG> illustrates an example recursive process <NUM> for resetting a network connection using a wait time by retransmitting a services request to a core network. In various implementations, the process <NUM> can be performed by a User Equipment (UE), such as the first UE <NUM> described above with reference to <FIG>.

At <NUM>, a request for services can be transmitted to a core network <NUM>. In some implementations, the request includes at least one of a Session Initiation Protocol (SIP) message or a Session Description Protocol (SDP) message. In particular examples, the request can be a SIP INVITE message, a Provisional Acknowledgement (PRACK) message, or the like. For instance, the request may be a request to initiate a session that involves the delivery and/or exchange of the services by the entity performing the process <NUM>.

The services may be Quality of Service (QoS)-sensitive services that are associated with a minimum QoS level. In particular implementations, the request can be for Guaranteed Bit Rate (GBR) services. For instance, the services may be voice services. In various implementations, the requested services may be pre-associated with a dedicated tunnel. For example, the type of requested services may be pre-associated with a dedicated bearer, a dedicated 5th Generation (<NUM>) QoS Indicator (5QI) data flow, or the like. In various implementations, the request <NUM> may cause the core network and/or an Internet Protocol (IP) Multimedia Subsystem (IMS) network connected to the core network to at least attempt to establish the dedicated tunnel through the core network and the IMS network.

In various implementations, the core network can be a 4th Generation (<NUM>) core network, a 5th Generation (<NUM>) core network, or a combination thereof. In some instances, a Circuit-Switched (CS) network may be unavailable to the device performing the process <NUM>. The request may be transmitted to the core network via a Radio Access Network (RAN), in particular examples.

At <NUM>, the process includes determining whether a confirmation of a dedicated tunnel has been received. In some implementations, the core network may establish a suitable dedicated tunnel corresponding to the requested services and confirm that the dedicated tunnel has been established by providing at least one message to the entity performing the process <NUM>. For example, the entity performing the process <NUM> may receive information indicating a context of the dedicated tunnel.

If the confirmation is determined to have been received at <NUM>, the process <NUM> proceeds to <NUM>. At <NUM>, the requested services are received via the established dedicated tunnel. Accordingly, the services may be delivered via a minimum QoS level corresponding to the established dedicated tunnel.

On the other hand, if the confirmation is determined to have not been received at <NUM>, the process <NUM> proceeds to <NUM>. At <NUM>, the process <NUM> includes determining whether a wait time has expired. In some cases, the wait time may begin when the request is transmitted at <NUM>. In certain examples, the wait time may begin when a message (e.g., a 18X response message, an Acknowledgement (ACK) message, or the like) is received from the core network in response to the request. According to various implementations, a length of the wait time can be between about <NUM> seconds to about <NUM> seconds. For example, the wait time can be about <NUM> seconds.

If the wait time is determined to have not expired at <NUM>, the process <NUM> returns to <NUM>. However, if the wait time is determined to have expired at <NUM>, the process <NUM> proceeds to <NUM>. At <NUM>, the session is determined to have been terminated. In some examples, the session is automatically terminated by the entity performing the process <NUM>. For instance, if the session is a voice call, the voice call may be dropped. In some instances, the session is terminated in response to a user input. For example, in the case of a voice call, a user may "hang up" the call.

At <NUM>, a request to reset one or more network connections is transmitted to the core network. In various implementations, the network connection(s) may be reset in response to the request at <NUM>. The network connection(s) may include at least one network connection that was interrupted or otherwise malfunctioning, and that prevented the establishment of the dedicated tunnel through the core network and/or the IMS network. The network connection(s) may be in the core network, in the IMS network, or between the core network and the IMS network. In the case of a <NUM> core network, the network connection(s) may include at least one of a Gx interface, an Rx interface, or an SGi interface. In the case of a <NUM> core network, the network connection(s) may include an N5 interface. Accordingly, by causing the network connection(s) to be reset. In some instances, <NUM> includes initiating an IMS registration process, such that multiple network connections associated with the core network and/or the IMS network are reset.

After <NUM>, the process <NUM> returns back to <NUM>. If the interrupted network connection(s) are reset in response to the request transmitted at <NUM>, a dedicated tunnel may be successfully established using the reset network connection(s) in a subsequent cycle of the process <NUM>. Accordingly, even if the services were not successfully received in an initial cycle of the process <NUM>, the services may be received in a subsequent cycle of the process <NUM>.

<FIG> illustrates an example process <NUM> for automatically resetting a network connection using a wait time. In various implementations, the process <NUM> can be performed by a User Equipment (UE), such as the first UE <NUM> described above with reference to <FIG>.

At <NUM>, a request for Quality of Service (QoS)-sensitive services is transmitted to a core network. In some implementations, the request includes at least one of a Session Initiation Protocol (SIP) message or a Session Description Protocol (SDP) message. In particular examples, the request can be a SIP INVITE message. The request may initiate a session.

The QoS-sensitive services may be associated with a minimum QoS level. In particular implementations, the request can be for Guaranteed Bit Rate (GBR) services. For instance, the services may be voice services. In various implementations, the requested services may be pre-associated with a dedicated tunnel. For example, the type of requested services may be pre-associated with a dedicated bearer, a dedicated 5th Generation (<NUM>) QoS Indicator (5QI) data flow, or the like.

At <NUM>, a wait time is determined to have expired without having received a confirmation of the dedicated tunnel. In some cases, the wait time may begin when the request is transmitted at <NUM>. In certain examples, the wait time may begin when a message (e.g., a Provisional Acknowledgement (PRACK) message) is received from the core network in response to the request. According to various implementations, a length of the wait time can be between about <NUM> seconds to about <NUM> seconds. For example, the wait time can be about <NUM> seconds.

In some implementations, the core network may attempt to establish a suitable dedicated tunnel corresponding to the requested QoS-sensitive services and confirm that the dedicated tunnel has been established by providing at least one message to the entity performing the process <NUM>. However, in various implementations, an interruption at a connection (e.g., at least one of a Gx interface, an Rx interface, an Sgi interface, or an N4 interface) associated with a core network or an Internet Protocol (IP) Multimedia Subsystem (IMS) network may prevent the dedicated tunnel from being established in a timely manner. The dedicated tunnel may fail to be established through the core network and the IMS network, and core network may fail to transmit information indicating a context of an established dedicated bearer, in various examples.

At <NUM>, a request to reestablish one or more connections is automatically transmitted to the core network. The request may cause the core network to reset the connection(s). The connection(s) may include the interrupted connection that prevented the establishment of the dedicated tunnel. For example, the connection(s) may include at least one of a Gx interface, an Rx interface, an SGi interface, or an N4 interface associated with the core network and/or the IMS network. In some cases, multiple connections associated with the core network and/or the IMS network can be reset. For instance, an IMS registration process can be performed in response to the request transmitted at <NUM>.

As a result of the process <NUM>, the QoS-sensitive services can be re-requested and successfully delivered, despite the interrupted connection. By resetting the interrupted connection, a dedicated tunnel may be successfully established through the core network and the IMS network in response to subsequent requests for services.

<FIG> illustrates example device(s) <NUM> to cause a connection associated with an Internet Protocol (IP) Multimedia Subsystem (IMS) network to be reset, as described herein. In some embodiments, some or all of the functionality discussed in connection with <FIG> can be implemented in the device(s) <NUM>. Further, the device(s) <NUM> can be implemented as one or more server computers, a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, such as a cloud infrastructure, and the like. It is to be understood in the context of this disclosure that the device(s) <NUM> can be implemented as a single device or as a plurality of devices with components and data distributed among them.

As illustrated, the device(s) <NUM> comprise a memory <NUM>. In various embodiments, the memory <NUM> is volatile (including a component such as Random Access Memory (RAM)), non-volatile (including a component such as Read Only Memory (ROM), flash memory, etc.) or some combination of the two.

The memory <NUM> may include various components, such as at least one service request component <NUM> and at least one wait time component <NUM>. The service request component(s) <NUM> may include instructions for requesting services from a core network. The wait time component <NUM> may include instructions for determining that a wait time has expired without receiving information about a context of an established dedicated tunnel for the services, as well as for taking certain actions based on the determination. The service request component(s) <NUM>, the wait time component(s) <NUM>, and various other elements stored in the memory <NUM> can comprise methods, threads, processes, applications, or any other sort of executable instructions. The service request component(s) <NUM>, the wait time component(s) <NUM>, and various other elements stored in the memory <NUM> can also include files and databases.

The memory <NUM> may include various instructions (e.g., instructions in the service request component(s) <NUM> and/or the wait time component(s) <NUM>), which can be executed by at least one processor <NUM> to perform operations. In some embodiments, the processor(s) <NUM> includes a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), or both CPU and GPU, or other processing unit or component known in the art.

The device(s) <NUM> can also include additional data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Such additional storage is illustrated in <FIG> by removable storage <NUM> and non-removable storage <NUM>. Tangible computer-readable media can include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. The memory <NUM>, removable storage <NUM>, and non-removable storage <NUM> are all examples of computer-readable storage media. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, Digital Versatile Discs (DVDs), Content-Addressable Memory (CAM), or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the device(s) <NUM>. Any such tangible computer-readable media can be part of the device(s) <NUM>.

As illustrated in <FIG>, the device(s) <NUM> can also include one or more wired or wireless transceiver(s) <NUM>. For example, the transceiver(s) <NUM> can include a Network Interface Card (NIC), a network adapter, a Local Area Network (LAN) adapter, or a physical, virtual, or logical address to connect to the various base stations or networks contemplated herein, for example, or the various user devices and servers. To increase throughput when exchanging wireless data, the transceiver(s) <NUM> can utilize Multiple-Input/Multiple-Output (MIMO) technology. The transceiver(s) <NUM> can include any sort of wireless transceivers capable of engaging in wireless, Radio Frequency (RF) communication. The transceiver(s) <NUM> can also include other wireless modems, such as a modem for engaging in Wi-Fi, WiMAX, Bluetooth, or infrared communication.

The device(s) <NUM> also can include input device(s) <NUM>, such as a keypad, a cursor control, a touch-sensitive display, voice input device, etc., and output device(s) <NUM> such as a display, speakers, printers, etc. These devices are well known in the art and need not be discussed at length here. In particular implementations, a user can provide input to the device(s) <NUM> via a user interface associated with the input device(s) <NUM> and/or the output device(s) <NUM>.

Claim 1:
A method performed by a User Equipment, UE, comprising:
transmitting (<NUM>), to a core network (<NUM>), a request for services (<NUM>) from the core network (<NUM>) and an Internet Protocol, IP, Media Subsystem, IMS, network (<NUM>);
determining (<NUM>) that a wait time (<NUM>) has expired without having received a first response confirming that a first dedicated bearer through the core network and the IMS network has been established for the services;
in response to determining that a first wait time has expired, transmitting (<NUM>), to the core network, a request (<NUM>) to reset at least one connection associated with the core network and the IMS network to enable establishment of a second dedicated bearer through the core network and the IMS network;
wherein transmitting the request to reset causes the core network to reset at least one of a Gx interface, an Rx interface, or an SGi interface;
receiving, from the core network within a second wait time, a second response (<NUM>) confirming that the second dedicated bearer through the core network and the IMS network has been established for the services; and
receiving (<NUM>) the services from the core network and the IMS network via the second dedicated bearer.