PRIORITY CLAIM

[0001] This application claims the benefit of priority to U.S. Provisional Patent Application Serial No. 62/106,431 filed on Jan 22, 2015, and entitled "METHODS FOR APPLICATION SPECIFIC CONGESTION CONTROL FOR DATA COMMUNICATIONS," which is incorporated herein by reference in its entirety.

TECHNICAL FIELD

[0002] Embodiments pertain to systems, methods, and component devices for wireless communications, and particularly to Application specific Congestion control for Data Communication (ACDC) for long term evolution (LTE), LTE- advanced, and other similar wireless communication systems.

BACKGROUND

[0003] LTE and LTE-advanced are standards for wireless communication of high-speed data for user equipment (UE) such as mobile telephones. As usage of wireless data networks increase, efficient use of network resources, particularly when a network is at or near its capacity limits, may call for managed usage of the resources. In some communication systems, congestion control may be implemented to manage system operation and to regulate usage of a data network by various devices. Unlike voice communications, where continuous network access is needed to maintain a voice communication link, data communications, in some situations, do not require the same level of continuous network usage. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] FIG. 1 is a block diagram of a system including an evolved node B (eNB) and user equipment (UE) that may operate according to some embodiments described herein.

[0005] FIG. 2 is a block diagram illustrating additional details of a UE in communication with an eNB that may operate according to some embodiments described herein.

[0006] FIG. 3 is a block diagram illustrating additional details of a UE in communication with an eNB that may operate according to some embodiments described herein.

[0007] FIG. 4 describes a method for application specific congestion control, according to some embodiments described herein.

[0008] FIG. 5 is a block diagram illustrating additional details of a UE in communication with an eNB that may operate according to some embodiments described herein.

[0009] FIG. 6 describes a method for application specific congestion control, according to some embodiments described herein.

[0010] FIG. 7 illustrates aspects of a computing machine, according to some example embodiments.

[0011] FIG. 8 illustrates aspects of a UE, in accordance with some example embodiments.

[0012] FIG. 9 is a block diagram illustrating an example computer system machine which may be used in association with various embodiments described herein.

[0013] FIG. 10 illustrates aspects of a UE, in accordance with some example embodiments. DETAILED DESCRIPTION

[0014] Embodiments relate to systems, devices, apparatus, assemblies, methods, and computer readable media to enhance wireless communications, and particularly to communication systems that operate with application specific congestion control for data communications. The following description and the drawings illustrate specific embodiments to enable those skilled in the art to practice them. Other embodiments can incorporate structural, logical, electrical, process, and other changes. Portions and features of some embodiments can be included in, or substituted for, those of other embodiments, and are intended to cover all available equivalents of the elements described.

[0015] FIG. 1 illustrates a wireless network 100, in accordance with some embodiments. The wireless network 100 includes a UE 101 and an eNB 150 connected via one or more channels 180, 185 across an air interface 190. UE 101 and eNB 150 communicate using a system that supports ACDC for managing the access of UE 101 to a network via eNB 150.

[0016] In wireless network 100, the UE 101 and any other UE in the system may be, for example, laptop computers, smartphones, tablet computers, printers, machine-type devices such as smart meters or specialized devices for healthcare monitoring, remote security surveillance, an intelligent transportation system, or any other wireless devices with or without a user interface. The eNB 150 provides the UE 101 network connectivity to a broader network (not shown). This UE 101 connectivity is provided via the air interface 190 in an eNB service area provided by the eNB 150. In some embodiments, such a broader network may be a wide area network operated by a cellular network provider, or may be the Internet. Each eNB service area associated with the eNB 150 is supported by antennas integrated with the eNB 150. The service areas are divided into a number of sectors associated with certain antennas. Such sectors may be physically associated with fixed antennas or may be assigned to a physical area with tunable antennas or antenna settings adjustable in a beamforming process used to direct a signal to a particular sector. One embodiment of the eNB 150, for example, includes three sectors each covering a 120 degree area with an array of antennas directed to each sector to provide 360 degree coverage around the eNB 150. [0017] The UE 101 includes control circuitry 105 coupled with transmit circuitry 1 10 and receive circuitry 115. The transmit circuitry 110 and receive circuitry 1 15 may each be coupled with one or more antennas. The control circuitry 105 may be adapted to perform operations associated with wireless communications using congestion control. Control circuitry 110 may include various combinations of application specific circuitry and baseband circuitry. The transmit circuitry 1 10 and receive circuitry 115 may be adapted to transmit and receive data, respectively, and may include radio frequency (RF) circuitry or front end module (FEM) circuitry. In various embodiments, aspects of transmit circuitry 1 10, receive circuitry 115, and control circuitry 105 may be integrated in various ways to implement the circuitry described in FIG. 10 below. The control circuitry 105 may be adapted or configured to perform various operations such as those described elsewhere in this disclosure related to a UE. The transmit circuitry 110 may transmit a plurality of multiplexed uplink physical channels. The plurality of uplink physical channels may be multiplexed according to time division multiplexing (TDM) or frequency division multiplexing (FDM) along with carrier aggregation. The transmit circuitry 110 may be configured to receive block data from the control circuitry 105 for transmission across the air interface 190. Similarly, the receive circuitry 1 15 may receive a plurality of multiplexed downlink physical channels from the air interface 190 and relay the physical channels to the control circuitry 105. The plurality of downlink physical channels may be multiplexed according to TDM or FDM along with carrier aggregation. The transmit circuitry 110 and the receive circuitry 115 may transmit and receive both control data and content data (e.g. messages, images, video, etc.) structured within data blocks that are carried by the physical channels.

[0018] FIG. 1 also illustrates the eNB 150, in accordance with various embodiments. The eNB 150 circuitry may include control circuitry 155 coupled with transmit circuitry 160 and receive circuitry 165. The transmit circuitry 160 and receive circuitry 165 may each be coupled with one or more antennas that may be used to enable communications via the air interface 190.

[0019] The control circuitry 155 may be adapted to perform operations for managing channels and congestion control communications used with various UEs, including communication of open mobile alliance (OMA) management object (OMA-MO) describing application categories as detailed further below. The transmit circuitry 160 and receive circuitry 165 may be adapted to transmit and receive data, respectively, to any UE connected to eNB 150. The transmit circuitry 160 may transmit downlink physical channels comprised of a plurality of downlink subframes. The receive circuitry 165 may receive a plurality of uplink physical channels from various UEs including UE 101.

[0020] FIG. 2 is a block diagram illustrating additional details of a UE 201 in communication with an eNB 250 that may operate according to some embodiments described herein. FIG. 2 provides an abstraction of various operational layers, modules, and applications that operate on hardware of UE 201 (e.g. one or more processors and memory). As illustrated, UE 201 includes applications 220, 222, and 224; connectivity manager (CM) 216; radio interface layer (RIL) 214; transmission control protocol (TCP)/internet protocol (IP) stack 214; routing table 230; network interfaces 208, 210, and 212; cellular modem 204; wireless local area network (WLAN) circuitry 205 ; and other access circuitry 206. Radio resource control (RRC) 204A and non-access stratum (NAS) 204B are included in cellular modem 204.

[0021] For a UE 201 supporting connectivity via multiple access technologies, the UE may include a functional entity for each access technology (e.g., one entity called cellular modem 204 for third generation partnership project (3GPP) access, another one called WLAN circuitry 205 for WLAN access, and other access circuitry 206). In such embodiments, a functional entity illustrated as CM 216 is responsible for managing an access technology and for establishing and maintaining the connectivity. In some embodiments, these functional entities may be implemented on separate apparatuses (e.g., separate integrated circuits) while in other embodiments these may be integrated in a single apparatus, circuit, or assembly.

[0022] For Over the Top (OTT) applications, the CM 216 itself is requesting and handling the establishment of a packet data network (PDN) connection with an associated access point name (APN). This may be done at UE 201 without prior request from a specific application. In this case, the APN is usually called the "Internet APN" or "Default APN." After the PDN connection is established, the CM 204 creates a default route for the PDN connection and its associated Network Interface 208 in the routing table(s) 230. This is the default case when no WLAN circuit 205 connection is available. If a WLAN circuit 205 connection is available, the operation the CM 216 depends on whether in- parallel to the WLAN circuit 205 connection, an Internet- APN/PDN connection over cellular modem 204 is to be established.

[0023] In the example of FIG. 2, a request 291 from the application 222 is conveyed by the CM 216 to the RIL 214, and then from the RIL 214 to the Cellular Modem 204. After the request 291 is successfully served, the CM 216 updates a routing table 230 corresponding with the connection in update 292. The TCP/IP stack 214 may use the routing table 230 to determine the network interface 208, 210, or 212 to be used for the routing of application data packets received from an application 220, 222, or 224. In some embodiments, TCP/IP stack 214 may manage some aspects of routing table 230.

[0024] In some embodiments with a CM 216, for ACDC to be applied, the CM 216 determines an application identifier (ID) of application 222 when the application begins communicating, and the RRC 204A receives the ACDC broadcast information. In some embodiments the RRC 204A determines whether UE 201 is in a connected mode or not. Then one of the entities CM 216, NAS 204B, RRC 204 A, or some other entity can evaluate the ACDC parameters (e.g., details of an OMA-MO as discussed below) and perform a mapping from the application identifier to an ACDC category. The entity performing this operation can use the application identifier from CM 216. The ACDC category is also provided to the entity that is performing an ACDC check to make a decision as to whether the application requesting access is allowed network access or not. The entity making this decision may be any entity listed above in various embodiments, including entities not specifically detailed in UE 201 in various other embodiments. This entity uses the broadcast ACDC information and the information about whether UE 201 is in a connected mode in order to make the access decision for each application requesting network access. This entity may also operate with category or application specific back-off timers. In some embodiments, a different entity further down the protocol stack may implement back-off timers associated with particular applications 220, 222, 224, or other applications, or back-off timers associated with specific categories.

[0025] In some embodiments, all of the above may be done by CM 216, including the mapping from an application identifier to an ACDC category, an access decision, and a back-off timer operation. In such embodiments, CM 216 informs RRC 204A that ACDC checks have been passed successfully and access class barring (ACB) can be skipped.

[0026] In other embodiments, the mapping from application identifiers to ACDC categories, access decisions, and back-off timer operation are all performed in RRC 204 A. Some such embodiments may operate without a CM 216. In still further embodiments, actions may be distributed over several layers as detailed in the embodiments below.

[0027] In various embodiments, RRC 204A reads ACDC information in a broadcast channel from eNB 250. RRC 204A applies ACDC parameters in order to decide if UE 201 can initiate an RRC connection establishment procedure. ACDC can be simply an ACB skip functionality for certain application categories or it could provide parameters similar to ACB (e.g., ACB functions including probability of access barring and barring time).

[0028] In such embodiments, RRC 204A identifies an ACDC category of the application (e.g., application 222) that is starting. Thus, in such embodiments, NAS 204B either provides the ACDC category of the application that started the request or NAS 204B provides a mapping of the applications (e.g., applications 220, 222, 224) to application identifiers and then provides an identifier of the application that started the request. Based on the information on ACDC category, together with the broadcast information, RRC 204A can apply ACDC or ACB. RRC 204A thus reads broadcast information on ACDC and receives information (e.g., identifier and/or category information) from NAS 204B about an application associated with a network access request or communication. RRC 204A also applies ACDC or ACB based on this information. In some embodiments, operation is facilitated by OMA-MO files including application category information as detailed below.

[0029] In embodiments using an OMA-MO format, NAS 204B may be responsible for reading the OMA-MO data. In embodiments where NAS 204B reads an OMA-MO file, various different processes may implement aspects of ACDC. In some embodiments, OMA-MO information can be shared by NAS 204b with the CM 216. In other embodiments, OMA-MO information can optionally also be shared with the RRC 204A as a list of all categories and all applications that belong to each category. In various embodiments, when a request is initiated by an application 220, 222, 224, etc., the NAS 204B may provide to RRC 204A the ACDC category of the application that started the request. In other embodiments, NAS 204b provides to RRC 204a the identifier of the application that started the request. In such embodiments, NAS 204B operates so that RRC is provided details of a map of application identifiers onto ACDC categories in order for UE 201 to perform ACDC.

[0030] In some embodiments, NAS 204B operates such that when a service request procedure is barred due to ACB, the RRC 204A will notify the barring condition to the NAS 204B and the NAS 204B will not initiate a new service request procedure until the RRC 204A notifies the NAS 204B that the congestion situation is alleviated. This may be considered a "barring time." Thus, in some embodiments, a barring time is ended by a communication from RRC 204A to NAS 204B specifying that the barring time is complete. This barring time may be controlled in RRC 204 A by a timer, a notification from eNB 250 updating network conditions, or any other such processes for determining that an appropriate time for blocking an application from accessing a network is over. In order to be able to bypass this requirement to not initiate a new service request procedure for requests coming from applications in the ACDC list, various embodiments may operate as follows: in a first option, RRC 204A sends the ACDC indication to the NAS 204B to indicate that ACDC is activated. The ACDC indication also includes data about the ACDC level and other related ACDC information. In such embodiments, from the point when ACDC is activated on, NAS 204B will ignore the barring indication (e.g., ACB barring due to congestion) for any applications until ACDC is deactivated. In other embodiments, RRC 204A sends the ACDC indication to the NAS 204B to indicate ACDC is activated as well as providing the ACDC category level and other related information. The category level as referred to herein is a position in the ACDC category structure when the ACDC is organized with hierarchical categories from a lowest to a highest priority, or from a highest to lowest priority. From this point on, NAS 204B will ignore the barring indication for requests coming from an application belonging to an ACDC category higher than the ACDC category level barred, until ACDC is deactivated. In still further embodiments, NAS 204B will ignore the barring indication (ACB barring due to congestion) for requests coming from an application identified in the ACDC list, regardless of whether or not ACDC is activated. In still further embodiments, the functionality of barring of a request in the NAS 204B is completely removed from the NAS procedures. NAS will always forward any request to the RRC, regardless of whether or not ACDC is activated, and any ACDC will be managed by RRC 204 A.

[0031] In embodiments using a CM 216 or other circuitry or modules implementing similar management functionality, when a request is initiated by an application via CM 216, embodiments may use various implementations to manage ACDC connectivity. In a first embodiment, CM 216 provides to NAS 204B the ACDC category that started the request. This may be implemented where CM 216 may send a request to the NAS 204B to inquire if an application is part of a category and then NAS 204B will respond providing the category to which the application belongs. Alternatively, NAS 204B may share the entire ACDC information, or a combination list of all categories and all applications that belong to each category, with the CM 216. In other implementations, CM 216 may read the information directly (e.g., CM 216 may read an OMA-MO file). In another embodiment, CM 216 provides only the identifier of the application that started the request to the NAS 204B.

[0032] The above embodiments use ACDC indication communications comprising ACDC parameters. The ACDC indications may be structured as part of an existing system information block (SIB), e.g., SIB2. In other

embodiments, a new SIB-like structure may be used. This ACDC indication may be received by all UEs in a system or communicating with an eNB, assuming that the ACDC functionality is mandatory within a system to be supported by all UEs. No additional ACDC details would be required by the UE in such a case. In other embodiments where ACDC is not mandatory, ACDC indications may be received only by UEs that support ACDC functionality. In such embodiments, an SIB may be structured to be received by UEs that support ACDC, or an indication may be included in a new or existing SIB indicating that the network supports an ACDC mechanism that will be used in communications between the supporting UEs and the supporting elements of the network.

[0033] If the UE and eNB both support the ACDC functionality, the ACDC indication would be checked by the UE on a regular basis in order to use the updated information following legacy periodicity and a legacy modification period. Alternatively, these ACDC parameters might be allowed to be changed more frequently similar to public warning systems (PWS) notifications such as standardized earthquake and tsunami warning system (ETWS) notifications.

[0034] These ACDC parameters may be broadcasted in different ways.

Particular embodiments for a stage-3 text are described. It will be apparent that other implementations are possible within the scope of the present innovations. For example, some embodiments may use SIB2 or other new SIB structures; however, a similar concept could apply to other SIBs or a new SIB replacement structure. In one embodiment, the network indicates a congestion/barring level for each ACDC category. The categories are barred differently depending on a priority for each category. For allowed categories, whitelists may be used, and with whitelist usage for ACDC functionality, the network would broadcast the ACDC parameter indication/information for all the ACDC categories allowed. In embodiments using a blacklist approach, the network would broadcast the ACDC parameters indication/information for all the ACDC categories that are not allowed. For example, for the case of a whitelist and assuming that ACDC category 1 is the most probable to be allowed and ACDC category 5 is the least probable, the network might broadcast ACDC indications for categories 1-3, which would mean that ACDC categories 4 and 5 would be fully barred.

[0035] In some embodiments, the network only indicates the ACDC category that determines the range of ACDC categories allowed or not allowed, depending on whether ACDC is defined as a whitelist or blacklist operation. For example, assuming that ACDC is defined as a whitelist, and there are 5 ACDC categories and ACDC category 1 is the category with highest priority, the network at a certain instant may indicate that the threshold is ACDC category 2, which would be understood by the UE as only allowing network access to applications associated with categories 1 and 2. In other implementations, any number of categories may be used with any possible structure for indicating allowable or barred applications or groups of applications.

[0036] In embodiments where ACDC parameters provide a simple indication that an ACDC category is allowed, there are new IEs sent when the ACDC category is allowed. For example:

(1) acdc-Category-rl3 INTEGER (l ...maxACDC-r 13) could also be a list of the index of all the categories allowed or an ACDC threshold.

[0037] In embodiments where access barring configuration indications are provided indicating whether or not the ACDC category is allowed, the network provides an access barring indication for the ACDC categories that are allowed. In some embodiments, the network may need to add an index or reference of the ACDC category that is being indicated. In other embodiments, an ACDC listing may be used where the order implicitly defines the category (e.g., the first element of the list would correspond to the ACDC category 1 , the second element of the list to the ACDC category 2, and so on.) The network would decide which ACDC categories it wants to allow. If a particular ACDC category is completely allowed, the setting of the parameters would be such that the UE is never barred for this application. In some embodiments, if the ACDC category is not indicated (e.g., the network only broadcasts ACDC information for 3 elements), the ACDC categories 4 and 5 would be understood as to have to follow legacy ACB mechanism. For example:

(2) acdc-List-rl3 SEQUENCE (SIZE (l..maxACDC-rl3)) OF ACDC-Config-r 13 } OPTIONAL, - Need OR

ACDC-Config-rl3 ::= SEQUENCE { acdc-Barring-rl3

AC-BarringConfig OPTIONAL, -- Need OP -- Need OR}

AC-BarringConfig ::= SEQUENCE { ac-BarringFactor

ENUMERATED {p00, p05, plO, pl5, p20, p25, p30, p40, p50, p60, p70, p75, p80, p85, p90, p95, plOO}, ac-BarringTime

ENUMERATED { s4, s8, sl6, s32, s64, sl28, s256, s512 }, }

[0038] In such embodiments, those categories not indicated in the ACDC broadcast categories are mapped to a lowest ACDC category. When ACDC is configured and activated in the UE, the UE will configure ACDC barring for the configured applications that are part of the configured categories. For applications not listed explicitly in the configured categories, the UE will assume those applications belong to the lowest ACDC category, and will select ACDC barring based on a last entry in the list of ACDC categories list. In some embodiments the application is not listed explicitly in the configured categories because the application is uncategorized, and the uncategorized application thus has the access barring information of the lowest ACDC category broadcast by the network applied to the application. In some other embodiments an application is not listed explicitly in the configured categories when an application is associated with a category not found within the listed ACDC categories. For example, an application operating on a UE may be associated with a category D, where only categories A-C are defined by the ACDC categories broadcast by the network. When network access for the application is triggered, and the ACDC category D is not found within the ACDC categories broadcast by the system, the access barring parameters would be taken from the lowest ACDC category broadcast by the network.

[0039] In some embodiments, ACB is dependent on indications for the ACDC. ACB may thus be dependent on whether the ACDC category is allowed. In some embodiments, the ACDC indication only configures a factor that the UE needs to apply on top of legacy ACB parameters already being broadcasted (e.g., a simple number might be included to be used as a division factor such as the factor N for ACDC category such as [ac-BarringFactor/N] may be used with the factor M indicated for ACDC category 2 such as [ac- BarringFactor/M].) In other embodiments, the system determines the percentage of the ACB current value that affects a certain ACDC category. In such embodiments, a 0% would indicate that the ACDC category is not barred and it is allowed, a 10% would indicate that the ACDC category should only assume 10% of the indicated ACB barring parameters, and so on. For example:

(3) acdc-List-rl3 SEQUENCE (SIZE (l..maxACDC-r 13)) OF ACDC-Config-rl3 } OPTIONAL, - Need OR

ACDC-Config-rl3 ::= SEQUENCE { acdc-BarringFactor- rl3 INTEGER (0...100) OPTIONAL, -- Need OP -- Need OR} where acdc-BarringFactor-rl3 indicates the percentage of the ACB parameters that should be for a specific ACDC category. This might be defined to apply only to some of the parameters, such as the ac-barringFactor, or to all of them. In such embodiments, the ACB parameters used would depend on the kind of request, although in most cases this would correspond to MO-data. However, there might be cases where the application triggers other establishment groups, in which case the MO-signaling ACB parameters might be used then for other systems such as service specific access control (SSAC) systems for multimedia telephony (MMTEL) voice/video. In some embodiments, the factor could be also defined to be a value above 100 assuming that the system is to be structured to provide a higher barring factor than the one provided by the ac-BarringFactor. Alternatively, the factor could also be a multiplication factor instead.

[0040] In various embodiments, these solutions may also be combined. For example, based on the above, some embodiments may use:

(5) acdc-PerPLMN-List-rl3 SEQUENCE (SIZE (l..maxPLMN-rl l))

OF ACDC-ConfigPLMN-r 13 } OPTIONAL, - Need OR

ACDC-ConfigPLMN-rl3 ::= SEQUENCE { acdc-List- rl3 SEQUENCE (SIZE (l..maxACDC-rl3)) OF

ACDC-Config-rl 3 } OPTIONAL, - Need OR}

ACDC-Config-rl3 ::= SEQUENCE { acdc-Barring-rl3 AC-BarringConfig

OPTIONAL, -- Need OP} where maxACDC-rl3 is defined as a maximum number of ACDC categories that the operators may define through OMA configuration. In some

embodiments, if a legacy "AC-BarringConfig" is used, a Barring Factor definition might be updated or a similar IE specified for ACDC might be created in order to indicate when a certain ACDC category is always allowed without having to apply the random number drawn.

[0041] For example, for an ac-BarringFactor in some embodiments, if the random number drawn by the UE is lower than this value, access is allowed. Otherwise the access is barred. The values are interpreted in the range [0,1): pOO = 0, p05 = 0.05, plO = 0.10,..., p95 = 0.95. Values other than pOO can only be set if all bits of the corresponding ac-BarringForSpecialAC are set to 0. A UE has responsibility in such embodiments to read the updated values and use them.

[0042] Thus, while ACB and ACDC may coexist, different operations may be used to manage the relationship between ACDC and ACB in systems using ACB according to 3GPP LTE, LTE advanced, or other related communications standards. In some embodiments, when ACDC is configured (e.g. via open mobile alliance device management (OMA-DM) and activated (e.g. via the broadcast channel) in the UE, the UE will use ACDC for the configured applications that are part of the configured categories. For applications not listed in the configured categories, the UE uses ACB categories instead. In other embodiments, when ACDC is configured and activated in the UE, the UE will use ACDC for the configured applications that are part of the configured categories. For applications not listed explicitly in the configured categories, the UE will assume those applications belong to the lowest ACDC category.

Embodiments described below assume the use of ACDC configured and activated using OMA-DM via the broadcast channel. Any embodiment described herein, however, may alternatively use the ACDC configured and activated in the UE with ACDC for configured applications that are part of configured categories. [0043] FIG. 3 is a block diagram illustrating additional details of a UE 301 in communication with an eNB 350 that may operate according to some embodiments described herein. FIG. 3 describes aspects of information flow in UE301 performing ACDC checks before accessing a network for an application layer 302 via eNB 350. In the procedure described below with respect to FIG. 3, the UE 301 and network including eNB 350 supports ACDC functionality and a mapping from an application identifier for an application in application layer 302 to an ACDC category associated with the application performed at the NAS layer 306. In other embodiments, this mapping may be performed by a CM or RRC such as CM 304, RRC layer 308, CM 216, or RRC 204A.

[0044] As part of an initial ACDC setup operation, NAS layer 306 reads the application categories for ACDC conveyed to the UE 301 through OMA-MO 310. In FIG. 3, it is shown how the OMA-MO 310 contains information of the different applications identified by application identifiers belonging to/associated with each ACDC category, including an identifier for an application in application layer 302. In other embodiments, other kinds of information or structures for matching categories with applications may be used.

[0045] RRC 308 receives ACDC indication information on a broadcast channel from eNB 350 as part of communication 312, including the ACDC parameters. The ACDC parameters may contain a probability of access and a barring time for cases or categories where network access is not allowed. If the probability of barring is zero, then the access is granted. If probability of barring is X, then the probability of access is 1-X. Other potential ways of broadcasting this kind of information are discussed above. In some embodiments, for applications not listed in the configured categories, the UE 301 uses ACB parameters instead. In other embodiments, for applications not listed in the configured categories, the UE 301 will assume those applications belong to the lowest ACDC category.

[0046] The application layer 302 then sends request for connectivity to CM 304 or, if connectivity is already established, the application layer 302 sends an application data packet. Either of these requests will be associated with a particular application that is further associated with an ACDC category (e.g., catl, cat2, cat3, etc.). [0047] In some embodiments, when the UE 301 moves from connected to idle mode, it can keep the PDN connection; as a consequence, the application can also keep its IP socket. The system thus is structured to consider the case that the IP socket is already assigned from an earlier network access and the application can send data packets right away. In order to handle this case, various options are possible. In a first embodiment, CM 304 may intercept every single data packet - at least during the phase when the UE is in idle mode. This means a new attention (AT) command from RRC layer 308 to CM 304 is used to inform CM 304 about changes between an RRC idle mode and RRC connected mode. CM 304 then checks to which application the data packet belongs. For this purpose, the CM 304 would learn which local port number was assigned to which application or application identifier. In other embodiments, CM 304 may release all IP sockets each time the UE 301 moves to RRC idle mode, so that the application always needs to start with a new request for connectivity. This may use a notification from RRC layer 308 to CM 304, such as a new AT command, to indicate transition from connected to idle mode

[0048] CM 304 then sends the request or application data packet for connectivity to NAS layer 306, including the application identifier. Optionally, CM 304 can provide the ACDC category instead of the application identifier. This would operate such that the NAS layer 306 previously provides the ACDC categories list to CM 304.

[0049] The NAS layer 306 then checks if the application initiating the communication or connection from application layer 302 is in the ACDC list from OMA-MO 310 and, if so, which category it belongs to.

[0050] NAS layer 306 then forwards the request for RRC connection establishment to the RRC layer 308, including indication of the ACDC category to which the application belongs. Optionally, NAS layer 306 can provide the application identifier instead of the ACDC category. This would operate such that the NAS layer 306 previously provides the ACDC categories list to RRC layer 308. This allows RRC layer 308 to map application identifiers into ACDC categories. If the application is not part of ACDC list, NAS layer 306 can either omit the application notification or indicate that the request comes from an application not in the ACDC list. [0051] RRC layer 308 then performs an ACDC check. This may involve initiating a barring mechanism for applications currently barred from network access by ACDC, if applicable. Otherwise, RRC layer 308 performs ACB checks.

[0052] If ACDC category passes ACDC (e.g., no barring is initiated), then RRC layer 308 sends the RRC connection establishment request and the service request to the physical layer as part of communication 314 to eNB 350.

Otherwise (e.g., barring is initiated) a reject is sent to the NAS layer 306 from RRC layer 308. This may optionally include the cause of the barring (e.g., category or ACDC parameter descriptions associated with the ACDC initiated barring of access to the network.)

[0053] As described above, in some embodiments, both ACDC and ACB may be used to manage network access in some embodiments. In certain

embodiments, operation of both ACDC and ACB may be managed such that when ACDC is configured and activated in the UE, the UE will use ACDC for the configured applications that are part of ACDC categories. For applications not listed in configured ACDC categories, ACB will be used. In other embodiments, when ACDC is configured and activated in the UE, the UE will use ACDC for the configured applications that are part of the configured ACDC categories. For applications not explicitly listed in configured ACDC categories, the UE will assume those applications belong to the lowest ACDC category, and ACB may operate with any ACB parameters replaced with ACDC parameters associated with the lowest priority ACDC category. In other embodiments, other systems for managing the operation of both ACB and ACDC may be used. In various embodiments described herein, any such conflict management between ACB and ACDC may be used.

[0054] FIG. 4 then describes a method 400 for application specific congestion control for LTE, LTE advanced, or similar network data communication systems. The operations of method 400 may be implemented using any UE described herein, and will be associated with a corresponding method performed by an eNB. The UE performing method 400 may be similar to any device described herein, including UEs 101, 700, 800, 1000, or a device similar to system 900. In some embodiments, method 400 is described by instructions stored in a non-transitory computer readable medium. The instructions may be used by one or more processors accessing the medium to cause a device to perform method 400.

[0055] As illustrated, method 400 begins with operation 405 to receive, at the UE from an eNB, an OMA-MO comprising a plurality of application categories associated with ACDC for a network including an eNB and implementing ACDC. In operation 410 the UE receives, at a RRC layer of the UE from the eNB, an ACDC indication comprising ACDC parameters associated with a set of network conditions. The ACDC indication and the OMA-MO are both received at any point prior to the additional ACDC operations described below and may be updated during operation of the UE.

[0056] Then, in operation 415, a NAS layer of the UE receives a first communication associated with a first application. As described above, this communication is received from an application layer, and may either be a request for connection or may be a data packet if the connection has been previously established. In operation 420, the first communication is processed to identify a first category of a plurality of application categories, wherein the first category is associated with the first application, and wherein each category of the plurality of application categories is associated with a set of congestion control parameters based on the ACDC parameters. The categories correspond to the categories from the OMA-MO received in operation 405 above. In operation 425, a first set of current congestion control parameters is identified, and an ACDC check is performed based on the current set of congestion control parameters associated with the first category. In operation 430, the first communication is processed based on the results of the ACDC check. If congestion control associates the communication with a barring of access, then a notification that the access is barred is sent from the RRC layer to the NAS layer as part of the processing of the first communication. If access is not barred, then the processing of the first communication involves sending the communication to the physical layer for operations with the eNB as part of the application communicating with the network via the eNB. [0057] FIG. 5 is a block diagram illustrating additional details of a UE 501 in communication with an eNB 550 that may operate according to some embodiments described herein.

[0058] In this example of FIG. 5, the initial request for connectivity sent by the app layer is treated in a similar way as described above in FIGs. 3 and 4. FIGs. 5 and 6 describe certain embodiments where the transmission of data packets is treated differently after the initial connection is established. As such, FIG. 5 does not assume that the CM 504 is intercepting every single application data packet or that it releases all IP sockets each time the UE 501 moves to an RRC idle mode. Instead, FIG. 5 describes operations using a radio access bearer (RAB) manager 524, which is an entity in the user plane protocol stack of the cellular modem (e.g. cellular modem 204).

[0059] Thus, an initial request for connectivity may be performed by UE 501 performing a method such as method 400 or operations described above with respect to FIG. 3, with the operations performed by application layer 502, CM 504, NAS layer 506, OMA-MO 510, and RRC layer 508.

[0060] After a PDN connection has been established and the IP socket created, the CM 504 determines which local IP address and local port number is assigned to the application and informs NAS layer 506 about this. CM 504 will also inform the NAS layer 506 later when the IP socket is released. This may, for example, use a new AT command, where CM 504 provides NAS layer 506 with the correct information (e.g. application identifier, local IP address, local user datagram protocol (UDP) port number, and/or local TCP port number) when the IP socket is created and informs the NAS layer 506 later when the IP socket for the application identifier has been released.

[0061] With this information, the NAS layer 506 creates and maintains a mapping table shown as flow table 530, which provides a mapping from a local IP address and local UDP port number, or local IP address and local TCP port number, to an application identifier.

[0062] After flow table 530 is established, when the application is set to transmit an application user data packet, the application from application layer 502 delivers the packet via the IP socket to the TCP/IP protocol stack 522. [0063] The TCP/IP protocol stack 522 delivers the packet to the RAB manager 524. The RAB manager checks whether the radio bearers 526 are established. If radio bearers 526 are not established (for example, if UE 501 is in RRC idle mode), then the RAB manager 524 requests that the NAS layer, or the evolved packet system (EPS) mobility management (EMM) entity in the NAS layer 506, initiate a service request procedure so that the radio bearers 526 are established. With this request, the RAB manager 524 provides the EMM in the NAS layer 506 with the local IP address and, if available, the local UDP port or TCP port which the RAB manager 524 extracted from the IP packet header. This IP packet header may be extracted as part of the check whether the radio bearers 526 are established.

[0064] Using flow table 530, the NAS layer 506 performs a mapping from the local IP address, and/or local UDP/TCP port to the application identifier associated with the data packet transmission. Then, by means of the OMA-MO 510, the NAS layer 506 maps from the application identifier to the ACDC category detailed in the OMA-MO 510. This provides the NAS layer 506 with the application identifier of the application attempting to send the data packet as well as the ACDC category associated with the packet. The NAS layer 506 can now proceed to perform the operations described above related to the request for RRC connection establishment to the RRC layer 508, with communications 512 and 514 similar to communications 312 and 314.

[0065] In other embodiments, the tasks may be assigned in different ways to different layers. For example, the RAB manager 524 may create and maintain the flow table 530 in some embodiments rather than the NAS layer 506. In such an embodiment, CM 504 would provide RAB manager 524 with tuples (App ID, local IP address, local UDP port number, and/or local TCP port number); and the RAB manager 524 would provide the NAS layer 506 with the application identifier instead of the descriptive data (local IP address, local UDP/TCP port) of the user data packet.

[0066] In various embodiments, the communication from an application may be processed in different ways. When multiple consecutive application requests occur, the NAS layer and RRC layer may process them differently for efficiency, in some embodiments. In some embodiments each ACDC category i may have a barring time Tbar_i (e.g., a time that the application is barred from network access) and a barring probability Pbar_i, and the priority of category j may be greater than the priority category k, if j<k. When a request arrives to the RRC layer for a category i communication and the request is barred, the RRC layer runs a timer Tbar_i. In some embodiments, this timer could also or alternatively be associated with ACB barring. In such an embodiment, the NAS layer is notified of ACDC/ACB barring associated with timer Tbar_i.

[0067] When a request for a second category j is sent from a CM to the NAS layer, then in some embodiments, if j >= i, the communication is automatically barred. This may happen in the NAS layer to block the RRC connection request to the RRC layer. In other embodiments, this may occur in the RRC layer, which sends a rejection to the NAS layer.

[0068] In some embodiments, the RRC layer may operate as follows. If j < i, then the RRC layer will check barring conditions based on Pbar_J. If the ACDC category passes the barring test, Tbar_i is stopped and the RRC layer initiates an RRC connection request procedure. If the ACDC category does not pass the barring test, the RRC layer rejects the request and a number of options may occur. In one embodiment, the RRC layer runs one timer per ACDC category. In another embodiment, the RRC layer stops Tbar_i and runs a new timer = min(Tbar_j and remaining lifetime of Tbar_i). In another embodiment, the RRC layer stops Tbar_i and runs Tbar_J. In another embodiment, the RRC layer continues running Tbar_i.

[0069] In embodiments where the NAS takes a decision that a previous access barred indication could be ignored (e.g. where a new ACDC category has a higher priority) and therefore, RRC only stops the running bar time and checks whether access is barred or not for the new higher priority ACDC category. If access is barred under the new higher priority ACDC category, a new bar time is initiated. After the new bar time is initiated, upper layers are informed about the failure to establish an RRC connection, and that access barring is applicable due to ACDC.

[0070] FIG. 6 describes a method for application specific congestion control, according to some embodiments described herein. Method 600 may be performed following method 400 or a similar method for establishing an initial connection in response to an application requesting network access. In various embodiments, the operations of method 400 and 600 may be repeated and combined in a variety of different ways as a UE enters and leaves an RRC idle mode and releases and reestablishes connections. Similarly, various embodiments may omit certain operations in accordance with the present innovations (for example, if a RAB manager determines that radio bearers are established, then operation 610 may be replaced with an alternate operation using the established radio bearers).

[0071] Method 600 begins with operation 605 following an initial communication and set of operations establishing a connection for an application. Operation 605 includes a TCP/IP protocol stack receiving, from a first application, a second communication comprising an application user data packet and delivering, from the TCP/IP protocol stack to a RAB manager of the UE, the application user data packet.

[0072] In operation 610, the RAB manager verifies that a set of radio bearers are not established for the first application as part of an RRC idle mode of the UE and initiates a request to an EMM of the NAS layer to initiate a service request procedure to establish the set of radio bearers for the first application, wherein the request to the EMM comprises the local IP address and the local port number.

[0073] The NAS layer then performs a mapping from the local IP address and the local port number to an identifier for the first application and second mapping from the identifier for the first application to the first category as part of operation 615. This information is then communicated from the NAS layer to the RRC layer in operation 620. It is used by the RRC layer to identify the current congestion control parameters associated with the first category and to perform an ACDC check in operation 620 to determine whether access to the network is allowed or barred.

[0074] Based on the result of this ACDC check, the service request procedure is processed. If congestion control associates the service request procedure with a barring of access, then a notification that the access is barred is sent from the RRC layer to the NAS layer as part of the processing of the service request procedure. If access is not barred, then the processing of the service request procedure involves establishment of the radio bearers by the eNB and sending the second communication via the radio bearers to the physical layer for operations with the eNB as part of the application communicating with the network via the eNB.

EXAMPLES

[0075] In various embodiments, methods, apparatus, non-transitory media, computer program products, or other implementations may be presented as example embodiments, in accordance with the descriptions provided above. Certain embodiments may include UE such as phones, tablets, mobile computers, or other such devices. Some embodiments may be integrated circuit components of such devices, such as circuits implementing processing on an integrated circuitry. In some embodiments, functionality may be on a single chip or multiple chips in an apparatus. Some such embodiments may further include transmit and receive circuitry on integrated or separate circuits, with antennas that are similarly integrated or separate structures of a device. Any such components or circuit elements may similarly apply to corresponding evolved node B embodiments described herein.

[0076] Example 1 is a non-transitory computer readable medium comprising instructions that, when executed by one or more processors, configure a UE for ACDC, configure the UE to: receive, at an RRC layer of the UE from an eNB, an ACDC indication comprising ACDC parameters associated with a set of network conditions; receive, at a NAS layer of the UE, a first communication associated with a first application; process the first

communication to identify a first category of a plurality of application categories, wherein the first category is associated with the first application, and wherein each category of the plurality of application categories is associated with current congestion control parameters based on the ACDC parameters; identify current congestion control parameters associated with the first category; perform an ACDC check; and process the first communication based on the results of the ACDC check.

[0077] In Example 2, the subject matter of Example 1 optionally includes wherein the instructions further configure the UE to: receive, at the UE from an eNB, an OMA-MO comprising the plurality of application categories associated with ACDC for a network associated with the eNB ; wherein the ACDC indication is received at the UE following receipt of the OMA-MO.

[0078] In Example 3, the subject matter of any one or more of Examples 1-2 optionally include wherein the instructions further configure the UE to: receive, at a CM of the UE from an application layer of the UE, a first communication associated with a first application; wherein the first

communication is received at the NAS layer of the UE via the CM from the first application.

[0079] In Example 4, the subject matter of Example 3 optionally includes wherein receipt of the ACDC indication is processed by the RRC layer of the UE using the application categories from the OMA-MO.

[0080] In Example 5, the subject matter of Example 4 optionally includes wherein the instructions further configure the UE to process the first communication to identify the first category by: sending the first communication from the CM to the NAS layer with an application identifier for the first application; checking, at the NAS layer, the application identifier with an ACDC list to identify the first category as associated with the first application; and sending the first communication from the NAS layer to the RRC layer with an indication identifying the first category.

[0081] In Example 6, the subject matter of Example 5 optionally includes wherein the instructions configure the UE to perform the ACDC check by: receiving the first communication at the RRC layer from the NAS layer with the indication identifying the first category; and performing the ACDC check at the RRC layer to identify any applicable barring mechanism.

[0082] In Example 7, the subject matter of Example 6 optionally includes wherein the instructions configure the UE to process the first communication by: based on a determination at the RRC layer that the first application is barred from network access by the current congestion control parameters associated with the first category, communicating a rejection from the RRC layer to the NAS layer.

[0083] In Example 8, the subject matter of Example 7 optionally includes wherein the rejection comprises an ACDC category barred rejection indication. [0084] In Example 9, the subject matter of Example 8 optionally includes wherein the instructions configure the UE to process the first communication by: based on a determination at the RRC layer that the first application is allowed network access by the current congestion control parameters associated with the first category, forwarding the first communication to a physical layer of the UE.

[0085] In Example 10, the subject matter of any one or more of

Examples 1-9 optionally includes wherein the ACDC parameters comprise a probability of access barring for each application category of the plurality of application categories.

[0086] In Example 11 , the subject matter of any one or more of

Examples 1-10 optionally includes wherein the ACDC parameters further comprise a barring time for each application category of the plurality of application categories.

[0087] In Example 12, the subject matter of any one or more of

Examples 1-11 optionally includes wherein the first communication comprises an application data packet.

[0088] In Example 13, the subject matter of any one or more of

Examples 3-12 optionally includes wherein the first communication is received at the CM as part of an interception, by the CM, of each application data packet for each application operating on the UE to be transmitted using the network.

[0089] In Example 14, the subject matter of Example 13 optionally includes wherein the CM releases all IP sockets each time the UE transitions to an RRC idle state.

[0090] In Example 15, the subject matter of any one or more of

Examples 1-14 optionally includes wherein the instructions further configure the UE to: communicate, from the application layer of the UE, a second

communication associated with a second application; process the second communication to determine that the second application is not associated with any category of the plurality of application categories; and based on the determination that the second application is not associated with any of the plurality of application categories, process the second communication using a set of ACB protocols separate from the different sets of congestion control parameters. [0091] In Example 16, the subject matter of any one or more of

Examples 1-15 optionally includes wherein the instructions further configure the UE to: communicate, from the application layer of the UE to the connectivity manager of the UE, a second communication associated with a second application; process the second communication to determine that the second application is not associated with any category of the plurality of application categories; and based on the determination that the second application is not associated with any of the plurality of application categories, process the second communication using a lowest priority ACDC category of the plurality of application categories.

[0092] In Example 17A, the subject matter of any one or more of

Examples 1-16 optionally includes: wherein the first communication comprises a request for connectivity.

[0093] In Example 17B, the subject matter of any one or more of Examples 1-16 optionally includes wherein the first communication comprises an application data packet.

[0094] In Example 18, the subject matter of Example 17 optionally includes wherein the instructions further configure the UE to: establish a PDN connection and generate an IP socket for the first application in response to the request for connectivity; determine a local IP address and a local port number assigned to the first application; communicate, to the NAS layer, the local IP address and the local port number for the first application; and generate, by the NAS layer, a mapping table to map the local IP address and the local port number to the first application.

[0095] In Example 19, the subject matter of Example 18 optionally includes wherein the instructions further configure the UE to: receive, at a TCP/IP protocol stack from the first application, a second communication comprising an application user data packet; deliver, from the TCP/IP protocol stack to a RAB manager of the UE, the application user data packet; deliver, from the RAB manager to the NAS layer, the local IP address and the local port number associated with the second communication; perform, by the NAS layer, a mapping from the local IP address and the local port number to an identifier for the first application; perform, by the NAS layer, a second mapping from the identifier for the first application to the first category; communicate, from the NAS layer to the RRC layer, a service request with an indication identifying the first category to the RRC layer; identify, by the RRC layer, a set of current congestion control parameters associated with the first category; perform, by the RRC layer, an ACDC check based on the set of current congestion control parameters associated with the first category; process, by the RRC layer, the service request based on the result of the ACDC check; and, upon establishment of the radio bearers, deliver, by the RAB manager, the second communication via the radio bearers to a physical layer of the UE.

[0096] In Example 20, the subject matter of any one or more of

Examples 18-19 optionally includes wherein the instructions further configure the UE to: verify, by the RAB manager, that a set of radio bearers are not established for the first application as part of an RRC idle mode of the UE; initiate, by the RAB manager, a request to an EMM of the NAS layer to initiate a service request procedure to establish the set of radio bearers for the first application, wherein the request to the EMM comprises the local IP address and the local port number.

[0097] In example 21, an apparatus of a UE comprising control circuitry is configured to: receive, at the UE from an eNB, an OMA-MO comprising a plurality of application categories associated with ACDC for a network associated with the eNB; receive, at a RRC layer of the UE from an eNB, an ACDC indication comprising ACDC parameters associated with a set of network conditions; receive, at a NAS layer of the UE a first communication associated with a first application; process the first communication to identify a first category of the plurality of application categories, wherein the first category is associated with the first application, and wherein each category of the plurality of application categories is associated with a set of congestion control parameters based on the ACDC parameters; identify a first set of congestion control parameters associated with the first category; perform an ACDC check based on the current congestion control parameters associated with the first category; and process the first communication based on the result of the ACDC check. [0098] In Example 21 A, the subject matter of Example undefined optionally includes embodiments wherein the control circuitry comprises:

application circuitry configured to execute instructions for the first application; and baseband circuitry coupled to the application circuitry and configured to implement the RRC layer and the NAS layer.

[0099] In Example 22, the subject matter of Example 21 optionally includes further comprising: an antenna; and RF circuitry coupled to the antenna and the baseband circuitry, the RF circuitry to receive the OMA-MO object from the eNB via the antenna.

[00100] Example 23 is an apparatus of a UE comprising radio frequency circuitry and baseband circuitry configured as: means for receiving, at the UE from an eNB, an OMA-MO comprising a plurality of application categories associated with ACDC for a network associated with the eNB; means for accessing an ACDC indication comprising ACDC parameters associated with a set of network conditions; means for accessing a first communication associated with a first application; means for processing the first communication to identify a first category of the plurality of application categories, wherein the first category is associated with the first application, and wherein each category of the plurality of application categories is associated with a set of congestion control parameters based on the ACDC parameters; means for identifying a first set of congestion control parameters associated with the first category; means for performing an ACDC check based on the current congestion control parameters associated with the first category; and means for processing the first communication based on the results of the ACDC check.

[00101] In Example 24, the subject matter of Example 23 optionally includes further comprising application circuitry operating an application and: means for establishing a PDN connection and generating an internet protocol IP socket for the first application in response to the first communication comprising a request for connectivity; means for determining a local IP address and a local port number assigned to the first application and communicating the local IP address and the local port number for the first application; means for generating a mapping table to map the local IP address and the local port number to the first application. [00102] Example 25 is a method for ACDC comprising: receiving, at a

RRC layer of the UE from an eNB, an ACDC indication comprising ACDC parameters associated with a set of network conditions; receiving, at a NAS layer of the UE a first communication associated with a first application; processing the first communication to identify a first category of a plurality of application categories, wherein the first category is associated with the first application, and wherein each category of the plurality of application categories is associated with a set of congestion control parameters based on the ACDC parameters; identifying a first set of congestion control parameters associated with the first category; performing an ACDC check based on the current congestion control parameters associated with the first category; and processing the first communication based on the result of the ACDC check.

[00103] In Example 26, the subject matter of Example 25 optionally includes further comprising: receiving, at a RRC layer of the UE from an eNB, an ACDC indication comprising ACDC parameters associated with a set of network conditions; receiving, at a NAS layer of the UE a first communication associated with a first application; processing the first communication to identify a first category of a plurality of application categories, wherein the first category is associated with the first application, and wherein each category of the plurality of application categories is associated with a set of congestion control parameters based on the ACDC parameters; identifying a first set of congestion control parameters associated with the first category; performing an ACDC check based on the current congestion control parameters associated with the first category; and processing the first communication based on the result of the ACDC check.

[00104] In Example 27, the subject matter of Example 26 optionally includes further comprising: receiving, at the UE from an eNB, an OMA-MO comprising the plurality of application categories associated with ACDC for a network associated with the eNB ; wherein the ACDC indication is received at the UE following receipt of the OMA-MO.

[00105] In Example 28, the subject matter of Example 27 optionally includes wherein the instructions further configure the UE to: receiving, at a CM of the UE from an application layer of the UE, a first communication associated with a first application; wherein the first communication is received at the NAS layer of the UE via the CM from the first application.

[00106] In Example 29, the subject matter of any one or more of

Examples 27-28 optionally includes wherein receipt of the ACDC indication is processed by the RRC layer of the UE using the application categories from the OMA-MO.

[00107] In Example 30, the subject matter of Example 29 optionally includes wherein the instructions further configure the UE to process the first communication to identify the first category by: sending the first communication from the CM to the NAS layer with an application identifier for the first application; checking, at the NAS layer, the application identifier with an ACDC list to identify the first category as associated with the first application; and sending the first communication from the NAS layer to the RRC layer with an indication identifying the first category.

[00108] In Example 31 , the subject matter of Example 30 optionally includes wherein the instructions configure the UE to perform the ACDC check by: receiving the first communication at the RRC layer from the NAS layer with the indication identifying the first category; and performing the ACDC check at the RRC layer to identify any applicable barring mechanism.

[00109] In Example 32, the subject matter of Example 31 optionally includes wherein the instructions configure the UE to process the first communication by: based on a determination at the RRC layer that the first application is barred from network access by the current congestion control parameters associated with the first category, communicating a rejection from the RRC layer to the NAS layer.

[00110] In Example 33, the subject matter of Example 32 optionally includes wherein the rejection comprises an ACDC category barred rejection indication.

[00111] In Example 34, the subject matter of Example 33 optionally includes wherein the instructions configure the UE to process the first communication by: based on a determination at the RRC layer that the first application is allowed network access by the current congestion control parameters associated with the first category, forwarding the first

communication to a physical layer of the UE.

[00112] In Example 35, the subject matter of Example 34 optionally includes wherein the ACDC parameters comprise a probability of access barring for each application category of the plurality of application categories.

[00113] In Example 36, the subject matter of any one or more of

Examples 25-35 optionally includes wherein the ACDC parameters further comprise a barring time for each application category of the plurality of application categories.

[00114] In Example 37, the subject matter of any one or more of

Examples 25-36 optionally includes wherein the first communication comprises an application data packet.

[00115] In Example 38, the subject matter of any one or more of

Examples 27-37 optionally includes wherein the first communication is received at the CM as part of an interception, by the CM, of each application data packet for each application operating on the UE to be transmitted using the network.

[00116] In Example 39, the subject matter of Example 38 optionally includes wherein the CM releases all IP sockets each time the UE transitions to an RRC idle state.

[00117] In Example 40, the subject matter of any one or more of

Examples 25-39 optionally includes wherein the instructions further configure the UE to: communicating, from the application layer of the UE, a second communication associated with a second application; processing the second communication to determine that the second application is not associated with any category of the plurality of application categories; and based on the determination that the second application is not associated with any of the plurality of application categories, processing the second communication using a set of ACB protocols separate from the different sets of congestion control parameters.

[00118] In Example 41 , the subject matter of any one or more of

Examples 25-40 optionally includes wherein the instructions further configure the UE to: communicate, from the application layer of the UE to the connectivity manager of the UE, a second communication associated with a second application; process the second communication to determine that the second application is not associated with any category of the plurality of application categories; and based on the determination that the second application is not associated with any of the plurality of application categories, process the second communication using a lowest priority ACDC category of the plurality of application categories.

[00119] In Example 42, the subject matter of any one or more of

Examples 25-41 optionally includes wherein the first communication comprises a request for connectivity.

[00120] In Example 43, the subject matter of Example 42 optionally includes wherein the instructions further configure the UE to: establish a PDN connection and generate an IP socket for the first application in response to the request for connectivity; determine a local IP address and a local port number assigned to the first application; communicate, to the NAS layer, the local IP address and the local port number for the first application; and generate, by the NAS layer, a mapping table to map the local IP address and the local port number to the first application.

[00121] In Example 44, the subject matter of Example 43 optionally includes wherein the instructions further configure the UE to: receive, at a TCP/IP protocol stack from the first application, a second communication comprising an application user data packet; deliver, from the TCP/IP protocol stack to a RAB manager of the UE, the application user data packet; deliver, from the RAB manager to the NAS layer, the local IP address and the local port number associated with the second communication; perform, by the NAS layer, a mapping from the local IP address and the local port number to an identifier for the first application; perform, by the NAS layer, a second mapping from the identifier for the first application to the first category; communicate, from the NAS layer to the RRC layer, a service request with an indication identifying the first category to the RRC layer; identify, by the RRC layer, a set of current congestion control parameters associated with the first category; perform, by the RRC layer, an ACDC check based on the set of current control parameters associated with the first category; process, by the RRC layer, the service request based on the result of the ACDC check; and, upon establishment of the radio bearers, deliver, by the RAB manager, the second communication via the radio bearers to a physical layer of the UE.

[00122] In Example 45, the subject matter of Example 44 optionally includes wherein the instructions further configure the UE to: verify, by the RAB manager, that a set of radio bearers are not established for the first application as part of an RRC idle mode of the UE; and initiate, by the RAB manager, a request to an EMM of the NAS layer to initiate a service request procedure to establish the set of radio bearers for the first application, wherein the request to the EMM comprises the local IP address and the local port number.

[00123] Example 46 may include a method comprising: transmitting, from the network, a broadcast message to the UEs including an indication of the one or more ACDC parameters for each defined ACDC category of applications.

[00124] Example 47 may include a method of example 46 where the one or more ACDC parameters include a barring or congestion level for each ACDC category.

[00125] Example 48 may include a method of example 46 where the one or more ACDC parameters include a list of ACDC categories allowed or not allowed.

[00126] Example 49 may include a method of example 46 where the one or more ACDC parameters include the highest ACDC category allowed and any ACDC category below the category allowed is not allowed as per ACDC.

[00127] Example 50 may include a method comprising a UE supporting

ACDC mechanism and storing a OMA-MO file; receiving, by a first layer in the UE, a broadcast message including the one or more ACDC parameters;

determining, by a second layer in the UE, the ACDC category of the application that wants to transmit a packet to the network; and processing, by a third layer in UE, the one or more ACDC parameters in order to determine which ACDC parameters to use and to determine whether the application is allowed to access the network.

[00128] Example 51 may include a method of example 50 where the first

UE layer is the RRC.

[00129] Example 52 may include a method of example 50 where the second UE layer is the CM layer. [00130] Example 53 may include a method of example 52 where the CM layer receives the application identity from the application layer.

[00131] Example 54 may include a method of example 52 where the CM reads the OMA-MO file and maps the application identity of the application that wants to transmit a packet to the ACDC category.

[00132] Example 55 may include a method of example 54 where the second UE layer is the NAS layer.

[00133] Example 56 may include a method of example 55 where the NAS layer receives the application identity from the application layer or from the CM layer.

[00134] Example 57 may include a method of example 55 where the NAS reads the OMA-MO file and maps the application identity of the application that wants to transmit a packet to the ACDC category.

[00135] Example 58 may include a method of example 52 where the CM receives the information from the OMA-MO file from the NAS layer and maps the application identity of the application that wants to transmit a packet to the ACDC category.

[00136] Example 59 may include a method of example 50 where the third

UE layer is the RRC layer.

[00137] Example 60 may include a method of example 59 where the RRC receives an indication of the ACDC category from the CM layer and maps the ACDC category to the one or more ACDC parameters.

[00138] Example 61 may include a method of example 59 where the RRC receives an indication of the ACDC category from the NAS layer and maps the ACDC category to the one or more ACDC parameters.

[00139] Example 62 may include a method of example 50 where the third

UE layer is the NAS layer.

[00140] Example 63 may include a method of example 62 where the NAS receives the one or more ACDC parameters from the RRC layer and maps the ACDC category to the one or more ACDC parameters.

[00141] Example 64 may include a method of example 50, where upon successful establishment of a TCP or UDP connection between the application on the UE and a host in the network, a fourth UE layer stores a relationship between the application identity and the combination (local IP address, UDP port number) or (local IP address, TCP port number).

[00142] Example 65 may include a method of example 64, where upon receipt of an indication that an application wants to transmit a user data packet, if the UE is in RRC idle mode, the fourth UE layer maps the combination (local IP address, UDP port number) or (local IP address, TCP port number) from the header of the user data packet to an application identity and provides the application identity to the UE second layer.

[00143] Example 66 may include a method of example 65 where the second and the fourth UE layer are the CM layers.

[00144] Example 67 may include a method of example 66 where the fourth UE layer is the NAS layer and the indication that an application wants to transmit a user data packet is a request from the RAB manager to establish the radio bearers.

[00145] Example 68 may include a method of example 66 where the fourth UE layer is the RAB manager.

[00146] Example 69 is an apparatus of a user equipment (UE) comprising: radio frequency circuitry configured to: receive an open mobile alliance (OMA) management object (OMA-MO) comprising a plurality of application categories associated with ACDC for a network associated with the eNB; and baseband circuitry coupled to the radio frequency circuitry, the baseband circuitry configured to access an ACDC indication comprising ACDC parameters associated with a set of network conditions; access a first communication associated with a first application; process the first communication to identify a first category of the plurality of application categories, wherein the first category is associated with the first application, and wherein each category of the plurality of application categories is associated with a set of congestion control parameters based on the ACDC parameters; identify a first set of congestion control parameters associated with the first category and for performing an ACDC check based on the congestion control parameters associated with the first category; and process the first communication based on a result of the ACDC check. [00147] Example 70 is the apparatus of claim 69 further comprising: application circuitry coupled to the baseband circuitry, the application circuitry configured to execute the first application and communicate the first communication to the baseband circuitry; wherein the baseband circuitry is further configured to: establish a packet data network (PDN) connection and generating an internet protocol (IP) socket for the first application in response to the first communication comprising a request for connectivity; determine a local IP address and a local port number assigned to the first application and communicating the local IP address and the local port number for the first application; and generate a mapping table to map the local IP address and the local port number to the first application.

[00148] In various embodiments, any additional elements associated with the various embodiments described herein may be combined with elements in other embodiments in ways apparent from the detailed description provided herein.

EXAMPLE SYSTEMS AND DEVICES

[00149] FIG. 7 illustrates aspects of a computing machine, according to some example embodiments. Embodiments described herein may be implemented into a system 700 using any suitably configured hardware and/or software. FIG. 7 illustrates, for some embodiments, an example system 700 comprising RF circuitry 735, baseband circuitry 730, application circuitry 725, memory/storage 740, a display 705, a camera 720, a sensor 715, and an input/output (I/O) interface 710, coupled with each other at least as shown.

[00150] The application circuitry 725 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The processor(s) may include any combination of general-purpose processors and dedicated processors (e.g., graphics processors, application processors, etc.). The processors may be coupled with the memory/storage 740 and configured to execute instructions stored in the memory/storage 740 to enable various applications and/or operating systems running on the system 700.

[00151] The baseband circuitry 730 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The processor(s) may include a baseband processor. The baseband circuitry 730 may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 735. The radio control functions may include, but are not limited to, signal modulation, encoding, decoding, radio frequency shifting, and the like. In some embodiments, the baseband circuitry 730 may provide for communication compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry 730 may support communication with an evolved universal terrestrial radio access network (EUTRAN), other wireless metropolitan area networks (WMANs), a WLAN, or a wireless personal area network (WPAN). Embodiments in which the baseband circuitry 730 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.

[00152] In various embodiments, the baseband circuitry 730 may include circuitry to operate with signals that are not strictly considered as being in a baseband frequency. For example, in some embodiments, the baseband circuitry 730 may include circuitry to operate with signals having an intermediate frequency, which is between a baseband frequency and a radio frequency.

[00153] The RF circuitry 735 may enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuitry 735 may include switches, filters, amplifiers, and the like to facilitate the communication with the wireless network.

[00154] In various embodiments, the RF circuitry 735 may include circuitry to operate with signals that are not strictly considered as being in a radio frequency. For example, in some embodiments, the RF circuitry 735 may include circuitry to operate with signals having an intermediate frequency, which is between a baseband frequency and a radio frequency.

[00155] In various embodiments, the transmitter circuitry or receiver circuitry discussed above with respect to the UE or eNB may be embodied in whole or in part in one or more of the RF circuitry 735, the baseband circuitry 730, and/or the application circuitry 725. [00156] In some embodiments, some or all of the constituent components of a baseband processor may be used to implement aspects of any embodiment described herein. Such embodiments may be implemented by the baseband circuitry 730, the application circuitry 725, and/or the memory/storage 740 may be implemented together on a system on a chip (SOC).

[00157] The memory/storage 740 may be used to load and store data and/or instructions, for example, for the system 700. The memory/storage 740 for one embodiment may include any combination of suitable volatile memory (e.g., dynamic random access memory (DRAM)) and/or no n- volatile memory (e.g., flash memory).

[00158] In various embodiments, the I/O interface 710 may include one or more user interfaces designed to enable user interaction with the system 700 and/or peripheral component interfaces designed to enable peripheral component interaction with the system 700. User interfaces may include, but are not limited to, a physical keyboard or keypad, a touchpad, a speaker, a microphone, and so forth. Peripheral component interfaces may include, but are not limited to, a nonvolatile memory port, a universal serial bus (USB) port, an audio jack, and a power supply interface.

[00159] In various embodiments, the sensor 715 may include one or more sensing devices to determine environmental conditions and/or location information related to the system 700. In some embodiments, the sensors 715 may include, but are not limited to, a gyro sensor, an accelerometer, a proximity sensor, an ambient light sensor, and a positioning unit. The positioning unit may also be part of, or interact with, the baseband circuitry 730 and/or RF circuitry 735 to communicate with components of a positioning network (e.g., a global positioning system (GPS) satellite). In various embodiments, the display 705 may include a display (e.g., a liquid crystal display, a touch screen display, etc.).

[00160] In various embodiments, the system 700 may be a mobile computing device such as, but not limited to, a laptop computing device, a tablet computing device, a netbook, an ultrabook, a smartphone, and the like. In various embodiments, the system 700 may have more or fewer components, and/or different architectures. [00161] FIG. 8 shows an example UE, illustrated as a UE 800. The UE 800 may be an implementation of the UE 101 , the eNB 150, or any device described herein. The UE 800 can include one or more antennas 808 configured to communicate with a transmission station, such as a base station (BS), an eNB, or another type of wireless wide area network (WW AN) access point. The UE 800 can be configured to communicate using at least one wireless communication standard including 3 GPP LTE, WiMAX, High Speed Packet Access (HSPA), Bluetooth, and WiFi. The UE 800 can communicate using separate antennas for each wireless communication standard or shared antennas for multiple wireless communication standards. The UE 800 can communicate in a WLAN, a WPAN, and/or a WWAN.

[00162] FIG. 8 also shows a microphone 820 and one or more speakers 812 that can be used for audio input and output to and from the UE 800. A display screen 804 can be a liquid crystal display (LCD) screen, or another type of display screen such as an organic light emitting diode (OLED) display. The display screen 804 can be configured as a touch screen. The touch screen can use capacitive, resistive, or another type of touch screen technology. An application processor 814 and a graphics processor 818 can be coupled to an internal memory 816 to provide processing and display capabilities. A non- volatile memory port 810 can also be used to provide data I/O options to a user. The non- volatile memory port 810 can also be used to expand the memory capabilities of the UE 800. A keyboard 806 can be integrated with the UE 800 or wirelessly connected to the UE 800 to provide additional user input. A virtual keyboard can also be provided using the touch screen. A camera 822 located on the front (display screen) side or the rear side of the UE 800 can also be integrated into the housing 802 of the UE 800.

[00163] FIG. 9 is a block diagram illustrating an example computer system machine 900 upon which any one or more of the methodologies herein discussed can be run, and which may be used to implement the eNB 150, the UE 101, or any other device described herein. In various alternative embodiments, the machine operates as a standalone device or can be connected (e.g., networked) to other machines. In a networked deployment, the machine can operate in the capacity of either a server or a client machine in server-client network environments, or it can act as a peer machine in peer-to-peer (or distributed) network environments. The machine can be a personal computer (PC) that may or may not be portable (e.g., a notebook or a netbook), a tablet, a set-top box (STB), a gaming console, a Personal Digital Assistant (PDA), a mobile telephone or smartphone, a web appliance, a network router, switch, or bridge, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term "machine" shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

[00164] The example computer system machine 900 includes a processor 902 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both), a main memory 904, and a static memory 906, which communicate with each other via an interconnect 908 (e.g., a link, a bus, etc.). The computer system machine 900 can further include a video display unit 910, an

alphanumeric input device 912 (e.g., a keyboard), and a user interface (UI) navigation device 914 (e.g., a mouse). In one embodiment, the video display unit 910, input device 912, and UI navigation device 914 are a touch screen display. The computer system machine 900 can additionally include a mass storage device 916 (e.g., a drive unit), a signal generation device 918 (e.g., a speaker), an output controller 932, a power management controller 934, a network interface device 920 (which can include or operably communicate with one or more antennas 930, transceivers, or other wireless communications hardware), and one or more sensors 928, such as a GPS sensor, compass, location sensor, accelerometer, or other sensor.

[00165] The storage device 916 includes a machine-readable medium 922 on which is stored one or more sets of data structures and instructions 924 (e.g., software) embodying or utilized by any one or more of the methodologies or functions described herein. The instructions 924 can also reside, completely or at least partially, within the main memory 904, static memory 906, and/or processor 902 during execution thereof by the computer system machine 900, with the main memory 904, the static memory 906, and the processor 902 also constituting machine-readable media.

[00166] While the machine-readable medium 922 is illustrated in an example embodiment to be a single medium, the term "machine-readable medium" can include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more instructions 924. The term "machine-readable medium" shall also be taken to include any tangible medium that is capable of storing, encoding, or carrying instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure, or that is capable of storing, encoding, or carrying data structures utilized by or associated with such instructions.

[00167] The instructions 924 can further be transmitted or received over a communications network 926 using a transmission medium via the network interface device 920 utilizing any one of a number of well-known transfer protocols (e.g., hypertext transfer protocol (HTTP)). The term "transmission medium" shall be taken to include any medium that is capable of storing, encoding, or carrying instructions for execution by the machine, and includes digital or analog communications signals or other intangible media to facilitate communication of such software.

[00168] 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, CD-ROMs, hard drives, non-transitory computer readable storage media, 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. 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 RAM, Erasable Programmable Readonly Memory (EPROM), flash drive, optical drive, magnetic hard drive, or other medium for storing electronic data. The base station and mobile station may also include a transceiver module, a counter module, a processing module, and/or a clock module or timer module. One or more programs that may implement or utilize the various techniques described herein may use 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.

[00169] Various embodiments may use 3GPP LTE/LTE-A, Institute of Electrical and Electronic Engineers (IEEE) 902.11, and Bluetooth

communication standards. Various alternative embodiments may use a variety of other WW AN, WLAN, and WPAN protocols and standards in connection with the techniques described herein. These standards include, but are not limited to, other standards from 3GPP (e.g., HSPA+, UMTS), IEEE 902.16 (e.g., 902.16p), or Bluetooth (e.g., Bluetooth 8.0, or like standards defined by the

Bluetooth Special Interest Group) standards families. Other applicable network configurations can be included within the scope of the presently described communication networks. It will be understood that communications on such communication networks can be facilitated using any number of PANs, LANs, and WANs, using any combination of wired or wireless transmission mediums.

[00170] FIG. 10 illustrates, for one embodiment, example components of a UE device 1000, in accordance with some embodiments. In some

embodiments, the UE device 1000 may include application circuitry 1002, baseband circuitry 1004, RF circuitry 1006, FEM circuitry 1008, and one or more antennas 1010, coupled together at least as shown. In some embodiments, the UE device 1000 may include additional elements such as, for example, memory/storage, display, camera, sensor, and/or I/O interface.

[00171] The application circuitry 1002 may include one or more application processors. For example, the application circuitry 1002 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The processor(s) may include any combination of general-purpose processors and dedicated processors (e.g., graphics processors, application processors, etc.). The processors may be coupled with and/or may include memory/storage and may be configured to execute instructions stored in the memory/storage to enable various applications and/or operating systems to run on the system.

[00172] The baseband circuitry 1004 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry 1004 may include one or more baseband processors and/or control logic to process baseband signals received from a receive signal path of the RF circuitry 1006 and to generate baseband signals for a transmit signal path of the RF circuitry 1006. Baseband processing circuity 1004 may interface with the application circuitry 1002 for generation and processing of the baseband signals and for controlling operations of the RF circuitry 1006. For example, in some embodiments, the baseband circuitry 1004 may include a second generation (2G) baseband processor 1004a, third generation (3G) baseband processor 1004b, fourth generation (4G) baseband processor 1004c, and/or other baseband processor(s) 1004d for other existing generations, generations in development or to be developed in the future (e.g., fifth generation (5G), 6G, etc.). The baseband circuitry 1004 (e.g., one or more of baseband processors 1004a-d) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 1006. The radio control functions may include, but are not limited to, signal modulation/demodulation,

encoding/decoding, radio frequency shifting, and the like. In some

embodiments, modulation/demodulation circuitry of the baseband circuitry 1004 may include Fast-Fourier Transform (FFT), precoding, and/or constellation mapping/demapping functionality. In some embodiments, encoding/decoding circuitry of the baseband circuitry 1004 may include convolution, tail-biting convolution, turbo, Viterbi, and/or Low Density Parity Check (LDPC) encoder/decoder functionality. Embodiments of modulation/demodulation and encoder/decoder functionality are not limited to these examples and may include other suitable functionality in other embodiments.

[00173] In some embodiments, the baseband circuitry 1004 may include elements of a protocol stack such as, for example, elements of an EUTRAN protocol including, for example, physical (PHY), media access control (MAC), radio link control (RLC), packet data convergence protocol (PDCP), and/or RRC elements. A central processing unit (CPU) 1004e of the baseband circuitry 1004 may be configured to run elements of the protocol stack for signaling of the PHY, MAC, RLC, PDCP and/or RRC layers. In some embodiments, the baseband circuitry may include one or more audio digital signal processor(s) (DSP) 1004f. The audio DSP(s) 1004f may be include elements for

compression/decompression and echo cancellation and may include other suitable processing elements in other embodiments. Components of the baseband circuitry may be suitably combined in a single chip, a single chipset, or disposed on a same circuit board in some embodiments. In some embodiments, some or all of the constituent components of the baseband circuitry 1004 and the application circuitry 1002 may be implemented together such as, for example, on a SOC.

[00174] In some embodiments, the baseband circuitry 1004 may provide for communication compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry 1004 may support communication with an evolved universal terrestrial radio access network (EUTRAN) and/or other WMAN, WLAN, or WPAN. Embodiments in which the baseband circuitry 1004 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.

[00175] RF circuitry 1006 may enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuitry 1006 may include switches, filters, amplifiers, and the like to facilitate the communication with the wireless network. RF circuitry 1006 may include a receive signal path which may include circuitry to down-convert RF signals received from the FEM circuitry 1008 and provide baseband signals to the baseband circuitry 1004. RF circuitry 1006 may also include a transmit signal path which may include circuitry to up- convert baseband signals provided by the baseband circuitry 1004 and provide RF output signals to the FEM circuitry 1008 for transmission.

[00176] In some embodiments, the RF circuitry 1006 may include a receive signal path and a transmit signal path. The receive signal path of the RF circuitry 1006 may include mixer circuitry 1006a, amplifier circuitry 1006b, and filter circuitry 1006c. The transmit signal path of the RF circuitry 1006 may include filter circuitry 1006c and mixer circuitry 1006a. RF circuitry 1006 may also include synthesizer circuitry 1006d for synthesizing a frequency for use by the mixer circuitry 1006a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 1006a of the receive signal path may be configured to down-convert RF signals received from the FEM circuitry 1008 based on the synthesized frequency provided by synthesizer circuitry 1006d. The amplifier circuitry 1006b may be configured to amplify the down-converted signals, and the filter circuitry 1006c may be a low-pass filter (LPF) or band- pass filter (BPF) configured to remove unwanted signals from the down- converted signals to generate output baseband signals. Output baseband signals may be provided to the baseband circuitry 1004 for further processing. In some embodiments, the output baseband signals may be zero-frequency baseband signals, although this is not a requirement. In some embodiments, mixer circuitry 1006a of the receive signal path may comprise passive mixers, although the scope of the embodiments is not limited in this respect.

[00177] In some embodiments, the mixer circuitry 1006a of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 1006d to generate RF output signals for the FEM circuitry 1008. The baseband signals may be provided by the baseband circuitry 1004 and may be filtered by filter circuitry 1006c. The filter circuitry 1006c may include a LPF, although the scope of the embodiments is not limited in this respect.

[00178] In some embodiments, the mixer circuitry 1006a of the receive signal path and the mixer circuitry 1006a of the transmit signal path may include two or more mixers and may be arranged for quadrature down conversion and/or up conversion, respectively. In some embodiments, the mixer circuitry 1006a of the receive signal path and the mixer circuitry 1006a of the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g., Hartley image rejection). In some embodiments, the mixer circuitry 1006a of the receive signal path and the mixer circuitry 1006a may be arranged for direct down conversion and/or direct up conversion, respectively. In some embodiments, the mixer circuitry 1006a of the receive signal path and the mixer circuitry 1006a of the transmit signal path may be configured for superheterodyne operation.

[00179] In some embodiments, the output baseband signals and the input baseband signals may be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternate embodiments, the output baseband signals and the input baseband signals may be digital baseband signals. In these alternate embodiments, the RF circuitry 1006 may include analog-to-digital converter (ADC) and digital-to- analog converter (DAC) circuitry, and the baseband circuitry 1004 may include a digital baseband interface to communicate with the RF circuitry 1006.

[00180] In some dual-mode embodiments, separate circuitry including one or more integrated circuits may be provided for processing signals for each spectrum, although the scope of the embodiments is not limited in this respect.

[00181] In some embodiments, the synthesizer circuitry 1006d may be a fractional-N synthesizer or a fractional N/N+l synthesizer, although the scope of the embodiments is not limited in this respect as other types of frequency synthesizers may be suitable. For example, synthesizer circuitry 1006d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider.

[00182] The synthesizer circuitry 1006d may be configured to synthesize an output frequency for use by the mixer circuitry 1006a of the RF circuitry 1006 based on a frequency input and a divider control input. In some embodiments, the synthesizer circuitry 1006d may be a fractional N/N+l synthesizer.

[00183] In some embodiments, frequency input may be provided by a voltage controlled oscillator (VCO), although that is not a requirement. Divider control input may be provided by either the baseband circuitry 1004 or the applications processor 1002 depending on the desired output frequency. In some embodiments, a divider control input (e.g., N) may be determined from a look- up table based on a channel indicated by the applications processor 1002.

[00184] Synthesizer circuitry 1006d of the RF circuitry 1006 may include a divider, a delay-locked loop (DLL), a multiplexer and a phase accumulator. In some embodiments, the divider may be a dual modulus divider (DMD) and the phase accumulator may be a digital phase accumulator (DPA). In some embodiments, the DMD may be configured to divide the input signal by either N or N+1 (e.g., based on a carry out) to provide a fractional division ratio. In some example embodiments, the DLL may include a set of cascaded, tunable, delay elements, a phase detector, a charge pump, and a D-type flip-flop. In these embodiments, the delay elements may be configured to break a VCO period up into Nd equal packets of phase, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

[00185] In some embodiments, synthesizer circuitry 1006d may be configured to generate a carrier frequency as the output frequency, while in other embodiments, the output frequency may be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used in conjunction with quadrature generator and divider circuitry to generate multiple signals at the carrier frequency with multiple different phases with respect to each other. In some embodiments, the output frequency may be a LO frequency (fLO). In some embodiments, the RF circuitry 1006 may include a polar converter.

[00186] FEM circuitry 1008 may include a receive signal path, which may include circuitry configured to operate on RF signals received from one or more antennas 1010, amplify the received signals, and provide the amplified versions of the received signals to the RF circuitry 1006 for further processing. FEM circuitry 1008 may also include a transmit signal path, which may include circuitry configured to amplify signals for transmission provided by the RF circuitry 1006 for transmission by one or more of the one or more antennas 1010.

[00187] In some embodiments, the FEM circuitry 1008 may include a

TX/RX switch to switch between transmit mode and receive mode operation. The FEM circuitry may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry may include a low-noise amplifier (LNA) to amplify received RF signals and provide the amplified received RF signals as an output (e.g., to the RF circuitry 1006). The transmit signal path of the FEM circuitry 1008 may include a power amplifier (PA) to amplify input RF signals (e.g., provided by RF circuitry 1006), and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas 1010).

[00188] In some embodiments, the UE 1000 comprises a plurality of power saving mechanisms. If the UE 1000 is in an RRC_Connected state, where it is still connected to the eNB because it expects to receive traffic shortly, then it may enter a state known as Discontinuous Reception Mode (DRX) after a period of inactivity. During this state, the device may power down for brief intervals of time and thus save power.

[00189] If there is no data traffic activity for an extended period of time, then the UE 1000 may transition off to an RRC_Idle state, where it disconnects from the network and does not perform operations such as channel quality feedback, handover, and the like. The UE 1000 goes into a very low power state and it performs paging where it periodically wakes up to listen to the network and then powers down again. The device cannot receive data in this state; in order to receive data, the device transitions back to an RRC_Connected state.

[00190] An additional power saving mode may allow a device to be unavailable to the network for periods longer than a paging interval (ranging from seconds to a few hours). During this time, the device is totally unreachable to the network and may power down completely. Any data sent during this time incurs a large delay and it is assumed the delay is acceptable.

[00191] The embodiments described above can be implemented in one or a combination of hardware, firmware, and software. Various methods or techniques, or certain aspects or portions thereof, can take the form of program code (i.e., instructions) embodied in tangible media, such as flash memory, hard drives, portable storage devices, read-only memory (ROM), RAM,

semiconductor memory devices (e.g., EPROM, Electrically Erasable

Programmable Read-Only Memory (EEPROM)), magnetic disk storage media, optical storage media, and any other machine-readable storage medium or storage device wherein, when the program code is loaded into and executed by a machine, such as a computer or networking device, the machine becomes an apparatus for practicing the various techniques. [00192] It should be understood that the functional units or capabilities described in this specification may have been referred to or labeled as components or modules in order to more particularly emphasize their implementation independence. For example, a component or module can 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 component or module can also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, or the like. Components or modules can also be implemented in software for execution by various types of processors. An identified component or module of executable code can, for instance, comprise one or more physical or logical blocks of computer instructions, which can, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified component or module need not be physically located together, but can comprise disparate instructions stored in different locations which, when joined logically together, comprise the component or module and achieve the stated purpose for the component or module.

[00193] Indeed, a component or module of executable code can be a single instruction, or many instructions, and can even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data can be identified and illustrated herein within components or modules, and can be embodied in any suitable form and organized within any suitable type of data structure. The operational data can be collected as a single data set, or can be distributed over different locations including over different storage devices, and can exist, at least partially, merely as electronic signals on a system or network. The components or modules can be passive or active, including agents operable to perform desired functions.