Systems and methods for addressing priority service congestion

Abstract

Techniques for congestion management within a communication network are provided. In one embodiment, a wireless transmit / receive unit (WTRU) includes a radio resource control (RRC) layer and a non-access stratum (NAS) layer. The RRC layer receives an indication for a service from the NAS. The indication is interpreted as a request for the indicated specific service. The indicated service corresponds to at least one of mobile-originated (MO) voice communications, circuit-switched fallback (CSFB) supplementary services (SS), or MO short message service (SMS), and the RRC layer receives a signal from the network indicating that one or more services provided by the network may be enabled. If the service is one of the one or more enabled services, the RRC layer sends a connection request to the network for the service requested by the NAS.

Description

Technical Field

[0001] The present invention relates to wireless communication.

[0002] Cross - reference to related applications This application claims the benefit of U.S. Provisional Patent Application No. 61 / 897,810, filed October 30, 2013, entitled "SYSTEM AND METHODS FOR HANDLING PRIORITY SERVICES CONGESTION", which is hereby incorporated by reference in its entirety for all purposes.

Background Art

[0003] Networks based on 3GPP may encounter congestion, including congestion corresponding to communication traffic associated with services and / or procedures, among several communication networks. A number of network devices (e.g., cellular smartphones operating in an even higher - density network), and the corresponding network traffic they generate can also contribute to communication network congestion. For example, video streaming, small data transmission, voice transmission, and / or multimedia transmission, and / or the like, as well as network services that support such transmissions can all contribute to network congestion. Important transmissions (e.g., emergency transmissions) may be adversely affected by those that can be severe competitors for transmission resources and / or services within a congested network.

Summary of the Invention

[0004] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features and / or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0005] Systems, methods, and means are provided for congestion management within a network. A wireless transmit / receive unit (WTRU) may set a unique establishment cause, or a unique service indication, to differentiate services. The service may be one of a mobile originated (MO) voice communication, an MO circuit switched fallback (CSFB) voice, a CSFB supplementary service (SS), or an MO short message service (SMS). The WTRU may transmit a service request message to a base station, the service request message comprising a request for a connection to the service. The WTRU may receive a response message in response to the service request. The response message indicates an acceptance or rejection of the request for a connection to the service.

[0006] Embodiments contemplate one or more techniques for a wireless transmit / receive unit (WTRU) that may be in communication with a communication network and / or may include a radio resource control (RRC) layer. The RRC layer may receive a first message, which may include an indication of a service. The RRC layer may receive a second message, which may indicate one or more services enabled by the communication network. The service may be determined to be one of the one or more services enabled by the communication network. Based on the service being one of the one or more services enabled by the communication network, the RRC layer may transmit a connection request for the service.

[0007] Embodiments contemplate one or more techniques for a wireless transmit / receive unit (WTRU) that may be in communication with a communication network and / or may include a Radio Resource Control (RRC) layer. The RRC layer may receive a first message, which may include an indication of a service. The RRC layer may receive a second message, which may indicate one or more services that may be enabled by the communication network. The service may be determined not to be one of the one or more services that may be enabled by the communication network. The RRC layer may refrain from transmitting a connection request for the service based on the service not being one of the one or more services that may be enabled by the communication network.

Brief Description of the Drawings

[0008] A detailed description of example embodiments follows, with reference to the accompanying drawings. For purposes of illustration, the drawings show example embodiments. The contemplated subject matter is not limited to the specific elements and / or means illustrated or described. And, absent specific note to the contrary, no subject matter is intended to be required and / or essential. Additionally, the described embodiments may be used in any combination, in whole or in part.

Figure 1A

Figure 1B

Figure 1C

Figure 1D

Figure 1E

Figure 2

Figure 3

[0009] The detailed description of the exemplary embodiments will be described with reference to the various figures. This description provides detailed examples of possible implementations, but it should be noted that the details are examples and are not intended to limit the scope of the present application in any way. As used herein, the articles "a" or "an" can be understood to mean, for example, "one or more" or "at least one" when there are no further conditions or characterizations. Further, as used herein, the term user equipment (UE) can be understood to mean the same as the term wireless transmit / receive unit (WTRU).

[0010] FIG. 1A is a diagram of an exemplary communication system 100 in which one or more of the disclosed embodiments can be implemented. The communication system 100 can be a multi-connection system that provides content such as voice, data, video, messaging, broadcasting, etc. to a plurality of wireless users. The communication system 100 enables a plurality of wireless users to access such content through sharing of system resources including wireless bandwidth. For example, the communication system 100 can utilize one or more channel access methods such as CDMA, TDMA, FDMA, orthogonal FDMA (OFDMA), and single-carrier FDMA (SC-FDMA).

[0011] As shown in Figure 1A, the communication system 100 can include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, and / or 102d (which may generally or collectively be referred to as WTRU 102), radio access networks (RANs) 103 / 104 / 105, core networks 106 / 107 / 109, public switched telephone network (PSTN) 108, Internet 110, and other networks 112. However, it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a wireless environment. For example, the WTRUs 102a, 102b, 102c, 102d can be configured to transmit and / or receive wireless signals and can include user equipment (UE), mobile stations, fixed or mobile subscriber units, pagers, cellular telephones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, and home appliances, among others.

[0012] The communication system 100 can also include base stations 114a and base station 114b. Each of the base stations 114a, 114b can be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks such as core networks 106 / 107 / 109, Internet 110, and / or network 112. For example, the base stations 114a, 114b can be base transceiver stations (BTSs), Node Bs, eNode Bs, home Node Bs, home eNode Bs, site controllers, access points (APs), and wireless routers, among others. Although each of the base stations 114a, 114b is shown as a single element, it will be understood that the base stations 114a, 114b can include any number of interconnected base stations and / or network elements.

[0013] The base station 114a can be part of the RAN 103 / 104 / 105, and the RAN 103 / 104 / 105 can also include other base stations and / or network elements (not shown) such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. The base station 114a and / or the base station 114b can be configured to transmit and / or receive radio signals within a specific geographical area, which can be called a cell (not shown). The cell can be further divided into cell sectors. For example, the cell associated with the base station 114a can be divided into three sectors. Thus, in one embodiment, the base station 114a can include three transceivers, i.e., one for each sector of the cell. In another embodiment, the base station 114a can utilize MIMO technology and thus can utilize multiple transceivers for each sector of the cell.

[0014] The base stations 114a, 114b can communicate with one or more of the WTRUs 102a, 102b, 102c, 102d via the air interfaces 115 / 116 / 117, and the air interfaces 115 / 116 / 117 can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interfaces 115 / 116 / 117 can be established using any suitable radio access technology (RAT).

[0015] More specifically, as described above, the communication system 100 can be a multi-connection system and can utilize one or more channel access methods such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA. For example, the base stations 114a within RAN103 / 104 / 105 and the WTRUs 102a, 102b, 102c can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA) that can establish air interfaces 115 / 116 / 117 using Wideband CDMA (WCDMA (registered trademark)). WCDMA can include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed Downlink Packet Access (HSDPA) and / or High-Speed Uplink Packet Access (HSUPA).

[0016] In another embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA) that can establish air interfaces 115 / 116 / 117 using LTE (Long Term Evolution) and / or LTE-Advanced (LTE-A).

[0017] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c can implement radio technologies such as IEEE 802.16 (i.e., WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM (registered trademark)), GSM Enhanced Data Rates for GSM Evolution (EDGE), and GSM EDGE (GERAN).

[0018] The base station 114b in Fig. 1A can be, for example, a wireless router, a home Node B, a home eNode B or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in local areas such as workplaces, homes, vehicles and campuses. In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a wireless technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d can implement a wireless technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a pico cell or a femto cell. As shown in Fig. 1A, the base station 114b can have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the core network 106 / 107 / 109.

[0019] RAN 103 / 104 / 105 can communicate with core networks 106 / 107 / 109, which can be any type of network configured to provide voice, data, applications, and / or VoIP (Voice over IP) services to one or more of WTRUs 102a, 102b, 102c, 102d. For example, core networks 106 / 107 / 109 can provide call control, billing services, mobile location information services, prepaid calls, Internet connectivity, video distribution, etc., and / or can perform high-level security functions such as user authentication. Although not shown in Figure 1A, it will be understood that RAN 103 / 104 / 105 and / or core networks 106 / 107 / 109 can communicate directly or indirectly with other RANs that utilize the same RAT or a different RAT as RAN 103 / 104 / 105. For example, in addition to being connected to RAN 103 / 104 / 105 that utilizes E-UTRA radio technology, core networks 106 / 107 / 109 can also communicate with another RAN (not shown) that utilizes GSM radio technology.

[0020] The core networks 106 / 107 / 109 can also serve as gateways for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 can include a circuit-switched telephone network that provides POTS (plain old telephone service). The Internet 110 can include a global system of interconnected computer networks and devices that use common communication protocols such as TCP, UDP, and IP within the TCP / IP Internet protocol suite. The network 112 can include a wired or wireless communication network owned and / or operated by another service provider. For example, the network 112 can include another core network connected to one or more RANs that can utilize the same RAT or a different RAT as the RANs 103 / 104 / 105.

[0021] Some or all of the WTRUs 102a, 102b, 102c, 102d within the communication system 100 can include a multimode function, i.e., the WTRUs 102a, 102b, 102c, 102d can include multiple transceivers for communicating with different wireless networks via different wireless links. For example, the WTRU 102c shown in Figure 1A can be configured to communicate with a base station 114a that can utilize cellular-based wireless technology and with a base station 114b that can utilize IEEE802 wireless technology.

[0022] Figure 1B is a system diagram of an exemplary WTRU 102. As shown in Figure 1B, the WTRU 102 can include a processor 118, a transceiver 120, a transceiver element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, a non-removable memory 130, a removable memory 132, a power supply 134, a GPS chipset 136, and other peripheral devices 138. It will be understood that the WTRU 102 can include any sub-combination of the above elements while maintaining consistency with one embodiment. Also, embodiments contemplate that nodes represented by base stations 114a, 114b, and / or, without limitation, base transceiver stations (BTSs), Node-Bs, site controllers, access points (APs), home Node-Bs, evolved home Node-Bs (eNodeBs), home evolved Node-B gateways, proxy nodes, etc., can include some or all of the elements illustrated in Figure 1B and described herein.

[0023] The processor 118 can be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors cooperating with a DSP core, a controller, a microcontroller, an ASIC, an FPGA circuit, any other type of integrated circuit (IC), and a state machine, etc. The processor 118 can perform signal encoding, data processing, power control, input / output processing, and / or any other function that enables the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to the transceiver 120, and the transceiver 120 can be coupled to the transceiver element 122. Although Figure 1B shows the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 can be integrated together in an electronic package or chip.

[0024] The transceiver element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via the air interfaces 115 / 116 / 117. For example, in one embodiment, the transceiver element 122 can be an antenna configured to transmit and / or receive RF signals. In another embodiment, the transceiver element 122 can be a radiator / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, the transceiver element 122 can be configured to transmit and receive both RF signals and optical signals. It will be understood that the transceiver element 122 can be configured to transmit and / or receive any combination of wireless signals.

[0025] Also, although the transceiver element 122 is shown as a single element in FIG. 1B, the WTRU 102 can include any number of transceiver elements 122. More specifically, the WTRU 102 can utilize MIMO technology. Thus, in one embodiment, the WTRU 102 can include two or more transceiver elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via the air interfaces 115 / 116 / 117.

[0026] The transceiver 120 can be configured to modulate the signals transmitted by the transceiver element 122 and demodulate the signals received by the transceiver element 122. As described above, the WTRU 102 can have a multi-mode function. Thus, the transceiver 120 can include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs such as, for example, UTRA and IEEE 802.11.

[0027] The processor 118 of the WTRU 102 can be coupled to and receive user input data from a speaker / microphone 124, keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit). The processor 118 can also output user data to the speaker / microphone 124, keypad 126, and / or the display / touchpad 128. Further, the processor 118 can obtain information from and store data in any type of suitable memory, such as a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 can include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 can include a subscriber identity module (SIM) card, a memory stick, and a secure digital (SD) memory card, among others. In other embodiments, the processor 118 can obtain information from and store data in a memory on a server or a home computer (not shown), etc., that is not physically located on the WTRU 102.

[0028] The processor 118 can receive power from a power source 134 and can be configured to distribute and / or control the power to other components within the WTRU 102. The power source 134 can be any suitable device for powering the WTRU 102. For example, the power source 134 can include one or more dry cells (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium ion (Li-ion), etc.), a solar cell, and a fuel cell, among others.

[0029] Processor 118 can also be coupled to a GPS chipset 136, which can be configured to provide location information (e.g., longitude and latitude) regarding the current location of WTRU 102. In addition to, or instead of, information from the GPS chipset 136, WTRU 102 can receive location information from a base station (e.g., base stations 114a, 114b) via an air interface 115 / 116 / 117, and / or can determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that WTRU 102 can obtain location information using any suitable location determination method while maintaining consistency with one embodiment.

[0030] Processor 118 can further be coupled to other peripheral devices 138, which can include one or more software modules and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripheral devices 138 can include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photos or video), a Universal Serial Bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a Frequency Modulation (FM) radio unit, a digital music player, a media player, a video game player module, and an Internet browser, among others.

[0031] Figure 1C is a system diagram of RAN 103 and core network 106 according to one embodiment. As described above, RAN 103 can communicate with WTRUs 102a, 102b, 102c via air interface 115 using UTRA radio technology. RAN 103 can also communicate with core network 106a. As shown in Figure 1C, RAN 103 can include Node Bs 140a, 140b, 140c, and each of Node Bs 140a, 140b, 140c can include one or more transceivers for communicating with WTRUs 102a, 102b, 102c via air interface 115. Each of Node Bs 140a, 140b, 140c can be associated with a specific cell (not shown) within RAN 103. RAN 103 can also include RNCs 142a, 142b. It will be understood that RAN 103 can include any number of Node Bs and RNCs while maintaining consistency with one embodiment.

[0032] As shown in Figure 1C, Node Bs 140a, 140b can communicate with RNC 142a. Also, Node B 140c can communicate with RNC 142b. Node Bs 140a, 140b, 140c can communicate with their respective RNCs 142a, 142b via the Iub interface. RNCs 142a, 142b can communicate with each other via the Iur interface. Each of RNCs 142a, 142b can be configured to control their respective connected Node Bs 140a, 140b, 140c. Also, each of RNCs 142a, 142b can be configured to perform or support other functions such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, and data encryption.

[0033] The core network 106 shown in FIG. 1C can include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and / or a gateway GPRS support node (GGSN) 150. Although each of the above elements is shown as part of the core network 106a, it will be understood that any of these elements can be owned and / or operated by an entity different from the core network operator.

[0034] The RNC 142a within the RAN 103 can be connected to the MSC 146 within the core network 106 via the IuCS interface. The MSC 146 can be connected to the MGW 144. The MSC 146 and the MGW 144 can provide access to a circuit-switched network such as the PSTN 108 to the WTRUs 102a, 102b, 102c, and facilitate communication between the WTRUs 102a, 102b, 102c and conventional landline communication devices.

[0035] The RNC 142a within the RAN 103 can also be connected to the SGSN 148 within the core network 106 via the IuPS interface. The SGSN 148 can be connected to the GGSN 150. The SGSN 148 and the GGSN 150 can provide access to a packet-switched network such as the Internet 110 to the WTRUs 102a, 102b, 102c, and facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0036] As described above, the core network 106 can also be connected to a network 112, which can include other wired or wireless networks owned and / or operated by other service providers.

[0037] Figure 1D is a system diagram of RAN 104 and core network 107 according to one embodiment. As described above, RAN 104 can utilize E-UTRA radio technology to communicate with WTRUs 102a, 102b, 102c via air interface 116. RAN 104 can also communicate with core network 107.

[0038] RAN 104 can include eNodeBs 160a, 160b, 160c, although it will be understood that RAN 104 can include any number of eNodeBs while maintaining consistency with one embodiment. Each of eNodeBs 160a, 160b, 160c can include one or more transceivers for communicating with WTRUs 102a, 102b, 102c via air interface 116. In one embodiment, eNodeBs 160a, 160b, 160c are capable of implementing MIMO technology. Thus, eNodeB 160a, for example, can use multiple antennas to transmit and receive radio signals with WTRU 102a.

[0039] Each of eNodeBs 160a, 160b, 160c is associated with a particular cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, and user scheduling in the uplink and / or downlink, etc. As shown in Figure 1D, eNodeBs 160a, 160b, 160c can communicate with each other via the X2 interface.

[0040] The core network (CN) 107 shown in Figure 1D can include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. Each of the above elements is shown as part of core network 107, although it will be understood that any of these elements can be owned and / or operated by an entity different from the core network operator.

[0041] The MME 162 can be connected to each of the eNodeBs 160a, 160b, 160c within the RAN 104 via the S1 interface and can serve as a control node. For example, the MME 162 can be responsible for user authentication of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selection of a specific serving gateway during the initial connection of the WTRUs 102a, 102b, 102c, etc. The MME 162 can also provide control plane functions for switching between the RAN 104 and other RANs (not shown) that utilize other radio technologies such as GSM or WCDMA.

[0042] The serving gateway 164 can be connected to each of the eNodeBs 160a, 160b, 160c within the RAN 104 via the S1 interface. The serving gateway 164 can generally route and transfer user data packets to / from the WTRUs 102a, 102b, 102c. The serving gateway 164 can also perform other functions such as user plane anchoring during handover between eNodeBs, triggering paging when downlink data is available to the WTRUs 102a, 102b, 102c, and management and storage of the contexts of the WTRUs 102a, 102b, 102c.

[0043] The serving gateway 164 can also be connected to the PDN gateway 166, which can provide access to a packet switched network such as the Internet 110 to the WTRUs 102a, 102b, 102c and can facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0044] The core network 107 can facilitate communication with other networks. For example, the core network 107 can provide access to a circuit-switched network such as the PSTN 108 to the WTRUs 102a, 102b, 102c, and can facilitate communication between the WTRUs 102a, 102b, 102c and conventional landline communication devices. For example, the core network 107 can include, or communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. Also, the core network 107 can provide access to the network 112 to the WTRUs 102a, 102b, 102c, and the network 112 can include other wired or wireless networks owned and / or operated by other service providers.

[0045] Figure 1E is a system diagram of the RAN 105 and the core network 109 according to one embodiment. The RAN 105 can be an access service network (ASN) that communicates with the WTRUs 102a, 102b, 102c via the air interface 117 using IEEE 802.16 wireless technology. As will be further described below, the communication links between the different functional entities of the WTRUs 102a, 102b, 102c, the RAN 105, and the core network 109 can be defined as reference points.

[0046] As shown in FIG. 1E, RAN 105 can include base stations 180a, 180b, 180c and an ASN gateway 182, although it will be understood that RAN 105 can include any number of base stations and ASN gateways while maintaining consistency with one embodiment. Base stations 180a, 180b, 180c are each associated with a specific cell (not shown) within RAN 105 and can each include one or more transceivers for communicating with WTRUs 102a, 102b, 102c via air interface 117. In one embodiment, base stations 180a, 180b, 180c can implement MIMO technology. Thus, base station 180a, for example, can transmit and receive radio signals to and from WTRU 102a using multiple antennas. Base stations 180a, 180b, 180c can also provide mobility management functions such as handoff triggering, tunnel establishment, radio resource management, traffic classification, and quality of service (QoS) policy enforcement. ASN gateway 182 can serve as a traffic aggregation point and can be responsible for paging, caching of subscriber profiles, routing to core network 109, etc.

[0047] Air interface 117 between WTRUs 102a, 102b, 102c and RAN 105 can be defined as an R1 reference point implementing the IEEE 802.16 specification. Also, each of WTRUs 102a, 102b, 102c can establish a logical interface (not shown) with core network 109. The logical interface between WTRUs 102a, 102b, 102c and core network 109 can be defined as an R2 reference point, and the R2 reference point can be used for authentication, authorization, IP host configuration management, and / or mobility management.

[0048] The communication links between each of the base stations 180a, 180b, and 180c can be defined as R8 reference points, including protocols for facilitating WTRU handover and data transfer between base stations. The communication links between the base stations 180a, 180b, 180c and the ASN gateway 182 can be defined as R6 reference points. The R6 reference point can include a protocol for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.

[0049] As shown in Figure 1E, the RAN 105 can be connected to the core network 109. The communication link between the RAN 105 and the core network 109 can be defined as an R3 reference point, including, for example, a protocol for facilitating data transfer and mobility management functions. The core network 109 can include a Mobile IP Home Agent (MIP-HA) 184, an Authentication Authorization Accounting (AAA) server 186, and a gateway 188. Although each of the above elements is shown as part of the core network 109, it will be understood that any of these elements can be owned and / or operated by an entity different from the core network operator.

[0050] MIP-HA can be responsible for IP address management, enabling the WTRU102a, 102b, 102c to roam between different ASNs and / or between different core networks. The MIP-HA 184 can provide access to a packet switched network such as the Internet 110 to the WTRU102a, 102b, 102c, and can smooth the communication between the WTRU102a, 102b, 102c and IP-enabled devices. The AAA server 186 can be responsible for user authentication and user service support. The gateway 188 can smooth the interconnection with other networks. For example, the gateway 188 can provide access to a circuit switched network such as the PSTN 108 to the WTRU102a, 102b, 102c, and can smooth the communication between the WTRU102a, 102b, 102c and traditional landline communication devices. Also, the gateway 188 can provide access to the network 112 to the WTRU102a, 102b, 102c, and the network 112 can include other wired or wireless networks owned and / or operated by other service providers.

[0051] Although not shown in Figure 1E, it will be understood that the RAN 105 can be connected to other ASNs and the core network 109 can be connected to other core networks. The communication link between the RAN 105 and other ASNs can be defined as the R4 reference point, and the R4 reference point can include a protocol for coordinating the mobility of the WTRU102a, 102b, 102c between the RAN 105 and other ASNs. The communication link between the core network 109 and other core networks is defined as the R5 reference point, and the R5 reference point can include a protocol for smoothing the interconnection between the home core network and the visited core network.

[0052] In a network based on 3GPP, for example, congestion mitigation and / or service prioritization may be provided. In some cases, some services / procedures may have a lower priority or may not be possible at all, while other services may be given a higher priority. However, an evolved Node B (eNB) may not be able to distinguish a Radio Resource Control (RRC) connection request that includes a request for a service that may have a lower priority (or may not be possible at all depending on the case) from one that may have a higher priority. Embodiments contemplate that it may be useful to distinguish Radio Resource Control (RRC) connection requests for various types of services at the eNB.

[0053] Considerations for congestion mitigation and / or service prioritization within a mobile network (e.g., a 3GPP-based mobile network) may be provided. In some cases, one or more services and / or procedures may not be possible within the system (e.g., signaling that is mobile originated for user data) or may be given a lower priority, while other services may be given a higher priority (e.g., emergency services over the packet switched (PS) or circuit switched (CS) domain). One or more regulatory mechanisms may be provided, such as access class barring (ACB), service specific access barring (SSAB) (e.g., to achieve reduction of circuit switched fallback (CSFB) requests), and / or extended access barring (EAB) (e.g., to reduce the number of access attempts made by a device considered to be a low access priority device (LAPD)).

[0054] Congestion and / or prioritization of the use of one or more services may be provided. For example, MO voice communication requests, IMS voice or CSFB requests, etc. may be prioritized higher and above other IP data (e.g., video streams and / or browsing data). Congestion mitigation mechanisms in RRC_IDLE and RRC_CONNECTED may be improved to provide, for example, prioritization of mobile originating access during congestion (e.g., emergency access, high-priority access, etc.). Prioritization of mobile originating access (e.g., access for starting voice services such as MO voice communication, MMTEL voice calls, and / or CSFB voice calls) may be provided during congestion, for example, according to the operator's policy and / or other scenarios.

[0055] A wireless transmit / receive unit (WTRU) within an LTE network may have access to CS services such as SMS and / or CS voice calls, and / or supplementary services (SS). The SMS service may be provided as native using NAS signaling. For example, an SMS message may be transmitted by an LTE NAS message that acts as a carrier for the message. A CS voice call may be made available by CSFB, and for example, in that CSFB the WTRU may request to perform an inter-system change (e.g., using a NAS extended service request (ESR) message). In some embodiments, the CS voice call may be placed within GERAN / UTRAN, depending, for example, after an inter-system change. The WTRU may not be able to receive services, depending, for example, when the WTRU is in idle mode and / or when the WTRU is not in connected mode. The WTRU may establish an RRC connection, and for that RRC connection, an establishment cause may be passed to the eNB, and for example, thereby the eNB may know the reason for the connection request and / or be able to act based on it (e.g., accept or reject the request). The establishment cause that the WTRU may use may correspond to a procedure (e.g., the service indicated) that the WTRU may be requesting. The NAS layer may verify the establishment cause (or the service indicated) and / or the corresponding procedure. The NAS layer may pass the establishment cause or service indication to the RRC layer. Table 1 exemplifies establishment causes that may be used when a service request / service indication is triggered. The WTRU may transition to connected mode, for example, for a service request trigger, depending, for example, to send an SMS, request CSFB, and / or request the use of resources for IP data, etc.

[0056]

Table 1

[0057] Some embodiments recognize that the eNB may not distinguish between requests from a WTRU for SMS and IP data. As illustrated in Table 1, for example, a WTRU (e.g., NAS) may set a service indication or establishment cause in the MO data if, according to some cases, the service request procedure can be initiated for CSFB, SMS transmission, and / or user plane resources. Some embodiments recognize that the eNB may not distinguish between RRC connection requests and may not be able to apply appropriate regulation and / or prioritization mechanisms. To enhance system performance, reduce congestion, and / or prioritize one or more services (e.g., MO voice communication) upward, embodiments contemplate that it may be useful to distinguish requests at the eNB such that the requests can be handled based on the congestion level on the system and / or eNB in some scenarios. For example, the eNB may be configured to enable an MO voice call, while SMS may not be possible (or may be provided with a relatively lower priority than an MO voice call) during times of (e.g., relatively high) congestion, as SMS is, according to some reasons, a non-real-time service among others.

[0058] One or more WTRUs may be provided with one or more regulatory mechanisms that can limit, for example, according to certain (e.g., as described herein), a certain configuration for accessing a system for a certain service. Embodiments contemplate that it may be useful to optimize the regulatory mechanisms. For example, CSFB may be used for voice calls and supplementary services (SS). Voice calls may be more important than SS. From the perspective of the WTRU and / or the network (e.g., eNB), the actual reasons (e.g., voice calls or SS) for performing CSFB may be transparent. Embodiments recognize that the defined access class barring (ACB) mechanism may not distinguish between regulations for CSFB due to voice calls or due to SS. For a WTRU in idle mode, embodiments recognize that the access control mechanism may not distinguish between voice or video (e.g., IP multimedia system (IMS) voice or video) access and other data. Voice may not be prioritized upward, for example, when transitioning from the RRC idle state to the RRC connected state.

[0059] The network may use service specific access control (SSAC) to suppress and / or prioritize downward mobile originated (MO) access for MMTEL voice and MMTEL video in RRC connection establishment. The network may make other MO access in congestion impossible without using SSAC, while making MO access for MMTEL voice and MMTEL video possible. Voice over LTE (VoLTE) calls may suffer from double regulation. For example, a VoLTE call may be regulated by SSAC and again by regular ACB. Even if a WTRU requiring VoLTE passes the SSAC test at the IMS level, it may still undergo the legacy ACB test at RRC, which it may or may not pass. Normal data access may not be controlled by ACB, for example, without affecting voice calls. Such access control mechanisms may be in a state of conflict with mechanisms where VoLTE traffic may have a higher priority than, for example, background traffic. The lack of ability to distinguish between requests for SMS and IP data, and the inadequate regulation mechanisms may result in an increase in the number of attempts for RRC connection establishment. An increase in the number of attempts for RRC connection establishment may degrade the system, although this is not limited to congestion, for example, when a smaller number of services may be made possible by the network.

[0060] Access control based on a Quality of Service (QoS) Class Identifier (QCI) may be provided. The access control may be applied and / or enforced by one or more QoS mechanisms, such as the QCI. The WTRU may be aware of one or more of the bearers that the WTRU may have, or the QCI for each. The eNB may be capable of signaling QCI bearers that may be usefully prioritized upwards, whereby on the one hand, other bearers may be backed off or assigned a lower priority. Such prioritization of QCI bearers may cause the WTRU to transmit packets on a particular bearer that may be prioritized upwards, while backing off system access requests for data on other bearers. Embodiments contemplate one or more techniques for the network and / or eNB to indicate that congestion exists within the network and / or whereby a voice or certain QCI may be usefully prioritized upwards.

[0061] Embodiments recognize that the WTRU may have multiple access control mechanisms in different layers, such as the AS, NAS, and IMS applications. Embodiments contemplate one or more techniques such that these mechanisms may operate in parallel with the QCI access control mechanism, for example, without causing any conflicts.

[0062] Embodiments recognize that in certain scenarios, such as during an emergency, it may be useful for the WTRU to prioritize the bearer that carries voice packets above other bearers, instead of activating the eNB's access control based on the QCI. Embodiments contemplate one or more techniques for the WTRU to request such QCI-level prioritization and / or how the network / eNB may process such requests from the WTRU.

[0063] A cause for establishment and / or a service indication may be provided for each service type. The cause for establishment (or service indication) may distinguish between Mobile Originated (MO) requests sent to the SMS over mobile, MO voice communications, CSFB for voice calls, and / or CSFB for SS. Such a cause for establishment or service indication may apply to GERAN / UTRAN. For example, in UTRAN, the WTRU may use a unique cause for establishment or service indication for voice calls, SMS, and / or SS. The WTRU (e.g., NAS) may set the service indication or cause for establishment to MO voice communications and / or MO CSFB voice when initiating a service request procedure for, e.g., MO voice communications and / or MO CSFB for voice calls. The WTRU (e.g., NAS) may set the service indication or cause for establishment to CSFB SS when initiating a service request procedure for CSFB for SS. The WTRU (e.g., NAS) may set the service indication or cause for establishment to MO SMS (or MT SMS for mobile-terminated SMS) when initiating a service request procedure for (or for) MO SMS. The WTRU RRC layer may send a request for the indicated service to the network / eNB. In some embodiments, the RRC request may include a service indication as part of the cause for establishment for the service.

[0064] The eNB may be configured to filter RRC requests (e.g., to reject a request) based on, e.g., the requested service. The eNB may reject requests for SMS, for example. The eNB may reject a request for an RRC connection if, e.g., the cause for establishment is set to MO SMS and / or if the eNB is configured to reject requests for the SMS service.

[0065] The eNB may have a configuration (e.g., provided by operations and maintenance (O&M)), and by that, the configuration may be used to accept or reject requests. The MME may notify the eNB to reject connections for certain services such as MO SMS, MO voice communication, CSFB SS, etc. The MME may do so using defined S1AP procedures, and the MME may indicate that the service is set to a lower priority. This may be done using a bitmap that may refer to a service where the bit position is (e.g., provided / enabled by the eNB / communication network for the WTRU). The eNB may reject the RRC connection or release existing connections that may be affected, based on information received either from the MME or via the configuration, for example. S1AP procedures (e.g., S1AP overload start) may be utilized. The MME may use a mechanism to notify the eNB to stop access restrictions (e.g., accept requests) for services as described herein.

[0066] The eNB may reject the WTRU's MSG1 or MSG3, for example, during the random access channel (RACH) procedure. The eNB may include a cause code to indicate that the reason for the rejection may be a service (e.g., MO SMS). The WTRU may learn that the requested service (e.g., as indicated by the corresponding establishment cause) may not be possible based on, for example, the rejection of the connection by the eNB and / or based on the release of the RRC connection. The eNB may include a timer, and the WTRU may use that timer to back off or refrain from sending requests for this service until, for example, the timer expires and / or until an indication is received by the WTRU, e.g., by a system information block (SIB). The SIB may indicate that the service may be permitted again. The eNB may continue the request and / or forward the establishment cause to the MME. The MME may determine to reject the connection based on the service indicated or the type of service indicated. The connection rejection may be implemented at the MME. The MME may reject the NAS connection (e.g., due to service rejection) and may indicate the cause to the WTRU. The MME may indicate the cause together with a backoff timer. The backoff timer may prohibit the WTRU from sending other requests for the rejected service until the timer expires and / or until the WTRU is paged for a similar MT service. In some embodiments, the WTRU may monitor an internal timer for a backoff time or a refrain time (e.g., a regulated time) to send requests for the indicated service. The WTRU timer may be activated / started based on the rejection of the connection by the eNB, the release of the RRC connection, and / or the receipt of another signal indicating that one or more services are not permitted. The WTRU timer preset value may be statically configured and / or may be dynamically adjustable (e.g., as part of a signal indicating one or more of those services).

[0067] Referring to FIG. 2, in 2002, the WTRU 2000 can receive the SIB from the eNB 2001, and the SIB can indicate that one or more services, such as MO SMS and / or voice, etc. are possible, and / or that one or more services are not possible. In 2004, for example, the NAS can send a message to the RRC, and the message can include a service request, possibly together with a service notification or establishment cause (e.g., including a new call / service type such as MO SMS and / or MO voice call, or the like). In 2006, the WTRU 2000 can send an RRC connection request based on, for example, the information received in the SIB and / or the service request, to establish an RRC connection for the corresponding service. For example, the bit position for MO SMS can be set to a value indicating that MO SMS can be made possible (e.g., not restricted) by the eNB 2001 (and / or the communication network of which the eNB 2001 is a part) (e.g., within a bitmap). The WTRU 2000 can send an RRC connection request for MO SMS (e.g., to the eNB / network) after, for example, reading the SIB and / or the bit position. Alternatively or additionally, in 2008, the WTRU 2000 can refrain from sending an RRC connection request based on, for example, the information received in the SIB and / or the service request, to establish an RRC connection for the corresponding service. For example, the bit position for MO SMS can be set to a value indicating that MO SMS cannot be made possible (e.g., restricted) by the eNB 2001 (and / or the communication network of which the eNB 2001 is a part) (e.g., within a bitmap). The WTRU 2000 can refrain from sending an RRC connection request for MO SMS (e.g., to the eNB / network) after, for example, reading the SIB and / or the bit position. Refraining can include, for example, implementing an ACB for MO SMS, and can include restricting the MO SMS service.

[0068] More fine-grained (e.g., smaller-granularity) regulations for each service may be provided. Embodiments contemplate a finer granularity of regulating for each specific service (e.g., the regulatory mechanism may be implemented for MO voice communication, MO CSFB for voice, CSFB SS, and / or MO SMS). A bitmap (or other display) may be included in the system information block (SIB) to indicate that a service may be enabled (e.g., not regulated), and / or may not be enabled (e.g., regulated).

[0069] For example, the eNB may set the bit position to 1 for the corresponding service (e.g., using a configuration or indication from the MME as described herein). The bit position of 1 for the corresponding service may indicate that the service is enabled (e.g., not regulated) by the eNB / communication network. The WTRU may read this information from the SIB, and the WTRU may establish an RRC connection for the corresponding service (e.g., as required by another layer such as the NAS layer). For example, during (e.g., relatively low) congestion, the bit position for SMS may be set to 1, and the WTRU may send an RRC connection request for SMS after reading the SIB and / or the bit position. Embodiments contemplate that a bit value of 1 or 0 may be used to convey a service that may be enabled (e.g., not regulated), or may not be enabled (e.g., regulated), as may be most suitably configured for each operator / user device.

[0070] As a further example, a bit position of 0 for a corresponding service may indicate that the service is not enabled (e.g., is regulated) by the eNB / communication network. The WTRU may read this information from the SIB, and the WTRU may refrain from establishing an RRC connection for the corresponding service. For example, during congestion (e.g., relatively high), the bit position for SMS may be set to 0, and the WTRU may refrain from sending an RRC connection request for SMS after reading the SIB and / or the bit position. Refraining may include applying an ACB for SMS, may include regulating SMS. The RRC layer may notify the NAS layer regarding the regulation. The RRC layer may notify the NAS layer when / if the regulation ends. The NAS layer (e.g., evolved mobility management (EMM)) may notify an entity (e.g., an SMS entity) that may trigger a request that the service may be unavailable for some time, depending. The WTRU may display the corresponding message to the user.

[0071] Referring to FIG. 3, at 3002, the WTRU 3000 can receive the SIB from the eNB 3001, and the SIB can indicate that one or more services, such as MO SMS, and / or voice, etc. are possible, and / or that one or more services are not possible. At 3003, the WTRU 3000 can refrain from transmitting an RRC connection request and establishing an RRC connection for one or more services indicated as not possible, based on, for example, the information received in the SIB and / or the service request. For example, the bit position for MO SMS can be set to a value indicating that MO SMS cannot (e.g., is restricted) be made possible by the eNB 3001 (and / or the communication network of which the eNB 3001 is a part). At 3004, the RRC layer can notify the NAS layer of a service-specific ACB. The RRC layer can notify the NAS layer of when the restriction will end and / or whether it will end. At 3006, the NAS layer (e.g., EMM) can notify the entity that triggered the request (e.g., the SMS entity) that the service is unavailable (e.g., for some period of time).

[0072] The network (e.g., eNB and / or MME) can notify the WTRU that an MO request for SMS cannot be permitted for a certain duration (e.g., as configured by the network), which, for example, can increase the chance of a successful RRC connection for a voice call, reduce congestion, and / or prioritize a certain service such as a voice call (e.g., MO voice, voice communication, IMS for voice and / or CSFB, or CSFB) above others. Such permission information can reduce RRC connection requests that might otherwise be triggered for SMS, which can, for example, increase the chance of success for other services (e.g., a voice call which might be of higher priority).

[0073] One or more priority levels may be provided. For example, MT IMS and / or MO voice communication (and / or CSFB voice) may be given the highest priority (e.g., priority level 1). MO voice communication and / or MO IMS and / or CSFB voice may be given a priority lower than priority level 1 (e.g., priority level 2). MT SMS may be given a priority lower than priority level 2 (e.g., priority level 3). MO SMS may be given a priority lower than priority level 3 (e.g., priority level 4). MT SS may be given a priority lower than priority level 4 (e.g., priority level 5). MO SS may be given the lowest priority (e.g., priority level 6). The WTRU may be configured by this list of priority levels (or other similar list). The WTRU may be notified to initiate congestion control. The WTRU may use the configuration to refrain from requesting a certain service as notified by the eNB using broadcast signaling and / or as notified by the eNB and / or mobility management entity (MME) by dedicated signaling. One or more of the contemplated techniques may be used in GERAN / UTRAN. One or more of the contemplated techniques may be used by the WTRU in connected mode. One or more techniques may each be used by a base station system (BSS) / RNC for GERAN / UTRAN. The MME equivalent may be a mobile switching center (MSC) or SGSN.

[0074] Access control based on an operator policy may be provided. Access control based on an operator policy may be realized through the use of operator-specific policies and access control rules. The policies may be flow-based policies (e.g., IP flow-based policies), service-based policies (e.g., specific APNs), signaling radio bearer-based policies (e.g., signaling radio traffic filters or identifiers), data radio bearer-based policies, and / or QCI-based policies, etc. The IP flow filter may include one or more of address type, start source IP address, end destination IP address, protocol type, start source port number, end source port number, start destination port number, end destination port number, QOS, and / or application ID. The policies may be pre-configured on the WTRU and / or signaled to the WTRU, e.g., through the control plane or through the user plane. Examples of signaling by the control plane may include RRC broadcast signaling, RRC individual signaling, and / or NAS signaling, etc. An example of user plane signaling may be signaling by the S14 interface. The ANDSF policy signaling mechanism may be used. Another example of a user plane signaling mechanism may be signaling by the IMS signaling data bearer. The policies may be enumerated and / or represented in the form of a bitmap, and one or more or each element of the enumeration or bitmap refers to a specific policy definition on the WTRU. For example, different policies may be set for different categories of users (e.g., gold users vs. silver users vs. bronze users).

[0075] Policy-based access control can be achieved, for example, by an access control mechanism and / or an access priority setting mechanism. A network (e.g., an eNB and / or an MME) can signal policy-based access control information to a WTRU to activate one or more specific access control policies. A network (e.g., an eNB and / or an MME) can signal policy-based access control information to a WTRU to activate a specific access priority setting policy, or multiple policies. Policy enforcement can be performed in the access layer, for example, with respect to the execution of the ACB or EAB mechanism, such as its execution. Policy enforcement can be performed in one or more higher layers, such as a non-access layer, or at the IMS level such as SSAC. Policy enforcement can be provided in the access layer and / or a higher layer, depending, for example, on the type of traffic being access controlled. Policy definition can include a valid area definition. For example, a policy can be activated by the network and / or applied to a given subscriber if the valid area defined for the policy within the WTRU can include the subscriber's current location. A policy can include the time of day for the scope of application of the policy. For example, a policy can be activated by the network and / or applied to a given subscriber if the time of day defined for the policy within the WTRU can cover the time during which the policy can be active.

[0076] The network may configure the WTRU according to one or more policies. For example, there may be three policies P1, P2, and P3 (policy annotations used for illustrative purposes and not for limiting purposes). Policy P1 may be set for gold subscribers, policy P2 may be set for silver subscribers, and policy P3 may be set for bronze subscribers. For example, one or more of policies P1, P2, and / or P3 may include one or more traffic flow filters. Also for example, the exemplary policy P1 may include three IP flow filters (e.g., F1(P1), F2(P1), F3(P1)). Policy P2 may include three IP flow filters (e.g., F1(P2), F2(P2), F3(P2)). Policy P3 may include two IP flow filters (e.g., F1(P3), F2(P3)).

[0077] The Access Network Discovery and Selection Function (ANDSF) server may configure the WTRU with policies P1, P2, and / or P3 via the S14 interface. The eNB may configure the WTRU according to policies P1, P2, and / or P3. The eNB may use individual RRC signaling and / or RRC broadcast signaling. The RRC layer of the WTRU may transfer the policy to upper layers within the WTRU based on receiving, for example, policies P1, P2, and / or P3. The MME may signal policies P1, P2, and / or P3 to the WTRU. The NAS layer of the WTRU may transfer the policy to other entities within the upper layers of the WTRU and / or transfer them downward to the access layer within the WTRU based on receiving, for example, policies P1, P2, and / or P3.

[0078] The WTRU can be statically pre-configured by the operator with policies P1, P2, and / or P3. The pre-configured policies on the WTRU can be updated using one of the methods described herein. The functions within the WTRU that can receive the pre-configured policies P1, P2, and / or P3 can forward the policies to the NAS layer, the access layer, and / or the ANDSF client on the WTRU, or to other entities within the WTRU that can interact with access control, such as the IMS layer.

[0079] The eNB may signal a bitmap, e.g., [bit (P1)=1, bit (P2)=0, bit (P3)=0], to the WTRU. The bitmap may be signaled using RRC individual signaling and / or RRC broadcast signaling. For example, the eNB may use the bitmap to notify the WTRU that traffic matching the criteria of policy P1 (e.g., an IP flow that may be defined by policy P1) may be prioritized upward for access, while on the other hand, traffic matching the criteria of policy P2 and / or P3 may be restricted from access or may be assigned a lower relative priority than that of P1 traffic. The eNB may control the activation and / or deactivation of access control on the WTRU using an activation flag. The eNB may signal the activation flag to the WTRU using RRC individual signaling and / or RRC broadcast signaling. For example, as an optimization, the eNB may broadcast a priority factor for one or more, or each, of policies P1, P2, and / or P3, where 0≦priority factor≦1 for one or more, or each, of the policies. The network (e.g., the eNB) may use the priority factor for a given policy to control one or more WTRUs according to the given policy that may be prioritized upward for access. The eNB may broadcast a barring factor for one or more, or each, of policies P1, P2, and / or P3, where 0≦barring factor≦1 for one or more, or each, of the policies. The eNB may use the barring factor to control one or more WTRUs according to the given policy that may be restricted from access. The eNB may broadcast a barring time for one or more, or each, of policies P1, P2, and / or P3.The eNB can control how long access to the WTRU can be restricted for traffic that matches the criteria defined by the policy using the policing time for the given policy.

[0080] Other network nodes, such as the MME, can signal to the WTRU a policy bitmap, a priority factor, a policing factor, and / or a policing time. The MME can signal this information to the WTRU using, for example, NAS signaling and / or other higher layer protocol signaling. An IMS signaling node can signal information to the WTRU. A network node such as an ANDSF server can signal policy information to the WTRU.

[0081] While IP flows can be used to describe policies P1, P2, and / or P3 (as in the previous example), other parameters, such as QCI and / or APN (e.g., service-based access control), can be used to define policies P1, P2, and / or P3. For example, P1 can include one or more Internet Protocol (IP) flows with QCI1, QCI5, and / or QCI9, P2 can include one or more IP flows with QCI3 and / or QCI9, and P3 can include an IP flow with at least QCI9 or the like. The eNB can be configured by the core network with policies P1, P2, and / or P3. The eNB function can be defined, for example, to detect an IP flow filter if an IP flow can be used to describe a policy. The Quality of Service Class Identifier (QCI) number can indicate a level of priority, and in some embodiments, for example, QCI1 can be the highest priority and QCI9 can be the lowest priority.

[0082] The WTRU may perform access control using a policy-based access control bitmap, a priority factor, a regulation factor, and / or a regulation time. For example, the WTRU may receive a bitmap [bit (P1)=1, bit (P2)=0, bit (P3)=0]. The WTRU may receive an access control activation flag. The WTRU may activate access control, for example, when receiving the access control activation flag and / or the policy bitmap. The bit (P1) set to 1 may cause the WTRU to prioritize traffic data packets that match the criteria defined by policy P1. The WTRU may regulate (or set to a lower relative priority) traffic other than that corresponding to P1, for example, while access control may be active.

[0083] The WTRU may receive from the network bits corresponding to policies that are prioritized for access. The WTRU may receive from the network bits corresponding to policies that are to be used by the WTRU for access. The WTRU may receive from the network an access priority factor for one or more, or each, of policies P1, P2, and / or P3. The WTRU may extract a random number "rand", which may be uniformly distributed within the value range 0 ≦ rand < 1. The WTRU may not prioritize traffic that matches the corresponding policy for access, for example, if the random number is lower than the access priority factor received by the WTRU. The WTRU may prioritize traffic that matches the corresponding policy for access, for example, if the random number is higher than or equal to the access priority factor. In a scenario where traffic cannot be prioritized, the WTRU may regulate (or set to a lower priority) traffic for an amount of time for access, which amount of time may be determined, for example, based on the received regulation time, which may correspond to the policy being evaluated.

[0084] The WTRU may receive access control factors for access to the network for one or more, or each, of policies P1, P2, and / or P3. The WTRU may not be able to regulate (or may not be able to lower the priority of) traffic that matches a corresponding policy if, for example, a random number is lower than the access control factor received by the WTRU. The WTRU may be able to regulate (or may be able to lower the priority of) traffic that matches a corresponding policy if, for example, a random number is higher than or equal to the access control factor. For example, the WTRU may be able to regulate (or may be able to lower the priority of) traffic for an amount of time, which amount of time may be calculated based on, for example, a received regulation time corresponding to the policy being evaluated. The WTRU may be able to set the priority of traffic that matches a corresponding policy higher for access if, for example, a random number is lower than the access priority factor received by the WTRU. The WTRU may not be able to set the priority of traffic that matches a corresponding policy higher for access if, for example, a random number is higher than or equal to the access priority factor. In a scenario where traffic cannot be set to a higher priority, the WTRU may be able to regulate (or lower the priority of) traffic for an amount of time for access, which amount of time may be determined based on a received regulation time that may correspond to the policy being evaluated.

[0085] The WTRU may receive access control factors for one or more, or each, of policies P1, P2, and / or P3. The WTRU may regulate traffic matching the corresponding policy, according to, for example, if a random number is lower than the access control factor received by the WTRU. The WTRU may regulate traffic for an amount of time, which amount of time may be calculated based on, for example, a received regulation time that may correspond to the policy being evaluated. The WTRU may not regulate traffic matching the corresponding policy, according to, for example, if a random number is higher than, or equal to, the access control factor.

[0086] The execution of the policies described herein within the WTRU may be implemented in the WTRU access stratum and / or in one or more of the higher strata of the WTRU, for example, in the NAS and / or in the IMS layer.

[0087] Access regulation based on an enhanced QCI may be provided. The WTRU may, according to, for example, enable (e.g., implicitly enable) an access control mechanism based on the QCI when the network may indicate that network congestion exists. In some embodiments, there may be an explicit indication from the eNB and / or the network to enable the prioritization of one or more QCI bearers.

[0088] Among several scenarios, for example, in a scenario where the network and / or the eNB may explicitly prioritize a voice service upward, the network may indicate that a bearer with a certain QCI for voice (e.g., QCI1) may not be backed off, and according to, other bearers with other QCI values may be backed off, and / or may not be allowed to make a system access (e.g., for a certain period of time). Such embodiments may prioritize voice bearers higher than bearers including other types of traffic.

[0089] One or more types of congestion indications may be provided, sent and / or broadcast by the eNB / network. The congestion indication may enable (e.g., implicitly enable) the WTRU to prioritize a certain QCI bearer upwards. The network may broadcast the level of congestion in a SIB broadcast message. For example, the network may describe the level of congestion in an RRC information element (IE) or SIB IE (which may be set to, e.g., 1, 2, or 3). Level 1 may indicate that the network is not congested. Level 2 may indicate that the network is moderately (e.g., relatively) congested. Level 3 may indicate that the network is severely (e.g., relatively) congested. The WTRU may, for example, back off (e.g., implicitly back off) for non-voice bearers and / or may restrict access (e.g., which may include implementing ACB) and / or may request access to the network for a voice call when, for example, the WTRU can read a level 3 congestion. The WTRU may, for example, assume (e.g., implicitly) that there is a possibility that the network is congested when an RRC request for MO data is sent by the WTRU and rejected by the eNB. The WTRU may request access to the network for a voice call that may be promised by the network.

[0090] The network may indicate (e.g., explicitly) to the WTRU to prioritize one or more QCI bearers upwards. This notification may be sent in an RRC and / or SIB message with one or more QCI values with subsequent: priorities, may send an indication that voice and / or some other specific service may be prioritized upwards, and / or may be sent to the WTRU in one or more of that the eNB may grant a scheduling request for a data radio bearer (DRB) including voice packets.

[0091] A WTRU may implement one or more access control mechanisms. The access control mechanisms may enable a WTRU that is in a congested network scenario, for example, not to send unnecessary connection requests to the network that could further worsen the congestion situation in the network. In some embodiments, the network may indicate to the WTRU to use a certain mechanism at a given point in time, for example, depending on whether another mechanism may be available when access control based on QCI is activated. The WTRU may deactivate one or more of the access control mechanisms. The WTRU may maintain one or more, or each, of the access control mechanisms, for example, depending on the level of congestion.

[0092] For example, the WTRU may maintain, for example, each, or a relatively large subset, of the access control mechanisms that are activated if, for example, the network may indicate that there is level 3 congestion in the network. The WTRU may maintain, for example, applying one or more, or a smaller subset, when level 2 congestion is indicated. The network may be able to indicate to the WTRU the mechanisms that may be applied at a point in time.

[0093] The WTRU may request the network, for example, to prioritize its access to voice services or some other service when there is no congestion in the network. This may occur, for example, when the WTRU indicates to the network an emergency situation. The network may activate an access class regulation mechanism based on QCI and / or some other access regulation mechanism to prioritize, for example, the requested service such as a voice call. The QCI-based access regulation that may be requested by one of the WTRUs may apply to one or more or each of the other WTRUs under the coverage of that eNB. A voice call may be prioritized within the cell for a period of time, for example, while the emergency WTRU is making a voice call and / or providing information regarding its emergency situation. The eNB may cause the WTRU that may have requested access class regulation to revert to its normal operation when it ends its emergency voice call.

[0094] Although features and elements have been described above in individual combinations, one of ordinary skill in the art will fully recognize that each feature or element can be used alone or in any combination with other features and elements. Additionally, the methods described herein may be implemented by a computer program, software, or firmware incorporated into a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted by wired or wireless connection), and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, ROM, RAM, registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor in connection with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A wireless transmit / receive unit (WTRU) comprising: receiving, via non-access stratum (NAS) signaling, a first operator-specific service-based access control indication, wherein the first operator-specific service-based access control indication is associated with a first set of services, and the first set of services corresponds to one application ID; identifying a first access attempt to access a base station, wherein the first access attempt is associated with the services of the first set of services; determining, based on the first operator-specific service-based access control indication, that the first access attempt is permitted to be transmitted to the base station; transmitting, based on the determination that the first access attempt is permitted to be transmitted to the base station, a first access request to the base station, wherein the first access request is associated with the identified first access attempt; a processor configured to perform the above; a WTRU comprising the above.

2. The WTRU of claim 1, wherein the first set of services associated with the first operator-specific service-based access control indication further corresponds to at least one of an IP flow, an access point name (APN), a quality of service (QoS), or a QoS class identifier (QCI).

3. The WTRU of claim 1, wherein the first access attempt is associated with access stratum (AS) signaling.

4. Receiving, via non-access stratum (NAS) signaling, a first operator-specific service-based access control indication, wherein the first operator-specific service-based access control indication is associated with a first set of services, and the first set of services corresponds to one application ID; Identifying a first access attempt to access a base station, wherein the first access attempt is associated with the services of the first set of services; Based on the access control indication of the service base specific to the first operator, determining that the first access attempt is permitted to be transmitted to the base station; Based on the determination that the first access attempt is permitted to be transmitted to the base station, transmitting a first access request to the base station, wherein the first access request is associated with the identified first access attempt; A method comprising. **Claim 5** The method according to claim 4, wherein the set of the first services associated with the access control indication of the service base specific to the first operator further corresponds to at least one of an IP flow, an access point name (APN), a quality of service (QoS), or a QoS class identifier (QCI). **Claim 6** The method according to claim 4, wherein the first access attempt is associated with access stratum (AS) signaling.

Images