HK1185211B - Handling wait time in a congested wireless communication network - Google Patents

Description

Handling latency in congested wireless communication networks

Cross reference to related applications

This application claims priority to U.S. provisional patent application No.61/595,576, entitled "Advanced wireless communication Systems and Techniques", filed on 6/2/2012, which is hereby incorporated by reference in its entirety for all purposes.

Technical Field

Embodiments of the present disclosure relate generally to the field of wireless communication systems, and more specifically to techniques and configurations for handling congestion in a wireless communication network.

Background

Interactions between a wireless device and the wireless communication network in which the device operates may be directed according to a particular set of protocols or rules configured to handle such interactions. A wireless device (e.g., a machine-to-machine device) may send a communication (e.g., a request for a connection) to a network in order to establish a connection that allows the device to communicate messages (e.g., data) to another device or machine over the network. In some instances, the network may be overloaded (e.g., "congested") and may deny the device request. The network may then provide the device with a latency value during which the device may not be allowed to reconnect with the network. However, in some instances, the latency value may be provided without necessary security protection, or may conflict with another latency value that may have been provided to the device prior to the device submitting the communication.

Drawings

The embodiments will be readily understood by the following detailed description in conjunction with the accompanying drawings. To simplify this description, like reference numerals designate like structural elements. Embodiments are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings.

Fig. 1 illustrates an example wireless communication network in accordance with some embodiments.

Fig. 2 and 3 are block diagrams illustrating example communications between a user equipment (mobile device) and a wireless communication network, in accordance with some embodiments.

Fig. 4 is a process flow diagram of communications between a user equipment and a network server in a wireless communication network, in accordance with some embodiments.

Fig. 5 is a process flow diagram of handling latency provided to a mobile device in a congested wireless network environment in accordance with some embodiments.

Fig. 6 illustrates an example system that can be used to implement various embodiments described herein.

Detailed Description

Embodiments of the present disclosure provide data techniques and configurations in wireless communication networks, including techniques and configurations to handle latency in congested wireless communication networks. In the following detailed description, reference is made to the accompanying drawings which form a part hereof wherein like numerals designate like parts throughout, and in which is shown by way of illustration embodiments in which the subject matter of the present disclosure may be practiced. It is to be understood that other embodiments may be utilized and structural or logical changes may be made without departing from the scope of the present disclosure. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of embodiments is defined by the appended claims and their equivalents.

Various operations will be described as multiple discrete operations in turn, in a manner that is most helpful in understanding the claimed subject matter. However, the order of description should not be construed as to imply that these operations are necessarily order dependent. In particular, these operations may not be performed in the order of presentation. The operations described may be performed in a different order than the embodiments described. In additional embodiments, various additional operations may be performed and/or the described operations may be omitted.

The description may use the phrases "in an embodiment" or "in an embodiment," which may each refer to one or more of the same embodiment or different embodiments. Furthermore, the terms "comprising," "including," "having," and the like, as used with respect to embodiments of the present disclosure, are synonymous.

The term module, as used herein, may refer to or include an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group) and/or memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable components that provide the described functionality, or may be part of such components.

Example embodiments may be described herein with respect to wireless communication networks including, for example, third generation partnership project (3GPP) Long Term Evolution (LTE) networks, including any amendments, updates, and/or revisions (e.g., LTE release 10 (also referred to as LTE-Advanced (LTE-a)), LTE release 11, etc.), Worldwide Interoperability for Microwave Access (WiMAX) networks, and so forth. Embodiments described herein may operate with respect to a radio access network, such as an evolved universal terrestrial radio access network (E-UTRAN) with evolved node base stations (enbs) and a core network (e.g., an evolved packet core with gateways, management entities, etc.).

In other embodiments, the communication schemes described herein may be compatible with additional/alternative communication standards, specifications, and/or protocols. For example, embodiments of the present disclosure may be applied to other types of wireless networks where similar advantages may be obtained. Such networks may include, but are not limited to, Wireless Local Area Networks (WLANs), Wireless Personal Area Networks (WPANs), and/or Wireless Wide Area Networks (WWANs) (e.g., cellular networks), among others.

The following embodiments may be used in various applications including transmitters and receivers of a mobile radio system. Radio systems specifically included within the scope of embodiments include, but are not limited to, Network Interface Cards (NICs), network adapters, base stations, Access Points (APs), relay nodes, enbs, gateways, bridges, hubs, and satellite radiotelephones. Moreover, the radio systems within the scope of the embodiments may include satellite systems, Personal Communication Systems (PCS), two-way radio systems, Global Positioning Systems (GPS), two-way pagers, Personal Computers (PC) and related peripherals, Personal Digital Assistants (PDA), personal computing accessories and all existing and future arising systems which may be substantially related and to which the principles of the embodiments suitably may be applied.

The techniques described herein provide for handling various types of communications, such as connections and other requests, between a UE and a network controller in a wireless network environment, where the network may be congested and unable to immediately accept requests or other communications from the UE. If it is determined that the network is congested and therefore unable to process requests from the UE, the network may provide the UE with a latency value during which the UE may refrain from attempting to contact or connect to the network. The handling of the provided latency value by the UE in different scenarios is described in more detail below.

Fig. 1 schematically illustrates an example wireless network 100 in accordance with some embodiments. Network 100 may include RAN20 and core network 25. In some embodiments, the network 100 may be an LTE network, the RAN20 may be an E-UTRAN, and the core network 25 may be an evolved core network, such as EPS (evolved packet system). The UE 15 may access the core network 25 via a radio link ("link") with an eNB (e.g., one of the enbs 40, 42, etc.) in the RAN 20. The UE 15 may be, for example, a subscriber station (e.g., a mobile device) configured to communicate with the enbs 40, 42 in accordance with one or more protocols. For ease of discussion, the following description is provided for an example 3 GPP-compliant network 100; however, the subject matter of the present disclosure is not limited in this regard and the described embodiments may be applicable to other networks that benefit from the principles described herein. In some embodiments, the UE 15 may be configured to communicate using a multiple-input and multiple-output (MIMO) communication scheme. One or more antennas of the UE 15 may be used to simultaneously utilize radio resources of multiple respective component carriers of the RAN20 (e.g., which may correspond to antennas of the enbs 40, 42). In some embodiments, the UE 15 may be configured to communicate in, for example, downlink communications using Orthogonal Frequency Division Multiple Access (OFDMA) and/or in uplink communications using single carrier frequency division multiple access (SC-FDMA).

Although fig. 1 depicts the UE 15 generally as a mobile device (e.g., a cellular telephone), in various embodiments the UE 15 may be a Personal Computer (PC), notebook computer, ultrabook, netbook, smartphone, ultra mobile PC (umpc), handheld mobile device, Universal Integrated Circuit Card (UICC), Personal Digital Assistant (PDA), client device (CPE), tablet, or other consumer electronic device (e.g., MP3 player, digital camera, etc.). In an embodiment, the UE 15 may be a Machine Type Communication (MTC) device, also referred to as a machine-to-machine device. In this disclosure, the terms UE and mobile device will be used interchangeably for simplicity purposes. The enbs 40, 42 may include one or more antennas, one or more radio modules to modulate and/or demodulate signals transmitted or received over the air interface, and one or more digital modules to process signals transmitted and received over the air interface.

In some embodiments, communication with the UE 15 via the RAN20 may be facilitated by means of one or more nodes 45 (e.g., radio network controllers). One or more nodes 45 may act as an interface between core network 25 and RAN 20. According to various embodiments, one or more nodes 45 may include a Mobility Management Entity (MME) configured to manage signaling exchanges (e.g., authentication and NAS (non-access stratum) messages for UE 15) between base stations 40, 42 and core network 25 (e.g., one or more servers 50), a packet data network gateway (PGW) providing gateway routers to internet 65, and/or a Serving Gateway (SGW) managing user data tunnels or paths between enbs 40, 42 and the PGW of RAN 20. Other types of nodes may be used in other embodiments.

The core network 25 may include logic (e.g., modules) to provide authentication of the UE 15 or other actions associated with establishment of a communication link to provide status of the connection of the UE 15 with the network 100. For example, the core network 25 may include one or more servers 50 that may be communicatively coupled to the base stations 40, 42. In an embodiment, the one or more servers 50 may include a Home Subscriber Server (HSS) that may be used to manage subscriber parameters (e.g., the subscriber's International Mobile Subscriber Identity (IMSI), authentication information, etc.). The core network 25 may include other servers, interfaces, and modules. In some embodiments, logic associated with different functionality of one or more servers 50 may be consolidated to reduce the number of servers, including, for example, consolidating them into a single machine or module.

According to various embodiments, network 100 may be an Internet Protocol (IP) based network. For example, the core network 25 may be, at least in part, an IP-based network, such as a packet-switched (PS) network. The interface between network nodes (e.g., one or more nodes 45) may be IP-based, including backhaul connections to the base stations 40, 42. In some embodiments, the network may be enabled to provide connectivity to a Circuit Switched (CS) network (e.g., CS domain). In embodiments, the UE may communicate with the network according to one or more communication protocols, such as a Radio Resource Control (RRC) protocol suitable for an LTE communication environment.

An example connection diagram between the UE 15 and the network 100 is shown in fig. 2. As diagram 200 illustrates, UE 15 may send an RRC connection request message 204 to a network controller 206. The RRC connection request message 204 may be a request by the UE 15 for allocation of radio resources so that the UE 15 may communicate data with the RAN 20. The network controller 206 may control establishment and/or maintenance of RRC connections between the UE and the RAN 20. The network controller 206 may be deployed in the eNB 40 or 42 with which the UE 15 attempts to establish an RRC connection. In other embodiments, network controller 206 or components thereof may be deployed in additional/alternative network entities, such as nodes in one or more of nodes 45, servers in one or more of servers 50, and so forth.

If the RAN20 is congested and is not able to support an RRC connection associated with the RRC connection request 204, the network controller 206 may respond with an RRC connection reject message 208 to reject the RRC connection request 204. In which case an RRC connection between the UE 15 and the RAN20 may not be established.

In some instances, for a particular type of device (e.g., MTC device), the network controller 206 may provide a latency (WT) value, also referred to as deferred latency or EWT, in the connection rejection message 208. (for simplicity, the terms "deferred latency value," "latency value," and "latency" will be used interchangeably herein). A timer associated with the device, referred to as a "backoff timer," may be started running for the duration of the wait time and may keep the device "suspended," i.e., refrain from transmitting communications to the network until the wait time expires and the device may be allowed to resend the request to the network (or reestablish a connection with the device). However, because a secure communication mode has not been established, the UE 15 may receive the latency value provided by the network controller 206 without security protection.

In other instances, a latency value may be provided to a device (UE). Fig. 3 is a block diagram 300 illustrating an example where the UE 15 may initiate a connection request by sending an RRC connection request message 304 to the network controller 206. The network controller 206 in this example may determine that the RAN20 may be able to support the RRC connection associated with the RRC connection request 304. Thus, the network controller 206 may respond with a connection setup message 308. Many other "handshake" messages (not shown) may be communicated between the UE 15 and the network controller 206 according to the adapted communication protocol. For example, the UE 15 may respond to the connection setup message 308 with a notification that the connection setup is complete; the network controller 306 may issue a security mode establishment command; the UE 15 may inform the network controller 306 that the security mode has been established. In one embodiment, the network controller 306 may provide an RRC connection release message 310 that may include a latency value. In instances where RRC connection release occurs immediately after RRC connection establishment, there may not be time for security mode setup. Thus, the latency may be received in an unsecure mode.

In summary, when the network is congested, the network controller 206 may specify a deferral latency and require the UE 15 to "back off for the duration of the latency. As discussed, when the network controller 206 determines that the network (e.g., RAN 20) is congested, this may occur during connection establishment or during other types of communications (e.g., RRC signaling) between the UE 15 and the network. When the network controller 206 determines that the network (e.g., RAN 20) is congested, this may also occur during RRC connection release, and the UE 15 should "back off" for all future requests.

There may also be a need to handle the deferred latency of other types of communications, for example during messaging associated with non-access stratum (NAS) functionality that supports mobility and session management procedures for the UE 15 to establish and maintain IP connectivity between the UE 15 and external packet data networks. As discussed, the deferred latency may be received with security protection in some cases, and without security protection in other cases. Further, the UE 15 may receive the deferred latency (e.g., in an RRC reject message or a connection release message) when the backoff timer may already be running on the device. The disclosed technology provides for the handling of latency by the mobile device in the above scenario.

Fig. 4 is a process flow diagram illustrating communication between a network controller (e.g., network controller 206) and a UE (e.g., UE 15) in a wireless network environment according to an embodiment. Process 400 begins at block 402, where a network controller may receive a connection request from a UE. As discussed above, there may be different types of communications initiated by the mobile device, e.g., RRC connection requests. At decision block 404, for example, the network controller may determine whether network congestion is above some determined level that allows a connection to be established with the device. Network congestion may be based on one or more congestion characteristics such as, but not limited to, effective bandwidth throughput, loss, delay, congestion, and/or other known characteristics. If it is determined that the network congestion is below the determined level, the connection for the UE is accepted at block 408. If it is determined that the network congestion and/or overload is above the determined level, the network controller may reject the connection along with the latency value (e.g., the network controller may send the RRC connection reject message described above) at block 410.

Fig. 5 is a process flow diagram illustrating handling latency provided to a UE (e.g., UE 15) in a congested wireless network environment in accordance with an embodiment. Process 500 begins at block 502, where a communication may be sent to a network controller, such as network controller 206. As discussed above, the communication may be any type of request, such as an RRC connection request.

At block 504, the UE may receive a response from the network controller. In one example, if the network is congested, the response may include a rejection of the request for connection (e.g., an RRC connection reject message), which may include a latency value generated by the network controller for the UE. Other types of communications between the UE and the network controller may include the NAS connection release instance discussed with respect to fig. 3 or other "abnormal" situations resulting from the unexpected receipt of a latency value from the network controller. For example, in the NAS signaling connection example discussed above, the UE may receive the deferred latency value from the network along with an RRC connection release message. In other examples, the deferred latency value may be included in a network response to a UE-provided attach request message, tracking area update request message, location update request message, routing area update request message, or service request message.

At decision block 508, it may be determined whether a backoff timer associated with the UE is running. This situation may occur, for example, when the network has been congested and the UE has been required to back off and is therefore running a back off timer. If it is determined that the back-off timer is running, a determination may be made at block 510 to ignore the received latency value, after which process 500 proceeds to block 516. Because the received latency value may be unprotected (e.g., received in an unsecure mode), the value of the running back-off timer may not need to be modified. When the latency value is secured or unprotected, the UE may ignore the received latency value and simply rely on the back-off timer that is already running. (in some cases if the timer value is protected and if the timer is already running, the UE may stop the timer and restart the timer with the newly received value that is integrity protected).

If it is determined that the back-off timer is not running, then at decision block 512 it may be determined whether any other additional (e.g., predetermined) criteria associated with handling the received latency are met. For example, one such criterion may be that the UE is a low priority device (e.g., MTC device). In an embodiment, the determination regarding device priority may be made based on a priority indicator included in an initial communication (e.g., RRC connection request) of the UE. In other examples, UE communications (e.g., an attach request message, a tracking area update request message, a location update request message, a routing area update request message, or a service request message) may each include a priority indicator (e.g., a low priority indicator). Other criteria may include procedures to determine that are already running on the device, such as attachment, tracking area update, location update, or service request procedures. If any of these processes are ongoing, it may be desirable to handle the latency received from the network.

If it is determined at block 512 that the additional predetermined criteria are not met, the process proceeds to block 510, where the received latency value may be ignored. For example, in the instance of releasing the NAS signaling connection (i.e., when the network releases the RRC connection), the UE may ignore the network-provided deferred latency value when no attach, tracking area update, or service request procedures are ongoing.

If it is determined at block 512 that the additional predetermined criteria are met (e.g., it is determined that the mobile device is a low priority device), a back-off timer is started at block 514 with the received latency value. (different criteria may apply in different situations-for example, depending on how the operator configures the network system, the above examples may be equally applicable to low priority and normal devices, as well as other priority class (e.g., emergency class and Access Class (AC)11-15) devices).

At decision block 516, it may be determined whether the running back-off timer has expired. If it is determined that the back-off timer is still running, process 500 moves back to block 516. Once it is determined that the back-off timer has expired, the communication may be re-sent to the network server or a different communication may be initiated at block 518.

Embodiments of the present disclosure may be implemented into a system using any suitable hardware and/or software to configure as desired. Fig. 6 schematically illustrates an example system that can be used to implement various embodiments described herein. For one embodiment, fig. 6 illustrates an example system 600, the example system 600 having one or more processors 604, a system control module 608 coupled to at least one of the processor(s) 604, a system memory 612 coupled to the system control module 608, non-volatile memory (NVM)/storage 616 coupled to the system control module 608, and one or more communication interfaces 620 coupled to the system control module 608.

In some embodiments, system 600 may be capable of functioning as UE 15 as described herein. In other embodiments, system 600 may be capable of functioning as one or more nodes 45 or one or more servers 50 of fig. 1, or otherwise providing logic/modules that perform the functions as described with respect to enbs 40, 42 and/or other modules described herein. In some embodiments, system 600 may include one or more computer-readable media (e.g., system memory or NVM/storage 616) having instructions and one or more processors (e.g., processor(s) 604) coupled with the one or more computer-readable media and configured to execute the instructions to implement modules that perform the actions described herein.

System control module 608 for one embodiment may include any suitable interface controllers to provide for any suitable interface to at least one of processor(s) 604 and/or to any suitable device or component in communication with system control module 608.

The system control module 608 may include a memory controller module 610 to provide an interface to a system memory 612. The memory controller module 610 may be a hardware module, a software module, and/or a firmware module.

System memory 612 may be used to load and store data and/or instructions for system 600, for example. For example, system memory 612 for one embodiment may comprise any suitable volatile memory, such as suitable DRAM. In some embodiments, the system memory 612 may include double data rate type quad synchronous dynamic random access memory (DDR4 SDRAM).

System control module 608 for one embodiment may include one or more input/output (I/O) controllers to provide an interface for NVM/storage 616 and communication interface(s) 620.

For example, NVM/storage 616 may be used to store data and/or instructions. NVM/storage 616 may include, for example, any suitable non-volatile memory (e.g., flash memory) and/or may include, for example, any suitable non-volatile storage device(s), such as one or more hard disk drive(s) (HDD (s)), one or more Compact Disk (CD) drive(s), and/or one or more Digital Versatile Disk (DVD) drive(s).

NVM/storage 616 may include storage resources that are physically part of a device on which system 600 is installed, or NVM/storage 616 may be accessible by, but not necessarily part of, the device. The NVM/storage 616 may be accessed over a network via the communication interface(s) 620, for example.

Communication interface(s) 620 may provide an interface for system 600 to communicate over one or more networks and/or with any other suitable device. System 600 may wirelessly communicate with one or more components of a wireless network according to any of one or more wireless network standards and/or protocols.

For one embodiment, at least one of the processor(s) 604 may be packaged together with logic for one or more controller(s) of the system control module 608, such as a memory controller module 610. For one embodiment, at least one of the processor(s) 604 may be packaged together with logic for one or more controller(s) of the system control module 608 to form a System In Package (SiP). For one embodiment, at least one of the processor(s) 604 may be integrated on the same circuit chip as logic for one or more controller(s) of the system control module 608. For one embodiment, at least one of the processor(s) 604 may be integrated on the same circuit chip with logic for one or more controller(s) of the system control module 608 to form a system on a chip (SoC).

In various embodiments, the system 600 may be, but is not limited to, a server, a workstation, a desktop computing device, or a mobile computing device (e.g., a laptop computing device, a handheld computing device, a tablet, a netbook, etc.). In various embodiments, system 600 may have more or less components and/or different architectures. For example, in some embodiments, system 600 may include one or more of a camera, a keyboard, a Liquid Crystal Display (LCD) screen (including a touch screen display), a non-volatile memory port, multiple antennas, a graphics chip, an Application Specific Integrated Circuit (ASIC), and a speaker.

According to various embodiments, the present disclosure describes an apparatus comprising one or more computer-readable media having instructions and one or more processors coupled with the one or more computer-readable media, and configured to: executing the instructions to send a Radio Resource Control (RRC) request message to a network controller; receiving a response message including the deferred latency value from the network controller; determining whether a back-off timer associated with the apparatus is running when the response message is received; and determining whether to start a back-off timer with the received deferred latency value based at least in part on the determination of whether the back-off timer is running.

According to various embodiments, the present disclosure describes a system comprising a network controller configured to: receiving a Radio Resource Control (RRC) request message through a wireless communication network, determining whether the wireless communication network is congested; and based on the determination, providing a response message including the deferred latency value in response to the received RRC request message. The system also includes a device configured to: the method includes receiving a response message from a network controller including an deferred latency value, determining whether a backoff timer associated with a device is running when the response message is received, and determining whether to start the backoff timer at the received deferred latency value based at least in part on the determination of whether the backoff timer is running.

According to various embodiments, the present disclosure describes a computer-implemented method comprising: the apparatus generally includes means for sending a request message to a network controller, means for receiving a response message from the network controller including a deferred latency value, means for determining whether a backoff timer associated with the apparatus is running when the response message is received, and means for starting the backoff timer at the received deferred latency value based at least in part on the determination that the backoff timer is running.

According to various embodiments, the present disclosure describes a computer-readable storage medium having instructions stored thereon that, when executed on a computing device, cause the computing device to send a request message to a network controller; receiving a response message including the deferred latency value from the network controller; determining whether a back-off timer associated with the computing device is running when the response message is received; determining whether the request message includes a low priority indication; and starting the back-off timer at the received deferred latency value based at least in part on a determination that the back-off timer is running and that the request message includes a low priority indication.

Although certain embodiments have been illustrated and described herein for purposes of description, a wide variety of alternate and/or equivalent embodiments or implementations calculated to achieve the same purposes may be substituted for the embodiments shown and described without departing from the scope of the present disclosure. This application is intended to cover any adaptations or variations of the embodiments discussed herein. Therefore, it is manifestly intended that the embodiments described herein be limited only by the claims and the equivalents thereof.

Claims (15)

1. A user equipment, UE, comprising:

means for sending a non-access stratum, NAS, signaling message to a network controller, the NAS signaling message being a location update request, a tracking area update request, or a service request;

means for receiving, from the network controller, as an instruction, a deferred latency, EWT, value in response to the NAS signaling message to back off for a period of time corresponding to the EWT value;

means for determining whether the NAS signaling message has a low priority indication; and

means for determining whether to start a backoff timer at the EWT value based on whether the NAS signaling message has a low priority indication.

2. The UE of claim 1, wherein:

receiving the EWT value in a Radio Resource Control (RRC) reject message.

3. The UE of claim 1, wherein:

receiving the EWT value in a Radio Resource Control (RRC) connection release message.

4. The UE of claim 1, wherein:

receiving the EWT value from a lower layer.

5. The UE of any of claims 1-4, further comprising:

means for determining whether a back-off timer associated with the UE is running upon receipt of the EWT value; and

means for determining whether to start the backoff timer at the received EWT value based, at least in part, on a determination of whether the backoff timer is running.

6. The UE of any of claims 1-4, further comprising:

means for starting the backoff timer at the EWT value upon determining that the NAS signaling message does contain a low priority indication.

7. The UE of any of claims 1-4, further comprising:

means for ignoring the EWT value upon determining that the NAS signaling message does not contain a low priority indication.

8. The UE of any of claims 1-4, wherein the UE comprises a Machine Type Communication (MTC) device.

9. A user equipment, UE, comprising:

means for receiving a message from a network controller comprising an deferred latency EWT value;

means for determining whether a process is running, wherein the process is an attach process, a tracking area update process, a location update process, or a service request process;

means for determining whether to start a backoff timer at the EWT value based on the determination of whether a procedure is running; and

means for ignoring the EWT value based on a determination that the EWT value is received when the procedure is not in progress.

10. The UE of claim 9, wherein the EWT value is received from a lower layer or is received for a circuit switched domain.

11. The UE of claim 9 or 10, wherein the UE comprises a mobile station having a touch screen user interface.

12. A computer-implemented method performed in an apparatus in communication with a network controller, the method comprising:

sending a message to the network controller, the message being a location update request, a tracking area update request, or a service request;

receiving, from the network controller in response to the message, a deferred latency (EWT) value as an instruction to backoff for a period of time corresponding to the EWT value;

determining whether the message contains a low priority indication; and

determining whether to start a backoff timer at the received deferred latency value based on the determination of whether the message includes a low priority indication.

13. The method of claim 12, further comprising:

starting the backoff timer at the received deferred latency value based on a determination that the message contains a low priority indication.

14. The method of claim 12, further comprising:

ignoring the deferred latency value based on a determination that the message does not contain a low priority indication.

15. The method of any of claims 12-14, wherein the network controller is associated with a wireless communication network.