JP5944438B2 - Flexible radio link control packet data unit length - Google Patents

Description

  Embodiments in accordance with the present invention generally relate to wireless communication systems, and more particularly to data flow control in mobile communication systems.

  Wideband Code Division Multiple Access Radio Access Network (WRAN) introduced High Speed Downlink Packet Access (HSDPA) in 3GPP Release 5 and increased in speed in 3GPP Release 6. High Speed Uplink Packet Access (HSUPA) / Enhanced Uplink (EUL) was introduced. High speed packet access (HSPA) is a term common to both HSDPA and EUL. The 3GPP specification from Release 4 to Release 6 uses several fixed Medium Access Control-d (MAC-d) packet data unit (PDU) lengths for HSPA. The radio link control (RLC) transmission window limit is 2047 PDUs, and the round trip time (from the serving radio network controller to the user equipment and its return path) is longer, so the cellular system The peak bit rate at is limited.

  With the introduction of multiple inputs and multiple outputs (MIMO) and / or 64-value quadrature amplitude modulation (QAM), the peak bit rate is 42 megabits per second (Mbps). For higher HSDPA peak bit rates (assuming an RLC window size of 2047 is maintained), longer MAC-d PDU lengths are required. As long as only an integer number of MAC-d PDUs are scheduled over a radio interface in one transmission time interval (TTI), ie data in which one MAC-d PDU can be transmitted in one TTI. As long as it is the smallest unit of coverage, the use of excessively long MAC-d PDUs will limit coverage.

  The RLC Acknowledged Mode (AM) provides a structure for using a flexible PDU length. For example, in RLC AM (3GPP TS 25.322, RLC protocol specification), a flexible PDU length structure is defined. Although some RLC PDU lengths may be configured, the header field may limit the actual number that can be used. For example, up to 8 different MAC-d PDU lengths are currently available through HS-DSCH, in which case the MAC-d PDU includes an RLC PDU and an optional MAC-d header. Thus, a completely new PDU length structure is required for optimal performance.

  The current solution for high speed downlink shared channel (HS-DSCH) capacity allocation and HS-DSCH data frame definition is flexible RLC (or flexible PDU length structure). ) Is not effective for the solution. The bit rate of the HS-DSCH data frame cannot be well controlled using the current HS-DSCH capacity allocation control frame format. The current control frame format is that a given number of PDUs (HS-DSCH credits (Credit)) of a given maximum length (maximum MAC-d PDU length) are transmitted in a given interval (HS-DSCH interval). Identify what is possible. Assuming a fixed MAC-d PDU length, it is easy to translate this format into octets within a certain interval, or to bit rate. However, with the introduction of flexible RLC, each Mac-d PDU and all Mac-d PDUs may have different lengths. Thus, a 1-octet PDU consumes all credits like a 1500-octet PDU, which makes it difficult to control the number of octets per allowed interval or the allowed bit rate.

  The initial capacity for HS-DSCH data transfer is granted by the base station during radio link activation procedure, radio link reconfiguration procedure, or radio link addition procedure via HS-DSCH initial capacity allocation. During these procedures, the HS-DSCH initial capacity allocation is sent by the base station to the serving radio network controller, and the maximum MAC-d PDU length (maximum MAC-d PDU size) and the number of MAC-d PDUs ( HS-DSCH initial window size). This current interpretation of HS-DSCH initial capacity allocation is used for a fixed MAC-d PUU length and is clearly not suitable for flexible RLC.

  The current HS-DSCH data frame format does not support different MAC-d PDU lengths. Transmission of different length MAC-d PDUs can be very inefficient since new data frames are required for each different length PDU (eg, transport network overhead can be very high) Have sex). Furthermore, in the current format, a 4-bit pre-extension is inserted before each MAC-d PDU in the data frame, which increases the overhead significantly in the case of a octet-aligned PDU, which is a common case. . The current format cannot cope with a flexible RLC approach (for example, when a MAC-d PDU containing an 1500 octet long Internet Protocol (IP) packet is transmitted). At the same time, the current MAC-d PDU length indicator assumes bit granularity and is not necessary when the MAC-d PDU becomes an octet array with the removal of MAC-d multiplexing. Furthermore, the elimination of MAC-d multiplexing significantly increases the number of transport network connections required by some radio bearers when HS-DSCH data frames do not support some type of logical channel mapping. There is also a possibility (for example, four connections instead of one may be required for signaling radio bearer (SRB)).

  The object of the present invention is to overcome at least some of the above disadvantages and to provide improved data flow control for a communication system.

  Embodiments described herein introduce a new HS-DSCH framing protocol format (hereinafter referred to as “HS-DSCH framing protocol type 2 format”) that may allow transmission of PDUs of different lengths. provide. In one embodiment, the framing protocol type 2 format is a new HS-DSCH framing protocol type type that identifies MAC-d PDU credits by number of octets (as opposed to a given maximum length PDU number combination). 2 provides a capacity allocation control frame format. The HS-DSCH framing protocol type type 2 capacity allocation control frame also supports larger MAC-d PDU lengths by allowing reuse of unused credits.

  In addition to the new capacity allocation control frame format, the HS-DSCH framing protocol type 2 frame format provides a new HS-DSCH framing protocol type 2 data frame format. HS-DSCH framing protocol type type 2 data frames may allow more than one PDU length within the same data frame. Further, the HS-DSCH framing protocol type 2 data frame format may allow transmission of several PDUs associated with different logical channels in the same data frame in one embodiment.

The new HS-DSCH framing protocol type type 2 frame format may provide:
• Maximum MAC-d PDU length up to 1500 octets, and octet granularity in MAC-d PDU length is effectively supported • Maximum transmission unit of transport network used • Ability to support flexible MAC-d PDU lengths • Ability to support higher bit rates for advanced high-speed packet access (HSPA) (eg, up to 42 megabits per second (Mbps))
A small overhead in the transport network layer (data frame header and control frame length), and
A single data frame format and control frame format that will help with easier expansion in the future

1 is a diagram of an example network in which the systems and apparatus described herein can be implemented. FIG. 2 is an exemplary diagram of the base station of FIG. 1. FIG. 2 is an exemplary diagram of a computer readable medium that may be associated with the base station of FIG. FIG. 2 is an exemplary diagram of the radio network controller of FIG. 1. 4 is a flowchart of exemplary steps for transmitting a data frame, according to an example embodiment. FIG. 3 is an exemplary diagram of a control frame for capacity allocation of a high speed downlink shared channel (HS-DSCH) framing protocol type 2 according to an example embodiment. FIG. 4 is an exemplary diagram of portions of an HS-DSCH framing protocol type type 2 data frame, according to an example embodiment. FIG. 4 is an exemplary diagram of portions of an HS-DSCH framing protocol type type 2 data frame, according to an example embodiment. FIG. 4 is an exemplary diagram of portions of an HS-DSCH framing protocol type type 2 data frame, according to an example embodiment. FIG. 4 is an exemplary diagram of portions of an HS-DSCH framing protocol type type 2 data frame, according to an example embodiment. FIG. 4 is an exemplary diagram of portions of an HS-DSCH framing protocol type type 2 data frame, according to an example embodiment. 4 is a flowchart of exemplary steps for determining whether a node can support the HS-DSCH framing protocol type 2 format. FIG. 3 is an exemplary flow diagram according to an example embodiment.

  The following detailed description is made with reference to the accompanying drawings. The same reference numbers in different drawings may indicate the same or similar elements. Furthermore, the following detailed description does not limit the invention.

  The embodiments described herein provide an HS-DSCH framing protocol (referred to as “HS-DSCH framing protocol type 2”) that allows transmission of PDUs of different lengths.

  FIG. 1 is a diagram of an example network 100 in which the systems and devices described herein may be implemented. The network 100 is a group of user equipment (UE) 110-1 to 110-L (collectively referred to as “user equipment 110” in some examples) and a radio access network (RAN). 120 and a core network (CN) 130 may be included. For simplicity, four user equipments 110, one radio access network 120, and one core network 130 are shown here. In practice, there may be more or fewer user equipment, wireless networks, and / or core networks.

  User equipment 110 may include one or more devices capable of transmitting / receiving voice and / or data to / from radio access network 120. In one embodiment, user equipment 110 may include, for example, a wireless phone, a personal digital assistant (PDA), a laptop, and the like.

  The radio access network 120 may include one or more devices for transmitting voice and / or data to the user equipment 110 and the core network 130. As shown, the radio access network 120 is a group of base stations (BSs) 122-1 through 122-M (collectively referred to as "base stations 122", and in some examples individually referred to as "base stations"). 122) and a group of radio network controllers (RNCs) 124-1 to 124-N (collectively referred to as "radio network controllers 124"), and in some examples, individually referred to as "radio network controllers 124". May be included). For simplicity, here, four base stations 122 and two radio network controllers 124 are shown in FIG. In practice, there may be more or fewer base stations and / or radio network controllers.

  One or more base stations 122 (also referred to as “Node B”) receive voice and / or data from the radio network controller 124 and transmit the voice and / or data to the user equipment 110 via the radio interface. Of devices. One or more devices that receive voice and / or data from the user equipment 110 via a wireless interface and transmit the voice and / or data to the radio network controller 124 or other user equipment 110. May also be included.

  Radio network controller 124 may include one or more devices that control and manage base station 122. The wireless network controller 124 may also include a device that processes user data to manage the use of wireless network services. Radio network controller 124 receives voice and data from base station 122, other radio network controller 124, and / or core network 130 / from base station 122, other radio network controller 124, and / or core network 130. You may send / receive.

  The radio network controller 124 may operate as a controlling radio network controller (CRNC), a drift radio network controller (DRNC), or a service providing radio network controller (SRNC). The CRNC serves to control the resources of the base station 122. On the other hand, the SRNC provides a service to a specific user equipment 110 and manages the connection to the user equipment 110. Similarly, the DRNC plays a similar role as the SRNC (eg, may route traffic between the SRNC and a particular user equipment 110).

  As shown in FIG. 1, the radio network controller 124 may be connected to the base station 122 via an Iub interface or may be connected to other radio network controllers 124 via an Iur interface.

  The core network 130 may include one or more devices that transfer / receive voice and / or data to a circuit switched and / or packet switched network. In one embodiment, the core network 130 includes, for example, a mobile switching center (MSC), a gateway MSC (GMSC), a media gateway (MGW), a service providing GPRS (General Packet Radio Service) support node (SGSN). , A gateway GPRS support node (GGSN), and / or other devices.

  In some embodiments, one or more components of network 100 may perform one or more tasks described as being performed by one or more other components of network 100.

  FIG. 2 is an exemplary diagram of base station 122-1 in accordance with an example embodiment. Base stations 122-2 to 122-M may be similarly configured. As shown in FIG. 2, the base station 122-1 may include an antenna 210, a transceiver (TX / RX) 220, a processing system 230, and an Iub interface (I / F) 240. Base station 122-1 may include additional components and / or components different from those shown in FIG.

  The antenna 210 may include one or more directional antennas and / or omnidirectional antennas. The transceiver 220 may be associated with the antenna 210 and may include transceiver circuitry for transmitting and / or receiving symbol sequences in a network such as the network 110 via the antenna 210.

  The processing system 230 can control the operation of the base station 122-1. Processing system 230 can also process information received via transceiver 220 and Iub interface 240. The processing system 230 may further measure the quality and strength of the connection, determine a frame error rate (FER), and send this information to the radio network controller 124-1. As shown, the processing system 230 may include a processing unit 232, a group of prioritized queues 234, and a logical channel identifier (ID) to prioritized queue mapper 236. Of course, the processing system 230 may include additional components and / or components different from those shown in FIG.

  The processing unit 232 can process information received via the transceiver 220 and the Iub interface 240. The processing includes, for example, data conversion, forward error correction (FEC), rate adaptation, wideband code division multiple access (WCDMA), spreading / despreading, phase shift keying (QPSK). phase shift keying) and the like. Further, the processing unit 232 may generate a control message and / or a data message (for example, an HS-DSCH data frame), and send the control message and / or the data message to the transceiver 220 and / or the Iub interface 240. It may be transmitted via. The processing unit 232 may also process control messages and / or data messages received from the transceiver 220 and / or the Iub interface 240.

  The prioritized queue 234 can store information transmitted to the user equipment (eg, in the form of a PDU) and / or information received from the user equipment 110. In one embodiment, each user equipment 110 associated with base station 122-1 may be associated with one or more prioritized queues from prioritized queue 234. The prioritized queue may be initialized for a user equipment 110 when a MAC-d flow is established for the user equipment 110, for example.

  The logical channel identifier to priority queue mapper 236 can map the received logical channel identifier to the priority queue identifier. In one embodiment, an HS-DSCH framing protocol type 2 data frame may associate one or more logical channel identifiers with one or more PDUs stored in the data frame. Base station 122-1 can identify the appropriate prioritized queue from prioritized queue 234 using the logical channel identifier to store the PDU.

  The Iub interface 240 enables one or more lines that allow the base station 122-1 to transmit data to and receive data from the radio network controller 124-1. A card may be included.

  In some embodiments, one or more components of base station 122-1 may perform the tasks described as being performed by one or more other components of base station 122-1. Good.

  FIG. 3 is an exemplary illustration of a computer-readable medium 300 that may be associated with a base station, such as base station 122-1. Although one computer readable medium is described below, it will be appreciated that the computer readable medium 300 may be stored locally at the base station 122-1, or stored at one or more different remote locations. Multiple computer readable media may be included.

  As shown, the computer readable medium 300 may hold a group of entries in the following exemplary fields: a logical channel identifier field 310 and a prioritized queue identifier field 320. The computer readable medium 300 may include additional information or information that is different from the information shown in FIG.

  Logical channel identifier field 310 may store a sequence of characters that identify a logical channel associated with a user equipment such as user equipment 110-1. In one embodiment, the sequence of characters may be unique for this particular base station. The priority queue identifier field 320 may store a sequence of characters that identify priority queues in the priority queue 234. In one embodiment, each prioritized queue in prioritized queue 234 may be associated with a unique sequence of characters that serves as an identifier for that prioritized queue.

  Thus, via computer readable medium 300, base station 122-1 can identify prioritized queues based on received logical channel identifiers.

  FIG. 4 is an exemplary diagram of a radio network controller 124-1, in accordance with an example embodiment. The radio network controller 124-2 may be similarly configured. As shown in FIG. 4, the radio network controller 124-1 may include a processing system 410, an Iub interface 420, an Iur interface 430, and / or other interfaces 440. The radio network controller 124-1 may include additional components and / or components that are different from the components shown in FIG.

  The processing system 410 may control the operation of the radio network controller 124-1. As shown in the figure, the processing system 410 may include a processing unit 412 that performs protocol exchange among the Iub interface 420, the Iur interface 430, and another interface 440. Further, the processing unit 412 may generate control messages and / or data messages, and may transmit these control messages and / or data messages via the interfaces 420 to 440. The processing unit 412 may also process control messages and / or data messages received from the interfaces 420-440.

  The Iub interface 420 enables the radio network controller 124-1 to transmit control messages and / or data messages to the base station 122-1, and receives control messages and / or data messages from the base station 122-1. It may include one or more line cards that make it possible to do. The Iur interface 430 allows the radio network controller 124-1 to send control messages and / or data messages to other radio network controllers, such as the radio network controller 124-2, and the radio network controller 124-. One or more line cards that allow receiving control messages and / or data messages from other radio network controllers, such as 2, may be included. Other interfaces 440 may include interfaces to other devices and / or networks. For example, other interfaces 440 may include an Iucs interface that is a core network interface to a circuit switched voice network and an Iups interface that is a core network interface to a packet switched data network.

  In some embodiments, one or more components of radio network controller 124-1 perform the tasks described as being performed by one or more other components of radio network controller 124-1. May be.

  FIG. 5 is a flowchart of exemplary steps for transmitting a data frame, according to an example embodiment. In one embodiment, each part of the steps described in FIG. 5 may be performed by a base station, such as base station 122-1, where some of the steps are in a wireless network such as radio network controller 124-1. It may be executed by the controller. In other embodiments, some or all of the exemplary steps described below may be performed by other devices or combinations of devices.

  Exemplary steps may begin with the base station 122-1 generating a control frame for HS-DSCH framing protocol type 2 capacity allocation (CAPACITY ALLOCATION) (block 505). In one embodiment, the base station 122-1 may perform HS-DSCH framing protocol type 2 capacity allocation in response to an HS-DSCH capacity request from the radio network controller 124-1, or at any other time. A control frame may be generated. In particular, the HS-DSCH framing protocol type 2 capacity allocation control frame can identify MAC-d PDU credits in octets rather than by the number of PDUs.

  FIG. 6 is an exemplary diagram of a control frame 600 for HS-DSCH framing protocol type 2 capacity allocation in accordance with an example embodiment. As shown in the figure, the control frame 600 for HS-DSCH framing protocol type 2 capacity allocation includes a congestion status information element 610 and information on a common transport channel priority indicator (CmCH-PI). It may include an element 620, a MAC-d PDU credit information element 630, an HS-DSCH interval information element 640, an HS-DSCH repetition period information element 650, and a preliminary extension information element 660. In other embodiments, the HS-DSCH framing protocol type 2 capacity allocation control frame 600 may hold additional information elements or different information elements than those shown in FIG.

  The congestion status information element 610 may include information indicating whether a congestion status has been detected. The common transport channel priority indicator information element 620 may include information indicating the relative priority of data frames transferred from the radio network controller 124-1. The MAC-d PDU credit information element 630 is allowed to be transmitted by the radio network controller during one HS-DSCH interval by the HS-DSCH framing protocol type 2 capacity allocation control frame 600. d may include information indicating the number of octets in the PDU. In one embodiment, the value information element for the MAC-d PDU credit may range from 0 to 16,777,215, for example, where “0” represents a transmission stop, “16,777,215” may represent unlimited transmissions. The field length of the information element of the MAC-d PDU credit may be 24 bits.

  In an alternative embodiment, the MAC-d PDU credit information element 630 may be 20 bits, in which case 3 of the remaining 4 bits are used as spare bits and 1 bit is unused. May be used to indicate whether or not the credit octet can be reused by the radio network controller 124-1 at the next interval.

  The HS-DSCH interval information element 640 may store information representing a time interval during which HS-DSCH credits may be utilized in the HS-DSCH framing protocol type 2 capacity allocation control frame 600. . The HS-DSCH repetition period information element 650 stores information representing the number of subsequent intervals in which HS-DSCH credits may be used in the control frame 600 for capacity allocation of the HS-DSCH framing protocol type 2. May be. The preliminary extension information element 660 may be a placeholder for a future information element that may be added to the control frame 600 for HS-DSCH framing protocol type 2 capacity allocation.

  Thus, according to an exemplary embodiment, a new “MAC-d PDU credit” information element 630 is introduced in the control frame for HS-DSCH capacity allocation, which replaces the old “HS-DSCH credit” field. . The MAC-d PDU credit information element 630 with octet granularity (rather than the number of PDUs) allows the HS-DSCH (eg, because the amount of remaining octets is less than the length of the waiting MAC-d PDU). At the end of the interval, a situation occurs where one or more octets cannot be utilized for transmission of MAC-d PDUs. If the HS-DSCH repetition period information element 650 indicates that the repetition period is greater than 1 or 0, the "MAC-d PDU credit" It may be given to the flow. In this situation, the radio network controller can reuse these unused credits at the start of the next HS-DSCH interval.

  Returning to FIG. 5, the base station 122-1 transmits the HS-DSCH framing protocol type 2 capacity allocation control frame (for example, the HS-DSCH framing protocol type 2 capacity allocation control frame 600) to the radio network controller 124-. 1 (block 510). For example, the base station 122-1 may transfer an HS-DSCH framing protocol type 2 capacity allocation control frame to the radio network controller 124-1 via the Iub interface 240.

  The radio network controller 124-1 may receive an HS-DSCH framing protocol type 2 capacity allocation control frame (block 515). For example, the radio network controller 124-1 may receive a control frame for capacity allocation of the HS-DSCH framing protocol type 2 via the Iub interface 420. In response to receiving the control frame for HS-DSCH framing protocol type 2 capacity allocation, radio network controller 124-1 may generate a data frame for HS-DSCH framing protocol type 2 (block 520). In particular, HS-DSCH framing protocol type 2 data frames may store PDU blocks of the same length, in which case one block of PDUs may be different in length from the PDUs of other blocks. .

  FIG. 7A is an exemplary diagram of an HS-DSCH framing protocol type 2 data frame 700, according to an example embodiment. As shown, the HS-DSCH framing protocol type 2 data frame 700 may include a header 701 and a payload 715. The header 701 includes a header cyclic redundancy check (CRC) information element 702, a frame type (FT) information element 703, a frame sequence (Sec.) Number information element 704, and a common transport channel priority. Degree indicator (CmCH-PI) information element 705, flash information element 706, logical (Log.) Channel (Ch.) Identifier (ID) information element 707, user buffer size information element 708, PDU Information element 709 of the total number of blocks, information element 710 of the number of PDU block descriptions (#) (for example, each block is a MAC-d PDU length information element 711 and the number of PDUs in the block (#PDU)) Information element 712 and And if the attached communication) may include. In other embodiments, the header 701 may include additional information elements and / or different information elements than those shown in FIG. 7A.

  The header CRC information element 702 may store the calculated CRC in the header 701 of the data frame 700. The frame type information element 703 may store information indicating whether the frame 700 is a data frame or a control frame. The frame sequence number information element 704 may store a value representing the frame sequence number for the data frame 700 in the MAC-d flow. The common transport channel priority indicator information element 705 may include information indicating the relative priority of the data frame 700. The flash information element 706 may store information indicating whether the DRNC should delete all MAC-d PDUs from the corresponding prioritized queue received prior to the data frame 700 on the same transmission bearer. . The logical channel identifier information element 707 may store information identifying an instance of a logical channel when multiple logical channels are carried in the same transport network flow. In one embodiment, the logical channel identifier information element 707 may store a value between, for example, 0-15, in which case the values 0-14 identify logical channels 1-15 and the value 15 Can be reserved for future use. The field length of the logical channel identifier information element 707 may be 4 bits in the exemplary embodiment. The user buffer size information element 708 may store information representing the buffer size (eg, the amount of data in the buffer) in octets for a given common transport channel priority indicator level.

  The PDU block total information element 709 may store information representing the total number of PDU blocks in the data frame 700. A PDU block may be defined as one or more PDUs of the same length. Each PDU block may be described by the length of the PDU in the block and the number of PDUs. In situations where in-order delivery is desired, a block having one or more PDUs of the same length may be included in the data frame 700. For example, if the maximum PDU length is significantly smaller than a full IP packet, the IP packet may be segmented into a sequence of multiple PDUs, each having the same maximum PDU length. In one embodiment, the PDU block may support a PDU length that is the same length as the IP packet (eg, 1500 octets). The information element 709 of the total number of PDU blocks may store, for example, a value between 0 and 31. In this case, the value “0” may represent an invalid value. The field length of the information element 709 of the total number of PDU blocks may be 5 bits in the exemplary embodiment.

  As indicated above, each PDU block in data frame 700 may be associated with an information element 710 in the PDU block description. The information element 710 of the PDU block description may include an information element 711 of the MAC-d PDU length in the block and an information element 712 of the number of PDUs (#) in the block. The MAC-d PDU length information element 711 within a block may store information representing the length of each MAC-d PDU within this particular block. The length can be provided in octets. In one embodiment, the MAC-d PDU length information element 711 in the block may be a value between 0 and 2047, for example, in which case the value “0” may represent an invalid value. Good. The field length of the MAC-d PDU length information element 711 within the block may be 11 bits in the exemplary embodiment. The information element 712 for the number of PDUs in the block may store, for example, a value between 0 and 31. In this case, the value “0” may represent an invalid value. The field length of the information element 712 of the number of PDUs in a block may be 5 bits in the exemplary embodiment.

  The payload 715 includes one or more PDU blocks 716, a new information element (IE) flag information element 717, a delay reference time (DRT) information element 718, and a preliminary extension information element 719. And an information element 720 of the payload CRC. In other embodiments, payload 715 may include additional information elements and / or information elements that are different from those shown in FIG. 7A.

  The order of the PDU blocks 716 in the payload 715 may follow the corresponding order of the information elements of the PDU block description in the header 701. In the exemplary configuration shown in FIG. 7A, the header 701 includes descriptions for PDU blocks 1-n. Thus, payload 715 may include n PDU blocks ordered from 0 to n. As indicated above, each PDU block may include one or more PDUs of the same length. However, the length of PDUs in one block may be different from the length of PDUs in other blocks in the payload 715.

  New information element flag information element 717 may store information (eg, one or more flags) if at least one new information element is present in data frame 700. Each flag may indicate which new information element is present according to the information element 717 of the new information element flag. The delay reference time information element 718 may store information used for dynamic delay measurement. The preliminary extension information element 719 may be a placeholder for a future information element that may be added to the data frame 600. Payload CRC information element 720 may store the calculated CRC in payload 715 of data frame 700.

  As an alternative to the exemplary configuration shown in FIG. 7A, the MAC-d PDU length information element in the block is increased by one bit to be able to support a 4-bit MAC-d PDU length granularity. May be. This alternative embodiment may support legacy user equipment by enabling MAC-d PDU multiplexing. If the removal of MAC-d multiplexing is not allowed in the radio access network, the length of the MAC-d PDU length information element in the block is increased to represent the length in units of 4 bits. The information element of the logical channel identifier may be deleted.

  In some situations (eg, when the data frame includes small PDUs of different lengths), the 1-bit “more information” information element is the information element of the PDU block description in the header 701. 710 may be included. An exemplary diagram of an alternative PDU description information element 725 for this alternative embodiment is shown in FIG. 7B. The information element of the MAC-d PDU length in the block and the information element of the number of PDUs (#) in the block from the data frame 700 shown in the figure is an information element of “detailed information” (MI) Supplemented at 726, this detailed information may store information about the PDU within the block. In one embodiment, when the “detailed information” information element 726 stores a value of 0, the MAC-d PDU length information element in the associated block may be 7 bits long, The number of PDUs in a given block may be 1. On the other hand, when the “detailed information” information element 726 stores a value of 1, the 4 bits of the next octet may indicate the length (13 bits in total), and the other 4 bits indicate the number of PDUs. May be.

  FIG. 7C is an exemplary diagram of an HS-DSCH framing protocol type type 2 data frame 730, according to an example embodiment. In this embodiment, the information element 710 of the PDU description for each block (that is, the information element 711 of the MAC-d PDU length in the block and the information element 712 of the number of PDUs in the block) is (data frame 700 Instead of the header 701 (as in). As shown, the PDU description information element 710 for a given block may be placed immediately before the PDU 716 for this block.

  In other embodiments, a length indicator (eg, a 12-bit indicator) for each MAC-d PDU may be included in the header or payload of the HS-DSCH framing protocol type 2 data frame. An exemplary HS-DSCH framing protocol type 2 data frame 735 with a length indicator in the header portion 740 is shown in FIG. 7D. As shown, the header 740 of the HS-DSCH framing protocol type 2 data frame 735 includes a header cyclic redundancy check (CRC) information element 702, a frame type (FT) information element 703, a frame sequence ( Seq.) Number information element 704, common transport channel priority indicator (CmCH-PI) information element 705, flash information element 706, and logical (Log.) Channel (ch.) Identifier (ID). Information element 707, user buffer size information element 708, PDU total information element 741, multiple MAC-d PDU length indicator information elements 742 (eg, one for each PDU in data frame 735), , May be included. In other embodiments, the header 740 may include additional information elements and / or information elements that are different from the information elements shown in FIG. 7D.

  Header cyclic redundancy check information element 702, frame type information element 703, frame sequence number information element 704, common transport channel priority indicator information element 705, flash information element 706, logical channel identifier The information element 707 and the user buffer size information element 708 may include information similar to that described above with respect to FIG. 7A. The PDU total information element 741 may store information indicating the number (or amount) of PDUs in the data frame 735. Each MAC-d PDU length indicator information element 742 may store information representing the corresponding PDU length (eg, in octets) within the payload 745. For example, if PDU # 1 has a length of 8 octets, the information element of the MAC-d PDU length indicator for PDU # 1 may store a value indicating 8 octets.

  The payload 745 includes one or more PDUs 746, a new information element (IE) flag information element 717, a delay reference time (DRT) information element 718, a preliminary extension information element 719, and a payload CRC information. Element 720. In other embodiments, the payload 745 may include additional information elements and / or information elements different from those shown in FIG. 7D.

  In payload 745, each PDU may be placed in its original order to avoid reordering. The order of the PDUs may correspond to the order of the MAC-d PDU length indicator 742 in the header 740. The information element 717 of the new information element flag, the information element 718 of the delay reference time, the information element 719 of the spare extension unit, and the information element 720 of the payload CRC are information similar to the information described above with reference to FIG. 7A. Can be included.

  In some embodiments, the logical channel identifier may be the same for the entire HS-DSCH framing protocol type 2 data frame, such as data frame 700 of FIG. 7A. In other embodiments, a particular HS-DSCH framing protocol type 2 data frame may be associated with more than one logical channel identifier. FIG. 7E is an exemplary diagram of an HS-DSCH framing protocol type 2 data frame 750 associated with more than one logical channel identifier. As shown, the header 755 of the HS-DSCH framing protocol type 2 data frame 750 includes a header cyclic redundancy check (CRC) information element 702, a frame type (FT) information element 703, a frame sequence ( Seq.) Number information element 704, common transport channel priority indicator (CmCH-PI) information element 705, flash information element 706, user buffer size information element 708, and PDU block total information element 709 and multiple MAC-d PDU description information elements 751 (eg, one for each PDU in data frame 750), in which case the MAC-d PDU description for a particular PDU Information element 7 51 includes a logical channel identifier information element 752 for the PDU and a MAC-d PDU length indicator information element 753. In other embodiments, the header 755 may include additional information elements and / or different information elements than those shown in FIG. 7E.

  Header cyclic redundancy check information element 702, frame type information element 703, frame sequence number information element 704, common transport channel priority indicator information element 705, flash information element 706, user buffer size Information element 708 and PDU block total information element 709 may include information similar to that described above with respect to FIG. 7A. The logical channel identifier information element 752 for a PDU may store information identifying a logical channel instance for the PDU. In one embodiment, the logical channel identifier information element 752 may store, for example, a value between 0 and 15, in which case values from 0 to 14 indicate logical channels 1 to 15, “15” may be reserved for future use. The field length of the logical channel identifier information element 752 may be 4 bits in the exemplary embodiment. The MAC-d PDU length indicator information element 753 for a PDU may store information representing (eg, in octets) the length of the corresponding PDU in the payload 760. For example, if PDU # 1 has a length of 8 octets, the MAC-d PDU length indicator information element 753 for PDU # 1 may store a value indicating 8 octets.

  The payload 760 includes one or more PDUs 761, a new information element (IE) flag information element 717, a delay reference time (DRT) information element 718, a spare extension information element 719, and payload CRC information. Element 720. In other embodiments, the payload 760 may include additional information elements and / or information elements different from those shown in FIG. 7E.

  In the payload 760, each PDU can be placed in its original order to avoid reordering. The order of PDUs 716 may correspond to the order of MAC-d PDU length indicators 753 in header 755. The information element 717 of the new information flag, the information element 718 of the delay reference time, the information element 719 of the spare extension unit, and the information element 720 of the payload CRC have the same information as the information described above with reference to FIG. 7A. May be included.

  Returning to FIG. 5, the radio network controller 124-1 may forward an HS-DSCH framing protocol type 2 data frame (eg, data frame 700, 730, 735, or 750) to the base station 122-1. Block 525). For example, the radio network controller 124-1 may forward HS-DSCH framing protocol type 2 data frames to the base station 122-1 via the Iub interface 420.

  The base station 122-1 may receive a data frame of HS-DSCH framing protocol type 2 from the radio network controller 124-1. For example, the base station 122-1 may receive an HS-DSCH framing protocol type 2 data frame via the Iub 240. The base station 122-1 obtains the logical channel identifier from the HS-DSCH framing protocol type 2 data frame (eg, from the logical channel identifier information element 707 in the header 701 of the HS-DSCH framing protocol type 2 data frame 700). Extracting and analyzing the HS-DSCH framing protocol type 2 data frame may map the extracted logical channel identifier to a prioritized queue identifier (block 535). For example, the base station 122-1 uses the extracted logical channel identifier via the logical channel identifier to priority queue mapper 236, so that the PDU of the data frame in the priority queue 234 The identifier for the prioritized queue may be looked up (eg, via computer readable medium 300). In situations where the HS-DSCH framing protocol type 2 data frame includes multiple logical channel identifiers (eg, data frame 750 in FIG. 7E), the base station 122-1 may prioritize the PDU associated with the logical channel identifier. Multiple lookup operations may be performed to identify the attached queue.

  In the prior art, a high speed downlink packet access (HSDPA) base station maintains multiple prioritized queues. An instance of a prioritized queue is initialized when a MAC-d PDU flow is established via a Node B Application Part (NBAP) message. Further, one prioritized queue may serve several logical channels (or radio bearers). The prior art does not include signaling to the base station to support the mapping of prioritized queues to logical channels (or radio bearers) using HS-DSCH radio links / radio bearers for user data transmission . As a result, the priority queue identifier is transmitted to the user equipment along with the logical channel for each PDU, so that the user equipment 1) to which logical channel the PDU belongs, and 2) which priority queue Can be determined for scheduling and reordering. This leads to an unnecessarily large overhead on the radio interface.

  In stark contrast, in the embodiments described herein, the radio network controller can send a control message to the base station that provides a mapping between logical channels and prioritized queues. This mapping is already included in the prior art for signaling between the controlling radio network controller / serving radio network controller (CRNC / SRNC) and the user equipment. Then, only the logical channel identification needs to be added to each PDU transmitted from the base station to the user equipment by signaling the same mapping to the base station. Then, the user equipment can determine the correct priority queue identifier from the logical channel identifier. Therefore, the overhead in the radio interface can be reduced.

  Table 1 shows the old HS-DSCH data frame format (ie, HS-DSCH framing protocol type 1 data frame) and the new HS-DSCH data frame format (ie, the exemplary embodiment described herein). Accordingly, an example of an overhead value related to HS-DSCH framing protocol type 2 data frame) is shown. In such an example, it is assumed that the delay reference time information element is not present in the data frame. As shown, the new HS-DSCH data frame format is a substantial amount in each situation (except when a single octet of 10 octets is transmitted, ie the overhead would be equal in that situation). The overhead of is omitted.

  Once the prioritized queue has been identified, the base station 122-1 can send PDUs from HS-DSCH framing protocol type 2 data frames to the prioritized queue 234 for later transmission to the user equipment 110. May be stored in an appropriate prioritized queue (block 540).

  Returning to block 525, once the radio network controller 124-1 has transmitted an HS-DSCH framing protocol type 2 data frame, the radio network controller 124-1 determines whether there are any unused credits remaining, HS-DSCH framing. A determination may be made from a control frame for protocol type 2 capacity allocation (block 545). As indicated above, the MAC-d PDU credit information element of the HS-DSCH framing protocol type 2 capacity allocation control frame is included in the HS-DSCH framing protocol type 2 capacity allocation control frame (e.g., MAC- d) Indicates the number of octets of the MAC-d PDU that are allowed to be transmitted by the radio network controller during one HS-DSCH interval (in the information element 630 of the PDU credit). If the capacity allocation control frame is valid for more than one interval, the radio network controller may reuse credits that were not used within a certain interval in subsequent intervals.

  If the wireless network controller 124-1 determines from the control frame for capacity allocation of the HS-DSCH framing protocol type 2 that unused credits remain (block 545-YES), the wireless network controller 124-1 Unused credit may be utilized in the next interval (block 550). In one embodiment, the radio network controller 124-1 may utilize unused credits only at the next interval (not at multiple intervals ahead of the next interval). The ability to utilize credits that were not utilized in the previous interval in the next interval provides a stable bit rate. On the other hand, when the radio network controller 124-1 determines from the control frame for capacity allocation of the HS-DSCH framing protocol type 2 that there are no unused credits (block 545-NO), the process ends. obtain. For example, the process may return to block 515 where the radio network controller 124-1 receives a control frame of another HS-DSCH framing protocol type 2 capacity allocation.

  FIG. 8 is a flowchart of exemplary steps for determining whether a node can support the HS-DSCH framing protocol type 2 format, according to an example embodiment. In one embodiment, each part of the steps described in FIG. 8 may be performed by a base station, such as base station 122-1, and part of the processing may be performed by a radio network controller 124-1. It may be executed by a radio network controller. In other embodiments, some or all of the exemplary steps described below may be performed by other devices or combinations of devices. For example, the steps described below may be performed by a first radio network controller and a second radio network controller.

  Exemplary steps may begin with generating a control message that identifies the HS-DSCH framing protocol type supported by the radio network controller (block 805). In one embodiment, the control message may be, for example, a RADIO LINK SETUP REQUEST message, a RADIO LINK ADD REQUUE REQUEST REQUEST message, a RADIO LINK RECONFIGURATION REQUEST message, a RADIO LINK RECONFIGURATION REQUEST message, a RADIO LINK RECONFIGURATION message, or a RADIO LINK RECONFIGURATION message. May include a type of control message. In one embodiment, the control message may include an information element of HS-DSCH framing protocol type support in an information element of HS-DSCH frequency division duplex (FDD) information. An exemplary coding of information elements for HS-DSCH framing protocol type support is shown in Table 2. As shown, the HS-DSCH framing protocol type support information element may store a list of 8-bit Boolean values in an example embodiment. Lists of Boolean values of other sizes are possible. The HS-DSCH framing protocol type support information element may indicate which HS-DSCH framing protocol types are supported. More than one framing protocol type may be supported. From right to left in the Boolean list, each position may indicate HS-DSCH framing protocol types 1-8. In one embodiment, “0” may indicate that the type is not supported, and “1” may indicate that the type is supported. For example, a Boolean list of “11000000” may indicate that both Type 1 and Type 2 framing protocol formats are supported.

  The radio network controller 124-1 may send a control message to the base station 122-1 (block 810). For example, the radio network controller 124-1 may transmit a control message via the Iub interface 420. Base station 122-1 may receive a control message (block 815). For example, the base station 122-1 may receive a control message via the Iub interface 240. After receiving this control message (including the HS-DSCH framing protocol type information element), the base station 122-1 may select the HS-DSCH framing protocol type (block 820). Base station 122-1 may make a selection based on multiple factors. For example, in one embodiment, base station 122-1 may select HS-DSCH framing protocol type 2 whenever base station 122-1 is compatible with this framing protocol format.

  Base station 122-1 may generate a response message that identifies the selected HS-DSCH framing protocol type (block 825). In one embodiment, the response message may be, for example, a RADIO LINK SETUP RESPONSE message, a RADIO LINK REDENSION RESPONSE message, a RADIO LINK RECONFIGURATION RESPONSE message, a RADIO LINK RECONFIGURATION PON A type of response message may be included. The type of response message generated may be based on a control message received from the radio network controller 124-1. In one embodiment, the response message may include an information element of the selected HS-DSCH framing protocol type in the information element of the HS-DSCH frequency division duplex (FDD) information response. An exemplary coding of selected HS-DSCH framing protocol type information elements is shown in Table 3. As shown, the selected HS-DSCH framing protocol type information element may store an integer (eg, 1-8) representing the number of protocol types in an exemplary embodiment. The selected HS-DSCH framing protocol type information element may indicate the HS-DSCH framing protocol type used. For example, a value of “1” may indicate that framing protocol type 1 is selected, and a value of “2” may indicate that HS-DSCH framing protocol type 2 is selected.

  In one embodiment, the base station 122-1 may include an HS-DSCH Initial Capacity Allocation information element in the response message. The HS-DSCH initial capacity allocation information element may provide flow control information for each scheduling priority class for the HS-DSCH framing protocol over the Iub interface. The HS-DSCH initial capacity allocation information element includes a scheduling indicator information element (which can also store information indicating the relative priority of the HS-DSCH data frame), and the length of the MAC-d PDU. An information element of maximum MAC-d PDU size (which may also store information representing (for example in bits)) and transmitted by the radio network controller 124-1 before a new credit is received from the base station 122-1. Information element of HS-DSCH initial window size (which may also store information representing the initial number of MAC-d PDUs to be obtained). The interpretation of the HS-DSCH initial capacity allocation information element may vary based on the selected framing protocol type. For example, for framing protocol type 2, the HS-DSCH initial capacity allocation information element multiplies the maximum MAC-d PDU length (maximum MAC-d PDU size) by the number of MAC-d PDUs (HS-DSCH initial window size). May be interpreted. This gives the total number of bits (or octets).

  In one embodiment, the base station 122-1 may include an information element of maximum HS-DSCH framing protocol data frame length in the information element of the HS-DSCH frequency division duplex (FDD) information response (block 830). An exemplary coding of the HS-DSCH framing protocol data frame length information element is shown in Table 4. As shown in the figure, the HS-DSCH framing protocol data frame length information element is an integer that represents the maximum HS-DSCH framing protocol data frame length in octets (eg, from 1 to 5000 or more) in an exemplary embodiment. Can be stored. In practice, when the radio network controller 124-1 has a maximum transmission unit of the receiving framing protocol having a length equal to the maximum length in the information element of the HS-DSCH framing protocol data frame length. The radio network controller 124-1 considers the maximum transmission unit of its framing protocol and may therefore trigger the maximum PDU length for radio link control. This information element may be applicable to all HS-DSCH framing protocol types.

  Once the response message is generated, the base station 122-1 may send the response message to the radio network controller 124-1 (block 835). For example, the base station 122-1 may transmit a control message via the Iub interface 240. The radio network controller 124-1 may receive a control message (block 840). For example, the radio network controller 124-1 may receive a control message via the Iub interface 420. The radio network controller 124-1 may determine whether a framing protocol type has been selected by the base station 122-1 (block 845). For example, the radio network controller 124-1 may analyze the response message to determine whether the response message includes an information element of a selected HS-DSCH framing protocol type.

  If an information element of the selected HS-DSCH framing protocol type is included in the received response message (YES in block 845), the radio network controller 124-1 may use the base station 122-1 based on this information element. The HS-DSCH framing protocol type selected by can be identified. The radio network controller 124-1 may generate an HS-DSCH data frame to the base station 122-1 according to the selected selected HS-DSCH framing protocol type (block 850). For example, if the selected HS-DSCH framing protocol type information element indicates that the base station 122-1 has selected the HS-DSCH framing protocol type 2 format, the radio network controller 124-1 may HS-DSCH framing protocol type 2 data frames to -1 can be generated and transmitted.

  On the other hand, if the selected HS-DSCH framing protocol type information element is not included in the received response message (or if no response is received from the base station 122-1, for example) (block 845-NO), the radio network controller 124-1 may generate and transmit an HS-DSCH data frame to the base station 122-1 based on a predetermined HS-DSCH framing protocol type. In one embodiment, the predetermined HS-DSCH framing protocol type may include an HS-DSCH framing protocol type 1 format.

  As an alternative to the steps described above with respect to FIG. 8, the base station's ability to handle different HS-DSCH framing protocol types may be configured in a wireless network associated with the base station. For example, the radio network controller 124-1 may be configured with information identifying HS-DSCH framing protocol types supported by the base stations 122-1 and 122-2. Thus, for example, if the radio network controller 124-1 has a PDU to be transmitted to the base station 122-1, the radio network controller 124-1 (eg, in a memory associated with the radio network controller 124-1) It can be determined (by looking up the information) whether base station 122-1 is capable of handling HS-DSCH framing protocol type 2. If the base station 122-1 is capable of handling HS-DSCH framing protocol type 2, the radio network controller 124-1 may include an HS-DSCH that includes a PDU, as described herein. It is possible to generate a framing protocol type 2 data frame and transfer the data frame to the base station 122-1.

  In one embodiment as illustrated in FIG. 9, the serving radio network controller (SRNC) supports a flexible PDU length (ie, HS-DSCH framing protocol type 2 format) by the drift radio network controller (DRNC). You may need to know if you want to do it. It is possible that not all base stations associated with the drift radio network controller support new flexible PDU-length data frames, and this support may vary from cell to cell. The solution for this includes information on support for flexible PDU length per cell in the CAPABILITY CONTAINER information element 910 transmitted from the drift radio network controller to the serving radio network controller. That is. Similarly, for the relocation of the serving radio network controller, the information element is sent from the reserving serving network controller to the target radio network controller to the target RNC's transparent container (SOURCE RNC TARGET RNC TRANSPARENT CONTAINER). ), Which conveys the ability to handle flexible PDU-length data frames.

  The ability to support flexible PDU length data frames may also be communicated to the user equipment 110. For example, an information element indicating whether the base station can support a flexible PDU-length data frame may be included in the control message to the user equipment 110. The control message may include, for example, a RADIO BEARER SETUP message, a RADIO BEARER RECONFIGUREATION message, a TRANSPORT CHANNEL RECONFIguration message, and / or other types of control messages.

Thus, as described herein, the HS-DSCH framing protocol type 2 frame format may provide:
• Maximum MAC-d PDU length up to 1500 octets and octet granularity in MAC-d PDU length is effectively supported • Ability to account for maximum transmission unit limitations of the transport network used • Flexible Ability to support MAC-d (RLC) PDU lengths • Ability to support higher bit rates of evolved high-speed packet access (HSPA) (eg, up to 42 megabits per second (Mbps))
A small overhead in the transport network layer (data frame header and control frame length), and
A single data frame format and control frame format for Release 7 that will help with easier expansion in the future. The HS-DSCH framing protocol type 2 capacity allocation control frame may provide:
The ability to represent octets or bit rates (instead of the number of PDUs and maximum PDU length), the ability to have good bit rate granularity,
Ability to transmit large or small PDUs with low latency and without overly intensive loading on the transport network HS-DSCH framing protocol type 2 data frames may provide: .
Ability to support flexible MAC-d PDU lengths Small overhead for all cases, eg PDUs of different lengths in the same data frame, and
・ Small PDU of the same length

  The embodiments described herein provide an effective solution for transport network support for flexible PDU-length data frames. The HS-DSCH framing protocol type 2 capacity allocation control frame supports a larger MAC-d PDU length by allowing reuse of unused credits. HS-DSCH framing protocol type 2 data frames allow for large MAC-d PDU lengths and allow more than one PDU length in the same data frame. In addition, HS-DSCH framing protocol type 2 data frames allow MAC-d PDUs from several logical channels within one connection. Header overhead and padding for the transport network are kept small for typical usage.

  The new information elements described here allow for improved interoperability between different frame formats without adding new signaling messages. A new interpretation of the information element of the HS-DSCH initial capacity allocation supports a flexible PDU-length data frame without changing the definition of the information element.

  While the embodiments described herein provide illustrations and detailed descriptions, they are not intended to be exhaustive or to limit implementation to the precise form disclosed. Modifications and variations can be made in light of the above disclosure or from realistic implementations. For example, the following description focuses on the architecture of a Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (UTRAN), but it should be understood that Is equally applicable to other types of architectures, such as UTRAN flat architecture. In the UTRAN flat architecture, a radio network controller (RNC) and a base station (BS) may be combined into one RNC / BS node. The gateway device may transfer traffic between the core network and the RNC / BS node via the transport network.

  Although a series of operations have been described with respect to FIGS. 5 and 8, the order of operations may be changed in other embodiments. Furthermore, independent operations may be performed in parallel.

  The example embodiments may be implemented in the illustrated implementation in a number of different forms of software, firmware, and hardware, as described above. The actual software code or hardware specialized for control used to implement the example embodiments described herein does not limit the invention. Accordingly, the operation and operation of an example embodiment is described without reference to specific software code. That is, it should be understood that software and control hardware can be designed to implement an exemplary embodiment based on the description herein.

  Further, certain portions of the invention may be implemented as “logic” that performs one or more functions. This logic may include application specific integrated circuits, field programmable gate arrays, hardware such as processors or microprocessors, software, or a combination of hardware and software.

  Although specific combinations of features are recited in the claims and / or disclosed in the specification, these combinations are not intended to limit the invention. Indeed, many of these features may be combined in ways not specifically recited in the claims and / or disclosed in the specification.

  As used herein, the term “comprise / comprising” is used to specify the presence of a stated feature, integer, step, or component. Emphasize not excluding the presence or addition of these other features, integers, steps, components, or collections thereof.

  Any element, operation, or instruction used in the description of the present application is not to be regarded as essential or essential to the invention unless explicitly described as such. Further, as used herein, the article “a” includes one or more items. Where only one item is intended, the word “one” or similar phrase is used. Further, the phrase “based on” is used to refer to “based, at least in part, on” unless stated otherwise. ).

Claims (11)

A method performed by a first device (122) in a high speed downlink packet access environment (100) comprising:
High speed downlink includes a second first value representing the number of packet data units toe octets whose transmission is permitted by the device (124) between the shared channel spacing (630), the capacity allocation for high-speed downlink shared channel Generating a control frame (600);
Transferring a capacity allocation control frame (600) of the high speed downlink shared channel to the second device (124);
In response to the control frame (600) for capacity allocation of the high speed downlink shared channel, a high speed downlink shared channel data frame including a second number of packet data unit octets is received from the second device (124). And steps to
Including
If the second number is less than the first number, unused packet data unit octets are reused in the next interval;
A method characterized by that. The high-speed downlink shared channel capacity allocation control frame (600) stores a first time interval during which the second device is allowed to use the first number of packet data unit octets . The method of claim 1, further comprising an information element (640). The control frame for capacity allocation of the high speed downlink shared channel stores a value indicating the number of subsequent intervals during which the second device is allowed to use the first number of packet data unit octets. The method of claim 2, further comprising: a second information element (650). Capacity allocation for high-speed downlink shared channel including the value (630) representing a first number of packet data units toe octets that a radio network controller (124) is allowed to transmit during a High Speed Downlink Shared Channel interval A processing system (230) adapted to generate a control frame (600) of
The high-speed downlink shared channel capacity allocation control frame (600) is transferred to the radio network controller (124), and the radio is transmitted as a response to the high-speed downlink shared channel capacity allocation control frame (600). An Iub interface (240) adapted to receive a high speed downlink shared channel data frame comprising a second number of packet data unit octets from the network controller (124) ;
If the second number is less than the first number, unused packet data unit octets are reused in the next interval;
A device characterized by. The control frame for capacity allocation of the high speed downlink shared channel further includes:
A first information element (640) for storing a time interval during which the radio network controller is allowed to use the first number of packet data unit octets ;
5. A second information element (650) storing a value indicating a number of subsequent intervals during which the radio network controller is allowed to utilize the first number of packet data unit octets. The device described in 1. A method performed by a first device (124) in a high speed downlink packet access environment (100) comprising:
Receiving a high speed downlink shared channel capacity allocation control frame (600) from a second device (122), wherein the high speed downlink shared channel capacity allocation control frame (600) is a high speed downlink; a first value representing a first number of the first packet data units toe octets which device (124) is allowed to transmit during a shared channel spacing comprising a (630), and said step,
In response to receiving the control frame (600) for capacity allocation of the high speed downlink shared channel, a high speed downlink shared channel data frame (700, 730, 735, 750) including a second number of packet data unit octets is received. Generating, wherein the second number is equal to or less than the first number;
Forwarding the high speed downlink shared channel data frame (700, 730, 735, 750) to the second device (122) at certain intervals;
Only including,
If the second number is less than the first number, the method further includes reusing unused packet data unit octets in the next interval;
A method characterized by that. The capacity allocation control frame of the high speed downlink shared channel is a second value indicating the number of subsequent intervals during which the first device is allowed to use the first number of packet data unit octets. including an information element (640) for storing the method of claim 6.   The high speed downlink shared channel data frame includes a plurality of blocks (716), each block includes a group of packet data units, and the length of each packet data unit in the first block of the plurality of blocks is The method according to claim 6, wherein a length of each packet data in a second block of the plurality of blocks is different. 9. The method of claim 8 , wherein the high speed downlink shared channel data frame includes a packet data unit and a logical channel identifier (707, 752).   The method of claim 6, wherein the high speed downlink shared channel data frame comprises a plurality of packet data units (761) and a plurality of logical channel identifiers (752).   A first device (124) in a high speed downlink packet access environment (100), comprising:
  An Iub interface (420) for receiving a control frame for capacity allocation of the high speed downlink shared channel from the second device (122);
  A processing system (410) adapted to generate a high speed downlink shared channel data frame including a second number of packet data unit octets in response to receiving a control frame of capacity allocation of the high speed downlink shared channel When,
  With
  The high speed downlink shared channel capacity allocation control frame (600) is a first of packet data unit octets allowed to be transmitted by the first device (124) during a high speed downlink shared channel interval. Including a first value (630) representing a number;
  The Iub interface (420) is further adapted to forward the high speed downlink shared channel data frame to the second device (122) at intervals, wherein the second number is the first number. Equal to or less than the first number,
  If the second number is less than the first number, unused packet data unit octets are reused in the next interval;
  A device characterized by that.

Images