BACKGROUND

[0001] Aspects of the present disclosure relate generally to wireless communication systems, and more particularly, to radio link control.

[0002] Wireless communication networks are widely deployed to provide various communication services such as telephony, video, data, messaging, broadcasts, and so on. Such networks, which are usually multiple access networks, support communications for multiple users by sharing the available network resources. One example of such a network is the UMTS Terrestrial Radio Access Network (UTRAN). The UTRAN is the radio access network (RAN) defined as a part of the Universal Mobile Telecommunications System (UMTS), a third generation (3G) mobile phone technology supported by the 3rd Generation Partnership Project (3GPP). The UMTS, which is the successor to Global System for Mobile Communications (GSM) technologies, currently supports various air interface standards, such as Wideband-Code Division Multiple Access (W-CDMA), Time Division-Code Division Multiple Access (TD-CDMA), and Time Division-Synchronous Code Division Multiple Access (TD- SCDMA). The UMTS also supports enhanced 3G data communications protocols, such as High Speed Packet Access (HSPA), which provides higher data transfer speeds and capacity to associated UMTS networks.

[0003] As the demand for mobile broadband access continues to increase, research and development continue to advance the UMTS technologies not only to meet the growing demand for mobile broadband access, but to advance and enhance the user experience with mobile communications.

[0004] In a wireless communication network, a wireless device may organize radio transmissions using radio bearers controlled by a radio resource control (RRC) protocol. Within a bearer, a radio link control (RLC) entity receives service data units (SDU) from higher layers via a radio access buffer (RAB) queue and sends packet data units (PDUs) to a lower layer for transmission. When a packet switched (PS) call is ongoing in a UMTS network, the RLC entity may be released when there is a higher layer change such as a radio access technology (RAT) change, radio bearer release, or radio resource control release. When an RLC entity is released, the RLC layer will typically discard any SDUs and PDUs that the RLC entity is processing. That is, the RLC may discard all of the SDUs, including SDUs having PDUs that have not been transmitted or acknowledged. The discarded SDUs may not be received by a network side RLC entity. The discarded SDUs may eventually be detected as a missing packet by a higher layer such as a transmission control protocol (TCP) layer or the application layer, and be resent on a new connection, but the delay may be significant. For example, the discarded SDU may be transmitted after new TCP segments causing a delay. A network node such as an application server or a far end UE, may report the missing packets leading to disruption of the user experience, for example, a dropped call. Accordingly, there is need for improvement to RLC release procedures.

SUMMARY

[0005] The following presents a simplified summary of one or more aspects in order to provide a basic understanding of such aspects. This summary is not an extensive overview of all contemplated aspects, and is intended to neither identify key or critical elements of all aspects nor delineate the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form as a prelude to the more detailed description that is presented later.

[0006] The disclosure provides a method and apparatus for improving the packet switched call performance when a radio link control (RLC) entity is released. A wireless device may detect release of a first RLC entity that is being used to process a service data unit (SDU). The SDU of the first RLC entity may be identified as being transmitted but not acknowledged. The SDU may then be stored back into a radio access buffer (RAB) queue. The SDU may be processed for transmission using a second RLC entity after the SDU is obtained from the RAB queue. The wireless device may also include a retransmission buffer indicating a status of one or more protocol data units (PDUs) generated from the SDU for determining whether the SDU has been acknowledged. Accordingly, loss of an SDU during release of a RLC entity may be prevented.

[0007] In an aspect, the disclosure provides a method of wireless communication. The method includes detecting release of a first RLC entity. The method further includes identifying, in response to detecting the release of the first RLC entity, a SDU of the first RLC entity that has been transmitted but not acknowledged. Additionally, the method includes storing the SDU back into a radio access bearer (RAB) queue; and processing the SDU for transmission using a second RLC entity after obtaining the SDU from the RAB queue.

[0008] In another aspect, an apparatus for wireless communication is provided. The apparatus includes means for detecting release of a first RLC entity and means for identifying, in response to detecting the release of the first RLC entity, a SDU of the first RLC entity that has been transmitted but not acknowledged. The apparatus also includes means for storing the SDU back into a RAB queue; and means for processing the SDU for transmission using a second RLC entity after obtaining the SDU from the RAB queue.

[0009] Yet another aspect of the disclosure provides a computer program product, including a non-transitory computer-readable medium. The non-transitory computer- readable medium includes instructions that when executed by a processor cause the processor to detect release of a first RLC entity; identify, in response to detecting the release of the first RLC entity, a SDU of the first RLC entity that has been transmitted but not acknowledged; store the SDU back into a RAB queue; and process the SDU for transmission using a second RLC entity after obtaining the SDU from the RAB queue.

[0010] Another aspect of the disclosure provides an apparatus for wireless communication including at least one processor; and a memory coupled to the at least one processor. The at least one processor is configured to: detect a release of a first RLC entity; identify, in response to detecting the release of the first RLC entity, a SDU of the first RLC entity that has been transmitted but not acknowledged; store the SDU back into a RAB queue; and process the SDU for transmission using a second RLC entity after obtaining the SDU from the RAB queue.

[0011] To the accomplishment of the foregoing and related ends, the one or more aspects comprise the features hereinafter fully described and particularly pointed out in the claims. The following description and the annexed drawings set forth in detail certain illustrative features of the one or more aspects. These features are indicative, however, of but a few of the various ways in which the principles of various aspects may be employed, and this description is intended to include all such aspects and their equivalents. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] FIG 1 is a diagram illustrating a user equipment in communication with a base station.

[0013] FIG. 2 is a flowchart illustrating an example method of wireless communication.

[0014] FIG. 3 is a diagram illustrating an example flow of data and control within a user equipment.

[0015] FIG. 4 is a message diagram illustrating an example scenario involving an RLC entity release.

[0016] FIG. 5 is a block diagram illustrating an example of a hardware implementation for an apparatus employing a processing system.

[0017] FIG. 6 is a block diagram illustrating an example of a telecommunications system.

[0018] FIG. 7 is a conceptual diagram illustrating an example of an access network.

[0019] FIG. 8 is a conceptual diagram illustrating an example of a radio protocol architecture for the user and control plane.

[0020] FIG. 9 is a block diagram conceptually illustrating an example of a Node B in communication with a UE in a telecommunications system.

DETAILED DESCRIPTION

[0021] The detailed description set forth below in connection with the appended drawings is intended as a description of various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. In some instances, well known structures and components are shown in block diagram form in order to avoid obscuring such concepts.

[0022] When a higher layer causes the RLC layer to release the RLC entity, instead of discarding the SDUs and PDUs being processed by the RLC entity, the RLC layer may instead return any partially transmitted SDU that has not been acknowledged for storing back into the front of the RAB queue. The SDU is not considered acknowledged until all of the PDUs have been acknowledged. Accordingly, the SDU may be returned to the RAB queue if one of the corresponding PDUs has not been acknowledged. Such returned SDUs will be first in line for transmission on a new radio link. When the new radio link is established, the RLC layer will form new PDUs for transmission from the SDU in the RAB queue. Using this approach, re-transmission at the RLC layer is faster than waiting for higher layers to detect the missing or unacknowledged packet and will help reduce errors. Accordingly, the performance of a PS call may be improved.

[0023] Referring to FIG. 1, in an aspect, a wireless communication system 10 includes at least one UE 12 in communication coverage of at least one network entity 14 (e.g., base station). UE 12 may communicate with network 16 via network entity 14. In some aspects, multiple UEs including UE 12 may be in communication coverage with one or more network entities, including network entity 14. In an example, UE 12 may transmit and/or receive wireless communications to and/or from network entity 14.

[0024] In some aspects, UE 12 may also be referred to by those skilled in the art (as well as interchangeably herein) as a mobile station, a subscriber station, a mobile unit, a subscriber unit, a wireless unit, a remote unit, a mobile device, a wireless device, a wireless communications device, a remote device, a mobile subscriber station, an access terminal, a mobile terminal, a wireless terminal, a remote terminal, a handset, a terminal, a user agent, a mobile client, a client, or some other suitable terminology. Additionally, network entity 14 may be a macrocell, picocell, femtocell, relay, Node B, mobile Node B, UE (e.g., communicating in peer-to-peer or ad-hoc mode with UE 12), or substantially any type of component that can communicate with UE 12 to provide wireless network access at the UE 12.

[0025] According to the present aspects, UE 12 may include modem component 20, which may be configured to manage radio communications, particularly during release of an RLC entity. The modem component 20 may include a radio link control component (RLC) 25, and a radio resource control (RRC) component 50.

[0026] The RLC component 25 may include hardware or means for implementing an

RLC protocol. The RLC protocol may be described in, for example, 3GPP TS 25.322. The RLC component 25 may implement and control one or more RLC entities 40, 45 for communicating with the network 16 using an over-the-air (OTA) link. Each RLC entity 40, 45 may enable an end-to-end link between the UE 12 and the network 16. The end-to-end link may include one of the UE-side RLC entities 40, 45 and a network side peer entity (not shown). Each RLC entity 40, 45 may be one of, or include one or more of, a transparent mode entity, an unacknowledged mode entity, and an acknowledged mode entity. As an example, the first RLC entity 40 may be an acknowledged mode RLC entity. The RLC component 25 may also include an RAB queue controller 30 for receiving SDUs from higher layers.

[0027] The RAB queue controller 30 may be configured to control the reception of data from higher layers for subsequent transmission by the RLC layer. The higher layers for the RLC may include, for example, the RRC protocol, the packet data convergence protocol (PDCP), TCP, user datagram protocol (UDP), internet protocol (IP), and applications. The RAB queue controller 30 may process the data received from the higher layers for storage in a RAB queue 32 as an SDU. For example, the RAB queue controller 30 may attach an identifier or sequence number to received data for storage as an SDU. The RAB queue controller 30 may include one or more RAB queues 32 for storing SDUs. Multiple RAB queues 32 may be used, for example, for transmissions over different radio bearers or for different types of SDUs. RAB queue controller 30 may select an appropriate RAB queue 32 for each received SDU for processing by an RLC entity 40, 45. The RAB queue controller 30 may also be referred to as a transmission queue or a RLC service access point (SAP). In particular, the RAB queue controller 30 may be or may include an RLC Acknowledged Mode (AM) SAP.

[0028] The RAB queues 32 may include a memory, buffer, data store, or other machine-readable medium for storing received SDUs. An RAB queue 32 may exist separate from any RLC entity but may be associated with, for example, one of the one or more RLC entities 40 upon establishment of the respective RLC entity. Generally, the RAB queues 32 may be first-in, first-out (FIFO) queues that provide SDUs to the RLC entity in the order in which the SDUs are received by the RAB queue 32. The RAB queue 32 may obtain the SDU from the front of the queue and provide the SDU to the RLC entity 40. The RAB queues 32 may, however, also allow for insertion of an SDU at the front of the queue, for example, by RAB queue controller 30. For example, when storing an SDU back into the RAB queue 32, the RAB queue controller 30 may insert a previously provided SDU at the front of the RAB queue 32. In another aspect, the RAB queue 32 may maintain a copy of a previously provided SDU until an RLC entity acknowledges that the SDU has been successfully transmitted. The RAB queue 32 may track the transmission and acknowledgement status of the SDUs. When storing an SDU back into the RAB queue 32, the RAB queue controller 30 may indicate the copy of the previously provided SDU for retransmission. [0029] Each RLC entity 40, 45 may be configured for generating PDUs for transmission over a physical channel. In particular, the RLC entity 40 may be configured to generate PDUs of an appropriate size for transmission within a transmission time interval on the physical channel. The RLC entity 40 may receive an SDU from one of the RAB queues 32 and segment the SDU into one or more PDUs for transmission. The RLC entity 40 may also concatenate SDUs or parts thereof into a PDU for transmission. The RLC entity 40 may add headers to the PDUs for processing at the receiving RLC entity. The RLC entity 40 may then transmit the PDUs. As used herein, transmission by the RLC entity 40, may include passing the generated PDUs to a lower layer (i.e. the physical layer) or actual transmission of the PDUs on the physical layer to another device. The RLC entity 40 may also receive one or more PDUs transmitted by a network side peer RLC entity located in the network 16 and assemble the PDUs to form an SDU to pass to the higher layers. A receiving side of the RLC entity 40 may include a memory or buffer for storing received PDUs while waiting for the remaining PDUs of the SDU to arrive. Further, the RLC entity 40 may include a retransmission buffer 42 and an acknowledgement (ACK) controller 44.

[0030] The retransmission buffer 42 may store the SDUs and/or PDUs while awaiting transmission and acknowledgement. The retransmission buffer 42 may track the status of each PDU as well as the relationship between PDUs and SDUs. The retransmission buffer 42 may determine that an SDU has been acknowledged when each PDU including part of the SDU has been acknowledged. The retransmission buffer 42 may clear acknowledged SDUs and PDUs. During an RLC release procedure, the retransmission buffer 42 may be configured to return unacknowledged SDUs to the RAB queue 32 when the RLC entity 40 is released.

[0031] The ACK controller 44 may be configured to extract status information from status PDUs and piggybacked status information from PDUs to determine whether transmitted PDUs have been acknowledged. For example, the status information may include a positive or negative acknowledgment for each PDU or an update indicating that all PDUs below a sequence number have been received. The ACK controller 44 may provide the status information to the retransmission buffer 42 to trigger retransmission or clearing of the PDUs.

[0032] The RRC component 50 may include hardware or means for implementing an

RRC protocol. The RRC protocol may be described in, for example, 3GPP TS 25.331. In particular, the RRC component 50 may be configured to receive messages from the network 16 for controlling radio resources. The RRC component 50 may update the configuration of UE 12 according to the received messages. Various received messages may require changes that result in release of an RLC entity 40. For example, the RRC component 50 may receive a message indicating an inter-RAT change, a radio bearer release or an RRC release. The RRC component 50 may include a release control component 52 for handling such messages. The RRC component 50 may also establish the RLC entity 45 as a new RLC entity based on one or more received messages.

[0033] The release control component 52 may be configured to release an RLC entity as part of an RRC procedure. The release control component 52 may use primitives to communicate with the RLC component 25. For example, a CRLC-CONFIG-Req primitive may be used to configure RLC entities. The primitives may include parameters indicating the specific actions, including a release, to be performed by the RLC component 25. The release control component 52 may indicate whether RLC component 25 should maintain or discard transmitted SDUs. In an aspect, the release control component 52 may maintain transmitted SDUs during an RLC entity release as long as a packet data protocol (PDP) context is active for the UE. On the other hand, if the reconfiguration is because of a PDP context release, the release control component 52 may discard transmitted SDUs.

[0034] Referring to FIG. 2, in an operational aspect, a UE such as UE 12 (FIG. 1) may perform one aspect of a method 100 for wireless communication. While, for purposes of simplicity of explanation, the method is shown and described as a series of acts, it is to be understood and appreciated that the method (and further methods related thereto) is/are not limited by the order of acts, as some acts may, in accordance with one or more aspects, occur in different orders and/or concurrently with other acts from that shown and described herein. For example, it is to be appreciated that a method could alternatively be represented as a series of interrelated states or events, such as in a state diagram. Moreover, not all illustrated acts may be required to implement a method in accordance with one or more features described herein.

[0035] In an aspect, at block 102, the method 100 includes detecting release of a first

RLC entity. The UE 12 may detect release of an RLC entity by the network 16. More specifically, the RRC component 50 may receive a message indicating that the UE 12 should perform a higher layer operation that involves release of an RLC entity 40. The RRC component 50 may instruct the RLC component 25 to release the RLC entity 40.

[0036] At block 104, the method 100 may include identifying an SDU that has been transmitted but not acknowledged. The UE 12 may identify one or more transmitted SDUs that have not been acknowledged in response to the release of the RLC entity 40. A transmitted SDU may include any SDU that has been received by the RLC entity 40 from a RAB queue 32. The transmitted SDU may have been segmented into a first set of PDUs, stored in the retransmission buffer 42, passed to a lower layer, and transmitted over the air. The RLC component 25 and RLC entity 40 may consider a transmitted PDU to be unacknowledged until a status update is received from the peer RLC entity. Accordingly, an unacknowledged PDU may have been transmitted and received, but the status update may not have been received. An SDU may be considered acknowledged when every PDU containing part of the SDU has been acknowledged. Also, an unacknowledged SDU may include one or more PDUs that have been acknowledged while at least one PDU of the SDU is unacknowledged. The RLC entity 40 may use the retransmission buffer 42 to determine whether an SDU has been transmitted and acknowledged.

[0037] At block 106, the method 100 may include storing the SDU back into the RAB queue. The RLC controller 25 may return the SDU to the RAB queue controller 30 for storing back into the RAB queue 32. For example, the RLC controller 25 may use a primitive to indicate that the SDU should be transmitted. The RAB queue controller 30 may add the SDU to a RAB queue 32. The RAB queue 32 may be the same RAB queue from which the RLC entity 40 previously received the SDU. In an aspect, the RAB queue controller 30 may store the SDU at the front of the RAB queue 32. Accordingly, the returned SDU may be the first SDU for transmission when a new RLC entity is established because the SDU was inserted at the front of the RAB queue 32. In another aspect, storing the SDU back into the RAB queue 32 may require reassembly of the SDU. For example, if the retransmission buffer 42 stores only the PDUs and not the received SDU, the transmitted SDU may be reassembled from the PDUs similar to the process used by the receiving side of the RLC entity 40. In another aspect, where the RAB queue 32 maintains a copy of unacknowledged SDUs, storing the SDU back into the RAB queue 32 may include marking the copy of the SDU for retransmission. For example, the retransmission buffer 42 may indicate an identifier of an unacknowledged SDU for retransmission.

[0038] At block 108, the method 100 may include processing the SDU for transmission using a second RLC entity. The second RLC entity 45 may process the SDU after obtaining the SDU from the RAB queue 32. The RLC entity 45 may be established after the RLC entity 40 is released. In an aspect, the RLC entity 45 may re-use computing resources of the RLC entity 40 such as memory for the retransmission buffer 42. The RLC entity 45 may be configured differently than the RLC entity 40. For example, the RLC entity 45 may enable a connection to a different base station 14, use a different RAT, or use a different PDU size. Transmitting the SDU using the RLC entity 45 may include segmenting the SDU into a second set of PDUs by the RLC entity 45 and transmitting the second set of PDUs. Accordingly, the second set of PDUs may be different than any PDUs that were transmitted by the first RLC entity 40. The PDUs transmitted by RLC entity 40 for an SDU may be different from the PDUs transmitted by RLC entity 50 for the same SDU. The network 16 may receive and reassemble the second set of PDUs to obtain the SDU. The SDUs returned to the RAB queue 32 may therefore, be received by the network 16 relatively quickly and in approximately the same order as originally intended for transmission.

[0039] FIG. 3 is a diagram illustrating an example flow of data and control within a UE, such as UE 12 (FIG. 1). Similar reference numbers may indicate similar components. The UE 12 may be illustrated as divided into multiple layers including upper layers, the RLC layer, and lower layers.

[0040] In the upper layers, an RRC component 50 and an application 210 may both send data to the RAB queue 32. The data may be stored as RLC SDUs 220. The RAB queue 32 may be located between the higher layers and the RLC layer. The RAB queue 32 may be separate from any RLC entity. The RAB queue 32 may store the SDUs 220 received from higher layers. The RAB queue 32 may also send the SDUs 220 to an RLC entity. Initially, the RAB queue 32 may send the SDUs 220 to the RLC entity 40.

[0041] At the first RLC entity 40, a received SDU 220a, for example, may be segmented into PDUs 230 stored in the retransmission buffer 42. It should be appreciated that the retransmission buffer 42 may store additional SDUs 220 and PDUs 230. The retransmission buffer 42 may also store identifiers or pointers to the SDUs or PDUs rather than the data. The retransmission buffer 42 may also track a status 240 of the PDUs 230. The ACK controller 44 may update the status 240 of the PDUs 230 as status messages are received by receiver 212. The retransmission buffer 42 may clear an SDU 220 when all of the PDUs 230 associated with an SDU 220 are acknowledged. The retransmission buffer 42, along with other components of RLC entity 40, may send the PDUs 230 to a transmitter 214, which may send the PDUs to, for example, network entity 14.

[0042] The RRC component 50 may also send a command 255 indicating release of the first RLC entity 40. The command 250 may be triggered by higher layer signaling, which may have been received as one or more PDUs and passed to the RRC component 50 as an SDU. The command 250 may cause the RLC entity 40 to cease processing SDUs 220 from RAB queue 230. The command 250 may also cause the retransmission buffer 42 to generate a return message 260 to the RAB queue 32. The return message 260 may include any unacknowledged SDU 220. For example, the return message 260 may include SDU 220a, which is associated with PDU 230 remaining in retransmission buffer 42.

[0043] The RRC component 50 may also send a second command (not shown) that causes the establishment of the second RLC entity, such as an RLC entity 45. After the RLC release command 255, the RAB queue 32 may provide the SDUs 220 to the RLC entity 45. The RLC entity 45 may operate in a similar manner to the RLC entity 40. Notably, the SDU 220a that was returned to the RAB queue 32 may be processed by the second RLC entity 45 to generate PDUs 270, which may be a different size than PDUs 230, but contain the same data. The second RLC entity 45 may also track the status 280 of the PDUs 270. Accordingly, the UE 12 may avoid loss of SDUs SDU 220a for example, when the RLC entity 40 is released.

[0044] FIG. 4 is a message diagram 300 illustrating an example scenario involving an

RLC release. The UE 12 may be in communication with the network 16 using an established RLC entity 40. The UE 12 may transmit an SDU 302 as a plurality of PDUs. For example, the SDU 302 may be segmented into PDU#1, PDU#2, and PDU#3.

[0045] The network 16 may provide a status update 304 acknowledging receipt of one or more PDUs. The network 16 may provide the status update 304 at regular intervals or when triggered by a polling bit in a PDU. The status update 304 may, for example, acknowledge PDU#1 and PDU#2. PDU#3 may be unacknowledged. For example, PDU#3 may not have received by the network 16, PDU#3 may not have been included in the last polling, or PDU#3 may have been negatively acknowledged (NACK). UE 12 may retransmit PDU#3, wait for a timer, or wait for further status updates.

[0046] The network 16 may send an RRC message 306. The RRC message 306 may be, for example, an RRC reconfiguration message indicating an inter-RAT change that results in an RLC release 308. Other RRC messages such as a radio bearer release or a RRC release may also result in an RLC release 308. RLC release 308 may also be triggered by other messages or higher layer actions.

[0047] The RLC release 308 may include releasing an RLC entity 40. As a result of the

RLC entity 40 being released, the UE 12 may return SDU 302 to a RAB queue 32 because the SDU 302 has been transmitted but not fully acknowledged. The RLC release 308 may also include establishment of an RLC entity 45 over a new connection.

[0048] The UE 12 may transmit the SDU 302 as a second set of PDUs using the RLC entity 45. The second set of PDUs may include PDU#4 and PDU#5. The second set of PDUs may include similar information as the first set of PDUs, but may be segmented into a different number of PDUs. The headers for the PDUs may also be different. The network 16 may transmit a status update message 310 acknowledging receipt of PDU#4 and PDU#5. Accordingly, UE 12 may consider SDU 302 to be acknowledged.

[0049] FIG. 5 is a block diagram illustrating an example of a hardware implementation for an apparatus 400 employing a processing system 414. For example, the apparatus 400 may be an example of the UE 12 including modem component 20 for releasing an RLC entity. In this example, the processing system 414 may be implemented with a bus architecture, represented generally by the bus 402. The bus 402 may include any number of interconnecting buses and bridges depending on the specific application of the processing system 414 and the overall design constraints. The bus 402 links together various circuits including one or more processors, represented generally by the processor 404, and computer-readable media, represented generally by the computer- readable medium 406. The bus 402 may also link various other circuits such as timing sources, peripherals, voltage regulators, and power management circuits, which are well known in the art, and therefore, will not be described any further. A bus interface 408 provides an interface between the bus 402 and a transceiver 410. The transceiver 410 provides a means for communicating with various other apparatus over a transmission medium. Depending upon the nature of the apparatus, a user interface 412 (e.g., keypad, display, speaker, microphone, joystick) may also be provided. [0050] The processor 404 is responsible for managing the bus 402 and general processing, including the execution of software stored on the computer-readable medium 406. The software, when executed by the processor 404, causes the processing system 414 to perform the various functions described infra for any particular apparatus. The computer-readable medium 406 may also be used for storing data that is manipulated by the processor 404 when executing software.

[0051] The various concepts presented throughout this disclosure may be implemented across a broad variety of telecommunication systems, network architectures, and communication standards. By way of example and without limitation, the aspects of the present disclosure illustrated in FIG. 6 are presented with reference to a UMTS system 500 employing a W-CDMA air interface. A UMTS network includes three interacting domains: a Core Network (CN) 504, a UMTS Terrestrial Radio Access Network (UTRAN) 502, and User Equipment (UE) 510. The UE 510 may be an example of the UE 12 (FIG. 1) and include a modem component 20 for releasing an RLC entity. In this example, the UTRAN 502 provides various wireless services including telephony, video, data, messaging, broadcasts, and/or other services. The UTRAN 502 may include a plurality of Radio Network Subsystems (RNSs) such as an RNS 507, each controlled by a respective Radio Network Controller (RNC) such as an RNC 506. Here, the UTRAN 502 may include any number of RNCs 506 and RNSs 507 in addition to the RNCs 506 and RNSs 507 illustrated herein. The RNC 506 is an apparatus responsible for, among other things, assigning, reconfiguring and releasing radio resources within the RNS 507. The RNC 506 may be interconnected to other RNCs (not shown) in the UTRAN 502 through various types of interfaces such as a direct physical connection, a virtual network, or the like, using any suitable transport network.

[0052] Communication between a UE 510 and a Node B 508 may be considered as including a physical (PHY) layer and a medium access control (MAC) layer. Further, communication between a UE 510 and an RNC 506 by way of a respective Node B 508 may be considered as including a radio resource control (RRC) layer. In the instant specification, the PHY layer may be considered layer 1; the MAC layer may be considered layer 2; and the RRC layer may be considered layer 3. Information hereinbelow utilizes terminology introduced in the RRC Protocol Specification, 3GPP TS 25.331 v9.1.0, incorporated herein by reference. [0053] The geographic region covered by the RNS 507 may be divided into a number of cells, with a radio transceiver apparatus serving each cell. A radio transceiver apparatus is commonly referred to as a Node B in UMTS applications, but may also be referred to by those skilled in the art as a base station (BS), a base transceiver station (BTS), a radio base station, a radio transceiver, a transceiver function, a basic service set (BSS), an extended service set (ESS), an access point (AP), or some other suitable terminology. For clarity, three Node Bs 508 are shown in each RNS 507; however, the RNSs 507 may include any number of wireless Node Bs. The Node Bs 508 provide wireless access points to a CN 504 for any number of mobile apparatuses. Examples of a mobile apparatus include a cellular phone, a smart phone, a session initiation protocol (SIP) phone, a laptop, a notebook, a netbook, a smartbook, a personal digital assistant (PDA), a satellite radio, a global positioning system (GPS) device, a multimedia device, a video device, a digital audio player (e.g., MP3 player), a camera, a game console, or any other similar functioning device. The mobile apparatus is commonly referred to as a UE in UMTS applications, but may also be referred to by those skilled in the art as a mobile station, a subscriber station, a mobile unit, a subscriber unit, a wireless unit, a remote unit, a mobile device, a wireless device, a wireless communications device, a remote device, a mobile subscriber station, an access terminal, a mobile terminal, a wireless terminal, a remote terminal, a handset, a terminal, a user agent, a mobile client, a client, or some other suitable terminology. In a UMTS system, the UE 510 may further include a universal subscriber identity module (USIM) 511, which contains a user's subscription information to a network. For illustrative purposes, one UE 510 is shown in communication with a number of the Node Bs 508. The DL, also called the forward link, refers to the communication link from a Node B 508 to a UE 510, and the UL, also called the reverse link, refers to the communication link from a UE 510 to a Node B 508. The UE 510 may further include a mobile component 513 for managing mobility of UE 510 among the Node Bs 508.

[0054] The CN 504 interfaces with one or more access networks, such as the UTRAN

502. As shown, the CN 504 is a GSM core network. However, as those skilled in the art will recognize, the various concepts presented throughout this disclosure may be implemented in a RAN, or other suitable access network, to provide UEs with access to types of CNs other than GSM networks. [0055] The CN 504 includes a circuit- switched (CS) domain and a packet-switched (PS) domain. Some of the circuit- switched elements are a Mobile services Switching Centre (MSC), a Visitor location register (VLR) and a Gateway MSC. Packet- switched elements include a Serving GPRS Support Node (SGSN) and a Gateway GPRS Support Node (GGSN). Some network elements, like EIR, HLR, VLR and AuC may be shared by both of the circuit- switched and packet-switched domains. In the illustrated example, the CN 504 supports circuit- switched services with a MSC 512 and a GMSC 514. In some applications, the GMSC 514 may be referred to as a media gateway (MGW). One or more RNCs, such as the RNC 506, may be connected to the MSC 512. The MSC 512 is an apparatus that controls call setup, call routing, and UE mobility functions. The MSC 512 also includes a VLR that contains subscriber-related information for the duration that a UE is in the coverage area of the MSC 512. The GMSC 514 provides a gateway through the MSC 512 for the UE to access a circuit- switched network 516. The GMSC 514 includes a home location register (HLR) 515 containing subscriber data, such as the data reflecting the details of the services to which a particular user has subscribed. The HLR is also associated with an authentication center (AuC) that contains subscriber-specific authentication data. When a call is received for a particular UE, the GMSC 514 queries the HLR 515 to determine the UE's location and forwards the call to the particular MSC serving that location.

[0056] The CN 504 also supports packet-data services with a serving GPRS support node (SGSN) 518 and a gateway GPRS support node (GGSN) 520. GPRS, which stands for General Packet Radio Service, is designed to provide packet-data services at speeds higher than those available with standard circuit-switched data services. The GGSN 520 provides a connection for the UTRAN 502 to a packet-based network 522. The packet-based network 522 may be the Internet, a private data network, or some other suitable packet-based network. The primary function of the GGSN 520 is to provide the UEs 510 with packet-based network connectivity. Data packets may be transferred between the GGSN 520 and the UEs 510 through the SGSN 518, which performs primarily the same functions in the packet-based domain as the MSC 512 performs in the circuit- switched domain.

[0057] An air interface for UMTS may utilize a spread spectrum Direct-Sequence Code

Division Multiple Access (DS-CDMA) system. The spread spectrum DS-CDMA spreads user data through multiplication by a sequence of pseudorandom bits called chips. The "wideband" W-CDMA air interface for UMTS is based on such direct sequence spread spectrum technology and additionally calls for a frequency division duplexing (FDD). FDD uses a different carrier frequency for the UL and DL between a Node B 508 and a UE 510. Another air interface for UMTS that utilizes DS-CDMA, and uses time division duplexing (TDD), is the TD-SCDMA air interface. Those skilled in the art will recognize that although various examples described herein may refer to a W-CDMA air interface, the underlying principles may be equally applicable to a TD- SCDMA air interface.

[0058] An HSPA air interface includes a series of enhancements to the 3G/W-CDMA air interface, facilitating greater throughput and reduced latency. Among other modifications over prior releases, HSPA utilizes hybrid automatic repeat request (HARQ), shared channel transmission, and adaptive modulation and coding. The standards that define HSPA include HSDPA (high speed downlink packet access) and HSUPA (high speed uplink packet access, also referred to as enhanced uplink, or EUL).

[0059] HSDPA utilizes as its transport channel the high-speed downlink shared channel

(HS-DSCH). The HS-DSCH is implemented by three physical channels: the high-speed physical downlink shared channel (HS-PDSCH), the high-speed shared control channel (HS-SCCH), and the high-speed dedicated physical control channel (HS-DPCCH).

[0060] Among these physical channels, the HS-DPCCH carries the HARQ

ACK/NACK signaling on the uplink to indicate whether a corresponding packet transmission was decoded successfully. That is, with respect to the downlink, the UE 510 provides feedback to the node B 508 over the HS-DPCCH to indicate whether it correctly decoded a packet on the downlink.

[0061] HS-DPCCH further includes feedback signaling from the UE 510 to assist the node B 508 in taking the right decision in terms of modulation and coding scheme and precoding weight selection, this feedback signaling including the CQI and PCI.

[0062] "HSPA Evolved" or HSPA+ is an evolution of the HSPA standard that includes

MIMO and 64-QAM, enabling increased throughput and higher performance. That is, in an aspect of the disclosure, the node B 508 and/or the UE 510 may have multiple antennas supporting MIMO technology. The use of MIMO technology enables the node B 508 to exploit the spatial domain to support spatial multiplexing, beamforming, and transmit diversity. [0063] Multiple Input Multiple Output (MIMO) is a term generally used to refer to multi-antenna technology, that is, multiple transmit antennas (multiple inputs to the channel) and multiple receive antennas (multiple outputs from the channel). MIMO systems generally enhance data transmission performance, enabling diversity gains to reduce multipath fading and increase transmission quality, and spatial multiplexing gains to increase data throughput.

[0064] Spatial multiplexing may be used to transmit different streams of data simultaneously on the same frequency. The data steams may be transmitted to a single UE 510 to increase the data rate or to multiple UEs 510 to increase the overall system capacity. This is achieved by spatially precoding each data stream and then transmitting each spatially precoded stream through a different transmit antenna on the downlink. The spatially precoded data streams arrive at the UE(s) 510 with different spatial signatures, which enables each of the UE(s) 510 to recover the one or more the data streams destined for that UE 510. On the uplink, each UE 510 may transmit one or more spatially precoded data streams, which enables the node B 508 to identify the source of each spatially precoded data stream.

[0065] Spatial multiplexing may be used when channel conditions are good. When channel conditions are less favorable, beamforming may be used to focus the transmission energy in one or more directions, or to improve transmission based on characteristics of the channel. This may be achieved by spatially precoding a data stream for transmission through multiple antennas. To achieve good coverage at the edges of the cell, a single stream beamforming transmission may be used in combination with transmit diversity.

[0066] Generally, for MIMO systems utilizing n transmit antennas, n transport blocks may be transmitted simultaneously over the same carrier utilizing the same channelization code. Note that the different transport blocks sent over the n transmit antennas may have the same or different modulation and coding schemes from one another.

[0067] On the other hand, Single Input Multiple Output (SIMO) generally refers to a system utilizing a single transmit antenna (a single input to the channel) and multiple receive antennas (multiple outputs from the channel). Thus, in a SIMO system, a single transport block is sent over the respective carrier. [0068] Referring to FIG. 7, an access network 600 in a UTRAN architecture is illustrated. The access network 500 may provide communications for UEs 530, 532, 534, 536, 538, 540, each of which may be an example of the UE 12 (FIG. 1) and include a modem component 20. The multiple access wireless communication system includes multiple cellular regions (cells), including cells 602, 604, and 606, each of which may include one or more sectors. The multiple sectors can be formed by groups of antennas with each antenna responsible for communication with UEs in a portion of the cell. For example, in cell 602, antenna groups 612, 614, and 616 may each correspond to a different sector. In cell 604, antenna groups 618, 620, and 622 each correspond to a different sector. In cell 606, antenna groups 624, 626, and 628 each correspond to a different sector. The cells 602, 604 and 606 may include several wireless communication devices, e.g., User Equipment or UEs, which may be in communication with one or more sectors of each cell 602, 604 or 606. For example, UEs 630 and 632 may be in communication with Node B 642, UEs 634 and 636 may be in communication with Node B 644, and UEs 638 and 640 can be in communication with Node B 646. Here, each Node B 642, 644, 646 is configured to provide an access point to a CN 504 (see FIG. 6) for all the UEs 630, 632, 634, 636, 638, 640 in the respective cells 602, 604, and 606.

[0069] As the UE 634 moves from the illustrated location in cell 604 into cell 606, a serving cell change (SCC) or handover may occur in which communication with the UE 634 transitions from the cell 604, which may be referred to as the source cell, to cell 606, which may be referred to as the target cell. Management of the handover procedure may take place at the UE 634, at the Node Bs corresponding to the respective cells, at a radio network controller 506 (see FIG. 6), or at another suitable node in the wireless network. For example, during a call with the source cell 604, or at any other time, the UE 634 may monitor various parameters of the source cell 604 as well as various parameters of neighboring cells such as cells 606 and 602. Further, depending on the quality of these parameters, the UE 634 may maintain communication with one or more of the neighboring cells. During this time, the UE 634 may maintain an Active Set, that is, a list of cells that the UE 634 is simultaneously connected to (i.e., the UTRA cells that are currently assigning a downlink dedicated physical channel DPCH or fractional downlink dedicated physical channel F-DPCH to the UE 634 may constitute the Active Set). [0070] The modulation and multiple access scheme employed by the access network

600 may vary depending on the particular telecommunications standard being deployed. By way of example, the standard may include Evolution-Data Optimized (EV-DO) or Ultra Mobile Broadband (UMB). EV-DO and UMB are air interface standards promulgated by the 3rd Generation Partnership Project 2 (3GPP2) as part of the CDMA2000 family of standards and employs CDMA to provide broadband Internet access to mobile stations. The standard may alternately be Universal Terrestrial Radio Access (UTRA) employing Wideband-CDMA (W-CDMA) and other variants of CDMA, such as TD-SCDMA; Global System for Mobile Communications (GSM) employing TDM A; and Evolved UTRA (E-UTRA), Ultra Mobile Broadband (UMB), IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, and Flash-OFDM employing OFDM A. UTRA, E-UTRA, UMTS, LTE, LTE Advanced, and GSM are described in documents from the 3GPP organization. CDMA2000 and UMB are described in documents from the 3GPP2 organization. The actual wireless communication standard and the multiple access technology employed will depend on the specific application and the overall design constraints imposed on the system.

[0071] The radio protocol architecture may take on various forms depending on the particular application. An example for an HSPA system will now be presented with reference to FIG. 8.

[0072] Referring to FIG. 8 an example radio protocol architecture 700 is shown that relates to a user plane 702 and a control plane 704 of a user UE or node B/base station. For example, radio protocol architecture 700 may be included in UE 12 (FIG. 1). The radio protocol architecture 700 for the UE and node B is shown with three layers: Layer 1 706, Layer 2 708, and Layer 3 710. Layer 1 706 is the lowest lower and implements various physical layer signal processing functions. As such, Layer 1 706 includes the physical layer 707. Layer 2 (L2 layer) 708 is above the physical layer 707 and is responsible for the link between the UE and node B over the physical layer 707. Layer 3 (L3 layer) 710 includes a radio resource control (RRC) sublayer 715. The RRC sublayer 715 handles the control plane signaling of Layer 3 between the UE and the UTRAN.

[0073] In the user plane, the L2 layer 708 includes a media access control (MAC) sublayer 709, a radio link control (RLC) sublayer 711, and a packet data convergence protocol (PDCP) 713 sublayer, which are terminated at the node B on the network side. Although not shown, the UE may have several upper layers above the L2 layer 708 including a network layer (e.g., IP layer) that is terminated at a PDN gateway on the network side, and an application layer that is terminated at the other end of the connection (e.g., far end UE, server, etc.).

[0074] The PDCP sublayer 713 provides multiplexing between different radio bearers and logical channels. The PDCP sublayer 713 also provides header compression for upper layer data packets to reduce radio transmission overhead, security by ciphering the data packets, and handover support for UEs between node Bs. The RLC sublayer 711 provides segmentation and reassembly of upper layer data packets, retransmission of lost data packets, and reordering of data packets to compensate for out-of-order reception due to hybrid automatic repeat request (HARQ). The MAC sublayer 709 provides multiplexing between logical and transport channels. The MAC sublayer 709 is also responsible for allocating the various radio resources (e.g., resource blocks) in one cell among the UEs. The MAC sublayer 709 is also responsible for HARQ operations.

[0075] FIG. 9 is a block diagram of a Node B 810 in communication with a UE 850, where the Node B 810 may be the Node B 508 in FIG. 6, and the UE 850 may be the UE 510 in FIG. 6 or the UE 12 in FIG 1. The UE 850 may include a modem component 20 for controlling release of an RLC entity. In the downlink communication, a transmit processor 820 may receive data from a data source 812 and control signals from a controller/processor 840. The transmit processor 820 provides various signal processing functions for the data and control signals, as well as reference signals (e.g., pilot signals). For example, the transmit processor 820 may provide cyclic redundancy check (CRC) codes for error detection, coding and interleaving to facilitate forward error correction (FEC), mapping to signal constellations based on various modulation schemes (e.g., binary phase-shift keying (BPSK), quadrature phase-shift keying (QPSK), M-phase-shift keying (M-PSK), M-quadrature amplitude modulation (M-QAM), and the like), spreading with orthogonal variable spreading factors (OVSF), and multiplying with scrambling codes to produce a series of symbols. Channel estimates from a channel processor 844 may be used by a controller/processor 840 to determine the coding, modulation, spreading, and/or scrambling schemes for the transmit processor 820. These channel estimates may be derived from a reference signal transmitted by the UE 850 or from feedback from the UE 850. The symbols generated by the transmit processor 820 are provided to a transmit frame processor 830 to create a frame structure. The transmit frame processor 830 creates this frame structure by multiplexing the symbols with information from the controller/processor 840, resulting in a series of frames. The frames are then provided to a transmitter 832, which provides various signal conditioning functions including amplifying, filtering, and modulating the frames onto a carrier for downlink transmission over the wireless medium through antenna 834. The antenna 834 may include one or more antennas, for example, including beam steering bidirectional adaptive antenna arrays or other similar beam technologies.

[0076] At the UE 850, a receiver 854 receives the downlink transmission through an antenna 852 and processes the transmission to recover the information modulated onto the carrier. The information recovered by the receiver 854 is provided to a receive frame processor 860, which parses each frame, and provides information from the frames to a channel processor 894 and the data, control, and reference signals to a receive processor 870. The receive processor 870 then performs the inverse of the processing performed by the transmit processor 820 in the Node B 810. More specifically, the receive processor 870 descrambles and despreads the symbols, and then determines the most likely signal constellation points transmitted by the Node B 810 based on the modulation scheme. These soft decisions may be based on channel estimates computed by the channel processor 894. The soft decisions are then decoded and deinterleaved to recover the data, control, and reference signals. The CRC codes are then checked to determine whether the frames were successfully decoded. The data carried by the successfully decoded frames will then be provided to a data sink 872, which represents applications running in the UE 850 and/or various user interfaces (e.g., display). Control signals carried by successfully decoded frames will be provided to a controller/processor 890. When frames are unsuccessfully decoded by the receiver processor 870, the controller/processor 890 may also use an acknowledgement (ACK) and/or negative acknowledgement (NACK) protocol to support retransmission requests for those frames.

[0077] In the uplink, data from a data source 878 and control signals from the controller/processor 890 are provided to a transmit processor 880. The data source 878 may represent applications running in the UE 850 and various user interfaces (e.g., keyboard). The modem component 20 may control an RLC entity for generating PDUs from the applications or other higher layer sources. Similar to the functionality described in connection with the downlink transmission by the Node B 810, the transmit processor 880 provides various signal processing functions including CRC codes, coding and interleaving to facilitate FEC, mapping to signal constellations, spreading with OVSFs, and scrambling to produce a series of symbols. Channel estimates, derived by the channel processor 894 from a reference signal transmitted by the Node B 810 or from feedback contained in the midamble transmitted by the Node B 810, may be used to select the appropriate coding, modulation, spreading, and/or scrambling schemes. The symbols produced by the transmit processor 880 will be provided to a transmit frame processor 882 to create a frame structure. The transmit frame processor 882 creates this frame structure by multiplexing the symbols with information from the controller/processor 890, resulting in a series of frames. The frames are then provided to a transmitter 856, which provides various signal conditioning functions including amplification, filtering, and modulating the frames onto a carrier for uplink transmission over the wireless medium through the antenna 852.

[0078] The uplink transmission is processed at the Node B 810 in a manner similar to that described in connection with the receiver function at the UE 850. A receiver 835 receives the uplink transmission through the antenna 834 and processes the transmission to recover the information modulated onto the carrier. The information recovered by the receiver 835 is provided to a receive frame processor 836, which parses each frame, and provides information from the frames to the channel processor 844 and the data, control, and reference signals to a receive processor 838. The receive processor 838 performs the inverse of the processing performed by the transmit processor 880 in the UE 850. The data and control signals carried by the successfully decoded frames may then be provided to a data sink 839 and the controller/processor, respectively. If some of the frames were unsuccessfully decoded by the receive processor, the controller/processor 840 may also use an acknowledgement (ACK) and/or negative acknowledgement (NACK) protocol to support retransmission requests for those frames.

[0079] The controller/processors 840 and 890 may be used to direct the operation at the

Node B 810 and the UE 850, respectively. For example, the controller/processors 840 and 890 may provide various functions including timing, peripheral interfaces, voltage regulation, power management, and other control functions. The computer readable media of memories 842 and 892 may store data and software for the Node B 810 and the UE 850, respectively. A scheduler/processor 846 at the Node B 810 may be used to allocate resources to the UEs and schedule downlink and/or uplink transmissions for the UEs.

[0080] Several aspects of a telecommunications system have been presented with reference to a W-CDMA system. As those skilled in the art will readily appreciate, various aspects described throughout this disclosure may be extended to other telecommunication systems, network architectures and communication standards.

[0081] By way of example, various aspects may be extended to other UMTS systems such as TD-SCDMA, High Speed Downlink Packet Access (HSDPA), High Speed Uplink Packet Access (HSUPA), High Speed Packet Access Plus (HSPA+) and TD- CDMA. Various aspects may also be extended to systems employing Long Term Evolution (LTE) (in FDD, TDD, or both modes), LTE-Advanced (LTE-A) (in FDD, TDD, or both modes), CDMA2000, Evolution-Data Optimized (EV-DO), Ultra Mobile Broadband (UMB), IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, Ultra- Wideband (UWB), Bluetooth, and/or other suitable systems. The actual telecommunication standard, network architecture, and/or communication standard employed will depend on the specific application and the overall design constraints imposed on the system.

[0082] In accordance with various aspects of the disclosure, an element, or any portion of an element, or any combination of elements may be implemented with a "processing system" that includes one or more processors. Examples of processors include microprocessors, microcontrollers, digital signal processors (DSPs), field programmable gate arrays (FPGAs), programmable logic devices (PLDs), state machines, gated logic, discrete hardware circuits, and other suitable hardware configured to perform the various functionality described throughout this disclosure. One or more processors in the processing system may execute software. Software shall be construed broadly to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software modules, applications, software applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, functions, etc., whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise. The software may reside on a computer-readable medium. The computer-readable medium may be a non-transitory computer-readable medium. A non-transitory computer-readable medium includes, by way of example, a magnetic storage device (e.g., hard disk, floppy disk, magnetic strip), an optical disk (e.g., compact disk (CD), digital versatile disk (DVD)), a smart card, a flash memory device (e.g., card, stick, key drive), random access memory (RAM), read only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), a register, a removable disk, and any other suitable medium for storing software and/or instructions that may be accessed and read by a computer. The computer-readable medium may also include, by way of example, a carrier wave, a transmission line, and any other suitable medium for transmitting software and/or instructions that may be accessed and read by a computer. The computer-readable medium may be resident in the processing system, external to the processing system, or distributed across multiple entities including the processing system. The computer- readable medium may be embodied in a computer-program product. By way of example, a computer-program product may include a computer-readable medium in packaging materials. Those skilled in the art will recognize how best to implement the described functionality presented throughout this disclosure depending on the particular application and the overall design constraints imposed on the overall system.

[0083] It is to be understood that the specific order or hierarchy of steps in the methods disclosed is an illustration of exemplary processes. Based upon design preferences, it is understood that the specific order or hierarchy of steps in the methods may be rearranged. The accompanying method claims present elements of the various steps in a sample order, and are not meant to be limited to the specific order or hierarchy presented unless specifically recited therein.

[0084] The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein, but is to be accorded the full scope consistent with the language of the claims, wherein reference to an element in the singular is not intended to mean "one and only one" unless specifically so stated, but rather "one or more." Unless specifically stated otherwise, the term "some" refers to one or more. A phrase referring to "at least one of a list of items refers to any combination of those items, including single members. As an example, "at least one of: a, b, or c" is intended to cover: a; b; c; a and b; a and c; b and c; and a, b and c. All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims. No claim element is to be construed under the provisions of 35 U.S.C. §112, sixth paragraph, unless the element is expressly recited using the phrase "means for" or, in the case of a method claim, the element is recited using the phrase "step for."