Patent Application
20190141772
When a user subscribes to a telecomm carrier's telephony services, the subscribing user can utilize a user equipment (UE), such as a mobile handset, to make calls. A carrier that provides access to a Long Term Evolution (LTE) network can provide such telephony services using Voice over LTE (VoLTE). VoLTE is a fairly reliable technology, but the UE may, in some instances, be unsuccessful in establishing a VoLTE call. This can be due to various issues that arise from time-to-time inhibiting establishment of a VoLTE session. For example, a network outage may occur during a particular call attempt, and the UE may not receive a network response that is needed to establish a dedicated evolved packet system (EPS) bearer for setting up a VoLTE call. Such a network outage may be due to a failure at a mobility management entity (MME) that is responsible for sending the response to the UE.
Rather than wait an indefinite period of time for such an issue to resolve itself from the network side, the UE is typically configured to utilize one or more timers during call setup to proactively resolve the issue from the client side. These timers are configured to timeout if something that is expected to occur during call setup does not occur within a set period of time. Accordingly, after a call setup timer is triggered, the UE can wait a set period of time until the timer expires, and thereafter take some remedial action. The action taken by the UE can include, among other possible actions, dropping the call so that the user is not left waiting indefinitely for an answer, or reattempting the call using a different approach (e.g., a different call path) in an effort to establish the call for the user.
Existing call setup timers implemented in today's UEs are problematic because the call setup timers can, in some instances, cause downstream network issues, like network outages, due to the way the timers are designed. A salient example is in the context of emergency calls. When a user dials 911 (in the United States) on his/her UE, the call is routed to an appropriate (e.g., nearest) public safety answering point (PSAP). Local regulations for PSAPs may differ, but most PSAPs are required to take extra steps to avoid a situation where an emergency call goes unanswered. For instance, some PSAPs are required to record every call attempt to the PSAP, some record every call that begins ringing, some require a person to answer the call, and/or, if an Interactive Voice Response
(IVR) system is in place, a call can be answered by the IVR system, and some PSAPs call back every call that is not answered by a person or an IVR system. Imagine a scenario where multiple UEs are frequently reattempting calls to a single PSAP, but failing to establish the call on each reattempt due to a network issue. In this scenario, the frequent expiration of call setup timers on the individual UEs are causing the frequent reattempts, and the PSAP may be unable to recover from the issue due to the sheer volume of incoming calls. As a consequence, the problem may “snowball” out of control to a point where the PSAP can no longer handle the high volume of traffic, and calls may not get through to the PSAP. As a result, one or more of these calls may go unanswered and emergency response services may be compromised. In recognizing that the aforementioned problem is, at least partly, caused by poorly-designed call setup timers, there is a need for further improvements to UE call setup procedures utilizing timers.
The detailed description is set forth with reference to the accompanying figures, in which the left-most digit of a reference number identifies the figure in which the reference number first appears. The use of the same reference numbers in different figures indicates similar or identical items or features.
Described herein are techniques and systems for implementing one or more timers during setup of a communication session. This timer(s) is sometimes referred to herein as a “session setup timer,” or a “communication session setup timer,” and for calls in particular, a “call setup timer.” The session setup timer(s) may be triggered and terminated by particular events, as described herein, which are expected to occur during session setup. In some embodiments, a session setup timer is triggered by an originating UE sending a request, or receiving a response, that uses a first signaling protocol, and is terminated by the originating UE sending a request, or receiving a response, that uses a second signaling protocol different from the first signaling protocol. This provides more flexibility as compared to existing call setup timers because existing call setup timers are limited to triggering and termination events that occur within a common signaling protocol.
An example process to be implemented by an originating UE can include receiving user input requesting to establish a communication session, performing a first setup procedure of multiple setup procedures to setup the communication session, the first setup procedure comprising at least of: (i) sending a first request using a first signaling protocol or (ii) receiving a first response using the first signaling protocol, and starting a timer in response to the performing of the first setup procedure, the timer being configured to expire after a period of time. After starting the timer, the originating UE continues the multiple setup procedures, and, during those setup procedures, if the originating UE performs a second setup procedure using a second signaling protocol prior to expiration of the timer, the originating UE stops the timer, finishes the setup procedures, and establishes the communication session over a telecommunications network. Here, the second setup procedure may comprises at least one of: (i) sending a second request using a second signaling protocol or (ii) receiving a second response using the second signaling protocol. If, however, the timer expires prior to the performance of the second setup procedure, the originating UE may halt the multiple setup procedures, and reattempt the setup of the communication session with new setup procedures.
In some embodiments, a timer(s) implemented by an originating UE during setup of a communications session is triggered by a response received from a node of a telecommunications network. This alternative approach also provides more flexibility as compared to existing call setup timers, which are known to be triggered by requests that are sent from the UE to a network node.
An example process implemented by an originating UE can include receiving user input requesting to establish a communication session, performing a first setup procedure of multiple setup procedures to setup the communication session, the first setup procedure comprising receiving a response from a node of a telecommunications network, and starting a timer in response to performance of the first setup procedure, the timer being configured to expire after a period of time. After starting the timer, the originating UE continues the multiple setup procedures, and, during those setup procedures, if a particular setup procedure occurs prior to expiration of the timer, the originating UE stops the timer, finishes the setup, and establishes the communication session over the telecommunications network. If, however, the timer expires prior to the occurrence of the particular setup procedure, the originating UE may halt the multiple setup procedures and reattempt the setup of the communication session with new setup procedures.
Also disclosed herein are systems and devices comprising one or more processors and one or more memories, as well as non-transitory computer-readable media storing computer-executable instructions that, when executed, by one or more processors perform various acts and/or processes disclosed herein.
The techniques and systems described herein for implementing session setup timers at an originating UE provide more flexibility in configuring the UE to take an appropriate action(s) at an appropriate time(s) during setup of a communication session. Specifically, configuring a session setup timer to be triggered and terminated by the particular events described herein allows for optimization of UE procedures performed during setup of a communication session. Optimization of UE procedures during session setup may alleviate (e.g., reduce the occurrence of) downstream network issues, such as network outages. The end result is an improved session experience from the perspective of subscribing users participating in a communication session.
In accordance with various embodiments described herein, the terry “user equipment (UE),” “wireless communication device,” “wireless device,” “communication device,” “mobile device,” and “client device,” may be used interchangeably herein to describe any UE the originating UE 100) that is capable of transmitting/receiving data wirelessly using any suitable wireless communications/data technology, protocol, or standard, such as Global System for Mobile Communications (GSM), Time Division Multiple Access (TDMA), Universal Mobile Telecommunications System (UMTS), Evolution-Data Optimized (EVDO), Long Term Evolution (LTE), Advanced LTE (LTE+), Generic Access Network (GAN), Unlicensed Mobile Access (UMA), Code Division Multiple Access (CDMA), Orthogonal Frequency Division Multiple Access (OFDM), General Packet Radio Service (GPRS), Enhanced Data GSM Environment (EDGE), Advanced Mobile Phone System (AMPS), High Speed Packet Access (HSPA), evolved HSPA (HSPA+), Voice over IP (VoIP), Voice over LTE (VoLTE), IEEE 802.1x protocols, WiMAX, Wi-Fi, Data Over Cable Service Interface Specification (DOCSIS), digital subscriber line (DSL), and/or any future IP-based network technology or evolution of an existing IP-based network technology. The originating UE 100 may be implemented as any suitable type of computing device configured to communicate over a wireless network, including, without limitation, a mobile phone (e.g., a smart phone/handset), a tablet computer, a laptop computer, a portable digital assistant (PDA), a wearable computer (e.g., electronic/smart glasses, a smart watch, fitness trackers, etc.), an in-vehicle (e.g., in-car) computer, and/or any similar mobile device, as well as situated computing devices including, without limitation, a television (smart television), set-top-box (STB), desktop computer, and the like.
In general, a user can utilize the originating UE 100 to communicate with other computing devices of a telecommunications network via the IMS core 102. The IMS core is sometimes referred to herein as the “IMS core network 102,” the “IMS network 102,” the “Core Network (CN) 102,” or the “IM CN Subsystem 102”. The IMS core 102 is an architectural framework defined by the 3rd generation partnership project (3GPP) for delivering Internet Protocol (IP) multimedia to a UE, such as the originating UE 100. The IMS core 102 can be maintained and/or operated by one or more service providers, such as one or more wireless carriers (or “operators”), that provide IMS-based services to users (sometimes called “subscribers”) who are associated with UEs, such as the originating UE 100. For example, a service provider may offer multimedia telephony services that allow a subscribed user to call or message other users via the IMS core 102 using his/her UE. A user can also utilize an associated UE to receive, provide, or otherwise interact with various different IMS-based services by accessing computing devices of the IMS core 102. In this manner, an operator of the IMS core 102 may offer any type of IMS-based service, such as, telephony services, emergency services (e.g., E911), gaming services, instant messaging services, presence services, video conferencing services, social networking and sharing services, location-based services, push-to-talk services, and so on. In order to access these services (e.g., telephony services), a UE is configured to request establishment of a communication session. In the case of telephony services, the communication session can comprise a call (i.e., a voice-based communication session, such as a VoLTE call).
The originating UE 100 is configured to utilize various radio access networks (RANs) and/or radio access technologies (RATs) in order to access the IMS core 102. UEs that are fourth generation (4G) LTE-compliant are configured to communicate within heterogeneous cellular networks by employing radios that can communicate over LTE systems (or “LTE networks”) as well as over legacy systems (or “legacy networks”). Legacy networks, such as third generation (3G), and second generation (2G) networks, may employ circuit-switching for voice communications, while LTE networks employ packet-switching for both data and voice communications in an all-IP data transport technology. In general, 4G LTE-compliant and 5G New Radio (NR)-compliant UEs are configured to prefer attachment to corresponding networks, which offer relatively high data-rate throughput as compared to available legacy networks. In most UEs, a choice of which protocol to employ depends primarily on what networks are available to the UE at the UE's present geographic location. Furthermore, in instances where the preferred network (e.g., 4G 5G, etc.) is unavailable or unusable for any reason, legacy networks, if available, may be used as a fallback protocol, such as by using a circuit-switch fallback (CSFB) mechanism. The originating UE 100 of
Before attempting to setup and establish a communication session, the originating UE 100 may perform the attach procedure 106, which may include, among other sub-procedures, requesting registration for one or more IMS-based services provided via the IMS core 102. Registration of the originating UE 100 can involve identifying a proxy CSCF (P-CSCF) node of the IMS core 102, and sending a registration request via a RAN (e.g., an LTE RAN) to an address of the P-CSCF node.
As used herein, a “request” is a message that is sent from a UE, such as the originating UE 100, to a network node (e.g., a node of the IMS core 102, the MME 104, etc.). Meanwhile, a “response” is a message that is sent from a network node to a UE, such as the originating UE 100. This construct may be used when discussing communications that use any particular signaling protocol. For example, Session Initiation Protocol (SIP) may be used by the originating UE 100 for transmitting messages to/from the IMS core 102. Accordingly, a “SIP request” is a message that is sent from a UE, such as the originating UE 100, to the IMS core 102 using SIP protocol, and a “SIP response” is a message that is sent from the IMS core 102 to a UE, such as the originating UE 100, using SIP protocol. SIP is a signaling protocol that can be used to establish, modify, and terminate multimedia sessions (e.g., a multimedia telephony call) over packet networks, and to authenticate access to IMS-based services. Accordingly, during the attach procedure 106, the originating UE 100 may send a registration request using the SIP REGISTER method as part of the initial procedures for establishing a multimedia communication session. The IMS core 102 allows for peer-to-peer communications, as well as client-to-server communications over an IP-based network. Accordingly, the IMS core 102 can represent any type of SIP-based network that is configured to handle/process SIP signaling packets or messages.
In
In the case of a 3 digit emergency short code (“911” in the United States), the initial setup procedures 110 may include one or more setup procedures that are particular to the emergency type of communication session. For example, the originating UE 100 may send, as part of the initial setup procedures 110 for a 911 call, an emergency packet data network (E-PDN) connection request to the MME 104. Such a request may be sent from the UE 100 using Non-Access Stratum (NAS) protocol. NAS is actually a set of protocols in the EPS, and is used to convey non-radio signaling between a UE, such as the originating UE 100, and the MME 104 for LTE/E-UTRAN access. Continuing with the emergency call example, the initial setup procedures 110 may further include a response (e.g., an E-PDN connected response) from the MME 104 to the originating UE 100 indicating that the UE 100 is connected to the E-PDN. The originating UE 100 may also send an emergency registration (E-REG) request as part of the initial setup procedures 110, and may receive a response to the E-REG request indicating a successful emergency registration.
At least one of the initial setup procedures 110 may include a communication session request 110(1) sent from the originating UE 100 to the IMS core 102. As shown in
It is to be appreciated that the initial setup procedures 110 can include various actions and message transmissions by and between the originating UE 100 and various network nodes in addition to the example actions and message transmission described herein, and that some or all of the example setup procedures 110 may be performed during session setup, depending on the implementation. In general, any suitable setup procedures known to a person having ordinary still in the art can be included in the initial setup procedures 110 of
The call setup timer 112 of
A timer value defines a period of time (e.g., N seconds) after which the timer 112 will expire, as measured from starting the timer 112 at 114. The timer value may be specified in any suitable unit of time (e.g., seconds, milliseconds, minutes, etc.).
The example call setup timer 112 of
Like the initial setup procedures 110, the additional setup procedures 116 (that occur after the trigger event), and the final setup procedures 120 (that occur after the termination event) can include various actions and message transmissions by and between the originating UE 100 and various network nodes, some of which are described below. It is to be appreciated that the setup procedures enumerated herein are merely examples, and that some or all of these example setup procedures may be performed, along with additional setup procedures known to a person having ordinary skill in the art, during session setup, depending on the implementation. Furthermore, setup procedures can vary by the type of communication session, such as an emergency communication session verses a normal (non-emergency) communication session. Setup procedures may also vary by attachment result, such as combined attached verses not combined attached.
Example setup procedures that may be included in the setup procedures 110, 116, and/or 120 are now described by way of example. For example, an individual setup procedure of the setup procedures 110, 116, and 120 can include, without limitation, the originating UE 100 sending/receiving any SIP request/response to/from the IMS core 102, such as sending a SIP INVITE request, receiving a 100 Trying response (indicating that a communication session request, such as the request 110(1), has been received at a terminating UE), receiving a 180 Ringing response (indicating that a called party of the terminating UE is being alerted), receiving a 181 Call Being Forwarded response, receiving a 182 Queued response, receiving a 183 Session In Progress response, receiving a SIP response that includes session description protocol (SDP) information (e.g., an SDP answer), receiving a SIP response that includes “early media” (e.g., user data), and/or receiving a final response (most likely as part of the final setup procedures 120) to resolve the setup of the communication session. Such a final SIP response can be in the form of a 2xx—successful (e.g., a 200 (OK) response indicating successful connection), 3xx—redirection, 4xx—client failure, 5xx—server failure, or 6xx—global failure, and so on.
Further examples of the setup procedures 110, 116, and 120 of
Setup procedures for a given communication session may vary by implementation, session type (e.g., phone call verses video conference, emergency verses non-emergency call, etc.), attachment result (e.g., combined attached verses not combined attached), and/or other factors. Accordingly, detailed and exhaustive examples of setup procedures and the order in which they are performed in order to setup a communication session are not described herein, as the various possible setup procedures are generally known to a person having ordinary skill in the art. As such, any given session setup may include some or all of the example setup procedures described herein, performed in a suitable order to establish a communication session, such as a VoLTE call. It is to be appreciated that a communication session is not successfully established unless and until the originating UE 100 receives a final SIP response in the form of a 2xx response.
Turning to
In response to the timer 112 firing/expiring/timing out at 122, the originating UE 100 may perform a designated “fire” action 124. The fire action 124 taken by the originating UE 100 can vary, depending on the implementation. In some embodiments, the fire action 124 includes the originating UE 100 halting, at 126, any remaining setup procedures that were to be carried out by the originating UE 100 in an attempt to setup and establish the communication session, as well as reattempting the setup of the communication session with new setup procedures 128. In this manner, the fire action 124 can comprise multiple actions (e.g., halting and reattempting, as shown in
The example call setup timer 112 depicted in
The example of
Thus, the timer 212 of
Turning to
In response to the timer 212 firing/expiring at 222 (the meaning of “firing” and “expiring” is explained elsewhere in this disclosure), the originating UE 200 may perform a designated “fire” action 224, which can be any suitable fire action, as described herein, including halting, at 226, any remaining setup procedures that were to be carried out by the originating UE 200 in an attempt to setup and establish the communication session on a previous attempt, as well as reattempting the setup of the communication session with new setup procedures 228.
The example timer 212 depicted in
Table 1, below, shows examples of different session setup timers that can be implemented by an originating UE 100/200 according to the techniques and systems described herein. Timer “E” represents an example of the timer 112 discussed with reference to
The processes described in this disclosure may be implemented by the architectures described herein, or by other architectures. These processes are illustrated as a collection of blocks in a logical flow graph. Some of the blocks represent operations that can be implemented in hardware, software, or a combination thereof. In the context of software, the blocks represent computer-executable instructions stored on one or more computer-readable storage media that, when executed by one or more processors, perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, and the like that perform particular functions or implement particular abstract data types. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described blocks can be combined in any order or in parallel to implement the processes. It is understood that the following processes may be implemented on other architectures as well.
At 302, an originating UE 100/200 can send an attachment request to establish a radio link with a RAN that is within communication range of the UE 100/200. For example, the originating UE 100/200 can attach to an eNodeB within communication range of the UE 100/200, the eNodeB forming part of a RAN that provides LTE coverage for establishing a communication session over an LTE network.
At 304, the originating UE 100/200 establishes a radio link with the RAN. As described herein, the attachment result at block 304 can vary depending on the circumstances. For example, if, in addition to LTE coverage, the originating UE 100/200 is at a geographic location that is within a coverage area of a legacy network, the radio link established at block 304 as a result of the attachment request at block 302 may be a result where the originating UE 100/200 is combined attached, and is able to utilize the legacy (e.g., CS) network as a fallback measure (e.g., CSFB). In different circumstances, such as when the UE 100/200 is at a geographic location in an LTE-only coverage area, the attach result at block 304 may be a result where the UE 100/200 is not combined attached (e.g., an EPS-only attach result). Blocks 302 and 304, in combination, may represent the attach procedure 106/206 referenced in the discussion of
At 306, after the originating UE 100/200 is successfully attached and registration for IMS services is completed, the originating UE 100/200 may receive user input requesting to establish a communication session. The manner in which a user initiates a communication session (e.g., a call) can vary according to the examples provided herein. In the context of a call, the user may provide input to a touchscreen of the UE 100/200, for example, to dial a phone number or select a contact associated with a stored phone number.
At 308, the UE 100/200 may determine a set of setup procedures that are to be performed in order to setup the requested communication session. As noted above, the setup procedures may vary by the type of communication session (e.g., emergency verses non-emergency) initiated at block 306, and/or by the attachment result (e.g., combined attached verses not combined attached) at block 304. Accordingly, the determining at block 308 may include determining the type of communication session requested at block 306 and/or determining a result of the attachment request at block 304, and, based on the type of communication session and/or the attachment result, determining (e.g., looking up) the setup procedures to perform in order to setup the type of communication session requested.
At 310, the originating UE 100/200 may determine the relevant session setup timers 112/212 to be implemented based at least in part on the setup procedures determined at block 308. For example, given a set of setup procedures, the originating UE 100/200 can scan a table listing all available session setup timers for trigger events and termination events that match the setup procedures determined at block 308. This may be useful, for example, when an available timer 112/212 is triggered and terminated by setup procedures that are unique to an emergency call (e.g., a 911 call), and the user dials a non-emergency number at block 306. In this example scenario, the UE 100/200 determines that the available timer 112/212 that is triggered by emergency-related setup procedures is not implicated by the setup procedures determined for the non-emergency call, and thus, the timer 112/212 is excluded from a set of one or more relevant timers at block 310. In other words, the UE 100/200 can determine a subset of available timers that can possibly be triggered and terminated by the setup procedures determined at block 308. This sub-process of excluding irrelevant timers from consideration/implementation during session setup can conserve processing resources, as fewer timers are monitored for trigger events during session setup. Alternatively, the UE 100/200 may implement all available timers by omitting block 310 from the process 300.
At 312, the originating UE 100/200 may begin performing the multiple setup procedures that were determined at block 308 in order to setup the communication session. Again, because the particular setup procedures may vary by type of communication session and/or by the attachment result, the first few setup procedures can vary.
At 314, any implemented session setup timers 112/212 are monitored for the occurrence of a designated trigger event that starts the timer 112/212. Multiple different timers 112/212 can be monitored in parallel. As such, block 314 represents the monitoring of a trigger event, which may represent a trigger event that is designated for a particular session setup timer 112/212, or perhaps a common trigger event for multiple session setup timers that have different termination events. In some embodiments (as shown in
So long as the trigger event does not occur during performance of the setup procedures at block 312, the process 300 follows the “no” route from block 314 to block 312, by continuing to perform the setup procedures 312 with the aim of setting up the communication session. Once the trigger event occurs at block 314, however, the process 300 follows the “yes” route from block 314 to block 316 where a timer(s) 112/212 associated with the trigger event can be started in response to performance of the trigger event. The timer(s) 112/212 can be a local hardware or software timer(s) that is started by the originating UE 100/200 at block 316, and the timer 112/212 is configured to expire after a period of time since starting the timer at block 316. The period of time can be defined by a timer value, as described herein.
At 318, the originating UE 100/200 may continue performing the multiple setup procedures that were determined at block 308 in order to setup the communication session. The additional setup procedures include a subset of the multiple setup procedures that have not already been performed at block 312 leading up to the occurrence of the trigger event at block 314.
At 320, the session setup timer(s) 112/212 that was started at block 318 is monitored for timeout prior to the occurrence of a designated termination event that stops the timer(s) 112/212. The example process 300 will be described with respect to a single timer, but if multiple different timers 112/212 were started at block 316 by the occurrence of a common trigger event, those multiple timers 112/212 can be monitored in parallel for respective timeouts. In the multiple timer scenario, each timer 112/212 can have a different timer value, or multiple timers 112/212 can have the same timer value. In addition, if other session setup timers 112/212 are triggered by different trigger events, the process 300 can branch off for each triggered timer, in which case, the remainder of the process after starting each timer is similar to that described herein for a single timer.
If, at block 320, the time period for the triggered timer expires before the occurrence of the designated termination event, the process 300 follows the “yes” route from block 320 to block 322, where the originating UE 100/200 performs a fire action, as described herein. As an example, the fire action at block 322 may comprise halting the multiple setup procedures, and reattempting the setup of the communication session with new setup procedures 128/228. The new setup procedures 128/228 can be the same or different as the previously performed setup procedures. In some embodiments, reattempting the setup of the communication session with the new setup procedures 128/228 can comprise using at least one of a legacy telecommunications network (e.g., a CS network) where the originating UE 100/200 had previously attempted to establish the communication session over an LTE network. As another example, a reattempt at block 322 may use a different type of RAN, or a different type of RAT, as compared to the type of RAN or RAT that was previously used by the originating UE. This can include switching from VoLTE calling via a 3GPP RAN (e.g., an eNodeB) to VoWiFi calling via a non-3GPP (e.g., WiFi) RAN, using a wireless AP within communication range of the originating UE 100/200. As yet another example, a reattempt at block 322 may use a different address of a P-CSCF node as compared to the address of a previously used P-CSCF node during the previous attempt. Other fire actions that can be performed at block 322 may be listed in Table 1, herein.
If, at block 320, the timer 112/212 has not yet timed out/expired/fired, the process 300 follows the “no” route from block 320 to block 324, where the originating UE 100/200 monitors for the occurrence of a termination event that is designated for the timer 112/212. In some embodiments (as shown in
So long as the termination event does not occur during performance of the additional setup procedures at block 318, the process 300 follows the “no” route from block 324 to block 318, by continuing to perform the additional setup procedures at block 318 with the aim of setting up the communication session, and iterating over blocks 320 and 324 to monitor both the timeout of the timer 112/212 and the occurrence of the termination event. If the termination event occurs at block 324 prior to expiration of the timer 112/212, the process 300 follows the “yes” route from block 324 to block 326 where a timer(s) 112/212 associated with the termination event can be stopped in response to performance of the termination event.
At block 328, after the timer 112/212 is stopped, the originating UE 100/200 can establish the communication session over a telecommunications network. The successful establishment of the communication session at block 328 assumes that, in a situation where multiple session setup timers are implemented, none of the other timers 112/212 that were triggered during the session setup fired/expired/timed out.
Thus, the process 300 illustrates a flexible approach to using one or more session setup timers during setup of a communication session to determine if and when a fire action is to be performed at 322 during session setup. As described elsewhere herein, this may, in turn, alleviate downstream network issues, such as network outages, due to an intelligent implementation of session setup timers.
At 402, an originating UE 100/200 can send an attachment request to establish a radio link with a RAN that is within communication range of the UE 100/200. Sending the attachment request at block 402 may be similar to the description of block 302 of
At 404, the originating UE 100/200 establishes a radio link with the RAN. Establishing the radio link at block 404 may be similar to the description of block 304 of
At 406, after the originating UE 100/200 is successfully attached and registration for IMS services is completed, the originating UE 100/200 may receive user input requesting to establish a communication session. Receiving the user input at block 406 may be similar to the description of block 306 of
At 408, a type of communication session may be determined based on the user input received at 406. For example, if the user dialed 911 at block 406, the type of communication session may be determined as an emergency call. On the other hand, if the user dialed a 10 digit phone number of a friend at block 406, the type of communication session may be determined as a non-emergency call (or a normal call).
Accordingly, at 410, the originating UE 100/200 may determine whether the type of communication session is an emergency communication session. If so, the process 400 follows the “yes” route from block 410 to block 412, where the UE 100/200 may select, from among a plurality of timer values stored in memory (e.g., memory of the UE 100/200 or a remote memory resource), a timer value for a session setup timer 112/212 that corresponds to the emergency type of communication session (e.g., a 911 call). If, on the other hand, it is determined at 410 that the type of communication session is a non-emergency communication session (e.g., a normal call), the process 400 follows the “no” route from block 410 to block 414, where the UE 100/200 may select, from among the plurality of timer values stored in memory, a different timer value for a session setup timer 112/212 that corresponds to the non-emergency type of communication session (e.g., a call to a friend using a 10 digit phone number).
At 416, the originating UE 100/200 may begin performing setup procedures in order to setup the communication session. Again, because the particular setup procedures may vary by type of communication session and/or by the attachment result, the setup procedures can vary. In some embodiments, the setup procedures performed at 416 may include those setup procedures determined at block 308 of the process 300 in
At 418, for any implemented session setup timers 112/212 being monitored during session setup, the UE 100/200 may detect the occurrence of a trigger event. As described herein, the trigger event (e.g., setup procedure) detected at block 418 can comprise at least of: (i) sending a first request using a first signaling protocol or (ii) receiving a first response using the first signaling protocol. An example of this embodiment is described herein with reference to
At 420, in response to detection of the trigger event at block 418, the timer 112/212 associated with the trigger event can be started using the selected value. Thus, depending on the type of communication session, the timer can be started with a particular value at block 420 that corresponds to the type of communication session. In the case of an emergency call, for example, the timer 112/212 can be started with a timer value of 5 seconds, whereas, for a non-emergency call, the same timer 112/212 can be started with a timer value of 8 seconds. This allows for dynamic selection of an appropriate timer value depending on the type of communication session.
At 502, the originating UE 100/200—that started the timer at block 420 of the process 400—may continue performing setup procedures that have not already been performed leading up to the occurrence of the trigger event at block 418.
At 504, the triggered timer 112/212 times out/expires/fires before the occurrence of a designated termination event associated with the timer 112/212. Expiration of the timer at block 504 means that the originating UE 100/200 performs a fire action designated for the timer. However, the fire action may vary depending on the attachment result at block 404 of the process 400.
Accordingly, at 506, the originating UE 100/200 may determine a result of the UE's 100/200 attachment request, such as by determining whether the UE 100/200 is combined attached or not.
At 508, if it is determined that the originating UE 100/200 is combined attached, the process 500 follows the “yes” route from block 508 to block 510, where the UE 100/200 may select, from among a plurality of fire actions stored in memory (e.g., memory of the UE 100/200 or a remote memory resource), a fire action for the triggered session setup timer 112/212 that corresponds to a combined attached result of the attachment request. If, on the other hand, it is determined at 508 that the originating UE 100/200 is not combined attached (e.g., EPS-only attached), the process 500 follows the “no” route from block 508 to block 512, where the UE 100/200 may select, from among the plurality of fire actions stored in memory, a different fire action for the triggered session setup timer 112/212 that corresponds to a non-combined attached result.
At 514, the originating UE 100/200 performs the selected fire action. As an example, the UE 100/200 may select a fire action at block 510 (corresponding to the combined attached result) that includes reattempting the setup of the communication session using at least one of a legacy telecommunications network (e.g., a CS network). As another example, the UE 100/200 may select a fire action at block 512 (corresponding to the non-combined attached result) that includes reattempting the setup of the communication session using a different type of RAN, or a different type of RAT, as compared to the type of RAN or RAT that was previously used by the originating UE. Other fire actions that can be selected at block 510 or 512 and performed at block 514 may be listed in Table 1, herein.
As shown, the UE 600 may include one or more processors 602 and one or more forms of computer-readable memory 604. The UE 600 may also include additional storage devices. Such additional storage may include removable storage 606 and/or non-removable storage 608.
The UE 600 may further include input devices 610 (e.g., a touch screen, keypad, keyboard, mouse, pointer, microphone, etc.) and output devices 613 (e.g., a display, printer, speaker, etc.) communicatively coupled to the processor(s) 602 and the computer-readable memory 604. The UE 600 may further include communications interface(s) 614 that allow the UE 600 to communicate with other computing devices 616 (e.g., IMS nodes) such as via a network (e.g., the IMS core 102/202, the MME 104/204, etc.). The communications interface(s) 614 may facilitate transmitting and receiving wired and/or wireless signals over any suitable communications/data technology, standard, or protocol, as described herein. For example, the communications interface(s) 614 can comprise one or more of a cellular radio, a wireless (e.g., IEEE 802.1x-based) interface, a Bluetooth® interface, and so on. In some embodiments, the communications interface(s) 614 may include radio frequency (RF) circuitry that allows the UE 600 to transition between different RATs, such as transitioning between communication with a 4G LTE RAT and a legacy RAT (e.g., 3G/2G). The communications interface(s) 614 may further enable the UE 600 to communicate over circuit-switch domains and/or packet-switch domains.
In various embodiments, the computer-readable memory 604 comprises non-transitory computer-readable memory 604 that generally includes both volatile memory and non-volatile memory (e.g., random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EEPROM), Flash Memory, miniature hard drive, memory card, optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium). The computer-readable memory 604 may also be described as computer storage media and may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. Computer-readable memory 604, removable storage 606 and non-removable storage 608 are all examples of non-transitory computer-readable storage media. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the UE 600. Any such computer-readable storage media may be part of the UE 600.
The memory 604 can include a session setup module 618 (i.e., computer-executable instructions (or logic) that, when executed, by the processor(s) 602, perform the various acts and/or processes disclosed herein. For example, the session setup module 618 can be configured to carry out the setup procedures described herein that can include various actions and message transmissions for setting up and establishing a communication session (e.g., a VoLTE call).
As shown in
The memory 604 can further be used to store timer parameters 620, such as trigger events, termination events, timer values, and/or fire actions associated with particular timers. Table 1 includes examples of timer parameters 620 that may be stored in memory of the originating UE 600. Although the timer parameters are illustrated as being stored locally on the UE 600, the UE 600 may be configured to access the timer parameters from a remote storage location, such as a Cloud-based service that maintains timer parameters and continually updates those parameters. For locally stored timer parameters, parameter updates may be pushed, periodically, to the UE 600 for storage in the memory 604.
The environment and individual elements described herein may of course include many other logical, programmatic, and physical components, of which those shown in the accompanying figures are merely examples that are related to the discussion herein.
The various techniques described herein are assumed in the given examples to be implemented in the general context of computer-executable instructions or software, such as program modules, that are stored in computer-readable storage and executed by the processor(s) of one or more computers or other devices such as those illustrated in the figures. Generally, program modules include routines, programs, objects, components, data structures, etc., and define operating logic for performing particular tasks or implement particular abstract data types.
Other architectures may be used to implement the described functionality, and are intended to be within the scope of this disclosure. Furthermore, although specific distributions of responsibilities are defined above for purposes of discussion, the various functions and responsibilities might be distributed and divided in different ways, depending on circumstances.
Similarly, software may be stored and distributed in various ways and using different means, and the particular software storage and execution configurations described above may be varied in many different ways. Thus, software implementing the techniques described above may be distributed on various types of computer-readable media, not limited to the forms of memory that are specifically described.
This U.S. patent application is a continuation of and claims priority to co-pending and commonly assigned U.S. patent application Ser. No. 15/640,150, entitled “CALL SETUP TIMER TRIGGERED AND TERMINATED BY DIFFERENT PROTOCOLS,” and filed on Jun. 30, 2017, which claims priority to provisional U.S. patent application Ser. No. 62/469,391, entitled “VoLTE Call Setup Timer Triggers,” and filed on Mar. 9, 2017. application Ser. No. 15/640,150 and Application Ser. No. 62/469,391 are incorporated herein by reference in their entirety.
| Number | Date | Country | |
|---|---|---|---|
| 62469391 | Mar 2017 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 15640150 | Jun 2017 | US |
| Child | 16240519 | US |
