Abstract:
The application discloses techniques for determining where to locate and how to fit the duplicate detection functionality within the PDCP architecture as well as determining when to activate or deactivate various PDCP functions, such as the PDCP reordering function. These mechanisms can be implemented in wireless devices such as a WTRU, or in any wireless network nodes.

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application claims the benefit of U.S. provisional application No. 60/949,095, filed Jul. 11, 2007, which is incorporated by reference as if fully set forth. 
     
    
     FIELD OF INVENTION 
       [0002]    This application relates to wireless systems that utilize a packet data convergence protocol (PDCP) sublayer, such as the Third generation partnership project (3GPP) long term evolution (LTE) and/or high speed packet access (HSPA). 
       BACKGROUND 
       [0003]    The long term evolution (LTE) of the Third Generation Partnership Protocol (3GPP) has defined a user-plane protocol stack architecture as shown in  FIG. 1 , that includes the Layer 2 (L2) sub layers: packet data convergence protocol (PDCP), radio link control (RLC) and medium access control (MAC). 
         [0004]    In 3GPP, the main services and functions of the PDCP sublayer include:
       Header compression and decompression: robust header compression (ROHC) only;   Transfer of user data: transmission of user data means that PDCP receives PDCP system data unit (SDU) from the non access stratum (NAS) and forwards it to the RLC layer and vice versa;   Reordering of the downlink RLC SDUs at least during inter-evolved Node-B (eNB) mobility;   In-sequence delivery of upper layer PDUs at HO in the uplink (FFS);   Duplicate detection of lower layer SDUs;   Ciphering of user plane data and control plane data (NAS Signaling);       
 
         [0011]    According to 3GPP, the Packet Data Convergence Protocol (PDCP) supports the following functions:
       header compression and decompression of IP data flows (using the ROHC protocol, FFS) at the transmitting and receiving entity, respectively.
           transfer of data (user plane or radio resource control (RRC) data). This function is used for conveyance of data between users of PDCP services.   maintenance of PDCP sequence numbers for radio bearers.   in-sequence delivery of upper layer protocol data unit (PDU)s at handover (HO);   duplicate detection of lower layer SDUs;   ciphering and deciphering of user plane data and control plane data;   integrity protection of control plane data   
               
 
         [0019]      FIG. 2  depicts the PDCP PDU structure which consists of PDCP SDU and a PDCP header, and the PDCP header may be either 1 or 2 bytes long. 
         [0020]    COUNT
       For ciphering and integrity, a COUNT value is maintained. The COUNT value is composed of a Hyper Frame Number (HFN) and the Sequence Number (SN) as shown in  FIG. 3 . The SN is transmitted in each PDCP packet (e.g. the PDCP SN), while the HFN is not transmitted in each packet but rather maintained locally. The size of the HFN part depends on the size of the SN. The COUNT is constructed (assigned) at the PDCP receiver (e.g. in the WTRU) from the received PDCP SN and the locally stored HFN i.e. a COUNT assignment function exists at the PDCP receiver.       
 
         [0022]    For PDCP layering, the PDCP entity at the receiver will perform reordering  30  after performing deciphering  20  and decompression  10  at the receiver, as in Option  3  shown in  FIG. 4 . Alternatively, as in Option  1 , the receiver performs decompression  10  after reordering  30  followed by deciphering  20  or, as in Option  2 , the receiver performs decompression  10  after deciphering  20  followed by reordering  10 . 
         [0023]    Mechanisms for locating and fitting the “duplicate detection of lower layer SDUs” function into the PDCP layering architecture in an efficient and effective manner, especially in relation to the other functions that exist in the PDCP layer are desirable. Techniques for generating indications/triggers to be utilized by the various PDCP functions such as reordering and/or duplicate detection and/or any other PDCP function are also desirable in the LTE environment. Mechanisms for efficiently activating and deactivating the PDCP reordering function need are also desirable. 
       SUMMARY 
       [0024]    Techniques for determining where to locate and how to fit the duplicate detection functionality within the PDCP architecture as well as determining when to activate or deactivate various PDCP functions, such as the PDCP reordering function are disclosed. These mechanisms may be implemented in wireless devices such as a WTRU, or in wireless network nodes. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0025]    A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings wherein: 
           [0026]      FIG. 1  shows a LTE user-plane protocol stack; 
           [0027]      FIG. 2  shows a PDCP PDU Structure; 
           [0028]      FIG. 3  shows a format of a COUNT information element; 
           [0029]      FIG. 4  shows possible locations for the PDCP reordering function; 
           [0030]      FIG. 5  shows alternative locations for the duplicate detection functionality within the WTRU PDCP receiver; 
           [0031]      FIG. 6  is a signaling diagram showing an example embodiment; 
           [0032]      FIG. 7  is a signaling diagram showing another embodiment; 
           [0033]      FIG. 8  is a signaling diagram showing another embodiment; and 
           [0034]      FIG. 9  shows an example device in which the disclosed embodiments may be implemented. 
       
    
    
     DETAILED DESCRIPTION 
       [0035]    When referred to hereafter, the terminology “wireless transmit/receive unit (WTRU)” includes but is not limited to a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a computer, or any other type of user device capable of operating in a wireless environment. When referred to hereafter, the terminology “base station” includes but is not limited to a Node-B, eNB, a site controller, an access point (AP), or any other type of interfacing device capable of operating in a wireless environment. When referred to hereafter, the term eNB refers to any of the following: Evolved Universal Terrestrial Radio Access Network (UTRAN) Node-B, E-UTRAN Node-B, evolved Node-B. When referred to hereafter, the term PDCP refers to any of the following: a PDCP entity, the PDCP sublayer or PDCP functions/protocol. 
         [0036]    It should be noted that although some variables are referred to such as Rx_PDCP_SN at multiple places and within different algorithms, such variables may either be independent from each other (although referenced by the same variable name in different functions), or alternatively may be shared between different PDCP functions. 
         [0037]    Although functions are described within different sections below, it is possible to combine, merge or apply some of the concepts/methods described in certain sections for the purposes of other sections. Some of the algorithms described in this disclosure may also be applied in other scenarios, in different circumstances, or to solve other problems in addition to those described in this disclosure. 
         [0038]    The following describes embodiments for locating the packet duplication detection function within the PDCP layer. Other aspects of the PDCP layer described herein may or may not be used with these locations for the packet duplicate detection function. “Duplicate detection of lower layer SDUs” is a function of PDCP. The embodiments below include three example alternatives for performing the duplicate detection function within the PDCP sublayer. 
         [0039]      FIG. 5  illustrates the three alternatives (embodiments), by building on Option  3  of  FIG. 4 .  FIG. 5  also shows the COUNT Assignment operation  50  which is performed prior to the deciphering function  20 . The procedures, shown in  FIG. 5 , may be implemented in software (and/or firmware, hardware, etc.) in a device such as the WTRU  900  shown in  FIG. 9 . 
         [0040]    In a first embodiment (Alternative  1  in  FIG. 5 ), the duplicate detection function  44  is performed at or near the top of the Rx PDCP sublayer, preferably in conjunction  40  with the reordering function  42 . The processor  920 , shown in  FIG. 9 , will perform the procedures shown in  FIG. 5 . The processor  920  will determine the COUNT  50  first, then perform deciphering  20 , then perform header decompression  10 , then perform duplicate detection and reordering  40  ( 44  duplicate detection and  42  reordering, respectively). 
         [0041]    In a second embodiment (Alternative  2  in  FIG. 5 ), the duplicate detection function  60  is performed at or near the bottom of the Rx PDCP sublayer, preferably before the COUNT assignment function  50 . In this embodiment, the processor  920 , shown in  FIG. 9 , will perform duplicate detection  60  first, then it will determine the COUNT  50 , then deciphering  20 , then header decompression  10 , and then it will perform reordering  30 . 
         [0042]    In a third embodiment (Alternative  3  in  FIG. 5 ), the duplicate detection function  74  is performed at or near the bottom of the Rx PDCP sublayer, preferably in conjunction  70  with the COUNT determination function  72 . The processor  920 , shown in  FIG. 9 , will perform duplicate detection and determine the COUNT  70  ( 74  duplicate detection and COUNT  72 , respectively), then it will perform deciphering  20 , then header decompression  10 , and then it will perform reordering  30 . 
         [0043]    In the second and third embodiments, the duplicate detection function ( 60  and  74  respectively) can discard duplicates early eliminating the need to apply deciphering and/or decompression on packets that will ultimately be discarded. Also, such alternatives may simplify the COUNT assignment operation ( 50  and  70  respectively). 
         [0044]    Additional embodiments that perform duplicate detection at the PDCP receiver are disclosed below. 
         [0045]    Variables/Parameters:
       PDCP_SN: The received PDU includes the PDCP_SN which is the SN of the received PDCP packet.   WTRU Receive Variables:
           Rx_PDCP_SN: The SN expected for the next PDCP packet to be received.   Rx_Status[SN]=Indicates whether the packet having such SN was already received or not; initially, Rx_Status[SN]=‘Not Received’ for all SN&#39;s;   
               
 
         [0050]    In this embodiment, the duplicate detection method will utilize the PDCP SN of the received packet to determine whether the PDCP sublayer&#39;s buffer stores something at such PDCP SN; if so, the packet is discarded; if not, the packet is accepted. The following illustrates the operation: 
         [0051]    If (Rx_Status[PDCP_SN]==‘Not Received’;
       Accept (i.e. store) packet;   Rx_Status[PDCP_SN]=‘Received’;       
 
         [0054]    Else
       Discard packet;       
 
         [0056]    The following describes embodiments for providing indications to be utilized as triggers for PDCP functions. Other aspects of the PDCP layer described herein may or may not use these indications/triggers. Certain PDCP functions take handover (inter-eNB mobility) into account either directly or indirectly. For example, in 3GPP “Reordering of the downlink RLC SDUs at least during inter-eNB mobility” and “In-sequence delivery of upper layer PDUs at HO” are functions in the PDCP sub-layer. 
         [0057]    Additionally, the deciphering COUNT assignment/construction algorithm may also need to take handover (inter-eNB mobility) into account either directly or indirectly. 
         [0058]    In another embodiment, a variety of indications may be utilized to trigger the functions within PDCP, such as indicating when to start or stop the PDCP reordering function, COUNT assignment function, or any other function. These indications may be implemented as primitives, signals, messages, events, or in any other form. 
         [0059]    The indications that are described may be sent directly to the PDCP sublayer, or may be sent indirectly to the PDCP sublayer via another layer that generates another subsequent indication: as an example, the RRC layer may generate indications to the PDCP sublayer based on indications that the RRC layer receives. 
         [0060]    Described below are two classes or types of indications:
       Type A indications, such as an indication that inter-eNB mobility (e.g. handover) has started or is about to start.   Type B indications, such as an indication that inter-eNB mobility (e.g. handover) has completed.       
 
         [0063]    Although these indications are described in the context of a mobility scenario, they are also applicable and may be utilized during other scenarios that are not tied to inter-eNB mobility (e.g. handover). 
         [0064]    Although a given indication may be classified as Type A or Type B, some Type A indications may also be suitable as (serve as) Type B indications, and vice versa. 
         [0065]    Type A indications that are handover or RRC related may include one or more of the following:
       Indication of the WTRU reception of the Handover Command message   Indication that the WTRU is in an inter-eNB mobility state (e.g. HO in progress)   Any other indication signifying that HO (e.g. inter-eNB mobility) is about to occur       
 
         [0069]    Type A indications that are RLC related may include one or more of the following:
       Indication of initiating RLC reset   Indication of initiating RLC re-establishment   Indication of RLC flushing (its reordering buffer) and/or forwarding the packets it had in its buffer   Indication of RLC timing out on missing PDUs (i.e. SN gaps)   Indication of RLC receiving MRW command   Indication of RLC out-of-sequence delivery to upper layers due to HO   Indication of suspension of RLC in-sequence delivery to upper layers due to HO   Indication of RLC out-of-sequence delivery to upper layers due to reset or reestablishment   Indication of suspension of RLC in-sequence delivery to upper layers due to reset or reestablishment   Indication of RLC out-of-sequence delivery to upper layers (due to any reason)   Indication of suspension of RLC in-sequence delivery to upper layers (due to any reason)       
 
         [0081]    Type B indications that are handover (HO) or RRC related may include one or more of the following:
       Indication of the WTRU sending of the Handover Confirm message (or equivalently the indications that cause the Handover Confirm message to be sent)   Indication that the WTRU successfully accessed the target cell   Indication that the WTRU has exited the inter-eNB mobility state (e.g. HO completed)   Any other event indicating that HO (e.g. inter-eNB mobility) is complete       
 
         [0086]    Type B indications that are RLC related may include one or more of the following:
       Indication of successful or completed RLC reset   Indication of successful or completed RLC re-establishment   Indication of RLC in-sequence delivery to upper layers after HO (i.e. in the target eNB)   Indication of RLC in-sequence delivery to upper layers after reset or reestablishment   Indication of RLC in-sequence delivery to upper layers (at any time)       
 
         [0092]    Type B indications that are PDCP related may include one or more of the following:
       Indication that PDCP SN source cell gaps have been filled (i.e. with target transmissions)       
 
         [0094]    In one embodiment, a “Type A indication” (described in earlier section) is used to activate the PDCP reordering function. 
         [0095]    In another embodiment, a “Type B indication” (described above) is used to deactivate the PDCP reordering function. 
         [0096]    Examples of Type B indications that may also be suitable as (serve as) Type A indications, and hence may be used to activate the PDCP reordering function are:
       Indication of successful or completed RLC reset   Indication of successful or completed RLC re-establishment   Indication of the WTRU sending of the Handover Confirm message (or equivalently the indications that cause the Handover Confirm message to be sent)   Indication that the WTRU successfully accessed the target cell       
 
         [0101]    The following is a first embodiment for reordering activation. As shown in  FIG. 6 , in this embodiment which may be implemented in a device such as the WTRU  900  shown in  FIG. 9 , the RRC  610  receives the HO Command  612  which subsequently invokes an RLC reset (or re-establishment)  614 , and the RLC  630  forwards PDCP PDUs in the RLC buffer up to the PDCP  620  (such PDCP PDUs may be out of sequence or in sequence) by flushing the RLC buffer at  618  and the PDCP Reordering function  640  is simultaneously signaled to activate by Signal  616  (e.g. a PDCP Reordering Activation Signal). The Signal  616  may also be received by the PDCP  620  before the RLC begins forwarding PDCP PDUs. 
         [0102]    The following is a second embodiment for reordering activation. As shown in  FIG. 7 , in this embodiment which may be implemented in a device such as the WTRU  900  shown in  FIG. 9 , the RRC  610  receives the HO Command  612  and sends a Signal  616  (such as a PDCP reordering activation signal) to PDCP. The PDCP  620  then receives the Signal  616  from the RRC  610 . This signal activates the PDCP Reordering function  640 , which will begin reordering PDCP PDUs as soon as they are received from the RLC  630 . The PDCP sends an RLC reset (or re-establishment) Signal  614  to the RLC  630  subsequently invoking an RLC Reset (or re-establishment)  650 . The RLC  630  forwards PDCP PDUs in the RLC buffer to the PDCP  620  (such PDCP PDUs may be out of sequence or in sequence) by flushing the RLC buffer at  618 . Because the PDCP Reordering function  640  was previously activated, it will immediately begin to reorder the received PDCP PDUs. 
         [0103]    The following is a third embodiment for reordering activation. As shown in  FIG. 8 , in this embodiment which may be implemented in a device such as the WTRU  900  shown in  FIG. 9 , the RRC  610  receives the HO Command  612  and sends a Signal  616  (such as a PDCP Reordering Activation Signal) to PDCP. The PDCP  620  then receives the Signal  616  from the RRC  610 . This signal activates the PDCP Reordering function  640 , which will begin reordering PDCP PDUs as soon as they are received from the RLC  630 . In this embodiment, the RRC  610  sends an RLC reset (or re-establishment) Signal  614  to the RLC  630  subsequently invoking an RLC Reset (or re-establishment)  650 . The RLC  630  forwards PDCP PDUs in the RLC buffer to the PDCP  620  (such PDCP PDUs may be out of sequence or in sequence) by flushing the RLC buffer at  618 . Because the PDCP Reordering function  640  was previously activated, it will immediately begin to reorder the received PDCP PDUs. 
         [0104]    The following describes embodiments for PDCP reordering function operations. Other aspects of the PDCP layer described herein may or may not be used with these embodiments. In 3GPP, “Reordering of the downlink RLC SDUs at least during inter-eNB mobility” and “In-sequence delivery of upper layer PDUs at HO” are functions in the PDCP sub-layer. A reordering function may be implemented with two functions or procedures in PDCP:
       PDCP SN maintenance: e.g. to detect missing PDCP SN&#39;s (i.e. SN gaps)   Timer operations: e.g. to wait for missing PDCP SN&#39;s up to a certain time       
 
         [0107]    In one embodiment, when PDCP Reordering is activated at or during handover, and deactivated during ‘normal’ operations, reordering timer operations will work as follows: 
         [0108]    During normal operations:
       the PDCP reordering function will not wait for missing PDCP SN&#39;s (i.e. it will not start a timer) during normal operations;   or the PDCP reordering function will timeout immediately (i.e. zero timer value).       
 
         [0111]    At or during handover,
       the PDCP reordering function will wait for missing PDCP SN&#39;s (i.e. start a non-zero timer);       
 
         [0113]    In another embodiment, the PDCP Reordering is activated at or during handover, and at other events. This embodiment is similar to the previous embodiment, except that there are other events where reordering is activated (i.e. a reordering timer is started) in addition to HO, such as failure scenarios, or on RLC reset or re-establishment. 
         [0114]    In regards to the PDCP SN maintenance function, in one embodiment, the PDCP Reordering function maintains the PDCP SN. In this embodiment, the PDCP reordering function maintains, updates and keeps track of the received PDCP SN (e.g. Rx_PDCP_SN which is the PDCP SN that that the receiver expects to receive next) at all times. 
         [0115]    In another embodiment, the PDCP Reordering function does not maintain the PDCP SN. In this embodiment, the PDCP reordering function does not maintain, update or keep track of the received PDCP SN (e.g. Rx_PDCP_SN which is the PDCP SN that that the receiver expects to receive next) at all times; instead, at handover, the expected starting PDCP SN is communicated to the PDCP reordering function, either:
       Autonomously or locally in the WTRU for example, as follows:
           starting from the first gap at HO   or starting from the PDCP SN that was stored in the Rx_PDCP_SN variable at the time of the HO event.   Or based on RLC receiver and/or HARQ receiver acknowledgment status information   
           Explicitly (network-assisted): e.g. the HO command indicates the PDCP SN of the first packet that was forwarded from the source eNB to the target eNB       
 
         [0121]    The following describes additional embodiments/variants for PDCP operation. In one embodiment, the HO Command (or any other signaling message) can indicate either the time (starting time) or PDCP SN at which PDCP reordering should be started. For example, the HO Command can indicate the PDCP SN of the first packet that was forwarded (or that will be forwarded) from the source eNB to the target eNB, and such PDCP SN can be used by the WTRU as the starting PDCP SN at which reordering (e.g. reordering timeout operations) can be started. 
         [0122]    In another embodiment, the WTRU identifies the packets (i.e. PDCP SN&#39;s) that are expected to be transmitted to the target eNB based on the packets that were negatively acknowledged (or not yet acknowledged) by the RLC receiver (or by the HARQ receiver). 
         [0123]    In another embodiment, the HO Command (or any other signaling message) may indicate either the time or PDCP SN at which PDCP reordering could be deactivated. For example, the HO Command may indicate the PDCP SN of the last packet that was forwarded (or that will be forwarded) from the source eNB to the target eNB, and such indicated PDCP SN can be used by the WTRU as the starting PDCP SN at which reordering (e.g. reordering timeout operations) can be deactivated. Alternatively, the HO Command can indicate the PDCP SN of the first packet that was sent (or that will be sent) directly from the target eNB (i.e. was not forwarded). 
         [0124]    In another embodiment, the PDCP sublayer deactivates (stops) the PDCP reordering functions when all the PDCP SN gaps caused by out-of-order delivery during HO are filled/transmitted (i.e. in the target eNB) (i.e. when the missing packets are received and submitted to upper layers), or when the PDCP reordering function has timed out (i.e. timer has expired). 
         [0125]    In another embodiment, reordering may be performed based on the combination of HFN and PDCP SN (i.e. the COUNT), rather than based on PDCP SN only, in order to prevent problems related to having multiple packets in the PDCP receiver buffer that have the same PDCP SN but different HFN, or for any other reason. 
         [0126]    Based on the above embodiments, additional embodiments may be constructed. 
         [0127]    In a first additional embodiment, upon receiving an indication from RRC or RLC (such as an indication of handover), a WTRU PDCP starts a timer 
         [0128]    Upon timer expiry, the WTRU PDCP deactivates reordering. 
         [0129]    In a second additional embodiment, the PDCP deactivates the PDCP reordering function when all the PDCP SN gaps caused by out-of-order delivery during HO are filled/transmitted (i.e. when the missing packets are received and submitted to upper layers, e.g. one or more higher layers) 
         [0130]    In a third additional embodiment, the PDCP deactivates reordering at the earlier of the two above events (i.e. either condition of embodiments 2 or 3, whichever occurs first). 
         [0131]    Additional embodiments determine the anchor or reference PDCP SN and/or HFN to be used in various WTRU operations/functions, such as starting/stopping the PDCP reordering function, updating the PDCP COUNT assignment method, or any other function. 
         [0132]    In general, the following approaches may be utilized:
       1) WTRU autonomous approaches   2) Network assisted approaches.       
 
         [0135]    In WTRU autonomous based embodiments, the WTRU utilizes local information, possibly with assistance from different layers such as RLC (packet reception) status information and/or HARQ information to determine the PDCP SN and/or HFN that it should use. 
         [0136]    In one embodiment, at the WTRU receiver, the RLC sublayer identifies to the PDCP sublayer, the packets (e.g. RLC SDUs) it has successfully acknowledged in its latest RLC status report (e.g. based on the acknowledgement status of the RLC PDUs constituting the SDUs). The latest RLC status report for which a positive HARQ acknowledgment was received could be used to increase the reliability of this scheme. Such information from the RLC will enable the PDCP sublayer, at the receiver, to determine the PDCP SNs that it should expect to receive, due to the forwarding of packets between the eNB&#39;s, which will help in deciding when certain PDCP functions (e.g.: reordering) will start or stop. 
         [0137]    In the network assisted embodiments, the access network (e.g. eNB) provides indications to assist a WTRU in determining what PDCP SN and/or HFN it should use. 
         [0138]    In one embodiment, a signal/message containing a PDCP status report is sent from the eNB to the WTRU indicating the successful “transmission” of PDCP packets to the WTRU (in contrast to a conventional 3GPP report which indicates the successful “reception” of PDCP packets). This PDCP status report will report on which PDCP packets (PDCP SNs) were transmitted successfully to the WTRU (e.g. based on RLC/ARQ and/or HARQ acknowledgement feedback). Alternatively, the report will indicate which PDCP packets (SNs) were NOT transmitted successfully to the WTRU (e.g. based on RLC/automatic repeat request (ARQ) and/or HARQ acknowledgement feedback, or the lack of acknowledgment). Equivalently, the eNB will identify PDCP SN gaps to the WTRU receiver in a message, which in turn can be used for starting or stopping PDCP reordering or in the COUNT assignment function. Such a message can be included in the HO Command for example. 
         [0139]    In another embodiment, a signal (e.g. an RRC message such as the HO Command, or any other message) is sent from the eNB to the WTRU indicating which PDCP SN and/or the HFN it should utilize for one or more of the following purposes:
       Starting the PDCP reordering function   Stopping the PDCP reordering function   In the COUNT assignment function
 
Consequently, the WTRU will re-anchor (i.e. set the values of the Rx_PDCP_SN and/or Rx_HFN PDCP state variables) to new locally-determined or explicitly-signaled values.
       
 
         [0143]    Although features and elements are described above in particular combinations, each feature or element can be used alone without the other features and elements or in various combinations with or without other features and elements. The methods or flow charts provided herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable storage medium for execution by a general purpose computer or a processor. Examples of computer-readable storage mediums include a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). 
         [0144]    Suitable processors include, by way of example, a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), and/or a state machine. 
         [0145]    A processor in association with software may be used to implement a radio frequency transceiver for use in a wireless transmit receive unit (WTRU), user equipment (UE), terminal, base station, radio network controller (RNC), or any host computer. The WTRU may be used in conjunction with modules, implemented in hardware and/or software, such as a camera, a video camera module, a videophone, a speakerphone, a vibration device, a speaker, a microphone, a television transceiver, a hands free headset, a keyboard, a Bluetooth® module, a frequency modulated (FM) radio unit, a liquid crystal display (LCD) display unit, an organic light-emitting diode (OLED) display unit, a digital music player, a media player, a video game player module, an Internet browser, and/or any wireless local area network (WLAN) or Ultra Wide Band (UWB) module.