US20150119015A1

US20150119015A1 - Application access class barring

Info

Publication number: US20150119015A1
Application number: US14/494,206
Authority: US
Inventors: Yi Gai; Jing Zhu; Rath Vannithamby
Original assignee: Individual
Current assignee: Intel Corp
Priority date: 2013-10-31
Filing date: 2014-09-23
Publication date: 2015-04-30
Also published as: EP3064012A1; US20160227580A1; EP3063992A4; EP3063882A4; EP3064013A4; US20160227496A1; EP3063992B8; CN105580417B; HUE041804T2; US10779297B2; KR20180036804A; CN105580477B; US10397935B2; EP3064016A1; HK1223764A1; EP3063882A1; US10251187B2; US20160255640A1; CN105557052B; EP3063882B1

Abstract

Technology for supporting application access class (AAC) barring is disclosed. An evolved node B (eNB) may communicate to a user equipment (UE) that the eNB has a capability to support application access class (AAC) barring. An AAC message may be generated that includes one or more AAC parameters related to the AAC barring. The AAC message may be sent from the eNB to the UE, wherein the UE is barred from loading one or more applications UE based on the one or more AAC parameters in the AAC message.

Description

RELATED APPLICATIONS

This application claims the benefit of and hereby incorporates by reference U.S. Provisional Patent Application Ser. No. 61/898,425, filed Oct. 31, 2013, with an attorney docket number P61993Z.

BACKGROUND

Wireless mobile communication technology uses various standards and protocols to transmit data between a node (e.g., a transmission station) and a wireless device (e.g., a mobile device). Some wireless devices communicate using orthogonal frequency-division multiple access (OFDMA) in a downlink (DL) transmission and single carrier frequency division multiple access (SC-FDMA) in an uplink (UL) transmission. Standards and protocols that use orthogonal frequency-division multiplexing (OFDM) for signal transmission include the third generation partnership project (3GPP) long term evolution (LTE), the Institute of Electrical and Electronics Engineers (IEEE) 802.16 standard (e.g., 802.16e, 802.16m), which is commonly known to industry groups as WiMAX (Worldwide interoperability for Microwave Access), and the IEEE 802.11 standard, which is commonly known to industry groups as WiFi.
In 3GPP radio access network (RAN) LTE systems, the node can be a combination of Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Node Bs (also commonly denoted as evolved Node Bs, enhanced Node Bs, eNodeBs, or eNBs) and Radio Network Controllers (RNCs), which communicates with the wireless device, known as a user equipment (UE). The downlink (DL) transmission can be a communication from the node (e.g., eNodeB) to the wireless device (e.g., UE), and the uplink (UL) transmission can be a communication from the wireless device to the node.

BRIEF DESCRIPTION OF THE DRAWINGS

Features and advantages of the disclosure will be apparent from the detailed description which follows, taken in conjunction with the accompanying drawings, which together illustrate, by way of example, features of the disclosure; and, wherein:

FIG. 1 illustrates a block diagram of an evolved node B (eNB) generating an application access class (AAC) message and communicating the AAC message to a user equipment (UE) in accordance with an example;

FIG. 2 illustrates abstract syntax notation (ASN.1) code representing a system information block type 2 (SIB2) message containing various application access class (AAC) parameters in accordance with an example;

FIG. 3 illustrates a block diagram of an evolved node B (eNB) communicating an application access class (AAC) message to a user equipment (UE) indicating that the UE is to implement AAC barring while in a radio resource control (RRC) connected mode in accordance with an example;

FIG. 4 depicts functionality of circuitry of an evolved node B (eNB) operable to support application access class (AAC) barring in accordance with an example;

FIG. 5 depicts functionality of circuitry of a user equipment (UE) operable to support application access class (AAC) barring in accordance with an example;

FIG. 6 depicts a flow chart of a method for supporting application access class (AAC) barring in accordance with an example; and

FIG. 7 illustrates a diagram of a wireless device (e.g., UE) in accordance with an example.

Reference will now be made to the exemplary embodiments illustrated, and specific language will be used herein to describe the same. It will nevertheless be understood that no limitation of the scope of the invention is thereby intended.

DETAILED DESCRIPTION

Before the present invention is disclosed and described, it is to be understood that this invention is not limited to the particular structures, process steps, or materials disclosed herein, but is extended to equivalents thereof as would be recognized by those ordinarily skilled in the relevant arts. It should also be understood that terminology employed herein is used for the purpose of describing particular examples only and is not intended to be limiting. The same reference numerals in different drawings represent the same element. Numbers provided in flow charts and processes are provided for clarity in illustrating steps and operations and do not necessarily indicate a particular order or sequence.

EXAMPLE EMBODIMENTS

An initial overview of technology embodiments is provided below and then specific technology embodiments are described in further detail later. This initial summary is intended to aid readers in understanding the technology more quickly but is not intended to identify key features or essential features of the technology nor is it intended to limit the scope of the claimed subject matter.
A technology is described for implementing application access class (AAC) barring for user equipments (UEs) in a network. AAC barring can refer to barring specific applications or categories of applications for a defined period of time at the UE. In one configuration, AAC barring can be included within an access class barring (ACB) mechanism. Alternatively, AAC barring can be a standalone procedure. An evolved node B (eNB) can determine whether to implement AAC barring, and if so, which applications are to be barred at the UE. Each application can be barred according to a probability (as described in greater detail below) and a barring time. The eNB can assign a higher priority to some types of applications (e.g., voice applications) over other types of information (e.g., music streaming). The eNB can generate an AAC message including various parameters relating to the applications that are barred at the UE. The eNB can communicate the AAC message to the UE, wherein the AAC message includes a plurality of AAC barring configurations in the AAC message. Each AAC barring configuration may correspond with a particular application. The UE, upon receiving the AAC message from the eNB, can select one AAC barring configuration from the AAC message that corresponds to an application being operated at the UE. The UE can perform a random access channel (RACH) procedure based on the selected AAC barring configuration in order to support the application being operated at the UE. In one example, the AAC barring configuration can indicate applications that are barred from accessing a network (i.e., applications that contribute to network congestion). In other words, the applications can be barred at the UE in accordance with the AAC barring configuration. In one configuration, the AAC message communicated from the eNB to the UE can include a one-bit indication that the UE is to obey AAC barring when the UE is in a radio resource control (RRC) connected mode.
The number of applications that are being downloaded, installed and operated on user equipments (UEs), such as mobile devices, tablet computers, laptop computers, etc., is continually growing at an increasing rate. These applications can include social networking applications, online shopping applications, news applications, educational applications, music applications, video streaming applications, and so on. Several standard developing organizations (SDOs), including 3GPP, have identified that the growing number of applications operating at the UEs are a major cause of network inefficiencies. These applications can (intentionally or unintentionally) cause congestion over a Radio Access Network (RAN) and Core Network (CN) owing to access for services.
When a disaster occurs (e.g., earthquake, tsunami), a large amount of traffic and signaling load can arrive at a network operator, since people are trying to dial 911, call their relatives/friends, send messages/emails, or perform video calls, to report their status and/or to ask for help. The network operator can have the ability to deal with the burst traffic, recognizing the traffic associated with emergent situation and providing service to support the general public. A similar problem can occur during social events (e.g., sport match, new-year event), for which a relatively large amount of traffic can be generated in a short period of time.
During network congestion, particularly during emergency situations, it can be desirable to restrict certain applications or categories of applications (e.g., social networking applications, video streaming applications) to access the wireless network in order to protect and/or free up valuable wireless network resources. In other words, certain applications can be restricted when a wireless network or channel condition of the wireless network exceeds a capacity threshold. In addition, certain applications or categories of applications (e.g., emergency response applications) can be given priority when the wireless network is congested when these emergency situations occur. The certain applications or categories of applications can be restricted as long as the restriction complies with regional/national or countrywide net neutrality regulations. As an example, after a severe earthquake in a geographical region, packet-based communication applications that confirm the safety of citizens (e.g. Disaster Message Board service, Disaster Voice Messaging service) when a natural disaster or particularly newsworthy event occurs can be given priority over video streaming applications during the emergency situation.
While the network is overloaded, it can be desirable for the network to restrict access attempts from some UEs. In 3GPP Technical Specification (TS) 22.011, the Access Class Barring (ACB) mechanism is defined to allow the network to control access attempts from UEs over the radio interface. Access Classes (AC) are defined ranging from 0 to 15, where 0 to 9 are allocated randomly to UEs, and stored in a subscriber identification module (SIM) or a universal subscriber identification module (USIM). Once the AC is randomly assigned to the UE, the AC is generally not modifiable. AC 10 is reserved for E911 calls. In addition to AC 0 to 9, UEs can be one or more out of 5 special classes: AC 11 is for public land mobile network (PLMN) use, AC 12 is for security services, AC 13 is for public utilities, AC 14 is for emergency services, and AC 15 is for PLMN staff.
The eNB may control access from the UEs through the broadcast of AC barring parameters in the SIB2 message. In other words, a plurality of UEs can receive the broadcasted SIB2 message from the eNB, and based on the SIB2 message, the access capabilities of the UEs can be controlled. For regular UEs with AC 0 to 9, their access is controlled by an AC barring factor parameter (ac-BarringFactor) and an AC barring time parameter (ac-BarringTime), where ac-Barring Factor is the probability that a UE passes the “persistent” test, i.e., if the random number generated by the UE is lower than this value, access for the UE is allowed. Otherwise the access is barred for the UE. In one example, ac-BarringTime is the mean access barring time value in seconds. For UEs with AC 10, their access is controlled by an AC barring for emergency parameter (ac-BarringForEmergency), which is a boolean value to indicate barring or not. For UEs with AC 11-15, their access is controlled by an AC barring for special AC parameter (ac-BarringForSpecialAC), which is a boolean vector (of size 5) to indicate barring or not for each AC type.
While ACB is used for prioritizing emergent/high priority UEs with AC 11-15, ACB does not currently differentiate application types. For example, the type of application, such as multimedia telephony service (MMTEL), circuit switched fallback (CSFB), and voice over long term evolution (VoLTE) is currently not distinguishable in ACB. Initial random accesses are performed indifferently, as long as they are from the UEs with AC 0-9. Assigning different priority levels to different applications running on the same device is currently not allowed. All of the applications running on that device are to follow the same category or access class that is associated with the device. In other words, the applications cannot be differentiated when the devices fall under the same access class or category. For example, if UE has MMTEL or Mobile originating CSFB or web browsing, it can experience the same delay in ACB procedure due to the same ac-Barring Factor. The current ACB parameters do not differentiate the applications, such as VoLTE from the normal access. Random access due to a UE-initiated VoLTE call cannot be prioritized.
Therefore, the existing ACB mechanism can be improved by introducing a novel Application Access Class (AAC) that differentiate UEs with AC 0-9, but are running different applications. AAC can allow for application-specific ACB configurations at the UE, so that random access channel (RACH) congestion can be handled more efficiently. In other words, application-level classifications can be provided for ACB. While access control (AC) is a device-level classification identifier, the AAC is an application-level classification identifier. The use of AAC can provide application-level prioritization for UEs with AC 0-9. In addition, the use of ACB can be extended to UEs that are in a radio resource control (RRC) connected mode (RRC_CONNECTED). ACB is currently only used for UEs that are in idle mode (RRC_IDLE). However, ACB can be extended to those UEs that are in RRC_CONNECTED in order to bar the random access of low priority UEs/applications, and thus prioritize the high priority UEs/applications.
FIG. 1 illustrates an exemplary block diagram of an evolved node B (eNB) 102 generating an application access class (AAC) message and communicating the AAC message to a user equipment (UE) 104. The AAC can be provided with access class barring (ACB), or alternatively, AAC can be provided as a standalone mechanism. The eNB 102 can determine AAC-type information, for example, via a media access control (MAC) layer at the eNB 102. The AAC-type information can include predefined AAC values associated with application types. The ability to have different application classes allows the eNB 102 to define which application belongs to which application class.
As non-limiting examples, the AAC value of “0” can be associated with multimedia telephony service (MMTEL), the AAC value of “1” can be associated with circuit switched fallback (CSFB), and the AAC value of “2” can be associated with voice over long term evolution (VoLTE). In general, a plurality of AAC values can be set for a plurality of applications, such as video applications, gaming applications, social networking applications, image sharing applications, etc. that can be operated at the UEs. In one example, an AAC value can be associated with a category of applications (e.g., video sharing applications as a whole), but the AAC value can alternatively be associated with a specific application (e.g., a specific image sharing application). In one example, the AAC values can be associated with applications that communicate with the network (as opposed to applications that simply run on the UE itself and do not connect with the Internet, thereby not increasing network congestion).
The eNB 102 can detect network congestion and, in response, limit the usage of certain applications at a plurality of UEs that are communicating within the network. For example, the eNB 102 can decide to limit the usage of certain applications when the network exceeds a capacity threshold. The eNB 102 can decide which applications are consuming the most bandwidth, which applications are to be given a higher priority, which applications are to be given a lower priority, etc. when determining which applications are to be limited for the UEs. In one example, the eNB 102 can be notified of the network congestion by other network elements, such as a mobility management entity (MME), a serving gateway (SGW), a packet data network gateway (PGW), etc.
In response to the network congestion, the eNB 102 can generate an AAC message for transmission to the UE 104. The AAC message can indicate the eNB's support of AAC. In addition, the AAC message can include a number of AAC parameters, including an AAC barring support parameter (aac-BarringSupport), an AAC barring type parameter (aac-BarringType), an AAC barring factor parameter (aac-Barring Factor), and an AAC barring time (aac-BarringTime) parameter. In other words, the AAC message can contain an AAC barring configuration for the UE 104. In one example, the AAC message can be included in a system information block type 2 (SIB2) message communicated from the eNB 102 to the UE 104.
The AAC barring support parameter can be a Boolean value indicating whether AAC barring is supported at the eNB 102 or not. For example, a Boolean value of “0” can indicate that AAC barring is not supported and a Boolean value of “1” can indicate that AAC is supported. The AAC barring type parameter can be an integer ranging from 0 to 15 indicating the AAC value. The AAC value can indicate an application or an application category that is barred at the UE. For example, the AAC value of “0” can be associated the MMTEL and the AAC value of “1” can be associated with CSFB. The AAC barring factor parameter can indicate a probability that a UE with an AAC value indicated in the AAC barring type parameter passes a “persistent” test. In other words, the UE can generate a random number “Rand” and the random number has to pass the “persistent” test in order for the application running on the UE to have access to the network. By setting the AAC barring factor (i.e., a threshold value) to a relatively low value, the probability of the UE having access to the application is reduced because the UE has to generate a “Rand” that is lower than the AAC barring factor in order for the application running on the UE to have access to the network. In other words, if the probability in the AAC barring factor is relatively high, the UE has a greater chance of being able to run the application, whereas if the probability in the AAC barring factor is relatively low, the UE has a reduced chance of being able to run the application. The AAC barring time parameter can indicate a mean access barring time value (in seconds) for a UE with an AAC value indicated in the AAC barring type parameter.
Multiple AACs can be applicable for the UE 104. For each AAC, different access barring parameters can be defined. In other words, different levels of priority or barring can be given for different applications. The eNB 102 can communicate various AAC barring parameters for multiple AAC types to the UE 104. The various AAC barring parameters can be included in an AAC message. In one example, the eNB 102 can broadcast the AAC message in a SIB2 message to the UEs, wherein the AAC message includes a plurality of AAC barring configurations.
As a non-limiting example, an AAC message that is communicated from the eNB 102 to the UE 104 can include a first AAC barring configuration that defines an AAC value of “0,” for which the application type is MMTEL, the AAC barring factor is p95 (i.e., indicating that the UE has a 95% chance or probability to pass the persistent test and be allowed access to MMTEL) and the AAC barring time is s4 (i.e., 4 seconds). The AAC message can include a second AAC barring configuration that defines an AAC value of “1,” for which the application type is CSFB, the AAC barring factor is p90 (i.e., indicating that the UE has a 90% chance or probability to pass the persistent test and be allowed access to CSFB) and the AAC barring time is s4 (i.e., 4 seconds). In addition, the AAC message can include a third AAC barring configuration that defines an AAC value of “2,” for which the application type is “Other”, the AAC barring factor is p20 (i.e., indicating that the UE has a 20% chance or probability to pass the persistent test and be allowed access to the “other” applications) and the AAC barring time is s4 (i.e., 16 seconds). In this example, MMTEL can have the relatively highest priority level with respect to the UE 104 and CSFB can have a second highest priority level with respect to the UE 104. On the other hand, the AAC value related to “Other” (e.g., video applications, social networking applications) results in a relatively low chance for the application to be run at the UE 104 and a relatively high barring time for running the application at the UE 104. The eNB 102 can communicate the AAC barring configuration containing the multiple AAC values of “0,” “1,” and “2” to the UE 104.
The UE 104 can receive the AAC barring configurations from the eNB 102. As discussed above, the AAC barring configurations can define barring parameters for one or more AACs. For example, the AAC barring configurations can define barring parameters for voice applications, text applications or data applications, respectively. The UE 104 can implement one or more of the AAC barring configurations received from the eNB 102. In other words, the UE 104 can operate applications in accordance with the AAC barring configuration. When the UE 104 attempts to access a channel for running these applications, the UE 104 can abide by the AAC barring configurations. As an example, a specific AAC barring configuration received at the UE 104 can define voice calls as having the AAC value of “1,” the AAC barring factor of 80%, and the AAC barring time of 5 seconds. Therefore, the UE 104 can attempt to perform voice calls with a success probability of approximately 80% and an average barring time of 5 seconds.
The UE 104 can perform a random access channel (RACH) procedure based on one of the AAC barring configurations when the type of application that is being operated at the UE 104 corresponds or matches with one of the AAC values in the AAC barring configurations. In other words, the UE 104 can select an AAC barring configuration in the AAC message that corresponds to a type of application that is operating at the UE, and perform RACH based on the selected AAC barring configuration in order to support a type of application operating at the UE. When the UE 104 performs RACH according to the AAC barring configuration, RACH congestion can be alleviated because not all applications are allowed to access the RACH. The UE 104 can perform the RACH in order to request an uplink allocation from the eNB 102. The UE 104 and the eNB 102 can exchange a plurality of messages when the RACH procedure is being performed. In one aspect, the application-specific access baring is for RACH channel prioritization, i.e., certain applications can be allowed a higher priority level for initiating the RACH as compared to other applications with a lower priority level.
Alternatively, the UE 104 can perform random access in a default manner when the type of application that is being operated at the UE 104 does not correspond or match with one of the AAC values in the AAC barring configurations. For example, the AAC barring configurations can define “0” for voice calls and “1” for video conferencing, respectively. The AAC barring configuration may not be applicable to a social networking operation that is being operated at the UE 104, and therefore, the UE 104 can perform the random access according to its default manner. In one example, voice calls can be assigned a higher priority during emergency situations as compared to other types of applications, such as video chat, gaming, etc.
In one example, the UE 104 can simultaneously operate two separate applications. The UE 104 may select one AAC barring configuration for one of the two applications based on the AAC values associated with each of the two applications. In one example, can select the AAC barring configuration having a lowest AAC barring factor among the two AAC barring configurations (that correspond with two separate applications). The UE can 104 perform RACH based on the selected AAC barring configuration. For example, a first application can have an AAC barring factor of 80% and a second application can have an AAC barring factor of 60%. The UE 104 can perform the RACH for the first application (which corresponds to the selected AAC barring configuration) with the AAC barring factor of 80% because the first application has a greater priority level or probability level out of the two applications.
FIG. 2 illustrates exemplary abstract syntax notation (ASN.1) code representing a system information block type 2 (SIB2) message containing various application access class (AAC) parameters. The SIB2 message can include ACB barring configuration parameters, such as an ACB barring factor, an ACB barring time and an ACB barring for special AC. In addition, the SIB2 message can include AAC barring configuration parameters, such as an AAC barring support (e.g., a Boolean value), an AAC barring time (e.g., an integer ranging from 0 to 15), an AAC barring factor (e.g., p00, p05, p10, p15, p20, p25, p30, p40, p50, p60, p70, p75, p80, p85, p90, p95), and an ACB barring time (e.g., s4, s8, s16, s32, s64, s128, s256, s512). In one configuration, the SIB2 message can include multiple AAC barring configuration. For example, the SIB2 message can include AAC barring parameters (e.g., AAC barring support, AAC barring type, AAC barring factor, AAC barring time) for each application class, e.g., MMTEL and CSFB. Therefore, each application class can be subject to varying barring factors and barring times. The SIB2 message containing the ASN.1 code can be communicated from an evolved node B (eNB) to a user equipment (UE).
FIG. 3 illustrates a block diagram of an evolved node B (eNB) 302 communicating an application access class (AAC) message to a user equipment (UE) 304 indicating that the UE 304 is to implement AAC barring while in a radio resource control (RRC) connected mode. For example, the eNB 302 can send a one-bit indication in a system information block type 2 (SIB2) message that is communicated to the UE 304. The one-bit indication can inform the UE 304 of the use of access class barring (ACB) when the UE 304 is in RRC connected mode. In one example, the AAC message can include an AC barring RRC connected parameter, which is a Boolean value indicating whether ACB is supported in RRC connected mode or not. For example, a Boolean value of “0” can indicate that ACB is not supported in RRC connected mode and a Boolean value of “1” can indicate that ACB is supported in RRC connected mode. When the AC barring RRC connected parameter is set to “enabled,” the UE 304 in RRC connected mode can perform ACB based on its access class (AC) or AAC during the random access procedure.
In one example, AAC barring can be applicable whether the UE 304 is in RRC connected mode or RRC idle mode. By extending ACB when the UE 304 is in RRC connected mode, the UE 304 that is already in RRC connected mode can be specified as being subject to the application access barring procedure. In one configuration, application class barring may not be applied to UEs that are already connected (i.e., when the AC barring RRC connected parameter is not set to “enabled”), and instead, the application class barring can be applied to the UEs that are not connected (i.e., in idle mode).
Another example provides functionality 400 of circuitry of an evolved node B (eNB) operable to support application access class (AAC) barring, as shown in the flow chart in FIG. 4. The functionality can be implemented as a method or the functionality can be executed as instructions on a machine, where the instructions are included on at least one computer readable medium or one non-transitory machine readable storage medium. The circuitry can be configured to communicate, to a user equipment (UE), that the eNB has a capability to support application access class (AAC) barring, as in block 410. The circuitry can be configured to generate an AAC message that includes one or more AAC parameters related to the AAC barring, as in block 420. The circuitry can be configured to send the AAC message to the UE, wherein the UE is barred from loading one or more applications based on the one or more AAC parameters in the AAC message, as in block 430.
In one example, the circuitry can be further configured to communicate the capability indicating that eNB supports the AAC barring in a system information block 2 (SIB2) message. In one example, the circuitry can be further configured to send the one or more AAC parameters in a system information block 2 (SIB2) message. In yet another example, the AAC parameters in the AAC message include at least one of: an AAC barring support parameter, an AAC barring type parameter, an AAC barring factor parameter, an AAC barring time parameter or an access class barring radio resource control (RRC) connected parameter. In addition, the AAC barring type parameter in the AAC message indicates an AAC value, the AAC value being an integer that represents an application type that is barred at the UE.
In one aspect, the application type indicated in the AAC value includes at least one of: a multimedia telephony service (MMTEL) application, a circuit switched fallback (CSFB), or a voice over long term evolution (VoLTE) application. In another aspect, the circuitry can be further configured to: determine the AAC value in a medium access control (MAC) layer of the eNB; and generate the AAC message to include the AAC value. In yet another aspect, the AAC message sent to the UE includes a one-bit message indicating that the UE is subject to AAC barring when the UE is in a radio resource control (RRC) connected mode.
Another example provides functionality 500 of circuitry of a user equipment (UE) operable to support application access class (AAC) barring, as shown in the flow chart in FIG. 5. The functionality can be implemented as a method or the functionality can be executed as instructions on a machine, where the instructions are included on at least one computer readable medium or one non-transitory machine readable storage medium. The circuitry can be configured to receive an AAC message from an evolved node B (eNB) that includes a plurality of application access class (AAC) barring configurations, as in block 510. The circuitry can be configured to select an AAC barring configuration in the AAC message that corresponds to a type of application that is operating at the UE, as in block 520. The circuitry can be configured to perform a random access channel (RACH) procedure based on the selected AAC barring configuration in order to support the type of application operating at the UE, as in block 530.
In one example, the AAC barring configuration for the UE indicates one or more applications that are barred from accessing a Third Generation Partnership Project (3GPP) Long Term Evolution (LTE) network. In another example, the circuitry can be further configured to perform the RACH procedure in accordance with the AAC barring configuration in order to reduce congestion at the RACH. In yet another example, the AAC message received from the eNB includes a capability at the eNB to support the AAC barring.
In one configuration, the AAC message received from the eNB is a system information block 2 (SIB2) message. In another configuration, the ACC barring configuration in the AAC message includes one or more AAC barring parameters, the AAC barring parameters including at least one of: an AAC barring support parameter, an AAC barring type parameter, an AAC barring factor parameter, an AAC barring time parameter or an access class barring radio resource control (RRC) connected parameter. In yet another configuration, the AAC barring type parameter in the AAC message indicates an AAC value, the AAC value being an integer that represents an application type that is barred at the UE.
In one aspect, the application type indicated in the AAC value includes at least one of: a multimedia telephony service (MMTEL) application, a circuit switched fallback (CSFB), or a voice over long term evolution (VoLTE) application. In another aspect, the circuitry can be further configured to: operate at least two applications simultaneously at the UE; select one AAC barring configuration for one of the two applications based on the AAC values associated with each of the two applications, the AAC values being included in the plurality of AAC barring configurations in the AAC message; and perform the RACH procedure based on the selected AAC barring configuration.
In one example, the AAC message received from the eNB includes a one-bit message indicating that the UE is subject to AAC barring when the UE is in a radio resource control (RRC) connected mode. In another example, the UE includes an antenna, a touch sensitive display screen, a speaker, a microphone, a graphics processor, an application processor, internal memory, or a non-volatile memory port.
Another example provides a method 600 for supporting application access class (AAC) barring, as shown in the flow chart in FIG. 6. The method can be executed as instructions on a machine, where the instructions are included on at least one computer readable medium or one non-transitory machine readable storage medium. The method can include the operation of communicating, from an evolved node B (eNB) to a user equipment (UE), that the eNB has a capability to support application access class (AAC) barring, as in block 610. The method can include the operation of generating an AAC message that includes one or more AAC parameters related to the AAC barring, as in block 620. The method can include the operation of sending the AAC message, from the eNB to the UE, wherein the UE is barred from loading one or more applications UE based on the one or more AAC parameters in the AAC message, as in block 630.
In one example, the method further comprises the operation of communicating the capability indicating that eNB supports the AAC barring and the AAC message in a system information block 2 (SIB2) message. In another example, the AAC parameters in the AAC message include at least one of: an AAC barring support parameter, an AAC barring type parameter, an AAC barring factor parameter, an AAC barring time parameter or an access class barring radio resource control (RRC) connected parameter.
In configuration, the method further comprises the operations of determining the AAC value in a medium access control (MAC) layer of the eNB; and generating the AAC message to include the AAC value. In another configuration, the method further comprises the operation of sending a one-bit message to the UE indicating that the UE is subject to AAC barring when the UE is in a radio resource control (RRC) connected mode, the one-bit message being included in the AAC message.
FIG. 7 provides an example illustration of the wireless device, such as a user equipment (UE), a mobile station (MS), a mobile wireless device, a mobile communication device, a tablet, a handset, or other type of wireless device. The wireless device can include one or more antennas configured to communicate with a node or transmission station, such as a base station (BS), an evolved Node B (eNB), a baseband unit (BBU), a remote radio head (RRH), a remote radio equipment (RRE), a relay station (RS), a radio equipment (RE), a remote radio unit (RRU), a central processing module (CPM), or other type of wireless wide area network (WWAN) access point. The wireless device can be configured to communicate using at least one wireless communication standard including 3GPP LTE, WiMAX, High Speed Packet Access (HSPA), Bluetooth, and WiFi. The wireless device can communicate using separate antennas for each wireless communication standard or shared antennas for multiple wireless communication standards. The wireless device can communicate in a wireless local area network (WLAN), a wireless personal area network (WPAN), and/or a WWAN.
FIG. 7 also provides an illustration of a microphone and one or more speakers that can be used for audio input and output from the wireless device. The display screen may be a liquid crystal display (LCD) screen, or other type of display screen such as an organic light emitting diode (OLED) display. The display screen can be configured as a touch screen. The touch screen may use capacitive, resistive, or another type of touch screen technology. An application processor and a graphics processor can be coupled to internal memory to provide processing and display capabilities. A non-volatile memory port can also be used to provide data input/output options to a user. The non-volatile memory port may also be used to expand the memory capabilities of the wireless device. A keyboard may be integrated with the wireless device or wirelessly connected to the wireless device to provide additional user input. A virtual keyboard may also be provided using the touch screen.
Various techniques, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, compact disc-read-only memory (CD-ROMs), hard drives, non-transitory computer readable storage medium, or any other machine-readable storage medium wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the various techniques. Circuitry can include hardware, firmware, program code, executable code, computer instructions, and/or software. A non-transitory computer readable storage medium can be a computer readable storage medium that does not include signal. In the case of program code execution on programmable computers, the computing device may include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. The volatile and non-volatile memory and/or storage elements may be a random-access memory (RAM), erasable programmable read only memory (EPROM), flash drive, optical drive, magnetic hard drive, solid state drive, or other medium for storing electronic data. The node and wireless device may also include a transceiver module (i.e., transceiver), a counter module (i.e., counter), a processing module (i.e., processor), and/or a clock module (i.e., clock) or timer module (i.e., timer). One or more programs that may implement or utilize the various techniques described herein may use an application programming interface (API), reusable controls, and the like. Such programs may be implemented in a high level procedural or object oriented programming language to communicate with a computer system. However, the program(s) may be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language, and combined with hardware implementations.
It should be understood that many of the functional units described in this specification have been labeled as modules, in order to more particularly emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom very-large-scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like.
Modules may also be implemented in software for execution by various types of processors. An identified module of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions, which may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified module need not be physically located together, but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the module and achieve the stated purpose for the module.
Indeed, a module of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within modules, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network. The modules may be passive or active, including agents operable to perform desired functions.
Reference throughout this specification to “an example” or “exemplary” means that a particular feature, structure, or characteristic described in connection with the example is included in at least one embodiment of the present invention. Thus, appearances of the phrases “in an example” or the word “exemplary” in various places throughout this specification are not necessarily all referring to the same embodiment.
As used herein, a plurality of items, structural elements, compositional elements, and/or materials may be presented in a common list for convenience. However, these lists should be construed as though each member of the list is individually identified as a separate and unique member. Thus, no individual member of such list should be construed as a de facto equivalent of any other member of the same list solely based on their presentation in a common group without indications to the contrary. In addition, various embodiments and example of the present invention may be referred to herein along with alternatives for the various components thereof. It is understood that such embodiments, examples, and alternatives are not to be construed as defacto equivalents of one another, but are to be considered as separate and autonomous representations of the present invention.
Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided, such as examples of layouts, distances, network examples, etc., to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that the invention can be practiced without one or more of the specific details, or with other methods, components, layouts, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention.
While the forgoing examples are illustrative of the principles of the present invention in one or more particular applications, it will be apparent to those of ordinary skill in the art that numerous modifications in form, usage and details of implementation can be made without the exercise of inventive faculty, and without departing from the principles and concepts of the invention. Accordingly, it is not intended that the invention be limited, except as by the claims set forth below.

Claims

What is claimed is:

1. An evolved node B (eNB) operable to support application access class (AAC) barring, the eNB having circuitry configured to:

communicate, to a user equipment (UE), that the eNB has a capability to support application access class (AAC) barring;

generate an AAC message that includes one or more AAC parameters related to the AAC barring; and

send the AAC message to the UE, wherein the UE is barred from loading one or more applications based on the one or more AAC parameters in the AAC message.

2. The circuitry of claim 1, further configured to communicate the capability indicating that eNB supports the AAC barring in a system information block 2 (SIB2) message.

3. The circuitry of claim 1, further configured to send the one or more AAC parameters in a system information block 2 (SIB2) message.

4. The circuitry of claim 1, wherein the AAC parameters in the AAC message include at least one of: an AAC barring support parameter, an AAC barring type parameter, an AAC barring factor parameter, an AAC barring time parameter or an access class barring radio resource control (RRC) connected parameter.

5. The circuitry of claim 4, wherein the AAC barring type parameter in the AAC message indicates an AAC value, the AAC value being an integer that represents an application type that is barred at the UE.

6. The circuitry of claim 5, wherein the application type indicated in the AAC value includes at least one of: a multimedia telephony service (MMTEL) application, a circuit switched fallback (CSFB), or a voice over long term evolution (VoLTE) application.

7. The circuitry of claim 1, further configured to:

determine the AAC value in a medium access control (MAC) layer of the eNB; and

generate the AAC message to include the AAC value.

8. The circuitry of claim 1, wherein the AAC message sent to the UE includes a one-bit message indicating that the UE is subject to AAC barring when the UE is in a radio resource control (RRC) connected mode.

9. A user equipment (UE) operable to support application access class (AAC) barring, the UE having circuitry configured to:

receive an AAC message from an evolved node B (eNB) that includes a plurality of application access class (AAC) barring configurations;

select an AAC barring configuration in the AAC message that corresponds to a type of application that is operating at the UE;

perform a random access channel (RACH) procedure based on the selected AAC barring configuration in order to support the type of application operating at the UE.

10. The circuitry of claim 9, wherein the AAC barring configuration for the UE indicates one or more applications that are barred from accessing a Third Generation Partnership Project (3GPP) Long Term Evolution (LTE) network.

11. The circuitry of claim 9, further configured to perform the RACH procedure in accordance with the AAC barring configuration in order to reduce congestion at the RACH.

12. The circuitry of claim 9, wherein the AAC message received from the eNB includes a capability at the eNB to support the AAC barring.

13. The circuitry of claim 9, wherein the AAC message received from the eNB is a system information block 2 (SIB2) message.

14. The circuitry of claim 9, wherein the ACC barring configuration in the AAC message includes one or more AAC barring parameters, the AAC barring parameters including at least one of: an AAC barring support parameter, an AAC barring type parameter, an AAC barring factor parameter, an AAC barring time parameter or an access class barring radio resource control (RRC) connected parameter.

15. The circuitry of claim 14, wherein the AAC barring type parameter in the AAC message indicates an AAC value, the AAC value being an integer that represents an application type that is barred at the UE.

16. The circuitry of claim 15, wherein the application type indicated in the AAC value includes at least one of: a multimedia telephony service (MMTEL) application, a circuit switched fallback (CSFB), or a voice over long term evolution (VoLTE) application.

17. The circuitry of claim 15, further configured to:

operate at least two applications simultaneously at the UE; and

select one AAC barring configuration for one of the two applications based on the AAC values associated with each of the two applications, the AAC values being included in the plurality of AAC barring configurations in the AAC message; and

perform the RACH procedure based on the selected AAC barring configuration.

18. The circuitry of claim 9, wherein the AAC message received from the eNB includes a one-bit message indicating that the UE is subject to AAC barring when the UE is in a radio resource control (RRC) connected mode.

19. The circuitry of claim 9, wherein the UE includes an antenna, a touch sensitive display screen, a speaker, a microphone, a graphics processor, an application processor, internal memory, or a non-volatile memory port.

20. A method for supporting application access class (AAC) barring, the eNB having circuitry configured to:

communicating, from an evolved node B (eNB) to a user equipment (UE), that the eNB has a capability to support application access class (AAC) barring;

generating an AAC message that includes one or more AAC parameters related to the AAC barring; and

sending the AAC message, from the eNB to the UE, wherein the UE is barred from loading one or more applications UE based on the one or more AAC parameters in the AAC message.

21. The method of claim 20, further comprising communicating the capability indicating that eNB supports the AAC barring and the AAC message in a system information block 2 (SIB2) message.

22. The method of claim 20, wherein the AAC parameters in the AAC message include at least one of: an AAC barring support parameter, an AAC barring type parameter, an AAC barring factor parameter, an AAC barring time parameter or an access class barring radio resource control (RRC) connected parameter.

23. The method of claim 20, further comprising:

determining the AAC value in a medium access control (MAC) layer of the eNB; and

generating the AAC message to include the AAC value.

24. The method of claim 20, further comprising sending a one-bit message to the UE indicating that the UE is subject to AAC barring when the UE is in a radio resource control (RRC) connected mode, the one-bit message being included in the AAC message.