HK1227213A1 - Implementations of application specific access class barring skip functionality in a wireless network - Google Patents

Abstract

User Equipment (UE) may skip the Access Class Barring (ACB) procedure for specific services, such as MMTEL voice, MMTEL video, and SMS. In one implementation, NAS layer of a UE may: receive, from an upper layer relative to the NAS layer, a request for a particular service type that is being originated by the UE; receive an indication, from a Radio Resource Control (RRC) layer of the UE, that access to a cell, associated with the UE, is barred; and bypass the indication that access to the cell is barred, when the particular service type matches a predetermined set of service types. The bypassing may include: requesting that the RRC layer establish an RRC connection for the service request, and notifying the RRC layer that the request for the RRC connection corresponds to the particular service type.

Description

Implementation of application specific access class barring skip function in wireless networks

Related applications

This application claims the benefit of U.S. provisional patent application No.61/933,880 filed on 31/2014 and U.S. provisional patent application No.61/953,669 filed on 14/3/2014, both of which are incorporated herein by reference as if set forth herein.

Background

Due to the rapid growth in smartphone usage (even when operating normally), wireless network operators may face the problem of addressing high-load signaling and user traffic. When user-generated and/or application-generated network usage may be concentrated at a certain time and/or a certain area, this problem may result in congestion in the Radio Access Network (RAN) and/or the Core Network (CN), which becomes more pronounced in the event of disasters and/or public celebrations (e.g., new year events, sporting events, etc.).

In a network congestion situation, a network operator may desire to prioritize emergency access or high priority access over other access types, Radio Resource Control (RRC)/non-access stratum (NAS) messages over normal data, and/or voice services over non-voice services. One possible solution for prioritized traffic is based on configuring the User Equipment (UE) in idle mode to skip Access Class Barring (ACB) procedures for certain applications, such as multimedia telephony (MMTel) voice, MMTel video, and Short Message Service (SMS) (e.g., MMTel SMS, SMS under SG, and SMS under S102).

ACB implemented in the third generation partnership project (3GPP) standard is one such technique: by which network operators are able to manage network congestion, such as that resulting from emergency situations in which a large number of communication sessions (e.g., telephone calls) are attempted simultaneously in the network. ACB is one such solution: this solution may allow Public Safety (PS) personnel, such as emergency answering personnel, and general emergency calls to Public Safety Answering Points (PSAPs) to have priority over the network.

In an ACB, each UE may be assigned to belong to one of ten randomly assigned mobile populations (defined as Access Classes (ACs) 0 to 9). The access class of a particular UE may be stored by the UE. Further, the UE may be a member of one or more of the five dedicated classes (access classes 11 to 15). These five special categories may be assigned to particular high priority users as follows: level 15-Public Land Mobile Network (PLMN) personnel; level 14 — emergency services; class 13-utilities; level 12 — Security service; and level 11 — PLMN usage.

In an overload situation, for example, in an emergency situation where congestion is generated, the network operator may choose to use ACBs to reduce access to the network. The network operator may broadcast a message indicating which access classes are restricted. UEs that are not members of the allowed access class may block or otherwise disallow certain communications through the network. In some cases, e.g., non-emergency (normal) congestion situations, the network operator may use the ACB to control congestion, e.g., by setting access class restriction rates and/or restriction times. Furthermore, the ACB related restriction parameters may be configured independently for mobile originated data and mobile originated signaling attempts.

Drawings

Embodiments of the present invention will be readily understood by the following detailed description in conjunction with the accompanying drawings. For convenience of description, like reference numerals may denote like structural elements. In the drawings, embodiments of the invention are shown by way of example and not by way of limitation.

FIG. 1 is an illustration of an example environment in which systems and/or methods described herein may be implemented;

fig. 2 is a flowchart illustrating an example of a process for performing ACB skipping;

fig. 3 and 4 are diagrams illustrating operations related to ACB skipping for IP Multimedia (IMS) services;

fig. 5 and 6 are diagrams illustrating operations related to ACB skipping for SMS service;

7-12 are diagrams illustrating in more detail possible implementations for implementing ACB skipping;

FIG. 13 is a diagram illustrating an example timeline of communications associated with a sample communication session in which a normalized Stop (Stop) indication is used;

14-16 are diagrams illustrating different implementations related to operations for generating a stop and Start (Start) indication; and

FIG. 17 is an illustration of example components of a device.

Detailed Description

The following detailed description refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements. 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 in accordance with the present invention is defined by the appended claims and their equivalents.

The description herein relates to techniques by which a network may indicate whether a UE skips Access Class Barring (ACB) procedures in a wireless network, such as a Long Term Evolution (LTE) network or other network. The functions related to skipping ACBs may be referred to as "ACB skipping," "ACB skipping functions," "bypassing ACBs," or other terms where access to a cell is considered unrestricted. ACB skipping may be performed for specific functions, which may be, for example, MMTEL voice, MMTEL video, and SMS. A notification related to ACB skipping may be sent to the UE via a broadcast channel to reach the UE in idle mode.

In some cases, the network operator may desire priority emergency or high priority access over other access types, priority RRC/NAS messages over normal data, and/or priority voice services over other data. Consistent with aspects described herein, techniques will be described to implement prioritization of network traffic based on UE ignoring or skipping policy network ACB procedures (ACB skipping) for certain applications or services (i.e., on a per application/service basis).

One implementation described herein may include a User Equipment (UE) including processing circuitry to implement a non-access stratum (NAS) layer to: receiving, from an upper layer with respect to the NAS layer, a request for a transmission of a specific service type initiated from the UE; receiving, from a Radio Resource Control (RRC) layer of the UE, an indication that access to a cell associated with the UE is restricted; and bypassing the indication that access to the cell is restricted when the particular service type matches the set of predetermined service types. Bypassing can include requesting the RRC layer to establish an RRC connection for the service request and informing the RRC layer that the request to establish the RRC connection corresponds to the particular service type. The request for transmission may comprise an internet protocol multimedia (IMS) request or a Short Message Service (SMS) request.

The UE may also include processing circuitry to implement an RRC layer to: receiving an indication from the network relating to access class barring skipping; and establishing the RRC connection based on a request from the NAS layer when the state of access class barring skip indicates that the access class barring skip is active for the particular service type. The RRC layer may also limit establishment of RRC connections when the state of ACB skip indicates that the ACB skip is not active for a particular service type.

The set of predetermined service types may comprise at least one of: multimedia telephony (MMTel) video, MMTel voice, MMTel Short Message Service (SMS), and SMS under SG or SMS under S102 interface.

In addition, the indication from the network regarding the status of access class barring skip may comprise a system information block type 2(SIB2) message including one or more fields indicating the access class barring skip status for various services.

In another implementation, a method may include: receiving, by a UE from a network, an Access Class Barring (ACB) indication that a cell is barred due to congestion; receiving, by an RRC layer of the UE, from a network, an indication that one or more particular serving ACBs initiated by the UE should be bypassed; providing, from an application layer of the UE to a NAS layer of the UE, an identification of a service being initiated by the UE; receiving, by the RRC layer, a request to establish a radio connection for the service from the NAS layer; receiving, by the RRC layer, an identification of the service provided; and establishing, by the RRC layer and with the network, a radio connection for the service regardless of the indication of the ACB when the identification of the service received by the RRC layer matches one or more particular services associated with the indication that the ACB should be bypassed.

In another implementation, a UE may include: a non-transitory memory device storing a plurality of memory executable instructions; and a processor configured to execute processor-executable instructions. Executing the processor-executable instructions causes the processor to: receiving an ACB indication from the cellular network that the cell is restricted due to congestion; receiving, by an RRC layer of the UE, from a network, an indication that one or more particular serving ACBs initiated by the UE should be bypassed; providing, from an application layer of the UE to a NAS layer of the UE, an identification of a service being initiated by the UE; receiving, by the RRC layer, a request to establish a radio connection for the service from the NAS layer; receiving, by the RRC layer, an identification of the service provided; and establishing, by the RRC layer, a radio connection for the service with the network when the identification of the service received by the RRC layer matches one or more particular services associated with the indication that the ACB should be bypassed.

In another implementation, a UE may include: means for receiving an ACB indication from a cellular network that a cell is restricted due to congestion; means for receiving, by an RRC layer of the UE, from a network, an indication that one or more particular serving ACBs initiated by the UE should be bypassed; means for providing, from an application layer of the UE to a NAS layer of the UE, an identification of a service being initiated by the UE; means for receiving, by the RRC layer from the NAS layer, a request to establish a radio connection for the service; means for receiving, by the RRC layer, an identification of the service provided; and means for establishing, by the RRC layer, a radio connection with the network for the service when the identification of the service received by the RRC layer matches one or more particular services associated with the indication that the ACB should be bypassed.

FIG. 1 is an illustration of an example environment 100 in which systems and/or methods described herein may be implemented. As shown, environment 100 may include one or more User Equipment (UE)110 (referred to as a singular "UE 100" or a plural "plurality of UEs 110"), which UEs 110 may obtain network connectivity, e.g., over wireless network 120. Wireless network 120 may provide access to one or more external networks, each labeled as a Packet Data Network (PDN) 150. The wireless network may include a Radio Access Network (RAN)130 and a core network 140. In some implementations, the RAN130 may be associated with a network operator that controls or otherwise manages the core network 140. The core network 140 may include an Internet Protocol (IP) based network such as a System Architecture Evolution (SAE) core network or a General Packet Radio Service (GPRS) core network.

The UE110 may include portable computing and communication devices, such as Personal Digital Assistants (PDAs), smart phones, cellular phones, laptop computers connected to a cellular wireless network, tablet computers, and the like. UE110 may also include non-portable computing devices such as a desktop computer, consumer or commercial electronic device, or other device capable of wirelessly connecting to access network 130.

RAN130 may represent a 3GPP access network that includes one or more access technologies. Access network 130 may include a base station 132. In the context of an LTE-based access network, each base station 132 may be referred to as an evolved nodeb (enodeb) 132. The eNodeB 132 may provide a radio interface over which the eNodeB may communicate with the UE 110. The radio interface may comprise, for example, a radio interface implementing an evolved UMTS (universal mobile telecommunications system) terrestrial radio access network (E-UTRA) network. The enodebs 132 may communicate with each other using an X2 interface, and the enodebs 132 may communicate with devices associated with the core network 140 (e.g., the MME 134 and the SGW 142) using an S1 interface.

Core network 140 may include an IP-based network. In a 3GPP network architecture, the core network 140 may include an Evolved Packet Core (EPC). As shown, the core network 140 may include a Mobility Management Entity (MME)134, a Serving Gateway (SGW)142, and a packet data network gateway (PGW) 146. Although certain network devices are shown as being part of RAN130 and core network 140 in environment 100, the marking of a network device as being in the "RAN" or the "core network" of environment 100 may be any decision that does not affect the operation of wireless network 120.

MME 134 may include one or more computing and communication devices that perform operations to register UE110 with core network 140, establish bearer channels associated with sessions with UE110, handover UE110 from one eNodeB to another eNodeB, and/or perform other operations. MME 134 may generally handle control plane traffic. The SGW 142 may include one or more network devices that aggregate traffic received from one or more enodebs 132. The SGW 142 may generally handle user (data) plane traffic.

The PGW 146 may include one or more devices that serve as interconnection points between the core network 140 and external IP networks (e.g., the PDN 150 and/or operator IP services). PGW 146 may route packets to and from the access network and the external IP network. The SGW 142 may communicate with the PGW 146, for example, using S5 and/or S8 interfaces.

PDNs 150 may each comprise a packet-based network. PDN 150 may include an external network, such as a public network (e.g., the internet) or a proprietary network that provides services provided by an operator of core network 140 (e.g., IP Multimedia (IMS) -based services, transparent end-to-end packet-switched streaming services (PSS), or other services).

The number of devices and/or networks shown in fig. 1 is provided for explanatory purposes only. Indeed, additional devices and/or networks may be present; fewer devices and/or networks; different devices and/or networks; devices and/or networks arranged differently than shown in fig. 1. Alternatively or additionally, one or more devices of environment 100 may perform one or more of the functions described as being performed by other one or more devices of environment 100.

Fig. 2 is a flow diagram illustrating an example of a process 200 for performing ACB skipping. Process 200 may be performed, for example, by UE 110.

Process 200 may include receiving an indication that an ACB skip function is to be implemented for a particular application/service (block 210). For example, a particular application/service may include the services MMTEL voice, MMTEL video, and SMS. In other implementations, the UE210 may perform ACB skipping for other applications or services. The particular application for which ACB skipping is implemented may be indicated in a message (e.g., a broadcast or unicast message) sent by one or more devices in wireless network 120 and received by UE 110.

In one implementation, the message indicating that ACB skipping is to be implemented may be sent to the UE210 as part of a system information block type 2(SIB2) broadcast message, as specified in the 3GPP TS 36.331 standard. For example, the SIB2 message may include fields that indicate whether ACB skipping is to be implemented for MMTEL voice, MMTEL video, and SMS. One possible implementation of such a system information block type 2 message is shown in table 1. Table 2 includes field descriptions for the fields in table 1. In tables 1 and 2, underlining indicates the text that can supplement the existing 3GPP TS 36.331 standard to implement the message.

Referring back to fig. 2, process 200 may further include: when the ACB is active for a particular service, ACB skipping (possibly interacting with IMS, NAS, and RRC layers) is performed for the indicated application/service to ignore the ACB (block 220). For example, if ACB skipping is enabled for a certain service (e.g., MMTEL voice), the UE may implement ACB skipping by bypassing normal ACB checking when a NAS request for an RRC connection associated with MMTEL voice is identified in the RRC layer. The actual implementation details of ACB skipping may differ based on the UE's interaction with the higher network layers (i.e., NAS and IMS layers). With respect to IMS services, various aspects related to ACB skipping will be described below with reference to fig. 3, 4, and 7-10. With respect to SMS service, various aspects related to ACB skipping will be described below with reference to fig. 5, 6, 11, and 12.

For an actual implementation where ACB skips for IMS services, two main functions may need to be addressed: (1) the RRC layer may need to know the triggered services in the IMS layer; and (2) may need to handle NAS "congestion relief notifications" in a different way. NAS congestion mitigation notification refers to the following requirements in the NAS layer: when access to a cell is restricted due to ACB to a previous RRC connection establishment procedure (due to initiation of a service request or tracking area update procedure in NAS), RRC will inform NAS of the restriction condition and NAS cannot send a new request to establish RRC connection before RRC informs NAS of congestion situation mitigation (i.e. NAS cannot initiate a service request or tracking area update procedure). In this way, the upper layer may be notified of the failure to establish the RRC connection.

When a service is triggered through the IMS layer, the RRC layer may need to know which service is being triggered to implement ACB skipping for that service. In one implementation, the IMS layer may directly notify the RRC layer when a particular IMS service initiates a connection by communicating the IMS service type (e.g., voice, video, or SMS under IP) to the RRC layer. The notification from the IMS layer to the RRC layer may inform the RRC layer that one of the IMS services is about to start. The "RRC connection establishment" procedure may then be triggered and the RRC layer may implement ACB skipping (if configured with ACB skipping for this service). The notification from the IMS layer to the RRC layer may be sent via AT commands.

In another possible implementation of having the RRC layer know which service is being triggered to implement ACB skipping to that service, the IMS layer may notify the NAS layer (e.g., by conveying an indication of the service type to the NAS layer) when one of the relevant IMS services initiates a connection. The NAS layer may then forward this information to RRC when the NAS requests establishment of an RRC connection. The RRC layer may then implement ACB skipping as appropriate. The notification from the IMS layer to the NAS layer may be sent via AT commands.

As mentioned above, in addition to the RRC layer being aware of the ACB skip function, the NAS standard may require: when service is restricted due to ACB, the RRC layer informs the NAS layer of the restriction condition, and the NAS layer then refrains from initiating a new service request or tracking area update procedure until the RRC layer informs the NAS layer that ACB is no longer applicable (e.g., when the congestion situation is relieved). If the request is not processed, it may cause ACB skipping problems. The problem may be described by way of example. Consider the situation where a non-IMS application generates user plane data that then triggers the NAS service request procedure and the RRC connection establishment procedure. It is assumed that there is a congestion situation that causes the ACB to be activated. Activating an ACB may involve the RRC layer starting a timer (referred to as "timer T303" or "limit timer") that controls the limit time. According to existing NAS requirements, the NAS will not initiate another service request procedure until it is notified of restriction scenario mitigation (e.g., when a timer expires). Any IMS service initiated while the limit timer is running will not be able to trigger a NAS service request even if the ACB skip condition is configured for that service.

One technique for handling the requirement for the RRC layer to inform the NAS layer of the ACB restriction conditions during ACB skipping is to modify the NAS requirements to not initiate another service request for services affected by the ACB skipping function (e.g., MMTel video, MMTel voice, and SMS). In one implementation, these services may always trigger a NAS service request procedure and trigger a corresponding request for the RRC layer to establish an RRC connection. The RRC layer, knowing whether ACB skipping is configured, can then determine whether the RRC connection establishment procedure can continue.

Two additional options for handling the requirement for the RRC layer to inform the NAS layer of the ACB restriction conditions during ACB skipping will be described next with reference to fig. 3 and 4. In fig. 3 and 4, the operations indicated by underlined words may represent new functions and/or procedures associated with the IMS layer 310, the RRC layer 320, and the NAS layer 330.

Fig. 3 and 4 each show an IMS layer 310, an RRC layer 320, and a NAS layer 330. Each of the layers 310, 320, and 330 may represent logic related to the operation of IMS layer functionality, RRC layer functionality, and NAS layer functionality, respectively. The logic of the IMS layer 310, RRC layer 320, and NAS layer 330 may be implemented in the UE110 and/or within a network element such as eNodeB 132. In general, the IMS layer 310 may perform application level functions related to delivering Internet Protocol (IP) multimedia services. The RRC layer 320 may perform control functions related to the LTE air interface control plane. Examples of functions performed by the RRC layer 320 may include: receiving system information related to a NAS, receiving system information related to an Access Stratum (AS), paging, security functions, mobility functions, and quality of service (QoS) functions. NAS layer 330 may perform control functions related to the control plane between UE110 and MME 134. NAS layer 330 may represent the highest layer of the control plane at the radio interface and may implement protocols between UE110 and MME 134 that are not terminated in E-UTRAN.

As shown in fig. 3, the RRC layer 320 may receive an indication that an ACB skip is active (at 3.1, "an indication that an ACB skip is active for a particular service"). As previously described, the indication may be received as part of a system information block type 2 broadcast message that describes the particular service for which ACB skipping is enabled. When the IMS service triggers a service request procedure ("IMS service indicator" at 3.2), the IMS layer 310 may notify the RRC layer 320. The notification may include an indication of a service (e.g., MMTel video or MMTel voice). If ACB skipping is active for the service, the RRC layer 320 may stop the restriction timer (timer T303). Stopping the barring timer may allow NAS layer 330 to request establishment of an RRC connection in response to a request for an IMS service from a higher layer (e.g., IMS layer 310) when ACB skipping is active for the service (i.e., RRC layer 320 will not restrict the connection when the barring timer is stopped). The RRC layer 320 may also inform the NAS layer 330 that congestion relief is active (at 3.3, "congestion relief notification"). NAS layer 330 may receive a corresponding send request (via the user plane send request at 3.4) from the IMS layer. The NAS layer 330 may request establishment of an RRC connection from the RRC layer 320 (at 3.5, "request establishment of an RRC connection"). When ACB skipping is active for a particular IMS service, the RRC layer 320 may perform ACB skipping for that service (at 3.6, "skip ACB for a particular IMS service"). The RRC layer 320 may thus establish the requested RRC connection. Once ACB skipping is triggered, the RRC layer 320 may reset the barring timer (timer T303), and upon expiration or being stopped, the RRC layer 320 may provide congestion relief notifications to the NAS layer 330.

Fig. 4 is a diagram illustrating an operation related to another option for handling a requirement of the RRC layer to inform the NAS layer of the ACB condition. In contrast to fig. 3, where the NAS layer 330 does not know the service type, in the operation of fig. 4, the NAS layer 330 knows the service type. As shown in fig. 4, the RRC layer 320 may receive an indication that an ACB skip is active (at 4.1, "an indication that an ACB skip is active for a particular service"). As previously described, the indication may be received as part of a system information block type 2 message and may indicate the type of particular service(s) for which ACB skipping is implemented. The RRC layer 320 may inform the NAS layer 330 that congestion relief is active. The notification may also include an indication received as part of an ACB skip message that indicates to ignore ACBs of the particular service type(s) (i.e., to ignore restrictions on certain services) (at 4.2, "congestion relief notification and an indication to ignore restrictions conditions for a particular service"). In other words, a failure notification may be sent from the RRC layer 320 to the NAS layer 330 when there is possible service blocking due to the ACB, and a notification may also be sent indicating that the NAS layer 330 should ignore ACBs for a particular service type when ACB skipping is active.

NAS layer 330 may receive from IMS layer 310 a request sent from the IMS layer (at 4.3, a request sent via the user plane), which will trigger a service request. The IMS layer 310 may also provide an indication (at 4.4, "IMS service indicator") of the service (e.g., MMTel video or MMTel voice) to the NAS layer 330. When the service (provided at 4.4) matches a service corresponding to a notification indicating that NAS layer 330 should ignore ACBs for a particular service type (provided at 4.2), NAS layer 430 may ignore the ACBs for the particular service (at 4.5, "ignore restrictions for the particular service"). NAS layer 330 may send a request to RRC layer 320 to establish an RRC connection for the service request. The request may also include an indication of the service (at 4.6, "request to establish RRC connection, including service indication"). When ACB skipping is active for a particular IMS service, the RRC layer 320 may perform ACB skipping for the service by establishing the requested RRC connection (at 4.7, "skipping ACB for a particular IMS service").

In the implementations discussed above with reference to fig. 3 and 4, the IMS layer 310 informs the RRC layer 320 or the NAS layer 330 of the type of service being established. An indication of an IMS service may only be needed if ACB skipping is configured for that service. In one implementation, the RRC layer 320 may inform the IMS layer 310 when ACB skipping is active, and optionally, for services associated with active ACB skipping. The IMS layer 310 may send only a service indication to the RRC layer 320 (fig. 3) or the NAS layer 330 (fig. 4) only when needed (i.e., only when the ACB skip function is configured). This may allow minimizing signaling between layers within UE 110.

In one possible variation of the operation shown in fig. 4, the 4.2 communication may not include an indication of which particular services may ignore the restrictive congestion indication. In this case, at 4.5, the restrictions may always be ignored for services that support ACB skipping (e.g., all IMS and SMS services). Alternatively, the 4.2 communication may indicate "IMS only", "SMS only", or both "IMS and SMS". At 4.7 the RRC layer 320 may determine whether to request establishment of an RRC connection based on the indicated service type.

As discussed above, fig. 3 and 4 illustrate various aspects related to ACB skipping for IMS services. Various aspects related to ACB skipping for SMS (e.g., SMS over SG or S102 interface) services will be described next with reference to fig. 5 and 6. Generally, SMS services may be received directly in the NAS layer 330 and corresponding service type notifications may be sent from the NAS layer 330 to the RRC layer 320 without additional notifications. Similarly, the RRC 320 knows that ACB skipping may not be sufficient and may need to handle NAS congestion relief notifications.

Fig. 5 is a diagram illustrating an operation related to handling a requirement that the RRC layer notifies the NAS layer of a cell restriction condition (e.g., handling NAS congestion relief notification). As shown in fig. 5, the SMS layer 510 may communicate with the NAS layer 330. The SMS layer 510 may represent application layer logic related to the operation of SMS functions. The logic of SMS layer 510 may be implemented within UE110 and/or within network elements of wireless network 120. In the implementation of fig. 5, the NAS layer 330 may ignore the restriction indication (i.e., the restriction indication is not implemented at the NAS layer).

As shown in fig. 5, the RRC layer 320 may receive an indication that an ACB skip is active (at 5.1, "an indication that an ACB skip is active for a particular service"). As previously described, the indication may be received as part of a system information block type 2 message. When an SMS is to be sent, the SMS layer 510 may notify the NAS layer 320 (at 5.2, "SMS service"). NAS layer 330 may ignore any ACB condition of the SMS send request (at 5.3, "ignore ACB to SMS"). For example, the RRC layer 320 may refrain from notifying the NAS layer 330 of the congestion relief condition (e.g., refrain from indicating that the ACB is active). NAS layer 330 may trigger the service request procedure and send an indication of SMS service (at 5.4, "service request with SMS service indication") to RRC layer 320 and request triggering of RRC connection establishment. When ACB skipping is active for SMS originated calls, the RRC layer 320 may perform ACB skipping for SMS service (at 5.5, "skip ACB for SMS").

Fig. 6 is a diagram illustrating operations related to another option for handling a requirement for the RRC layer to notify the NAS layer of a cell restriction condition (e.g., handling NAS congestion relief notification). In the implementation of fig. 6, NAS layer 330 may override the ACB restriction condition for SMS service based on an indication from RRC layer 320.

As shown in fig. 6, the RRC layer 320 may receive an indication that an ACB skip is active (at 6.1, "an indication that an ACB skip is active for a particular service"). As previously described, the indication may be received as part of a system information block type 2 message and may indicate the type of particular service(s) for which ACB skipping is implemented, such as an SMS service (e.g., an SMS originating call). The RRC layer 320 may inform the NAS layer 330 that congestion relief is active. The notification may also include an indication to ignore the cell restriction conditions for the SMS service (at 6.2, "congestion relief notification and an indication to ignore the restriction conditions for the SMS"). When an SMS is to be sent, the SMS layer 510 may notify the NAS layer 320 (at 6.3, "SMS service"). When an indication to ignore the restriction conditions for SMS is previously received (e.g., an indication previously received at 6.2), NAS layer 330 may ignore any cell restriction conditions for SMS service (at 6.4, "ignore restriction conditions for SMS once indicated"). NAS layer 330 may trigger the service request procedure and send a request to establish an RRC connection and an indication of SMS service to RRC layer 320 (at 6.5, "service request with SMS service indication"). When ACB skipping is active for SMS originated calls, the RRC layer 320 may perform ACB skipping for SMS service (at 6.6, "skip ACB for SMS"). The operations of FIG. 6 may generally be related to the following: the RRC layer 320 informs the NAS layer 330 when a cell restriction condition (due to congestion) is not implemented for SMS. For simplicity, this may be performed when the request to previously establish the RRC connection is provided by NAS layer 330 and restricted by RRC layer 320. In this case, the RRC layer 320 may send an indication to the NAS layer 330 of a failure due to congestion (at 6.2), possibly including an indication of an SMS override restriction condition in future requests. When the SMS service is triggered in the future, the NAS layer 330 may start the service request procedure and ignore the restriction condition.

Further, a more detailed implementation of ACB skipping will be described below with reference to fig. 7-12. Additional implementations of fig. 7-12 may represent more detailed and/or lower level implementations relative to the descriptions of fig. 3-6. In fig. 7-12, the underlined text may indicate new functionality or modified functionality related to the prior art. Further, italicized text may indicate that communications may occur asynchronously at any time.

Fig. 7 is a diagram illustrating an implementation of ACB skipping based on the description of fig. 4. As shown in fig. 7, the functions implemented by UE110 may include: IMS component 710, User Plane (UP) component 720, Packet Data Convergence Protocol (PDCP) component 730, NASEPS mobility management (EMM) component 740, and RRC component 750. As further shown in fig. 7, the functions implemented by wireless network 120 (e.g., eNodeB 132) may include an RRC component 760. Each of components 710 and 750 may represent logic related to operation of different protocol layers at UE 110. Similarly, component 760 may represent logic related to the operation of the RRC layer in wireless network 120.

IMS components 710 may perform functions related to IMS services. The UP component 720RRC layer 320 may perform functions related to user plane traffic. The PDCP component 730 may perform functions related to the PDCP layer. These functions may include, for example, header compression and decompression of IP data, data transport (user plane or control plane), and maintenance of PDCP Sequence Numbers (SNs). NASEMM component 740 may perform functions related to EPS mobility management protocols for control of movement of UE110 with respect to wireless network 120. RRC component 750 may perform control functions related to operation of the LTE air interface control plane with respect to UE 110. RRC component 760 may perform control functions related to the operation of the LTE air interface control plane with respect to wireless network 120.

As shown in fig. 7, RRC component 750 may receive an indication from RRC component 760 that ACB skipping is active (which indication may include one or more messages or information elements). As previously described, this indication may be received as part of a SIB2 message (at 7.1, "SIB 2-ACB skip"). If RRC component 750 receives a request associated with an application to establish an RRC connection due to a service request procedure in NAS and access is denied (i.e., the application is not configured for ACB skipping and ACB restriction is active for the cell), RRC component 750 may inform NAS EMM component 740 that congestion mitigation is active (e.g., ACB is active) but still configure ACB skipping for one or more specific services (at 7.2, "congestion indication and indication to ignore restriction condition for specific MMTEL service").

When the IMS component 710 starts MMTel voice, MMTel video or MMTel SMS, the IMS component 710 may send a request (or indication) to the NASEMM component 740 (at 7.3, "IMS transaction request (MMTel service indicator)"). The request may include a notification for the service that should be started (e.g., the type of application/service, e.g., MMTel voice, MMTel video, or MMTel SMS). This request may be implemented via AT commands sent from IMS component 710 to NAS EMM component 740. In parallel, the IMS component 710 can transmit (via the UP component 720) a user plane packet (at 7.4, "transmit UP packet (SIP INVITE/SIP message)") to the NAS EMM component 740, wherein the user plane packet includes a Session Initiation Protocol (SIP) INVITE/SIP message.

In response to the request (communication 7.3), NAS EMM component 740 may determine whether an ACB is active for the service and whether an indication to perform ACB skipping for the service was previously received (at 7.5, "check ACB skip information (MMTEL)"). If ACB skipping is configured for this service and ACB skipping is configured for this particular IMS service, the NASEMM component 740 may bypass any previously received indication to restrict the service request.

NAS EMM component 740 may send a request to RRC component 750 to establish an RRC connection for the service. The request may also include an indication of the service (at 7.6, "establish RRC connection request (MMTEL service indicator)"). The indication of service may be generalized (e.g., UE-initiated ACB bypass) or more specific (i.e., on a per application or service basis, e.g., MMTel voice, as described above).

When ACB skipping is active for a particular service, RRC component 750 may perform ACB skipping for the service by establishing the requested RRC connection (at 7.7, "check ACB skip information (MMTEL, SMS)"). When ACB skipping is not active for a particular service type but ACB is active, RRC component 750 may ignore the request to establish an RRC connection as per normal ACB procedures.

Fig. 8 is a diagram illustrating another possible implementation of ACB skipping based on the description of fig. 4. As shown, RRC component 750 can receive an indication from RRC component 760 that ACB skipping is active (which indication can include one or more messages or information elements). As previously described, this indication may be received as part of a system information block type 2(SIB2) message (at 8.1, "SIB 2-ACB skip").

When the IMS component 710 starts MMTel voice, MMTel video or MMTel SMS, the IMS component 710 may send a request (or indication) to the NASEMM component 740 (at 8.2, "IMS transaction request (MMTel service indicator)"). The request may include a notification for the type of service that should be started (e.g., the type of application, e.g., MMTel voice, MMTel video, or MMTel SMS). This request may be implemented via AT commands sent from IMS component 710 to NAS EMM component 740. In parallel, the IMS component 710 can transmit (via the UP component 720) a user plane packet (at 8.3, "transmit UP packet (SIP INVITE/SIP message)") to the NAS EMM component 740, wherein the user plane packet includes a Session Initiation Protocol (SIP) INVITE/SIP message.

NAS EMM component 740 may receive an indication to restrict the service request ("congestion indication" at 8.4) (i.e., an indication that the ACB is active). In this implementation, the NAS EMM component 740 does not know whether ACB skipping is configured. Accordingly, the NASEMM component 740 may always bypass any previous indication it receives from the RRC component 750 to limit the service request for any of the following service types: MMTel voice, MMTel video, or MMTel SMS (at 8.5, "ACB is always bypassed for MMTel").

NAS EMM component 740 may send a request to RRC component 750 to establish an RRC connection (i.e., user plane radio resources) for the service. The request may also include an indication of the service (at 8.6, "establish RRC connection request (MMTEL service indicator)"). The indication of service may be generalized (e.g., UE-initiated ACB bypass) or more specific (i.e., on a per-application or service type basis, e.g., MMTel voice, as described above). For example, a field indicating "RRC establishment cause" may be set to indicate a service. Alternatively or additionally, a new or different call type may be implemented instead of "RRC establishment cause".

When ACB skipping is active for a particular service, RRC component 750 may perform ACB skipping for the service ("check ACB skip information (MMTEL, SMS)" at 8.7) and establish the requested connection. When ACB skipping is not active for a particular service but ACB is active, RRC component 750 may ignore the request to establish an RRC connection as per normal ACB procedures.

Fig. 9 is a diagram illustrating a possible implementation of ACB skipping based on the description of fig. 3. As shown, RRC component 750 can receive an indication from RRC component 760 that ACB skipping is active. As previously described, this indication may be received as part of a SIB2 message (at 9.1, "SIB 2-ACB skip").

When IMS component 710 starts MMTel voice, MMTel video, or MMTel SMS, IMS component 710 may send a request (or indication) (at 8.2, "IMS transaction request (MMTel service indicator)") to RRC component 750. The request may include a notification for the type of service that should be started. The request may be implemented via an AT command sent from IMS component 710 to RRC component 750. Further, the IMS component 710 can send a user plane packet to the UP component 720 (via the UP component 720), which the UP component 720 can send to the PDCP component 730 (at 9.3, "transport UP packet (SIP INVITE/SIP message)"), wherein the user plane packet includes a Session Initiation Protocol (SIP) INVITE/SIP MESSAGE.

When ACB skip is active for the service type indicated in the request for communication 9.2 ("check whether ACB skip (MMTEL, SMS) is implemented", at 9.4), RRC component 750 may inform NAS EMM component 740 that access is granted and that NAS EMM component 740 should bypass any previous indication to restrict the service request received from RRC component 750 ("access grant indication", at 9.5). Since the RRC component 750 does not inform the NAS EMM component 740 about the service (i.e. the NAS EMM component 740 is not aware of the service), a service request can be triggered for any application in the NAS EMM component 740 from this point on.

Sometimes, IMS signaling messages may be received at NAS EMM component 740 (at 9.6, "establish UP request"). In response, NAS EMM component 740 may initiate the service.

NAS EMM component 740 may trigger a service request and send a request to RRC component 750 to establish an RRC connection for the service ("establish RRC connection request (MMTEL/MMS)" at 9.7). RRC component 750, as a result of receiving the transaction request from IMS component 710 (at 9.2), may be aware of the type of service (e.g., MMTel voice, MMTel video, or MMTel SMS) associated with the RRC connection setup request received at 9.7. When ACB skipping is active for a particular service, RRC component 750 may perform ACB skipping for the service and establish the requested connection. When ACB skipping is not active for a particular service but ACB is active, RRC component 750 may ignore the request to establish an RRC connection as per normal ACB procedures.

Fig. 10 is a diagram illustrating a possible implementation of ACB skipping based on a combination of the descriptions of fig. 3 and 4. As shown, RRC component 750 can receive an indication from RRC component 760 that ACB skipping is active. As previously described, this indication may be received as part of a SIB2 message (at 10.1, "SIB 2-ACB skip").

If RRC component 750 receives an establish RRC connection request associated with a service to establish an RRC connection and access is denied (i.e., the application is not configured for ACB skipping and ACB restriction is active), RRC component 750 can inform NAS EMM component 740 that the service is restricted (e.g., ACB is active) but still configure ACB skipping for one or more specific services ("congestion indication, including information indicating ACB skipping for a specific service" at 10.2).

RRC component 750 may notify IMS component 710 to: ACB skipping is configured, and for which services (e.g., MMTel voice, MMTel video, or MMTel SMS) ACB skipping is configured ("ACB skip indication and specific service" at 10.3).

When the IMS component 710 starts MMTel voice, MMTel video or MMTel SMS, the IMS component 710 may send a request (at 10.4, "IMS transaction request (MMTel service indicator)") to the NASEMM component 740. The request may include a notification for the service that should be started (e.g., the type of application, e.g., MMTel voice, MMTel video, or MMTel SMS). Alternatively, in an implementation similar to that shown in fig. 9, the request may be sent to RRC component 750. Further, the IMS component 710 can send a user plane packet to the UP component 720 (via the UP component 720), which the UP component 720 can send to the PDCP component 730 (at 10.5, "transport UP packet (SIP INVITE/SIP message)"), wherein the user plane packet includes a Session Initiation Protocol (SIP) INVITE/SIP MESSAGE. Sometimes, IMS signaling messages may be received at NAS EMM component 740 (at 10.6, "establish UP request"). In response, NAS EMM component 740 may initiate the service.

In this implementation, the NAS EMM component 740 knows (due to communication 10.3) when ACB skipping is configured for a particular service. Accordingly, NAS EMM component 740 may bypass any previous indication it receives from RRC component 750 to limit the service request corresponding to a particular service ("detect ACB skip info (MMTEL)" at 10.7).

NAS EMM component 740 may send a request to RRC component 750 to establish an RRC connection for the service. The request may also include an indication of the service (at 10.8, "establish RRC connection request (MMTEL service indicator)"). The indication of service may be generalized (e.g., UE-initiated ACB bypass) or more specific (i.e., on a per-application or service type basis, e.g., MMTel voice, as described above).

When ACB skipping is active for a particular service type, RRC component 750 may perform ACB skipping for the service (at 10.9, "check whether ACB skipping (MMTEL, SMS) is implemented)" and establish the requested connection. When ACB skipping is not active for a particular service but ACB is active, RRC component 750 may ignore the request to establish an RRC connection as per normal ACB procedures.

Fig. 11 is a diagram illustrating a possible implementation of ACB skipping for SMS over SG or S102 interface based on the description of fig. 5. As shown in fig. 11, the functions implemented by UE110 may include: an SMS component 1110, a NAS component 1120, and an RRC component 1130. As further shown in fig. 11, the functions implemented by wireless network 120 (e.g., eNodeB 132) may include RRC component 1140. Each of components 1110 and 1130 may represent logic related to operation of different protocol layers at UE 110. Similarly, component 1140 may represent logic related to the operation of the RRC layer in wireless network 120.

The SMS component 1110 can perform functions related to SMS services. NAS component 1120 may perform control functions related to the control plane between UE110 and MME 134. RRC component 1130 may perform control functions related to the LTE air interface control plane at UE 110. Similarly, RRC component 1140 may perform control functions related to the LTE air interface control plane in wireless network 120.

As shown in fig. 11, RRC component 1130 may receive an indication from RRC component 1140 that ACB skipping is active. As previously described, this indication may be received as part of a SIB2 message (at 11.1, "SIB 2-ACB skip"). The SMS component 1110 may notify the NAS component 1120 when the SMS request is made ("SMS transaction request" at 11.2). The NAS component 1120 does not know whether ACB skipping is configured. In this implementation, NAS component 1120 may thus always bypass any previous indication received from RRC component 1130 to limit the service request (i.e., ACB) from the SMS service (at 11.3, "ignore cell restriction notification for SMS"). NAS component 1120 may forward the corresponding service request procedure and the indication of the SMS service to RRC component 1130 (at 11.4, "service request with SMS service indication") to establish the RRC connection. The indication of SMS service may be generalized (e.g., UE-initiated ACB bypass) or more specific (i.e., a specific service such as an SMS-initiated call, as described above). When ACB skipping is active for SMS service, RRC component 1130 may perform ACB skipping for the SMS service (at 11.5, "skip ACB for SMS").

Fig. 12 is a diagram illustrating a possible implementation of ACB skipping for SMS over SG or S102 interface based on the description of fig. 6. As previously described, the indication may be received as part of a SIB2 message (at 12.1, "SIB 2-ACB skip"). If the RRC component 1130 receives a request to establish an RRC connection due to a service request from the NAS component 1120 and access is denied for the request (e.g., ACB is active and service is not configured for ACB skip), the RRC component 1130 may notify the NAS component 1120 that the requested service is restricted and that ACB skip is active for SMS (at 12.2, "congestion indication (ACB restriction active) and indicate to ignore restriction condition for SMS").

The SMS component 1110 may notify the NAS component 1120 when the SMS request is made ("SMS transaction request" at 12.3). When an indication to ignore the restriction conditions for the SMS is previously received, the NAS component 1120 may ignore any ACB conditions for the SMS request (at 12.4, "ignore cell restriction notification for SMS based on previous indication"). NAS component 1120 may forward the corresponding service request procedure and indication of the SMS service and the request to establish the RRC connection to RRC component 1130 (at 12.5, "service request with SMS service indication"). The indication of SMS service may be generalized (e.g., UE-initiated ACB bypass) or more specific (i.e., a specific service such as SMS-initiated call, as described above). When ACB skipping is active for SMS service, RRC component 1130 may perform ACB skipping for the SMS service (at 12.6, "skip ACB for SMS").

As described above, in order for the RRC layer to know when to start implementing ACB skipping, the IMS layer may notify the NAS/RRC layer of the initiation of the IMS call before being sent SIP INVITE by the IMS layer (e.g., see fig. 7-10). At this time, the RRC layer may determine (when used) to implement ACB skipping in the above manner. The determination of when to implement ACB skipping may be referred to herein as a "Start" indication.

In addition to starting ACB skipping, it may also be important to Stop ACB skipping appropriately (referred to herein as a "Stop" indication). Two possible techniques for implementing the stop indication may include: (1) implementation-specific techniques in which determining when ACB skipping should no longer be implemented is performed based on a particular UE implementation; or (2) the stop indication is implemented as a standardized indication that is sent from the IMS layer to the NAS and/or RRC layers.

With respect to technique (1) (implementation-specific), UE110 may implement ACB skipping for a single RRC connection establishment attempt, alternatively or in addition, UE110 may implement ACB skipping for a certain period of time. In some implementations, the UE110 may determine when to stop performing ACB skipping (e.g., determine when an IMS call has completed) based on internal information exchange between layers and/or based on Deep Packet Inspection (DPI) of packets in the user plane.

With respect to technique (2) (normalization stop indication), in one implementation, the normalization stop indication may be sent by the IMS layer after the IMS layer receives the SIP200OK message in response to the SIP INVITE message. Alternatively or in addition, the IMS layer may inform the NAS layer and/or RRC layer that IMS services are ended, completed, or released by sending a stop indication. As a more specific example that may be applied to IMS voice and video calls, the IMS layer may send a stop indication after the IMS layer receives SIP200OK (at the UE) in response to SIP BYE or after the IMS layer successfully sends a SIP200OK in response to SIP BYE (for the case of a call release initiated by the remote end via SIP BYE). For IMS services such as SMS, the IMS message indicating service completion may be different.

The IMS layer may send a stop indication in case of an abnormal end of IMS service. The IMS layer may additionally send a stop indication, for example, when a failure occurs within the IMS layer or when a user aborts an IMS call setup attempt before he successfully establishes an IMS call. It may be important to inform the NAS layer and/or RRC layer when IMS services end, complete, or are released, since a radio link failure, RRC connection re-establishment failure, or RRC connection failure may occur during an IMS call. These failures may cause the RRC connection to be released and may trigger the NAS layer to perform a Tracking Area Update (TAU) procedure in an attempt to recover the NAS signaling connection and the user plane bearer.

Fig. 13 is an illustration showing an example timeline of communications associated with a sample communication session in which standardized start and stop indications are used (e.g., technique (2)). As shown, assume that UE110 enters a cell of wireless network 120 ("cell 1") and the IMS layer of UE110 initiates a service request ("start indication") (e.g., for MMTEL voice). As part of the service request, an SIP INVITE message may be sent ("SIP INVITE sent") and a connection request ("RRC connection request") made to the RRC layer. Since ACB skipping may be active for this cell ("ACB skipping in cell 1"), an RRC connection request may be established. In response to the SIP INVITE message, a SIP200OK response may be received by UE110 ("SIP 200OK received"). The call may be established ("call established"), and upon receipt of the SIP200OK message, the IMS layer may send a stop indication ("stop indication") to the RRC or NAS layer.

At some point, assume that UE110 changes the cell to a second cell ("cell 2"). Changing cells may result in a handover operation that may include a reconfiguration or reconnection of the RRC channel ("RRC connection reconfiguration"). In addition, it is assumed that a connection failure occurs. The failure may include a radio link failure, which may be detected by UE110 ("RLF detected"). UE110 may then attempt to reestablish the connection ("RRC connection reestablishment request"). Assume that the reestablishment attempt fails ("reestablishment failure") and UE110 enters idle mode ("idle mode"). At some point, the cell may be reselected ("cell reselection") and a tracking area update procedure may be performed by the NAS layer in an attempt to recover NAS signaling connections and user plane bearers ("tracking area update" and "cell 2" referenced a second time). ACB skipping may be active in cell 2 ("ACB skipping in cell 2"). UE110 may establish a new call ("call established") and the IMS layer of UE110 may send a stop indication ("stop indication") after the UE IMS layer receives a SIP200OK message ("SIP BYE sent" and "SIP 200OK received") in response to the SIP BYE message being sent.

14-16 are diagrams illustrating different implementations related to operations for generating stop and start indications. The operations of fig. 14-16 will be described with respect to communications between the IMS layer 310, RRC layer 320, and NAS layer 330. In fig. 14-16, the operations indicated by underlining may represent non-standard communications and/or procedures associated with the IMS layer 310, the RRC layer 320, and the NAS layer 330.

In the implementation of fig. 14, a start indication and a stop indication may be sent from the IMS layer 310 to the RRC layer 320. As shown in fig. 14, the RRC layer 320 may receive an indication that an ACB skip is active (at 14.1, "an indication that an ACB skip is active for a particular service"). As previously described, the indication may be received as part of a system information block type 2 message. The IMS layer 310 may notify the RRC layer 320 when the IMS service triggers a service request procedure (at 14.2, "IMS service indicator (start)"). The notification may include an indication of the service. The notification may be used as a start indicator. If ACB skipping is active for the service, the RRC layer 320 may stop the restriction timer (timer T303). The RRC layer 320 may also inform the NAS layer 330 that congestion relief is active (at 14.3, "congestion relief notification"). NAS layer 330 may receive a corresponding IMS send request (at 14.4, a service request via the user plane). The NAS layer 330 may request establishment of an RRC connection from the RRC layer 320 (at 14.5, "request establishment of an RRC connection"). When ACB skipping is active for a particular IMS service, the RRC layer 320 may perform ACB skipping for that service (at 14.6, "skip ACB for a particular IMS service"). Once ACB skipping is triggered, the RRC layer 320 may reset the restriction timer (timer T303). The IMS layer 310 may notify the RRC layer 320 that the IMS service is complete ("IMS service indicator (stop)" at 14.7). The notification may be used as a stop indicator. At this point, the RRC layer 320 may resume the function of ACB checking for future RRC connection establishment procedures.

In the implementation of fig. 15, start and stop indications may be sent from the IMS layer 310 to the NAS layer 330. The start indication and stop indication may be forwarded by NAS layer 330 to RRC layer 320, each requesting establishment of an RRC connection.

As shown in fig. 15, the RRC layer 320 may receive an indication that an ACB skip is active (at 15.1, "an indication that an ACB skip is active for a particular service"). As previously described, this indication may be received as part of the SIB2 message and may indicate the type of particular service(s) for which ACB skipping is implemented. The RRC layer 320 may inform the NAS layer 330 of the congestion condition. The notification may also include an indication to ignore ACBs for a particular service (i.e., to ignore restrictions for certain services) received as part of an ACB skip message (at 15.2, "congestion indication and indication to ignore restriction conditions for a particular service"). In other words, a failure notification may be sent from the RRC layer 320 to the NAS layer 330 when there is a possible service blockage due to the ACB, and a notification may also be sent indicating that the NAS layer 330 should ignore ACBs for a particular service type when ACB skipping is active. In some implementations, the congestion indication (at 15.2) may not be associated with a particular service list. In this case, NAS layer 330 may ignore the restriction conditions for any service that may be subject to ACB skipping.

NAS layer 330 may receive an IMS request from IMS layer 310 (at 15.3, "service request via user plane"). The IMS layer 310 may also provide an indication of the service type (at 15.4, "IMS service indicator (start)") to the NAS layer 330. An indication of the type of service may be used as a start indicator. In one implementation, the communication 15.3 may be through a BC/RABM (radio access bearer manager), and the communication 15.4 may be a direct communication (e.g., via AT commands) between the IMS layer 310 and the NAS layer 330. When the service (provided at 15.4) matches a service corresponding to a notification indicating that NAS layer 330 should ignore ACBs for a particular service (provided at 15.2), NAS layer 430 may ignore the ACBs for the particular service (at 15.5, "ignore restrictions for the particular service"). NAS layer 330 may send a request to RRC layer 320 to establish an RRC connection for the service request. The request may also include an indication of the service (at 15.6, "request to establish RRC connection, including service indication (start)"). When ACB skipping is active for a particular IMS service, the RRC layer 320 may perform ACB skipping for the service by establishing the requested RRC connection (at 15.7, "skipping ACB for a particular IMS service"). When the IMS service is completed, the IMS layer 310 can notify the NAS layer 330 (at 15.8, "NAS notified, IMS service indicator (stop)"), and the NAS layer 330 can notify the RRC layer 320 (at 15.9, "NAS notified RRC, IMS service indicator (stop)"). In this manner, the stop indication may be forwarded from the IMS layer 310 to the RRC layer 320.

In the implementation of fig. 16, the start indication may be sent from the IMS layer 310 to the NAS layer 330, and then from the NAS layer 330 to the RRC layer 320. A stop indication may be sent from the IMS layer 310 to the NAS layer 330. The stop indication is only needed at the NAS layer 330 (and not the RRC layer 320) because service requests can always be initiated by the NAS layer 330.

As shown in fig. 16, the RRC layer 320 may receive an indication that ACB skipping is active (at 16.1, "indication that ACB skipping is active"). As previously described, this indication may be received as part of the SIB2 message and may indicate the particular service(s) for which ACB skipping is implemented. The RRC layer 320 may inform the NAS layer 330 of the congestion condition. The notification may also include an indication to ignore ACBs for a particular service (i.e., to ignore restrictions for certain services) received as part of an ACB skip message (at 16.2, "congestion indication and indication to ignore restriction conditions for a particular service"). In other words, a failure notification may be sent from the RRC layer 320 to the NAS layer 330 when there is a possible service blockage due to the ACB, and a notification may also be sent indicating that the NAS layer 330 should ignore the ACB for a particular service when ACB skipping is active. In some implementations, the congestion indication (at 16.2) may not be associated with a particular service list. In this case, NAS layer 330 may ignore the restriction conditions for any service that may be subject to ACB skipping.

NAS layer 330 may receive an IMS request from IMS layer 310 (at 16.3, "service request via user plane"). The IMS layer 310 may also provide an indication of the service type (at 16.4, "IMS service indicator (start)") to the NAS layer 330. The indication of the service may be used as a start indicator. In one implementation, the communication 16.3 may be through a BC/RABM, and the communication 16.4 may be a direct communication (e.g., via AT commands) between the IMS layer 310 and the NAS layer 330. When the service (provided at 16.4) matches a service corresponding to a notification indicating that NAS layer 330 should ignore ACBs for a particular service (provided at 16.2), NAS layer 430 may ignore the ACBs for the particular service (at 16.5, "ignore restrictions for the particular service"). NAS layer 330 may send a request to RRC layer 320 to establish an RRC connection for the service request. The request may also include an indication of the service (at 16.6, "request to establish RRC connection, including service indication"). In this manner, IMS requests may each be forwarded by NAS layer 330 to RRC layer 320 to establish an RRC connection until an IMS service indicator (stop) is received by NAS layer 330 from IMS layer 310. When ACB skipping is active for a particular IMS service, the RRC layer 320 may perform ACB skipping for the service by establishing the requested RRC connection (at 16.7, "skipping ACB for a particular IMS service"). When the IMS service is complete, the IMS layer 310 may notify the NAS layer 330 (at 16.8, "NAS notified, IMS service indicator (stop)"). In this implementation, since the NAS layer 330 is responsible for initiating a request to the RRC to establish an RRC connection for IMS services, it is not necessary to transmit a stop indication to the RRC layer 320.

Fig. 17 is an illustration of example components of a device 1700. Some of the devices shown in fig. 1, 3-12, and 14-16 may include one or more devices 1700. Device 1700 may include a bus 1710, processor 1720, memory 1730, input components 1740, output components 1750, and communication interface 1760. In another implementation, device 1700 may include additional, fewer, different, or differently arranged components.

Bus 1710 may include one or more communication paths that allow communication among the components of device 1700. Processor 1720 may include a processing circuit, such as a processor, microprocessor, or processing logic that may interpret and execute instructions. Memory 1730 may include any type of dynamic storage device that may store information and instructions for execution by processor 1720, and/or any type of non-volatile storage device that may store information for use by processor 1720.

Input component 1740 may include mechanisms that permit an operator to input information to device 1700, such as a keyboard, keypad, buttons, switches, and the like. Output component 1750 may include mechanisms to output information to an operator, such as a display, a speaker, one or more Light Emitting Diodes (LEDs), and so forth.

Communication interface 1760 may include any transceiver-like mechanism that enables device 1700 to communicate with other devices and/or systems. For example, communication interface 1760 may include an ethernet interface, an optical interface, a coaxial interface, or the like. Communication interface 1760 may include a wireless communication device, e.g., an Infrared (IR) receiver, a bluetooth radio, a WiFi radio, a cellular radio, or the like. The wireless communication device may be coupled to an external device, such as a remote control, a wireless keyboard, a mobile phone, and so forth. In some embodiments, device 1700 may include more than one communication interface 1760. For example, device 1700 may include a fiber optic interface and an ethernet interface.

Device 1700 may perform some of the operations described above. Device 1700 may perform these operations in response to processor 1720 executing software instructions stored in a computer-readable medium (e.g., memory 1730). The computer readable mechanism may be defined as a non-transitory memory device. The memory devices may include space within a single physical memory device or space across multiple physical memory devices. The software instructions may be read into memory 1730 from another computer-readable medium or from another device. The software instructions stored in memory 1730 may cause processor 1720 to perform the processes described herein. Alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.

In the foregoing specification, various embodiments have been described with reference to the accompanying drawings. It will, however, be evident that various modifications and changes may be made thereto, and additional embodiments may be implemented, without departing from the broader scope of the invention as set forth in the claims that follow. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

For example, while a series of blocks has been described with regard to fig. 2, the order of the blocks may be modified in other implementations. Also, non-dependent blocks may be performed in parallel.

It should be apparent that the example aspects described above may be implemented in many different forms of software, firmware, and hardware in the implementations illustrated in the figures. The actual software code or specialized control hardware used to implement these aspects should not be construed as limiting. Thus, the operation and behavior of the aspects were described without reference to the specific software code — it being understood that software and control hardware may be designed to implement the aspects based on the description herein.

Moreover, certain portions of the invention may be implemented as "logic" that performs one or more functions. The logic may comprise hardware (e.g., an ASIC or FPGA) or a combination of hardware and software.

Even if specific combinations of features are recited in the claims and/or disclosed in the description, these combinations are not intended to limit the invention. Indeed, many of these features may be combined in ways not specifically recited in the claims and/or disclosed in the specification.

No element, act, or instruction used in the present application should be construed as critical or essential to the invention unless explicitly described as such. The use examples of the terms "and" as used herein do not necessarily exclude the following explanations: the phrase "and/or" is intended in this example. Similarly, use examples of the term "or" as used herein do not necessarily exclude the following explanations: the phrase "and/or" is intended in this example. In addition, as used herein, the articles "a" and "an" are intended to include one or more items and may be used interchangeably with the phrase "one or more". Where only one item is intended, the terms "a," "an," "only," or similar language are used. In addition, the phrase "based on" means "based at least in part on," unless otherwise specified.

Claims (25)

1. A User Equipment (UE) comprising processing circuitry to implement a non-access stratum (NAS) layer to:

receiving, from an upper layer with respect to the NAS layer, a transmission request for a specific service type initiated by the UE;

receiving, from a Radio Resource Control (RRC) layer of the UE, an indication that access to a cell associated with the UE is restricted;

bypassing the indication that access to the cell is restricted when the particular service type matches a set of predetermined service types, the bypassing comprising:

requesting the RRC layer to establish an RRC connection for the service request, an

Notifying the RRC layer that the request to establish the RRC connection corresponds to the particular service type.

2. The UE of claim 1, wherein the send request comprises an internet protocol multimedia (IMS) request or a Short Message Service (SMS) request.

3. The UE of claim 1, wherein the UE further comprises processing circuitry to implement the RRC layer to:

receiving an indication from the network regarding a status of access class barring skipping; and

establishing the RRC connection based on the request from the NAS layer when the state of access class barring skip indicates that access class barring skip is active for the particular service type.

4. The UE of claim 3, wherein the RRC layer is further to:

restricting establishment of the RRC connection when the ACB skipped state indicates that the ACB skip is not active for the particular service type.

5. The UE of claim 1, wherein the set of predetermined service types includes at least one of:

a multimedia telephony (MMTel) video,

the voice of the MMTel is presented,

MMTel Short Message Service (SMS), and

SMS over SG or S102 interface.

6. The UE of claim 1, wherein the send request is received from an Internet Protocol (IP) multimedia (IMS) layer of the UE.

7. The UE of claim 1, wherein the send request is received from a Short Message Service (SMS) layer.

8. The UE of claim 3, wherein the indication from the network regarding the status of access class barring skip comprises a System information Block type 2(SIB2) message including one or more fields indicating access class barring skip status for various services.

9. The UE of claim 1, wherein the notification is based on setting an RRC establishment cause or a call type.

10. The UE of claim 1, wherein the send request is transported from an Internet Protocol (IP) multimedia (IMS) layer to the NAS layer via an AT command.

11. The UE of claim 1, wherein the processing circuitry is further to implement the NAS layer to:

receiving an indication from an Internet Protocol (IP) multimedia (IMS) layer that the particular service is being stopped.

12. A method, comprising:

receiving, by a User Equipment (UE), from a network, an Access Class Barring (ACB) indication that a cell is barred due to congestion;

receiving, by a Radio Resource Control (RRC) layer of the UE, from the network, an indication that one or more particular serving ACBs initiated by the UE should be bypassed;

providing, from an application layer of the UE to a non-access stratum (NAS) layer of the UE, an identification of a service being initiated by the UE;

receiving, by the RRC layer, a request from the NAS layer to establish a radio connection for the service;

receiving, by the RRC layer, an identification of the service provided; and

establishing, by the RRC layer and with the network, a radio connection for the service regardless of the indication of the ACB when the identification of the service received by the RRC layer matches one or more particular services associated with the indication that the ACB should be bypassed.

13. The method of claim 12, wherein the service comprises a multimedia telephony (MMTel) video call, MMTel voice call, or MMTel SMS.

14. The method of claim 12, wherein the application layer comprises an Internet Protocol (IP) multimedia layer.

15. The method of claim 12, wherein the service comprises a Short Message Service (SMS) service through an SG or S102 interface, and the application layer comprises an SMS layer.

16. The method of claim 12, wherein the indication from the network that the ACB should be bypassed is received as a system information block type 2(SIB2) message, the SIB2 message including one or more fields indicating one or more particular services that should be bypassed.

17. The method of claim 12, wherein the providing of the identification of the service is performed via an AT command.

18. The method of claim 12, further comprising:

providing, from an Internet Protocol (IP) multimedia (IMS) layer to the NAS layer, an indication of when the service has ceased.

19. A User Equipment (UE), comprising:

a non-transitory memory device storing a plurality of processor-executable instructions; and

a processor configured to execute the processor-executable instructions, wherein executing the processor-executable instructions causes the processor to:

receiving, from a cellular network, an Access Class Barring (ACB) indication that a cell is barred due to congestion;

receiving, by a Radio Resource Control (RRC) layer of the UE, from the network, an indication that one or more particular serving ACBs initiated by the UE should be bypassed;

providing, from an application layer of the UE to a non-access stratum (NAS) layer of the UE, an identification of a service being initiated by the UE;

receiving, by the RRC layer, a request from the NAS layer to establish a radio connection for the service;

receiving, by the RRC layer, an identification of the service provided; and

establishing, by the RRC layer, a radio connection with the network for the service when the identification of the service received by the RRC layer matches one or more particular services associated with the indication that ACBs should be bypassed.

20. The UE of claim 19, wherein the service comprises a multimedia telephony (MMTel) video call, MMTel voice call, or MMTel SMS.

21. The UE of claim 20, wherein the application layer comprises an Internet Protocol (IP) multimedia layer.

22. The UE of claim 19, wherein the service comprises a Short Message Service (SMS) service over an SG or S102 interface, and the application layer comprises an SMS layer.

23. The UE of claim 22, wherein the indication from the network that ACBs should be bypassed is received as a system information block type 2(SIB2) message that includes one or more boolean value fields indicating one or more particular services that should be bypassed.

24. The UE of claim 19, wherein the providing of the identification of the service is performed via an AT command.

25. The UE of claim 19, wherein the plurality of processor-executable instructions, when executed by the processor, further cause the processor to:

providing, from an Internet Protocol (IP) multimedia (IMS) layer to the NAS layer, an indication of when the service has ceased.