Managing transmissions of internet protocol multimedia subsystem packets

Abstract

A user equipment (UE) device in a mobile cellular network implements one or more techniques to maintain an Internet Protocol (IP) Multimedia Subsystem (IMS) service(s) when one or more data radio bearers (DRBs) associated are released by the network during the IMS service. For example, the UE transmits IMS packets for an IMS service to the network over at least a first DRB of a plurality of DRBs. Then, responsive to at least the first DRB being released during the IMS service, the UE continues at least a portion of the IMS service by transmitting the IMS packets associated with the at least a portion of the IMS service to the network over at least a second DRB of the plurality of DRBs.

Description

MANAGING TRANSMISSIONS OF INTERNET PROTOCOL MULTIMEDIA SUBSYSTEM PACKETSBACKGROUND

[0001] The advancement in mobile communication technologies has led to the development of the Internet Protocol (IP) Multimedia Subsystem (IMS), which is a standardized architectural framework for delivering IP multimedia services.Historically, mobile networks were primarily focused on voice communication, utilizing circuit-switched technology. However, with the advent of the Third Generation (3G) and subsequent generations of mobile communication technologies, there has been a paradigm shift towards packet-switched technology, enabling richer multimedia services over IP.

[0002] IMS plays an substantial role in this transition, offering a unified platform that integrates traditional voice services with internet-based data and multimedia services. The IMS architecture allows network operators to deliver a diverse range of services, including voice, video, messaging, and data services, across a common IP-based infrastructure. The versatility of IMS lies in its ability to operate over various access types, such as Global System for Mobile Communication (GSM), Wideband Code Division Multiple Access (WCDMA), Long-Term Evolution (LTE), Fifth Generation (5G), and even non-cellular networks such as Wi-Fi. User Equipment (UE) devices, such as smartphones, tablets, and other connected devices, are integral to the IMS ecosystem. These devices are configured with the necessary hardware and software to manage IMS services, including Voice over IP (VoIP), video calls, and converged messaging. The interaction between UEs and the IMS network is primarily managed through protocols such as the Session Initiation Protocol (SIP), which handles session management and control.

[0003] One of the key features of IMS is its ability to provide seamless service continuity and handover capabilities across different network types. This is particularly important in a mobile environment where users may transition between various types of network connections, such as moving from a cellular network to WiFi. IMS ensures that ongoing sessions, such as voice calls or data sessions, aremaintained without interruption during these transitions. However, interruptions can still occur for various reasons, including network congestion, signal loss, handover failures, or issues with the dedicated bearers. These interruptions, in many instances, result in an undesirable user experience.SUMMARY OF EMBODIMENTS

[0004] In accordance with one aspect, a method at a user equipment (UE) device includes transmitting Internet Protocol (IP) Multimedia Subsystem (IMS) packets for at least one IMS service to a network over at least a first data radio bearer (DRB) of a plurality of DRBs. At least a portion of the at least one IMS service is continued over at least a second DRB of the plurality of DRBs in response to releasing at least the first DRB during the at least one IMS service.

[0005] In at least some embodiments, the second DRB is a default DRB.

[0006] In at least some embodiments, the second DRB is a DRB established for a different IMS service.

[0007] In at least some embodiments, transmitting the IMS packets for the at least one IMS service includes transmitting a first set of IMS packets for the at least one IMS service over the at least first DRB, and transmitting a second set of IMS packets for the at least one IMS service over the at least second DRB. Continuing the at least a portion of the at least one IMS service includes transmitting the first set of IMS packets and the second set of IMS packets over the at least second DRB.

[0008] In at least some embodiments, transmitting the IMS packets for the at least one IMS service includes transmitting a first set of IMS packets for the at least one IMS service over one of the at least first DRB or the at least second DRB, and transmitting a second set of IMS packets for the at least one IMS service over a different one of the at least first DRB or the at least second DRB. Continuing the at least a portion of the at least one IMS service includes switching the at least one IMS service to a different IMS service. The first set of IMS packets is transmitted over a remaining one of the at least first DRB or the at least second DRB in response to releasing one of the at least first DRB or the at least second DRB.

[0009] In at least some embodiments, transmitting the IMS packets for the at least one IMS service includes transmitting a first set of IMS packets for the at least one IMS service over one of the at least first DRB or a third DRIB of the plurality of DRBs, and transmitting a second set of IMS packets for the at least one IMS service over a different one of the at least first DRB or the third DRB. Continuing the at least a portion of the at least one IMS service includes transmitting the first set of IMS packets and the second set of IMS packets over the at least second DRB in response to releasing the at least first DRB and the third DRB. The at least second DRB is a default DRB.

[0010] In at least some embodiments, transmitting the IMS packets for the at least one IMS service includes transmitting a first set of IMS packets for the at least one IMS service over one of the at least first DRB or a third DRB of the plurality of DRBs, and transmitting a second set of IMS packets for the at least one IMS service over a different one of the at least first DRB or the third DRB. Continuing the at least a portion of the at least one IMS service includes switching the at least one IMS service to a different IMS service. The second set of IMS packets is transmitted over the at least second DRB in response to releasing the at least first DRB and the third DRB. The at least second DRB is a default DRB.

[0011] In at least some embodiments, transmitting the IMS packets for the at least one IMS service includes transmitting a first set of IMS packets for a first IMS service over the at least first DRB, and transmitting a second set of IMS packets for a second IMS service over the at least second DRB. Continuing the at least a portion of the IMS service includes releasing the first IMS service in response to releasing the at least first DRB, and transmitting the second set of IMS packets over the at least second DRB.

[0012] In at least some embodiments, transmitting the IMS packets for the at least one IMS service includes transmitting a first set of IMS packets for a first IMS service over the at least first DRB, and transmitting a second set of IMS packets for a second IMS service over a third DRB of the plurality of DRBs. Continuing the at least a portion of the IMS service includes transmitting the first set of IMS packets and thesecond set of IMS packets over the at least second DRB in response to releasing the at least first DRB and the third DRB. The at least second DRB is a default DRB.

[0013] In at least some embodiments, transmitting the IMS packets for the at least one IMS service includes transmitting a first set of IMS packets for a first IMS service over the at least first DRB, and transmitting a second set of IMS packets for a second IMS service over a third DRB of the plurality of DRBs. Continuing the at least a portion of the IMS service includes releasing the first IMS service in response to releasing the at least first DRB and the third DRB, and transmitting the second set of IMS packets over the at least second DRB. The at least second DRB is a default DRB.

[0014] In at least some embodiments, continuing at least a portion of the at least one IMS service includes transmitting the IMS packets associated with the at least a portion of the IMS service to the network over the at least second DRB of the plurality of DRBs in response to a set of configuration information at the UE indicating that the UE is one of configured to perform the IMS service without the at least first DRB or is configured to perform the IMS service over the at least second DRB.

[0015] In at least some embodiments, the set of configuration information includes at least one bitmask, wherein each bit of the bitmask is associated with a different type of IMS packet.

[0016] In at least some embodiments, the at least one IMS service is changed to a different type of IMS service in response to at least one of downlink Real-time Transport Protocol packets or Real-time Transport Control Protocol packets associated with the at least one IMS service having not been received within a threshold amount of time after the transmitting the at least one IMS service over the at least second DRB.

[0017] In at least some embodiments, the at least one IMS service is ended in response to at least one of downlink Real-time Transport Protocol packets or Realtime Transport Control Protocol packets associated with the at least one IMS service having not been received within a threshold amount of time after the transmitting the at least one IMS service over the at least second DRB.

[0018] In at least some embodiments, transmitting the IMS packets for the at least one IMS service includes one of transmitting IMS voice packets for an IMS voice call over the first DRB; transmitting IMS voice packets for an IMS video call over one of the at least first DRB and the at least second DRB, and IMS video packets for the IMS video call over a different one of the at least first DRB and the at least second DRB; transmitting IMS voice packets for an IMS video call over one of the at least first DRB and a third DRB of the plurality of DRBs, and IMS video packets for the IMS video call over a different one of the at least first DRB and the third DRB; transmitting IMS text packets for an IMS Real-time Text (RTT) call over the at least first DRB;

[0019] transmitting IMS voice packets for an IMS voice call over the at least first DRB or the at least second DRB, and IMS text packets for an IMS RTT call over a different one of the at least first DRB and the at least second DRB; and transmitting IMS voice packets for an IMS voice call over the at least first DRB or a third DRB of the plurality of DRBs, and IMS text packets for an IMS RTT call over a different one of the at least first DRB and the third DRB.

[0020] In accordance with another aspect, a user equipment device includes one or more radio frequency (RF) modems configured to wirelessly communicate with at least one network, one or more processors coupled to the one or more RF modems, and at least one memory storing executable instructions, the executable instructions configured to manipulate at least one of the one or more processors or the one or more RF modems to perform the methods described above and herein.BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The present disclosure may be better understood, and its numerous features and advantages made apparent to those skilled in the art by referencing the accompanying drawings. The use of the same reference symbols in different drawings indicates similar or identical items.

[0022] FIG. 1 is a diagram illustrating an example wireless system employing a UE device configured to maintain at least one IMS service when a dedicated bearer associated with the IMS service is abnormally released by the network in accordance with some embodiments.

[0023] FIG. 2 is a block diagram illustrating example modes of an IMS packet transmission management mechanism employed by the UE device of FIG. 1 in accordance with some embodiments.

[0024] FIG. 3 is a diagram illustrating one example of IMS transmission configuration information employed by the UE device of FIG. 1 in accordance with some embodiments.

[0025] FIG. 4 is a diagram illustrating another example of IMS transmission configuration information employed by the UE device of FIG. 1 in accordance with some embodiments.

[0026] FIG. 5 is a diagram illustrating an example hardware configuration of a UE device of the wireless system of FIG. 1 in accordance with some embodiments.

[0027] FIG. 6 is a signaling diagram illustrating an example of a method for performing one or more of the IMS transmission management techniques when the network releases a dedicated bearer during an IMS voice call in accordance with some embodiments.

[0028] FIG. 6 is a signaling diagram illustrating an example of a method for performing one or more of the IMS transmission management techniques when the network releases a dedicated bearer during an IMS voice call in accordance with some embodiments.

[0029] FIG. 7 and FIG. 8 are signaling diagrams together illustrating an example of a method for performing one or more IMS transmission management techniques when the network releases a dedicated DRB during an IMS video call in accordance with some embodiments.

[0030] FIG. 9 and FIG. 10 are signaling diagrams together illustrating an example of a method for performing one or more IMS transmission management techniques when the network releases a dedicated DRB during an IMS voice call and an IMS Real-time Text call in accordance with some embodiments.

[0031] FIG. 11 is a diagram of an example method for maintaining an IMS service when the network releases all dedicated bearers during the IMS service in accordance with some embodiments.

[0032] FIG. 12 is a diagram of an example method for maintaining at least a portion of an IMS service when the network releases at least one dedicated bearer during the IMS service while at least one other dedicated bearer remains established in accordance with some embodiments.

[0033] FIG. 13 is a diagram of another example method for maintaining a portion of an IMS service when the network releases at least one dedicated bearer during the IMS service while at least one other dedicated bearer remains established in accordance with some embodiments.

[0034] FIG. 14 is a diagram of an example method for configuring a UE to manage IMS transmissions when the network releases a dedicated bearer during an IMS service in accordance with some embodiments.

[0035] FIG. 15 is a diagram of another example method for configuring a UE to manage IMS transmissions when the network releases a dedicated bearer during an IMS service in accordance with some embodiments.DETAILED DESCRIPTION

[0036] In the field of cellular networks, IMS continues to be a crucial architectural framework, not only for LTE networks but also extending its capabilities into the domain of 5G. Initially developed by the 3rd Generation Partnership Project (3GPP), IMS was designed to provide a standardized network for telephony and internetbased voice and multimedia services over various network types, including GSM, WCDMA, LTE, and Wi-Fi. With the advent of 5G, IMS's role has further expanded, offering enhanced services that leverage the high-speed, low-latency capabilities of 5G technology.

[0037] An important function of IMS in both LTE and 5G networks is the management of data sessions, particularly through Data Radio bearers (DRBs), such as default and dedicated bearers. In LTE, a bearer is essentially a virtual tunnel fortransferring data packets between the user's device and the network. The default bearer in LTE, which is a non-guaranteed bit Rate (non-GBR) bearer and is established as soon as a device connects to the network, handles all regular traffic like web browsing and email. The default bearer provides continuous IP connectivity between the user equipment and the Packet Data Network Gateway (PDN-GW), handling all non-dedicated traffic like web browsing and email. The default bearer typically offers a lower Quality of Service (QoS), sufficient for general data use. Dedicated bearers, on the other hand, are used for high-priority services, such as Voice over LTE (VoLTE) or video calls, offering guaranteed bandwidth and low latency. These bearers are defined by specific traffic flows and parameters such as QoS Class Identifier (QCI) and Allocation and Retention Priority (ARP), ensuring high performance for critical services.

[0038] In 5G networks, the approach to managing data sessions becomes more sophisticated compared to LTE. 5G introduces "Network Slices", which are virtual networks designed for specific services or customer needs. Each network slice can have its own set of DRBs for User Plane data and Signaling Radio Bearers (SRBs) for Control Plane signaling. This system allows for more dynamic and efficient resource allocation, tailored to the diverse applications of 5G technology, such as Enhanced Mobile Broadband (eMBB), Ultra-Reliable Low Latency Communications (URLLC), and massive Machine Type Communications (mMTC).

[0039] However, challenges arise in situations where there's an unexpected release of a dedicated bearer for media (e.g., voice, video, text, or a combination thereof) during an ongoing IMS call, leading to poor user experience. For instance, when the network (NW) abnormally releases a dedicated bearer, the IMS network promptly reacts by sending a SIP BYE or CANCEL message with the reason cited as “Media bearer loss”. This action effectively ends the call immediately. The abnormal release of a dedicated bearer commonly occurs during handovers, particularly when an IMS connection is transferred from one radio access technology (RAT) to another, such as from cellular networks (e.g., LTE, New Radio (NR), etc.) to Wi-Fi. Normally, the network sends a Radio Resource Control (RRC) reconfiguration to release the dedicated bearers after the handover is complete. However, problems occur whenthere is a misalignment in handover status. For instance, the network might assume that the UE has successfully handed over to Wi-Fi, while in reality, the handover has failed, leaving the UE still connected over LTE. Additionally, environmental factors, such as a user moving to a different location (e.g., a hallway or outside a building) during a call, can also trigger handover issues. This movement can trigger a nonincall Wi-Fi to NR handover, which may initially be over VoWiFi but later switch to NR. If Voice over NR (VoNR) is not supported and the network initiates an EPS fallback (EPSFB) by sending an RRC release, the network does not configure the dedicated media bearer over LTE, leading to a call drop due to media bearer loss. In some instances, the network may also send an RRC Connection Reconfiguration message or a Deactivate EPS Bearer Context Request to release the dedicated media bearer, which also leads to a call drop.

[0040] As such, the following describes embodiments of systems and methods for a UE to manage the transmission of IMS packets such that call drops do not occur when a dedicated bearer is abnormally released or not configured by the network. As described in greater detail below, the UE establishes a first DRB, such as a default bearer, with the network based on an event. Examples of these events include an initial network attachment event, a re-establishment or re-attachment event, a handover event, changes in network configuration, initiating connections to different Packet Data Networks (PDNs), or the like. The UE communicates with the IMS via the first DRB to set up an IMS service (e.g., a voice call, a video call, or a Real-time Text (RTT) call) by exchanging various SIP messages with the IMS.Based on this process, the network and the UE establish a second DRB, such as a dedicated bearer.

[0041] For example, the UE sends a SIP Invite message to the IMS network using the established default bearer. The IMS network processes this Invite and requests the creation of the second DRB from the core network (CN). The CN responds to this request by sending a bearer resource allocation request to the Radio Access Network (RAN), specifically the base station (e.g., eNodeB or gNodeB). For example, the bearer resource allocation request is an Evolved Radio Access Bearer (E-RAB) Setup Request message or a Protocol Data Unit (PDU) Session Resource ModifyRequest message. The RAN, through the base station (BS), configures the required radio resources to establish the second DRB. The BS sends an RRC message to the UE, instructing the UE on how to configure its radio interface to align with the newly established DRB’s parameters. For example, the RRC message is an RRC Connection Reconfiguration message or a RRC Reconfiguration message. In at least some embodiments, the network and the UE establish one or more additional dedicated DRBs according to the processes described above. After the dedicated DRB(s) are established, the UE communicates packets for an IMS call (or service) over these DRB(s). For example, the UE, in some instances, uses the second DRB to communicate packets for a first IMS call (e.g., an IMS voice call, an IMS video call, or an IMS RTT call). If the UE has established an additional dedicated DRB(s), such as a third DRB, the UE uses this dedicated DRB to communicate packets for a second (different) IMS call or for a different type of data traffic for the first IMS service. For example, an IMS video call, in at least some instances, uses a dedicated DRB for audio packets and another dedicated DRB for video packets.

[0042] In some instances, the network abnormally releases one or more of the dedicated DRBs during an active IMS call, as described above, and sends an RRC Reconfiguration message to the UE, instructing the UE to adjust its radio parameters to match the updated network settings, such as changes in quality of service (QoS) or bandwidth allocation. In response to the RRC Reconfiguration message, the UE releases the corresponding dedicated DRB(s) and sends an RRC Reconfiguration Complete message to the network. However, instead of dropping the active IMS call(s) associated with the released dedicated DRB(s), the UE continues at least a portion of the IMS call. For example, if all dedicated DRBs have been released, the UE continues the IMS call by communicating its packets, or at least a portion thereof (e.g., audio packets only instead of audio and video packets), over the default DRB (e.g., the first DRB). However, if a dedicated DRB (e.g., the second DRB or third DRB) remains established, the UE continues communicating the IMS call packets, or a portion thereof, associated with the released dedicated DRB over this remaining dedicated DRB.

[0043] In at least some embodiments, when the UE releases the dedicated DRB(s) as described above, the UE determines if any additional dedicated DRBs remain established. If no DRBs remain established, the UE determines if it is configured to perform the IMS call (or a portion thereof), which was being performed over the released dedicated DRB(s), via the default DRB. For example, in at least some embodiments, the UE stores configuration information or data indicating that the UE is configured to transmit IMS audio packets, IMS voice packets, IMS text packets, a combination thereof, or none of these packets over the default DRB. In at least some embodiments, the configuration information is represented as a bitmask, with each bit representing a different type of IMS data traffic / packet. For example, one bit represents audio packets, another bit represents video packets, and another bit represents text packets. If a bit is enabled (or disabled), this indicates to the UE that it is configured to transmit the corresponding type of IMS packets via the default DRB. However, if a bit is disabled (or enabled), this indicates to the UE that it is not configured to transmit the corresponding IMS packets via the default DRB.

[0044] The UE, in at least some embodiments, stores separate configuration information for different Public Land Mobile Networks (PLMNs). The configuration information for these PLMNs may be the same or different. For example, the UE stores a first configuration information for a first PLMN and a second configuration information for a second PLMN. When the UE performs an IMS service (e.g., an IMS voice call, an IMS video call, or an IMS RTT call) on the first PLMN, the UE applies the first configuration information, and when the UE performs an IMS service (e.g., an IMS voice call, an IMS video call, or an IMS RTT call) on the second PLMN, the UE applies the second configuration information. In other embodiments, the UE stores single configuration information for multiple PLMNs. For example, the UE stores configuration information for a first PLMN and a second PLMN. When the UE performs an IMS service (e.g., an IMS voice call, an IMS video call, or an IMS RTT call) on the first PLMN or the second PLMN, the UE applies the configuration information.

[0045] In at least some embodiments, when the UE releases the dedicated DRB(s) as described above, and the UE determines at least one dedicated DRB remainsestablished, the UE determines if it is configured to transmit the type of IMS packets affected by the released dedicated DRB via any of the remaining dedicated DRBs. For example, in at least some embodiments, the UE stores configuration information or data indicating that the UE is configured to transmit IMS audio packets, IMS voice packets, IMS text packets, a combination thereof, or none of these packets over an existing dedicated DRB that has been established for a different component of the IMS call or a different IMS call altogether. In at least some embodiments, configuration information is stored for each type of dedicated DRB. For example, configuration information is stored for an audio-dedicated DRB, a video-dedicated DRB, and a text-dedicated DRB. This configuration information, in at least some embodiments, is represented as a bitmask, with each bit representing an IMS service, similar to that described above. If a bit is enabled (or disabled), this indicates to the UE that it is configured to transmit the corresponding type of IMS packets via the dedicated DRB associated with the bitmask. However, if a bit is disabled (or enabled), this indicates to the UE that it is not configured to transmit the corresponding type of IMS packets via the dedicated DRB associated with the bitmask.

[0046] For ease of illustration, the following techniques are described in an example context in which one or more UEs and one or more RANs implement at least a Fifth Generation (5G) New Radio (NR) standard (e.g., Third Generation Partnership Project (3GPP) Release 15, 3GPP Release 16, etc.) (hereinafter, "5G NR" or"5G NR standard"). However, it should be understood that the present disclosure is not limited to networks employing a 5G NR RAT configuration, but rather, the techniques described herein can be applied to any combination of different RATs employed at the UEs and the RANs. It should also be understood that the present disclosure is not limited to any specific network configurations or architectures described herein for implementing radio link failure detection at the UE. Instead, techniques described herein can be applied to any configuration of RANs. Also, the present disclosure is not limited to the examples and context described herein, but rather the techniques described herein can be applied to any network environment where a UE communicates with an IMS network to perform one or more IMS services. Moreover,the techniques described herein may be combined with any other suitable technique or combination of techniques.

[0047] FIG. 1 illustrates a mobile cellular network 100 (also referred to here as “network 100”) in accordance with at least some embodiments. As shown, the mobile cellular network 100 includes a user equipment (UE) 102 that is configured to communicate with one or more base stations (BSs) 104 (illustrated as BS 104-1 and BS 104-2) through one or more wireless communication links 106 (illustrated as wireless links 106-1 and 106-2). The UE 102, in at least some embodiments, includes any of a variety of wireless communication devices, such as a cellular phone, a cellular-enabled tablet computer or cellular-enabled notebook computer, a cellular-enabled wearable device, an automobile, or other vehicle employing cellular services (e.g., for navigation, provision of entertainment services, in-vehicle mobile hotspots, etc.), and so on. In at least some embodiments, the UE 102 employs a single RAT 108. In other embodiments, the UE 102 is a multi-mode UE that employs multiple RATs 108 (illustrated as RAT 108-1 and RAT 108-2). Examples of multiple RATs include cellular-based RATs, such as a 3GPP Long-Term Evolution (3GPP LTE) RAT, a 3GPP Fifth Generation New Radio (5G NR) RAT, a Wi-Fi RAT, and the like. It should be understood that although FIG. 1 only shows the UE 102 implementing two different RATs 108, the UE 102, in at least some implementations, implements three or more different RATs 108. In at least some embodiments, one or more RAT modules 110 (illustrated as RAT module 110-1 and RAT module 110-2) manage the RATs 108 and enable communication between the UE 102 and the radio access technology of the network 100. The one or more RAT modules 110, in at least some embodiments, include one or more of a modem chipset(s) of the UE 102, a protocol stack(s), driver software, or the like.

[0048] In at least some embodiments, the BSs 104 are implemented in a macrocell, microcell, small cell, picocell, and the like, or any combination thereof. Examples of base stations 104 include an Evolved Universal Terrestrial Radio Access Network Node B (E-UTRAN Node B), Evolved Node B (eNodeB or eNB), Next Generation (NG or NGEN) Node B (gNode B or gNB), and so on. The BSs 104 communicate with the UE 102 via the wireless links 106, which are implemented using any suitabletype of wireless link. The wireless links 106, in at least some embodiments, include a downlink of data and control information communicated from the base stations 104 to the UE 102, an uplink of data and control information communicated from the UE 102 to the BSs 104, or both. In at least some embodiments, the wireless links 106 (or bearers), such as data radio bearers (DRBs) and signal radio bearers (SRBs), are implemented using any suitable communication protocol or standard, or combination of communication protocols or standards, such as 3GPP 4G LTE, 5G NR, and so on. In at least some embodiments, multiple wireless links 106 are aggregated in a carrier aggregation to provide a higher data rate for the UE 102. Also, multiple wireless links 106 from multiple BSs 104 are configured, in at least some embodiments, for coordinated multipoint (CoMP) communication with the UE 102, as well as dual connectivity, such as single-RAT LTE-LTE or NR-NR dual connectivity, or multi-radio access technology (Multi-RAT) dual connectivity (MR-DC) including E-UTRA-NR dual connectivity (EN-DC), NGEN radio access network (RAN) E-UTRA-NR dual connectivity (NGEN-DC), and NR E-UTRA dual connectivity (NE-DC).

[0049] The BSs 104 collectively form a Radio Access Network (RAN) 112, such as an E-UTRAN or 5G NR RAN. The base stations 104 are connected to a core network (CN) 114 (illustrated as CN 114-1 and CN 114-2) via control-plane and userplane interfaces through one or more links 116 (illustrated as link 116-1 and link 116- 2). Depending on the configuration of the mobile cellular network 100, the core network 114 is either an Evolved Packet Core (EPC) network 114-1 or a 5G Core Network (5GC) 114-2. For example, in an E-UTRAN configuration or a 5G non- standalone (NSA) EN-DC configuration, the core network 114 is an EPC network 114-1 that includes, for example, a Mobility Management Entity (MME) 118, a Serving Gateway (SGW) 120, and a Packet Data Network Gateway (PGW) 122. The MME 118 provides control-plane functions, such as registration and authentication of multiple UEs 102, authorization, mobility management, and so on. The SGW 120 transfers user-plane packets related to audio calls, video calls, Internet traffic, and the like. The PGW 122 provides connectivity from the UE 102 to external packet data networks 124, such as the Internet 126 and an IMS network 128, by being the point of exit and entry of traffic for the UE 102. In a 5G standalone (SA) configuration or an NSA NE-DC or NGEN-DC configuration, the core network 114 is a 5GC network 114-2. The 5GC 114-2 includes, for example, an Access and Mobility Management function (AMF) 130, a User Plane Function (UPF) 132, and a Session Management Function (SMF) 134. The AMF 130 provides control-plane functions such as registration and authentication of multiple UEs 102, authorization, mobility management, and so on. The UPF 132 transfers user-plane packets related to audio calls, video calls, Internet traffic, and the like. The SMF 134 manages protocol data unit (PDU) sessions.

[0050] In at least some embodiments, the core network 114 communicatively couples the UE 102 to an IMS network 128 via the RAN 112. The IMS network 128 provides various IMS services to the UE 102, such as IMS short messages, IMS unstructured supplementary service data (USSD), IMS value-added service data, IMS supplementary service data, IMS voice calls, and IMS video calls. To this end, an entity (e.g., a server or a group of servers) operating in the IMS network 128 supports packet exchange with the UE 102. The packets convey signaling (such as session initiation protocol (SIP) messages, IP messages, or other suitable messages) as well as data (or media), such as voice or video. In at least some embodiments, the IMS network includes entities (not shown) such as a Proxy Call Session Control Function (P-CSCF), an Interrogating Call Session Control Function (l-CSCF), a Serving Call Session Control Function (S-CSCF), a Home Subscriber Server (HSS), a Media Gateway Control Function (MGCF), and the like.

[0051] In some instances, the network 100 abnormally or unexpectedly releases a dedicated DRB(s) for various reasons, as described above. The network 100 sends the UE 102 a SIP BYE or CANCEL message with the reason cited as “Media bearer loss”. When a conventionally configured UE receives this message from the network, the UE typically releases the dedicated DRB(s) on its end and the call / service ends, which leads to a poor user experience. However, the UE 102 of one or more embodiments employs at least one IMS packet transmission management mechanism 136 (also referred to herein as “transmission management mechanism 136”) for managing the transmission of packets for an IMS call / service when the associated dedicated DRB is released by the network 100 during an IMS call. The techniques implemented by transmission management mechanism 136 allow for IMSpackets associated with an abnormally released dedicated DRB to be continued over the default DRB or another dedicated DRB if available, such that the IMS call is continued instead of being terminated.

[0052] For example, FIG. 2 illustrates various example modes employed singularly or in various combinations by the UE 102 as part of the IMS packet transmission management mechanism 136 in accordance with at least some embodiments. Each of these modes is discussed in greater detail below with respect to FIG. 3 to FIG. 15. One such mode includes a first IMS packet transmission manage mode 202. During this mode, the IMS packet transmission management mechanism 136 performs one or more operations to maintain an IMS call when all dedicated DRBs(s) established for an IMS call are released by the network 100. For example, if all dedicated DRBs have been released, the transmission management mechanism 136 configures the UE 102 to transmit packets for the IMS call (or a portion thereof) affected by the released DRB(s) over the default DRB. For example, if all dedicated DRBs have been abnormally released by the network 100, the transmission management mechanism 136 configures the UE 102 to transmit at least one of voice packets, video packets, or text packets for one or more affected IMS calls using the default DRB.

[0053] As an example, if the network 100 releases all dedicated DRBs during an IMS video (or text) call, the transmission management mechanism 136, in at least some embodiments, configures the UE 102 to transmit all IMS packets over the default DRB. In at least some embodiments, if there are no DL IMS video (or text) packets received within a threshold amount of time, the UE 102 downgrades the IMS video (or text) call to an IMS voice call only. Stated differently, the UE changes the IMS service to a different type of IMS service. Once the IMS call is downgraded to an IMS voice only call, if there are no DL RTP / RTCP packets received within a threshold amount of time, the UE 102 ends the IMS voice call due to RTP / RTCP inactivity.

[0054] Another mode includes a second IMS packet transmission manage mode 204. During this mode, the IMS packet transmission management mechanism 136 performs one or more operations to maintain an IMS call when at least one dedicated DRB(s) is released by the network 100 during an IMS call and at least one otherdedicated DRB remains established for the IMS call. In at least some embodiments, the transmission management mechanism 136 configures the UE 102 to transmit the IMS packets associated with the released dedicated DRB(s) over the remaining dedicated DRB(s). As an example, consider an IMS video call having a first dedicated DRB established for audio packets and a second DRB established for video packets. If the first dedicated DRB is released by the network 100 during the IMS call, the transmission management mechanism 136 configures the UE 102 to transmit the audio packets, which were previously being transmitted over the first dedicated DRB, over the second DRB along with the video packets.

[0055] In at least some embodiments, if the network 100 only releases the dedicated DRB for voice media during an IMS video (or text) call, the transmission management mechanism 136 configures the UE 102 to transmit IMS voice packets over the default DRB. However, the UE 102 remains configured to transmit video packets, text packets, or both over the existing dedicated DRB(s). In at least some embodiments, if there are no downlink (DL) Real-Time Transport Protocol (RTP) or Real-Time Transport Control Protocol (RTCP) packets received within a threshold amount of time, the UE 102 ends the IMS call due to RTP / RTCP inactivity.

[0056] If the network 100 releases one or both of the video or text dedicated DRB(s) during the IMS video (or text) call, the transmission management mechanism 136, in at least some embodiments, configures the UE 102 to transmit the IMS video packets, the IMS text packets, or both over the default DRB. In other embodiments, the transmission management mechanism 136 configures the UE 102 to transmit the IMS video packets, the IMS text packets, or both over the dedicated DRB established for voice packets. If there are no DL IMS video / text packets received within a threshold amount of time, the UE 102, in at least some embodiments, downgrades the IMS call to a voice only IMS call. In at least some embodiments, the UE 102 implements an RTC / RTCP timer, QoS timer, a combination thereof, or the like to determine if the threshold(s) described above has been reached.

[0057] In at least some embodiments, the UE 102 maintains a set of IMS transmission configuration information 138 (also referred to herein as “configuration information 138”) that is used by the transmission management mechanism 136 todetermine how to manage IMS packet transmission when the network 100 abnormally releases a dedicated DRB(s) during an IMS call. For example, in at least some embodiments, when the transmission management mechanism 136 detects that a dedicated DRB(s) has been released during an active IMS call, the transmission management mechanism 136 determines if any additional dedicated DRBs remain established. If no established dedicated DRBs remain, the transmission management mechanism 136 uses the configuration information 138 to determine if the UE 102 is able to be configured to transmit the IMS packets for the current IMS call, which were being transmitted over the released dedicated DRB(s), via the default DRB. For example, the configuration information 138 indicates that the UE 102 is configured to transmit IMS audio packets, IMS voice packets, IMS text packets, a combination thereof, or none of these packets over the default DRB. The UE 102, in at least some embodiments, obtains the configuration information 138 from the network 100, the network operator, a combination thereof, or the like. One or more of these entities, in at least some embodiments, also configure or generate the configuration information 138.

[0058] In at least some embodiments, the configuration information 138 is represented as a bitmask, with each bit representing a different type of IMS data traffic / packet. For example, one bit represents audio packets, another bit represents video packets, and another bit represents text packets. If a bit is enabled (or disabled), this indicates to the transmission management mechanism 136 that the UE 102 is configured (or is configurable) to transmit the corresponding type of IMS packets via the default DRB. However, if a bit is disabled (or enabled), this indicates that the UE 102 is not configured (or configurable) to transmit the corresponding IMS packets via the default DRB.

[0059] FIG. 3 shows different examples of the configuration information 138 considered by the transmission management mechanism 136 when all dedicated DRBs are released by the network 100 during an IMS call. In the example illustrated in FIG. 3, the configuration information 138 is implemented as a 3-bit bitmask 302 (illustrated as “bitmask 302-1”). In this example, the first bit 304-1 (bit 0) represents IMS audio packets, the second bit 306-1 (bit 1) represents IMS video packets, andthe third bit 308-1 (bit 2) represents IMS text packets. It should be understood that bitmasks of other lengths and configurations or data structures other than bitmasks are applicable as well. For example, a first variable represents IMS audio packets, a second variable represents IMS video packets, and a third variable represents IMS text packets. The first, second, and third variables are the same data types (e.g., integer or unsigned integer) or grouped into a single data type (e.g., a structure or a list).

[0060] The transmission management mechanism 136, in this example, processes the bitmask 302-1 to determine how the UE 102 is configured (or how to configure the UE 102) for IMS packet transmission. For example, if the bitmask 302-1 is set to a first configuration 310-1 (e.g., 000), the transmission management mechanism 136 determines that the UE 102 cannot transmit any IMS voice packets, IMS video packets, or IMS text packets over the default DRB. Therefore, the UE 102 operates according to one or more specifications. If the bitmask 302-1 is set to a second configuration 310-2 (e.g., 001), the transmission management mechanism 136 configures the UE 102 to only transmit IMS audio packets over the default DRB but not IMS video packets or IMS text packets. If the bitmask 302-1 is set to a third configuration 310-3 (e.g., 010), the transmission management mechanism 136 configures the UE 102 to only transmit IMS video packets over the default DRB but not IMS audio packets or IMS text packets. If the bitmask 302-1 is set to a fourth configuration 310-4 (e.g., 011), the transmission management mechanism 136 configures the UE 102 to transmit IMS audio and video packets over the default DRB but not IMS text packets. If the bitmask 302-1 is set to a fifth configuration 310-5 (e.g., 100), the transmission management mechanism 136 configures the UE 102 to only transmit IMS text packets over the default DRB but not IMS audio packets or IMS video packets. If the bitmask 302-1 is set to a sixth configuration 310-6 (e.g., 111), the transmission management mechanism 136 configures the UE 102 to transmit IMS audio packets, IMS video packets, and IMS text packets over the default DRB.

[0061] As described above, in at least some embodiments, when the transmission management mechanism 136 detects that a dedicated DRB(s) has been releasedduring an active IMS call, the transmission management mechanism 136 determines if any additional dedicated DRBs remain established. If the transmission management mechanism 136 determines that at least one dedicated DRB remains established, the transmission management mechanism 136 processes the configuration information 138 to determine if the UE 102 is configured (or configurable) to transmit the IMS packets for the current IMS call, which were being transmitted over the released dedicated DRB(s), via another remaining dedicated DRB.

[0062] For example, FIG. 4 shows another example of the configuration information 138 considered by the transmission management mechanism 136 when a dedicated DRB is released by the network 100 during an IMS call, but at least one other dedicated DRB remains established. In this example, the remaining dedicated DRB is a media (voice) dedicated DRB. The first bit 304-2 (bit 0) of the bitmask 302 (illustrated a bitmask “302-2”) represents IMS video packets, and the second bit 306- 2 (bit 1) represents IMS text packets. The third bit 308-2 (bit 2) is not used in this example. It should be understood that bitmasks of other lengths and configurations or data structures other than bitmasks are applicable as well. Examples of the data structures are as described above. The transmission management mechanism 136, in this example, processes the bitmask 302-2 to determine how to configure the UE 102 for IMS packet transmission. For example, if the bitmask 302-2 is set to a first configuration 310-7 (e.g., 000), the transmission management mechanism 136 determines that the UE 102 cannot transmit any IMS video packets, IMS text packets, or both over the media (audio / voice) dedicated DRB. Therefore, the UE 102 operates according to one or more specifications. If the bitmask 302-2 is set to a second configuration 310-8 (e.g., 001), the transmission management mechanism 136 configures the UE 102 to only transmit IMS video packets over the media dedicated DRB but not IMS text packets. If the bitmask 302-2 is set to a third configuration 310-9 (e.g., 010), the transmission management mechanism 136 configures the UE 102 to only transmit IMS text packets over the media dedicated DRB but not IMS video packets. If the bitmask 302-2 is set to a fourth configuration 310-10 (e.g., 011), the transmission management mechanism 136 configures the UE 102 to transmit IMS video and text packets over the media dedicated DRB. In atleast some embodiments, if both bitmasks 302 are enabled and a default DRB remains, the media-dedicated DRB has higher priority than the default DRB for the transmission of IMS video packets and text packets.

[0063] In another example based on FIG. 4, the remaining dedicated DRB is a text dedicated DRB. The first bit 304-2 (bit 0) of the bitmask 302 (illustrated as bitmask “302-2”) represents I S video packets, and the second bit 306-2 (bit 1) represents IMS audio packets. The third bit 308-2 (bit 2) is not used in this example. It should be understood that bitmasks of other lengths and configurations or data structures other than bitmasks are applicable as well. Examples of the data structures are as described above. The transmission management mechanism 136, in this example, processes the bitmask 302-2 to determine how to configure the UE 102 for IMS packet transmission. For example, if the bitmask 302-2 is set to a first configuration 310-7 (e.g., 000), the transmission management mechanism 136 determines that the UE 102 cannot transmit any IMS video packets, IMS voice packets, or both over the text dedicated DRB. Therefore, the UE 102 operates according to one or more specifications. If the bitmask 302-2 is set to a second configuration 310-8 (e.g., 001), the transmission management mechanism 136 configures the UE 102 to only transmit IMS video packets over the text dedicated DRB but not IMS audio packets. If the bitmask 302-2 is set to a third configuration 310-9 (e.g., 010), the transmission management mechanism 136 configures the UE 102 to only transmit IMS voice packets over the text dedicated DRB but not IMS video packets. If the bitmask 302-2 is set to a fourth configuration 310-10 (e.g., 011), the transmission management mechanism 136 configures the UE 102 to transmit IMS video and audio packets over the text dedicated DRB. In at least some embodiments, if both bitmasks 302 are enabled and a default DRB remains, the text-dedicated DRB has higher priority than the default DRB for the transmission of IMS video packets and audio packets.

[0064] FIG. 5 illustrates an example device diagram 500 of a UE 102. In at least some embodiments, the device diagram 500 describes a UE that implements the management techniques for IMS packet transmission described herein. The UE 102 may include additional functions and interfaces that are omitted from FIG. 5 for the sake of clarity. The UE 102, in at least some embodiments, includes antennas 502, aradio frequency (RF) front end 504, and one or more RF transceivers 506 (e.g., a 3GPP 4G LTE transceiver 506-1 and a 5G NR transceiver 506-2) for communicating with one or more base stations 104 in a RAN 112, such as a 5G RAN, an E-UTRAN, a combination thereof, and so on. In at least some embodiments, the RF transceivers 506 are RF modems. The RF front end 504, in at least some embodiments, includes a transmitting (Tx) front end 504-1 and a receiving (Rx) front end 504-2. The Tx front end 504-1 includes components such as one or more power amplifiers (PA), drivers, mixers, filters, and so on. The Rx front end 504-2 includes components such as low-noise amplifiers (LNAs), mixers, filters, and so on. The RF front end 504, in at least some embodiments, couples or connects the one or more transceivers 506, such as the LTE transceiver 506-1 and the 5G NR transceiver 506- 2, to the antennas 502 to facilitate various types of wireless communication.

[0065] In at least some embodiments, the antennas 502 of the UE 102 include an array of multiple antennas configured similarly to or different from each other. The antennas 502 and the RF front end 504, in at least some embodiments, are tuned to or are tunable to one or more frequency bands, such as those defined by the 3GPP LTE, 3GPP 5G NR, IEEE wireless local area network (WLAN), IEEE wireless metropolitan area network (WMAN), or other communication standards. In at least some embodiments, the antennas 502, the RF front end 504, the LTE transceiver 506-1 , and the 5G NR transceiver 506-2 are configured to support beamforming (e.g., analog, digital, or hybrid) or in-phase and quadrature (l / Q) operations (e.g., I / Q modulation or demodulation operations) for the transmission and reception of communications with one or more base stations 104. By way of example, the antennas 502 and the RF front end 504 operate in sub-gigahertz bands, sub-6 GHz bands, above 6 GHz bands, or a combination of these bands defined by the 3GPP LTE, 3GPP 5G NR, or other communication standards.

[0066] In at least some embodiments, the antennas 502 include one or more receiving antennas positioned in a one-dimensional shape (e.g., a line) or a two- dimensional shape (e.g., a triangle, a rectangle, or an L-shape) for implementations that include three or more receiving antenna elements. While the one-dimensional shape enables the measurement of one angular dimension (e.g., an azimuth or anelevation), the two-dimensional shape enables two angular dimensions to be measured (e.g., both azimuth and elevation). Using at least a portion of the antennas 502, the UE 102 can form beams that are steered or un-steered, wide or narrow, or shaped (e.g., as a hemisphere, cube, fan, cone, or cylinder). The one or more transmitting antennas may have an un-steered omnidirectional radiation pattern or may produce a wide steerable beam. Either of these techniques enables the UE 102 to transmit a radio signal to illuminate a large volume of space. In some embodiments, the receiving antennas generate thousands of narrow steered beams (e.g., 2000 beams, 4000 beams, or 6000 beams) with digital beamforming to achieve desired levels of angular accuracy and angular resolution.

[0067] The UE 102, in at least some embodiments, includes one or more sensors 508 implemented to detect various properties such as one or more of temperature, supplied power, power usage, battery state, or the like. Examples of sensors include a thermal sensor, a battery sensor, a power usage sensor, and so on.

[0068] The UE 102 also includes at least one processor 510. The processor 510, in at least some embodiments, is a single-core processor or a multiple-core processor composed of a variety of materials, such as silicon, polysilicon, high-K dielectric, copper, and so on. In at least some embodiments, the processor 510 is implemented at least partially in hardware, including, for example, components of an integrated circuit or a system-on-a-chip (SoC), a digital-signal-processor (DSP), an applicationspecific integrated circuit (ASIC), a field-programmable gate array (FPGA), a complex programmable logic device (CPLD), other implementations in silicon or other hardware, or a combination thereof.

[0069] Examples of the processor(s) 510 include a communication processor, an application processor, microprocessors, DSPs, controllers, and so on. A communication processor, in at least some embodiments, is implemented as a modem baseband processor, software-defined radio module, configurable modem (e.g., multi-mode, multi-band modem), wireless data interface, wireless modem, or so on. In at least some embodiments, a communication processor supports one or more of data access, messaging, or data-based services of a wireless network, as well as various audio-based communication (e.g., voice calls). An application processor, inat least some embodiments, provides computing resources to applications executing on the UE 102. For example, an application provides a self-contained operating environment that delivers system capabilities (e.g., graphics processing, memory management, and multimedia processing) to support applications executing on the UE 102.

[0070] The UE 102 further includes a non-transitory computer-readable storage media 512 (CRM 512). The computer-readable storage media described herein excludes propagating signals. The CRM 512, in at least some embodiments, includes any suitable memory or storage device such as random-access memory (RAM), static RAM (SRAM), dynamic RAM (DRAM), non-volatile RAM (NVRAM), read-only memory (ROM), or Flash memory useable to store device data 514 of the UE 102. In at least some embodiments, the device data 514 includes user data, multimedia data, beamforming codebooks, applications 516, a user interface(s) 518, an operating system of the UE 102, and so on, which are executable by the processor(s) 510 to enable user-plane communication, control-plane signaling, and user interaction with the UE 102. The user interface 518, in at least one embodiment, is configured to receive inputs from a user of the UE 102. In at least some embodiments, the user interface 518 includes a graphical user interface (GUI) that receives the input information via a touch input. In other instances, the user interface 518 includes an intelligent assistant that receives the input information via an audible input or speech. Alternatively, or additionally, the operating system of the UE 102 is maintained as firmware or an application on the CRM 512 and executed by the processor(s) 510.

[0071] The CRM 512, in at least some embodiments, the CRM 512 further includes the IMS transmission configuration information 136 and either or both of a communication manager 520 and an IMS transmission management manager 522. Alternatively, or additionally, either or both of the communication manager 520 and the IMS transmission management manager 522, in at least some embodiments, is implemented in whole or part as hardware logic or circuitry integrated with or separate from other components of the UE 102

[0072] In at least some embodiments, the communication manager 520 configures the RF front end 504, the LTE transceiver (modem) 506-1 , the 5G NR transceiver (modem) 506-2, or a combination thereof, to perform one or more wireless communication operations. The IMS transmission management manager 522, in at least some embodiments, implements the IMS transmission management module mechanism(s) 136 described above with respect to FIG. 1 to FIG. 4 for managing IMS packet transmission when one or more dedicated DRBs are released by the network 100 during an IMS call.

[0073] FIG. 6 is a signaling diagram illustrating an example of a method 600 for performing one or more of the IMS transmission management techniques described above when the network 100 releases a dedicated DRB during an IMS voice call in accordance with some embodiments. It should be understood that the method 600 is not limited to the sequence of operations shown in FIG. 6, as at least some of the signaling / operations can be performed in parallel or in a different sequence. Also, in at least some embodiments, the method 600 can include one or more different signaling sequences or operations other than those shown in FIG. 6.

[0074] In at least some embodiments, the method 600 initiates after the UE 102 has attached to the network 100 and completed the necessary authentication and security protocols. Upon attaching to the network 100, the UE 102 initiates a data connection establishment procedure with the CN 114 via the RAN 112 to establish a data connection. In cases where the CN 114 is an EPC, the data connection establishment procedure is a PDN connectivity procedure, and the data connection is a PDN connection including a default EPS bearer. In cases where the CN 114 is a 5GC, the data connection establishment procedure is a PDU session establishment procedure, and the data connection is a PDU session including a first QoS flow. During or after the data connection establishment procedure, the UE 102 establishes a first DRB 601 (illustrated as first DRB 601-1) with the RAN 112 to facilitate IP connectivity for access to multimedia and data services. This process involves, among other things, the RAN 112 initiating an RRC (Connection) Reconfiguration procedure 602 with the UE 102, which configures the first DRB 601-1 and necessaryradio parameters on the UE 102. The first DRB 601-1 is associated with the default EPS bearer or the first QoS flow.

[0075] After establishing the first DRB 601-1 , the UE 102 initiates registration with IMS network 128, which allows the UE 102 to access IMS services, including voice, video, and messaging. The UE 102 utilizes SIP messages 604 to communicate with the IMS network 128 for registering its presence and capability to engage in multimedia communication. For example, the UE 102 sends a SIP REGISTER message to the IMS network 128, which includes UE's IP Multimedia Public Identity (IMPU) of the UE 102 and, in some instances, the IP Multimedia Private Identity (I MPI) of the UE 102, signaling the UE’s 102 readiness to initiate and receive IMS sessions.

[0076] Following successful registration, when initiating an IMS voice call, the UE 102 uses SIP INVITE messages to establish a call session through the IMS network 128. This process involves a series of SIP message exchanges, including INVITE, TRYING, RINGING, and OK, resulting in the establishment of an IMS voice call session. These SIP messages traverse the first DRB 601-1 established earlier, utilizing the QoS and IP connectivity provisioned to manage the call setup efficiently and maintain the voice call’s quality. In cases where the UE 102 initiates the IMS voice call in an idle state, the UE 102 performs an RRC connection establishment procedure and a security command procedure with the RAN 112 to initiate the IMS voice call. In such cases, the RAN 112 performs an RRC (Connection) Reconfiguration procedure with the UE 102, which configures the first DRB 601-1 , similar to procedure 602 described above.

[0077] The RAN 112 and CN 114 perform a session management procedure 606 to configure one or more of the session resource or bearer context to support the IMS voice call. In the case of LTE, the session management procedure 606 involves or includes an E-UTRAN Radio Access Bearer (E-RAB) Setup procedure, an E-RAB Modify procedure, or a combination thereof. In the case of 5G, the session management procedure 606 involves or includes a PDU Session Resource Setup procedure, a PDU Session Resource Modify procedure, or a combination thereof. In at least some embodiments, after the initial context setup, the CN 114 initiates thisprocedure to set up the necessary bearers in the RAN 112 for the UE 102. In LTE, the initial context setup involves the MME 118 sending an Initial Context Setup Request to the BS 104. In 5G, the initial context setup involves the AMF 130 sending an Initial Context Setup Request to the BS 104. During the session management procedure, the CN 114 sends a CN-to-BS message to the RAN 112, requesting to configure one or more DRBs. In response, the RAN 112 performs one or more RRC reconfiguration procedures 608 (described below) with the UE 102 to configure one or more dedicated DRBs 603 (illustrated as dedicated DRB(s) 603-1), including a second DRB 605 (illustrated as second DRB 605-1). The RAN 112 sends a BS-to- CN message to the CN 114 in response to the CN-to-BS message. For example, the CN-to-BS message and the BS-to-CN message can be an E-RAB Setup Request and an E-RAB Setup Response, respectively, in the case of the E-RAB Setup procedure. In another example, the CN-to-BS message and the BS-to-CN message can be a PDU Session Resource Setup Request and a PDU Session Resource Setup Response, respectively, in the case of the PDU Session Resource Setup procedure.

[0078] After the IMS voice call has been set up or as a result of the session management procedure 606, one or more dedicated DRBs 603-1 , including a second DRB 605-1 , are configured for the IMS voice call. An example of the second DRB 605-1 includes a media-dedicated DRB. This process involves, among other things, the RAN 112 initiating an RRC reconfiguration procedure 608 to the UE 102, by sending an RRC reconfiguration message to the UE 102, which includes the configuration for the second DRB 605-1 (e.g., RLC configuration, PDCP configuration, DRB ID, EPS Bearer ID (for LTE), PDU Session ID (for 5G), QoS flow ID (for 5G), a combination thereof, or the like). The UE 102 responds with an RRC reconfiguration complete message, indicating the successful configuration of the second DRB 605-1. After the second DRB 605-1 has been configured, the UE 102 communicates 610 (e.g., sends and receives) IMS packets 607 (illustrated as IMS packets 607-1), such as IMS voice packets 609 (illustrated as IMS voice packets 609- 1), with the IMS network 128 through the RAN 112 and CN 114 using the second DRB 605-1 established for the IMS voice call. For example, the IMS voice packets 609-1 are encapsulated and transmitted over the second DRB 605-1 , which isoptimized for the QoS requirements of voice traffic. It should be understood that in the descriptions above or below, the RRC reconfiguration message and the RRC reconfiguration complete message are an RRC Connection Reconfiguration message and an RRC Connection Reconfiguration Complete message, respectively, in LTE, an RRC Reconfiguration message and an RRC Reconfiguration Complete message, respectively, in 5G.

[0079] As described above, in some instances, the network 100 releases a dedicated DRB(s) during the IMS service. In the example illustrated in FIG. 6, the network 100 releases the second DRB 605-1 during the IMS voice call. For example, the CN 114 sends a Network Access Stratum (NAS) message 612 to the UE 102, which is used for bearer context or PDll session management between the UE 102 and CN 114. The NAS message 612 includes a Deactivate EPS Bearer Context Request (for LTE) or a PDU Session Modification Command (for 5G), which requests that the UE 102 release or modify an existing EPS bearer, PDU session or a QoS flow. In another example, the CN 114 sends a CN-to-BS message to the RAN 112 to cause (e.g., request or command) the RAN 112 to release the second DRB 605-1 . In response to receiving the CN-to-BS message, the RAN 112 sends an RRC reconfiguration message 614 to the UE 102, instructing the UE 102 to release the second DRB 605-1. In response, the UE 102 releases 616 the second DRB 605-1 by, for example, removing the configuration related to the second DRB 605-1 , and any associated data channels and protocol entities (e.g., RLC and / or PDCP entities). The UE 102 also deallocates any internal resources that were allocated to the second DRB 605-1. After the UE 102 releases the second DRB 605-1 , the UE 102 sends an RRC reconfiguration complete message 618 to the RAN 112. In at least some embodiments, the CN-to-BS message may be an E-RAB Release Command (for LTE) or a PDU Session Resource Modify Request (for 5G).

[0080] At this point (i.e. , when the second DRB 605-1 is released), a conventionally configured UE terminates the IMS voice call by sending, for example, a SIP BYE message (when the call is in a connected state) or a SIP CANCEL message (during call setup before the call is connected) to the IMS network 128 to terminate the IMS voice call. However, the UE 102 of one or more embodiments maintains 620 the IMSvoice call. For example, the UE 102 transmits 622 the IMS voice packets 609-1 , which were previously being transmitted over the second DRB 605-1 , to the IMS network 128 via the RAN 112 using the first DRB 601-1 . As such, the UE 102 maintains the IMS voice call even though the second DRB 605-1 has been released. In at least some embodiments, if there are no DL RTP / RTCP packets received within a threshold amount of time, the UE 102 ends the IMS voice call due to RTP / RTCP inactivity.

[0081] FIG. 7 and FIG. 8 are signaling diagrams together illustrating an example of a method 700 for performing one of more of the IMS transmission management techniques described above when the network 100 releases a dedicated DRB during an IMS video call in accordance with some embodiments. It should be understood that the method 700 is not limited to the sequence of operations shown in FIG. 7 and FIG. 8, as at least some of the signaling / operations can be performed in parallel or in a different sequence. Also, in at least some embodiments, the method 700 can include one or more different signaling sequences or operations other than those shown in FIG. 7 and FIG. 8.

[0082] In at least some embodiments, the method 700 initiates after the UE 102 has attached to the network 100 and completed the necessary authentication and security protocols. Upon attaching to the network 100, the UE 102 establishes a first DRB 601 (illustrated as first DRB 601-2) with the RAN 112 to facilitate IP connectivity for access to multimedia and data services by performing, among other things, an RRC reconfiguration procedure 702 with the RAN 112, as described above with respect to FIG. 6. The first DRB 601-2 is associated with a default bearer (e.g., EPS bearer), a PDU session, or a QoS flow). After establishing the first DRB 601-2, the UE 102 initiates registration with IMS network 128 and utilizes SIP messages 704 to communicate with the IMS network 128 for registering its presence and capability to engage in multimedia communication, as described above with respect to FIG. 6. However, instead of setting up a voice call, the UE 102 and IMS network exchange SIP messages to establish an IMS video call in FIG. 7.

[0083] The RAN 112 and CN 114 perform a session management procedure 706, as described above with respect to FIG. 6. After the IMS video call has been set upor as a result of the session management procedure 706, a plurality of dedicated DRBs 603 (illustrated as dedicated DRBs 603-2), including a second DRB 605 (illustrated as second dedicated DRB 605-2) and a third DRB 701 (illustrated as third DRB 701-1), are configured for the IMS video call. An example of the second DRB 605-2 includes a media-dedicated DRB, and an example of the third DRB 701-1 includes a video-dedicated DRB. This process involves, among other things, the RAN 112 initiating 708 one or more RRC reconfiguration procedures to the UE 102 to configure the DRBs 603-2, as described above with respect to FIG. 6. However, instead of a single dedicated DRB being configured, multiple dedicated DRBs are configured. After the second DRB 605-2 and third DRB 701-1 have been configured, the UE 102 communicates 710 (e.g., sends and receives) IMS packets 607 (illustrated as IMS packets 607-2), such as IMS voice packets 609 (illustrated as IMS voice packets 609-2) and IMS video packets 703 with the IMS network 128 through the RAN 112 and CN 114. For example, the UE 102 transmits IMS voice packets 609-2 over the second DRB 605-2 and IMS video packets 703 over the third DRB 701-1 established for the IMS video call.

[0084] In the example illustrated in FIG. 7, the network 100 releases one of the second DRB 605-2 or the third DRB 701-1 during the IMS video call. Similar to FIG. 6, the CN 114 may send a NAS message 712 requesting that the UE 102 release or modify an existing bearer (e.g., EPS bearer), PDU session or a QoS flow, which causes the second DRB 605-2 or the third DRB 701-1 to be released. Similar to FIG. 6, the CN 114 sends a CN-to-BS message to the RAN 112 to cause the RAN 112 to release one of the second DRB 605-2 or the third DRB 701-1. In response to the CN-to-BS message, the RAN 112 sends an RRC reconfiguration message 714 to the UE 102, instructing the UE 102 to release a specified dedicated DRB, such as the second DRB 605-2 or the third DRB 701-1. In a first configuration 705, the UE 102 releases 716-1 one of the second DRB 605-2 or the third DRB 701-1 , similar to that described above with respect to FIG. 6, in response to receiving the RRC reconfiguration message 714 from the RAN 112. After the UE 102 releases the second DRB 605-2 or the third DRB 701-1 , the UE 102 sends an RRC reconfiguration complete message 718 to the RAN 112. In at least someembodiments, the CN-to-BS message is an E-RAB Release Command (for LTE) or a PDU Session Resource Modify Request (for 5G).

[0085] Similar to FIG. 6, instead of terminating the IMS video call, the UE 102 of one or more embodiments maintains 720-1 the IMS video call. For example, if the second DRB 605-2 was released, the UE 102 transmits 722-1 the IMS voice packets 609-2 over the third DRB 701-1 along with the IMS video packets 703 to the IMS network 128 via the RAN 112. Alternatively, if the third DRB 701-1 was released, the UE 102 transmits 722-1 the IMS video packets 703 over the second DRB 605-2 along with the IMS voice packets 609-2 to the IMS network 128 via the RAN 112. As such, the UE 102 is able to maintain the IMS video call instead of the call being terminated.

[0086] FIG. 8 shows another configuration 707 in which the UE 102 releases 716-2 one of the second DRB 605-2 or the third DRB 701-1 in response to receiving the RRC reconfiguration message 714 from the RAN 112. However, in this configuration 707, after the UE 102 sends the RRC reconfiguration complete message 718 to the RAN 112, the UE 102 switches 720-2 the IMS video call to an IMS voice call. If the second DRB 603 was released, the UE 102 transmits 722-2 the IMS voice packets 609-2 over the third DRB 701-1 to the IMS network 128 via the RAN 112. Alternatively, if the third DRB 701-1 was released, the UE 102 transmits 722-2 the IMS voice packets 609-2 over the second DRB 605-2 to the IMS network 128 via the RAN 112. As such, the UE 102 is able to maintain at least the audio portion of IMS video call instead of the call being terminated. In at least some embodiments, after the UE 102 switches the IMS voice call to a video call, if there are no DL RTP / RTCP packets received within a threshold amount of time, the UE 102 ends the IMS voice call due to RTP / RTCP inactivity.

[0087] In an additional configuration 709 shown in FIG. 8, the UE 102 releases 716- 3 both the second DRB 605-2 and the third DRB 701-1 in response to receiving the RRC reconfiguration message 714 from the RAN 112. In this configuration 709, after the UE 102 sends the RRC reconfiguration complete message 718 to the RAN 112, the UE 102 continues 720-3 the IMS video call. For example, the UE 102 transmits 722-3 the IMS voice packets 609-2 and the IMS video packets 703 over the first DRB601-2 to the IMS network 128 via the RAN 112. As such, the UE 102 is able to maintain the IMS video call instead of the call being terminated. Alternatively, the UE 102 switches 720-4 the IMS video call to an IMS voice call, and transmits 722-4 the IMS voice packets 609-2 over the first DRB 601-2 to the IMS network 128 via the RAN 112. This allows the UE 102 to maintain at least the audio portion of IMS video call instead of the call being terminated.

[0088] In another configuration 711 shown in FIG. 8, the UE 102 releases 716-4 the second DRB 605-2 in response to receiving the RRC reconfiguration message 714 from the RAN 112. In this configuration 711 , after the UE 102 sends the RRC reconfiguration complete message 718 to the RAN 112, the UE 102 releases 720-5 the IMS video call. For example, the UE 102 sends SIP messages 802, via the first DRB 601-2, through the IMS network 128 to release the IMS video call.

[0089] FIG. 9 and FIG. 10 are signaling diagrams together illustrating an example of a method 900 for performing one of more of the IMS transmission management techniques described above when the network 100 releases a dedicated DRB during an IMS voice call and an IMS RTT call in accordance with some embodiments. It should be understood that the method 900 is not limited to the sequence of operations shown in FIG. 9 and FIG. 10, as at least some of the signaling / operations can be performed in parallel or in a different sequence. Also, in at least some embodiments, the method 900 can include one or more different signaling sequences or operations other than those shown in FIG. 9 and FIG. 10.

[0090] In at least some embodiments, the method 900 initiates after the UE 102 has attached to the network 100 and completed the necessary authentication and security protocols. Upon attaching to the network 100, the UE 102 establishes a first DRB 601 (illustrated as first DRB 601-3) with the RAN 112 to facilitate IP connectivity for access to multimedia and data services by performing, among other things, an RRC reconfiguration process 902 with the RAN 112, as described above with respect to FIG. 6. The first DRB 601-3 is associated with a default bearer, a PDU session, or a QoS flow. After establishing the first DRB 601-3, the UE 102 initiates registration with IMS network 128 and utilizes SIP messages 904 to communicate with the IMS network 128 for registering its presence and capability to engage in multimediacommunication, as described above with respect to FIG. 6. However, instead of only setting up an IMS voice call, the UE 102 and IMS network exchange SIP messages to establish an IMS voice call and an IMS RTT call in FIG. 9.

[0091] The RAN 112 and CN 114 perform a session management procedure 906, as described above with respect to FIG. 6. After the IMS voice call and IMS RTT call have been set up or as a result of the session management procedure 906, a plurality of dedicated DRBs 603 (illustrated as dedicated DRBs 603-3) are configured. For example, a second DRB 605 (illustrated as second DRB 605-3), such as a media-dedicated DRB, is configured for the IMS voice call and a third DRB 701 (illustrated as 701-2), such as a text-dedicated DRB, is configured for the IMS RTT call. This process involves, among other things, the RAN 112 initiating an RRC reconfiguration procedure to the UE 102, as described above with respect to FIG. 6. However, instead of a single dedicated DRB being configured, multiple dedicated DRBs are configured. After the second DRB 605-3 and third DRB 701-2 have been configured, the UE 102 transmits 910 (e.g., sends and receives) IMS packets 607 (illustrated as IMS packets 607-3), such as IMS voice packets 609 (illustrated as IMS voice packets 609-3) and IMS text packets 901 , with the IMS network 128 through the RAN 112 and CN 114. For example, the UE 102 transmits IMS voice packets 609-3 over the second DRB 605-3 established for the IMS voice call and IMS text packets 901 over the third DRB 701-2 established for the IMS RTT call.

[0092] In the example illustrated in FIG. 9, the network 100 releases one of the second DRB 605-3 or the third DRB 701-2 during the IMS video call. Similar to FIG. 6 and FIG. 7, the CN 114 may send a NAS message 912 requesting that the UE 102 release or modify an existing EPS bearer, a PDU session, or a QoS flow, which causes the second DRB 605-3 or the third DRB 701 -2 to be released. Similar to FIG. 6 and FIG. 7, the CN 114 sends a CN-to-BS message to the RAN 112 to cause the RAN 112 to release one of the second DRB 605-3 or the third DRB 701-2. In response to the CN-to-BS message, the RAN 112 sends an RRC reconfiguration message 914 to the UE 102, instructing the UE 102 to release a specified dedicated DRB, such as the second DRB 605-3 or the third DRB 701-2. In a first configuration 903, the UE 102 releases 916-1 one of the second DRB 605-3 or the third DRB 701 -2, similar to that described above with respect to FIG. 7, in response to receiving the RRC reconfiguration message 914 from the RAN 112. After the UE 102 releases the second DRB 605-3 or the third DRB 701-2, the UE 102 sends an RRC reconfiguration complete message 918 to the RAN 112. In at least some embodiments, the CN-to-BS message is an E-RAB Release Command (for LTE) or a PDU Session Resource Modify Request (for 5G).

[0093] Similar to FIG. 6 and FIG. 7, instead of terminating the IMS voice call and the IMS RTT call, the UE 102 of one or more embodiments maintains 920-1 the both the IMS voice call and the IMS RTT call. For example, if the second DRB 605-3 was released, the UE 102 transmits 922-1 the IMS voice packets 609-3 over the third DRB 701-2 along with the IMS text packets 901 to the IMS network 128 via the RAN 112. Alternatively, if the third DRB 701-2 was released, the UE 102 transmits 922-1 the IMS text packets 901 over the second DRB 605-3 along with the IMS voice packets 609-3 to the IMS network 128 via the RAN 112. As such, the UE 102 is able to maintain both the IMS voice call and the IMS RTT call instead of the calls being terminated.

[0094] FIG. 10 shows another configuration 905 in which the UE 102 releases 916- 2 a third DRB 701-2 in response to receiving the RRC reconfiguration message 914 from the RAN 112. However, in this configuration 905, after the UE 102 sends the RRC reconfiguration complete message 918 to the RAN 112, the UE 102 continues the IMS voice call and releases the IMS RTT call. The UE 102 continues to transmit 922-2 the IMS voice packets 609-3 over the second DRB 605-3 to the IMS network 128 via the RAN 112. As such, even though the IMS RTT call was released, the UE 102 is able to maintain the IMS voice call. In at least some embodiments, if there are no DL RTP / RTCP packets received within a threshold amount of time, the UE 102 ends the IMS voice call due to RTP / RTCP inactivity.

[0095] In an additional configuration 907 shown in FIG. 10, the UE 102 releases 916-3 both the second DRB 605-3 and the third DRB 701-2 in response to receiving the RRC reconfiguration message 914 from the RAN 112. In this configuration 907, after the UE 102 sends the RRC reconfiguration complete message 918 to the RAN 112, the UE 102 continues 920-3 both the IMS voice call and the IMS RTT call. Forexample, the UE 102 transmits 922-3 the IMS voice packets 609-3 and the IMS text packets 901 over the first DRB 601-3 to the IMS network 128 via the RAN 112. As such, the UE 102 is able to maintain both the IMS voice call and the IMS text call instead of these calls being terminated. Alternatively, the UE 102 releases 920-4 the IMS voice call and continues the IMS RTT call by transmitting 922-4 the IMS text packets 901 over the first DRB 601-3 to the IMS network 128 via the RAN 112. This allows the UE 102 to maintain IMS RTT call even though the IMS voice call was released.

[0096] In another configuration 909 shown in FIG. 10, the UE 102 releases 916-4 the second DRB 605-3 in response to receiving the RRC reconfiguration message 914 from the RAN 112. In this configuration 909, after the UE 102 sends the RRC reconfiguration complete message 918 to the RAN 112, the UE 102 releases 920-5 the IMS voice call and the IMS RTT call. For example, the UE 102 sends SIP messages 1002, via the first DRB 601-3, through the IMS network 128 to release the IMS video call.

[0097] In at least some embodiments, when UE 102 releases a dedicated DRB 603 in FIGs. 6-10, the UE 102 processes the configuration information 138 to determine how the IMS packets for the IMS call(s) are to be managed. For example, in response to the release of a dedicated DRB 603, the UE 102 determines if any additional dedicated DRBs 603 remain established. In the examples illustrated in FIG. 6, configuration 709 of FIG. 8, and configuration 907 of FIG. 9, the UE 102 determines that no other dedicated DRBs 603 remain established. Therefore, the UE 102 processes the configuration information 138, such as bitmask 302-1 , for this condition and determines which, if any, IMS packets are able to be transmitted over the default DRB 601 . If the UE 102 is not configurable such that it can transmit any IMS packets 607 over the default DRB 601 , the UE 102 operates according to one or more specifications and terminates the IMS call. However, if the UE 102 is configurable such that it can transmit IMS packets over the default DRB 601 , the UE 102 proceeds as described above with respect to FIG. 6, configuration 709 of FIG. 8, and configuration 907 of FIG. 10.

[0098] In the examples illustrated in configurations 705 of FIG. 7, configurations 707 and 711 of FIG. 8, configuration 903 of FIG. 9, and configurations 905 and 909 of FIG. 10, the UE 102 determines that at least one dedicated DRB 603 remains established. Therefore, the UE 102 processes the configuration information 138, such as bitmask 302-2, for this condition and determines which, if any, IMS packets are able to be transmitted over the remaining dedicated DRB 603. If the UE 102 is not configurable such that it can transmit IMS packets associated with a released dedicated DRB 603 over the remaining dedicated DRB(s) 603, the UE 102 operates according to one or more specifications and terminates the IMS call. However, if the UE 102 is configurable such that it can transmit IMS packets associated with a released dedicated DRB 603 over the remaining dedicated DRB 603, the UE 102 proceeds as described above with respect to configurations 707 and 711 of FIG. 8, configuration 903 of FIG. 9, and configurations 905 and 909 of FIG. 10.

[0099] FIG. 11 illustrates an example method 1100 for maintaining an IMS service when the network 100 releases a dedicated DRB 603 during the IMS service in accordance with some embodiments. The processes described below with respect to method 1100 have been described above in greater detail with reference to FIG. 1 to FIG. 10. It should be understood that method 1100 is not limited to the sequence of operations shown in FIG. 11 , as at least some of the operations can be performed in parallel or in a different sequence. Moreover, in at least some implementations, method 1100 can include one or more different operations than those shown in FIG. 11.

[0100] At block 1102, the UE 102 sets up a first DRB 601 , such as a default DRB, with the network 100. At block 1104, the UE 102 transmits SIP messages to set up one or more IMS services with an IMS network 128. At block 1106, the UE 102 sets up at least a second DRB 605, such as a dedicated DRB 603. At block 1108, the UE 102 transmits a set of IMS packets 607 of the services(s) with the IMS network 128 via the second DRB 603. For example, the UE 102 transmits IMS voice packets 609 with the IMS network 128 over a DRB 603 dedicated for voice media. At block 1110, the UE 102 releases the second DRB 605 in response to detecting an abnormal release of the second DRB 605 by the network 100. At block 1112, the UE 102continues the IMS service(s) in response to releasing the second DRB 605. At block 1114, the UE 102 transmits IMS packets 607 of the IMS service(s) with the IMS network 128 via the first DRB 601 . For example, the UE 102 transmits IMS voice packets 609 with the IMS network 128 over the default bearer (e.g., first DRB 601).

[0101] FIG. 12 illustrates an example method 1200 for maintaining at least a portion of an IMS service when the network 100 releases at least one dedicated DRB 603 during the IMS service while at least one other dedicated DRB 603 remains established in accordance with some embodiments. The processes described below with respect to method 1200 have been described above in greater detail with reference to FIG. 1 to FIG. 10. It should be understood that method 1100 is not limited to the sequence of operations shown in FIG. 12, as at least some of the operations can be performed in parallel or in a different sequence. Moreover, in at least some implementations, method 1200 can include one or more different operations than those shown in FIG. 12.

[0102] At block 1202, the UE 102 sets up a first DRB 601 , such as a default DRB, with the network 100. At block 1204, the UE 102 transmits SIP messages to set up one or more IMS services with an IMS network 128. At block 1206, the UE 102 sets up a plurality of additional DRBs 603, including a second DRB 605 and a third DRB 701. At block 1208, the UE 102 transmits IMS packets 607 of the services(s) with the IMS network 128 via the plurality of DRBs 603. In at least some embodiments, the UE 102 transmits a first set of IMS packets 607 and a second set of IMS packet 607. For example, the UE 102 transmits IMS voice packets 609 with the IMS network 128 over the second DRB 603, such as a media-dedicated DRB, and transmits IMS video packets 703 (second set of IMS packets) with the IMS network 128 over the third DRB 701 , such as a video-dedicated DRB. At block 1210, the UE 102 releases at least the second DRB 605 in response to detecting an abnormal release of at least the second DRB 605 by the network 100.

[0103] At block 1212, the UE 102 continues the IMS service(s) in response to releasing at least the second DRB 605. Alternatively, the UE 102 continues a portion of the IMS service(s) and releases the remaining portion of the IMS service(s) in response to releasing the second DRB 605. For example, the UE 102 switches anIMS video call to an IMS voice call, releases an IMS voice call and continues an IMS RTT call, or the like. At block 1214, the UE 102 transmits IMS packets 607 of the IMS service(s) (or the portion thereof) with the IMS network 128 via at least one DRB 603 of the plurality of additional DRBs 603 that remains established. For example, if the second DRB 605 was released, the UE 102 transmits the IMS voice packets 609 with the IMS network 128 over the third DRB 701 along with the IMS video packets 703. However, if the third DRB 701 was released, the UE 102 transmits the IMS video packets 703 with the IMS network 128 over the second DRB 605 along with the IMS voice packets 609.

[0104] FIG. 13 illustrates an example method 1300 for maintaining a portion of an IMS service when the network 100 releases a dedicated DRB 603 during the IMS voice call in accordance with some embodiments. The processes described below with respect to method 1300 have been described above in greater detail with reference to FIG. 1 to FIG. 10. It should be understood that method 1300 is not limited to the sequence of operations shown in FIG. 13, as at least some of the operations can be performed in parallel or in a different sequence. Moreover, in at least some implementations, method 1300 can include one or more different operations than those shown in FIG. 13.

[0105] At block 1302, the UE 102 sets up a first DRB 601 , such as a default DRB, with the network 100. At block 1304, the UE 102 transmits SIP messages to set up one or more IMS services with an IMS network 128. At block 1306, the UE 102 sets up a plurality of additional DRBs 603, including a second DRB 605 and a third DRB 701. At block 1308, the UE 102 transmits IMS packets 607 of the services(s) with the IMS network 128 via the plurality of DRBs 603. In at least some embodiments, the UE 102 transmits a first set of IMS packets 607 and a second set of IMS packet 607. For example, the UE 102 transmits IMS voice packets 609 with the IMS network 128 over the second DRB 603, such as a media-dedicated DRB, and transmits IMS video packets 703 with the IMS network 128 over the third DRB 701 , such as a videodedicated DRB. In another example, the UE 102 transmits IMS voice packets 609 with the IMS network 128 over the second DRB 603, such as a media-dedicatedDRB, and transmits IMS text packets 901 with the IMS network 128 over the third DRB 701 , such as a text-dedicated DRB.

[0106] At block 1310, the UE 102 releases at least the second DRB 605 and the third DRB 701 in response to detecting an abnormal release of at least the second DRB 605 by the network 100. At block 1312, the UE 102 continues a portion of the IMS service(s) and releases the remaining portion of the IMS service(s) in response to releasing the second DRB 605 and the third DRB 701. For example, the UE 102 switches an IMS video call to an IMS voice call, releases an IMS voice call and continues an IMS RTT call, or the like. At block 1314, the UE transmits IMS packets 607 of the first portion of the IMS service(s) with the IMS network 128 via the first DRB 601 . For example, the UE 102 transmits IMS voice packets 609 of an IMS video call with the IMS network 128 over the first DRB 601 (e.g., default DRB). In another example, if the UE 102 has released an IMS voice call but maintained an IMS RTT call, the UE 102 transmits IMS text packets 901 with the IMS network 128 over the first DRB 601 .

[0107] FIG. 14 illustrates an example method 1400 for configuring a UE to manage IMS transmissions when the network 100 releases a dedicated DRB 603 during an IMS service in accordance with some embodiments. The processes described below with respect to method 1400 have been described above in greater detail with reference to FIG. 1 to FIG. 10. It should be understood that method 1400 is not limited to the sequence of operations shown in FIG. 14, as at least some of the operations can be performed in parallel or in a different sequence. Moreover, in at least some implementations, method 1400 can include one or more different operations than those shown in FIG. 14.

[0108] At block 1402, the UE 102 sets up a default DRB 601 with the network 100. At block 1404, the UE 102 transmits SIP messages to set up one or more IMS services with an IMS network 128. At block 1406, the UE 102 sets up at least a one dedicated DRB 603. At block 1408, the UE 102 transmits IMS packets 607 of the services(s) with the IMS network 128 via the dedicated DRB 603. At block 1410, the UE 102 releases the dedicated DRB 603 in response to detecting an abnormal release of the dedicated DRB 603 by the network 100. At block 1412, the UE 102processes IMS transmission configuration information 138 to determine if it is configured to perform the IMS service(s) via the default DRB 601. At block 1414, if the UE 102 is configured to perform the IMS service(s) via the default DRB 601 , the UE 102 transmits the IMS packets 607 of the IMS service(s) with the IMS network over the default DRB 601. At block 1416, if the UE 102 is not configured to perform the IMS service(s) via the default DRB 601 , the UE 102 releases the IMS service(s).

[0109] FIG. 15 illustrates another example method 1500 for configuring a UE to manage IMS transmissions when the network 100 releases a dedicated DRB 603 during an IMS service in accordance with some embodiments. The processes described below with respect to method 1500 have been described above in greater detail with reference to FIG. 1 to FIG. 10. It should be understood that method 1500 is not limited to the sequence of operations shown in FIG. 15, as at least some of the operations can be performed in parallel or in a different sequence. Moreover, in at least some implementations, method 1500 can include one or more different operations than those shown in FIG. 15.

[0110] At block 1502, the UE 102 sets up a default DRB 601 with the network 100. At block 1504, the UE 102 transmits SIP messages to set up one or more IMS services with an IMS network 128. At block 1506, the UE 102 sets up a plurality of dedicated DRBs 603. At block 1508, the UE 102 transmits IMS packets 607 of a first type with the IMS network 128 via one dedicated DRB 605 of the plurality of dedicated DRBs 603, and transmits IMS packets 607 of a second (different) type with the IMS network 128 via another dedicated DRB 701 of the plurality of dedicated DRBs 603. At block 1510, the UE 102 releases the dedicated DRB 603 associated with the second type of IMS packets 607 in response to detecting an abnormal release of this dedicated DRB 603 by the network 100. At block 1512, the UE 102 processes IMS transmission configuration information 138 to determine if it is configured to perform the IMS service(s) without the released dedicated DRB 603. At block 1514, if the UE 102 is configured to perform the IMS service(s) without the released dedicated DRB 603, the UE 102 transmits the first type of IMS packets 607 and the second type of IMS packets 607 with the IMS network over the remaining dedicated DRB 603. At block 1516, if the UE 102 is not configured to perform theIMS service(s) without the released dedicated DRB 603, the UE 102 releases one, some, or all of the IMS service(s).

[0111] In some embodiments, certain aspects of the techniques described above may be implemented by one or more processors of a processing system executing software. The software comprises one or more sets of executable instructions stored or otherwise tangibly embodied on a non-transitory computer readable storage medium. The software can include the instructions and certain data that, when executed by the one or more processors, manipulate the one or more processors to perform one or more aspects of the techniques described above. The non-transitory computer readable storage medium can include, for example, a magnetic or optical disk storage device, solid state storage devices such as Flash memory, a cache, random access memory (RAM) or other non-volatile memory device or devices, and the like. The executable instructions stored on the non-transitory computer readable storage medium may be in source code, assembly language code, object code, or other instruction format that is interpreted or otherwise executable by one or more processors.

[0112] A computer readable storage medium may include any storage medium, or combination of storage media, accessible by a computer system during use to provide instructions and / or data to the computer system. Such storage media can include, but is not limited to, optical media (e.g., compact disc (CD), digital versatile disc (DVD), Blu-Ray disc), magnetic media (e.g., floppy disc , magnetic tape, or magnetic hard drive), volatile memory (e.g., random access memory (RAM) or cache), non-volatile memory (e.g., read-only memory (ROM) or Flash memory), or microelectromechanical systems (MEMS)-based storage media. The computer readable storage medium may be embedded in the computing system (e.g., system RAM or ROM), fixedly attached to the computing system (e.g, a magnetic hard drive), removably attached to the computing system (e.g., an optical disc or Universal Serial Bus (USB)-based Flash memory), or coupled to the computer system via a wired or wireless network (e.g., network accessible storage (NAS)).

[0113] Note that not all of the activities or elements described above in the general description are required, that a portion of a specific activity or device may not berequired, and that one or more further activities may be performed, or elements included, in addition to those described. Still further, the order in which activities are listed are not necessarily the order in which they are performed. Also, the concepts have been described with reference to specific embodiments. However, one of ordinary skill in the art appreciates that various modifications and changes can be made without departing from the scope of the present disclosure as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of the present disclosure.

[0114] Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and any feature(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential feature of any or all the claims. Moreover, the particular embodiments disclosed above are illustrative only, as the disclosed subject matter may be modified and practiced in different but equivalent manners apparent to those skilled in the art having the benefit of the teachings herein. No limitations are intended to the details of construction or design herein shown, other than as described in the claims below. It is therefore evident that the particular embodiments disclosed above may be altered or modified and all such variations are considered within the scope of the disclosed subject matter. Accordingly, the protection sought herein is as set forth in the claims below.

Claims

WHAT IS CLAIMED IS:1 . A method at a user equipment (UE) device (102), the method comprising: transmitting Internet Protocol (IP) Multimedia Subsystem (IMS) packets (607) for at least one IMS service to a network (128) over at least a first data radio bearer (DRB) of a plurality of DRBs (601 , 603); and responsive to releasing at least the first DRB during the at least one IMS service, continuing at least a portion of the at least one IMS service over at least a second DRB of the plurality of DRBs.

2. The method of claim 1 , wherein the second DRB is a default DRB.

3. The method of claim 1 , wherein the second DRB is a DRB established for a different IMS service.

4. The method of claim 1 , wherein transmitting the IMS packets for the at least oneIMS service comprises: transmitting a first set of IMS packets for the at least one IMS service over the at least first DRB; and transmitting a second set of IMS packets for the at least one IMS service over the at least second DRB, and wherein continuing the at least a portion of the at least one IMS service comprises transmitting the first set of IMS packets and the second set of IMS packets over the at least second DRB.

5. The method of claim 1 , wherein transmitting the IMS packets for the at least oneIMS service, comprises: transmitting a first set of IMS packets for the at least one IMS service over one of the at least first DRB or the at least second DRB; and transmitting a second set of IMS packets for the at least one IMS service over a different one of the at least first DRB or the at least second DRB, and wherein continuing the at least a portion of the at least one IMS service comprises: switching the at least one IMS service to a different IMS service; andresponsive to releasing one of the at least first DRB or the at least second DRB, transmitting the first set of IMS packets over a remaining one of the at least first DRB or the at least second DRB.

6. The method of claim 1 , wherein transmitting the IMS packets for the at least oneIMS service, comprises: transmitting a first set of IMS packets for the at least one IMS service over one of the at least first DRB or a third DRB of the plurality of DRBs; and transmitting a second set of IMS packets for the at least one IMS service over a different one of the at least first DRB or the third DRB, and wherein continuing the at least a portion of the at least one IMS service comprises: responsive to releasing the at least first DRB and the third DRB, transmitting the first set of IMS packets and the second set of IMS packets over the at least second DRB, wherein the at least second DRB is a default DRB.

7. The method of claim 1 , wherein transmitting the IMS packets for the at least oneIMS service, comprises: transmitting a first set of IMS packets for the at least one IMS service over one of the at least first DRB or a third DRB of the plurality of DRBs; and transmitting a second set of IMS packets for the at least one IMS service over a different one of the at least first DRB or the third DRB, and wherein continuing the at least a portion of the at least one IMS service comprises: switching the at least one IMS service to a different IMS service; and responsive to releasing the at least first DRB and the third DRB, transmitting the second set of IMS packets over the at least second DRB, wherein the at least second DRB is a default DRB.

8. The method of claim 1 , wherein transmitting the IMS packets for the at least oneIMS service, comprises:transmitting a first set of IMS packets for a first IMS service over the at least first DRB; and transmitting a second set of IMS packets for a second IMS service over the at least second DRB, and wherein continuing the at least a portion of the IMS service comprises: responsive to releasing the at least first DRB, releasing the first IMS service; and transmitting the second set of IMS packets over the at least second DRB.

9. The method of claim 1 , wherein transmitting the IMS packets for the at least oneIMS service, comprises: transmitting a first set of IMS packets for a first IMS service over the at least first DRB; and transmitting a second set of IMS packets for a second IMS service over a third DRB of the plurality of DRBs, and wherein continuing the at least a portion of the IMS service comprises: responsive to releasing the at least first DRB and the third DRB, transmitting the first set of IMS packets and the second set of IMS packets over the at least second DRB, wherein the at least second DRB is a default DRB.

10. The method of claim 1 , wherein transmitting the IMS packets for the at least oneIMS service, comprises: transmitting a first set of IMS packets for a first IMS service over the at least first DRB; and transmitting a second set of IMS packets for a second IMS service over a third DRB of the plurality of DRBs, and wherein continuing the at least a portion of the IMS service comprises: responsive to releasing the at least first DRB and the third DRB, releasing the first IMS service; and transmitting the second set of IMS packets over the at least second DRB, wherein the at least second DRB is a default DRB.11 . The method of claim 1 , wherein continuing at least a portion of the at least oneIMS service, comprises: responsive to a set of configuration information at the UE indicating that the UE is one of configured to perform the IMS service without the at least first DRB or is configured to perform the IMS service over the at least second DRB, transmitting the IMS packets associated with the at least a portion of the IMS service to the network over the at least second DRB of the plurality of DRBs.

12. The method of claim 11 , wherein the set of configuration information comprises at least one bitmask, wherein each bit of the bitmask is associated with a different type of IMS packet.

13. The method of claim 11 , further comprising: responsive to at least one of downlink Real-time Transport Protocol packets or Real-time Transport Control Protocol packets associated with the at least one IMS service having not been received within a threshold amount of time after the transmitting the at least one IMS service over the at least second DRB, changing the at least one IMS service to a different type of IMS service.

14. The method of claim 11 , further comprising: responsive to at least one of downlink Real-time Transport Protocol packets or Real-time Transport Control Protocol packets associated with the at least one IMS service having not been received within a threshold amount of time after the transmitting the at least one IMS service over the at least second DRB, ending the at least one IMS service.

15. The method of claim 1 , wherein transmitting the IMS packets for the at least oneIMS service comprises one of: transmitting IMS voice packets for an IMS voice call over the first DRB; transmitting IMS voice packets for an I S video call over one of the at least first DRB and the at least second DRB, and IMS video packets for theIMS video call over a different one of the at least first DRB and the at least second DRB; transmitting IMS voice packets for an IMS video call over one of the at least first DRB and a third DRB of the plurality of DRBs, and IMS video packets for the IMS video call over a different one of the at least first DRB and the third DRB; transmitting IMS text packets for an IMS Real-time Text (RTT) call over the at least first DRB; transmitting IMS voice packets for an IMS voice call over the at least first DRB or the at least second DRB, and IMS text packets for an IMS RTT call over a different one of the at least first DRB and the at least second DRB; and transmitting IMS voice packets for an IMS voice call over the at least first DRB or a third DRB of the plurality of DRBs, and IMS text packets for an IMS RTT call over a different one of the at least first DRB and the third DRB.

16. A user equipment, comprising: one or more radio frequency (RF) modems configured to wirelessly communicate with at least one network; one or more processors coupled to the one or more RF modems; and at least one memory storing executable instructions, the executable instructions configured to manipulate at least one of the one or more processors or the one or more RF modems to perform the method of any of the preceding claims.

Images