Method and apparatus for controlling network connectivity

Abstract

To provide method and device for controlling connectivity to a network with respect to an intermittent data service.SOLUTION: A new pause mode is defined so that WTRU (radio transmission / reception unit) can transit from a connection state or an idle state to a pause mode based on a triggering condition. WTRU transits from the connection state or the idle state to the pause mode when the characteristic or priority of data coincides with the characteristic or priority of the pause mode, and can operate by using a configuration different from that used under the connection state or the idle state. WTRU in the pause mode may perform a mobility procedure controlled by WTRU. WTRU in the pause mode can hold a dedicated resource such as C-RNTI (cell radio network temporary identity) to receive unicast traffic from a network.SELECTED DRAWING: Figure 3

Description

Technical Field

[0001] The present invention relates to a method and an apparatus for controlling connectivity to a network.

Background Art

[0002] Cross - reference to Related Applications This application claims priority to U.S. Provisional Patent Application No. 61 / 470,953, filed on April 1, 2011; U.S. Provisional Patent Application No. 61 / 555,653, filed on November 4, 2011; U.S. Provisional Patent Application No. 61 / 591,389, filed on January 27, 2012; and U.S. Provisional Patent Application No. 61 / 611,97, filed on March 16, 2012, the contents of which are hereby incorporated by reference herein.

[0003] 3GPP (Third Generation Partnership Project) LTE (Long Term Evolution) Release 8 / 9 (LTE R8 / 9) supports up to 100 Mbps in the downlink (DL) and 50 Mbps in the uplink (UL) for a 2x2 configuration. The LTE DL transmission scheme is based on an OFDMA (Orthogonal Frequency Division Multiple Access) air interface.

[0004] For flexible deployment, LTE R8 / 9 systems support scalable transmission bandwidths, namely 1.4MHz, 2.5MHz, 5MHz, 10MHz, 15MHz, or 20MHz. In LTE, each radio frame (10ms) contains 10 equally sized subframes of 1ms each. Each subframe contains two equally sized time slots of 0.5ms each. Depending on the length of the cyclic prefix (CP), there are either 7 or 6 OFDM (Orthogonal Frequency Division Multiplexing) symbols per time slot. 7 symbols per time slot are used with the normal CP length, and 6 symbols per time slot are used with the extended CP length. The subcarrier spacing in LTE is 15kHz. An alternative reduced subcarrier spacing mode using 7.5kHz is also possible.

[0005] A resource element (RE) corresponds to one subcarrier within a single OFDM symbol interval. Twelve consecutive subcarriers within a 0.5ms time slot constitute one resource block (RB). Therefore, using seven symbols per time slot, each RB consists of 12 x 7 = 84 REs. A DL carrier can contain a scalable number of RBs, ranging from 6 to 110. This corresponds to an overall scalable transmission bandwidth from approximately 1 MHz to 20 MHz. Typically, a common set of transmission bandwidths is specified, such as 1.4 MHz, 3 MHz, 5 MHz, 10 MHz, or 20 MHz.

[0006] The fundamental time-domain unit for dynamic scheduling is a subframe containing two consecutive time slots, which are sometimes referred to as a resource-block pair. Certain subcarriers on some OFDM symbols are allocated to carry pilot signals within the time-frequency grid. A given number of subcarriers on the edges of the transmission bandwidth are not transmitted to comply with spectral mask requirements.

[0007] LTE-Advanced, using carrier aggregation, is an evolution that aims to improve the data rates of single-carrier LTE R8 / 9 / 10 by using bandwidth expansion (i.e., carrier aggregation) among other methods. With carrier aggregation, a WTRU can transmit and receive simultaneously on multiple serving cells via PUSCH (physical uplink shared channel) and PDSCH (physical downlink shared channel). Up to four subcells (SCells) can be configured in addition to the primary serving cell (PCell). Subcells can support flexible bandwidth allocation up to 100 MHz.

[0008] Control information regarding PDSCH and PUSCH scheduling can be transmitted over one or more PDCCHs (physical downlink control channels). In addition to LTE R8 / 9 scheduling, which uses one PDCCH for each pair of UL and DL carriers, cross-carrier scheduling can be supported for a given PDCCH, enabling the network to provide PDSCH allocation and / or PUSCH grants for transmission in other serving cells(s).

[0009] In LTE R8 / 9 and LTE Release 10 (R10) using a single-carrier configuration, the network assigns a pair of UL and DL carriers to a WTRU (Radio Transceiver Unit), but for any given subframe, there is a single HARQ (Hybrid Auto Retransmission Request) process active on the UL and a single HARQ process active on the DL.

[0010] In LTE R10 configured with carrier aggregation, there is one HARQ entity per serving cell. Within any given subframe, there may be multiple HARQ processes active for UL and DL, but there is at most one UL HARQ process and one DL HARQ process per configured serving cell. [Overview of the project]

[0011] A method and apparatus for controlling network connectivity for intermittent data services is disclosed. A new dormant mode is defined so that a WTRU can transition from a connected state or idle response to a dormant mode based on conditions triggered by the WTRU. The WTRU can transition from a connected state or idle state to a dormant mode if the characteristics or priority of the data match the characteristics or priority of the dormant mode, and can operate using a different configuration than the one used for the connected state or idle state. A WTRU in dormant mode can periodically monitor signals from cells and perform mobility procedures controlled by the WTRU, so that the WTRU can select one of several cells based on pre-configured criteria and camp in the selected cell. A WTRU in dormant mode can maintain dedicated resources, such as a cell radio network temporary identity (C-RNTI), for receiving unicast traffic from the network so that the WTRU can monitor channels from the selected cell on scheduling opportunities configured to receive control signaling and user plane data while in dormant mode.

[0012] A WTRU can autonomously transition into or out of hibernation mode based on at least one of the following: NAS (non-access stratum) status, RRC (radio resource control) status, RRC connection release or reconfiguration, DRX (discontinuous reception) status, downlink activity, timer, uplink timing assignment status, DRB (data radio bearer) configuration, amount of data in the WTRU buffer, buffer filling rate, or inter-packet or inter-burst arrival time. Alternatively, a WTRU can transition into or out of hibernation mode based on control signaling from the network.

[0013] A WTRU can transmit on a special subframe. A special subframe is one that contains a sufficient guard period to tolerate uplink timing misalignment from a WTRU that does not have valid uplink timing alignment. Alternatively, a WTRU in idle mode can transmit PRACH (physical random access channel) transmissions on a WTRU-specific subframe. A WTRU can transmit PRACH transmissions on WTRU-specific PRACH opportunities using a PRACH resource dedicated to that WTRU. PRACH transmissions can be used to indicate the priority of pending data with respect to HARQ (Hybrid Automatic Retransmission Request) feedback or uplink transmissions.

[0014] A WTRU in hibernation mode can transmit uplink transmissions via a radio bearer configured for hibernation mode. The WTRU can detect traffic patterns and transition into or out of hibernation mode based on the detected traffic patterns. The WTRU can transmit uplink user plane data via control plane signaling. [Brief explanation of the drawing]

[0015] A more detailed understanding can be obtained from the following detailed explanation, which is given as an example in relation to the attached drawings. [Figure 1A] This is a system diagram showing an example communication system that can implement one or more of the disclosed embodiments. [Figure 1B] Figure 1A is a system diagram showing an example of a WTRU (Wave Transceiver Unit) that can be used within the communication system shown. [Figure 1C] Figure 1A is a system diagram showing an example of a wireless access network and an example of a core network that can be used within the communication system shown. [Figure 2] This diagram shows an example bearer service architecture in which a packet filter is used to direct packets to the relevant wireless bearer. [Figure 3] This figure shows the state transitions between RRC_IDLE, RRC_CONNECTED, and RRC_DORMANT according to one embodiment. [Figure 4] This diagram shows an example of state transitions in a NAS (non-access stratum). [Figure 5] This is a signaling diagram illustrating the process of an example of session management according to one embodiment. [Figure 6] This is a signaling diagram illustrating the process of entering a pause mode according to one embodiment. [Figure 7] This figure shows the procedure for an example of TDF (traffic detection function)-based controlled plane policing according to one embodiment. [Figure 8] This diagram illustrates the routing of packets from unwanted flows to a specific wireless bearer. [Modes for carrying out the invention]

[0016] Figure 1A is a diagram of an example communication system 100 that can implement one or more disclosed embodiments. The communication system 100 can be a multiple access system that provides content such as voice, data, video, messaging, broadcasting, and others to multiple wireless users. The communication system 100 can enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communication system 100 can use one or more channel access methods such as CDMA (Code Division Multiple Access), TDMA (Time Division Multiple Access), FDMA (Frequency Division Multiple Access), OFDMA (Orthogonal FDMA), SC-FDMA (Single-Carrier FDMA), and similar.

[0017] As shown in Figure 1A, the communication system 100 may include WTRUs (Radio Transmit / Receive Units) 102a, 102b, 102c, 102d, a RAN (Radio Access Network) 104, a core network 106, a PSTN (Public Switched Telephone Network) 108, the Internet 110, and other networks 112, but please understand that the disclosed embodiments intend any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d can be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRU 102a, 102b, 102c, and 102d may be configured to transmit and / or receive radio signals and may include UEs (User Equipment), mobile stations, fixed or mobile subscriber units, pagers, cell phones, PDAs (Personal Digital Assistants), smartphones, laptops, netbooks, personal computers, radio sensors, consumer electronics, and similar devices.

[0018] The communication system 100 can also include base stations 114a and 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 the core network 106, the Internet 110, and / or the network 112. For example, the base stations 114a, 114b can be a BTS (Base Transceiver Station), Node-B, eNode B, Home Node B, Home eNode B, site controller, AP (Access Point), wireless router, and the like. Although the base stations 114a, 114b are each illustrated as a single element, it should be understood that the base stations 114a, 114b can include any number of interconnected base stations and / or network elements.

[0019] Base station 114a can be part of the RAN 104, and the RAN 104 can also include other base stations and / or network elements (not shown), such as a BSC (Base Station Controller), RNC (Radio Network Controller), relay nodes, and the like. The base station 114a and / or the base station 114b can be configured to transmit and / or receive wireless signals within a particular geographic area, sometimes referred to as 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 transceiver for each sector of the cell. In another embodiment, the base station 114a can use MIMO (multiple-input multiple output) technology and thus can use multiple transceivers for each sector of the cell.

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

[0021] More specifically, as noted above, communication system 100 can be a multi-connection system and can use one or more channel access methods such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, base stations 114a in RAN 104 and WTRUs 102a, 102b, 102c can implement a wireless technology such as UTRA (UMTS (Universal Mobile Telecommunications System) Terrestrial Radio Access), and UTRA can establish air interface 116 using WCDMA (registered trademark) (wideband CDMA). WCDMA can include communication protocols such as HSPA (High-Speed Packet Access) and / or HSPA+ (Evolved HSPA). HSPA can include HSDPA (High-Speed Downlink Packet Access) and / or HSUPA (High-Speed Uplink Packet Access).

[0022] In another embodiment, base stations 114a and WTRUs 102a, 102b, 102c can implement a wireless technology such as E-UTRA (Evolved UMTS Terrestrial Radio Access), and E-UTRA can establish air interface 116 using LTE (Long Term Evolution) and / or LTE-A (LTE-Advanced).

[0023] In other embodiments, base stations 114a and WTRUs 102a, 102b, 102c can implement wireless technologies such as IEEE 802.16 (i.e., WiMAX (Worldwide Interoperability for Microwave Access)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, IS-2000 (Interim Standard 2000), IS-95 (Interim Standard 95), IS-856 (Interim Standard 856), GSM (Registered Trademark) (Global System for Mobile communications), EDGE (Enhanced Data rates for GSM Evolution), GERAN (GSM EDGE), and similar technologies.

[0024] The base station 114b in Figure 1A can be, for example, a wireless router, Home Node B, Home eNode B, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in localized areas such as workplaces, homes, vehicles, campuses, and similar locations. In one embodiment, the base station 114b and WTRUs 102c, 102d can implement wireless technologies such as IEEE 802.11 to establish a WLAN (Wireless Local Area Network). In another embodiment, the base station 114b and WTRUs 102c, 102d can implement wireless technologies such as IEEE 802.15 to establish a WPAN (Wireless Personal Area Network). In yet another embodiment, the base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish picocells or femtocells. As shown in Figure 1A, base station 114b may have a direct connection to the internet 110. Therefore, base station 114b may not be required to access the internet 110 via the core network 106.

[0025] RAN 104 may communicate with core network 106, which can be any type of network configured to provide voice, data, applications, and / or VoIP (voice over internet protocol) services to one or more of WTRUs 102a, 102b, 102c, and 102d. For example, core network 106 may provide call control, billing services, mobile location-based services, prepaid calls, internet connectivity, video distribution, etc., and / or perform high-level security functions such as user authentication. Although not shown in Figure 1A, it should be noted that RAN 104 and / or core network 106 may communicate directly or indirectly with other RANs using the same RAT as RAN 104 or a different RAT. For example, in addition to being connected to RAN 104 which may be utilizing E-UTRA radio technology, core network 106 may also communicate with another RAN (not shown) using GSM radio technology.

[0026] Core network 106 can also act as a gateway for WTRUs 102a, 102b, 102c, and 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing POTS (plain old telephone service). The Internet 110 includes a worldwide system of interconnected computer networks and devices using common communication protocols such as TCP (Transmission Control Protocol) / IP (Internet Protocol) within the Internet Protocol Suite, UDP (User Datagram Protocol), and IP. Network 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another core network connected to one or more RANs, which may use the same RAT as RAN 104 or a different RAT.

[0027] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 can include multimode capability; that is, WTRUs 102a, 102b, 102c, and 102d can include multiple transceivers to communicate with different radio networks over different radio links. For example, WTRU 102c, shown in Figure 1A, can be configured to communicate with base station 114a, which can use cellular-based radio technology, and base station 114b, which can use IEEE 802 radio technology.

[0028] Figure 1B is a system diagram of an example WTRU 102. As shown in Figure 1B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 106, removable memory 132, a power supply 134, a GPS (Global Positioning System) chipset 136, and other peripherals 138. It should be noted that the WTRU 102 may include any sub-combinations of the aforementioned elements while remaining consistent with the embodiment.

[0029] The processor 118 can be a general-purpose processor, a special-purpose processor, a conventional processor, a DSP (Digital Signal Processor), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an ASIC (Application-Specific Integrated Circuit), an FPGA (Field-Programmable Gate Array) circuit, any other type of IC (Integrated Circuit), a state machine, and similar. The processor 118 can perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables 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 transmit / receive element 122. Figure 1B shows the processor 118 and transceiver 120 as separate components, but it should be noted that the processor 118 and transceiver 120 can be integrated together in an electronic package or chip.

[0030] The transmit / receive element 122 can be configured to transmit or receive signals to or from a base station (e.g., base station 114a) via the air interface 116. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In another embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF signals and optical signals. It should be noted that the transmit / receive element 122 can be configured to transmit and / or receive any combination of radio signals.

[0031] Furthermore, although the transmit / receive element 122 is illustrated as a single element in Figure 1B, the WTRU 102 can include any number of transmit / receive elements 122. More specifically, the WTRU 102 can utilize MIMO technology. Thus, in one embodiment, the WTRU 102 can include multiple transmit / receive elements 122 (e.g., multiple antennas) that transmit and receive radio signals via the air interface 116.

[0032] The transceiver 120 can be configured to modulate the signal transmitted by the transmit / receive element 122 and demodulate the signal received by the transmit / receive element 122. As noted above, the WTRU 102 may have multimode capability. Therefore, the transceiver 120 may include multiple transceivers that enable the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11.

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

[0034] The processor 118 can receive power from the power supply 134 and can be configured to distribute and / or control power to other components within the WTRU 102. The power supply 134 can be any suitable device that supplies power to the WTRU 102. For example, the power supply 134 may include one or more dry cell batteries (e.g., NiCd (nickel-cadmium), NiZn (nickel-zinc), NiMH (nickel-metal hydride), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and similar devices.

[0035] The processor 118 may also be coupled to a GPS chipset 136, which can be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via the air interface 116 and / or determine its location based on the timing of signals being received from multiple nearby base stations. It should be noted that the WTRU 102 may acquire location information by any suitable location determination method while remaining consistent with the embodiment.

[0036] The processor 118 can be further coupled to other peripherals 138, which may include one or more software modules and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, peripherals 138 may include an accelerometer, e-compass, satellite transceiver, digital camera (for photography or video), USB (universal serial bus) port, vibration device, television transceiver, hands-free headset, Bluetooth® module, FM (frequency modulation) radio unit, digital music player, media player, video game player module, internet browser, and similar.

[0037] Figure 1C is a system diagram of RAN 104 and core network 106 according to one embodiment. As noted above, RAN 104 can use E-UTRA radio technology to communicate with WTRU 102a, 102b, and 102c via air interface 116. RAN 104 can also be configured to communicate with core network 106.

[0038] RAN 104 may include eNode-B 140a, 140b, and 140c, but it should be noted that RAN 104 may include any number of eNode-B while remaining consistent with the embodiment. Each of the eNode-B 140a, 140b, and 140c may include one or more transceivers that communicate with WTRU 102a, 102b, and 102c via the air interface 116. In one embodiment, the eNode-B 140a, 140b, and 140c can implement MIMO technology. Thus, for example, the eNode-B 140a can use multiple antennas to transmit radio signals to and receive radio signals from WTRU 102a.

[0039] Each of the eNode-B 140a, 140b, and 140c can be associated with a specific cell (not shown) and configured to handle wireless resource management decisions, handover decisions, user scheduling on uplink and / or downlink, and similar functions. As shown in Figure 1C, the eNode-B 140a, 140b, and 140c can communicate with each other via the X2 interface.

[0040] The core network 106 shown in Figure 1C may include an MME (mobility management gateway) 142, a serving gateway 144, and a PDN (packet data network) gateway 146. While each of the aforementioned elements is illustrated as part of the core network 106, it should be noted that any one of these elements may be owned and / or operated by an entity other than the core network operator.

[0041] The MME 142 can connect to each of the eNode-B 142a, 142b, and 142c within RAN 104 via the S1 interface and can act as a control node. For example, the MME 142 can be responsible for user authentication of WTRU 102a, 102b, and 102c, bearer activation / deactivation, selection of a specific serving gateway during the initial attachment of WTRU 102a, 102b, and 102c, and similar functions. The MME 142 can also provide control plane functionality for switching between RAN 104 and other RANs (not shown) using other radio technologies such as GSM or WCDMA.

[0042] The serving gateway 144 can be connected to each of the eNode B 140a, 140b, and 140c in the RAN 104 via the S1 interface. The serving gateway 144 can generally route and forward user data packets to and from WTRU 102a, 102b, and 102c. The serving gateway 144 can also perform other functions such as anchoring the user plane during eNode B handover, triggering paging when downlink data is available for WTRU 102a, 102b, and 102c, managing and storing the contents of WTRU 102a, 102b, and 102c, and similar.

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

[0044] The core network 106 can facilitate communication with other networks. For example, the core network 106 can give WTRUs 102a, 102b, and 102c access to a circuit-switched network such as the PSTN 108 to facilitate communication between WTRUs 102a, 102b, and 102c and traditional land-line communication devices. For example, the core network 106 may include, or communicate with, an IP gateway (e.g., an IMS (IP multimedia subsystem) server) that acts as an interface between the core network 106 and the PSTN 108. Furthermore, the core network 106 can give WTRUs 102a, 102b, and 102c access to network 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0045] In LTE, the PDCCH is used by the network to allocate PDSCH resources for downlink transmission and grant PUSCH resources for uplink transmission to the WTRU. The WTRU can request radio resources for uplink transmission by sending an SR (scheduling request) to the eNB. The SR can be sent either on a dedicated resource configured on the PUCCH, or using a random access procedure.

[0046] WTRUs are granted by eNBs for transmission over PUSCHs for radio resources indicated within grants received on PDCCHs or configured resources (i.e., SPS (semi persistently scheduled) UL grants).

[0047] The WTRU determines whether it needs to act on control signaling within a given subframe by monitoring the PDCCH for a specific downlink control information (DCI) message scrambled using a known RNTI (radio network temporary identifier) ​​at a specific location (i.e., search space) based on the aggregation level (AL), using different combinations of physical resources (i.e., control channel elements (CCEs)). Each AL corresponds to one, two, four, or eight CCEs. A single CCE contains 36 QPSK (quadrature phase shift keying) symbols or 72 channel-encoded bits.

[0048] The PDCCH is divided into two distinct regions. The set of CCE locations where a WTRU might find a DCI that it needs to operate on is called the search space. The search space is divided into a common search space and a WTRU-specific search space. The common search space is common to all WTRUs monitoring a given PDCCH, but the WTRU-specific search space is different for each WTRU. Since both search spaces are functions of the randomization feature, they may overlap for a given WTRU within a given subframe, and this overlap differs from subframe to subframe.

[0049] The set of CCE locations that constitute the common lookup space and its starting point is a function of the cell identity and subframe number. For LTE R8 / 9, DCI can be transmitted using AL4 (four CCEs) or AL8 (eight CCEs) within the common lookup space. For subframes that the WTRU monitors the PDCCH, the WTRU may attempt to decode two DCI format sizes with up to four different sets of four CCEs for AL4 (i.e., eight blind decoding attempts) and up to two different sets of eight CCEs for AL8 (i.e., four blind decoding attempts), for a total of at most 12 blind decoding attempts within the common lookup space (e.g., DCI formats 1A and 1C, as well as DCI format 3A used for power control).

[0050] The common search space corresponds to CCE 0-15, which implies four decoding candidates for AL4 (i.e., CCE 0-3, 4-7, 8-11, and 12-15) and two decoding candidates for AL8 (i.e., CCE 0-7 and 8-15).

[0051] The set of CCE locations that constitute the WTRU-specific lookup space and its starting point is a function of the WTRU identity and subframe number. For LTE R8 / 9, DCI can be transmitted within the WTRU-specific lookup space using AL1, AL2, AL4, or AL8. For subframes over which the WTRU monitors the PDCCH, the WTRU may attempt to decode two DCI formats with a total of at most 32 blind decoding attempts within its WTRU-specific lookup space, using up to six different CCEs for AL1 (i.e., 12 blind decoding attempts), up to six different sets of two CCEs for AL2 (i.e., 12 blind decoding attempts), up to two different sets of eight CCEs for AL8 (i.e., 4 blind decoding attempts), and up to two different sets of eight CCEs for AL8 (i.e., 4 blind decoding attempts).

[0052] Depending on the WTRU's connectivity to the network, capabilities, and supported features, a WTRU may monitor one or more RNTIs for grants, allocations, and other control information from the eNB. A WTRU may monitor at least one of the following: SI-RNTI (system information RNTI), P-RNTI (paging RNTI), RA-RNTI (random access RNTI), M-RNTI (MBMS (multimedia broadcast / multicast services) RNTI), C-RNTI (cell RNTI), temporary C-RNTI, SPS-C-RNTI (semi-persistent scheduling C-RNTI), and others. SI-RNTI is cell-specific and used to indicate the scheduling of system information on the PDSCH within a common lookup space. P-RNTI can be assigned to multiple WTRUs for decoding paging notifications (e.g., in IDLE mode) within a common lookup space. RA-RNTI is used to indicate the scheduling of random access responses on the PDSCH and identifies which time-frequency resources were used by the WTRU to transmit the random access preamble. M-RNTI is cell-specific and used to decode notifications of changes on the MCCH (MBMS control channel) within a common search space. C-RNTI is a WTRU-specific RNTI used to decode the PDCCH for contention-free grants and assignments, for example, regarding the DCI within the WTRU-specific search space. Temporary C-RNTI can be used to decode messages for contention-based procedures and / or before the WTRU is assigned its own C-RNTI. SPS-C-RNTI can be used within the WTRU-specific search space to activate semi-permanent downlink assignments on the PDSCH or uplink grants on the PUSCH. TPC (transmit power control)-PUSCH-RNTI and TPC-PUCCH-RNTI can be used for power control of the PUSCH and PUCCH, respectively.

[0053] In LTE, the network can configure the WTRU using the DRX (discontinuous reception) parameter. DRX is a feature that allows the WTRU not to monitor or decode the PDCCH in order to reduce WTRU power consumption. The DRX functionality relies on a specific set of rules based on PDCCH activity for several specific RNTIs. These rules ensure that the network and the WTRU are synchronized regarding when the WTRU can be reached using control signaling. When DRX is configured, the WTRU can monitor the PDCCH at least during DRX active time (excluding configured measurement gaps).

[0054] Within a transceiver (i.e., a WTRU), power consumption is distributed among the baseline baseband, baseband, transmitter, and receiver. The baseline baseband consumes very little power, while each of the other three components accounts for approximately one-third of the total power consumption. Each also has a different startup time, and the turn-on of the baseband component, including synchronization with the network signal, may require tens of milliseconds or more.

[0055] From the perspective of processing requirements and embodiments, it is assumed that in subframes where the WTRU monitors the PDCCH for DL ​​allocation, symbols containing user data (e.g., PDSCH) follow symbols used in the L1 control area (e.g., PDCCH), and that L1 signaling processing is not instantaneous. The WTRU can buffer at least a portion of the PDSCH symbols before it can complete at least the L1 signaling processing and determine whether there is a DL transmission addressed to the WTRU on the PDSCH in that subframe. Thus, the benefit of DRX goes beyond saving some processing of the PDCCH. For subframes where the WTRU is not required to monitor the PDCCH for UL grants and DL allocation, the WTRU may choose to turn off at least a portion of its transceiver (Tx / Rx) network, including memory components and / or baseband components (if the number of subframes where the WTRU does not monitor the PDCCH is sufficiently large, e.g., 20-30ms). The RNTIs to which WTRU applies the above include C-RNTI, TPC-PUCCH-RNTI, TPC-PUSCH-RNTI, SPS-C-RNTI, and others.

[0056] The ideas described herein may be further applied to DRX functions where additional RNTIs (one or more) are considered in subsequent evolutions of the specification and are therefore not excluded by this document.

[0057] In LTE, a WTRU may initiate a random access procedure when it makes initial access to the network to establish an RRC connection, when it accesses a target cell during handover, when it performs an RRC connection re-establishment procedure, when it is instructed by the network to perform a random access procedure (i.e., by a PDCCH random access order, for example, regarding the arrival of DL data), when it makes a scheduling request but does not have a dedicated resource on PUCCH for the request (for example, when it has new UL data to send that has a higher priority than existing data in its buffer), or similar.

[0058] Depending on whether a WTRU is allocated a dedicated RACH resource (e.g., a specific preamble and / or PRACH resource), a random access procedure can be either CFRA (contention-free random access) or CBRA (contention-based random access). For random access, the WTRU transmits a preamble over a PRACH (physical random access channel) resource. The WTRU then receives a RAR (random access response), which includes an uplink transmission grant and a TAC (timing advance command). For CBRA, for conflict resolution, the WTRU determines whether the RACH procedure was successfully completed based on either the C-RNTI on the PDCCH or the WTRU conflict resolution identity on the DL-SCH.

[0059] In LTE, the WTRU can be configured using RRC with dedicated resources for transmitting CQI / PMI reports and scheduling requests (SR). Furthermore, the WTRU can be configured with dedicated uplink resources for SPS and corresponding uplink PUCCH resources for HARQ ACKs (acknowledgments) related to DL SPS configurations. The network can allocate dedicated SRS resources to the WTRU to assist in scheduling decisions regarding the allocation of uplink resources for PUCCH transmissions.

[0060] In LTE, to maintain orthogonality between uplink transmissions from multiple WTRUs, uplink transmissions from different WTRUs to the eNB within the same subframe must be approximately time-aligned, with an error margin of within the cyclic prefix length. The cyclic prefix is ​​a guard interval in the time domain added to each symbol to handle channel delay spreading. For LTE, a typical inclusive frame structure with a cyclic prefix length contains seven symbols, with a cyclic prefix length of 5.2 μs for the first symbol and 4.7 μs for the other symbols in the frame. For larger cells, extended prefixes can be configured. Timing advance is a negative offset between the beginning of a received downlink subframe and the beginning of a transmitted uplink subframe in a mobile terminal (i.e., the subframe of an uplink transmission begins before the downlink subframe in the mobile terminal). This offset can be adjusted by the network using TAC (timing advance command) signaling, and such adjustment is based on previous uplink transmissions by the WTRU, including SRS (sounding signal) and any other uplink transmissions.

[0061] In LTE, before a WTRU can perform uplink transmissions related to periodic SRS or uplink transmissions over either PUCCH or PUSCH, the WTRU must have the correct timing alignment with the network. Uplink synchronization is initially achieved using the RACH procedure, and the network then transmits a TAC downlink to maintain the correct timing alignment. Upon receiving the TAC, the WTRU (re)starts the TAT (timing advance timer). The TAC may be received within the RAR during the RA procedure or within the Timing Advance MAC CE (Control Element).

[0062] When TAT is active, the WTRU can transmit over a PUCCH resource within a subframe where the WTRU does not perform a PUSCH transmit (single carrier property). PUCCH resources are dynamically allocated within the frequency / time shared resources of the PUCCH domain for HARQ ACK feedback regarding PDSCH transmits. The WTRU determines which PUCCH resource to use based on the first CCE of the DCI received on the PDCCH indicating the PDSCH allocation.

[0063] The TAT can be set so that a synchronized WTRU does not receive a TAC from the network for a period equal to at least the configured value of the TAT (i.e., a timeAlignmentTimer ranging from 500ms to 10240ms when enabled). A WTRU may not receive a TAC if all TACs are lost during that period. Alternatively, a WTRU may not receive a TAC if the network does not send any TACs at all to implicitly release a dedicated uplink resource when the network no longer schedules that WTRU for a new transmission. The appropriateness of the timing advance of a WTRU is controlled by the eNB.

[0064] When the TAT expires, the WTRU releases its dedicated uplink resources, namely all configured SRS resources and PUCCH resources for SR and CQI / PMI / RI, as well as all configured downlink and uplink SPS resources. Furthermore, a WTRU may not be permitted to perform any PUCCH or PUSCH transmissions after it is deemed to be out of synchronization with the network. This is to avoid possible interference with transmissions of other WTRUs. In addition, this provides an implicit means for the scheduler to cancel dedicated uplink resources by simply expiring the TAT following the absence of the TAC from the network.

[0065] An SRB (signaling radio bearer) is a radio bearer used to transmit RRC messages and NAS messages. SRB0 is used for RRC messages using CCCH (common control channel), and SRB1 is for RRC messages (including piggybacked NAS messages) and NAS messages before the establishment of SRB2, which uses DCCH (dedicated control channel). SRB2 is for NAS messages and is configured after security is activated. After security is activated, all RRC messages on SRB1 and SRB2 are integrity protected and encrypted. A DRB (data radio bearer) is a radio bearer used to transmit user plane data (e.g., IP packets).

[0066] One way to improve user plane latency for WTRUs that are synchronized (i.e., have effective timing alignment) but do not have effective UL grants is to use a contention-based (CB) method. A network can advertise uplink resources (otherwise unused) on the PDCCH to one or more WTRUs connected to that network. A special RNTI (i.e., a CB-RNTI (contention-based RNTI)) can be assigned to one or more WTRUs for this purpose, for example, during the radio configuration of the WTRUs, and the same CB-RNTI can signal to multiple WTRUs.

[0067] The NAS (non-access stratum) protocol operates between the WTRU and the MME (mobility management entity) within the core network. The NAS is responsible for (among other things) performing PLMN (public land mobile network) selection, registering with the network (e.g., the selected PLMN) (via the attach procedure or tracking area update procedure), requesting an IP address(s) and the resulting bearer requests for user plane operation, and transitioning from idle mode to connected mode.

[0068] When powered on, the WTRU starts in the EMM (EPS mobility management)-DEREGISTERED state (because it has not yet registered with the network). After the PLMN / cell is selected, the WTRU / NAS attempts to register with the network, thereby requesting an RRC connection to send the first NAS message (i.e., the attach message).

[0069] The NAS is said to be in EMM-Connected mode after the first NAS message is sent (while in RRC connection state) and the first NAS response is received. RRC connection is required to establish a NAS connection (i.e., for the WTRU to be in EMM-Connected mode).

[0070] When the WTRU is in idle mode, both the WTRU and the MME maintain these active bearers so that resources for the WTRU's active EPS bearers are set up when it transitions to connected mode. In LTE, the WTRU can activate at least the default bearer, and while in connected mode, at least the corresponding resources (radio and S1-U) for this bearer can be set up.

[0071] The NAS service request procedure is used to switch the WTRU from idle mode to connected mode. When this transition occurs, the network sets up resources (DRB and S1-U) related to the active EPS bearer context held by the MME.

[0072] When the WTRU transitions from idle mode to connected mode, all or a subset of dedicated bearers may not have resource (DRB) setup. The WTRU RRC informs the NAS about the deactivated ones (those without DRB setup), and the NAS deactivates the corresponding EPS bearers. However, the WTRU remains in the system and operates using the default bearers (but is permitted to request dedicated bearers if needed). The WTRU's RRC informs the NAS about bearers that have no resource setup at all. If the default bearer is one of them, the NAS performs a local detach, and the WTRU needs to reattach to the system to operate.

[0073] The NAS service request procedure is initiated in idle mode (except for CS (circuit switched) fallback). WTRUs that are already in connected mode (RRC and EMM) do not need to send NAS service request messages (except for CS fallback). The NAS service request procedure is considered successful by the WTRU (i.e., the NAS) when a lower layer indicates that the DRB has been set up or when a NAS denial of service message is received from the MME.

[0074] In LTE, a service that guarantees user plane data can be associated with a Radio Access Bearer (RAB). A WTRU can be configured with one or more RABs, and different RABs terminate within different PGWs (PDN gateways) in the core network.

[0075] A RAB can be associated with a DRB. A RAB can be associated with a specific set of QoS characteristics. The network configures the DRB according to the desired level of QoS (for example, using parameters such as logical channel priority, PBR (prioritized bit rate), PDCP (packet data convergence protocol), SDU (service data unit) discard timer, and others).

[0076] A DRB can be associated with either a default EPS bearer or a dedicated bearer. The application uses the bearer (both default and dedicated) according to the given QoS supported by these bearers. Packet filters can be used within the WTRU (e.g., with respect to uplink data) and within the CN (e.g., with respect to downlink data) to determine how IP packets should be associated with a given RAB.

[0077] In LTE, services can generate user plane data requiring different QoS levels. For example, a VoIP (Voice over IP) application can generate an RTP voice / audio stream using a given UDP port and exchange RTCP control packets using different UDP ports. In this case, the RTP flow can use the first RAB, and the RTCP flow can use the second RAB. Therefore, the WTRU determines, for each generated IP packet, which RAB the packet must be sent on. This can be achieved using packet filters or TFTs (traffic flow templates). The WTRU can be configured by the network using packet filters or TFTs.

[0078] Figure 2 shows an example bearer service architecture in which a packet filter is used to direct packets to the relevant radio bearer. In this example, packets may be sent to one of the available dedicated bearers or the default bearer, or discarded if they do not match the flow characteristics defined by the relevant TFT. The TFT is provided by the network (e.g., the PGW) when a CreateSessionResponse message is sent in response to a CreateSessionRequest message. This message may be sent, for example, when the SGW changes, for example during a handover, or when a WTRU requests PDN connectivity either during an attach procedure or a PDN connectivity request procedure.

[0079] In LTE, one or more EPS bearers can be set up or removed for a given WTRU using higher-layer procedures. A WTRU can maintain a default EPS bearer(s) and any other relevant dedicated bearers(s) within the context of the WTRU, as long as it is attached to the network. Specifically, EPS bearers are maintained within the context of the WTRU independently of the RRC connection state (i.e., even when in idle mode). EPS bearers are removed when the WTRU performs the detach procedure from the network.

[0080] In LTE, when a WTRU releases an RRC connection, it can release any radio access bearer (SRB, DRB) (for example, the S1u connection and associated context between the eNB and SGW are released).

[0081] In connectionless transmission, small data packets can be carried by the control plane following a signaling RRC connection establishment message. This type of data transmission can be considered a connectionless technique for packet forwarding in cellular networks because messages are transmitted without setting up a user plane connection. End-user packets can be sent with a larger header that enables subsequent processing of the packet by the receiving node (for example, end-user packets are embedded within a NAS / AS control plane message).

[0082] A WTRU can transmit data within any NAS message by adding an IE (information element) that can carry the data portion, for example. An IE can be added to, for example, an attach request message, a service request message, a PDN connectivity request (in the case of LTE) message, a TAU (tracking area update) request message, or similar. If a PDN connectivity request message is included within an attach message, the WTRU can indicate that setting up an EPS bearer / PDHP context is not necessary (for example, by using a specific value given to the EPS bearer identity). Furthermore, small amounts of data can be carried within a container in the Protocol Configuration Options IE. Data can be transmitted in the downlink direction using a similar method.

[0083] A new IE (Internet Indicator) called "Mtc-datagram-info" can be included within NAS messages (e.g., MM messages or EMM messages) to carry small amounts of data for MTC (machine-type communication) devices or other applications, extending the capabilities of the original NAS message to complete both management and data transfer functions in one. This IE can include a destination address, routing information, the type of small data, a chain end parameter indicating whether it is the last unit in a chain of small data transfer units to a certain destination, security information, or similar.

[0084] A WTRU can be configured in numerous different ways to achieve trade-offs between data transfer latency, power consumption, control signaling overhead, and network efficiency. For example, a WTRU can be RRC_CONNECTED for long periods of time in exchange for the benefits of low control signaling overhead and short data transfer latency, at the expense of battery usage and network resource efficiency when dedicated resources remain committed. Conversely, a WTRU can instead periodically transition between the RRC_CONNECTED and RRC_IDLE states in exchange for the benefits of low power consumption, at the expense of increased data transfer latency and additional control signaling overhead.

[0085] WTRUs can often support a variety of applications, each with different traffic characteristics and requirements, in parallel. Many such applications are agnostic to the technology used to transmit their data, and some applications may not be very well suited to wireless transmission. For example, in the case of an application that generates data traffic in small amounts over relatively long periods at intermittent intervals, a WTRU may be idle during the long periods, but still may connect to the network regularly to exchange small amounts of data.

[0086] When such applications remain active for extended periods, background traffic may be generated at regular intervals. Embodiments of how a WTRU can remain ready to transmit small amounts of data while maximizing battery and network resource usage are disclosed herein.

[0087] A WTRU implementing an embodiment disclosed herein is referred to as a “Hibernate WTRU,” a “Hibernate Mode WTRU,” or a “WTRU Using Hibernate Behavior,” and these terms are interchangeable. A Hibernate Mode WTRU can be implemented by using a new RRC state (e.g., RRC_DORMANT). Alternatively, Hibernate Mode can be implemented using additional procedures in the RRC Idle state (i.e., by defining a substate with a modification to the conventional RRC_IDLE state), or in the RRC Connected state (i.e., by defining a substate with a modification to the conventional RRC_CONNECTED state). Alternatively, Hibernate Mode can be implemented using additional energy-saving methods. Such procedures and methods may include using a second set of configuration parameters applicable to the applicable behavior. The terms “Hibernate Mode,” “RRC_DORMANT,” and “RRC_DORMANT State” are used to refer to the behavior or state of a WTRU or network entity related to any of these implementations.

[0088] Figure 3 shows the state transitions between RRC_IDLE310, RRC_CONNECTED320, and RRC_DORMANT330 (i.e., a new RRC state) according to one embodiment. Figure 3 shows the use of a new RRC state as an example of realizing a dormant mode, and it should be noted that the dormant mode can be realized by defining substates of RRC_IDLE310 or RRC_CONNECTED320 as described above. WTRUs can transition between RRC states based on predetermined implicit or explicit triggers, which will be described in detail below.

[0089] The WTRU is in the RRC_CONNECTED state (320) when an RRC connection is established. If an RRC connection is not established, the WTRU is in the RRC_IDLE state (310). In the RRC_IDLE state (310), the WTRU may be configured with a WTRU-specific DRX and performs WTRU-controlled mobility. The WTRU monitors the paging channel to detect incoming calls, system information changes, etc. The WTRU performs adjacent cell measurement and cell reselection, acquires system information, and logs available measurements.

[0090] In RRC_CONNECTED state 320, the WTRU transmits and / or receives unicast data. At lower layers, the WTRU can be configured with a WTRU-specific DRX. Network-controlled mobility (i.e., handover) is performed in RRC_CONNECTED state 320. The WTRU monitors the paging channel and / or the contents of system information block type 1 to detect system information changes. The WTRU monitors the control channel associated with the shared data channel to determine whether data is scheduled with respect to it, provides channel quality and feedback information, performs neighbor cell measurements and measurement reporting, etc.

[0091] In RRC_DORMANT state 330, unlike RRC_IDLE 310, the WTRU can send scheduling requests using a dedicated PRACH and send and receive unicast data using dedicated resources (e.g., using C-RNTI). In RRC_DORMANT state 330, unlike RRC_CONNECTED 320, the WTRU can perform WTRU-controlled mobility (e.g., WTRU autonomous cell selection and reselection), and scheduling opportunities for the WTRU can be adjusted to coincide with the paging cycle.

[0092] A WTRU may be requested by the network (using L3 messages) to move to the RRC_DORMANT state 330 (for example, to enable a WTRU transition to a network-controlled energy-saving state). A WTRU can be configured with one or more DRX configurations relating to either L3DRX operation or L2DRX operation, or the WTRU may autonomously derive those DRX configurations. An additional L3DRX with priority over L2DRX (for example, to avoid excessive radio link measurement requirements) may be configured in RRC_DORMANT 330. A WTRU may retain at least some of its PUCCH configuration (e.g., configuration relating to CQI reporting) and / or some of its dedicated SRS configuration even when not synchronized (e.g., to avoid the need for RRC reconfiguration for all unicast data transfers). A WTRU may use cell reselection during periods when it is not actively scheduled by the network with respect to unicast transfers, while at the same time using its measurement reporting configuration in other respects. Cell re-selection can trigger a transition to RRC_IDLE state 310, which can trigger initial access to the target cell.

[0093] In RRC_DORMANT state 330, the WTRU can transmit uplink data using contention-based grants (for example, to avoid scheduling request latency). Regardless of uplink timing synchronization, the WTRU can perform uplink transmissions within special subframes to avoid timing alignment maintenance, as detailed below. Alternatively, the WTRU can perform CFRA (contention-free random access) transmissions within WTRU-specific subframes to request uplink resources for uplink transfers corresponding to hiatus mode, to obtain uplink timing synchronization, and / or to acknowledge downlink transmissions(s).

[0094] When transitioning to hibernation mode, the RRC can notify higher layers (e.g., the NAS) of such a transition. For example, the RRC can indicate to the NAS that hibernation mode has been activated (e.g., upon transitioning to RRC_DORMANT state 330). Upon receiving such an instruction, the NAS can initiate session management signaling, for example, by installing packet filters (within the traffic flow template (TFT)) so that the WTRU can determine which packets from which DRBs can be sent using which hibernation mode radio bearer (XRB) in the WTRU configuration. Conceptually, an XRB represents a radio bearer configured for user plane data in hibernation mode for a specific type of traffic (e.g., low-priority, intermittent, background data services).

[0095] In another embodiment, the hibernation behavior can be achieved by modifying the idle mode procedure (e.g., RRC_IDLE state 310). In the modified RRC_IDLE state (e.g., a substate of RRC_IDLE state 310), the WTRU can monitor PDCCH for paging messages on its WTRU-specific paging opportunities. The WTRU can request and / or indicate to the network using an L3 message that it should move to RRC_IDLE (e.g., to enable an autonomous WTRU transition to an energy-saving state). The WTRU may be requested by the network using an L3 message that it needs to move to RRC_IDLE (e.g., to enable a network-controlled WTRU transition to an energy-saving state). The WTRU can retain at least some of the configurations applicable to the RRC_CONNECTED state 320 in the modified RRC_IDLE state (e.g., within a substate of RRC_IDLE state 310). A WTRU may retain at least its security context when transitioning to RRC_IDLE (e.g., to avoid the need to reactivate security for the next unicast data transfer). A WTRU may retain at least its C-RNTI when transitioning to RRC_IDLE (e.g., to avoid the need to reassign the C-RNTI using random access procedures for the next unicast data transfer). A WTRU may retain at least a portion of its PUCCH configuration (e.g., related to CQI reporting or D-SR) and / or dedicated SRS configuration when transitioning to RRC_IDLE, even if they are not synchronized (e.g., to avoid the need to reconfigure the RRC for the next unicast data transfer). Cell reselection can disable configurations applicable to RRC_CONNECTED and idle modes, such as security context and dedicated configurations (e.g., PUCCH configuration), and complete the transition to the RRC_IDLE state.A timer-based mechanism can be used to disable security contexts and dedicated configurations (e.g., PUCCH configurations) and complete the transition to the RRC_IDLE state (for example, if no unicast data transfers have occurred for a certain period of time, such as since the last transfer).

[0096] In another embodiment, the hibernation mode is achieved by modifying the connection mode procedure (for example, in the RRC_CONNECTED state). In the modified RRC_CONNECTED state (for example, a substate of the RRC_CONNECTED state), the WTRU can be configured with one or more DRX configurations relating to either L3DRX operation or L2DRX operation, or the WTRU can autonomously derive these DRX configurations. The WTRU may be configured with L2DRX for energy saving and scheduling opportunities, and an additional L3DRX may be configured with priority over L2DRX (for example, to avoid excessive radio link measurement requirements). The WTRU may retain at least a portion of its PUCCH configuration (for example, relating to CQI reporting or D-SR) and / or dedicated SRS configuration even when not synchronized (for example, to avoid the need for RRC reconfiguration for all unicast data transfers).

[0097] A new NAS state can be defined to reflect entering or exiting hibernation mode. For example, this state may be referred to as hibernation mode and can be implemented as a subset of either EMM-IDLE mode or EMM-CONNECTED mode. The term "EMM-DORMANT" as used thereafter in this specification may refer to a NAS hibernation mode that can be either a substate of EMM-IDLE (e.g., EMM-IDLE.DORMANT) or a substate of EMM-CONNECTED (e.g., EMM-CONNECTED.DORMANT). This hibernation state can be implemented as a substate of the EMM-REGISTERED state, namely the EMM-REGISTERED.NORMAL-SERVICE state.

[0098] Figure 4 shows an example of state transitions in a NAS. EMM-DORMANT410 defines the WTRU NAS behavior in a hibernation mode, which can be realized as substates such as EMM-IDLE, EMM-CONNECTED, or EMM-REGISTERED. The state EMM-nonDORMANT420 indicates that the WTRU may be in EMM-IDLE, EMM-CONNECTED, or EMM-REGISTERED, rather than operating in hibernation mode. The NAS transitions between EMM-DORMANT410 and EMM-nonDORMANT based on a trigger or instructions from a lower layer or MME.

[0099] While the embodiments are described in relation to 3GPP LTE, it should be noted that the embodiments are applicable to any wireless system, including but not limited to WCDMA, HSUPA, HSDPA, HSPA+, GERAN, IEEE 802.xx, and similar technologies.

[0100] Embodiments for enabling and disabling the hibernation mode are disclosed later in this specification. Whether the WTRU can use the hibernation mode of operation can be controlled using one or a combination of the following embodiments.

[0101] The WTRU in connected mode can implicitly determine that it can enable a hibernation mode of operation using at least one of the following embodiments:

[0102] A WTRU can enter hibernation mode if the WTRU's NAS enters hibernation mode (e.g., EMM_DORMANT) and indicates this to the RRC. A WTRU can enter hibernation mode (e.g., RRC_DORMANT state or RRC_IDLE state or RRC_CONNECTED state that supports hibernation mode operation) if the WTRU's NAS sends control signaling (e.g., NAS service request or NAS service update) requesting the setup of resources for hibernation mode operation (e.g., one or more EPS RABs mapping to one or more XRBs). Alternatively, a WTRU can enter hibernation mode if the WTRU's NAS receives control signaling to set up resources for hibernation mode operation (e.g., one or more EPS RABs mapping to one or more XRBs).

[0103] Alternatively, a WTRU can transition from connected mode (e.g., RRC_CONNECTED) to dormant mode (e.g., RRC_DORMANT state or RRC_IDLE state or RRC_CONNECTED state that support dormant mode operation). For example, a WTRU can transition to dormant mode upon receiving RRC control signaling or any control signaling (such as L2 MAC signaling) that activates the use of dormant behavior of the WTRU.

[0104] Alternatively, a WTRU may autonomously indicate and / or request the release of an RRC connection (for example, by sending an RRC connection release request message). The WTRU may include additional information in the request, including traffic characteristics such as, as described herein, average inter-packet arrival time with or without mean deviation, average inter-burst arrival time with or without mean deviation, average burst size, buffer filling rate, average packet size, or similar. The WTRU may include information related to the WTRU's mobility. The WTRU may include a selection of preferred parameters, such as DRX parameters and / or scheduling request parameters, including indices corresponding to parameters selected from a list of available parameters. The WTRU may autonomously enable hibernation mode as part of an RRC connection release request. Alternatively, the WTRU may be instructed in a message responding to an RRC connection release request to enable hibernation mode. This response message may include configuration or reconfiguration of the WTRU's parameters to be used while operating in hibernation mode.

[0105] Alternatively, the WTRU may enable hibernation mode if it has not received any control signaling (e.g., regarding dedicated transmission scheduling) during a consecutive number (which may be configurable) of DRX cycles, or if it receives a MAC DRX CE (control element) indicating that a different (e.g., possibly longer) DRX cycle is available. The WTRU may receive signaling (e.g., a MAC CE) indicating an index to a DRX configuration from a list of available DRX configurations. For example, this instruction may correspond to a different (e.g., non-default) configuration for other configuration aspects such as the RACH configuration and / or the PUCCH configuration (e.g., regarding D-SR).

[0106] Alternatively, WTRU can enable hibernation mode if WTRU has not been scheduled for a certain period of time and / or PDCCH activity is below a certain threshold (which may be configurable).

[0107] Alternatively, the WTRU can enable hibernation mode based on a timer (e.g., after a certain number of subframes have elapsed). This timer can be restarted based on the WTRU's scheduling activity, for example. For instance, this timer can be restarted on the condition that the WTRU successfully decodes PDCCH control signaling (e.g., scrambled using C-RNTI). Alternatively, this timer can correspond to the number of DRX cycles (if configured) that do not receive any control signaling. Alternatively, this timer can be restarted based on the WTRU's buffer status, for example, on the condition that the WTRU's uplink buffer is empty. This can be applied to the buffer status of a configured LCG (logical channel group) and / or LCH (logical channel) subset, excluding certain data (e.g., data for one or more LCHs corresponding to a particular QoS / service). Alternatively, this timer can be restarted based on the WTRU's TAT ​​(timing alignment timer) (e.g., upon TAT expiration).

[0108] Alternatively, the WTRU can be enabled in hibernation mode on the condition that it no longer has a valid uplink timing alignment (for example, that the TAT has expired with respect to at least the WTRU's main serving cell).

[0109] Alternatively, the WTRU may enable hibernation mode, provided that the WTRU RRC is reconfigured to include at least one XRB as part of the WTRU configuration.

[0110] Alternatively, a WTRU may enable hibernation mode on the condition that it has no data available for transmission. For example, a WTRU may enable hibernation mode on the condition that it indicates an empty buffer in a push transmission by including a padding BSR (buffer status report) that reports 0 data for any of the configured DRBs or DRBs not configured as XRBs. Alternatively, a WTRU may enable hibernation mode after a predetermined length of time from a subframe in which a BSR was included in a transmission or from a subframe in which the WTRU received a HARQ ACK for a transmission. Alternatively, a WTRU may enable hibernation mode on the condition that it determines that the data arrival rate of at least one DRB (e.g., one or more XRBs, and other DRBs having empty buffers during that time) is below a certain threshold (which may be configurable). Alternatively, the WTRU may enable hibernation mode if it determines that the inter-packet arrival rate of one or more specific DRBs (e.g., one or more XRBs, and other DRBs having empty buffers during that time) exceeds a certain threshold (which may be configurable). Alternatively, the WTRU may enable hibernation mode if the total sum of data is below a certain threshold.

[0111] Alternatively, the WTRU may enable hibernation mode if the time elapsed between uplink and / or downlink transmissions (i.e., inter-packet arrival time or inter-burst arrival time) exceeds a certain threshold (which may be configurable). The WTRU may perform such measurements for one or more subsets of configured DRBs. For example, the WTRU may record inter-packet arrival time or inter-burst arrival time for a set of DRBs configured as XRBs if it has no data for DRBs that are not configured as XRBs and / or if such DRBs have been inactive for a period of time. The WTRU may maintain mean time estimates. The WTRU may maintain mean deviation estimates. The WTRU's time estimates may be reset if a signaling radio bearer (SRB) transmission is performed or if any RB that is not configured as an XRB transmission is performed.

[0112] Alternatively, the WTRU may enable a hibernation mode if the buffer filling rate for uplink and / or downlink transmits is below a certain threshold (which may be configurable) for a given period of time. The WTRU performs such measurements for one or more subsets of configured DRBs. For example, the WTRU may record the buffer filling rate for a set of DRBs configured as XRBs if it has no data for DRBs that are not configured as XRBs and / or if such DRBs have been inactive for a given period of time. The WTRU's buffer filling rate estimate may be reset if a transmit is performed on an SRB or on any RB that is not configured as an XRB.

[0113] The WTRU can implicitly determine that the operation's hibernation mode can be disabled using at least one of the following embodiments.

[0114] A WTRU may transition out of hibernation mode provided that the WTRU's NAS transitions out of hibernation mode and indicates this to the RRC. A WTRU may transition out of hibernation mode provided that the WTRU's NAS sends control signaling (e.g., a NAS service request or NAS service update) requesting setup for resources of at least one dedicated bearer and / or default bearer (e.g., a bearer not associated with XRB) or there are pending NAS session management procedures. A WTRU may transition out of hibernation mode provided that the WTRU's NAS receives control signaling to set up resources of at least one dedicated bearer and / or default bearer (e.g., a bearer not associated with XRB) or there are pending NAS session management procedures.

[0115] A WTRU can transition from dormant mode (e.g., RRC_DORMANT state) or from an idle mode or a substate of connected mode that supports dormant mode of operation to connected mode (e.g., RRC_CONNECTED state) upon receiving RRC control signaling. For example, a WTRU can disable dormant mode on the condition that a higher layer (e.g., NAS) requests a transition to connected mode without dormant behavior (e.g., RRC_CONNECTED state). A WTRU can use RRC signaling procedures to transition to connected mode. For example, a WTRU can execute an RRC connection request procedure so that it can disable dormant behavior and / or transition to the RRC connected state.

[0116] Alternatively, the WTRU may disable hibernation mode on the condition that a higher layer (e.g., NAS) requests a transition to idle mode (e.g., an IDLE state without hibernation behavior). Alternatively, the WTRU may disable hibernation mode on the condition that the WTRU determines it must perform an RRC state transition to idle mode (e.g., an IDLE state without hibernation behavior) upon detection of, for example, a UL radio link failure or a DL radio link failure.

[0117] The WTRU may disable hibernation mode if it has received control signaling (e.g., regarding dedicated transmission scheduling) over a certain number of consecutive DRX cycles (which may be configurable) or if it receives a MAC DRX CE indicating that the WTRU can use a different (e.g., possibly shorter) DRX cycle. The WTRU may receive signaling (e.g., a MAC CE) indicating an index to a DRX configuration from a list of available DRX configurations. Alternatively, the WTRU may revert to the default DRX configuration. For example, the WTRU may revert to the default configuration for other configuration aspects such as the RACH configuration and / or the PUCCH configuration (e.g., regarding D-SR).

[0118] The WTRU may disable hibernation mode if it determines that it has been scheduled for a specific set of subframes and / or for a period longer than a certain number of subframes, or if PDCCH activity exceeds a certain threshold (which may be configurable).

[0119] The WTRU can disable hibernation mode based on a timer. For example, the WTRU can disable hibernation mode after a certain number of subframes have elapsed. This timer can be restarted based on the WTRU's buffer state. For example, this timer can be restarted if the WTRU's uplink buffer is non-zero for, for example, a subset of the WTRU's configured LCG and / or LCH. The WTRU can determine that the buffer level exceeds the available uplink resources for a certain length of time, which may lead to the disabling of hibernation, allowing it to request more resources.

[0120] The WTRU can disable the hibernation mode, provided it receives a TAC after transmission, for example, over PRACH or on a competition-based resource, and has a valid uplink timing alignment (for example, if TAT is initiated for at least the primary serving cell in the WTRU configuration).

[0121] The WTRU can disable the hibernation mode, provided that an RRC reconfiguration procedure is performed to add at least one DRB that is not an XRB to the WTRU configuration.

[0122] A WTRU may disable hibernation mode if it has new data available for transmission. For example, a WTRU may disable hibernation mode if it determines that data will become available for transmission that can benefit from connected mode behavior (e.g., data will become available for transmission for radio bearers not configured as XRBs (i.e., DRBs and / or SRBs) that need to be set up, or for existing DRBs and / or SRBs that are not XRBs).

[0123] A WTRU can disable hibernation mode, provided that data becomes available for transmission on any DRB that is not configured as an SRB and / or XRB. A WTRU can disable hibernation mode, provided that a scheduling request (SR) is triggered (or pending) or its BSR is triggered. A WTRU can disable hibernation mode, provided that an SR is triggered and / or pending for an SRB, an SR is triggered and / or pending for a DRB that is not configured as an XRB, an SR is triggered and / or pending for an RB associated with an LCH / LCG with a priority higher than a threshold, and / or a higher layer (e.g., NAS) initiates the setup of a new service requesting a transition to connected mode (e.g., the RRC_CONNECTED state without hibernation behavior). The WTRU can then initiate the RRC connection request procedure.

[0124] Alternatively, WTRU may disable hibernation mode if the data arrival rate for at least a subset of DRBs exceeds a certain threshold (which may be configurable), a particular DRB (for example, with respect to one or more XRBs, and when other DRBs have empty buffers during that time) is below a certain threshold (which may be configurable), or the total amount of data exceeds a certain threshold.

[0125] WTRU can disable the hibernation mode on the condition that a configured measurement event triggers a measurement report for a specific type of measurement event (e.g., a serving cell below a threshold or explicitly indicated in the measurement configuration).

[0126] A WTRU may disable hibernation mode if it receives an RRC connection reconfiguration message with mobility control IE that does not indicate that the WTRU needs to remain in hibernation mode, or if the handover is to a different RAT (Radio Access Technology) or a different PLMN (Public Land Mobile Network), or if a handover failure occurs while attempting to remain in hibernation mode.

[0127] A WTRU can disable dormancy mode, provided that the cell reselection procedure results in the selection of a cell different from the cell to which the WTRU is currently connected or camping.

[0128] A WTRU may disable the dormant mode if the WTRU encounters a radio link problem (e.g., a desynchronization or radio link failure condition) or if the WTRU performs the RRC connection re-establishment procedure.

[0129] The WTRU can disable hibernation mode if the time elapsed between uplink and / or downlink transmissions (e.g., inter-packet burst arrival time) is below a certain threshold (which may be configurable). The WTRU can perform such measurements for one or more subsets of configured DRBs. For example, the WTRU can record inter-packet arrival time or inter-burst arrival time for a set of DRBs configured as XRBs. The WTRU can maintain an average time estimate. The WTRU's time estimate can be reset if an SRB transmission is performed, any RB transmission not configured as an XRB is performed, and / or the WTRU exits hibernation mode.

[0130] The WTRU can disable hibernation mode if the buffer filling rate of uplink and / or downlink transmits exceeds a certain threshold (which may be configurable) over a period of time. The WTRU can perform such measurements on one or more subsets of configured DRBs. For example, the WTRU can record the buffer filling rate of a DRB configured as an XRB. The WTRU's buffer filling rate estimate can be reset if a transmit is performed on an SRB, a transmit is performed on any RB not configured as an XRB, and / or the WTRU exits hibernation mode.

[0131] The WTRU can enable and disable hibernation mode using any combination of the embodiments described above, provided that the use of hibernation mode is configured and / or permitted within the WTRU's radio resource configuration. Configurations relating to hibernation mode may be added to configurations used when not operating with hibernation mode relating to embodiments such as DRX, PUCCH, SRS, and PRACH. This configuration may include multiple parameters, configured, for example, as an indexed list of parameters, for each embodiment.

[0132] A WTRU in connected mode can enable a pause mode of operation based on explicit instructions according to at least one of the following embodiments.

[0133] A WTRU can transition to hibernation mode on the condition that the WTRU's NAS sends a control signaling indicating a request for hibernation mode operation (e.g., a NAS service request or NAS service update). For example, a WTRU can transition to hibernation mode when it receives a control signaling indicating hibernation mode operation from its NAS.

[0134] A WTRU can enable hibernation mode on the condition that it receives an RRC message indicating that hibernation mode needs to be enabled. For example, a WTRU can enable hibernation mode on the condition that it receives an RRC connection reconfiguration message that indicates that hibernation mode needs to be enabled (for example, a message that includes a flag and / or triggers a state transition to a different RRC state, such as RRC_DORMANT or a substate of the RRC idle or RRC connected state that supports hibernation behavior). This message may include an index to a set of configuration parameters that should be used while operating in hibernation mode. The WTRU can acknowledge the request and / or reconfiguration in a response message.

[0135] Alternatively, a WTRU may enable hibernation mode on the condition that it receives an RRC connection release message. This message may include an indication that hibernation mode needs to be enabled (for example, a message that includes a flag and / or triggers a state transition to a different RRC state, such as RRC_DORMANT or a substate of an RRC idle state or RRC connection state that supports hibernation behavior). A WTRU may confirm the request and / or reconfiguration in the response message. A WTRU may include additional information in the confirmation, including traffic characteristics such as mean inter-packet arrival time with or without mean deviation, mean inter-burst arrival time with or without mean deviation, mean burst size, buffer filling rate, mean packet size, or at least one of the like. A WTRU may include information related to the WTRU's mobility. A WTRU may include selections of preferred parameters, such as DRX parameters and / or scheduling request parameters, such as an index corresponding to a parameter selected from a list of available parameters. The message enabling hibernation mode may remove and / or release one or more configured DRBs and / or SRBs, and may add, reconfigure, or retain one or more XRBs.

[0136] A WTRU may enable hibernation mode on the condition that it receives an L2 control signaling indicating that hibernation mode should be enabled. For example, a WTRU may enable hibernation mode on the condition that it receives a MAC CE indicating that a different (e.g., longer) DRX cycle should be used. A WTRU may receive a signaling (e.g., a MAC CE) indicating an index to a DRX configuration from a list of available DRX configurations. For example, this instruction may correspond to a different (e.g., non-default) configuration with respect to other configuration aspects such as the RACH configuration and / or the PUCCH configuration (e.g., with respect to D-SR). This signaling may include a dedicated preamble index (e.g., ra-PreambleIndex) and / or a PRACH mask (e.g., ra-PRACH-MaskIndex). Alternatively, a WTRU may enable hibernation mode on the condition that it receives a MAC deactivation CE indicating that the WTRU's secondary serving cell should be deactivated and hibernation mode should be used for the primary serving cell. Alternatively, the WTRU may enable hibernation mode on the condition that it receives a MAC deactivation CE that deactivates the WTRU's primary serving cell (for example, for multiple subframes indicated in the MAC CE, configured by the RRC, or that can be known a priori).

[0137] A WTRU can enable hibernation mode on the condition that it receives L1 control signaling indicating downlink allocation for PDSCH transmissions and / or uplink grant for PUSCH transmissions. For example, a WTRU can enable hibernation mode on the condition that the control signaling is received within a specific subframe (e.g., within a semi-statically configured set of subframes and / or within the on-duration of DRX active time). Alternatively, a WTRU can enable hibernation mode on the condition that the L1 control signaling is received within a subframe that is part of DRX active time but not part of the WTRU's DRX on-duration. Alternatively, a WTRU can enable hibernation mode on the condition that it receives L1 control signaling indicating that the WTRU needs to enable hibernation mode (e.g., using bits in the DCI format). Alternatively, a WTRU can enable hibernation mode on the condition that the DCI is scrambled with a WTRU-specific RNTI indicating that the WTRU needs to change the state of hibernation mode operation.

[0138] A WTRU can enable hibernation mode based on TDF (traffic detection function)-based CP (control plane) policing (for example, using a conventional TDF enforcer operator policy which is either provided via PCRF (policy control rules function) or configured directly by the operator within the PGW (i.e., PCEF (policy control and enforcement function))). The TDF / ADCF (application detection and control function) identifies user plane flows exhibiting certain behaviors and provides this information back to the control plane management entity. Examples of behavior include, but are not limited to, the reception of bursts of small packets at regular intervals that may cause the establishment or disintegration of system resources. Since the detection of such behavior in the user plane may be linked to or related to control plane interference, the PGW (via the SGW) classifies such behavior and communicates its characteristics to the MME (or other control plane entity). The MME can take action or pass this information to the eNB or WTRU, which can then take a specific action. Such specific actions include, but are not limited to, flushing out certain types of traffic or instantiating a new bearer to back off specific control plane events, such as NAS service requests.

[0139] The WTRU can disable the operation pause mode based on explicit instructions according to at least one of the following embodiments.

[0140] A WTRU can transition out of hibernation mode if its NAS sends a control signal (e.g., a NAS service request or NAS service update) indicating an operation unrelated to hibernation mode (e.g., a resource related to sending in connected mode). Alternatively, a WTRU can transition out of hibernation mode if its NAS receives a control signal (e.g., a resource related to sending in connected mode).

[0141] A WTRU may disable hibernation mode when it receives an RRC message indicating that hibernation mode should be disabled. For example, a WTRU may disable hibernation mode upon receiving an RRC connection reconfiguration message that indicates that hibernation mode should be disabled (e.g., a message that includes flags indicating and / or triggering a state transition to a different RRC state such as RRC_CONNECTED or RRC_IDLE, which does not support hibernation behavior).

[0142] A WTRU can transition from hibernation mode to a connected state if it receives an RRC message that reconfigures the RRC connection, such as an RRC connection reconfiguration request. An RRC connection reconfiguration message can indicate that the hibernation behavior needs to be deactivated.

[0143] A WTRU can transition from hibernation mode to idle mode, provided it receives an RRC connection release message. The RRC connection release message may include an instruction that hibernation mode needs to be disabled (e.g., a message containing a flag indicating that the hibernation behavior needs to be deactivated and / or a message containing a flag that triggers a state transition to idle mode, such as RRC_IDLE). The WTRU may acknowledge the request and / or reconfiguration in a response message. A message to disable hibernation mode may remove and / or release all configured radio bearers (e.g., all SRBs, DRBs, and / or XRBs).

[0144] The WTRU may disable hibernation mode, provided it receives an L2 control signaling indicating that hibernation mode should be disabled. For example, the L2 control signaling could be a MAC CE indicating that a different (e.g., shorter) DRX cycle should be used, or a MAC activation CE activating at least one serving cell of the WTRU, e.g., a subcell of the WTRU's configuration. The WTRU may receive a signaling (e.g., a MAC CE) indicating an index to a DRX configuration from a list of available DRX configurations. Alternatively, the WTRU may revert to the default DRX configuration. For example, the WTRU may revert to the default configuration for other configuration aspects such as the RACH configuration and / or the PUCCH configuration (e.g., with respect to D-SR).

[0145] A WTRU may disable hibernation mode on the condition that it receives L1 control signaling indicating downlink allocation for PDSCH transmissions and / or uplink grant for PUSCH transmissions. For example, a WTRU may disable hibernation mode on the condition that the control signaling is received within a specific subframe, such as within a semi-statically configured set of subframes and / or within the on-duration of DRX active time for multiple consecutive DRX cycles. Alternatively, a WTRU may disable hibernation mode on the condition that it receives L1 control signaling that explicitly indicates the WTRU needs to disable hibernation mode, for example using bits in the DCI format. Alternatively, a WTRU may disable hibernation mode on the condition that the DCI is scrambled with a WTRU-specific RNTI indicating that the WTRU needs to change the state of hibernation mode operation. Alternatively, a WTRU may disable hibernation mode on the condition that it receives PDCCH signaling that triggers a random access procedure.

[0146] Embodiments for deriving scheduling opportunities for WTRU in hibernation mode will be described later in this specification.

[0147] The WTRU can determine a sequence of one or more subframes that can enable the reception of control signaling, including the reception of a PDCCH and the decoding of a DCI scrambled using a specific RNTI. Furthermore, in the case of a DCI addressed to the WTRU's RNTI, the WTRU can buffer at least a portion of the corresponding PDSCH so that the WTRU can decode the corresponding transmission over the PDSCH if necessary.

[0148] In any embodiment described herein, the WTRU may enable and / or disable the reception of control signaling after a fixed number of subframes (e.g., 4 ms or 8 ms) or any period that may correspond to the WTRU processing time.

[0149] Furthermore, other behaviors of the WTRU can be controlled using the period during which the WTRU in idle mode monitors control signaling. For example, the WTRU may perform channel measurements (if configured), report CQI (channel quality indicator), PMI (precoding matrix indicator), and / or RI (rank indicator) (if configured), and transmit SRS (sounding reference signal) (if configured) when monitoring the PDCCH within a subframe that actively monitors the PDCCH or for a WTRU-specific RNTI (e.g., the WTRU's C-RNTI).

[0150] To enable the eNB to keep the WTRU in a time-aligned state, the WTRU can transmit SRS within a subframe in which it monitors control signaling. Alternatively, the WTRU can transmit SRS in special subframes, as detailed below, in response to aperiodic SRS requests when it does not have the correct timing alignment, and / or while the WTRU is monitoring downlink control signaling.

[0151] The WTRU can use the DRX mechanism in a sleep mode of operation, for example, to reduce power consumption. The DRX mechanism provides the WTRU with an opportunity to monitor control signaling, for example, on the PDCCH. The DRX mechanism can be a Layer 3 (e.g., RRC) mechanism, or a Layer 2 (e.g., MAC) mechanism used in RRC_CONNECTED mode, or a modified version thereof.

[0152] The WTRU can enable or disable the reception of downlink control signaling regarding DCI for PDCCH orders to independently perform downlink assignment, uplink grant, and random access procedures. For example, if the WTRU determines that it does not have data available for uplink transmission but needs to monitor control signaling within the relevant subframe, the WTRU may attempt to decode control signaling regarding PDCCH orders to perform downlink assignment and random access procedures.

[0153] A WTRU in hibernation mode can implicitly enable the reception of control signaling for scheduling one or more unicast transmissions using at least one of the following embodiments:

[0154] The WTRU can use a Layer 3 (L3) DRX mechanism. The WTRU can enable the reception of control signaling on the PDCCH and decode one or more DCIs scrambled using the WTRU's assigned RNTI during a WTRU-specific paging opportunity. The RNTI can be the WTRU-specific RNTI (i.e., the WTRU's C-RNTI). The RNTI can be used in attempts to decode on the PDCCH, in addition to other RNTIs (e.g., P-RNTIs) that the WTRU can decode during a paging opportunity. The WTRU can monitor the PDCCH for its C-RNTI during a WTRU-specific paging opportunity, similar to idle-mode procedures. The paging opportunity can be extended by any number of subframes (which may be configurable) that the WTRU can monitor for its assigned RNTI (e.g., the WTRU's C-RNTI).

[0155] Alternatively, a WTRU may use L3 (e.g., RRC) configured opportunities that may differ from WTRU-specific paging opportunities. For example, a WTRU may monitor PDCCH for its C-RNTI for scheduling opportunities. One scheduling frame may correspond to one radio frame, which may contain one or more scheduling opportunities. Scheduling frames and scheduling opportunities can be derived using combinations of formulas and DRX parameters provided by the RRC (either by broadcast or using dedicated signaling). For example, a scheduling frame may be determined as a function of the SFN (system frame number) and the WTRU's identity (e.g., derived from the WTRU's IMSI (international mobile subscriber identity)), and a scheduling opportunity may be determined based on an index to a subframe pattern that can be a function of the WTRU's identity (e.g., derived from the WTRU's IMSI). Alternatively, scheduling frames and scheduling opportunities can be received via dedicated signaling (e.g., RRC), for example, as part of a radio resource configuration procedure or as part of a signaling procedure that constitutes DRX for a WTRU. A WTRU follows a DRX cycle, which corresponds to individual time intervals between monitoring scheduling opportunities for a particular WTRU. A WTRU can monitor at least one scheduling opportunity per DRX cycle.

[0156] Alternatively, the WTRU may use a Layer 2 (L2) DRX mechanism. The WTRU can be configured with one or more DRX configurations for L2 DRX operation, or it may autonomously derive one or more DRX configurations for L2 DRX operation. For example, the WTRU may use multiple configured Layer 2 DRX cycles and / or be configured with additional DRX cycles. For example, the WTRU may enable reception of control signaling on the PDCCH and decode one or more DCIs scrambled using an RNTI assigned to the WTRU from a subframe where a scheduling request is triggered. The RNTI may be a WTRU-specific RNTI (e.g., the WTRU's C-RNTI). The WTRU may monitor the PDCCH for its C-RNTI for subframes in which a scheduling request (SR) is pending. An SR may be triggered (and / or pending) for an SRB (e.g., when new data becomes available for an SRB). SR can be triggered for DRBs (and / or pending) (e.g., when new data becomes available for a DRB). SR can be triggered for DRBs that are not configured as XRBs. SR can be triggered for RBs associated with LCH / LCGs that have a priority higher than a threshold (and / or pending) (e.g., when new data becomes available for a DRB). SR can be triggered (and / or pending) from the availability of sending certain types of L3 messages (e.g., measurement reports), such as serving cells below a threshold.

[0157] Alternatively, the WTRU can enable the reception of control signaling on the PDCCH within a subframe following the transmission of a random access preamble on the PRACH resource. The WTRU can decode RA-RNTI and C-RNTI regarding the random access response when a dedicated preamble is used for RACH.

[0158] In any of the above, the WTRU may extend PDCCH monitoring activity after successfully decoding at least one control signaling, including when a DCI is received with scheduling information (for example, when a DCI is decoded that requests a non-periodic SRS transmission to provide "keep-alive" and / or for timing alignment at the eNB, or when a DCI is decoded that triggers a random access procedure).

[0159] A WTRU in hibernation mode can implicitly disable the reception of control signaling related to unicast transmission scheduling. For example, provided that the WTRU successfully decodes the DCI, the WTRU can extend its PDCCH monitoring activity for several subsequent subframes until the associated timer(s) expire, allowing the WTRU to disable the reception of control signaling until at least the next wake-up opportunity (for example, based on a timer that can be restarted upon successful decoding of the control signaling, and / or using an L2 DRX if configured).

[0160] A WTRU in hibernation mode can enable the reception of control signaling regarding the scheduling of one or more unicast transmissions based on explicit signaling.

[0161] A WTRU can be configured using wake-up opportunities that occur at periodic intervals. Alternatively, a WTRU can enable reception of control signaling on the PDCCH and, after receiving a paging message containing at least one paging record having the WTRU identifier (e.g., the WTRU identity in the paging record that matches one of the WTRU identities assigned by a higher layer or by the RRC), decode one or more DCIs scrambled using the RNTI assigned to the WTRU (e.g., C-RNTI). The paging message may contain specific information about the WTRU, such as the C-RNTI and / or a (dedicated) preamble and / or (dedicated) PRACH resources.

[0162] A WTRU may initiate a random access procedure following the receipt of a paging message. The random access procedure may be performed if the WTRU does not have a valid timing alignment or does not have a configuration for transmission over PUSCH without first having a valid timing alignment (for example, if the WTRU is not permitted to transmit over PUSCH without uplink time alignment).

[0163] In any of the above, the WTRU may extend PDCCH monitoring activity after successfully decoding at least one control signal. For example, the received DCI may include scheduling information, for instance, if the DCI requests a non-periodic SRS transmission (e.g., to provide "keep-alive" and / or for timing alignment at the eNB).

[0164] A WTRU in hibernation mode can disable the reception of control signaling related to the scheduling of one or more unicast transmissions based on explicit signaling. Explicit signaling includes L3 signaling (e.g., RRC), L2 signaling (e.g., MAC CE), and L1 signaling (e.g., DCI with explicit instructions). For example, a WTRU can disable the reception of control signaling upon receiving a MAC DRX CE indicating that the WTRU can stop monitoring the PDCCH. Alternatively, a specific MAC CE can be defined for this purpose. For example, a WTRU can disable the reception of control signaling upon receiving a DCI or a DCI scrambled with a specific RNTI that includes an instruction for the WTRU to disable the reception of control signaling.

[0165] Embodiments relating to downlink data transmission and / or uplink data transmission in idle mode are disclosed later in this specification. Traffic patterns for intermittent transmission of small amounts of data may be characterized by downlink data transfer only (e.g., "keep-alive" type messages from network services), downlink data transfer and subsequent uplink data transfer (e.g., request-response type messages such as requests originating from network services (e.g., location-based services and / or push-based services (e.g., email))), uplink data transfer only (e.g., keep-alive type messages from applications), and uplink data transfer and subsequent downlink data transfer (e.g., request-response type messages such as requests originating from applications within a mobile terminal (e.g., location-based clients and / or fetch-based services (e.g., email clients))).

[0166] A WTRU in hiatus mode can monitor control signaling according to one or more embodiments disclosed herein to determine scheduling opportunities. While in hiatus mode, the WTRU may use connectionless methods or control plane / signaling bearers to transfer small amounts of data. When initiated, the WTRU may perform any of the following procedures for each corresponding data transfer:

[0167] The WTRU can be scheduled for uplink transmission during times when the WTRU may not have the correct timing alignment (for example, when the TA timer expires with respect to the WTRU).

[0168] In one embodiment, a WTRU can be configured for uplink transmissions within a special subframe that can tolerate timing misalignment. The special subframe may include at least one guard period (e.g., a sufficiently large number of symbols, which may be based on the cell size) to prevent large timing misalignments from interfering with other intra-cell transmissions in adjacent subframes. For example, one guard period may be defined at the beginning and / or end of the subframe. Within the special subframe, the WTRU can perform unsynchronized transmissions (e.g., random access procedures including RACH preamble transmissions, PUCCH transmissions, or PUSCH transmissions on a PRACH resource). Random access within the special subframe can be contention-free.

[0169] A WTRU may receive dedicated signaling (e.g., RRC) that constitutes one or more special subframes in a semi-static form (e.g., periodic in time). Alternatively, a WTRU may receive dynamic PDCCH control signaling (e.g., Grant DCI for PUSCH transmission). Or, a WTRU may receive broadcast signaling that exhibits one or more special subframes and / or periodicity (e.g., system information broadcasts on BCCH (broadcast control channel)). The network can handle all possible intra-cell and inter-cell interference through appropriate allocation of uplink resources. For example, such subframes may be recursive subframes (e.g., each of the X subframes in a radio frame, where X can be 1 or more).

[0170] Other WTRUs may not be permitted to transmit within a special subframe. The format of a special subframe may be understood by one or more WTRUs that support transmission within that special subframe. For WTRUs that do not support transmission within a special subframe, the special subframe may be configured as an MBSFN (multicast / broadcast over a single frequency network) subframe. This should ensure backward compatibility for unsupported WTRUs while preventing intra-cell and inter-cell interference within the special subframe.

[0171] A WTRU without proper timing alignment can perform uplink transmissions on a PUSCH resource within a special subframe according to PDCCH control signaling, but cannot perform PUSCH transmissions on other subframes. The special subframe may not be limited to PUSCH or PRACH transmissions, but may apply to SRS transmissions (if configured) or any other physical channel transmissions. This is referred to as "uplink transmission within a special subframe."

[0172] For special subframes, the WTRU can be configured using at least one of the following: parameters for decoding and processing dynamic downlink control signaling that schedules uplink transmissions on a competition-based PUSCH (CB-PUSCH) that includes a specific RNTI (e.g., CB-RNTI) to be monitored on the PDCCH; a subframe from which the WTRU can decode control signaling for CB-PUSCH transmissions; a subframe from which the WTRU can perform transmissions on a CB-PUSCH resource; or similar. This configuration can be similar to an SPS configuration in terms of resource periodicity, parameters such as RNTI, resource allocation (e.g., resource blocks), and MSC (modulation and coding scheme).

[0173] The WTRU can periodically monitor and decode the DCI scrambled using CB-RNTI on the PDCCH to determine the parameters for performing uplink transmission. The WTRU can decode the control signaling provided that it has data available for transmission, the data corresponds to an XRB, the WTRU has a BSR (buffer status report) to transmit, or the WTRU has valid uplink timing synchronization.

[0174] A WTRU can receive a dedicated PRACH resource valid for one or more WTRU-specific subframes. For a WTRU-specific subframe, the WTRU can be configured with at least one of the following: dedicated parameters for transmission over the PRACH resource, a dedicated preamble (ra-PreambleIndex), a PRACH mask index (PRACH-Mask-index), a maximum number of preamble retransmissions, or similar. For example, a WTRU can be configured with a dedicated preamble (e.g., for contention-free transmission over the PRACH resource) and / or a dedicated PRACH resource (e.g., for multiplexing different WTRUs for a given subframe). The WTRU can perform transmission over PRACH using configuration within a subset of subframes. This subset of subframes can be configured by the network using, for example, periodicity, a bitmask applicable to multiple subframes (e.g., one or more frames), and / or a function of the SFN (system frame number). This procedure is referred to as "CFRA transmission on a WTRU-specific subframe."

[0175] A WTRU can be configured with multiple sets of PRACH parameters to convey additional information to the network. Such information may include requests for uplink resources, including HARQ feedback, resources related to one or more XRBs, and / or resources related to non-XRB radio bearers (e.g., those with higher priority). Parameters that can be configured to convey such information include separate sets of PRACH resources, different sets of WTRU-specific subframes for PRACH, and / or different sets of dedicated preambles. For example, when a WTRU performs a preamble transmission on a WTRU-specific PRACH opportunity to request uplink resources, the WTRU may choose either a first dedicated preamble to indicate a scheduling request (i.e., RA-SR (scheduling request via random access procedure)) regarding the type of data in the WTRU's buffers (including BSR) or a second preamble to indicate an SR for data corresponding to an XRB. Alternatively, the first preamble could indicate an XRB SR (for uplink transmission of user data while remaining in hibernation mode), and the second preamble could relate to an SRB (for example, to request an RRC connection to exit hibernation mode). Alternatively, relating to the previous example above, instead of choosing between the first and second preambles, the WTRU could instead choose between a first WTRU-specific subframe and a second WTRU-specific subframe. Alternatively, the WTRU could choose between a first PRACH resource and a second PRACH resource. Alternatively, provided the WTRU has valid uplink timing alignment, the WTRU could choose between a first configuration for scheduling requests such as PRACH configurations and a second configuration for scheduling requests such as PUCCH configurations for D-SRs.

[0176] A WTRU can perform a preamble transmission in a WTRU-specific PRACH opportunity (i.e., within a WTRU-specific subframe) to send HARQ feedback corresponding to one or more (e.g., bursts) transmissions or retransmissions, for example, regarding XRBs. The WTRU may select a first preamble to correspond to a HARQ acknowledgment or to acknowledging the entire burst. The WTRU may select a second preamble to perform RA-SA and / or to indicate a HARQ NACK. An RLC report that allows the network to determine whether or not to perform a retransmission in the RLC may be included in the first uplink transmission. Alternatively, instead of selecting between the first and second preambles, the WTRU may instead select between the first WTRU-specific subframe and the second WTRU-specific subframe. Alternatively, the WTRU may select between the first PRACH resource and the second PRACH resource. Alternatively, the WTRU can select a preamble used to indicate the HARQ feedback (e.g., HARQ ACK) as a function of the DCI's first CCE (Control Channel Element) received on the PDCCH signaling scheduled by the DCI for the downlink transmission sent with respect to it. If the feedback corresponds to multiple transmissions (e.g., a burst), the selected preamble can be a function of the DCI that scheduled the last transmission in the burst. If the feedback corresponds to multiple transmissions (e.g., a burst), the HARQ feedback can be an ACK conditional on all downlink transmissions in the bundle being successfully received. Alternatively, the preamble can be sent conditional on at least one transmission in the burst being successfully received. The selected preamble can be a function of the number of successfully received transmissions in a burst, for example, with respect to a series of transmissions starting from the last transmission for which no affirmative acknowledgment was sent.

[0177] Alternatively, a WTRU in hiatus mode may use conventional procedures to access the network in subframes other than WTRU-specific subframes for data other than data related to XRBs (BSRs may be excluded). For example, a WTRU may use random access procedures with cell parameters or other dedicated parameters that may not correspond to those related to PRACH transmissions concerning WTRU-specific subframes, or it may use scheduling requests on PUCCH, provided that the WTRU has valid uplink synchronization, to establish an RRC connection and / or request dedicated transmission resources when data for which hiatus behavior is inappropriate becomes available for transmission. Such data may correspond to data with higher priority (e.g., SRB data, DRB data). Such data may correspond to data relating to any radio bearer other than XRBs in the WTRU configuration. Alternatively, if a WTRU receives a control signaling on PDCCH requesting the WTRU to perform a random access procedure, the WTRU may perform a conventional random access procedure.

[0178] A WTRU operating in hiatus mode may initiate a procedure to obtain a valid uplink timing alignment if the WTRU does not have a valid uplink timing alignment (for example, if TAT is not operating at least with respect to the primary serving cell) (e.g., random access including CFRA transmissions in WTRU-specific subframes or SRS transmissions in special subframes if configured). A WTRU in hiatus mode may be configured to obtain timing alignment on the condition that it receives a successful downlink control signaling indicating a PDSCH assignment (allowing the WTRU to subsequently transmit a HARQ A / N over PUCCH) or a downlink control signaling indicating a PUSCH grant (allowing the WTRU to subsequently transmit over PUSCH) (e.g., by a higher layer). If the WTRU does not have a valid timing alignment within the subframe in question, the WTRU may refrain from performing a transmission over PUSCH with respect to the grant.

[0179] A WTRU operating in hibernation mode may initiate a procedure to obtain a valid uplink timing alignment if it has data available for transmission in its buffer (for example, a BSR has been triggered), or if it has a pending scheduling request, or if it determines that it needs to obtain a valid timing alignment while in hibernation mode (for example, to initiate a random access procedure).

[0180] With regard to downlink data transfer, a WTRU operating in hibernation mode can receive and decode dedicated downlink assignments (one or more) on the PDCCH (e.g., scrambled using C-RNTI) regardless of whether the WTRU has a valid TA (Time Alignment). If the WTRU has a valid TA, it can transmit HARQ A / N feedback (e.g., on the PUDCH). Otherwise, the WTRU may choose not to transmit HARQ A / N feedback. Alternatively, the WTRU can perform a CFRA transmission within a WTRU-specific subframe to obtain uplink timing synchronization and / or to acknowledge a downlink transmission.

[0181] For downlink data transfers that are followed by uplink data transfers, a WTRU operating in hibernation mode can receive and decode dedicated downlink assignments (one or more) on the PDCCH (e.g., scrambled using C-RNTI) regardless of whether the WTRU has a valid TA. If the WTRU has a valid TA, it can send HARQ A / N feedback (e.g., on the PUCCH) after receiving downlink transmissions. Alternatively, a WTRU operating in hibernation mode can receive and decode control signaling on the PDCCH (e.g., scrambled using C-RNTI) that instructs the WTRU to perform random access procedures, specifically if the WTRU does not have a valid TA. If the WTRU has a valid TA, it can receive and decode control signaling (e.g., uplink grants) on the PDCCH (e.g., scrambled using C-RNTI) regarding uplink transmissions on a dedicated PUSCH resource. Alternatively, a WTRU can transmit over a dedicated PUSCH resource using a special subframe if the grant timing corresponds to a special subframe and the WTRU does not have valid timing alignment. A WTRU can receive and decode control signaling (e.g., uplink grants) on a PDCCH (e.g., scrambled using CB-RNTI (contention-based RNTI)) with respect to contention-based uplink transmissions on PUSCH. A WTRU can transmit over a PUSCH resource if the WTRU has valid TA. A WTRU can transmit over a PUSCH resource within a special subframe if the WTRU does not have valid timing alignment and / or if the grant timing corresponds to a special subframe.

[0182] A WTRU can initiate a scheduling request (SR) procedure using a valid PUCCH resource, either by using a CFRA transmission within a WTRU-specific subframe if configured, or by using a random access procedure. A WTRU can initiate an SR procedure provided that a competition-based grant is not available for the subframe in question. For example, a PUCCH resource for a D-SR could be configured for use while in hibernation mode. Alternatively, the method and / or resources to be used for an SR could be signaled within a downlink transmission, such as a MAC CE.

[0183] With regard to uplink data transfer, a WTRU operating in idle mode can initiate an SR procedure using a valid PUCCH resource for the SR, either by using CFRA transmission within a WTRU-specific subframe if configured, or by using a random access procedure. A WTRU can initiate an SR procedure provided that it is not available with respect to the subframe in which a competition-based grant is involved.

[0184] A WTRU can receive and decode control signaling (e.g., uplink grants) on the PDCCH (e.g., scrambled using C-RNTI) for uplink transmissions. A WTRU can transmit on a dedicated PUSCH resource, provided that the WTRU has a valid TA. Alternatively, a WTRU can transmit on a dedicated PUSCH resource within a special subframe if the grant timing corresponds to a special subframe and the WTRU does not have a valid timing alignment.

[0185] A WTRU can receive and decode control signaling (e.g., uplink grants) on a PDCCH (e.g., scrambled using CB-RNTI) with respect to competition-based uplink transmissions on a PUSCH. In this case, the WTRU can transmit on a PUSCH resource if the WTRU has a valid TA, or on a PUSCH resource in a special subframe if the WTRU does not have a valid timing alignment and / or the timing of the grant corresponds to a special subframe.

[0186] For uplink data transfers that are followed by downlink data transfers, a WTRU operating in idle mode may initiate an SR procedure using a valid PUCCH resource for the SR, either by using a CFRA transmission within a WTRU-specific subframe or by using a random access procedure. A WTRU may initiate an SR procedure provided that it is not available with respect to the subframes involved in the competition-based grant.

[0187] A WTRU can receive and decode control signaling (e.g., uplink grants) on a PDCCH (e.g., scrambled using C-RNTI) for uplink transmissions. A WTRU can transmit on a dedicated PUSCH resource, provided that the WTRU has a valid TA, or on a dedicated PUSCH resource within a special subframe if the grant timing corresponds to a special subframe and the WTRU does not have a valid timing alignment.

[0188] A WTRU can receive and decode control signaling (e.g., uplink grants) on a PDCCH (e.g., scrambled using CB-RNTI) with respect to competition-based uplink transmissions on a PUSCH. In this case, the WTRU can transmit on a PUSCH resource if the WTRU has a valid TA, or on a PUSCH resource in a special subframe if the WTRU does not have a valid timing alignment and / or the timing of the grant corresponds to a special subframe.

[0189] Furthermore, regardless of whether the WTRU has a valid time alignment, it can receive and decode one or more dedicated downlink assignments on the PDCCH (e.g., scrambled using C-RNTI). If the WTRU has a valid TA, it can transmit HARQ A / N feedback (e.g., on the PUCCH).

[0190] Embodiments relating to channel quality measurement and reporting in hiatus mode are disclosed later in this specification. A WTRU operating in hiatus mode can be configured using channel condition reporting such as a CQI (channel quality indicator), PMI (precoding matrix indicator), RI (rank indicator), or similar. The WTRU can retain the CQI configuration when it does not have a valid timing alignment. For example, the WTRU may not apply the default physical channel configuration for CQI-ReportConfig and cqi-Mask when TAT expires.

[0191] A WTRU can measure and report channel status information such as CQI, PMI, and / or RI for subframes in which the WTRU monitors control signaling on the PDCCH. The WTRU can measure and report starting from a subframe in which the WTRU successfully decodes the control signaling. For example, the WTRU can measure and report CQI, PMI, and / or RI within subframes in which the WTRU monitors control signaling on the PDCCH, starting from a subframe in which the WTRU successfully decodes the control signaling. The above can be applied to SRS configuration parameters (e.g., soundingRS-UL-ConfigDedicated) and procedures.

[0192] Embodiments for performing mobility-related procedures in idle mode are disclosed later in this specification.

[0193] A WTRU operating in hibernation mode can support both network-controlled mobility (e.g., using configured L3 measurements) and WTRU autonomous mobility (e.g., using cell reselection).

[0194] A WTRU operating in hibernation mode can perform cell reselection, provided that L3 measurements are not configured, or during periods when the WTRU is not actively scheduled by the network for unicast transmissions.

[0195] A WTRU operating in idle mode can perform L3 measurements and measurement reporting with fewer requirements regarding measurement intervals compared to the RRC_CONNECTED state. A WTRU can perform L3 measurements and reporting during periods when it is actively scheduled by the network for unicast transmissions. A WTRU can release cell-specific WTRU-only parameters when mobility events occur while it is in idle mode. For example, a WTRU can release all dedicated configurations for random access, C-RNTI, scheduling opportunities, DRX, and / or configurations for measurements, as well as similar ones that may have remained active while in idle mode. Such mobility events include, but are not limited to, receiving an RRC connection reconfiguration message (handover command) regarding mobility control IE, initiation of a cell (re)selection procedure, a cell (re)selection procedure resulting in the selection of a cell different from the current serving cell, traffic area updates, transition to RRC_IDLE mode, and / or cessation of use of idle behavior.

[0196] A WTRU operating in hibernation mode can be configured with L3 measurements, and when configured, the WTRU can perform measurements during periods actively scheduled by the network for unicast transmissions. For example, the WTRU can perform L3 measurements during a time period, starting from the subframe in which the WTRU first receives control signaling for downlink allocation and / or uplink grant, until, for example, a timer expires (e.g., a TA timer or any other activity timer) or until the WTRU stops monitoring control signaling. The WTRU can report measurements when triggered by an event during periods actively scheduled by the network for unicast transmissions.

[0197] Embodiments of cell reselection and mobility controlled by the WTRU are disclosed later in this specification. A WTRU operating in idle mode may perform a cell reselection procedure according to idle mode procedures. A WTRU may perform a cell reselection procedure if it has successfully received an explicit instruction to begin monitoring control signaling, but has not successfully decoded dedicated control signaling after a certain period of time. A WTRU may perform an initial connection establishment procedure within the selected cell.

[0198] If a cell reselection procedure leads to the selection of a cell different from the cell in which the WTRU operates, the WTRU may do at least one of the following: If cell reselection occurs while the WTRU is actively scheduled, the WTRU may enter idle mode and perform the initial connection establishment procedure within the selected cell. If cell reselection occurs while the WTRU is not actively scheduled, the WTRU may enter idle mode and camp in the selected cell. Alternatively, the WTRU may perform the initial connection establishment procedure within the selected cell.

[0199] If a cell reselection occurs after the WTRU has successfully received an explicit instruction to begin monitoring control signaling, but before the WTRU is actively scheduled, the WTRU may enter idle mode and perform the initial connection establishment procedure within the selected cell.

[0200] In any of the embodiments described above, the WTRU may first attempt a connection re-establishment procedure within the selected cell. If the WTRU is configured for measurement reporting and performs an L3 measurement, the WTRU cannot perform a cell re-selection procedure, for example, if it performs an L3 measurement while the WTRU is actively scheduled.

[0201] Embodiments of configuring a radio bearer (XRB) for intermittent service are disclosed later in this specification. A WTRU can be configured with XRBs associated with one or more EPS (evolved packet system) bearers. For example, a WTRU can be configured with one or more XRBs, each associated with a value corresponding to an EPS bearer (e.g., an eps-BearerIdentity value). When a dormant mode is activated, the WTRU can use the XRBs to transmit user data (e.g., excluding control plane data) corresponding to the EPS bearers involved. One or more EPS bearers can be associated with a given XRB.

[0202] In another embodiment, the WTRU can be configured using a single XRB. This can be the default behavior, or it can be indicated using either a flag or a fixed code point relating to the value of eps-BearerIdentity. When the hiatus behavior is activated, the WTRU can use the XRB to transmit any user data (e.g., excluding control plane data) corresponding to any of the EPS bearers in the WTRU's configuration. This can be applied to the EPS bearers configured when the WTRU begins using the hiatus behavior.

[0203] In another embodiment, the WTRU can be configured with one XRB for each configured RB, for example, one XRB for each DRB in the WTRU configuration. For example, when the hiatus behavior is activated, the WTRU can use the XRB to transmit any user data (e.g., excluding control plane data) corresponding to the relevant RB (e.g., DRB) in the WTRU configuration.

[0204] In another embodiment, the WTRU can be configured with one XRB for each default EPS bearer in the WTRU configuration. When the hibernation behavior is activated, the WTRU can use the XRB to transmit any user data (e.g., excluding control plane data) corresponding to the relevant EPS bearer in the WTRU configuration. This can be applied to bearers configured when the WTRU begins using the hibernation behavior.

[0205] In another embodiment, the WTRU can be configured with a default XRB. When the hiatus behavior is activated, the WTRU can use the default XRB to send user data (e.g., excluding control plane data) corresponding to any EPS bearer that is not explicitly associated with another XRB. This can be applied to EPS bearers that share a similar context (e.g., with respect to applications using the same source IP address). This can be applied to EPS bearers configured when the WTRU receives a configuration to add an XRB.

[0206] Any of the above alternatives can be implemented so that the DRB operates as an XRB when the hibernation behavior is activated. When the hibernation behavior is deactivated and the WTRU remains connected, the XRB can revert to its normal DRB operation.

[0207] For a given XRB, the WTRU can be configured to transmit a subset of user data (excluding control plane data, for example) related to a given EPS bearer using the configured XRB when the quiescent behavior is activated. Such data can be identified using any of the flow classification and routing embodiments described in detail below.

[0208] A WTRU can process user data unrelated to XRB according to the applicable methods when quiescent behavior is not applicable. For example, with respect to an unsynchronized WTRU with activated quiescent behavior, new data that becomes available for transmissions that cannot be sent using XRB can trigger scheduling of requests using random access to request uplink resources to enable transmissions using DRB (if the WTRU does not have an established RRC connection) and / or DRB.

[0209] A WTRU can be configured not to trigger a BSR and / or SR when new data becomes available for an XRB (for example, based on the parameter logicalChannelSR-Mask-R1x in the LogicalChannelConfiguration IE). This can be applied when hiatus behavior is activated. For example, a WTRU using hiatus behavior can trigger a BSR and / or SR when new data becomes available for a DRB or SRB that is not configured as an XRB (or is not associated with one). A WTRU can trigger a BSR and / or SR for an XRB that is configured so that BSR and / or SR triggers are allowed according to the WTRU configuration. In another example, a WTRU using hiatus behavior can trigger a BSR and / or SR when new data becomes available for an XBR that is configured so that BSR and / or SR are not prohibited according to the WTRU configuration.

[0210] A WTRU can initiate a procedure for transmitting data on an uplink resource within a special subframe when new data becomes available for XRB. A WTRU can initiate such a procedure when hiatus behavior is activated.

[0211] The logical channel configuration (LCH) of an XRB can be, for example, not associated with a logical channel group (LCG) within a LogicalChannelConfiguration IE. The logical channel configuration of an XRB can have a lower priority than that of an SRB. An XRB can have the lowest priority among the radio bearers in a WTRU configuration. This can be applied when dormancy behavior is activated.

[0212] The XRB configuration can include explicit instructions (for example, using the parameter logicalChannelDormant-Mask-R1x in the LogicalChannelConfiguration IE) to allow the WTRU to determine whether the XRB in question can be used as a DRB for user plane traffic that can benefit from the dormant behavior.

[0213] A WTRU can configure an XRB for operations where header compression is not configured. A WTRU can transmit data over an XRB where security is not activated (e.g., without encryption). This can be a configurable mode of the XRB. A WTRU can be configured so that the XRB uses RLC UM (RLC Unacknowledged Mode) operation. A WTRU can be configured so that RC segmentation is not permitted for data transmission while operating in hibernation mode (e.g., with respect to data corresponding to the XRB). A WTRU can disable hibernation behavior for relevant data transfers when data transmission cannot be handled by an unsegmented transport block.

[0214] A WTRU can be configured using one or more XRBs. When multiple XRBs are configured, each XRB can be configured to support different levels of QoS, including but not limited to parameters such as priority (e.g., priority in LogicalChannelConfig IE), SDU discard timer (e.g., discardTimer in PDCP-Config IE), bucket size duration (e.g., bucketSizeDuration in LogicalChannelConfig IE), PBR (prioritized bit rate) (e.g., prioritizedBitRate in LogicalChannelConfig IE), or similar.

[0215] With respect to the control plane, the WTRU can process control plane data unrelated to the XRB (e.g., data related to the SRB) according to any applicable method when the pause behavior is not applicable.

[0216] A WTRU may have one XRB for SRB0. SRB0 can be used to (re)establish an RRC connection and / or transition to RRC connection mode. A WTRU may further have one XRB for SRB0 and one XRB for both SRB1 and SRB2. Alternatively, a WTRU may have one XRB for each SRB (i.e., SRB0, SRB1, SRB2). Alternatively, a WTRU may further have one XRB for all SRBs. Alternatively, an XRB may be configured by the SRB configured to transmit user data with control signaling.

[0217] Embodiments relating to flow classification and routing are disclosed later in this specification. A WTRU can be configured with XRBs associated with one or more EPS bearers related to a single PGW, or with XRBs associated with EPS bearers from multiple PGWs. When a WTRU is configured with XRBs associated with traffic from multiple EPS bearers, the eNB can perform flow classification of user data and routing to the correct PGW. Alternatively, when a WTRU is configured with XRBs associated with traffic from multiple EPS, the WTRU can perform flow classification of user data and routing to the correct PGW. Alternatingly, a WTRU can be configured with XRBs associated with a specific APN (access point name), i.e., there may be one or more XRBs per APN to which the WTRU is connected. In this case, the WTRU can perform traffic flow classification of user data and routing to the appropriate APN. When these APNs are accessed via the same P-GW, the P-GW can distinguish traffic by APN and route packets to the correct network.

[0218] A WTRU with hiatus behavior activated can perform flow classification on traffic generated by different services and / or applications. A WTRU can be configured with multiple packet filters and / or traffic flow templates (TFTs). A WTRU can be configured with a first set of packet filters and / or TFTs that can be used when hiatus behavior is not activated, and a second set that can be used otherwise.

[0219] The WTRU can determine when it can transfer data using XRB by using configured and applicable packet filters and / or TFTs. These packet filters can be configured within the WTRU by the MME. The MME can send packet filters in bearer activation messages, bearer change messages, or new dedicated NAS messages to the WTRU when an EPS bearer is set up. It can be specified in the NAS message that there are different sets of packet filters that may be applied differently depending on whether the WTRU is in connected mode or dormant mode. Alternatively, a dormant mode packet filter can be sent to the WTRU when it enters dormant mode. This can be done by a NAS message informing the WTRU to enter EMM-Dormant mode.

[0220] The WTRU can provide further information related to routing and flow classification to the eNB. For example, such information may include details related to the number of DRBs and / or packet size (e.g., average, maximum, minimum), inter-packet delay and / or inter-burst delay (e.g., average, maximum, minimum), the number of packets in a burst, and the protocol type (e.g., TCP (Transmission Control Protocol), UDP (User Datagram Protocol), RTP (Real-Time Transmission Protocol), RTCP (Real-Time Transmission Control Protocol)). The eNB can use this information to correctly configure the WTRU with respect to hiatus behavior, including XRB configuration. The eNB can use this information to perform the correct mapping of data received with respect to a given XRB to the S1-U bearer on the link heading to the SGW.

[0221] Alternatively, XRB data can be supplied to an equivalent S1-U XRB destined for the SGW. Similar functionality can be implemented at the SGW to map packets to the correct S5 bearer destined for the PDN GW. This implies the setup of an equivalent S1-U XRB between the eNB and the SGW (when entering always-on or hibernation mode, or when the XRB is set up).

[0222] An extension to the packet filter can provide an additional means of classifying packets so that they can be received by the WTRU, for example, for flow classification, by providing at least one of the following:

[0223] Packet filters can include parameters related to packet size (e.g., maximum or minimum size). The size can be derived from the length field of the IP header or transport header. Alternatively, the size can be derived from the PDCP (packet service data unit) or SDU (service data unit) size (uncompressed IP header).

[0224] A packet filter may include metrics applicable to the filter, which may include at least one of the following: a value for inter-packet arrival time for a given rule of the filter, a parameter representing burst characteristics (number of transmissions within a given time), an inter-packet arrival time value for a given rule of the filter, or the rate at which the rule is being matched by packets. These values ​​can be used as thresholds and as additional rules to validate filter entries.

[0225] Embodiments that trigger the WTRU's hibernation behavior can be applied at the packet filtering and TFT layers based on observations of how packets are filtered and / or behavior regarding packet classification. When such a trigger is present, the WTRU can enter or exit hibernation behavior, send a NAS service request message or a NAS service update message, or change the RRC / NAS state. After the WTRU enters hibernation mode, the WTRU can switch packet filters and begin routing data toward the XRB, or the packet filters may be configured such that the WTRU discards some of the background traffic. Alternatively, the WTRU may choose to use a connectionless method (i.e., sending data over the control plane) to send data.

[0226] Embodiments of session management relating to a Radio Access Bearer (RAB) having hiatus behavior are disclosed later in this specification. When a WTRU has hiatus behavior activated and the WTRU performs either a WTRU autonomous procedure such as a mobility-related procedure (e.g., a cell (re)selection procedure that changes the cell where the WTRU is camping) or a procedure controlled by an eNB (e.g., a handover to a different cell when the WTRU implements hiatus mode behavior as an extension of connection mode), the WTRU may perform at least one of the following: The WTRU may retain at least an XRB within the context of the WTRU unless hiatus mode is deactivated or indicated otherwise by explicit signaling (e.g., an RRC connection reconfiguration message with mobility control IE (i.e., a handover command)). The WTRU may retain all DRBs (one or more) associated with the XRB.

[0227] With regard to WTRU autonomous procedures, a WTRU can initiate a new service request to re-establish a radio access bearer. The WTRU can perform this service request either using RRC signaling (for example, a target eNB can establish a connection with the connected MME) or using NAS procedures. This may apply if the RAB is not held and is released autonomously following a WTRU autonomous mobility event.

[0228] Regarding WTRU autonomous procedures, a WTRU can initiate a procedure so that it can indicate its new location to the network. This can provide a means for the network to set up the WTRU's context to the target eNB. For example, a WTRU can initiate a TAU (tracking area update) procedure. The TAU procedure may include instructions that resources can be allocated for the EPS bearer in the WTRU's context.

[0229] Regarding WTRU autonomous procedures, a WTRU can deactivate its quiescent behavior, including releasing all configured XRBs. The WTRU can then initiate a procedure that allows it to indicate its new location to the network. This can provide a means for the network to establish an RRC connection with the WTRU so that quiescent behavior can be reconfigured if necessary. For example, a WTRU can initiate a TAU procedure. The TAU procedure may include instructions that resources must be allocated for the EPS bearers in the WTRU's context.

[0230] The above embodiments can be applied when a WTRU wishes to terminate or attempts to terminate hibernation behavior. Termination of hibernation mode may result from the need to set up resources for additional user plane traffic, traffic requiring one or more dedicated bearers, or from pending NAS session management procedures (activation, modification, or deactivation of at least one dedicated EPS bearer). A WTRU may terminate hibernation mode as a result of manual CSG (closed subscriber group) selection. If the termination of hibernation mode is controlled by the RRC (or lower tier), the NAS can provide the RRC (or lower tier) with instructions (based on the triggers listed above) that may lead to the RRC (or lower tier) terminating hibernation mode.

[0231] NAS signaling can be extended to support hibernation mode. A WTRU may determine that additional resources are needed for hibernation mode operation, either because the WTRU determines that hibernation mode needs to be activated, or because it is already using hibernation behavior but requires additional resources to operate in hibernation mode. In that case, the WTRU may be permitted to initiate a NAS service request procedure. The WTRU may initiate a NAS service request procedure in the current RRC mode (e.g., CONNECTED, DORMANT, IDLE) and / or EMM states that support hibernation behavior (e.g., EMM-CONNECTED, EMM-DORMANT, EMM-IDLE). The WTRU may be permitted to send a NAS service request in connected mode. This procedure, if accepted by the network, can trigger the setup of additional resources for the dedicated bearer(s) or default bearer(s) that are active with respect to the WTRU. Alternatively, the WTRU may receive a NAS response when the network initiates a change to the resources currently allocated to the WTRU. This response can be a new NAS message, an existing session management message, or a mobility management message (for example, with additional IE).

[0232] A WTRU may determine that additional resources are needed, for example, because it determines that it needs to deactivate hibernation mode. In that case, the WTRU may be permitted to initiate a NAS service request procedure. In other words, a WTRU may initiate a NAS service request procedure in RRC mode (e.g., CONNECTED, DORMANT, IDLE) and / or EMM states that support hibernation behavior (e.g., EMM-CONNECTED, EMM-DORMANT, EMM-IDLE). Alternatively, a WTRU may receive a NAS service request when the network begins to make changes to the resources currently allocated to the WTRU.

[0233] The setup of additional resources resulting from a NAS service request procedure initiated by a WTRU, or a network-initiated NAS service request procedure (i.e., paging and subsequent NAS service requests from a WTRU), or any dedicated NAS message triggering a NAS service request (or similar NAS procedure) by a WTRU, may result in the WTRU terminating or deactivating the hibernation behavior. Alternatively, the WTRU may be permitted to directly send a NAS session management message (to request the setup, modification, or deactivation of the EPS bearer context) before sending a NAS service request or a similar NAS message such as a NAS service update. Extended NAS service requests can be used to request the activation or deactivation of hibernation behavior.

[0234] Similar to the extended NAS service requests described above, a new NAS service update message can be introduced to modify the dedicated resources of a WTRU and / or request the activation or deactivation of dormant behavior. The behavior of a NAS service update can be similar to that described above for extended NAS service requests.

[0235] The WTRU may perform any of the embodiments described above relating to mobility management at the NAS layer in order to request additional user plane resources or to perform NAS session management procedures. Furthermore, the WTRU may perform any one or a combination of the following embodiments: The WTRU may perform management of radio bearers (e.g., XRBs) that can be used while in hibernation mode. For example, the WTRU may perform setup or reactivation of at least one radio bearer, or disassembly or deactivation of at least one radio bearer. The WTRU may perform management of radio bearers (e.g., one or more EPS RABs) that can be used when the WTRU exits hibernation mode. The WTRU may perform setup or reactivation of at least one radio bearer, or disassembly or deactivation of at least one radio bearer.

[0236] The NAS service request procedure is conventionally used for WTRUs in idle mode. Extensions to session management can be defined to enable operation with hiatus behavior. This specification provides an embodiment that allows a WTRU in hiatus mode to request more resources for other bearers. This implies resource allocation on both the radio interface and the S1 interface, thereby requiring the MME to be aware of this request in order to set up both radio and S1 resources.

[0237] The WTRU can perform at least one of the following procedures while in hibernation mode for the management of the radio bearer:

[0238] In one embodiment, a WTRU can execute a NAS service request or NAS service update initiated by the WTRU while in hibernation mode. The WTRU can initiate a NAS procedure with an MME to modify user plane resources. For example, a WTRU can send a NAS message (e.g., either an extended NAS service request or a NAS service update) to indicate to the MME that user plane resources (e.g., relating to at least one dedicated bearer) are needed. The NAS message may include a list of dedicated bearers for which resources are requested and may include a time parameter or flag parameter that can be used to indicate the duration of time for which the resources are needed. For example, a particular application of the WTRU may require the transmission of a relatively large amount of data over a short period of time (e.g., via consecutive transmissions), and the resources will no longer be needed after a certain time interval. Setting up resources for the requested bearer(s) may result in the WTRU exiting hibernation mode. Alternatively, sending a NAS message may result in the WTRU exiting hibernation mode or deactivating it. The WTRU can then receive a NAS message acknowledging receipt of the WTRU's NAS request, which may indicate that the WTRU can exit hibernation mode or deactivate it. The resource setup for the requested bearer(s) may result in the WTRU exiting hibernation mode.

[0239] The MME can receive NAS messages from the WTRU (for example, either an extended NAS service request or a NAS service update). When the MME receives a NAS message, it can establish the user plane of the EPS bearers that are active within the context of the WTRU. The MME can know that the WTRU is in hibernation mode. Alternatively, the received NAS message may include an indicator of which EPS bearers require user plane resources. The MME can take into account time factors or other parameters that may be included in the NAS message so that the resources are set up over a specific time period. The MME can then inform the serving eNB to set up resources for at least one dedicated bearer and / or default bearer (using an existing or new message via the S1AP interface). The MME can include additional parameters, such as the time interval during which the resources must be held, in the control signaling directed to the eNB. The MME can operate a timer with an indicated value so that it can inform the eNB to release resources for one or more dedicated bearers and / or default bearers after the timer expires. The MME can send a message to the WTRU acknowledging receipt of the NAS message and can also inform the WTRU to exit hibernation mode.

[0240] The eNB can receive S1AP messages (new or existing) from the MME to set up resources for the WTRU in hibernation mode. The eNB can then reconfigure the WTRU to exit hibernation mode. The eNB can start a timer according to the instructions in the received message so that the set-up resources can be released after the timer expires. After this timer expires, the eNB can reconfigure the WTRU to operate in hibernation mode.

[0241] In another embodiment, the MME can initiate the NAS request described above.

[0242] In another embodiment, the NAS can provide the RRC with information about the type of request (e.g., user plane resource setup, NAS session management signaling, NAS signaling, etc.). The WTRU RRC can send an RRC message to the eNB to request a transition from hibernation mode, for example, when triggered to exit hibernation mode. Alternatively, the WTRU RRC can further inform the eNB about pending requests that do not necessarily request the exit from hibernation mode. These may include information about requests at a higher layer (e.g., the NAS).

[0243] The eNB receives an RRC message from the WTRU in hibernation mode. This RRC message may contain instructions to exit hibernation mode or instructions related to the NAS protocol. Based on any previous configurations that may have been received (e.g., from the MME), the eNB can decide whether to transition the WTRU out of hibernation mode. For example, when the WTRU was first put into hibernation mode, the MME may have informed the eNB that all future requests to set up resources for additional bearers could be granted without permission from the MME. Alternatively, the MME may have informed the eNB that all transitions from (or to) hibernation mode may require permission from the MME.

[0244] The eNB can inform the MME regarding paging requests, which can authorize the WTRU to exit hibernation mode. Alternatively, the eNB can forward additional information received from the WTRU to the MME. For example, if the eNB receives a message to set up resources for at least one dedicated bearer, the eNB can indicate to the MME that the WTRU requires additional resources for at least one dedicated bearer. The eNB can wait for the MME to accept or reject the request before proceeding. The eNB may include a TEID (tunnel endpoint identity) that can be used by the SGW (Serving Gateway) for S1-U resource routes. The MME can forward this information to the SGW if the request is granted. Furthermore, the MME can forward the TEID (received from the SGW) to the eNB, which will then enable the setup of the user plane route for uplink data.

[0245] The RRC procedure described above can be applied when the NAS is not permitted to send service requests or other messages while the hibernation mode is a sub-state of connected mode.

[0246] Figure 5 is a signaling diagram of process 500 in an example of session management according to the embodiment disclosed above. The WTRU NAS (ESM (EPS session management) or EMM (EPS mobility management)) detects an event that terminates hibernation mode (for example, resulting from a request to set up resources from the ESM layer or an application) and sends an instruction to the WTRU RRC to set up resources or terminate hibernation mode (502).

[0247] Subsequently, the RRC within the WTRU may send an RRC message to the eNB with an instruction (e.g., new IE) indicating the desire to exit the hibernation mode of operation (504). Alternatively, the WTRU (i.e., the NAS) may send a NAS message (new or existing) to the network indicating the desire to exit hibernation mode.

[0248] The eNB sends a new or existing S1AP message to the MME with a new IE indicating a request for the WTRU to exit hibernation mode (506). This S1AP message may include a TEID.

[0249] After receiving this message, the MME can verify the IE and accept the request to exit hibernation mode. Alternatively, if the MME receives a NAS message from the WTRU, the MME can verify the NAS request and accept the WTRU request to exit hibernation mode. The MME can then trigger a bearer change procedure toward the SGW (508). The SGW can trigger a bearer change procedure toward the PDN GW (not shown) and send a bearer change response to the MME (510).

[0250] The MME responds to the eNB with a new or existing S1AP message that may include a new IE indicating the result of the request to terminate hibernation mode (512). This message may indicate to the eNB a list of radio bearers to be set up for the RAB, and therefore for the WTRU. Alternatively, the MME may respond with a NAS message directed to the WTRU.

[0251] The eNB may then send a new or existing RRC message to the WTRU indicating the result of the request to terminate hibernation mode (514). The eNB may request the WTRU to perform an RRC reconfiguration to add other data radio bearers that implicitly indicate acceptance of terminating hibernation mode.

[0252] Subsequently, the WTRU RRC may change its state or other parameters to reflect the end of hibernation mode. The RRC can indicate to the NAS that hibernation mode operation has ended and that this may cause the NAS to change its state or parameters to reflect this change.

[0253] Alternatively, when the WTRU receives a NAS message from the MME, the WTRU verifies the result of the request to exit hibernation mode, and if the request is accepted, the WTRU NAS may change its state or other parameters to reflect the exit from hibernation mode. The WTRU NAS may indicate to the WTRU RRC that it can exit hibernation mode. The WTRU NAS may trigger the RRC to change any RRC state. The WTRU can then use a data radio bearer that is set up for operation in normal mode (i.e., not hibernation mode) with respect to user plane traffic (516).

[0254] Alternatively, the eNB can initiate an RRC request, similar to what was described above for the WTRU.

[0255] Events occurring within the NAS layer can trigger transitions from hibernation mode to non-hibernation mode and vice versa.

[0256] When a WTRU enters hibernation mode (which may be implemented as a subset of RRC connection modes or a separate RRC state), the NAS may be notified of this so that it can take appropriate action. For example, in hibernation mode, the NAS may send a new message (e.g., a service update) to request resources for the dedicated bearer and therefore to exit hibernation mode.

[0257] RRC and NAS can interact with each entity during transitions to or from hibernation mode. Changes in hibernation mode behavior can imply a transition from or to hibernation mode in RRC and / or NAS operation.

[0258] The RRC can notify the NAS of changes in hibernation mode operation. For example, when the RRC enters hibernation mode, it can notify the NAS (EMM or ESM) of the transition to hibernation mode. This instruction can be effective for a given period of time, either known to the NAS or signaled by the RRC. Similarly, the RRC can notify the NAS of the transition from hibernation mode to normal operation mode.

[0259] If the NAS knows that it is entering and exiting hibernation mode, and such transitions can be triggered or controlled by the NAS, the NAS can notify the RRC (or any other layer, such as a lower layer like the ESM or MAC) of all transitions to and from hibernation mode.

[0260] Entities such as a NAS can use or set parameters that indicate the current mode of operation in the WTRU when they receive instructions (e.g., from other entities such as an RRC or MME) regarding the transition to hibernation mode. For example, when an instruction is received that the WTRU is operating in hibernation mode, the NAS can define or use a flag or any other parameter that indicates the mode of operation of the WTRU. A hibernation flag can be defined (e.g., a Boolean parameter), where true (or 1) indicates that the WTRU is in hibernation mode, and false (or 0) indicates that the WTRU is in normal mode (i.e., not in hibernation mode). This behavior can be applied to other entities / layers within the WTRU (e.g., an RRC, MAC, or an ESM entity in the NAS).

[0261] Instructions to the NAS may come from lower layers (e.g., RRC) or from other network entities such as the MME. For example, if the NAS receives instructions from the MME regarding hibernation mode operation or a request to enter hibernation mode, the NAS may set the flags (or other parameters) described above to know that the WTRU is operating in hibernation mode. Similarly, a request to exit hibernation mode or an instruction to exit hibernation mode, which may be received from the MME, may result in the WTRU changing the value of the hibernation flag (or any parameter) so that normal mode of operation begins.

[0262] At any point in its operation, the NAS can verify whether a WTRU is operating in hibernation mode using a flag, a state, or any other method. The NAS can then behave according to the WTRU's current mode of operation. The NAS can further verify whether this state is part of NAS EMM-IDLE, EMM-CONNECTED, or any other state. For example, if the NAS knows that the operation is in hibernation mode, it can send a service update message requesting resources for a dedicated bearer. This can be done if hibernation mode is implemented as a subset of EMM-CONNECTED. Alternatively, this can be done regardless of the actual state that implements the hibernation behavior. Alternatively, the NAS may be permitted to send service requests in hibernation mode. Both service update messages and service request messages can be used. The NAS (EMM or ESM) can prohibit further ESM requests while in hibernation mode. This can be done for a defined period of time according to instructions from a lower layer or network.

[0263] Except for the fact that at any point in its operation, if the NAS determines that the WTRU is not operating in hibernation mode, the NAS must send a service update message to inform the MME that the WTRU NAS is about to enter hibernation mode, it can avoid using service update messages.

[0264] The NAS can send a message to the MME to inform it about the WTRU NAS operation in hibernation mode, based on a trigger that causes it to enter hibernation mode, or based on a request from a lower layer to enter hibernation mode. The NAS can then enter a new state or maintain a flag indicating operation in hibernation mode. The NAS can enter a new state or maintain the flag after receiving an acknowledgment or confirmation from the MME. The NAS can then notify lower layers or other entities (e.g., the ESM) that the WTRU is operating in hibernation mode.

[0265] Alternatively, based on instructions received from the WTRU or triggered at the MME, the MME may request the eNB to put the WTRU into hibernation mode. This can be done using an S1AP message (e.g., WTRU CONTEXT MODIFICATION REQUEST) or any new message with an IE defined to indicate that the eNB needs to put the WTRU into hibernation mode. Upon receiving a request from the MME to put the WTRU into hibernation mode, the eNB may use an RRC message to indicate to the WTRU to enter hibernation mode. The MME may send a NAS message to indicate to the WTRU that hibernation mode is currently active. Alternatively, the NAS within the WTRU may be notified by an RRC or any other layer.

[0266] Triggers can be defined to put the WTRU into hibernation mode (the implementation of hibernation mode can be by the NAS, RRC, or both). In one embodiment, a session management entity (e.g., NAS ESM) can observe that the WTRU is transmitting packets that have certain characteristics (e.g., a specific or maximum packet size, or a specific inter-packet (or burst) arrival time, or any other defined characteristics, or a combination thereof). The session management entity can install packet filters (locally or via signaling with the MME) so that certain traffic packets can be grouped into at least one bearer that can be an XRB as a result of observing certain traffic patterns. Alternatively, the WTRU can send a new session management message to the MME to signal / request operation in hibernation mode.

[0267] A session management entity within a WTRU may await an acknowledgment before operating in hibernation mode. This acknowledgment may take the form of an acknowledgment of the installation of a packet filter on the uplink and / or downlink, or a request to install a packet filter in the WTRU. This acknowledgment may take the form of a new session management message. This acknowledgment may be sent by the network (e.g., MME).

[0268] A session management entity can receive instructions to enter hibernation mode and, as a result, perform predefined actions. These instructions can be local, from, for example, an application or a user plane entity (e.g., a PDCP entity) that has the functionality to observe certain traffic patterns. These instructions can also be received from another entity in the network, for example, a session management entity in the network (i.e., an MME).

[0269] A session management entity (e.g., a NAS ESM) may, triggered by an action that causes a WTRU to enter hibernation mode, inform a mobility management entity (e.g., a NAS EMM). The EMM may then perform a predefined action (i.e., apply the above-defined action to the EMM) in response to the instruction from the ESM to enter hibernation mode, or in response to the same trigger defined above.

[0270] Figure 6 is a signaling diagram of process 600 in an example of entering hibernation mode according to one embodiment. When triggered by a WTRU (e.g., an ESM or EMM entity of the NAS), the NAS (ESM or EMM) determines to operate in hibernation mode (602). This trigger can be the detection of the transmission of a small packet or any other trigger.

[0271] The NAS (ESM or EMM) sends a NAS message to the network (eNB) (604). This NAS message can be, for example, an ESM message to install a packet filter, or an EMM message which can be defined to request hibernation mode operation. Alternatively, the NAS can interact with the RRC to indicate the need to enter hibernation mode without necessarily providing a NAS message for transmission. In this case, the RRC can send an RRC message to the eNB that has an information element IE indicating that the WTRU is requesting to enter hibernation mode.

[0272] The eNB forwards the received NAS message to the MME (606). Alternatively, if the eNB receives an RRC message with an IE indicating a request to enter hibernation mode, the eNB may send an existing or new S1AP message to the MME with a new IE (for example, with a value set from one received from the WTRU). This message may include a TEID.

[0273] The MME can accept or reject the request based on the configuration within the network. If the MME accepts the request, it can trigger a bearer change toward the SGW (608). The SGW can initiate the bearer change toward the PDN GW (not shown) and send a bearer change response to the MME (610). The MME can respond to a request to enter hibernation mode by sending a NAS message (EMM or ESM) with the result of the request to the eNB (612). Alternatively, the MME can inform the eNB of the result of the request to enter hibernation mode via an existing or new S1AP message. This message may include a TEID.

[0274] The eNB forwards all received NAS messages to the WTRU (614). The WTRU validates the NAS (ESM or EMM) messages for the result of the request to enter hibernation mode. If the result indicates that hibernation mode is acceptable, the NAS can enter hibernation mode. The NAS can further indicate to the RRC that the WTRU needs to operate in hibernation mode. The RRC can enter hibernation mode. The WTRU can install packet filters if requested by the NAS message.

[0275] Alternatively, the eNB may send an RRC message with an IE indicating the result of the hibernation mode request. The RRC can validate the message and inform the NAS of the response. The NAS and / or RRC may then enter hibernation mode and / or set certain flags accordingly to reflect the hibernation mode behavior if the result indicates so. User plane data can be transferred between the hibernation mode WTRU and SGW (616).

[0276] Embodiments of per-flow access barring in hiatus mode are disclosed later in this specification. An increase in intermittent background traffic from a large population of inactive WTRUs can significantly contribute to the generation of excessive load in the system, particularly during peak times when other WTRUs may be active for higher-priority services and / or data. Such load may include user plane traffic, access attempts on RACH, and control plane signaling. RACH overload may preemptively occupy higher-priority data that should be served. Control plane signaling related to RRM (Radio Resource Management) of background services may preemptively occupy useful user plane traffic for high-priority services.

[0277] With respect to WTRUs with established RRC connectivity and / or configured dedicated resources, the network can use a combination of QoS configuration parameters (per radio bearer) and scheduling priorities (between RABs of a given WTRU and / or between different WTRUs) to ensure that QoS requirements for different services are satisfied within the cell. Alternatively, the network can update packet filters so that one or more flows are dropped by the WTRU, which requires intervention from the MME (NAS) to address issues (congestion) experienced by the eNB.

[0278] For WTRUs with established RRC connections and / or configured dedicated resources, the network may redistribute the WTRU to other cells (using handover) or release the WTRU RRC connection (using an RRC connection release procedure, possibly involving redirection to another cell) in the event of an overload within the system (e.g., when there are few or no resources available to serve higher-priority data or WTRUs).

[0279] With respect to WTRUs in idle mode, the network can either signal within system information parameters that affect the behavior of the WTRU's cell (re)selection procedure (so that the cell has a lower likelihood of being selected), or use mechanisms such as extended cell ringing, where certain types of services may have temporary pre-emption of access to a cell while other services are permitted (e.g., emergency calls). Extended cell ringing relies on broadcasting system information, is applicable in IDLE mode, and its classes are defined per WTRU.

[0280] Embodiments of delaying or preempting one or more WTRUs accessing the system during a given time period, in combination with the use of quiescent behavior, are disclosed later herein. These embodiments may enable the network to perform some form of backoff with respect to data associated with a certain type of service and / or perform a graceful gradation of such services provided to one or more WTRUs (for example, with respect to WTRUs that are using quiescent behavior and / or WTRUs configured with at least one XRB).

[0281] In some embodiments, backoff can be applied to certain types of services in combination with packet filtering and / or wireless bearer configurations. These embodiments can be applied in RRC CONNECTED mode, RRC IDLE mode (for example, with regard to dormant behavior such as packet filtering and RAB configurations that can remain in a WTRU configuration), or RRC DORMANT mode.

[0282] The embodiments may be useful when the system reaches an excessive load where higher-priority data can no longer be served within the cell and / or admission control can no longer accept further connections. Such conditions may result from the system reaching the maximum number of possible RRC connections, insufficient system capacity, congestion on control channels, and / or congestion on random access channels.

[0283] When backoff is applied, the WTRU may refrain from accessing the system and / or making requests to uplink resources for user data to which the backoff function is applicable (e.g., scheduling requests that use either dedicated or random access resources, or sending preambles on WTRU-specific PRACH opportunities). Alternatively, the WTRU may delay all requests relating to user data to which the backoff function is applicable until a certain amount of data (which may be configurable) is available for transmission within the WTRU's buffer. Alternatively, the WTRU may refrain from sending all requests relating to user data to which the backoff function is applicable for data exceeding the prioritized bit rate or for data DRB in the WTRU's configuration.

[0284] The WTRU can be configured to determine one or more flows (hereinafter referred to as "applicable flows") for which the backoff function is applied, based on at least one of the following: XRB, packet filters, service types and / or QoS parameters, or similar (which may be given as part of the DRB configuration).

[0285] A WTRU can be configured to determine when to apply a backoff function to an applicable flow based on, for example, WTRU pause behavior, WTRU state (e.g., RRC DORMANT state), implicit instructions, explicit instructions from the network (e.g., overload instructions broadcast as part of system information and / or instructions for acceptable service classes within a cell), a specific subframe (e.g., scheduling opportunities), or similar.

[0286] A WTRU can be configured to determine how long the backoff function should be applied to an applicable flow. The WTRU can apply the backoff function for a specific (configurable) length of time. The WTRU can apply the backoff function until it is no longer applicable, for example, when the backoff function no longer satisfies predefined conditions, when the WTRU changes the RRC state, and / or when the pause behavior is no longer applicable. Furthermore, the WTRU can stop applying the backoff function when a mobility event occurs (a change in serving cell), either from receiving a cell (re)selection procedure that results in a different serving cell or an RRC connection reconfiguration with mobility control IE (e.g., a handover).

[0287] When a WTRU performs an uplink transmission including a BSR while a backoff function is applied to some of its radio bearers, the WTRU may report non-zero amounts of data for radio bearers within the BSR, where applicable.

[0288] The traffic class can represent the relative priority among different service classes (e.g., highest priority, high priority, medium priority, low priority, lowest priority). The priority can be made to follow an assigned integer, e.g., [15,..., 0], where 15 can represent the highest priority. The traffic class can be made the priority related to a logical channel group (LCG) related to the configuration of a radio bearer when applicable.

[0289] In the idle mode, the WTRU preempts requests regarding DRBs assigned a low traffic class. For example, the WTRU can be configured with multiple DRBs, and one or more DRBs can be associated with one XRB. This XRB can be associated with one traffic class. Alternatively, a DRB can be associated with one traffic class. When operating in the idle mode, the WTRU can apply a backoff function for data corresponding to traffic classes below a configured value (e.g., the WTRU can be made not to initiate requests for uplink resources to the network). This can be applied during a period when the WTRU determines that the serving cell is in an overloaded state, for example, from receiving system broadcast information. When the WTRU performs an uplink transmission regarding a radio bearer of a traffic class with a higher probability that its transmission may include a BSR, the WTRU can report in the BSR the amount of data of the DRB corresponding to a lower traffic class.

[0290] In another embodiment, in the idle mode, the WTRU can pre-empt requests for data beyond the DRB PRB. For example, the WTRU can be configured using multiple DRBs, and the DRBs can be associated with traffic classes. In the idle behavior, the WTRU can apply a back-off function for data corresponding to traffic classes below a configured value so that it cannot start an uplink resource request to the network for data of applicable DRBs beyond the PRB. This can be applied when the serving cell determines, based on receiving system broadcast information, that it is in an overloaded condition.

[0291] The WTRU can be configured using multiple packet filters. Each packet filter can be associated with an index (e.g., starting from 0). The WTRU can activate one packet filter at any time. The WTRU can consider the packet filter with the lowest index as the default packet filter. The WTRU can change the active packet filter based on an indication received from the network. This indication can be received within the system information broadcast. The system information broadcast can signal the applicable indices for the WTRU configured using multiple packet filters in the cell. The WTRU can use a packet filter different from the default packet filter when operating in the idle mode. If the WTRU is configured using multiple packet filters and the highest configured index is less than the value indicated by the system broadcast, the WTRU can use the index with the highest value.

[0292] TDF-based control plane policing can be considered in two cases: network-based and WTRU-based. In network-based TDF-based control plane policing, unwanted user plane traffic patterns are identified by the network (e.g., PGW), and the network then correlates these patterns with potential control plane events that could cause unwanted system behavior. The network can then take action to mitigate the associated control plane congestion. In WTRU-based TDF-based control plane policing, the WTRU either detects unwanted user plane traffic patterns, correlates them with control plane events, and notifies the network of this behavior so that the network can take action to mitigate possible unwanted system behavior, or enforces ADC rules by correlating user plane traffic patterns with control plane events to mitigate potentially harmful / undesirable control plane events.

[0293] Figure 7 shows the procedure of an example of TDF-based control plane policing according to one embodiment. Figure 7 shows both network-based and WTRU-based TDF-based control plane policing.

[0294] Based on rules set by the PCRF or pre-configured by the operator, the PGW can detect traffic patterns. When a traffic pattern is detected, the PGW reports this event to the PCRF (702). The PCRF receives the traffic detection information and configures ADC (application detection and control) rules within the PGW (704). The PGW uses these rules to identify potential user plane traffic that can subsequently correlate with control plane events (706). For example, the TDF within the PGW uses the provided rules to identify applications in the service data flow by using the application ID provided by the PCRF as part of the ADC rules.

[0295] When a PGW identifies a specific pattern according to a rule, the PGW may notify the control plane management entity of the undesirable user plane behavior that can be correlated with the control plane management entity in order to determine corrective action. Corrective action includes, but is not limited to, preventing certain control plane events, such as sending a new service request or a new RRC connection request to establish a new establishment. The PGW then passes this notification to the MME, for example, by sending a bearer update request via the SGW (708, 710).

[0296] The MME correlates traffic discovery information to known signaling patterns. The MME can then send an E-RAB MODIFY REQUEST message or a DL NAS TRANSPORT message to either establish a short-lived connection to send 2-3 bytes and set up a new quiescent bearer to prevent decomposition, set up a new filter to direct packets to an existing quiescent bearer, or communicate / notify the eNB of the traffic pattern identification so that the eNB can take further action depending on resource availability (712).

[0297] Alternatively, the MME may send an E-RAB MODIFY REQUEST message, a DL NAS TRANSPORT message, or a similar message to initialize the backoff timer in the WTRU in order to prevent all new control plane messages from being sent during the duration of the backoff timer (712). The eNB can then forward this timer to the WTRU via RRC signaling (714). Alternatively, the MME may send the timer directly to the WTRU via NAS signaling.

[0298] A backoff timer can be applied to certain control plane messages, such as service requests (i.e., when this timer is provided, the WTRU cannot send service requests (for any service) during the timer's duration). Alternatively, the WTRU may be permitted to send service requests for voice calls, emergency calls, or other services. The WTRU may be provided with information on which services are permitted and which are not.

[0299] Alternatively, the backoff timer can be applied to a specific traffic class or a specific bearer or flow. For example, when a WTRU is provided with a backoff timer, the WTRU may not transition to connected mode for traffic generated on a specific bearer or for a specific flow. Alternatively, the backoff timer can be applied to the entire WTRU.

[0300] With respect to WTRU-based TD-based control plane policing, the WTRU is configured with ADC rules, or filtering information may be supplied to the WTRU, for example, during bearer establishment. The WTRU uses these rules to detect traffic patterns. After a traffic pattern is detected, the WTRU can send a notice to the PCRF (or any other node such as the MME) using, for example, a bearer resource request or a comprehensive transport of NAS messages (or any session management NAS message or mobility management NAS message) (702a). The WTRU can provide this instruction to the MME, which can then forward it to the PCRF via the SGW and PGW using CN messages such as a bearer change request message. Alternatively, a new message can be defined between these nodes. After this message (i.e., a trigger from the WTRU) is received by the PCRF, the PCRF can take action as shown in operations 702-714 of Figure 7.

[0301] Alternatively, the WTRU can use configured ADC rules to perform some of the actions. The WTRU can trigger a request for a suspend bearer, as disclosed above. Alternatively, the WTRU can route packets from unwanted flows to a suspend bearer. Figure 8 shows the routing of packets from unwanted flows to the XRB. A user plane filter 802 within the WTRU, which may be controlled according to the TDF / ADC 806 configured by the PGW, routes matching traffic to the XRB 804.

[0302] Alternatively, the WTRU may back off for a pre-configured duration, refraining from sending specific control plane messages for a particular flow or bearer, or refraining from sending any control plane messages for the duration of a pre-configured timer.

[0303] Paging can be used to send paging information to the RRC_IDLE WTRU and / or to indicate the availability of downlink data for the WTRU to the RRC_DORMANT WTRU. Paging can also be used to notify the RRC_IDLE, RRC_DORMANT, and RRC_CONNECTED WTRUs of system information changes, to notify them of ETWS primary and / or ETWS secondary notifications, and / or to notify them of CMAS notifications.

[0304] Paging information is provided to a higher layer, which in response can initiate RRC connection establishment, for example, to receive an incoming call. The higher layer can then respond by resuming decoding of downlink control signaling at the physical layer (for example, to receive a short unicast data transfer).

[0305] The network can initiate the paging procedure by sending a paging message when a WTRU has a paging opportunity. The network can address multiple WTRUs within a single paging message by including one paging record for each WTRU. Within the paging message, the network can indicate changes in system information and / or provide ETWS transaction values ​​or CMAS notices.

[0306] When a paging message is received, if it is RRC_IDLE, and the paging message contains a paging record, the WTRU can forward its WTRU-Identity and cn-Domain to the higher layer if the WTRU-Identity contained within the paging record matches one of the WTRU identities assigned by a higher layer.

[0307] When a paging message is received, if RRC_DORMANT, and the paging message contains a paging record, the WTRU can indicate to lower layers that it can resume monitoring downlink control signaling if the WTRU-Identity contained within the paging record matches one of the WTRU identities assigned by a higher layer.

[0308] If systemInfoModification is included, the WTRU can reacquire system information using the system information acquisition procedure. If etws-Indication is included and the WTRU is ETWS-enabled, the WTRU can reacquire SystemInformationBlockType1 immediately, i.e., without waiting until the next system information change cycle boundary. If schedulingInfoList indicates that SystemInformationBlockType10 exists, the WTRU can acquire SystemInformationBlockType10. If schedulingInfoList indicates that SystemInformationBlockType11 exists, the WTRU can acquire SystemInformationBlockType11. If cmas-Indication is included and the WTRU is CMAS-enabled, the WTRU can reacquire SystemInformationBlockType1 immediately, i.e., without waiting until the next system information change cycle boundary. If schedulingInfoList indicates that SystemInformationBlockType12 exists, the WTRU can acquire SystemInformationBlockType12.

[0309] Embodiment.

[0310] 1. A method for controlling the connectivity of the WTRU to the network.

[0311] 2. The method according to Embodiment 1, comprising the step of a WTRU determining the characteristics and / or priorities of data to be transmitted.

[0312] 3. The method according to Embodiment 2, comprising the step of a WTRU transitioning from a connected state or an idle state to a sleep mode on condition that the characteristics or priorities of the data match the characteristics or priorities of the sleep mode.

[0313] 4. The method according to Embodiment 3, comprising the step of a WTRU operating using a configuration for data transmission that is different from the configuration used in the connected state or the idle state.

[0314] 5. The method according to any one of Embodiments 2 to 4, wherein a WTRU in the sleep mode periodically monitors signals from cells so as to select one of a plurality of cells based on a preconfigured criterion of the WTRU and camp on the selected cell, and executes a mobility procedure controlled by the WTRU.

[0315] 6. The method according to any one of Embodiments 2 to 5, wherein a WTRU in the sleep mode retains dedicated resources for receiving unicast traffic from the network.

[0316] 7. The method according to any one of Embodiments 2 to 6, wherein a WTRU transmits a scheduling request via either a PUCCH or a PRACH according to the characteristics or priorities of the data.

[0317] 8. The method according to any one of Embodiments 2 to 7, wherein a WTRU transmits a scheduling request via a RACH by using either a first set of RACH configurations or a second set of RACH configurations according to the characteristics or priorities of the data.

[0318] 9. The method according to any one of embodiments 2 to 8, wherein the WTRU monitors downlink transmissions from selected cells using a dedicated WTRU-specific RNTI for WTRU-specific scheduling opportunities and a paging RNTI for WTRU-specific paging opportunities while in hibernation mode.

[0319] 10. The method according to any one of embodiments 2 to 9, comprising the step of a WTRU in hibernation mode transmitting a PRACH transmission on a WTRU-specific subframe.

[0320] 11. The method according to Embodiment 10, wherein the PRACH transmission is for indicating the priority of pending data with respect to HARQ feedback or uplink transmission.

[0321] 12. The method according to any one of embodiments 2 to 11, wherein the WTRU performs a CB-PUSCH transmission, provided that the WTRU has a valid uplink timing alignment for transmission.

[0322] 13. The method according to any one of embodiments 2 to 12, wherein the WTRU transmits an RRC signaling indicating a request for a hibernation mode.

[0323] 14. The method according to Embodiment 13, wherein RRC signaling includes information about traffic characteristics, including at least one of the following: average time and mean deviation between packets or between bursts, mobility information, index to DRX configuration from a list of DRX configurations, average packet size, and aggregated bitrate.

[0324] 15. The method according to any one of embodiments 2 to 14, comprising the step of a WTRU in hibernation mode transmitting an uplink transmission via a radio bearer configured for hibernation mode.

[0325] 16. The method according to any one of embodiments 2 to 15, wherein the WTRU in idle mode transmits uplink user plane data via control plane signaling.

[0326] 17. The method according to any one of embodiments 2 to 16, wherein the WTRU exits the hibernation mode and moves to an idle state, provided that the WTRU autonomously selects a new serving cell.

[0327] 18. WTRU, which controls network connectivity.

[0328] 19. The WTRU according to Embodiment 18, comprising a processor configured to determine the characteristics and / or priority of data to be transmitted.

[0329] 20. The WTRU according to Embodiment 19, wherein the processor is configured to transition from a connected state or an idle state to a hibernation mode on the condition that the characteristics or priority of the data match the characteristics or priority of the hibernation mode.

[0330] 21. The WTRU according to Embodiment 20, wherein the processor is configured to operate using a configuration for data transmission that is different from the configuration used for connected or idle states.

[0331] 22. The WTRU according to any one of embodiments 19 to 21, wherein the processor is configured to periodically monitor signals from multiple cells in a hiatus mode to select and camp a cell and to perform a mobility procedure controlled by the WTRU.

[0332] 23. The WTRU according to any one of embodiments 19 to 22, wherein the processor is configured to hold dedicated resources for receiving unicast traffic from the network in a hiatus mode.

[0333] 24. The WTRU according to any one of embodiments 19 to 23, wherein the processor is configured to send scheduling requests via either PUCCH or PRACH depending on the characteristics or priority of the data.

[0334] 25. The WTRU according to any one of embodiments 19 to 24, wherein the processor is configured to send scheduling requests via RACH by using either a first set of RACH configurations or a second set of RACH configurations, depending on the characteristics or priority of the data.

[0335] 26. A WTRU according to any one of embodiments 19 to 25, wherein the processor is configured to monitor downlink transmissions from selected cells using a dedicated WTRU-specific RNTI for WTRU-specific scheduling opportunities and a paging RNTI for WTRU-specific paging opportunities while in hibernation mode.

[0336] 27. A WTRU according to any one of embodiments 19 to 26, wherein the processor in hibernation mode is configured to transmit PRACH transmissions on a WTRU-specific subframe.

[0337] 28. A WTRU as described in any one of Embodiments 19 to 27, wherein the PRACH transmission is intended to indicate the priority of pending data with respect to HARQ feedback or uplink transmission.

[0338] 29. A WTRU according to any one of embodiments 19 to 28, wherein the processor is configured to perform CB-PUSCH transmissions, provided that the WTRU has a valid uplink timing alignment for transmission.

[0339] 30. The WTRU according to any one of embodiments 19 to 29, wherein the processor is configured to send RRC signaling indicating a request for a hibernation mode.

[0340] 31. The WTRU according to Embodiment 30, wherein the RRC signaling includes information about traffic characteristics, including at least one of the following: average time and mean deviation between packets or between bursts, mobility information, index to DRX configuration from a list of DRX configurations, average packet size, and aggregated bitrate.

[0341] 32. The WTRU according to any one of embodiments 19 to 31, wherein the processor in hibernation mode is configured to transmit uplink transmissions via a radio bearer configured for hibernation mode.

[0342] 33. The WTRU according to any one of embodiments 19 to 32, wherein the processor in hibernation mode is configured to transmit uplink user plane data via control plane signaling.

[0343] 34. The WTRU according to any one of embodiments 19 to 33, wherein the processor is configured to exit hibernation mode and move to an idle state, subject to the WTRU autonomously selecting a new serving cell.

[0344] While features and elements are described above in specific combinations, those skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. Furthermore, the methods described herein can be implemented in computer programs, software, or firmware embedded in computer-readable media for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, magnetic media such as ROM (read-only memory), RAM (random access memory), registers, cache memory, semiconductor memory devices, internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM discs and DVDs (digital multipurpose discs). A processor associated with the software can be used to implement a WTRU, UE, terminal, base station, RNC, or radio frequency transceiver used within any host computer.

Claims

1. A method implemented by a wireless transmitter / receiver unit (WTRU), Receiving a configuration message, the received configuration message containing information about a radio resource control (RRC) hiatus mode for the cell, and the WTRU in the RRC hiatus mode disables the reception of control signaling on the physical downlink control channel (PDCCH), Receiving a first downlink control information (DCI) signal indicating that the RRC pause mode is enabled, wherein the RRC pause mode differs from the DRX cycle in that at least one bit of the first DCI signal is for enabling the RRC pause mode. While the WTRU is in the RRC pause mode, it transmits a channel quality indicator (CQI) to the cell, Receiving a second DCI signal indicating that the RRC pause mode is disabled for the cell, Methods that include...

2. The method according to claim 1, wherein when the WTRU is in the RRC pause mode for the cell, the WTRU partially deactivates uplink data transmissions, except for uplink data transmissions for the CQI to the cell.

3. The method according to claim 1, wherein the RRC pause mode for the cell provides energy savings for the WTRU.

4. The method according to claim 1, wherein the reception of the first DCI signal is performed while the WTRU is in RRC connection mode.

5. A wireless transmitter / receiver unit (WTRU), Equipped with a transceiver operablely connected to the processor, The transceiver and processor are configured to receive configuration messages, the received configuration messages containing information about a radio resource control (RRC) hiatus mode for the cell, the WTRU in the RRC hiatus mode disables the reception of control signaling on the physical downlink control channel (PDCCH), The transceiver and processor are configured to receive a first downlink control information (DCI) signal indicating that the RRC pause mode is enabled, and unlike the DRX cycle, at least one bit of the first DCI signal is for enabling the RRC pause mode. The transceiver and processor are configured to transmit a channel quality indicator (CQI) to the cell while the WTRU is in the RRC hiatus mode. The transceiver and processor are configured to receive a second DCI signal indicating that the RRC hiatus mode should be disabled for the cell. WTRU.

6. The WTRU according to claim 5, wherein when the WTRU is in the RRC pause mode for the cell, the WTRU partially deactivates uplink data transmissions, except for uplink data transmissions for the CQI to the cell.

7. The WTRU according to claim 5, wherein the RRC pause mode for the cell provides energy savings for the WTRU.

8. The WTRU according to claim 5, wherein the reception of the first DCI signal is performed while the WTRU is in RRC connection mode.

Images