Mobile communication system, control device, base station device, system control method and device control method for data communication using fixed or variable length data size

ES 2 632 397 T3

DESCRIPTION

Mobile communication system, control device, base station device and communication control method

Technical field

The present invention relates to a mobile communication system for carrying out data communication using a fixed-length or variable-length data size.

Background

In the 3GPP (Collaboration Project of 3^to Generation - 3^rd Generation Partnership Project, the HSDPA (High Speed ​​Downlink Packet Access) standard for W-CDMA mobile communication has been standardized (see document 1 which does not is patent). In HSDPA, the MAC-hs protocol or the MAC-ehs protocol is used for the MAC (Medium Access Control) layer. HSDPA provides packet-based high-speed data communication on a downlink from an RNC (Radio Network Controller) to a UE (User Equipment) via a Node-B. IN HSDPA data communication, a flow control is carried out between the RNC (Radio Network Controller) and the Node-B (Base Station) (see also ERICSSON: “Support of higher bitrates and Flexible RLC PDU size on HS-DSCH in RAN Transport Network ”, 3GPP DRAFT; R3070150, 02-07-2007).

In flow control, the Node-B notifies the RNC of the data capacity, and the RNC transmits data in the scope of the data capacity to the Node-B. Here, the Node-B determines the data capacity, taking into consideration, for example, the capacity of the radio channel, the product quality report provided by the UE, the priority assigned to the carrier, and the status of the route. transmission between RNC and Node-B as parameters. A notification of the data capacity is provided through a frame control message called CAPACITY ALLOCATION.

In HSDPA data communication, three types of cases are contemplated for communication modes. The parameters that are adapted to each case are established for the RNCs and the Node-Bs.

Figure 1 is a table illustrating an example of parameter settings for the respective HSDPA cases. Referring to Figure 1, examples of parameter settings will be illustrated for the respective cases 1 to 3. Case 1 has already been defined from 3GPP Version 5 and later and cases 2 and 3 are expected to be defined in 3GPP Version 7 and later.

In case 1, the size of the PDUs (Protocol Data Units) in the RLC (Radio Link Control) layer (referred to in this report as "size of the RLC PDU "has a fixed length, and for the MAC layer, the MAC-hs protocol is used. A PDU is a unit of a transmission signal in a predetermined protocol. For example, a PDU includes a header according to a predetermined protocol and a payload that includes data in the protocol.

In the MAC-hs protocol, neither 64QAM (Quadrature Amplitude Modulation) nor MIMO (Multiple Input Multiple Output) are used.

In case 2, the RLC PDU size has a fixed length as in case 1, but the MAC-ehs protocol is used for the MAC layer. In the MAC-ehs protocol, 64QAM and MIMO can be used. Also in MACehs, a transmission method called Enhanced Layer 2 on the Downlink is used.

64QAM, which is one of the digital modulation methods, expresses 64 values ​​by a combination of eight types of phase and eight types of amplitude. MIMO is a radio communication technique for expanding a data communication band using a plurality of antennas simultaneously. In Enhanced Layer 2, the MAC-ehs protocol is provided in the Node-B segment user data. Enhanced Layer 2 allows for more efficient data transfer compared to a transmission method in which user data is divided by a fixed length on an RLC.

In case 3, the RLC PDU size is variable in length, and for the MAC layer, the MAC-ehs protocol is used. In this case, a Node-B designates a maximum length of the RLC PDU size. An RNC may select an RLC PDU size within a range equal to or less than the maximum length designated by the Node-B. In flow control, Node-B can control the maximum value of the RLC PDU size.

In the flow control in 3GPP Version 7 in which the MAC-ehs protocol has been introduced, a format called CAPACITY ALLOCATION TYPE 2 is used instead of a format called CAPACITY ALLOCATION TYPE 1 which is used in 3GPP Version 5.

ES 2 632 397 T3

With a frame in CAPACITY ALLOCATION TYPE 2, a Node-B can control the following four items.

(1) Maximum MAC-d / c PDU length (MAC-d PDU length) (2) HS-DSCH credit (the number of MAC-d PDUs that can be transmitted during a transmission interval in a HS-DSCH) (3) HS-DSCH Interval (duration in which the number of MAC-d PDUs indicated by the HS-DSCH are transmitted) (4) HS-DSCH Repetition Period (repetition count that indicates the number of repetitions of the previous duration)

For example, where a radio channel is going to get into congestion, the MAC-d / c PDU length (maximum MAC-d / c PDU length) may be reduced or the credit of the HS-DSCH may be reduced. in order to suppress the amount of downlink data. An HS-DSCH (High Speed ​​Downlink Shared Channel) is a channel shared by a plurality of HSDPA data communications.

As described above, in cases 2 and 3, which are to be defined in 3GPP Version 7 and later, 64QAM and MIMO can be used, which could not be used in and before 3GPP Version 6.

Between cases 2 and 3 to be defined in 3GPP Version 7 and later, there is a difference in whether the RLC PDU size has a fixed length or a variable length.

In case 3, since the RLC PDU size is variable, the maximum value of the RLC PDU size can be varied in a range equal to or less than 1504 octets in flow control. As a result of such flow control, more efficient data communication can be provided in accordance with the changing communication status.

Meanwhile, case 2 allows the use of 64QAM and MIMO even carrying out flow control using an existing and simple algorithm with fixed RLC PDU size as in case 1.

Citation List

Non-Patent Literature

Non-patent Literature 1: 3GPP TS 25.308 V8.2.0 (2008-05), High Speed ​​Downlink Packet Access (HSDPA), Global Description, Stage 2 (Version 8).

Summary of the Invention

Technical problem

In order to use 64QAM or MIMO, you need to use the MAC-ehs protocol. Where the MAC-ehs protocol is used, the RLC PDU size can be either a fixed length or a variable length, and thus, for an RLC to operate, it is necessary to set the size of the RLC PDU to have a fixed length or a variable length.

However, in the NBAP protocol (Node-B Application Part, 3GPP TS25.433), which is a current call control protocol, an RNC cannot notify a Node-B about whether the size of the PDU RLC has a fixed length or a variable length. Figure 2 is a table illustrating parameters in the NBAP protocol. This table is one illustrated in 3GPP TS 24.4339.2.1.31.IA. Referring to Figure 2, it can be seen that there is no information element to report an adjustment as to whether the RLC PDU size is a fixed length or a variable length, and thus the NBAP protocol cannot provide a notification. of such an adjustment. Accordingly, there is a problem that there may be a discrepancy in the setting states of whether the RLC PDU size has a fixed length or a variable length between an RNC and a Node-B.

When using the MAC-ehs protocol, current NBAP assumes that the HS-DSCH MAC-d PDU Size Format IE has a “Flexible MAC-d PDU Size”. Consequently, an RNC sets the RLC PDU size to be a fixed length and a Node-B sets the RLC PDU size to a variable length, which can result in a state discrepancy between the RNC and Node-B.

If the size of the RLC PDU is set to be of variable length, the Node-B can give an instruction to change the size of the RLC PDU to the RNC in flow control. However, the RNC cannot resize the RLC PDU because the RLC PDU size is set to be a fixed length.

ES 2 632 397 T3

For example, where the Node-B gives an Instruction to provide a size greater than the fixed length set in the RNC, to the RNC, the Node-B should be able to receive a PDU with a size greater than the fixed length. However, where the RLC PDU size is set to have a fixed length at the RNC, the RNC segments the data by the fixed length. In that case, the efficiency of using system resources such as a band may not be sufficiently improved.

Also, for example, if the Node-B gives an instruction to provide a size smaller than the fixed length set in the RNC, to the RNC, the RNC in which the RLC PDU size is set to have the fixed length does not It can transmit data to Node-B or send data with a size that exceeds the limit, to Node-B. In such a case, serious failures in flow control and / or system operation occur.

Figure 3 is a table illustrating an example of a communication mode to describe a flow control failure. Figure 4 illustrates an example of a sequence that results in the occurrence of a flow control defect.

In the example in Figure 3, the RLC PDU size is 82 bytes, the MAC-ehs protocol is used, and MIMO and 64QAM are used.

In this case, the IE Maximum Extended MAC-d PDU in NBAP Size, which designates a maximum value of the MAC-d PDU size, is set to 82 bytes.

Referring to the sequence of Figure 4, first, an RNC adjusts the size of the RLC PDU to be a fixed length (step 901). When MAC-ehs is used, no logical channel multiplexing is performed at the MAC-d layer, and thus no MAC-d header is provided. Accordingly, in this example, the size of the MAC-d PDU is equal to the size of the RLC PDU (step 902).

The RNC prepares an NBAP message: RL SETUP REQUEST (step 903) and transmits the message to a Node-B (step 904). This NBAP: RL SETUP REQUEST message includes an IE Maximum MAC-d PDU Extended in Size set to 82 bytes, which is the maximum value of the MAC-d PDU size.

Receiving the message from NBAP: RL SETUP REQUEST, the Node-B recognizes that the maximum value of the MAC-d PDU size is 82 bytes (step 904), and sets the maximum value together with information about the 64QAM, MIMO and MAC-ehs (step 905).

After the HSDPA is established, flow control is initiated.

Here, it is assumed that the Node-B decides to adjust the size of the MAC-d PDU to a size less than 82 bytes in flow control due to radio channel congestion (step 908). The Node-B sets the maximum value of the MAC-d PDU size to a new value less than 82 bytes (step 909) and sends a control frame of the CAPACITY ALLOCATION OF THE TYPE 2 HS-DSCH that includes a IE Maximum Extended MAC-d PDU in Size in which the value has been set, at the RNC (step 910). This frame is a frame used for the Node-B to notify the RNC of control information about flow control. Examples of the control information in flow control include MAC-d / c PDU length, credits, and a transmission interval.

Since the size of the RLC PDU is set to a fixed length, the RNC cannot transmit data with a length less than the fixed length, resulting in data communication stopping (step 911).

An object of the present invention is to provide a technique that avoids a discrepancy in a state of adjustment, between devices, as to whether the size of the data in the data communication has a fixed length or a variable length in a system. of mobile communication.

Solution to the problem

This object is achieved by a control device according to claim 1, a base station device according to claim 4, a mobile communication system according to claim 8 and a communication control method according to claim 16; the dependent claims refer to further developments of the invention.

Brief description of the drawings

[Figure 1] Figure 1 is a table illustrating examples of adjusted parameters in respective HSDPA cases. [Figure 2] Figure 2 is a table illustrating parameters in the NBAP protocol.

[Figure 3] Figure 3 is a table illustrating an example communication mode to describe a flow control failure.

ES 2 632 397 T3

[Figure 4] Figure 4 is a diagram illustrating an example of a sequence that results in the occurrence of a flow control failure.

[Figure 5] Figure 5 is a block diagram illustrating a configuration of the RNC 11 according to a first example embodiment.

[Figure 6] Figure 6 is a block diagram illustrating a Node-B 12 configuration in accordance with the first example embodiment.

[Figure 7] Figure 7 is a block diagram illustrating a configuration of a mobile communication system according to a second example embodiment.

[Figure 8] Figure 8 is a sequence diagram illustrating an operation of a mobile communication system according to the second example embodiment.

[Figure 9] Figure 9 is a diagram to describe an overview of an NBAP protocol message.

[Figure 10] Figure 10 is a diagram illustrating an example of 3GPP TS 25.433 change.

[Figure 11] Figure 11 is a diagram illustrating an example of a TYPE 2 HS-DSCH DATA FRAME according to a third example embodiment.

[Figure 12] Figure 12 is a sequence diagram illustrating an operation of a mobile communication system in accordance with the third example embodiment.

[Fig. 13] Fig. 13 is a diagram illustrating an example of defining a HS-DSCH MAC-d PDU Size Format according to a fourth example embodiment.

Description of achievements

Exemplary embodiments will be described in detail with reference to the drawings, in which the following third to fifth embodiments are described as useful in understanding the invention, but do not form part of the invention. A radio communication system described as an example embodiment is a W-CDMA mobile communication system in accordance with 3GPP.

(First Execution of Example)

Figure 5 illustrates the configuration of the RNC 11 according to a first example embodiment.

As illustrated in Figure 5, the RNC 11 includes the communicator 11A that communicates with a base station device using a fixed-length data size and a variable-length data size, and the transmitter 11B that provides notification of (transmits) information indicating whether the data communication data size has a fixed length or a variable length to the base station device (Node-B 12).

Accordingly, in the present example embodiment, information notification may be provided indicating whether the data size of the data communication is fixed or variable (identification information) from the RNC 11 to the Node-B 12.

Figure 6 illustrates the configuration of Node-B 12 in accordance with the first example embodiment.

As illustrated in Figure 6, Node-B 12 includes receiver 12B that receives information indicating whether the data size of the data communication has a fixed length or a variable length from a control device (RNC 11), and the communicator 12A communicating with the control device using a fixed-length data size and a variable-length data size.

Accordingly, in the present exemplary embodiment, the Node-B 12 receives the information (the identification information) transmitted from the RNC 11, which makes it possible to avoid the occurrence of a discrepancy in the state of the adjustment between the devices, relative a whether the size of the transmission data in the data communication has a fixed length or a variable length.

(Second Example Embodiment)

Figure 7 is a block diagram illustrating the configuration of a mobile phone communication system in accordance with a second example embodiment. The present example embodiment is an embodiment of the RNC 11 configuration according to the first example embodiment illustrated in Figure 5 and the Node-B 11 configuration according to the first example embodiment illustrated in Figure 6. Referring to Figure 7, the mobile phone communication system according to the present example embodiment includes the RNC 11 and the Node-B 12. The RNC 11, which is connected to a CN (Core Network Node-B 11 (not illustrated), controls Node-B 12, providing user data communication

ES 2 632 397 T3 by means of a UE (not illustrated). The Node-B 12, which is connected to the UE (not illustrated) via a radio channel, repeats the user data between the UE and the RNC 11.

The mobile communication system enables data communication by means of HSDPA, and responds to the two cases where the data transmission data size of the downlink data using HSDPA has a fixed length and a variable length.

The RNC 11 provides a notification of (transmits) identifying information indicating whether the transmission data size of the downlink data is set to have a fixed length or a variable length to Node-B 12. A notification of this Identification information is provided by means of a message according to a call control protocol terminated by the RNC 11 and the Node-B 12. The message used for the notification of the identification information is a message sent from the RNC 11 to the Node-B 12 when a radio link is established, changed or added.

The Node-B 12 operates on the basis of the identification information provided by the RNC 11. For example, the Node-B 12 performs a data communication flow control based on the identification information. In flow control, the Node-B 12 adaptively changes a plurality of items according to the communication status, and notifies the RNC 11 about these items.

The RNC 11 transmits downlink data to Node-B 12 within the scope of the limitations imposed by the elements provided, and in accordance with a downlink data size format provided to Node-B 12 by identifying information (that is, if the transmission data size of the downlink data is a fixed length or a variable length). Consequently, the data quantity of the downlink data and the like can be suitably controlled according to the communication status, allowing for proper management of eg congestion.

Examples of items for flow control include a permitted transmission data size, a permitted data frame transmission interval, and the number of permitted data frame transmissions within a predetermined time period.

If the identification information provided by the RNC 11 indicates that the size of the transmission data has a fixed length, the Node-B 12 performs a flow control with fixing the size of the transmission data between these elements.

In the current example embodiment, the identification information may be, for example, one-bit information. More specifically, bit "1" indicates that the RLC PDU size is a variable length, and bit "0" indicates that the RLC PDU size is a fixed length.

According to the present example embodiment, a notification of the identification information indicating whether the size of the transmission data is set to a fixed length or to a variable length is provided from the RNC 11 to the Node-B 12, and the Node-B 12 operates on the basis of the identification information provided by the RNC 11, which makes it possible to avoid the occurrence of a discrepancy in the state of the setting between the devices as regards whether the size of the transmission data has a fixed length or a variable length.

Also, if a notification is provided as to whether the size of the transmission data is a fixed length or a variable length from RNC 11 to Node-B 12 when a radio link is established, Node-B 12 performs a flow control with the fixed transmission data size, based on the shared acknowledgment with the RNC 11, immediately after the establishment of the radio link. Similarly, if a notification is provided as to whether the size of the transmission data has a fixed length or a variable length when a radio link is changed or added, Node-B 12 can carry out flow control. with the fixed transmission data size, immediately after the change or addition of the radio link.

Referring to Figure 7 again, the RNC 11 includes the transmission path termination unit 19, the call controller 13 and the call control protocol processor 14, which are included in a control plane, the unit lu interface termination units 15, RLC protocol function units 16, MAC-d protocol function unit 17, and frame protocol function units 18, which are included in a user plane.

The call controller 13 performs various types of call control related processing. The call control includes call establishment when there is an outgoing call from the UE or an incoming call to the UE, and clearing the established call. Call control also includes the establishment and release of an HSDPA call by the UE. In call control, the call controller 13 transmits / receives call control messages to / from the Node-B 12, the UE or the CN.

Call control protocol processor 14 compiles and parses messages in accordance with the NBAP protocol, which is a call control protocol shared with Node-B 12, under the control of call controller 13.

ES 2 632 397 T3

For example, when an HSDPA communication is established, the call controller 13 transmits / receives an NBAP protocol message to / from the Node-B 12 through the call control protocol processor 14, to carry out the settings. for MIMO, 64QAM or MAC-ehs.

An Iu interface termination unit 15 terminates an Iu interface with the CN. More specifically, the Iu interface termination unit 15 provides, for example, functions of the PDCP (Packet Data Convergence Protocol) presented in document 3GPP TS 25.323, the user plane protocol Iu presented in document 3GPP TS 25.415 and the GTP-U protocol indicated in document 3GPP TS 29.060.

For an example of a downlink, the Iu interface termination unit 15 obtains RLC PDUs from a downlink signal received from the higher order CN through the Iu interface and transmits the RLC PDUs to the control units. RLC protocol function 16. For an uplink example, the Iu interface termination unit 15 transmits uplink data from the RLC protocol function units 16 to the CN via the Iu interface.

The RLC protocol function units 16 provide an RLC function presented in 3GPP TS 25,322. The RLC function is a function that performs various types of processing related to the control of a radio link. The RLC protocol function units 16 carry out the processing of data transmitted / received by the UE, according to the RLC protocol by means of the RLC function. Three types of modes are defined for an RLC transmission method. The first is the recognized mode (abbreviated here as RLC-AM (AM) Acknowledged Mode). The second is the unrecognized mode (RLC-UM (UM - UnAcknowledged Mode, in English)). The third is transparent mode (RLC-TM).

In RLC-AM mode, until 3GPP Version 6, the size of the RLC PDU (Protocol Data Unit) was a fixed length, and user data was segmented at the data layer. RLC.

However, in 3GPP Version 7, a feature called Enhanced Layer 2 has been introduced to HSDPA. For Node-B 12, the MAC-ehs protocol is used instead of the MAC-hs protocol. Instead of the data being segmented according to the RLC protocol at RNC 11, higher order data is segmented according to the MAC-ehs protocol at Node-B 12, allowing the provision of RLC data. -Flexible -AM with a variable length in addition to RLC-AM with a fixed length. In the case of variable length, data with a maximum RLC PDU size of 1503 octets is transmitted from RNC 11 to Node-B 12.

The MAC-d protocol function unit 17 implements the MAC-d protocol, which is one of the MAC functions presented in 3GPP TS 25,321. The MAC-d protocol is a part of the protocol for the MAC layer, and the whole protocol for the MAC layer includes this MAC-d protocol, and the MAC-hs protocol or the MAC-ehs protocol. The MAC-d protocol allows the multiplexing of a plurality of logical channels of the plurality of RLC protocol function units 16. However, no logical channel multiplexing is performed when Node-B 12 uses the MAC -ehs.

Frame protocol function units 18 implement an HS-DSCH frame protocol function presented in 3GPP TS 25,435. The HS-DSCH frame protocol is a protocol for carrying out the generation and segmentation of an HS-DSCH frame used in HSDPA. The frame protocol function units 18 in the RNC 11 generate downlink data frames.

In high speed data transmission using 64QAM or MIMO, TYPE 2 HS-DSCH DATA FRAME is used for the frame type. Accordingly, the frame protocol function units 18 generate data frames of TYPE 2 HS-DSCH DATA FRAME.

Also, the frame protocol function units 18 carry out the processing for controlling the flow between the frame protocol function units 18 and the frame protocol function units 23 at Node-B 12.

For example, when radio channel interference, insufficient transmission power and / or transmission path congestion are detected on the Iub interface, the frame protocol function units 23 at Node-B 12 transmit a CAPACITY ALLOCATION FROM TYPE 2 HS-DSCH to frame protocol function units 18 in RNC 11, thereby giving an instruction to suppress downlink data frame transmissions to RNC 11.

In contrast, when congestion, etc., has been alleviated, the frame protocol function units 23 at Node-B 12 transmit a TYPE 2 HS-DSCH CAPACITY ASSIGNMENT to the frame protocol function units. frame 18 at RNC 11, thereby giving permission to increase the downlink data frame transmissions to RNC 11.

Instructions for suppressing and increasing the downlink data frame are provided by prescribing MAC-d / c PDU Length, credits, or a transmission interval.

ES 2 632 397 T3

The frame protocol function units 18 in the RNC 11 transmit data of a TYPE 2 HS-DSCH DATA FRAME according to the MAC-d / c PDU Length, credits or a transmission interval provided by the TYPE 2 HS-DSCH CAPACITY ALLOCATION received from the frame protocol function units 23 at Node-B 12.

The transmission path termination unit 19 transmits / receives data in a format according to a transport bearer over a transmission path between the RNC 11 and the Node-B 12 (Iub interface) to / from the communication termination unit. transmission path 20 at Node-B 12. For the transport carrier, for example, ATM (Asynchronous Transfer Mode) or IP (Internet Protocol - Internet Protocol, in English) is used.

For example, where there are two packet services, there are logical channels for the respective packet services. In the MAC-d protocol function unit 17, those logical channels are not multiplexed, and thus, there are also transparent carriers for the respective packet services.

Referring to Figure 7 again, Node-B 12 includes transmission path termination unit 20, radio transmitter / receiver 25, NBAP protocol function unit 21, and call controller 22, which are included in one blueprint. control unit, frame protocol function units 23 and MAC-ehs protocol function unit 24, which are included in a user plane.

The transmission path termination unit 20 looks towards the transmission path termination unit 19 at the RNC 11 through the transmission paths (Iub interface) between the Node-B 12 and the RNC 11, and transmits / receives data in a format adapted for a transport bearer to / from the transmission path termination unit 19 at the RNC 11.

The NBAP protocol function unit 21 compiles and analyzes the NBAP protocol messages transmitted / received to / from the RNC 11 under the control of the call controller 22.

The call controller 22 performs various types of processing related to call control. In call control, the call controller 22 transmits / receives call control messages to / from the RNC 11 or the UE.

The frame protocol function units 23, facing towards the frame protocol function units 18 in the RNC 11, implement an HS-DSCH frame protocol function. More specifically, the frame protocol function units 23 receive a DATA FRAME TYPE 2 HS-DSCH DATA frame according to the HS-DSCH Frame Protocol from the frame protocol function units 18 in the RNC 11, get the MAC-d PDUs in the frame, and transmit the MAC-d PDUs to the MAC-ehs protocol function unit 24.

Also, as described above, the frame protocol function units 23 perform flow control processing between the frame protocol function units 23 and the frame protocol function units 18 in the RNC 11.

The MAC-ehs protocol function unit 24 segments data from the RNC 11 and transmits the segmented data to the UE through the radio transmitter / receiver 25. As a result of the MACehs protocol function unit 24 in the Node- B 12 performs data segmentation, inefficient padding at the RLC level in RNC 11 can be avoided.

The transmitter / receiver 25, which are connected to the UE via a radio channel, transmits / receives call control messages from the call controller 22 and user data from the MAC-ehs protocol function unit 24.

FIG. 8 is a sequence diagram illustrating an operation of the mobile phone communication system according to the second example embodiment. In the mobile phone communication system according to the present example embodiment, when a radio link is established, changed or added, a notification about whether the RLC PDU size has a fixed length or a variable length is provided from RNC 11 to Node-B 12. Figure 8 illustrates a sequence when establishing a radio link. Also, in this specification, a system operation is set from when a notification is provided about whether the RLC PDU size has a fixed length or a variable length from RNC 11 to Node-B 12 to when Node- B 12 performs flow control in accordance with the notification.

Referring to Figure 8, where the mode of the RLC is the RLC-AM mode, the call controller 13 in the RNC 11 first determines whether the size of the RLC PDU is fixed or variable (step 101).

If the RLC PDU size is fixed, the call controller 13 sets an RLC size flag indicating that the RLC PDU size has a "fixed length" in the RLC protocol function units 16 (step 102). The call controller 13 then adjusts the size of the RLC PDU as the size of

The MAC-d PDU is 2 632 397 T3 (step 103). In addition, the call controller 13 sets the RLC Size Flag to "fixed length" (step 104).

Meanwhile, it has been determined in step 101 that the size of the RLC PDU is variable, the call controller 13 sets an RLC size indicator indicating that the size of the RLC PDU has a "variable length" in the RLC protocol function units 16 (step 105). Next, the call controller 13 sets a maximum value of the RLC PDU size as the MAC-d PDU size (step 106). In addition, the call controller 13 sets the RLC size indicator to "variable length" (step 107).

Next, after step 104 or 107, the call control protocol processor 14 compiles a NBAP RL SETUP REQUEST message in which, for example, the use of MIMO and 64QAM is set, the flag of MAC-d PDU size and RLC size (step 108), and sends the message to NodeB 12 (step 109). This RLC size indicator allows a notification to be provided as to whether the RLC PDU size is a fixed length or a variable length from RNC 11 to Node-B 12.

Figure 9 is a diagram for describing an overview of an NBAP protocol message. Figure 9 indicates that an RLC PDU size indicator, which is a new parameter, is added to the information elements table in 3GPP TS 25.433 9.2.1.311A. Whether the RLC size has a fixed length or a variable length is set in this flag.

Upon receipt of the NBAP protocol message, the call controller 22 at Node-B 12 obtains the MAC-d PDU size of the message (step 110). The call controller 22 also obtains the RLC size indicator, and applies the value of the indicator to flow control in the frame protocol function units 23 (step 111). Also, the call controller 22 sets the information regarding, for example, whether or not the MAC-ehs protocol is used, in the MAC-ehs protocol function unit 24 (step 112).

The frame protocol function units 23, which carry out flow control, initiate flow control when, for example, radio channel congestion is detected (step 113). In flow control, the frame protocol function units 23 first check the RLC size indicator (step 114)

If the RLC PDU size is a fixed length, the frame protocol function units 23 control the other parameters by keeping the MAC-d PDU Length IE fixed (step 115). The frame protocol function units 23 limit, for example, the credits, the transmission interval or the repetition period without changing the MAC-d PDU Length IE, thereby solving the radio channel congestion.

Meanwhile, if it has been determined in step 114 that the RLC PDU size has a variable length, the frame protocol function units 23 control the different parameter classes including the MAC-d PDU Length IE ( step 116).

A flow control command of the frame protocol function units 23 is provided to the RNC 11 through a TYPE 2 HS-DSCH CAPACITY ALLOCATION message (step 117). The frame protocol function units 18 in the RNC 11 control the downlink data transmissions in accordance with the command from the frame protocol function units 23 in the Node-B 12 (step 118).

Since a sequence for the case where a radio link is established is illustrated herein, the RLC size indicator has been set in the NBAP RL SETUP REQUEST message. As another example, if a radio link is added, the RLC PDU size indicator may be set in an NBAP RL ADD REQUEST message. Also, if a radio link is changed, the RLC PDU size indicator can be set in an NBAP RL RECONFIGURATION PREPARE message or in an RL RECONFIGURATION REQUEST message.

According to the present example embodiment, even if the RLC PDU size is a fixed length, the acknowledgment at RNC 11 and acknowledgment at Node-B 12 are consistent with each other, allowing HSDPA communications using MAC-ehs protocol are performed favorably. In that case, the size of the RLC PDU is not adjusted to have a variable length in flow control, allowing the application of existing processing to the RLC protocol function units 16.

Furthermore, in the mobile phone communication system according to the present example embodiment, the MAC-ehs protocol can be used even if the RLC PDU size has a fixed length, allowing to maintain compatibility with a previous system. to 3GPP Version 7. For example, when a change is made to a serving cell as a result of the UE moving from an area covered by a Node-B prior to 3GPP Version 7 to an area covered by Node-B 12 according to the 3GPP Version 7 and later, the RLC PDU size can be kept at a fixed length. There is no need to reinitialize RLC processing, allowing reduction of data loss in higher order users (eg UE).

ES 2 632 397 T3

The RLC PDU size identifying information (RLC PDU size indicator) is used by Node-B 12 for a priority queue. For example, Node-B 12 performs flow control for each priority queue, using the identification information. The details of this example will be described below.

Node-B 12, when receiving downlink user data from RNC 11, evaluates Common Channel Priority Indicators (CmCH-PIs) in MAC-d PDU data , and assigns the MAC-d PDU data to the priority queues associated with the respective MAC-d PDU data. Herein, these CmCH-PIs are associated not only with priority queues at Node-B 12, but also with RLC PDU size identifying information. Therefore, the RLC PDU size identification information has an effect on the selection of a MAC-d PDU length (Maximum MAC-d / c PDU Length) in the flow control carried out. for each priority queue.

As described above, if the length of the MAC-d PDU has a variable length or a fixed length it can be selected for each priority queue, and thus, Node-B 12 can carry out flow control to each priority queue, in other words according to the associated priority (CmCH-PI).

A CmCH-PI corresponds to a Planning Priority Indicator via NBAP in Figure 9. A CmCH-PI is adjusted and updated by the RNC 11. A priority queue is a storage area (temporary memory) that temporarily stores data from RNC 11 downlink user. In each priority queue, QoS requirements are considered. Examples of QoS requirements include a traffic class and a peak rate.

An example of a change from 3GPP TS 25,433 concerning RLC PDU size identification information, that is, an RLC PDU size format in the above description is illustrated in Figure 10.

The above description in the present example embodiment has been given in terms of the case where the identification information is normally provided from the RNC 11 to the Node-B 12 via a control protocol message as a normal operation. However, for a real system, it is preferable to consider abnormal operation. An example of an operation in which there is an abnormality in the notification from the RNC 11 to the Node-B 12 as an abnormal operation will be indicated below.

When the identification information included in a message to request an establishment, change or addition of a communication link, which has been sent from the RNC 11 to the Node-B 12 indicates that the size of the transmission data has a variable length, if the message includes an information element indicating that the MAC-d PDU size has a fixed length or an information element indicating a maximum MAC-d PDU size, Node-B 12 cannot interpret the message normally. Therefore, the Node-B 12 sends a message to reject the establishment, change or addition of a communication link, to the RNC 11. Consequently, the request of the RNC 11 is rejected and the procedure is canceled.

Possible specific examples will be described below. When messages 1 to 3 are received, Node-B 12 detects an "abnormal condition", that is, abnormal setting, and rejects the RNC 11's request to cancel the procedure.

1. RL SETUP REQUEST message (1) If a RADIO LINK SETUP REQUEST message received from an RNC includes an information element, DL RLC PDU Size Format, for a default priority queue, in which the size of the RLC PDU has been adjusted to have a variable length and an information element, HS-DSCH MAC-d PDU Size Format that has a value indicating that the MAC-d PDU size has a fixed length, a Node-B transmits a RADIO LINK ESTABLISHMENT FAILURE message to reject the request procedure from the RNC, to the RNC.

(2) If a RADIO BINDING REQUEST message received from an RNC does not include an information element, Maximum Extended MAC-d PDU in Size, for a default priority queue, and an information element, DL RLC PDU size that has a value indicating that the RLC PDU size is variable in length, a Node-B transmits a RADIO LINK ESTABLISHMENT FAIL message to reject the request procedure from the RNC.

(3) If a RADIO BINDING REQUEST message received from an RNC includes an information element, the HS-DSCH MAC-d PDU Size Format, in which the MAC PDU size -d has been set to have a variable length, and does not include an information element, DL RLC PDU Size Format, a Node-B transmits a RADIO LINK ESTABLISHMENT FAILURE message to reject the procedure of request from the RNC.

two. RL ADD REQUEST message (1) If a RADIO LINK ADD REQUEST message received from an RNC includes a DL RLC PDU Size Format information element for a default priority queue, in which

ES 2 632 397 T3 the RLC PDU size has been adjusted to have a variable length, and an HS-DSCH MAC-d PDU Size Format information element has a value indicating that the size of the MACd PDU has a fixed length, a Node-B transmits a RADIO ADD FAILURE message to reject the request procedure from the RNC, to the RNC.

(2) If a RADIO LINK ADD REQUEST message received from an RNC does not include an Extended MAC-d PDU in Size information element for a default priority queue, and a device element Size Format of the DL RLC PDU has a value indicating that the RLC PDU size is variable in length, a Node-B transmits a RADIO LINK ADD FAILURE message to reject the request procedure from the RNC.

(3) If a RADIO BINDING ADD REQUEST message received from an RNC includes an HS-DSCH MAC-d PDU Size Format information element in which the MAC-d PDU size has been set to have a variable length, but does not include a DL RLC PDU Size Format information element, a base station transmits a RADIO LINK ADD FAILURE message to reject the RNC request procedure.

3. RL RECONFIGURATION REQUEST message

[1] In resetting a synchronous radio link:

(1) If there is a priority queue that is set so that the RLC PDU size has a variable length and is not set to use Maximum Extended MAC PDU in Size, in a new configuration, a Node- B transmits a RADIO LINK RECONFIGURATION REQUEST message to reject the request procedure from an RNC, to the RNC.

(2) If there is a priority queue in which the relevant Node-B Communication Context has been adjusted so that the MAC-d PDU size has a fixed length and the RLC PDU size has a fixed length. variable length, in a new configuration, a Node-B transmits a RADIO LINK RECONFIGURATION FAIL message to reject the request procedure from an RNC, to the RNC.

(3) If the relevant Node-B Communication Context has been adjusted so that the MAC-d PDU size has a variable length, and does not include an information element, RLC PDU Size Format of DL, for a predetermined priority queue in a new configuration, a Node-B transmits a RADIO LINK RECONFIGURATION FAIL message to reject the request procedure from an RNC, to the RNC.

[2] In the reestablishment of an asynchronous radio link:

(1) If there is a priority queue that has been adjusted so that the RLC PDU size has a variable length and has not been adjusted to use Maximum Extended MAC PDU in Size, in a new configuration, a Node-B transmits a RADIO LINK RECONFIGURATION FAIL message to reject the request procedure from an RNC, to the RNC, (2) If there is a priority queue for which the relevant Node-B Communication Context has been set so that the MAC-d PDU size has a fixed length and the RLC PDU size has a fixed length. variable length, in a new configuration, a Node-B transmits a RADIO LINK RECONFIGURATION FAIL message to reject the request procedure from an RNC, to the RNC.

(3) If the relevant Node-B Communication Context has been adjusted so that the MAC-d PDU size has a variable length, and does not include an information element, RLC PDU size format of DL, for a default priority queue in a new configuration, a Node-B transmits a RADIO LINK RECONFIGURATION FAIL message to reject the request procedure from an RNC, to the RNC.

In this specification, a Node-B Communication Context is a term defined in 3GPP, and refers to the data information (context) handled for each mobile phone device (UE).

(Third Example Realization)

In the second example embodiment described above, as illustrated in Figure 8, an example has been described in which a notification of an RLC size indicator is provided indicating whether the size of the RLC PDU has a fixed length or a variable length using an NBAP protocol message. A third exemplary embodiment will be described in terms of an example in which a spare bit is spread in a TYPE 2 HS-DsCH DATA FRAME according to the HS-DSCH frame protocol, which is defined in the TS 25,435, and notification of an RLC size indicator is provided by means of the bit.

ES 2 632 397 T3

The basic configuration of a mobile phone communication system according to the third example embodiment is similar to the system configuration according to the second example embodiment illustrated in Figure 7.

FIG. 11 is a diagram illustrating an example of a TYPE 2 HS-DSCH DATA FRAME according to the third example embodiment. Referring to Figure 11, an RLC size indicator is defined in the second bit from the highest order bit in the fourth octet.

FIG. 12 is a sequence diagram illustrating an operation of a mobile phone communication system in accordance with the third example embodiment. Referring to Figure 12, the call controller 13 in the RNC 11 first determines whether the size of the RLC PDU is fixed or variable (step 201). If the RLC PDU size is fixed, the call controller 13 sets an RLC size indicator indicating that the RLC PDU size is a "fixed length", in frame protocol function units 18 ( step 202). Meanwhile, if it has been determined in step 201 that the size of the RLC PDU is variable, the call controller 13 sets an RLC size indicator indicating that the size of the RLC PDU has a "variable length", in frame protocol function units 18 (step 202).

Subsequently, when transmitting a TYPE 2 HS-DSCH DATA FRAME data frame, the frame protocol function units 18 in the RNC 11 insert an RLC size indicator in the second bit from the highest order in the fourth byte of the frame (step 204).

When the data frame is received TYPE 2 HS-DSCH DATA FRAME, the frame protocol function units 23 at Node-B 12 obtain the RLC size indicator of the frame, and apply the value of the indicator to flow control (step 205).

The frame protocol function units 23 that carry out flow control, when, for example, radio channel congestion is detected, initiate flow control (step 206). In flow control, the frame protocol function units 23 first check the size indicator of the RLC (step 207).

If the RLC PDU size is a fixed length, the frame protocol function units 23 keep the MAC PDU Length IE fixed, and control the other parameters (step 208). For example, the frame protocol function units 23 limit credits, a transmission interval or a repetition period without changing the MAC-d PDU Length IE, thereby managing radio link congestion.

Meanwhile, if it has been determined in step 114 that the RLC PDU size has a variable length, the frame protocol function units 23 control the different parameter classes including the MAC-d PDU Length IE ( step 209).

A flow control command of the frame protocol function units 23 is provided to the RNC 11 by a TYPE 2 HS-DSCH CAPACITY ALLOCATION message (step 210). The frame protocol function units 18 at the RNC 11 control downlink data transmissions in accordance with the instruction of the frame protocol function units 23 at the Node-B 12 (step 211).

As described above, in accordance with the present example, the RNC 11 provides a notification of an RLC PDU size indicator to Node-B 12 via a TYPE 2 HS-DSCH DATA FRAME, and When receiving the TYPE 2 HS-DSCH DATA FRAME, the Node-B 12 dynamically manages the RLC PDU size indicator according to the notification through the frame. Thus, the present example allows dynamic control of whether the RLC PDU size has a fixed length or a variable length.

(Fourth Example Realization)

The above-described second example embodiment has been described in terms of an example in which an RLC size indicator is added to the HS-DSCH MAC-d stream information, as illustrated in Figure 9. It will be described a fourth exemplary embodiment in terms of an example in which "Fixed MAC-d PDU Size for MAC-ehs" is added as a new value of HSDSCH MAC-d PDU Size Format.

The basic configuration of a mobile phone communication system according to the fourth example embodiment is similar to the system configuration according to the second example embodiment illustrated in Figure 7.

FIG. 13 is a diagram illustrating an example of HS-DSCH MAC-d PDU Size Format definition according to the fourth example embodiment. Referring to Figure 13, the "Fixed MAC-d PDU Size for MAC-ehs" can be set as a value for the HS-DSCH MAC-d PDU Size Format.

ES 2 632 397 T3

For values ​​for HS-DSCH MAC-d PDU Size Format, 3GPP has already provided an ordered MAC-d PDU Size for MAC-hs and a Flexible MAC-d PDU Size for MAC-ehs. The present example embodiment is intended to introduce a new "Fixed MAC-d PDU Size for MAC-ehs" for MAC-ehs whose RLC PDU size has a fixed length.

According to the present example embodiment, when a HSDSCH MAC-d PDU Size Format for an HS-DSCH transport channel is set to "Flexible MAC-d PDU Size", the PDU sizes RLC for all MAC-d flows on the HS-DSCH transport channel have a variable length.

Also, when a HS-DSCH MAC-d PDU Size Format for an HSDSCH transport channel is set to "Fixed MAC-d PDU Size", the RLC PDU sizes for all flows MAC-d of the HS-DSCH transport channel have a fixed length.

The HS-DSCH MAC-d flow information used in the second example embodiment is an information element indicating a property of each logical channel mapped to a priority queue. The reporting of an RLC PDU size indicator by HS-DSCH MAC-d flow information has allowed the indication of whether the RLC PDU size has a fixed length or a variable length for each logical channel. In other words, logical channels whose RLC PDU sizes are of a fixed length and logical channels whose RLC PDU sizes are of variable length can be mixed.

Meanwhile, the HS-DSCH MAC-d PDU Size Format used in the fourth example embodiment is an information element designating a property of an HS-DSCH transport channel. A notification as to whether the RLC PDU size is a fixed length or a variable length by means of an HS-DSCH MAC-d PDU Size Format, a mix of logical channels whose RLC PDU sizes have a fixed length and logical channels whose RLC PDU sizes have a variable length, it is not allowed in an HS-DSCH transport channel.

According to the present example embodiment, whether the size of the RLC PDU has a fixed length or a variable length can be handled by the HS-DSCH transport channel, allowing simplification of the processing in the RNC 11 and the Node. -B 12 compared to the second example embodiment.

(Fifth Example Realization)

A fifth example embodiment will be described in terms of an example of a mobile phone communication system, which provides HSUPA (High Speed ​​Uplink Packet Access) communications, which are communication of high-speed uplink data, and that carry out a flow control of it.

In 3GPP Version 8, for HSUPA, the MAC-i / MAC-is protocol is introduced to make the RLC PDU size variable in length. In 3GPP, in addition to the MAC-i / MAC-is protocol, which is introduced in Version 8, the MAC-e / MAC-es protocol is defined.

The MAC-i / MAC-is protocol and the MAC-e / MAC-es protocol are mutually exclusive: only the MAC-i / MAC-is protocol or the MAC-e / MAC-es protocol is present in a UE. If the size of the RLC PDU is set to be variable length, it is necessary to use the MAC-i / MAC-is protocol.

Also, in the RRC protocol between an RNC and a UE, the RB Mapping Information (3GPP TS 25.331 document) allows notification about whether the RLC PDU size has a fixed length or a variable length, and, furthermore, in the case of a variable length, it allows the reporting of a minimum value and a maximum value of the RLC PDU size.

Meanwhile, the NBAP protocol between an RNC and a Node-B only allows the provision from the RNC to the Node-B of the notification of a maximum value of the MAC-d PDU size (IE Maximum Extended MAC-d PDU in Size) for each logical channel mapped in the MAC-d stream. Normally, no logical channel multiplexing is performed in the MAC-d protocol, and thus the size of the MAC-d PDU is the same as the size of the RLC PDU.

In general, in flow control in HSUPA communications, a method is used in which a Node-B schedules the uplink data transmissions from the UEs, and on the basis of the scheduling result, provides notification of the power that each UE is allowed to use (provides a grant (transmission grant)) to the UE. In this control, the power that a UE can use is indicated by a grant. The UE determines the amount of data that can be transmitted on an uplink, based on the grant provided.

In HSUPA communications, a Node-B can use MAC-1 / MAC-is, and can consider the maximum value of the RLC PDU size in its flow control. However, in the current NBAP protocol, it is impossible to report whether the size of the RLC PDU of each logical channel, to be multiplexed, has a fixed length or a variable length, and, if the size of the RLC PDU has a variable length, it is impossible to report the smallest value of the

ES 2 632 397 T3 RLC PDU size. Consequently, a state discrepancy regarding the size of the RLC PDU occurs between a Node-B, an RNC, and a UE, which may result in it being impossible for the Node-B to adequately provide a grant to the UE.

If a grant provided by a Node-B to a UE is less than a value corresponding to the fixed length of the RLC PDU size, the UE cannot transmit data to the uplink. Also, even if the RLC PDU size has a variable length, a grant provided by a Node-B to a UE is less than a value corresponding to the smallest value of the RLC PDU size, the UE cannot transmit either. data to the uplink.

Also, there are cases where only a small advantage can be provided by sizing the RLC PDU to have a variable length, such as the control signals (DCCH: Dedicated Control Channel Channel). Therefore, in some cases, it is preferable that the RLC PDU size of user data in a packet service is adjusted to have a variable length while the RLC PDU size of a control signal is adjusted to have a fixed length. In those cases, for a control signal, it is preferable to use MAC-i / MAC-is while the RLC PDU size is adjusted to have a fixed length; however, in the current NBAP, notification of such an adjustment cannot be provided.

Therefore, in the present example embodiment, in a mobile phone communication system providing HSUPA, an RNC notifies a Node-B about whether the RLC PDU size is a fixed length or a variable length and , if the RLC PDU size has a variable length, also a minimum value of the RLC PDU size.

When the notification is received from the RNC, the Node-B determines that a grant is provided to a UE in control of the HSUPA flow, according to the determination based on whether the size of the RLC PDU has a fixed length or a variable length. Also, if the size of the RLC PDU has a variable length, the Node-B, if the size of the RLC PDU has a variable length, determines that the grant is provided to the UE considering the minimum value of the PDU size RLC provided by the RNC.

More specifically, for example, the Node-B provides the UE with a sufficient grant for data transmission with an RLC PDU size that is greater than the minimum value of the RLC PDU size in order to avoid the occurrence of an event in which the UE to which the grant has been provided cannot transmit data.

The mobile phone communication system according to the present example is similar to the system according to the second example embodiment illustrated in Figure 7 including the rNc 11 and the Node-B 12. However, since the present example embodiment focuses on uplink data communications, the MAC-d protocol function unit 17 and the MAC-ehs protocol function unit 24 are not necessary, and therefore rather, a protocol function unit is needed that implements the MAC-i protocol and the MAC-is protocol.

As a basic operation of the RNC 11 in the mobile phone communication system according to the present example, the call controller 13 in the RNC 11 determines whether the size of the RLC PDU is fixed or variable. The call control protocol processor 14 compiles an NBAP protocol message in which information regarding the size of the RLC PDU is set, for example, whether the size of the RLC PDU is a fixed length or a variable length and in the case of a variable length, a minimum value, and transmit the NBAP protocol message to Node-B 12. At these points, a system operation according to the present example is similar to a system operation according to the second example embodiment.

Also, as a basic operation of the Node-B 12, when an NBAP protocol message is received, the call controller 22 obtains information regarding the size of the RLC PDU of the message, and the flow controllers apply the information to the control of the message. flow. At this point, the operation of the system according to the present example embodiment is similar to the operation of the system according to the second example embodiment. However, since the flow control in the present example embodiment is a control over the uplink data transmitted from the UEs, the flow control by the Node-B 12 is directed to the UEs. More specifically, the notification of a flow control command is provided to each UE as a provision of a grant as described above.