Method, apparatuses and system for management and setup of enhanced mac-e/es resources

0001This application relates to wireless communication.

0002An extended uplink mechanism has been introduced for the 3GPP (Third Generation Partnership Project) standard. As part of the extended uplink mechanism and improved L2 (Layer 2), new functional entities, including extended MAC-e / es entities, have been introduced into MAC (Medium Access Control). In WTRU (Radio Transmit / Receive Unit), the extended MAC-e / es is considered as a single sublayer. However, on the network side, the extended MAC-e entity and the extended MAC-es entity can be considered separate, the extended MAC-e exists on node B, and the extended MAC-es is SRNC (serving wireless network). It exists in the control device). There is one extended MAC-e for each WTRU in node B and one extended MAC-es for each WTRU in SRNC. These entities are separate in the network so that the more real-time and critical functionality of the extended MAC-e can be placed on node B.

0003Figure 1 is a block diagram of WTRU's Extended MAC Entity 100. The extended MACs in WTRU are the HARQ (hybrid automatic repeat request) module, the multiplexing-TSN (transmission sequence number) setting module, the E-TFC (extended uplink transport format combination) selection module, and two segmentation modules. And.

0004The HARQ module performs MAC functions related to the HARQ protocol, including storing extended MAC-e payloads and retransmitting these payloads. The HARQ module determines the E-TFC, RSN (retransmission sequence number), and power offset to be used by L1 (Layer 1).

0005Multiplexing-The TSN module concatenates multiple MAC-d PDUs (protocol data units) into extended MAC-es PDUs and multiplexes one or more extended MAC-es PDUs according to instructions from the E-TFC selection module. To be a single extended MAC-e that should be transmitted in subsequent TTIs (Transmission Time Intervals).

0006The E-TFC selection module provides scheduling information, relative and absolute permits received from UTRAN (UMTS Radio Access Network) via L1 signaling, and arbitration between various flows mapped on the E-DCH. To perform E-TFC selection according to the serving permissions signaled via RRC.

0007The segmentation module performs segmentation of MAC-d PDUs.

00082 and 2A show the extended MAC-e entity located on node B and the extended MAC-es entity located on RNC, respectively. With reference to Figure 2, the extended MAC-es sublayer manages E-DCH-specific functions. This extended MAC-es entity includes a disassembly module, a sort-queue distribution module, a sort / combination module, and a rebuild module.

0009The sort queue distribution module routes extended MAC-es PDUs to the correct sort buffer based on the SRNC (Serving Radio Network Controller) configuration and also on the logical channel ID.

0010The sort / combination module sorts received extended MAC-es PDUs according to the received TSN and node B tagging (ie CFN, subframe number). Extended MAC-es PDUs with consecutive TSNs are sent to the disassembly module when received.

0011The macro diversity selection module operates in the extended MAC-es in the case of soft handover for a plurality of nodes B.

0012The disassembly module is responsible for disassembling the extended MAC-es PDU, including removing the extended MAC-es header.

0013The rebuild function reassembles the segmented MAC-d PDUs and sends these MAC-d PDUs to the correct MAC-d entity.

0014Refer to Figure 2A, which shows the MAC-e entity in communication with the E-DCH scheduling module. This extended MAC-e entity includes an E-DCH control module, a demultiplexing module, and a HARQ entity.

0015The E-DCH scheduling module manages E-DCH cell resources between WTRUs. Scheduling permissions are determined and transmitted based on the scheduling request.

0016The E-DCH control module is responsible for receiving scheduling requests and sending scheduling permissions.

0017The demultiplexing module demultiplexes the extended MAC-e PDU into an extended MAC-es PDU. Extended MAC-es PDUs are forwarded to SRNC in the associated MAC-d flow.

0018The HARQ module can support multiple HARQ processes. Each process is responsible for generating an ACK or NACK that indicates the delivery status of the E-DCH transmission.

0019Figure 3 shows the RRC (Radio Resource Controller) service state of a 3GPP WTRU with extended uplinks. WTRU can operate in several states that depend on user activity. The following states, namely Idle, Cell_DCH, Cell_FACH, URA_PCH, and Cell_PCH, are defined. RRC state changes are controlled by the network using RNC parameters, and WTRU does not decide to perform state changes on its own.

0020In the Cell_DCH state, a dedicated physical channel is assigned to the WTRU on the uplink and downlink. WTRU is known at the cell level according to the current set of activity of WTRU. The WTRU can use dedicated transport channels, shared transport channels, or a combination of these transport channels.

0021The WTRU is in the Cell_FACH state if it is assigned to use a common control channel (eg CPCH). In the Cell_FACH state, no dedicated physical channel is assigned to the WTRU, and the WTRU constantly monitors FACH (eg, S-CCPCH) or HS-DSCH (fast downlink shared channel) in the downlink. The WTRU is assigned a default common or shared transport channel on the uplink that the WTRU can use at any time according to the access procedure for that transport channel. The location of the WTRU is known by UTRAN at the cell level, depending on the cell where the WTRU last performed a cell update.

0022No dedicated physical channel is assigned to the WTRU in the Cell_PCH state. WTRU selects PCH and uses discontinuous reception to monitor the selected PCH via the associated PICH. Uplink activities are not possible at all. The location of the WTRU is known by UTRAN at the cell level by the cell that last performed the cell update while the WTRU was in the CELL_FACH state.

0023No dedicated channel is assigned to WTRU in the URA_PCH state. WTRU selects PCH and uses discontinuous reception to monitor the selected PCH via the associated PICH. Uplink activities are not possible at all. The location of the WTRU is known at the UTRAN registration area level by the URA assigned to the WTRU during the last URA update in the Cell_FACH state.

0024E-RACH (Extended Random Access Channel) has been introduced for the CELL_FACH state as part of the extended uplink mechanism. E-RACH refers to the use of E-DCH (extension-only channel) in the Cell_FACH state, or the resource / physical channel used by the WTRU for uplink connection-based access. So far, the only uplink mechanism for WTRU in the Cell_FACH state has been transmission via RACH using the slotted Aloha approach with an acquisition instruction message.

<p num="0025"> With the introduction of E-DCH in the Cell_FACH state, WTRUs and networks may require the introduction of extended MAC-e / es entities to allow communication between WTRUs and networks. Due to the nature of E-DCH operation in the Cell_FACH state, some problems may arise with respect to E-DCH MAC resources. One of the issues concerns defining how and when to set up an extended MAC-e / es entity. In addition, rules regarding the location of extended MAC-e / es entities, as well as rules regarding whether extended MAC-e and / or extended MAC-es are common or dedicated entities are desired. Further RNC-Node B Interface (Iub) signaling for the setup and management of MAC entities is also desired. Therefore, a method of managing E-DCH resources and a method of managing TSN numbering are desired.</p>

<p num="0026"> Disclosed are methods and devices for managing extended MAC-e and extended MAC-es resources in the extended Cell_FACH state, as well as their respective variables for E-DCH. Due to the nature of E-DCH transmission in UL (uplink) in the Cell_FACH state, and the fact that WTRU may set up and release E-DCH resources more frequently, there is a way to manage TSN numbering. Be explained.</p>

0027A more detailed understanding can be obtained from the following description given as an example along with the attached drawings.

0028<figref num="1">It is a block diagram which shows the extended MAC-e / es entity of WTRU.</figref><figref num="2">It is a block diagram which shows the extended MAC-e entity of node B, and the extended MAC-es entity of RNC.</figref><figref num="2A">It is a block diagram which shows the extended MAC-e entity of node B, and the extended MAC-es entity of RNC.</figref><figref num="3">It is a block diagram which shows the RRC state in the HSPA + system.</figref><figref num="4">It is a figure which shows the exemplary wireless communication system which includes a plurality of WTRU (radio transmission / reception unit), a base station, and RNC (radio network control device).</figref><figref num="5">It is a functional block diagram which shows WTRU and the base station of FIG.</figref><figref num="6">Extended MAC-e and extended MAC-es entities are preconfigured as common entities for each E-DCH (extended dedicated channel) resource set that can be assigned to a WTRU when the E-RACH access procedure is performed. It is a flow chart which shows the method.</figref>

0029Hereinafter, when referred to, the term "WTRU (wireless transmission / reception unit)" refers to UE (user equipment), mobile station, fixed or mobile subscriber unit, pager, cellular telephone, PDA (personal digital). Includes, but is not limited to, assistants), computers, or any other type of user device that can operate in a wireless environment. As used herein, the term "base station" includes node B, site controllers, APs (access points), or any other type of interface device that can operate in a wireless environment. Not limited to the above.

0030FIG. 4 shows a wireless communication system 400 including a plurality of WTRU410s, a node B420, a CRNC430, an SRNC440, and a core network 450. As shown in FIG. 4, the WTRU410 is in communication with node B420, which is in communication with CRNC430 and SRNC440. Although Figure 4 shows three WTRU410s, one node B420, one CRNC430, and one SRNC440, any combination of wireless and wired devices can be included in the wireless communication system 400. Please note that.

0031Hereinafter, when referred to, CRNC430 and SRNC440 can be collectively referred to as UTRAN.

0032FIG. 5 is a functional block diagram 500 of WTRU410 and node B420 of the wireless communication system 400 of FIG. As shown in Figure 5, WTRU410 is in communication with node B420, and both WTRU410 and node B420 should perform the method of managing and setting up extended MAC-e / es resources in Cell_FACH state. It is composed.

0033In addition to the components that can be found in a regular WTRU, the WTRU 410 includes a processor 415, a receiver 416, a transmitter 417, and an antenna 418. Processor 415 is configured to manage and set up extended MAC-e / es resources in the Cell_FACH state. Receiver 416 and transmitter 417 are in communication with processor 415. The antenna 418 is in communication with both the receiver 416 and the transmitter 417, facilitating the transmission and reception of radio data.

0034In addition to the components that can be found in a regular base station, node B420 includes processor 425, receiver 426, transmitter 427, and antenna 428. Processor 425 is configured to manage and set up extended MAC-e / es resources in the Cell_FACH state. Receiver 426 and transmitter 427 are in communication with processor 425. Antenna 428 is in communication with both receiver 426 and transmitter 427, facilitating the transmission and reception of radio data.

0035The WTRU410 can be configured to send over the E-RACH to register the WTRU410 with the network for initial RRC connection requests, cell selection, and cell reselection. These connection requests are transmitted via CCCH (Common Control Channel). Once the WTRU is registered, the WTRU can send DTCH (Dedicated Traffic Channel) traffic or DCCH (Dedicated Control Channel) traffic to the network. However, DTCH is a bidirectional channel that carries user data, and DCCH traffic has dedicated control information between WTRU and UTRAN. DCCH is established through the RRC (Radio Resource Control) connection setup procedure. However, if the WTRU410 is sending an initial E-RACH access attempt, the extended MAC-e and extended MAC-es entities can be set up or not. Therefore, some alternatives to configuring extended MAC-e and extended MAC-es entities are described in more detail herein.

0036Referencing Figure 4 again, the WTRU410 is an extended MAC-if both the WTRU410 and the network support E-RACH (ie, E-DCH can be used in the CELL_FACH state) and also HS-DSCH. It can be configured with an e / es entity 419. However, HS-DSCH is a downlink transport channel shared by several WTRUs. HS-DSCH is associated with one downlink DPCH (dedicated physical channel) and one or more HS-SCCH (fast shared control channel). The extended MAC-e / es entity 419 in the WTRU410 includes the HARQ module, the multiplexing-TSN module, the E-TFC selection module, the segmentation module, the module used to add the E-RNTI, and the CCCH. (Common Control Channel) Can include modules used for CRC calculations on traffic. CCCH supports the general procedures required to establish a dedicated link with UTRAN. CCCH can include RACH and E-RACH, FACH (Forward Access Channel), and PCH (Paging Channel). The extended MAC-e / es entity 419 can also include an access class control module. The WTRU410 can transition to the Cell_FACH state if there is uplink data to send, or if the WTRU410 is already in the Cell_DCH state and the network moves the WTRU410 to the Cell_FACH state due to inactivity or the like. .. The WTRU410 can be configured to maintain an extended MAC-e / es entity as long as the WTRU410 can transmit uplink data over the E-DCH. The WTRU410 operates in idle mode when an RRC connection request is initiated by the WTRU410.

0037Node B420 has x extended MAC-e entities (extended MAC-e)₁Extended MAC-e from_xCan be configured with (up to), where x is the number of common E-DCH resources for all types of traffic. Each extended MAC-e entity can include an E-DCH scheduling module, an E-DCH control module, a demultiplexing module, and a HARQ module. The extended MAC-e entity can also be configured to read the E-RNTI used for conflict resolution. An extended MAC-e entity can be configured to communicate with a WTRU that has neither U-RNTI nor E-RNTI assigned, and if neither U-RNTI nor E-RNTI is assigned, the WTRU is , Communicate via CCCH. Each extended MAC-e entity can be associated with a common E-DCH resource that the WTRU acquires as part of a random access procedure. For example, node B420 should use the extended MAC-e entity while the WTRU is attempting E-RACH access and / or after the WTRU performs cell selection / reselection (ie DTCH / DCCH traffic). Can be configured in. The extended MAC-e entity can be preconfigured on node B420 (ie, set up when an E-DCH resource pool for CELL_FACH state and idle mode is provided to node B), or WTRU or It can be set up in response to the signal received from the RNC. Alternatively, node B420 can be configured to set up and maintain one dedicated extended MAC-e entity for each WTRU as long as that WTRU is in a given state.

0038The CRNC430 has y extended MAC-es entities (extended MAC-es) used exclusively for CCCH traffic.₁Extended MAC-es from_yCan be configured with (up to), where y is the number of common E-DCH resources in the cell. Each extended MAC-es entity is associated with a common E-DCH resource set that can be used by WTRU. Each extended MAC-es entity can include a decomposition module, a sort-queue distribution module, a sort module, a macrodiversity selection module, a rebuild module, and a CRC error correction module. Each extended MAC-es entity can be used during communication with a WTRU that has neither U-RNTI nor E-RNTI assigned (ie, for CCCH traffic). This CCCH traffic can be terminated at CRNC430 so that CCCH data traffic is not forwarded to SRNC440. Alternatively, CRNC430 can be configured to set up one dedicated extended MAC-es entity for each WTRU, as long as that WTRU is in a given state.

0039SRNC440 has z extended MAC-es entities (extended MAC-es) for DTCH / DCCH traffic.₁Extended MAC-es from_zCan be configured with (up to), where z is the number of WTRUs in the Cell_FACH state. Each of the z extended MAC-es entities can be associated with the WTRU410 after the WTRU-id of that extended MAC-es entity has been identified. Each extended MAC-es entity can include a decompose module, a sort-queue distribution module, a sort module, a macrodiversity selection module, and a rebuild module. The SRNC440 can be configured to set up an extended MAC-es entity in response to the WTRU entering the Cell_FACH state. DTCH / DCCH traffic terminates at SRNC440.

0040Alternatively, nodes B420 and CRNC430 have one dedicated extended MAC-e entity and one extended MAC-es entity for each WTRU, regardless of the E-DCH resource, as long as the WTRU is in the Cell_FACH state. It can also be configured to maintain.

0041Alternatively, node B420 and CRNC430 will have node B420 set up the extended MAC-e and extended MAC-es entities after the node B420 assigns and sends the E-RNTI (E-DCH wireless network temporary identifier) of the WTRU410. It can also be configured.

0042In some scenarios, the SRNC440 may not know the ID of the WTRU410 until the first transmission of the WTRU410 after receipt of the AICH (acquisition indicator channel) or E-AICH. In such cases, the SRNC440 can be configured to set up an extended MAC-es for the WTRU410 when the WTRU-ID is read from the header. Therefore, a new Iub signaling procedure shown in SRNC440 to set up an extended MAC-es entity for a given WTRU may be required.

0043When common extended MAC-e and / or extended MAC-es resources are set up for a given connection, these resources are set up as part of the common transport channel setup procedure between RNC and node B420. It is possible.

0044Figure 6 shows each E-DCH (which can be assigned to a WTRU when CRNC430 preconfigures and stores a common extended MAC-es entity and node B420 undergoes an E-RACH access procedure. (Extended dedicated channel) It is a flow chart of the method of preconfiguring and storing the common extended MAC-e entity related to the resource set. With reference to Figure 6, CRNC determines the E-DCH resource set and signals it to node B (610). CRNC and Node B preconfigure and store the common extended MAC-es entity and the common extended MAC-e entity for each available E-DCH resource set (620). WTRU performs a random access procedure to acquire the E-DCH resource set (630). An RRC connection request message is received from a WTRU in idle mode using an E-DCH set obtained using a random access procedure (640). Node B assigns E-RNTI and the extended MAC-es entity is set up in SRNC for WTRU (650).

0045Since the CRNC extended MAC-es entity and the node B extended MAC-e entity are preconfigured for the E-DCH resource set, the extended MAC-e and extended MAC-es for CCCH are associated with one WTRU at the same time. Can be configured to act as a common entity (ie for the WTRU that received the E-RACH access). In one option, the common extended MAC-e and common extended MAC-es entities can be used only for the initial traffic of the WTRU. Alternatively, an extended MAC entity can be used throughout the time the WTRU is communicating through the corresponding set of E-DCH resources for that extended MAC entity. It is then possible to receive an RRC connection setup complete message indicating that the WTRU is in connection mode.

0046Extended MAC-es entities in CRNC can be associated with the common E-DCH resource set used by WTRU410, or the common E-RNTI selected by WTRU410. The SRNC440 can be configured to set up a dedicated extended MAC-es entity for each WTRU operating in the Cell_FACH state that is registered and assigned an E-RNTI, and this entity is at least WTRU. Can be maintained for the duration of the Cell_FACH / CELL_PCH state for DTCH / DCCH traffic. For DTCH / DCCH traffic, data is first received in the common extended MAC-e entity associated with the common E-DCH resource used by the UE, and then through the Iub / Iur interface dedicated extended MAC in SRNC. -es Transferred to the entity. Therefore, if the extended MAC-e is a common entity for any WTRU using a set of resources, a process of identifying the WTRU-ID via the Iub / Iur frame protocol may be desired. .. Some alternatives will be described in more detail below.

0047In the first alternative, node B420 can be configured to use the Iub flow to send data over a common transport channel (for WTRUs using E-DCH in the Cell_FACH state). .. Since Iub is a common flow, CRNC430 can receive data from this common flow for each WTRU and does not know which WTRU this data belongs to. Therefore, node B420 should send the WTRU-ID in the header field of the Iub frame if the extended MAC-es is associated with a particular WTRU in the Cell_FACH state (ie, for DTCH / DCCH traffic). It can be configured. Similarly, the CRNC430 can be configured to send a WTRU-ID in the header of the Iur frame. The WTRU-id can be equipped with an E-RNTI when transmitted via the Iub interface, or can be equipped with an S-RNTI when transmitted via the Iur interface. This allows the SRNC440 to know the proper forwarding address of the data to the correct dedicated extended MAC-es entity for the WTRU.

0048In another alternative, the WTRU-id can comprise one or a combination of E-RNTI, U-RNTI, or C-RNTI, or S-RNTI. For CCCH traffic, WTRU-id does not exist and therefore the Iub frame protocol must not include E-RNTI. The CRNC430 can be configured to detect that the traffic belongs to CCCH traffic from the logical channel identifier and forward the data to the correct extended MAC-es entity in the CRNC430 associated with the appropriate E-DCH resource. Is. In an optional embodiment, there can be one common transport channel for DTCH / DCCH traffic and one transport channel set up for each E-DCH resource set for CCCH traffic. Node B420 can be configured to receive CCCH traffic and then forward the data to the transport channel associated with the extended MAC-e entity that received the data.

0049In another alternative, if node B420 and CRNC430 are both configured to set up a common extended MAC-e entity and a common extended MAC-es entity, the WTRU410 will have an extended MAC-es header for the extended MAC-es PDU. It can be configured to send a WTRU-id in. Node B420 can be further configured with a decomposition module capable of decoding the extended MAC-es PDU header and identifying the WTRU-id. Extended MAC-es By transmitting this information in the PDU, node B420 does not have to transmit an Iub frame with WTRU-id information. For example, the WTRU410 can be configured to transmit the WTRU-id in the extended MAC-es header only during the initial transmission for conflict resolution purposes. In this case, node B420 can be configured with an extended MAC-e entity that uses the initial transmission to determine the transfer procedure for successive data on subsequent transmissions to the RNC. The WTRU410 can transmit the WTRU-id until the WTRU410 receives the absolute permission of the E-DCH channel, at which point the WTRU410 stops transmitting the WTRU-id. Can be done.

0050In another alternative, node B420 can be configured to receive the WTRU-id from the WTRU and further extract this WTRU-id from the first transmission. Node B420 can then store this WTRU-id and use this information to send the WTRU-id to SRNC440 or CRNC430 using Iub signaling during subsequent transmissions. When the WTRU410 releases a set of E-DCH resources, node B420 can be configured to clear this WTRU-id. Alternatively, if a subsequent E-RACH access attempt is performed and a different WTRU-id is decrypted, node B420 modifies the stored WTRU-id information to reflect this new WTRU-id. be able to.

0051In yet another alternative, after node B420 receives the first transmission from the WTRU, node B420 can use this first transmission to identify which WTRU the data belongs to. .. Once the WTRU-id is identified, node B420 can set up a semi-dedicated flow to the RNC for the duration of the WTRU connection to the E-DCH resource. This creates a temporary connection flow between the common extended MAC-e and the dedicated extended MAC-es. This can be set up by sending an Iub signal informing the RNC to start setting up the flow between the common extended MAC-e entity and the common extended MAC-es entity corresponding to WTRU. is there. In this case, the WTRU-id is in the extended MAC-e header of all transmissions and this information is forwarded to the RNC via the Iub frame protocol, so the WTRU-id is in the Iub frame protocol. It does not have to be specified by.

0052Alternatively, E-DCH resources can be negotiated between node B420 and WTRU without RNC involvement, so features related to E-DCH, such as extended MAC-es, will be on node B420. It can be transferred. For this embodiment, a logical channel flow can be set up between the extended MAC-es entity and the RLC (Radio Link Control) entity. Alternatively, WTRU410 and node B420 can establish a common transport channel and WTRU-id, and the LCH (Linearization Channel) -ID is transmitted via the Iub frame protocol and / or the Iur frame protocol. It is possible.

0053The features and elements are described in the preceding paragraph in a particular combination, but each feature or element is alone with or without other features and elements, or with or without other features and elements. It can be used in various combinations. The method or flow diagram given herein can be implemented in a computer program, software, or firmware embedded in a computer-readable storage medium to be performed by a general purpose computer or processor. Examples of computer-readable storage media include ROM (read-only memory), RAM (random access memory), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, optomagnetic media, and CD-ROMs. Includes optical media such as discs and DVDs (digital versatile discs).

0054Suitable processors include, for example, general purpose processors, dedicated processors, traditional processors, DSPs (digital signal processors), multiple microprocessors, one or more microprocessors associated with DSP cores, controllers, microcontrollers, ASICs. Includes application specific integrated circuits, FPGA (field programmable gate array) circuits, any other type of IC (integrated circuits), and / or state machines.

0055A processor associated with the software can use a WTRU (wireless transmit / receive unit), UE (user equipment), terminal device, base station, RNC (wireless network controller), or radio frequency transceiver for use in any host computer. It can be used to carry out. WTRU includes cameras, video camera modules, video phones, speakerphones, vibrating devices, speakers, microphones, TV transceivers, hands-free headsets, keyboards, Bluetooth® modules, FM (frequency modulation) wireless units, LCDs (LCDs). Display) Display unit, OLED (organic light emitting diode) display unit, digital music player, media player, video game player module, internet browser, and / or any WLAN (wireless local area network) module or UWB (Ultra Wide Band) module It can be used in conjunction with modules implemented in hardware and / or software, such as.

0056(Embodiment) 1. How to provide a WTRU (Radio Transmit / Receive Unit) to set up MAC (Media Access Control) -es and MAC-e entities when performing RACH (Random Access Channel) access attempts. 2. The way the MAC-es and MAC-e entities are set up when the WTRU enters the CELL_FACH state, as in any of the preceding embodiments. 3. The method as in any of the preceding embodiments where the WTRU and network support E-DCH (extension-only channel) in the CELL_FACH state. 4. The method as in any of the preceding embodiments further comprising assigning the WTRU an E-RNTI (Temporary Radio Network Identifier). 5. Further provided to maintain a dedicated MAC-es or dedicated MAC-e entity per WTRU throughout the connection of the WTRU in a given state, this connection precedes, independent of the E-DCH resource. The method as in any embodiment. 6. Set up the MAC-es and MAC-e entities if the RACH preamble is received, if resources are allocated, or after the WTRU succeeds in completing the first transmission without conflict. The method as in any of the preceding embodiments further comprising. 7. The method as in any preceding embodiment where the WTRU ID is unknown until the first transmission of the WTRU after receipt of the AICH (Acquisition Marking Channel). 8. Once the WTRU-id is read from the MAC header, the method as in any of the preceding embodiments further comprises setting up a MAC-es for the WTRU. 9. The method as in any of the preceding embodiments further comprising instructing the RNC (Wireless Network Controller) to set up a MAC-es entity for a given WTRU via Iub signaling. 10. The method as in any of the preceding embodiments where the common MAC-es entity is always set up in the RNC for each E-DCH resource set. 11. The method as in any of the preceding embodiments where the common MAC-e entity is always set up on node B for each E-DCH resource set. 12. The MAC-e / es entity is the same method in any of the preceding embodiments that is used only for WTRU initial traffic. 13. The MAC-e / es entity is the way in any of the preceding embodiments where the WTRU is used all the time it is using the E-DCH resource set corresponding to that MAC-e / es entity. .. 14. The method as in any of the preceding embodiments further comprising setting up a common MAC-e entity and a common MAC-es entity for a WTRU that has neither U-RNTI nor ERNTI. 15. These entities are used for the WTRU, which is one of the preceding embodiments that attempts to access the RACH while the WTRU is in idle mode or after the WTRU has performed a cell reselection procedure. The street way in. 16. The method as in any of the preceding embodiments where a common MAC-e entity is set up on node B for each E-DCH resource set. 17. MAC-e is set up as a common transport channel resource and traffic is sent to the RNC via a common Iub frame flow as in any of the preceding embodiments. 18. The method as in any of the preceding embodiments, in which one MAC-es is created for each WTRU and the WTRU further comprises maintaining this MAC-es for a certain duration in CELL_FACH. 19. The method as in any of the preceding embodiments further comprising setting up a common MAC-e resource and / or a common MAC-es resource as part of the common transport channel setup procedure between RNC and Node B. 20. The method as in any of the preceding embodiments where the Iub and Iur frame protocols comprise a WTRU-id in a field. 21. WTRU-id is the method as in any of the preceding embodiments comprising E-RNTI, U-RNTI, C-RNTI, or S-RNTI. 22. If a common MAC-e and a common MAC-es are created, the method as in any of the preceding embodiments further comprising including the WTRU-id in the MAC-es header. 23. The method as in any of the preceding embodiments further comprising using the first transmission from MAC-e as an instruction on how to transfer contiguous data to the RNC. 24. Node B further comprises storing the WTRU-id from the first transmission and further using the first transmission to indicate the WTRU-id via the common Iub frame protocol for subsequent transmissions. The method as in any of the preceding embodiments. 25. The method as in any of the preceding embodiments where node B further comprises clearing the WTRU-id when the WTRU releases the set of E-DCH resources. 26. The method as in any of the preceding embodiments further comprising modifying the stored information on node B as RACH access is performed and a different WTRU-id is decrypted. 27. One of the preceding implementations in which Node B indicates the WTRU using the first transmission and is further equipped to set up a semi-dedicated flow for the RNC over the duration of the WTRU connection to the E-DCH resource. The street method in form. 28. The method as in any of the preceding embodiments further comprising creating a temporary connection flow between the common MAC-e and the dedicated MAC-es. 29. Any of the preceding ones further prepared to set up a temporary connection flow via Iub signaling instructing the RNC to start the flow between the common MAC-e and common MAC-es entities corresponding to WTRU. The method as in the embodiment. 30. The method as in any of the preceding embodiments further comprising moving the MAC-es function to node B. 31. The method as in any of the preceding embodiments further comprising terminating MAC-es to node B. 32. The method as in any of the preceding embodiments further comprising setting up a logical channel flow between the MAC-es entity and the RLC entity. 33. The method as in any of the preceding embodiments where a common transport channel is established and the WTRU-id and LCH-ID can be indicated via the Iub frame protocol and / or the Iur frame protocol. 34. If the WTRU is in CELL_FACH, the method as in any of the preceding embodiments comprising creating a dedicated MAC-es entity in both the WTRU and RNC. 35. The method as in any of the preceding embodiments comprising resetting the TSN (Transmission Sequence Number) to the initial value TSN when the EDCH resource used by the WTRU is released. 36. The method as in any of the preceding embodiments comprising releasing the EDCH resource based on the expiration of the timer. 37. The timer expires simultaneously with respect to the WTRU and the network as in any preceding embodiment. 38. The method as in any of the preceding embodiments, wherein the WTRU resets the TSN when the timer expires and the resource is freed by the WTRU. 39. The method as in any of the preceding embodiments comprising resetting the TSN and further performing a full MAC-e / es reset procedure. 40. Node B orders the release of resources, and WTRU and Node B reset the TSN to the initial value. The method as in any of the preceding embodiments, wherein . 41. Preceding with freeing resources based on the expiration of the traffic inactivity timer and signaling through Iub that node B notifies the MAC-es entity in the RNC to reset the TSN. The method as in any embodiment. 42. The method as in any of the preceding embodiments comprising initiating an inactivity timer on both the WTRU and node B when the MAC-e PDU is transmitted by the WTRU. 43. The method as in any of the preceding embodiments, comprising maintaining the TSN number, storing the last value in memory, and incrementing the TSN for new transmissions. 44. The method as in any of the preceding embodiments, comprising setting the TSN number to the initial value and also resetting the MAC-e / es completely when cell reselection is performed. 45. Setting the TSN and resetting the MAC-e / es is the same way as in any of the preceding embodiments where the WTRU performs cell reselection. 46. Setting the TSN and resetting the MAC-e / es is the same method as in any of the preceding embodiments where the SRNS (Serving Radio Network Subsystem) relocation takes place. 47. The method as in any of the preceding embodiments, wherein the RNC signals a MAC-e / es reset via an explicit MAC-e / es reset indicator. 48. The method as in any of the preceding embodiments, wherein the WTRU implicitly detects that an SRNS relocation has taken place based on the new U-RNTI. 49. The method as in any of the preceding embodiments further comprising setting up MAC-e and MAC-es entities for each E-DCH resource set. 50. The method as in any of the preceding embodiments further comprising resetting the TSN or resetting the MAC-e / es entity each time a resource is released. 51. MAC-es for dedicated traffic is terminated to SRNC, and this MAC-es is the same method as in any of the preceding embodiments associated with WTRU. 52. The method as in any of the preceding embodiments further comprising terminating the MAC-es used for CCCH (Common Control Channel) data or common traffic to the CRNC. 53. The MAC-es entity is the method as in any of the preceding embodiments associated with the common E-DCH resource set used by WTRU. 54. A radio transmit / receive unit configured to perform the method as in any one of embodiments 1-53. 55. Node B configured to perform the method as in any one of embodiments 1-53. 56. A CRNC (Controlling Radio Network Control Unit) configured to perform the method as in any one of embodiments 1-53. 57. SRNC (Serving Radio Network Controller) configured to perform the method as in any one of embodiments 1-53. 58. An integrated circuit configured to perform the method as in any one of embodiments 1-53.