WO2011132413A1 - 基地局、移動局、協調移動局、送信方法及び受信方法 - Google Patents

基地局、移動局、協調移動局、送信方法及び受信方法 Download PDF

Info

Publication number
WO2011132413A1
WO2011132413A1 PCT/JP2011/002313 JP2011002313W WO2011132413A1 WO 2011132413 A1 WO2011132413 A1 WO 2011132413A1 JP 2011002313 W JP2011002313 W JP 2011002313W WO 2011132413 A1 WO2011132413 A1 WO 2011132413A1
Authority
WO
WIPO (PCT)
Prior art keywords
mobile station
information
originating
cooperative
resource
Prior art date
Application number
PCT/JP2011/002313
Other languages
English (en)
French (fr)
Inventor
ホァンレイ
吉井勇
今村大地
Original Assignee
パナソニック株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by パナソニック株式会社 filed Critical パナソニック株式会社
Priority to US13/638,729 priority Critical patent/US9031022B2/en
Priority to JP2012511551A priority patent/JP5669827B2/ja
Priority to CN201180017170.5A priority patent/CN102860119B/zh
Publication of WO2011132413A1 publication Critical patent/WO2011132413A1/ja
Priority to US14/632,382 priority patent/US9380572B2/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/12—Wireless traffic scheduling
    • H04W72/121—Wireless traffic scheduling for groups of terminals or users
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/20—Control channels or signalling for resource management
    • H04W72/23—Control channels or signalling for resource management in the downlink direction of a wireless link, i.e. towards a terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/30—Resource management for broadcast services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H04W88/04—Terminal devices adapted for relaying to or from another terminal or user

Definitions

  • the present invention relates to a base station, a mobile station, a cooperative mobile station, a transmission method, and a reception method that perform client cooperative operation.
  • IEEE 802.16 Working Group is developing an 802.16m radio interface specification that meets the requirements of IMT (International Mobile Telecommunications)-Advanced Next Generation Mobile Phone System is there.
  • IMT International Mobile Telecommunications
  • WiMAX Worldwide Interoperability for ⁇ Microwave Access
  • MSP Mobile System Profile
  • PICS Protocol Implementation Conformance Statement
  • the IEEE 802.16 working group has started the conceptual design of the future 802.16 / WiMAX network that exceeds 802.16m / WiMAX2.0.
  • Future 802.16 / WiMAX networks will support the explosive growth of mobile data traffic spurred by large screen devices, multimedia applications and even more connected users and devices. There is a common perception among the 802.16 / WiMAX community.
  • the future 802.16 / WiMAX network will operate efficiently in cooperation with other wireless technologies such as 802.11 / Wi-Fi (Wireless Fidelity).
  • the future 802.16 / WiMAX network will be significantly improved compared to the 802.16m network in terms of various performance index values such as throughput and SE (Spectral Efficiency). For example, assuming coverage in an urban area, the future 802.16 / WiMAX network is 2 of the 802.16m / WiMAX 2.0 network in both UL (Uplink) and DL (Downlink). Double SE is the target at the cell edge (see, for example, Non-Patent Document 2).
  • the 802.16m / WiMAX 2.0 network has an SE cell edge of DL at a cell edge of at least 0.06 bps / Hz / second in a 4'2 antenna configuration and a cell edge of UL of at least 0.03 bps / Hz / second in a 2'4 antenna configuration. Note that we have an SE at
  • CLICO Client Collaboration
  • SE Service Call Identity
  • network overall energy efficiency at the cell edge of a wireless communication system.
  • CliCo is a technology in which clients communicate with each other in a wireless environment to transmit / receive data jointly (see, for example, Non-Patent Document 3).
  • client clustering and peer-to-peer communication are used to transmit / receive information between a BS and a client via multiple paths.
  • SE at the cell edge can be improved without increasing the equipment cost.
  • the battery of a client having a poor channel can be made longer.
  • FIG. 1 is a diagram illustrating a typical wireless communication system 100 that performs CliCo.
  • the wireless communication system 100 employs a configuration including a BS (Base Station, base station) 102 and a plurality of MSs (Mobile Station, mobile stations) of the MS 104 and the MS 106, for example.
  • BS Base Station, base station
  • MSs Mobile Station, mobile stations
  • FIG. 1 A block diagram illustrating a typical BS 102 is shown in FIG.
  • the BS 102 is equipped with only a WiMAX communication function, and includes a WiMAXWPHY block 130 and a WiMAX MAC block 120.
  • the WiMAX MAC block 120 executes a WiMAX OFDMA (Orthogonal Frequency Division Multiple Access) -based medium access control (Media Control: MAC) protocol.
  • the WiMAX PHY block 130 executes a WiMAX OFDMA based physical layer protocol under the control of the WiMAX MAC block 120.
  • the WiMAX MAC block 120 further includes a control unit 122, a scheduler 124, a message generation unit 126, and a message processing unit 128.
  • the control unit 122 controls general MAC protocol operations.
  • the scheduler 124 schedules resource allocation to each MS under the control of the control unit 122.
  • the message generator 126 receives the resource allocation scheduling information from the scheduler 124, the message generator 126 generates a data packet and DL control information.
  • the message processing unit 128 analyzes data packets and UL control information received from a plurality of MSs under the control of the control unit 122, and reports the analysis results to the control unit 122.
  • the data packet and DL control information generated by the message generator 126 are transmitted by the BS 102 to multiple MSs via an OFDMA transmitter (not shown in FIG. 2) in the WiMAX PHY block 130.
  • Data packets and UL control information analyzed by the message processor 128 are received by the BS 102 via an OFDMA receiver (not shown in FIG. 2) in the WiMAX PHY block 130.
  • the message generation unit 126 includes an HFBCH (HARQ feedback channel) generation unit 132 and a resource allocation generation unit 134.
  • HARQ represents a hybrid automatic repeat request (Hybrid Automatic Repeat Request).
  • the HFBCH generation unit 132 generates a HARQ feedback channel for UL data transmission that notifies HARQ feedback information (for example, ACK / NACK) for UL data transmission.
  • the resource allocation generation unit 134 generates resource allocation control information for UL / DL data transmission that notifies resource allocation information to each of a plurality of MSs.
  • the resource allocation control information generated by the resource allocation generating unit 134 includes group configuration (Group Configuration) information and HFBCH index information for GRA transmission in DL / UL. Including group resource allocation information.
  • the HFBCH generated by the HFBCH generation unit 132 may include HARQ feedback information for the UL GRA transmission.
  • an HFBCH analysis unit 136 exists in the message processing unit 128.
  • the HFBCH analysis unit 136 analyzes the received HFBCH for DL data transmission and determines whether or not the corresponding DL data transmission is successful. From the viewpoint of GRA, the HFBCH analysis unit 136 can derive HARQ feedback information for GRA transmission in DL from the received UL control information.
  • FIG. 1 A block diagram illustrating a typical MS 104 is shown in FIG.
  • the MS 104 is equipped with a communication function based on both WiMAX and Wi-Fi, and includes a WiMAX PHY block 142, a Wi-Fi PHY block 144, a WiMAX MAC block 146, a Wi-Fi MAC block 148, and a GLL (Generic Link Layer) block 150.
  • Consists of The WiMAX MAC block 146 executes a WiMAX OFDMA based MAC (medium access control) protocol.
  • the WiMAX PHY block 142 executes a WiMAX OFDMA based physical layer protocol under the control of the WiMAX MAC block 146.
  • the Wi-Fi MAC block 148 executes a Wi-Fi CSMA / CA (Carrier Sense Multiple Multiple Access with Collision Avoidance) based MAC (medium access control) protocol.
  • the Wi-Fi PHY block 144 executes a physical layer protocol based on Wi-Fi OFDM (Orthogonal Frequency Division Multiplexing) / DSSS (Direct SequencetSpread Spectrum) under the control of the Wi-Fi MAC block 148.
  • the GLL block 150 functions to manage the cooperative operation between different types of WiMAX links and W-Fi links.
  • the WiMAX MAC block 146 further includes a control unit 154, a message generation unit 152, and a message processing unit 156.
  • the control unit 154 controls general MAC protocol operations.
  • the message generator 152 generates UL control information and data packets under the control of the controller 154.
  • the message processing unit 156 analyzes the data packet and DL control information received from the BS 102 under the control of the control unit 154 and supplies the analysis result to the control unit 154.
  • the data packets and UL control information generated by the message generator 152 are transmitted from the MS 104 to the BS 102 via an OFDMA transmitter (not shown in FIG. 3) in the WiMAX PHY block 142.
  • Data packets and DL control information analyzed by the message processor 156 are received by the MS 104 via an OFDMA receiver (not shown in FIG. 3) in the WiMAX PHY block 142.
  • the message processing unit 156 includes a resource analysis unit 151 and an HFBCH analysis unit 153.
  • the HFBCH analysis unit 153 analyzes the received HFBCH for data transmission in the UL and determines whether or not the corresponding UL data transmission is successful.
  • the resource analysis unit 151 analyzes the received resource allocation control information and derives the resource allocation information specified for the MS 104.
  • the data packet generated by the message generator 152 under the control of the controller 154 is then transmitted from the MS 104 to the BS 102 according to the derived resource allocation information.
  • the data packet transmitted from the BS 102 to the MS 104 is then received by the MS 104 according to the derived resource allocation information.
  • the resource analysis unit 151 in the message processing unit 156 includes, from the received resource allocation control information, group resource information including group configuration information and HFBCH index information for GRA transmission in DL / UL. Assignment information may be derived.
  • the HFBCH analysis unit 153 can derive HARQ feedback information for the GRA transmission in the UL from the received HFBCH.
  • the message generation unit 152 includes an HFBCH generation unit 155.
  • the HFBCH generation unit 155 generates a HARQ feedback channel including HARQ feedback information for data transmission in DL. From the viewpoint of GRA, the HFBCH generation unit 155 may generate a HARQ feedback channel for the GRA transmission in the DL.
  • FIG. 1 A block diagram illustrating a typical MS 106 is shown in FIG.
  • the MS 106 is also equipped with a communication function based on both WiMAX and Wi-Fi, and has the same configuration and functionality as the MS 104.
  • the main difference between the MS 104 and the MS 106 is that, unlike the MS 106, there is a scheduler 158 in the Wi-Fi MAC block 148 of the MS 104, as shown in FIG. Used for operation scheduling.
  • the BS 102 communicates with the MS 104 via the WiMAX links 108a and 108b, and communicates with the MS 106 via the WiMAX links 110a and 110b.
  • MS 104 communicates with MS 106 via peer-to-peer Wi-Fi links 112a, 112b. Further, the MS 104 may communicate with the MS 106 via other wireless technologies such as WiMAX, Bluetooth, or 60 GHz mmW (millimeter wave), if available.
  • CliCo can be implemented in both DL and UL of the wireless communication system 100.
  • the operation of the CLIO in the UL in the wireless communication system 100 will be described below.
  • the MS 104 can start a CLIo procedure in the UL such as neighbor search and collaborator selection / allocation. If the signal quality of the WiMAX link 110a between the BS 102 and the MS 106 is good, the MS 104 can select the MS 106 as a collaborator. In the context of CliCo, MS 104 is called the originating MS and MS 106 is called the collaborative MS.
  • CliCo can occur in a variety of situations. For example, if the originating MS 104 is in the back of the cafeteria, then the signal quality of the WiMAX link to the originating MS 104 can be very poor. On the other hand, if the collaborative MS 106 is very close to the cafeteria window or entrance compared to the originating MS 104, the collaborative MS 106 may have a much better WiMAX link signal quality than the originating MS 104.
  • FIG. 5 is a diagram illustrating a typical frame configuration 200 that can be applied to the wireless communication system 100 that performs CliCo shown in FIG.
  • each of the frame 202 and the frame 212 includes 8 subframes. Five of them are DL subframes, and the other are UL subframes.
  • the BS 102 presents control information to a plurality of mobile stations connected to the BS 102, including the originating MS 104 and the cooperative MS 106 involved in the CLIo. 220 can be transmitted.
  • the MAP 220 includes a plurality of MAPMIEs (Information Elements). A part of the MAP IE can notify HARQ feedback information for UL data transmission, and a part of the MAP IE can notify resource allocation information for DL / UL data transmission.
  • One MAP IE in MAP 220 that notifies HARQ feedback information forms one HBFCH for UL data transmission.
  • the originating MS 104 and the coordinating MS 106 each set the MAP 220 to obtain respective resource allocation information including HFBCH index information. Decryption is required.
  • the originating MS 104 also needs to send a UL data burst 250 to the collaborating MS 106 via the peer-to-peer Wi-Fi link 112a.
  • the originating MS 104 If the originating MS 104 has successfully decoded the MAP 220 sent by the BS 102 over the WiMAX link 108b, then the originating MS 104 will follow the received resource allocation information in the first UL subframe 206 of the frame 202 in the WiMAX link. UL data burst 250 is transmitted to BS 102 via 108a.
  • the coordinating MS 106 has successfully decoded the MAP 220 sent by the BS 102 over the WiMAX link 110b, and received the UL data burst 250 sent by the originating MS 104 over the peer-to-peer Wi-Fi link 112a.
  • the collaborative MS 106 simultaneously transmits the same UL data burst 250 to the BS 102 via the WiMAX link 110a according to the received resource allocation information.
  • the BS 102 can combine two copies of the UL data burst 250 received from the WiMAX link 108a and the WiMAX link 110a to improve the quality of the received signal.
  • the BS 102 can transmit the MAP 240 to a plurality of mobile stations connected to the BS 102, including the originating MS 104 and the cooperative MS 106 involved in CliCo.
  • the HFBCHs that are part of the MAP 240 may inform HARQ feedback information for the UL data burst 250 transmitted by the originating MS 104 and the cooperative MS 106 during the first UL subframe 206 of the frame 202.
  • the originating MS 104 and the collaborating MS 106 obtain their respective HFBCH index information obtained by decoding the MAP 220 during the period 208. Accordingly, in order to obtain HARQ feedback information for UL data burst 250, the corresponding HFBCHs in MAP 240 need to be decoded respectively.
  • the HARQ feedback information indicates that the BS 102 has not successfully decoded the UL data burst 250 transmitted by the originating MS 104 and the cooperative MS 106 during the first UL subframe 206 of the frame 202, the first UL of the frame 212 During subframe 216, originating MS 104 and cooperating MS 106 may need to retransmit UL data burst 250.
  • future 802.16 / WiMAX networks must support explosive mobile data traffic. Furthermore, the future 802.16 / WiMAX network should improve the quality of experience of mobile communication Internet applications such as VoIP (Voice over Internet Protocol). Considering that VoIP has a periodic traffic pattern and a relatively fixed payload size, for example, PA (Persistent Allocation) and GRA, in order to improve the quality of VoIP experience, A PHY / MAC mechanism was designed. In the present invention, the application of GRA to CliCo is taken up.
  • the GRA mechanism defined in the IEEE 802.16m draft standard does not support CliCo. However, the GRA mechanism can easily accommodate CliCo.
  • the GRA mechanism allocates resources to multiple users as a group in order to save control overhead. This resource allocation is in units of transport flow.
  • the method of applying GRA to CliCo consists of two operations. That is, i) BS 102 adds each flow of originating MS 104 and cooperative MS 106 to a group, or deletes each flow of originating MS 104 and cooperative MS 106 from a group. ii) The BS 102 allocates resources to the flows of the originating MS 104 and the cooperative MS 106 in the same group.
  • the BS 102 when adding the flow of the originating MS 104 (or collaborative MS 106) to a group, the BS 102 receives the group configuration information in the unicast MAC control message. To the originating MS 104 (or collaborative MS 106). When allocating resources to the respective flows of the originating MS 104 and / or the collaborative MS 106 in the same group, the BS 102 transmits group resource allocation information including HFBCH index information to the originating MS 104 and the collaborating MS 106 by multicast MAPMIE. Note that the group configuration information transmitted in the unicast MAC control message and the group resource allocation information transmitted in the multicast MAPMIE are generated by the message generator 126 shown in FIG.
  • the group configuration information transmitted in the unicast MAC control message is the group resource allocation information transmitted in the corresponding multicast MAP IE. Can be used to interpret.
  • the contents of the group configuration information include the following. ⁇ Flow identifier, -User bitmap size, ⁇ UBI (User Bitmap Index), ⁇ Group identifier, ⁇ Allocation periodicity, ⁇ MIMO (Multiple Input Multiple Output) mode set (MIMO mode set), etc.
  • the flow identifier is used to notify the MS which of the MS flows are added to the group, and has a size of 4 bits.
  • the user bitmap size indicates the number of bits used for the user bitmap transmitted in the multicast MAP IE.
  • the user bitmap size takes one of 4 bits, 8 bits, and 32 bits.
  • UBI indicates the index of the flow of the MS in the user bitmap and has a size of 5 bits.
  • the group identifier uniquely identifies the DL / UL group to which the MS flow is added and has a size of 12 bits.
  • the allocation period specifies the frequency with which the multicast MAP IE that notifies the corresponding group resource allocation information is transmitted, and the period may be one of one frame, two frames, four frames, and eight frames.
  • the MIMO mode set conveys the supported MIMO modes within the group.
  • the main difference between the group configuration information for the originating MS 104 and the cooperative MS 106 is that the UBIs of the originating MS 104 and the cooperative MS 106 are different. Furthermore, since group configuration information is unicast to originating MS 104 and collaborative MS 106, collaborative MS 106 does not know the UBI of originating MS 104, and vice versa.
  • the group configuration information may further include a set of four HARQ burst sizes.
  • a set of 4 HARQ burst sizes may be ⁇ 6 bytes, 8 bytes, 9 bytes, 10 bytes ⁇ .
  • the burst size is the size of the encoded packet that can be divided into multiple FEC (Forward Error Correction) blocks. Burst size may include the addition of CRC (Cyclic Redundancy Code) per burst and / or FEC block where applicable.
  • the group configuration information may include 8 resource sizes.
  • a set of 8 resource sizes can be ⁇ 1 LRU, 2 LRUs, 3 LRUs, 4 LRUs, 5 LRUs, 6 LRUs, 7 LRUs, 8 LRUs ⁇ .
  • LRU represents a logical resource unit (Logical Resource Unit).
  • the set of 8 resource sizes may be different or the same as the 9 byte HARQ burst size There is also.
  • FIG. 6 is a diagram illustrating a typical bitmap for notifying some group resource allocation information according to the IEEE 802.16m draft standard [1]. There are two bitmaps used to notify some group resource allocation information. One is a user bitmap 302 and the other is a resource allocation bitmap 304.
  • the user bitmap 302 uses one bit per flow to convey which flows are scheduled for the current frame. .
  • the first bit of user bitmap 302 is referred to.
  • UBI of cooperative MS 106 is “00011”
  • the fourth bit of user bitmap 302 is referred to. Accordingly, the respective flows (corresponding to data) of both the originating MS 104 and the cooperative MS 106 are indicated by the resource allocation bitmap 304 and transmitted in the current frame.
  • the resource allocation bitmap 304 has a configuration including a plurality of 5-bit resource allocation instructions, and each resource allocation instruction corresponds to a specific scheduled flow.
  • each 5-bit resource allocation indication the first 2 bits are used to convey the HARQ burst size and the last 3 bits are used to convey the resource size.
  • the HARQ burst size is selected from four burst size types ⁇ 6 bytes, 8 bytes, 9 bytes, 10 bytes ⁇ , and is “00”, “01”, “10”, “11”. ".
  • both HARQ burst sizes are 9 bytes.
  • the resource sizes of originating MS 104 and collaborative MS 106 are indicated by “111” and “001”, respectively.
  • the resource sizes of originating MS 104 and collaborative MS 106 can be 8 LRUs and 2 LRUs, respectively.
  • Non-Patent Document 1 in addition to the user bitmap 302 and the resource allocation bitmap 304, when multiple MIMO modes are supported in a group, Other bitmaps called can be used.
  • Table 1 shows a table illustrating a typical GRAGMAP IE for transmitting group resource allocation information according to the IEEE 802.16m draft standard (see Non-Patent Document 1, for example).
  • the HFBCH index for a scheduled flow within a group is a predetermined function of its UBI and the HFA offset shown in Table 1. is there.
  • each of the originating MS 104 and the cooperative MS 106 can calculate the HFBCH index of its own device based on its own UBI after decoding the GRA MAP IE shown in Table 1.
  • FIG. 7 shows a flowchart illustrating a method 400 in which the originating MS 104 (or the cooperative MS 106) receives resource allocation information in the IEEE 802.16m draft standard (see, for example, Non-Patent Document 1).
  • Method 400 begins at step 402.
  • step 404 originating MS 104 (or collaborative MS 106) checks the user bitmap against its UBI.
  • step 406 originating MS 104 (or collaborative MS 106) determines whether its flow is scheduled in the current frame. If the flow of the originating MS 104 (or collaborative MS 106) is scheduled in the current frame, in step 408, the originating MS 104 (or collaborative MS 106) then derives its own HARQ burst size and resource size. Therefore, the resource allocation bitmap is checked against its own UBI.
  • step 410 originating MS 104 (or cooperative MS 106) calculates its own HFBCH index according to its own UBI. If, at step 406, the originating MS 104 (or collaborative MS 106) flow is not scheduled for the current frame, the method 400 ends at step 412.
  • IEEE P802.16m / D5 DRAFT Amendmentendto IEEE Standard for local and metropolitan area networks-Part 16: Air Interface for Broadband Wireless Access Systems-Advanced Air Interface IEEE C802.16-10 / 0016r1, Future 802.16 Networks: Challenges and Possibilities IEEE C802.16-10 / 0005r1, Client Cooperation, Future, Wireless, Broadband, Networks
  • both the originating MS 104 and the collaborative MS 106 involved in CliCo process the same data burst. It is sufficient if there is one HFBCH used for both the originating MS 104 and the collaborative MS 106. However, because the UBI is different in the same group, the originating MS 104 and the cooperative MS 106 have two different HFBCHs. This wastes valuable HFBCH resources.
  • An object of the present invention is to use a single HBCH for a plurality of MSs that process the same data burst, thereby avoiding unnecessary wasting of HFBCH resources, a base station, a mobile station, a cooperative mobile station, It is to provide a transmission method and a reception method.
  • a base station (BS) that communicates with a plurality of mobile stations (MSs) includes a control signal generation unit that generates a control signal indicating resource allocation information for each of the plurality of MSs, and the plurality of the plurality of mobile stations (MSs).
  • the control signal for a certain mobile station (MS) includes information related to another MS.
  • the BS communicates with a plurality of MSs including an originating MS and a cooperative MS utilized for communication between the BS and the originating MS, and for each of the plurality of MSs
  • a control signal generation unit that generates a control signal indicating resource allocation information and a transmission unit that transmits the control signal to the plurality of MSs are provided, and the control signal for the cooperative MS includes information on the originating MS.
  • the control signal for the cooperative MS when the flow of the cooperative MS is added to the same group as the originating MS, includes information regarding the originating MS.
  • the information regarding the originating MS is included in the resource allocation information for the cooperative MS.
  • the information on the originating MS is replaced with the burst size information for the cooperative MS.
  • the number of bits of information related to the originating MS varies depending on the number of MSs belonging to the same group as the originating MS.
  • the number of bits of burst size information for the cooperative MS increases according to the number of MSs belonging to the same group as the originating MS
  • the number of bits of size information decreases, the number of bits of information regarding the originating MS changes.
  • the actual resource size of the cooperative MS is the resource size of the originating MS and the nominal resource of the cooperative MS. • Obtained as a result of bit size operation.
  • the resource size of the cooperative MS is the same as the resource size of the originating MS, and the information regarding the originating MS includes burst size information and resource size information for the cooperative MS. Is replaced.
  • the actual resource size of the collaborative MS is obtained as a result of a bit unit calculation of the resource size of the originating MS and the nominal resource size of the collaborative MS.
  • the resource size of the cooperative MS is set to a predetermined value, and the information on the originating MS is replaced with burst size information and resource size information for the cooperative MS.
  • the information regarding the originating MS is identification information of the originating MS.
  • the information regarding the originating MS is an offset of the identifying information of the originating MS relative to the identifying information of the cooperative MS.
  • a MS receives a control signal for its own device including information related to another MS, a transmission resource according to the control signal, and the information related to the other MS.
  • the resource calculation part which calculates is provided.
  • the cooperative MS used for communication between the BS and the originating MS is a receiving unit that receives a control signal for the local cooperative MS including information related to the originating MS, the control signal And a resource calculation unit that calculates transmission resources according to information on the originating MS, and a transmission unit that transmits a signal received from the originating MS to the BS via the transmission resource.
  • the transmitting unit stops transmitting the signal to the BS.
  • the transmitting unit when the information regarding the originating MS indicates the identification information of the cooperative MS, transmits the signal to the BS during a predetermined period or a configurable period. Stop sending
  • a part of the information regarding the originating MS is included in the resource allocation information for the cooperative MS, and the other part of the information regarding the originating MS is transmitted to the cooperative MS. • Included in configuration information.
  • a transmission method executed in a BS communicating with a plurality of MSs generates a control signal indicating resource allocation information for each of the plurality of MSs, and controls the plurality of MSs to perform the control.
  • a control signal for one MS that transmits a signal includes information about another MS.
  • the method generates a control signal indicating resource allocation information for each of the plurality of MSs, transmits the control signal to the plurality of MSs, and the control signal for the cooperative MS includes information regarding the originating MS.
  • a reception method executed in an MS receives a control signal for the own device including information related to another MS, and transmits transmission resources according to the control signal and the information related to the other MS. Is calculated.
  • a reception method executed in a cooperative MS used for communication between a BS and an originating MS receives a control signal for the own device including information on the originating MS.
  • the transmission resource is calculated according to the control signal and the information related to the originating MS, and the signal received from the originating MS is transmitted to the BS via the transmission resource.
  • the present invention uses one HBCH for a plurality of MSs that process the same data burst, unnecessary HFBCH resource waste can be avoided.
  • FIG. 1 which shows an example of the radio
  • Block diagram showing an example of a BS (base station) Block diagram showing an example of an originating MS (mobile station)
  • the figure which shows an example of the bitmap which notifies some group resource allocation information by a prior art Flowchart illustrating a method for receiving group resource allocation information at an originating MS (or cooperating MS) according to the prior art.
  • the flowchart which illustrates the method to receive group resource allocation information in the MS which cooperates concerning Embodiment 1 of this invention
  • the flowchart which illustrates the method of receiving group resource allocation information in cooperating MS in the case of a 4-bit user bitmap according to Embodiment 2 of the present invention
  • the figure which shows an example of a bitmap in order to notify some group resource allocation information in the case of the 8-bit user bitmap which concerns on Embodiment 2 of this invention.
  • the flowchart which illustrates the method which receives group resource allocation information in the MS which cooperates in the case of the 8-bit user bitmap which concerns on Embodiment 2 of this invention.
  • the figure which shows an example of the bit map for notifying some group resource allocation information in the case of the 32-bit user bit map which concerns on Embodiment 2 of this invention.
  • the flowchart which illustrates the method of receiving group resource allocation information in cooperating MS in the case of the 32-bit user bitmap according to Embodiment 2 of the present invention
  • the figure which shows an example of the bitmap for notifying some group resource allocation information in the case of the 4-bit user bitmap which concerns on Embodiment 3 of this invention.
  • the basic concept of the method of applying GRA to CliCo according to FIG. 1 is that the BS 102 uses the group configuration information to transfer the UBI of the originating MS 104 to the collaborative MS 106. It is to share. More specifically, when the BS 102 adds the collaborative MS 106 flow to the group, the group configuration information unicast by the BS 102 to the collaborative MS 106 also includes the originating MS 104 UBI. The contents of the group configuration information unicast to the collaborative MS 106 by the BS 102 can be listed below. The flow identifier of the collaborative MS 106, User bitmap size, ⁇ UBI of outgoing MS104, ⁇ UBI of collaborative MS 106, Group identifier, ⁇ Allocation cycle, ⁇ MIMO mode set, etc.
  • the cooperative MS 106 knows the UBI of the originating MS 104, so the cooperative MS 106 uses the UBI of the originating MS 104 instead of its own UBI to derive its own HFBCH index. Can be used. As a result, only the same HFBCH is assigned to both the originating MS 104 and the collaborative MS 106 that are involved in CliCo. Therefore, unnecessary wasted HFBCH resources are avoided.
  • FIG. 8 shows a flowchart illustrating a method 500 for receiving resource scheduling information in the cooperative MS 106 according to Embodiment 1 of the present invention.
  • Method 500 begins at step 502.
  • collaborative MS 106 checks the user bitmap against its own UBI.
  • the collaborative MS 106 determines whether or not its own flow is scheduled in the current frame. If the flow of the cooperative MS 106 is scheduled in the current frame, in step 508, the cooperative MS 106 determines the resource allocation bits in light of its own UBI to derive its own HARQ burst size and resource size. Check the map.
  • cooperative MS 106 calculates its own HFBCH index according to the UBI of originating MS 104. If, at step 506, the collaborative MS 106 flow is not scheduled for the current frame, the method 500 ends at step 512.
  • the contents of group configuration information unicast by BS 102 to originating MS 104 and the contents of group resource allocation information multicast by BS 102 to originating MS 104 and cooperative MS 106 are: This is the same as the IEEE 802.16m draft standard (see Non-Patent Document 1, for example). However, the content of the group configuration information unicast by the BS 102 to the cooperative MS 104 is different from the IEEE 802.16m draft standard (see, for example, Non-Patent Document 1).
  • an alternative approach is that the group configuration information is multicast by the BS 102 to both the originating MS 104 and the collaborating MS 106.
  • the contents of the group configuration information multicasted by the BS 102 to both the originating MS 104 and the collaborative MS 106 can be listed below.
  • the group configuration information can be transmitted in either a MAC control message or a MAP IE.
  • a MAC control message a MAC control message
  • a MAP IE a MAP IE
  • Embodiment 1 of the present invention by allowing the collaborative MS 106 to share the UBI of the originating MS 104, additional control overhead can be introduced into the group configuration information at the stage before starting the group resource allocation. There is a disadvantage that there is.
  • the originating MS 104 and the cooperative MS 106 involved in CliCo process the same data burst, and thus have the same HARQ burst size. Therefore, the HARQ burst size indication for either the originating MS 104 or the collaborative MS 106 is unnecessary. Furthermore, the actual required UBI length depends on the user bitmap size. For example, if the user bitmap size is 8 bits, only 3 bit UBIs are actually needed instead of 5 bit UBIs.
  • the basic concept of the method for applying GRA to CliCo is that the BS 102 uses group resource allocation information instead of the group configuration information in the first embodiment of the present invention.
  • the cooperative MS 106 is allowed to share the UBI of the originating MS 104. More specifically, when BS 102 allocates resources to originating MS 104 and collaborative MS 106, the variable portion of the 5-bit resource allocation indication for collaborative MS 106 in the resource allocation bitmap is used to indicate the UBI of originating MS 104. The The length of the variable part depends on the user bitmap size. The remaining part of the 5-bit resource allocation indication for the cooperative MS 106 is used to indicate the resource size of the cooperative MS. However, the method for indicating the resource size of the cooperative MS 106 differs depending on the user bitmap size.
  • FIG. 9 shows an example of a bitmap for notifying some group resource allocation information in the case of a 4-bit user bitmap according to Embodiment 2 of the present invention.
  • the first 2 bits (eg, “00”) of the 5-bit resource allocation instruction for the cooperative MS 106 are transmitted instead of the HARQ burst size of the cooperative MS 106.
  • the last 3 bits (eg, “010”) are used to convey the resource size for the collaborative MS 106.
  • the first 2 bits (eg, “10”) of the 5-bit resource allocation indication for the originating MS 104 are used to convey the HARQ burst size of both the originating MS 104 and the collaborative MS 106. .
  • FIG. 10 shows a flowchart illustrating a method 700 for receiving group resource allocation information in the cooperative MS 106 in the case of a 4-bit user bitmap according to Embodiment 2 of the present invention.
  • Method 700 begins at step 702.
  • the collaborative MS 106 checks the user bitmap against its own UBI.
  • the collaborative MS 106 determines whether or not its own flow is scheduled in the current frame. If the flow of the collaborative MS 106 is scheduled in the current frame, in step 708, the collaborative MS 106 determines the resource allocation bits relative to its own UBI to derive the UBI of the originating MS 104 and its own resource size. Check the map.
  • step 710 the coordinating MS 106 again checks the resource allocation bitmap against the UBI of the originating MS 104 to derive its own HARQ burst size.
  • step 712 cooperative MS 106 calculates its own HFBCH index according to the UBI of originating MS 104.
  • step 706 if the collaborative MS 106 flow is not scheduled for the current frame, the method 700 ends at step 714.
  • FIG. 11 shows an example of a bitmap for notifying some group resource allocation information in the case of an 8-bit user bitmap according to Embodiment 2 of the present invention.
  • the resource allocation bitmap 804 the first 3 bits of the 5-bit resource allocation indication for the cooperative MS 106 are used to indicate the UBI of the originating MS 104, and the last 2 bits are Used to indicate the nominal resource size of the collaborative MS 106, not the actual resource size of the collaborative MS 106.
  • the actual resource size indication of the cooperative MS 106 can be obtained as a result of a bitwise exclusive OR operation between the resource size indication of the originating MS 104 and the nominal resource size indication of the cooperative MS 106.
  • the resource size indication of originating MS 104 is “111”
  • the actual resource size indication of cooperating MS 106 may be obtained as a result of a bitwise OR or logical product of the resource size indication of originating MS 104 and the nominal resource size indication of cooperating MS 106.
  • FIG. 12 shows a flowchart illustrating a method 900 for receiving group resource allocation information in the cooperative MS 106 in the case of an 8-bit user bitmap according to Embodiment 2 of the present invention.
  • Method 900 begins at step 902.
  • the collaborative MS 106 checks the user bitmap against its own UBI.
  • the collaborative MS 106 determines whether or not its own flow is scheduled in the current frame. If the collaborative MS 106 flow is scheduled in the current frame, in step 908, the collaborative MS 106 checks the resource allocation bitmap to derive the UBI of the originating MS 104.
  • step 910 the cooperative MS 106 checks the resource allocation bitmap again against its own UBI and the UBI of the originating MS 104 to derive its own HARQ burst size and resource size.
  • step 912 cooperative MS 106 calculates its own HFBCH index based on the UBI of originating MS 104. If at step 906 the collaborative MS 106 flow is not scheduled in the current frame, the method 900 ends at step 914.
  • the 5-bit for the cooperative MS 106 is included in the resource allocation bitmap.
  • the first 4 bits of the resource allocation indication are used to indicate the UBI of the originating MS 104, and the last 1 bit indicates the nominal resource size of the cooperative MS 106, not the actual resource size of the cooperative MS 106 Used for.
  • FIG. 13 shows an example of a bitmap for notifying some group resource allocation information in the case of a 32-bit user bitmap according to Embodiment 2 of the present invention.
  • the resource allocation bitmap 1004 all of the 5-bit resource allocation instructions for the cooperative MS 106 are used to indicate the UBI of the originating MS 104.
  • the resource size of the collaborative MS 106 is conveyed by a 3 bit resource size indication for the originating MS 104. That is, in the case of a 32-bit user bitmap, the originating MS 104 and the cooperative MS 106 always have the same resource size.
  • Table 2 shows an example of the GRA MAP IE for transmitting group resource allocation information according to Embodiment 2 of the present invention.
  • FIG. 14 shows a flowchart illustrating a method 1100 for receiving group resource allocation information in the cooperative MS 106 in the case of a 32-bit user bitmap according to Embodiment 2 of the present invention.
  • Method 1100 begins at step 1102.
  • the collaborative MS 106 checks the user bitmap against its own UBI.
  • the cooperative MS 106 determines whether or not its own flow is scheduled in the current frame. If the collaborative MS 106 flow is scheduled in the current frame, in step 1108 the collaborative MS 106 checks the resource allocation bitmap to derive the originating MS 104 UBI.
  • the coordinating MS 106 again checks the resource allocation bitmap against the originating MS 104 UBI to derive its own HARQ burst size and resource size.
  • cooperative MS 106 calculates its own HFBCH index according to the UBI of originating MS 104. If, in step 1106, the collaborative MS 106 flow is not scheduled in the current frame, the method 1100 ends in step 1114.
  • the difference between the methods 700, 900 and 1100 is in the method of deriving the resource size of the own device.
  • the resource size of collaborative MS 106 is derived in light of its own UBI.
  • the resource size of the collaborative MS 106 is derived in light of its own UBI and the originating MS 104 UBI.
  • the resource size of the collaborative MS 106 is derived in light of only the UBI of the originating MS 104.
  • an alternative method in the case of an 8-bit user bitmap is the first 3 bits of the 5-bit resource allocation indication for the cooperative MS 106 in the resource allocation bitmap. Is used to indicate the UBI of the originating MS 104, but the last two bits are used to convey the actual resource size of the coordinated MS 106, not the nominal resource size of the coordinated MS 106.
  • an alternative approach in the case of a 16-bit user bitmap is that in the resource allocation bitmap, the first 4 bits of the 5-bit resource allocation indication for the collaborative MS 106 indicate the UBI of the originating MS 104 The last 1 bit is used to indicate the actual resource size of the collaborative MS 106.
  • an alternative approach in the case of a 4-bit user bitmap is the first 2 bits of the 5-bit resource allocation indication for the cooperative MS 106 in the resource allocation bitmap. Is used to indicate the UBI of the originating MS 104, but the last 3 bits are used to indicate the nominal resource size of the cooperative MS 106, not the actual resource size of the cooperative MS 106.
  • the actual resource size of the cooperative MS 106 can be derived from the resource size indication of the originating MS 104 and the nominal resource size indication of the cooperative MS 106 in the manner described above.
  • an alternative method in the case of a 32-bit user bitmap is that all of the 5-bit resource allocation instructions of the cooperative MS 106 in the resource allocation bitmap are Although used to convey UBI, the resource size of the cooperative MS 106 is always set to a predetermined value.
  • the content of the group configuration information unicast by the BS 102 to the originating MS 104 or the cooperative MS 106 is the same as the IEEE standard 802.16m draft standard (for example, see Non-Patent Document 1). is there.
  • the content of the group resource allocation information multicasted by the BS 102 to the originating MS 104 or the cooperative MS 106 is different from the IEEE 802.16m draft standard (for example, see Non-Patent Document 1).
  • group resource allocation information can be transmitted by either multicast MAC control information or multicast MAP IE.
  • FIG. 15 shows an example of a bitmap for notifying some group resource allocation information in the case of a 4-bit user bitmap according to Embodiment 3 of the present invention.
  • the first two bits of the 5-bit resource allocation indication for the cooperative MS 106 are used to indicate the UBI of the originating MS 104. If the UBI indication (eg, “10”) of the originating MS 104 is the same as the UBI of the collaborative MS 106, various implications can occur.
  • the communicating MS 106 may imply not transmitting / receiving UL / DL data bursts in the subsequent N consecutive allocation periods.
  • N is determined in advance.
  • the value of N is indicated by the last 3 bits of the 5-bit resource allocation indication for the cooperative MS 106.
  • the UBI indication of the originating MS 104 in the resource allocation bitmap is the same as the UBI of the cooperative MS 106
  • An implication similar to the case of a 4-bit user bitmap can occur.
  • the length of the UBI indication value of originating MS 104 depends on the size of the user bitmap.
  • 3 bits can be used to convey the resource size of the collaborative MS 106.
  • all eight resource size sets are available for allocating resources to the collaborative MS 106.
  • 8-bit, 16-bit, or 32-bit user bitmap only a portion of the set of 8 resource sizes can be used to allocate resources to the collaborative MS 106. This reduces the scheduling flexibility of the BS 102.
  • FIG. 16 shows an example of a bitmap for notifying some group resource allocation information in the case of an 8-bit user bitmap according to Embodiment 4 of the present invention.
  • the resource allocation bitmap 1304 only the first two bits of the 5-bit resource allocation instruction for the cooperative MS 106 indicate the offset of the UBI of the originating MS 104 relative to the UBI of the cooperative MS 106. And the last 3 bits are used to indicate the resource size of the cooperative MS 106.
  • Table 3 shows an example of GRA MAP IE for transmitting group resource allocation information according to Embodiment 4 of the present invention.
  • Embodiment 4 of the present invention in the case of an 8-bit, 16-bit, or 32-bit user bitmap, only 2 bits are used for the UBI indication of the originating MS 106, so that the BS 102 sends the originating MS 104.
  • various restrictions need to be imposed.
  • the BS 102 may be subject to the following restrictions, for example.
  • the UBI of the originating MS 104 is less than the UBI of the collaborative MS 106, and the difference between the UBI of the originating MS 104 and the UBI of the collaborative MS 106 is greater than 4.
  • Embodiment 4 of the present invention since 3 bits are used to indicate the resource size of the cooperative MS 106, even in the case of an 8-bit, 16-bit, or 32-bit user bitmap, the cooperative The entire set of 8 resource sizes can be used to allocate MS 106 resources.
  • FIG. 17 shows an example of a bitmap for notifying some group resource allocation information in the case of an 8-bit user bitmap according to the fifth embodiment of the present invention.
  • the first 2 bits of the 5-bit resource allocation indication for the collaborative MS 106 are used to indicate the first part of the UBI of the originating MS 104, and finally Are used to indicate the resource size of the collaborative MS 106.
  • Table 4 shows an example of GRA MAP IE for transmitting group resource allocation information according to the fifth embodiment of the present invention.
  • the group configuration information unicast by the BS 102 to the cooperative MS 106 includes the second part of the UBI of the originating MS 104.
  • the contents of the group configuration information unicast to the collaborative MS 106 by the BS 102 can be listed below.
  • the flow identifier of the collaborative MS 106 User bitmap size, The second part of the UBI of the originating MS 104, ⁇ UBI of collaborative MS 106, ⁇ Group ID, ⁇ Allocation cycle, ⁇ MIMO mode set, etc.
  • the fifth embodiment of the present invention in the case of an 8-bit user bitmap, 3 bits reported in the group configuration information and the group resource allocation information are used for the UBI indication of the originating MS 106. No restrictions are imposed when the BS 102 adds the flows of the originating MS 104 and the collaborative MS 106 to the group.
  • the first part of the UBI of the originating MS 104 may be 2 bits on the LSB (least significant bit) side of the UBI of the originating MS 104.
  • the second part of the UBI of the outgoing MS 104 is one bit of the MSB (most significant bit) of the UBI of the outgoing MS 104, corresponding to the case of the 8-bit, 16-bit and 32-bit user bitmaps. It can be 2 bits and 3 bits on the MSB side.
  • the first part of the UBI of the originating MS 104 may be 2 bits on the MSB side of the UBI of the originating MS 104.
  • the second part of the UBI of the outgoing MS 104 is 1 bit of the LSB of the UBI of the outgoing MS 104, 2 bits of the LSB side, and the LSB side, corresponding to the case of the 8-bit, 16-bit and 32-bit user bitmaps, respectively.
  • the BS 102 allows the cooperating MS 106 to share the UBI of the originating MS 104 so that the cooperating MS 106 can use the UBI of the originating MS 104 to calculate its own HFBCH. It will be appreciated by those skilled in the art that various variations and / or modifications of the present invention can be made such that the BS 102 allows the originating MS 104 to share the collaborative MS 106 UBI.
  • each functional block used in the description of the above embodiment is typically realized as an LSI which is an integrated circuit. These may be individually made into one chip, or may be made into one chip so as to include a part or all of them. Although referred to as LSI here, it may be referred to as IC, system LSI, super LSI, or ultra LSI depending on the degree of integration.
  • the method of circuit integration is not limited to LSI, and implementation with a dedicated circuit or a general-purpose processor is also possible.
  • An FPGA Field Programmable Gate Array
  • a reconfigurable processor that can reconfigure the connection and setting of circuit cells inside the LSI may be used.
  • the present invention can be applied to a mobile communication system or the like.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

　複数の移動局（ＭＳｓ）と通信する基地局（ＢＳ）は、上記複数のＭＳｓの各々に対するリソース割当て情報を示す制御信号を作成する制御信号作成部と上記複数のＭＳｓへ上記制御信号を送信する送信部を含む構成をとり、あるＭＳに対する制御信号は、他のＭＳに関する情報を含む。

Description

基地局、移動局、協調移動局、送信方法及び受信方法
　本発明は、クライアント協調動作を行う、基地局、移動局、協調移動局、送信方法及び受信方法に関する。
　ＩＥＥＥ（Institute of Electrical and Electronics Engineers、電気電子技術者協会）８０２．１６ワーキンググループは、ＩＭＴ（International Mobile Telecommunications）－アドバンスト次世代携帯電話システムの諸要件を満たす８０２．１６ｍ無線インタフェース仕様を作成中である。ＩＥＥＥ ８０２．１６ｍ草案標準（例えば、非特許文献１参照）に基づいて、ＷｉＭＡＸ（Worldwide Interoperability for Microwave Access）フォーラムは、ＷｉＭＡＸ リリース２．０ ＭＳＰ（Mobile System Profile）及びＰＩＣＳ（Protocol Implementation Conformance Statement）を考案中である。ＩＥＥＥ ８０２．１６ｍ標準並びにＷｉＭＡＸリリース２．０ ＭＳＰ及びＰＩＣＳは、２０１１年早期には仕上げられると見込まれる。
　また、ＩＥＥＥ８０２．１６ワーキンググループは、８０２．１６ｍ／ＷｉＭＡＸ２．０を超える将来の８０２．１６／ＷｉＭＡＸネットワークの構想設計を開始した。将来の８０２．１６／ＷｉＭＡＸネットワークは、大型画面の機器、マルチメディア・アプリケーション並びにさらに増加する接続ユーザ及び機器によって拍車をかけられる移動通信データ・トラフィックの爆発的な増加をサポートするものになるだろうという共通の認識が、８０２．１６／ＷｉＭＡＸコミュニティの間にはある。また、将来の８０２．１６／ＷｉＭＡＸネットワークは、例えば、８０２．１１／Ｗｉ－Ｆｉ（Wireless Fidelity）等の他の無線技術と効率的に連携動作するものになるであろう。
　将来の８０２．１６／ＷｉＭＡＸネットワークは、スループットやＳＥ（Spectral Efficiency）等の様々な性能指標値に関して、８０２．１６ｍネットワークと比較して大幅に改良されたものになるであろう。例えば、都市区域におけるカバレッジを想定した場合、将来の８０２．１６／ＷｉＭＡＸネットワークは、ＵＬ（Uplink，アップリンク）とＤＬ（Downlink，ダウンリンク）の両方で、８０２．１６ｍ／ＷｉＭＡＸ２．０ネットワークの２倍のＳＥをセルエッジでの目標にしている（例えば、非特許文献２参照）。８０２．１６ｍ／ＷｉＭＡＸ２．０ネットワークは、４´２アンテナ構成で少なくとも０．０６ｂｐｓ／Ｈｚ／秒のＤＬのセルエッジでのＳＥと２´４アンテナ構成で少なくとも０．０３ｂｐｓ／Ｈｚ／秒のＵＬのセルエッジでのＳＥをもつことに留意されたい。
　例えば、ＣｌｉＣｏ（Client Collaboration、クライアント協調動作）等の協調技術は、無線通信システムのセルエッジでのＳＥ及びネットワーク全体のエネルギー効率の大幅な改良を確かなものにした。ＣｌｉＣｏは、無線環境においてクライアント同士がデータを合同で送信／受信するために交信する技術である（例えば、非特許文献３参照）。ＣｌｉＣｏでは、ＢＳとクライアント間で複数の経路を介して情報を送信／受信するために、クライアント・クラスタリング（Client Clustering）及びピアツーピア（Peer-to-Peer）通信が利用される。その結果、設備コストの増加なしに、セルエッジでのＳＥを向上させることができる。さらに、劣悪なチャネルを有するクライアントの電池を長持ちさせることができる。
　ＣｌｉＣｏを行う典型的な無線通信システム１００を例示する図を図１に示す。無線通信システム１００は、ＢＳ（Base Station，基地局）１０２と、例えば、ＭＳ１０４及びＭＳ１０６の複数のＭＳ（Mobile Station，移動局）とを含む構成を採る。
　典型的なＢＳ１０２を例示するブロック図を図２に示す。ＢＳ１０２は、ここではＷｉＭＡＸによる通信機能のみを装備し、ＷｉＭＡＸ ＰＨＹブロック１３０とＷｉＭＡＸ ＭＡＣブロック１２０からなる。ＷｉＭＡＸ ＭＡＣブロック１２０は、ＷｉＭＡＸ ＯＦＤＭＡ（Orthogonal Frequency Division Multiple Access）ベースの媒体アクセス制御（Media Access Control：ＭＡＣ）プロトコルを実行する。ＷｉＭＡＸ ＰＨＹブロック１３０は、ＷｉＭＡＸ ＭＡＣブロック１２０の制御の下で、ＷｉＭＡＸ ＯＦＤＭＡベースの物理層プロトコルを実行する。
　図２を参照すると、ＷｉＭＡＸ ＭＡＣブロック１２０はさらに、制御部１２２、スケジューラ１２４、メッセージ生成部１２６及びメッセージ処理部１２８を含む構成を採る。制御部１２２は、一般的なＭＡＣプロトコル動作を制御する。スケジューラ１２４は、制御部１２２の制御の下で、各ＭＳへのリソースの割当をスケジュールする。メッセージ生成部１２６は、スケジューラ１２４からリソース割当スケジューリング情報を受け取ると、データ・パケット及びＤＬ制御情報を生成する。メッセージ処理部１２８は、制御部１２２の制御の下で、複数のＭＳから受信したデータ・パケット及びＵＬ制御情報を分析し、その分析結果を制御部１２２へ報告する。
　メッセージ生成部１２６によって生成されたデータ・パケット及びＤＬ制御情報は、ＷｉＭＡＸ ＰＨＹブロック１３０内のＯＦＤＭＡ送信器（図２では図示せず）を介してＢＳ１０２によって複数のＭＳへ送信されることに留意されたい。メッセージ処理部１２８によって分析されるデータ・パケット及びＵＬ制御情報は、ＷｉＭＡＸ ＰＨＹブロック１３０内のＯＦＤＭＡ受信器（図２では図示せず）を介してＢＳ１０２によって受信される。
　図２を参照すると、メッセージ生成部１２６内には、ＨＦＢＣＨ（ＨＡＲＱフィードバック・チャネル）生成部１３２とリソース割当生成部１３４とが存在する。ここで、ＨＡＲＱはハイブリッド自動再送要求（Hybrid Automatic Repeat Request）を表す。ＨＦＢＣＨ生成部１３２は、ＵＬデータ送信に対するＨＡＲＱフィードバック情報（例えば、ＡＣＫ／ＮＡＣＫ）を通知する、ＵＬデータ送信に対するＨＡＲＱフィードバック・チャネルを生成する。リソース割当生成部１３４は、複数のＭＳの各々へのリソース割当情報を通知する、ＵＬ／ＤＬデータ送信のためのリソース割当制御情報を生成する。
　ＧＲＡ（Group Resource Allocation）の観点では、リソース割当生成部１３４によって生成されるリソース割当制御情報は、グループ・コンフィギュレーション（Group Configuration）情報並びにＤＬ／ＵＬでのＧＲＡ送信のためのＨＦＢＣＨのインデックス情報を含むグループ・リソース割当情報を含み得る。ＨＦＢＣＨ生成部１３２によって生成されるＨＦＢＣＨは、ＵＬでのＧＲＡ送信に対するＨＡＲＱフィードバック情報を含み得る。
　図２を参照するとメッセージ処理部１２８内には、ＨＦＢＣＨ分析部１３６が存在する。ＨＦＢＣＨ分析部１３６は、ＤＬでのデータ送信に対して受信したＨＦＢＣＨを分析し、その対応するＤＬデータ送信が成功したか否かを判断する。ＧＲＡの観点では、ＨＦＢＣＨ分析部１３６は、受信したＵＬ制御情報からＤＬでのＧＲＡ送信に対するＨＡＲＱフィードバック情報を導出し得る。
　典型的なＭＳ１０４を例示するブロック図を図３に示す。ＭＳ１０４は、ＷｉＭＡＸ及びＷｉ－Ｆｉの両方による通信機能を装備し、ＷｉＭＡＸ ＰＨＹブロック１４２、Ｗｉ－Ｆｉ ＰＨＹブロック１４４、ＷｉＭＡＸ ＭＡＣブロック１４６、Ｗｉ－Ｆｉ ＭＡＣブロック１４８、及びＧＬＬ（Generic Link Layer）ブロック１５０から構成される。ＷｉＭＡＸ ＭＡＣブロック１４６は、ＷｉＭＡＸ ＯＦＤＭＡベースのＭＡＣ（媒体アクセス制御）プロトコルを実行する。ＷｉＭＡＸ ＰＨＹブロック１４２は、ＷｉＭＡＸ ＭＡＣブロック１４６の制御の下で、ＷｉＭＡＸ ＯＦＤＭＡベースの物理層プロトコルを実行する。Ｗｉ－Ｆｉ ＭＡＣブロック１４８は、Ｗｉ－Ｆｉ ＣＳＭＡ／ＣＡ（Carrier Sense Multiple Access with Collision Avoidance）ベースのＭＡＣ（媒体アクセス制御）プロトコルを実行する。Ｗｉ－Ｆｉ ＰＨＹブロック１４４は、Ｗｉ－Ｆｉ ＭＡＣブロック１４８の制御の下で、Ｗｉ－Ｆｉ ＯＦＤＭ（Orthogonal Frequency Division Multiplexing）／ＤＳＳＳ（Direct Sequence Spread Spectrum）ベースの物理層プロトコルを実行する。ＧＬＬブロック１５０は、異種のＷｉＭＡＸリンクとＷ－Ｆｉリンクとの間の連携動作を管理するものとして機能する。
　図３を参照すると、ＷｉＭＡＸ ＭＡＣブロック１４６はさらに、制御部１５４、メッセージ生成部１５２、及びメッセージ処理部１５６を含む構成を採る。制御部１５４は、一般的なＭＡＣプロトコル動作を制御する。メッセージ生成部１５２は、制御部１５４の制御の下で、ＵＬ制御情報及びデータ・パケットを生成する。メッセージ処理部１５６は、制御部１５４の制御の下で、ＢＳ１０２から受信したデータ・パケット及びＤＬ制御情報を分析し、その分析結果を制御部１５４へ供給する。
　メッセージ生成部１５２によって生成されたデータ・パケット及びＵＬ制御情報は、ＷｉＭＡＸ ＰＨＹブロック１４２内のＯＦＤＭＡ送信器（図３では図示せず）を介して、ＭＳ１０４からＢＳ１０２へ送信されることに留意されたい。メッセージ処理部１５６によって分析されるデータ・パケット及びＤＬ制御情報は、ＷｉＭＡＸ ＰＨＹブロック１４２内のＯＦＤＭＡ受信器（図３では図示せず）を介してＭＳ１０４によって受信される。
　図３を参照すると、メッセージ処理部１５６内には、リソース分析部１５１とＨＦＢＣＨ分析部１５３とが存在する。ＨＦＢＣＨ分析部１５３は、ＵＬでのデータ送信に対して受信したＨＦＢＣＨを分析し、その対応するＵＬデータ送信が成功したか否かを判断する。リソース分析部１５１は、受信したリソース割当制御情報を分析し、ＭＳ１０４に対して特定されたリソース割当情報を導出する。ＵＬデータ送信の場合には、制御部１５４の制御の下でメッセージ生成部１５２によって生成されたデータ・パケットは、次に、導出されたリソース割当情報に従って、ＭＳ１０４からＢＳ１０２へ送信される。ＤＬデータ送信の場合には、ＢＳ１０２からＭＳ１０４へ送信されたデータ・パケットは、次に、導出されたリソース割当情報に従ってＭＳ１０４によって受信される。
　ＧＲＡの観点では、メッセージ処理部１５６内のリソース分析部１５１は、受信したリソース割当制御情報から、グループ・コンフィギュレーション情報並びにＤＬ／ＵＬでのＧＲＡ送信のためのＨＦＢＣＨのインデックス情報を含むグループ・リソース割当情報を導出し得る。ＨＦＢＣＨ分析部１５３は、受信したＨＦＢＣＨから、ＵＬでのＧＲＡ送信に対するＨＡＲＱフィードバック情報を導出し得る。
　図３を参照すると、メッセージ生成部１５２内にはＨＦＢＣＨ生成部１５５が存在する。ＨＦＢＣＨ生成部１５５は、ＤＬでのデータ送信に対するＨＡＲＱフィードバック情報を含むＨＡＲＱフィードバック・チャネルを生成する。ＧＲＡの観点では、ＨＦＢＣＨ生成部１５５は、ＤＬでのＧＲＡ送信に対するＨＡＲＱフィードバック・チャネルを生成し得る。
　典型的なＭＳ１０６を例示するブロック図を図４に示す。ＭＳ１０６もまた、ＷｉＭＡＸ及びＷｉ－Ｆｉの両方による通信機能を装備し、ＭＳ１０４と全く同様の構成と機能性を有する。ＭＳ１０４とＭＳ１０６との主な相違点は、ＭＳ１０６とは異なり、ＭＳ１０４のＷｉ－Ｆｉ ＭＡＣブロック１４８内には図３に示したとおり、スケジューラ１５８があることであり、このスケジューラはＣｌｉＣｏのための協調動作スケジューリングのために使用される。
　図１を参照すると、ＢＳ１０２は、 ＷｉＭＡＸリンク１０８ａ及び１０８ｂを介してＭＳ１０４と通信し、ＷｉＭＡＸリンク１１０ａ及び１１０ｂを介してＭＳ１０６と通信する。ＭＳ１０４は、ピアツーピアＷｉ－Ｆｉリンク１１２ａ，１１２ｂを介してＭＳ１０６と通信する。また、ＭＳ１０４は、利用可能であれば、例えば、ＷｉＭＡＸ、ブルートゥース、または６０ ＧＨｚ ｍｍＷ（ミリ波）等の他の無線技術を介してＭＳ１０６と通信してもよい。
　ＣｌｉＣｏは、無線通信システム１００のＤＬ及びＵＬの両方で実現可能であることに留意されたい。一例として、無線通信システム１００におけるＵＬでのＣｌｉＣｏの動作を以下に説明する。
　図１を参照すると、ＢＳ１０２とＭＳ１０４との間のＷｉＭＡＸリンク１０８ａの信号品質が悪くなると、ＭＳ１０４は、近隣探索、協調機選択／割当等のＵＬでのＣｌｉＣｏ手順を開始することができる。ＢＳ１０２とＭＳ１０６との間のＷｉＭＡＸリンク１１０ａの信号品質が良ければ、ＭＳ１０４は、ＭＳ１０６を協調機として選択できる。ＣｌｉＣｏのコンテクストでは、ＭＳ１０４は発信ＭＳと呼ばれ、ＭＳ１０６は協調ＭＳと呼ばれる。
　ＣｌｉＣｏは、様々な状況において起こり得る。例えば、発信ＭＳ１０４がカフェテリア内の奥の方にあるとすると、そのため、発信ＭＳ１０４へのＷｉＭＡＸリンクの信号品質が非常に悪いことがあり得る。一方、協調ＭＳ１０６は、発信ＭＳ１０４に比べて、カフェテリアの窓または入口に非常に近いところにあるとすれば、協調ＭＳ１０６は発信ＭＳ１０４よりも非常に良いＷｉＭＡＸリンクの信号品質を有し得る。
　図１に示したＣｌｉＣｏを行う無線通信システム１００に適用され得る、典型的なフレーム構成２００を例示する図を図５に示す。図５を参照すると、フレーム２０２及びフレーム２１２の各々は、８個のサブフレームからなる。そのうちの５個はＤＬサブフレームであり、その他はＵＬサブフレームである。
　ＵＬでのＣｌｉＣｏに関する限り、フレーム２０２の最初のＤＬサブフレーム２０４中において、ＢＳ１０２は、ＣｌｉＣｏに関与する発信ＭＳ１０４と協調ＭＳ１０６とを含む、ＢＳ１０２に接続された複数の移動局へ制御情報を示すＭＡＰ ２２０を送信することができる。ＭＡＰ２２０は、複数のＭＡＰ ＩＥ（Information Element：情報要素）からなる。ＭＡＰ ＩＥの一部はＵＬデータ送信に対するＨＡＲＱフィードバック情報を通知することができ、ＭＡＰ ＩＥの一部はＤＬ／ＵＬデータ送信のためのリソース割当情報を通知することができる。ＨＡＲＱフィードバック情報を通知する、ＭＡＰ２２０中の１個のＭＡＰ ＩＥが、ＵＬデータ送信に対する１つのＨＢＦＣＨを形成する。
　フレーム２０２の最初のＤＬサブフレーム２０４と最初のＵＬサブフレーム２０６との間の期間２０８中に、発信ＭＳ１０４と協調ＭＳ１０６は、ＨＦＢＣＨインデックス情報を含むそれぞれのリソース割当情報を得るために、ＭＡＰ２２０をそれぞれ復号する必要がある。また、発信ＭＳ１０４は、ピアツーピアＷｉ－Ｆｉリンク１１２ａを介して、ＵＬデータ・バースト２５０を協調ＭＳ１０６へ送信する必要がある。
　発信ＭＳ１０４がＷｉＭＡＸ リンク１０８ｂを介してＢＳ１０２により送信されたＭＡＰ２２０の復号に成功しているならば、発信ＭＳ１０４は、その受信したリソース割当情報に従って、フレーム２０２の最初のＵＬサブフレーム２０６中においてＷｉＭＡＸリンク１０８ａを介してＵＬデータ・バースト２５０をＢＳ１０２へ送信する。他方、協調ＭＳ１０６がＷｉＭＡＸリンク１１０ｂを介してＢＳ１０２により送信されたＭＡＰ２２０の復号に成功していて、かつ、ピアツーピアＷｉ－Ｆｉリンク１１２ａを介して発信ＭＳ１０４により送信されたＵＬデータ・バースト２５０の受信に成功しているならば、協調ＭＳ１０６は、その受信したリソース割当情報に従って、ＷｉＭＡＸリンク１１０ａを介して同一のＵＬデータ・バースト２５０をＢＳ１０２へ同時に送信する。その結果、ＢＳ１０２は、受信信号の品質を向上させるために、ＷｉＭＡＸリンク１０８ａとＷｉＭＡＸリンク１１０ａとから受信したＵＬデータ・バースト２５０の２個のコピーを合成できる。
　フレーム２１２の２番目のＤＬサブフレーム２１４中において、ＢＳ１０２は、ＣｌｉＣｏに関与する発信ＭＳ１０４及び協調ＭＳ１０６を含む、ＢＳ１０２に接続された複数の移動局へＭＡＰ２４０を送信することができる。上述のとおり、ＭＡＰ２４０中の一部を成すＨＦＢＣＨｓは、フレーム２０２の最初のＵＬサブフレーム２０６中において発信ＭＳ１０４及び協調ＭＳ１０６が送信したＵＬデータ・バースト２５０に対するＨＡＲＱフィードバック情報を通知することができる。
　フレーム２１２の２番目のＤＬサブフレーム２１４と最初のＵＬサブフレーム２１６の間の期間２１８中に、発信ＭＳ１０４及び協調ＭＳ１０６は、期間２０８中においてＭＡＰ２２０を復号することによって得られる、それぞれのＨＦＢＣＨインデックス情報に従って、ＵＬデータ・バースト２５０に対するＨＡＲＱフィードバック情報を得るために、ＭＡＰ２４０中の対応するＨＦＢＣＨｓをそれぞれ復号する必要がある。
　ＨＡＲＱフィードバック情報が、フレーム２０２の第１のＵＬサブフレーム２０６中において発信ＭＳ１０４及び協調ＭＳ１０６が送信したＵＬデータ・バースト２５０をＢＳ１０２が正常に復号していないことを示す場合、フレーム２１２の最初のＵＬサブフレーム２１６中において、発信ＭＳ１０４及び協調ＭＳ１０６は、ＵＬデータ・バースト２５０を再送する必要があり得る。
　上述したとおり、将来の８０２．１６／ＷｉＭＡＸネットワークは、爆発的な移動通信データ・トラフィックをサポートしなくてはならない。さらに、将来の８０２．１６／ＷｉＭＡＸネットワークは、ＶｏＩＰ（Voice over Internet Protocol）等の移動通信インターネット・アプリケーションの実感品質（Quality of Experience）を向上させなくてはならない。ＶｏＩＰは周期的なトラフィック・パターンをもち、比較的固定したペイロード・サイズであることを考えると、例えば、ＰＡ（Persistent Allocation）及びＧＲＡといった、特にＶｏＩＰの実感の品質を向上させるために、様々なＰＨＹ／ＭＡＣメカニズムが設計された。本発明では、ＣｌｉＣｏへのＧＲＡの適用を取り上げる。
　ＩＥＥＥ ８０２．１６ｍ草案標準（例えば非特許文献１参照）で規定されたＧＲＡメカニズムは、ＣｌｉＣｏに対応していない。しかし、ＧＲＡメカニズムは、ＣｌｉＣｏに容易に対応可能である。
　ＩＥＥＥ ８０２．１６ｍ草案標準（例えば非特許文献１参照）によれば、ＧＲＡメカニズムは、制御オーバヘッドを節減するために、あるグループとしての複数のユーザにリソースを割り当てる。このリソース割当はトランスポート・フロー（Transport flow）単位である。図１を参照すると、ＧＲＡをＣｌｉＣｏに適用する方法は、二つの操作からなる。すなわち、ｉ）ＢＳ１０２は、発信ＭＳ１０４及び協調ＭＳ１０６のそれぞれのフローをあるグループに加える、または発信ＭＳ１０４及び協調ＭＳ１０６のそれぞれのフローをあるグループから削除する。ｉｉ）ＢＳ１０２は、同一グループ内の発信ＭＳ１０４及び協調ＭＳ１０６のそれぞれのフローにリソースを割り当てる。
　ＩＥＥＥ ８０２．１６ｍ草案標準（例えば非特許文献１参照）によれば、発信ＭＳ１０４（または協調ＭＳ１０６）のフローをあるグループに加えるときに、ＢＳ１０２は、ユニキャストＭＡＣ制御メッセージ中でグループ・コンフィギュレーション情報を発信ＭＳ１０４（または協調ＭＳ１０６）へ送信する。同一グループ内の発信ＭＳ１０４及び／または協調ＭＳ１０６のそれぞれのフローにリソースを割り当てる場合、ＢＳ１０２は、マルチキャストＭＡＰ ＩＥでＨＦＢＣＨインデックス情報を含むグループ・リソース割当情報を発信ＭＳ１０４及び協調ＭＳ１０６へ送信する。ユニキャストＭＡＣ制御メッセージ中で送信されるグループ・コンフィギュレーション情報とマルチキャストＭＡＰ ＩＥで送信されるグループ・リソース割当情報は、図２に示したメッセージ生成部１２６によって生成されることに留意されたい。
　ＩＥＥＥ ８０２．１６ｍ草案標準（例えば非特許文献１参照）によれば、ユニキャストＭＡＣ制御メッセージ中で送信されるグループ・コンフィギュレーション情報は、対応するマルチキャストＭＡＰ ＩＥで送信されるグループ・リソース割当情報を解釈するために使用され得る。グループ・コンフィギュレーション情報の内容は、次のものを含む。
　・　フロー識別子（Flow identifier）、
　・　ユーザ・ビットマップ・サイズ（User bitmap size）、
　・　ＵＢＩ（User Bitmap Index，ユーザ・ビットマップ・インデックス）、
　・　グループ識別子（Group identifier）、 
　・　割当て周期（Allocation periodicity）、及び
　・　ＭＩＭＯ（Multiple Input Multiple Output）モード・セット（MIMO mode set）、等
　フロー識別子は、ＭＳのフローのうちのどのフローがグループに加えられるのかをＭＳに通知するために使用され、４ビットのサイズを有する。ユーザ・ビットマップ・サイズは、マルチキャストＭＡＰ ＩＥで送信されるユーザ・ビットマップに使用されるビット数を示す。ユーザ・ビットマップ・サイズは、４ビット、８ビット、及び３２ビットのうちの一つをとる。ＵＢＩは、ユーザ・ビットマップ中のＭＳのフローのインデックスを示し、５ビットのサイズを有する。グループ識別子は、ＭＳのフローが加えられるＤＬ／ＵＬグループを一意に識別し、１２ビットのサイズを有する。割当て周期は、対応するグループ・リソース割当情報を通知するマルチキャストＭＡＰ ＩＥが送信される頻度を指定し、周期は１フレーム、２フレーム、４フレーム及び８フレームのうちの一つであり得る。ＭＩＭＯモード・セットは、当グループ中でサポートされているＭＩＭＯモードを伝える。
　発信ＭＳ１０４と協調ＭＳ１０６に向けたグループ・コンフィギュレーション情報の主な違いは、発信ＭＳ１０４と協調ＭＳ１０６のそれぞれのＵＢＩが異なることである。さらに、グループ・コンフィギュレーション情報は発信ＭＳ１０４と協調ＭＳ１０６へユニキャスト（unicast）されるので、協調ＭＳ１０６は発信ＭＳ１０４のＵＢＩを知らないし、逆の場合もそうである。
　ＩＥＥＥ ８０２．１６ｍ草案標準（例えば非特許文献１参照）によれば、グループ・コンフィギュレーション情報は、４個のＨＡＲＱバースト・サイズ（HARQ burst size）のセットをさらに含み得る。例えば、４個のＨＡＲＱバースト・サイズのセットは、｛６バイト、８バイト、９バイト、１０バイト｝であり得る。バースト・サイズは、複数のＦＥＣ（Forward Error Correction）ブロックに分割可能である、符号化されたパケットのサイズであることに留意されたい。バースト・サイズは、適用できる場合、バースト当たり及び／またはＦＥＣブロック当たりのＣＲＣ（Cyclic Redundancy Code）の追加を含み得る。
　また、４個のＨＡＲＱバースト・サイズのそれぞれに対応して、グループ・コンフィギュレーション情報は、８個のリソース・サイズを含み得る。例えば、９バイトのＨＡＲＱバースト・サイズについては、８個のリソース・サイズのセットは、｛１ＬＲＵ、２ＬＲＵｓ、３ＬＲＵｓ、４ＬＲＵｓ、５ＬＲＵｓ、６ＬＲＵｓ、７ＬＲＵｓ、８ＬＲＵｓ｝となり得る。ここで、ＬＲＵは論理的リソース単位（Logical Resource Unit）を表わす。６バイト、８バイト、１０バイトの他の３個のＨＡＲＱバースト・サイズのそれぞれについては、８個のリソース・サイズのセットは、異なることもあるし、または９バイトのＨＡＲＱバースト・サイズと同じこともある。
　ＩＥＥＥ ８０２．１６ｍ草案標準（例えば非特許文献１参照）によれば、グループ・リソース割当情報の一部は、マルチキャストＭＡＰ ＩＥで送信されるビットマップによって運ばれる。ＩＥＥＥ ８０２．１６ｍ草案標準［１］による、一部のグループ・リソース割当情報を通知する典型的なビットマップを例示する図を図６に示す。一部のグループ・リソース割当情報を通知するために使用されるビットマップは二つある。一つはユーザ・ビットマップ３０２であり、もう一つはリソース割当ビットマップ３０４である。
　ＩＥＥＥ ８０２．１６ｍ草案標準（例えば非特許文献１参照）によれば、ユーザ・ビットマップ３０２は、現在のフレームにスケジュールされるのはどのフローであるかを伝えるためにフロー当たり１ビットを使用する。図６を参照すると、発信ＭＳ１０４のＵＢＩは「０００００」であるのでユーザ・ビットマップ３０２の１ビット目を参照する。協調ＭＳ１０６のＵＢＩは「０００１１」であるのでユーザ・ビットマップ３０２の４ビット目を参照する。したがって、発信ＭＳ１０４及び協調ＭＳ１０６両方のそれぞれのフロー（データに相当）はリソース割当ビットマップ３０４で指示され、現在のフレームに送信される。
　図６を参照すると、リソース割当ビットマップ３０４は、複数の５ビットのリソース割当指示を含む構成を採り、各リソース割当指示は特定のスケジュールされたフローに対応する。５ビットのリソース割当指示の各々において、最初の２ビットはＨＡＲＱバースト・サイズを伝えるために使用され、最後の３ビットはリソース・サイズを伝えるために使用される。
　図６を参照すると、ＨＡＲＱバースト・サイズは４個のバースト・サイズの種類｛６バイト、８バイト、９バイト、１０バイト｝から選択され、「００」, 「０１」、「１０」、「１１」によって指示される。図６では発信ＭＳ１０４及び協調ＭＳ１０６両方とも「１０」で示されるため、両方のＨＡＲＱバースト・サイズは９バイトである。発信ＭＳ１０４及び協調ＭＳ１０６のリソース・サイズは、それぞれ、「１１１」と「００１」によって示される。したがって、発信ＭＳ１０４及び協調ＭＳ１０６のリソース・サイズは、それぞれ、８ＬＲＵｓと２ＬＲＵｓであり得る。
　ＩＥＥＥ ８０２．１６ｍ草案標準（例えば非特許文献１参照）によれば、ユーザ・ビットマップ３０２及びリソース割当ビットマップ３０４に加えて、複数のＭＩＭＯモードがグループ中でサポートされる場合、ＭＩＭＯビットマップと呼ばれる他のビットマップが使用され得る。
　ＩＥＥＥ ８０２．１６ｍ草案標準（例えば非特許文献１参照）による、グループ・リソース割当情報を送信するための典型的なＧＲＡ ＭＡＰ ＩＥを例示する表を表１に示す。
Figure JPOXMLDOC01-appb-T000001
　さらに、ＩＥＥＥ ８０２．１６ｍ草案標準（例えば非特許文献１参照）によれば、グループ内のスケジュールされたフローについてのＨＦＢＣＨインデックスは、そのＵＢＩ及び表１に示したＨＦＡオフセットの予め決められた関数である。換言すると、発信ＭＳ１０４及び協調ＭＳ１０６のそれぞれが、表１に示したＧＲＡ ＭＡＰ ＩＥを復号後、自機のＵＢＩにより自機のＨＦＢＣＨインデックスを算出することができる。
　ＩＥＥＥ ８０２．１６ｍ草案標準（例えば非特許文献１参照）において、発信ＭＳ１０４（または協調ＭＳ１０６）がリソース割当情報を受信する方法４００を例示するフローチャートを図７に示す。方法４００はステップ４０２で開始する。ステップ４０４において、発信ＭＳ１０４（または協調ＭＳ１０６）は、自機のＵＢＩに照らしてユーザ・ビットマップをチェックする。ステップ４０６では、発信ＭＳ１０４（または協調ＭＳ１０６）は、自機のフローが現在のフレームでスケジュールされているか否かを判定する。発信ＭＳ１０４（または協調ＭＳ１０６）のフローが現在のフレームにスケジュールされていれば、ステップ４０８において、発信ＭＳ１０４（または協調ＭＳ１０６）は、次に、自機のＨＡＲＱバースト・サイズとリソース・サイズを導出するために、自機のＵＢＩに照らしてリソース割当てビットマップをチェックする。その後、ステップ４１０で、発信ＭＳ１０４（または協調ＭＳ１０６）は、自機のＵＢＩに応じて自機のＨＦＢＣＨインデックスを算出する。ステップ４０６で、発信ＭＳ１０４（または協調ＭＳ１０６）のフローが現在のフレームにスケジュールされていなければ、方法４００はステップ４１２で終了する。
IEEE P802.16m/D5, DRAFT Amendment to IEEE Standard for local and metropolitan area networks - Part 16: Air Interface for Broadband Wireless Access Systems - Advanced Air Interface IEEE C802.16-10/0016r1, Future 802.16 Networks: Challenges and Possibilities IEEE C802.16-10/0005r1, Client Cooperation in Future Wireless Broadband Networks
　ＩＥＥＥ ８０２．１６ｍ草案標準（例えば非特許文献１参照）によれば、ＣｌｉＣｏに関与する発信ＭＳ１０４及び協調ＭＳ１０６の両方が同一のデータ・バーストを処理する。発信ＭＳ１０４及び協調ＭＳ１０６の両方に用いる一つのＨＦＢＣＨがあれば十分である。しかしながら、同一グループにおいてＵＢＩが異なるため、発信ＭＳ１０４及び協調ＭＳ１０６は２つの異なるＨＦＢＣＨを有する。これは、貴重なＨＦＢＣＨリソースを浪費することになる。
　本発明の目的は、同一データ・バーストを処理する複数のＭＳに対して一つのＨＢＣＨを使用することで、不必要なＨＦＢＣＨリソースの浪費を避けることができる基地局、移動局、協調移動局、送信方法及び受信方法を提供することである。
　本発明の一態様によれば、複数の移動局（ＭＳｓ）と通信する基地局（ＢＳ）は、上記複数のＭＳｓの各々に対するリソース割当情報を示す制御信号を生成する制御信号生成部と上記複数のＭＳｓへ上記制御信号を送信する送信部を含む構成をとり、ある移動局（ＭＳ）に対する制御信号は、他のＭＳに関する情報を含む。
　本発明の一態様によれば、ＢＳは、発信ＭＳと、ＢＳと上記発信ＭＳとの間の通信のために利用される協調ＭＳを含む複数のＭＳｓと通信し、上記複数のＭＳｓの各々に対するリソース割当情報を示す制御信号を生成する制御信号生成部と、上記複数のＭＳｓへ上記制御信号を送信する送信部を具備し、上記協調ＭＳに対する制御信号は、上記発信ＭＳに関する情報を含む。
　本発明の一態様によれば、上記協調ＭＳのフローが上記発信ＭＳと同じグループに加えられる場合、上記協調ＭＳに対する制御信号は、上記発信ＭＳに関する情報を含む。
　本発明の一態様によれば、上記発信ＭＳに関する情報は、上記協調ＭＳに対するリソース割当情報の中に含まれる。
　本発明の一態様によれば、上記発信ＭＳに関する情報は、上記協調ＭＳに対するバースト・サイズ情報と入れ換えられる。
　本発明の一態様によれば、上記発信ＭＳに関する情報のビット数は、上記発信ＭＳと同じグループに属するＭＳｓの数に応じて変わる。
　本発明の一態様によれば、上記発信ＭＳと同じグループに属するＭＳｓの数に応じて、上記協調ＭＳに対するバースト・サイズ情報のビット数が増加するのに伴い、かつ、上記協調ＭＳに対するリソース・サイズ情報のビット数が減少するのに伴い、上記発信ＭＳに関する情報のビット数は変わる。
　本発明の一態様によれば、上記協調ＭＳに対するリソース・サイズ情報のビット数が減少する場合、上記協調ＭＳの実際のリソース・サイズは、上記発信ＭＳのリソース・サイズと上記協調ＭＳの公称リソース・サイズのビット単位の演算結果として得られる。
　本発明の一態様によれば、上記協調ＭＳのリソース・サイズは、上記発信ＭＳのリソース・サイズと同じであり、上記発信ＭＳに関する情報は、上記協調ＭＳに対するバースト・サイズ情報及びリソース・サイズ情報と入れ換えられる。
　本発明の一態様によれば、上記協調ＭＳの実際のリソース・サイズは、上記発信ＭＳのリソース・サイズと上記協調ＭＳの公称リソース・サイズのビット単位の演算結果として得られる。
　本発明の一態様によれば、上記協調ＭＳのリソース・サイズは予め決められた値に設定され、上記発信ＭＳに関する情報は、上記協調ＭＳに対するバースト・サイズ情報及びリソース・サイズ情報と入れ換えられる。
　本発明の一態様によれば、上記発信ＭＳに関する情報は、上記発信ＭＳの識別情報である。
　本発明の一態様によれば、上記発信ＭＳに関する情報は、上記協調ＭＳの識別情報に相対する、上記発信ＭＳの識別情報のオフセットである。
　本発明の一態様によれば、ＭＳは、他のＭＳに関する情報を含む、自機に対する制御信号を受信する受信部と、上記制御信号、及び、上記他のＭＳに関する情報に応じて、送信リソースを算出するリソース算出部を具備する。
　本発明の一態様によれば、ＢＳと発信ＭＳとの間の通信のために利用される協調ＭＳは、上記発信ＭＳに関する情報を含む自協調ＭＳに対する制御信号を受信する受信部、上記制御信号、及び、上記発信ＭＳに関する情報に応じて、送信リソースを算出するリソース算出部、及び上記発信ＭＳから受信した信号を、上記送信リソースを介して上記ＢＳへ送信する送信部を具備する。
　本発明の一態様によれば、上記発信ＭＳに関する情報が上記協調ＭＳの識別情報を示す場合は、上記送信部は、上記ＢＳへの上記信号の送信を停止する。
　本発明の一態様によれば、上記発信ＭＳに関する情報が上記協調ＭＳの識別情報を示す場合は、上記送信部は、予め決められた期間または設定可能な期間の間、上記ＢＳへの上記信号の送信を停止する。
　本発明の一態様によれば、上記発信ＭＳに関する情報の一部分は、上記協調ＭＳに対するリソース割当情報の中に含まれ、上記発信ＭＳに関する情報のその他の部分は、上記協調ＭＳへ送信されるグループ・コンフィギュレーション情報の中に含まれる。
　本発明の一実施形態によれば、複数のＭＳｓと通信するＢＳにおいて実行される送信方法は、上記複数のＭＳｓの各々に対するリソース割当情報を示す制御信号を生成し、上記複数のＭＳｓへ上記制御信号を送信し、あるＭＳに対する制御信号は、他のＭＳに関する情報を含む。
　本発明の一実施形態によれば、発信ＭＳと、ＢＳと上記発信ＭＳとの間の通信のために利用される協調ＭＳを含む複数のＭＳｓと通信する基地局（ＢＳ）において実行される送信方法は、上記複数のＭＳｓの各々に対するリソース割当情報を示す制御信号を生成し、上記複数のＭＳｓへ上記制御信号を送信し、上記協調ＭＳに対する制御信号は、上記発信ＭＳに関する情報を含む。
　本発明の一実施形態によれば、ＭＳにおいて実行される受信方法は、他のＭＳに関する情報を含む自機に対する制御信号を受信し、上記制御信号及び上記他のＭＳに関する情報に応じて送信リソースを算出する。
　本発明の一実施形態によれば、ＢＳと発信ＭＳとの間の通信のために利用される協調ＭＳにおいて実行される受信方法は、上記発信ＭＳに関する情報を含む自機に対する制御信号を受信し、上記制御信号及び上記発信ＭＳに関する情報に応じて、送信リソースを算出し、上記発信ＭＳから受信した信号を、上記送信リソースを介して上記ＢＳへ送信する。
　本発明の上記及びその他の特徴と利点は、添付の図面とともに本発明の以下の詳細な説明を参照し、添付の特許請求の範囲を参照することで、よりよく理解されることになろう。
　本発明は同一データ・バーストを処理する複数のＭＳｓに対して一つのＨＢＣＨを使用するので、不必要なＨＦＢＣＨリソースの浪費を避けることができる。
ＣｌｉＣｏ（クライアント協調動作）を行う無線通信システムの一例を示す図 ＢＳ（基地局）の一例を示すブロック図 発信ＭＳ（移動局）の一例を示すブロック図 協調ＭＳ（移動局）の一例を示すブロック図 フレーム構成の一例を示す図 従来技術による、一部のグループ・リソース割当情報を通知するビットマップの一例を示す図 従来技術による、発信ＭＳ（または協調するＭＳ）でグループ・リソース割当情報を受信する方法を例示するフローチャート 本発明の実施の形態１に係る協調するＭＳでグループ・リソース割当情報を受信する方法を例示するフローチャート 本発明の実施の形態２に係る４ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためビットマップの一例を示す図 本発明の実施の形態２に係る４ビットのユーザ・ビットマップの場合における、協調するＭＳでグループ・リソース割当情報を受信する方法を例示するフローチャート 本発明の実施の形態２に係る８ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためビットマップの一例を示す図 本発明の実施の形態２に係る８ビットのユーザ・ビットマップの場合における、協調するＭＳでグループ・リソース割当情報を受信する方法を例示するフローチャート 本発明の実施の形態２に係る３２ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためのビットマップの一例を示す図 本発明の実施の形態２に係る３２ビットのユーザ・ビットマップの場合における、協調するＭＳでグループ・リソース割当情報を受信する方法を例示するフローチャート 本発明の実施の形態３に係る４ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためのビットマップの一例を示す図 本発明の実施の形態４に係る８ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためのビットマップの一例を示す図 本発明の実施の形態５に係る８ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためのビットマップの一例を示す図
　以下、本発明の実施の形態について、添付図面を参照して詳細に説明する。本願明細書に援用する周知の機能及び構成の詳細な説明は、明確かつ簡潔にするために省略した。
　（実施の形態１）
　本発明の実施の形態１によれば、図１に準拠して、ＧＲＡをＣｌｉＣｏに適用する方法の基本概念は、ＢＳ１０２が、グループ・コンフィギュレーション情報を用いて、発信ＭＳ１０４のＵＢＩを協調ＭＳ１０６に共有させることである。より詳細には、ＢＳ１０２が協調ＭＳ１０６のフローをグループに加えるとき、ＢＳ１０２によって協調ＭＳ１０６へユニキャストされるグループ・コンフィギュレーション情報は、発信ＭＳ１０４のＵＢＩをも含む。ＢＳ１０２によって協調ＭＳ１０６へユニキャストされるグループ・コンフィギュレーション情報の内容は、以下に挙げることができる。
　・　協調ＭＳ１０６のフロー識別子、
　・　ユーザ・ビットマップ・サイズ、
　・　発信ＭＳ１０４のＵＢＩ、
　・　協調ＭＳ１０６のＵＢＩ、
　・　グループ識別子、 
　・　割当て周期、及び
　・　ＭＩＭＯモード・セット、等
　本発明の実施の形態１によれば、協調ＭＳ１０６は発信ＭＳ１０４のＵＢＩを知るので、協調ＭＳ１０６は、自機のＨＦＢＣＨインデックスを導出するために、自機自身のＵＢＩの代わりに発信ＭＳ１０４のＵＢＩを使用することができる。その結果、同一のＨＦＢＣＨのみが、ＣｌｉＣｏに関与する発信ＭＳ１０４及び協調ＭＳ１０６の両方に割り当てられる。したがって、不必要なＨＦＢＣＨリソースの浪費が避けられる。
　本発明の実施の形態１による、協調ＭＳ１０６でリソース・スケジューリング情報を受信するための方法５００を例示するフローチャートを図８に示す。方法５００はステップ５０２で開始する。ステップ５０４において、協調ＭＳ１０６は、自機のＵＢＩに照らしてユーザ・ビットマップをチェックする。ステップ５０６では、協調ＭＳ１０６は、自機のフローが現在のフレームにスケジュールされているか否かを判定する。協調ＭＳ１０６のフローが現在のフレームにスケジュールされていれば、ステップ５０８において、協調ＭＳ１０６は、自機のＨＡＲＱバースト・サイズ及びリソース・サイズを導出するために、自機のＵＢＩに照らしてリソース割当ビットマップをチェックする。ステップ５１０では、協調ＭＳ１０６は、発信ＭＳ１０４のＵＢＩに応じて自機のＨＦＢＣＨインデックスを算出する。ステップ５０６で、協調ＭＳ１０６のフローが現在のフレームにスケジュールされていなければ、方法５００はステップ５１２で終了する。
　本発明の実施の形態１によれば、ＢＳ１０２によって発信ＭＳ１０４へユニキャストされるグループ・コンフィギュレーション情報の内容と、ＢＳ１０２によって発信ＭＳ１０４及び協調ＭＳ１０６へマルチキャストされるグループ・リソース割当情報の内容とは、ＩＥＥＥ ８０２．１６ｍ草案標準（例えば、非特許文献１参照）と同じである。しかしながら、ＢＳ１０２によって協調ＭＳ１０４へユニキャストされるグループ・コンフィギュレーション情報の内容は、ＩＥＥＥ ８０２．１６ｍ草案標準（例えば、非特許文献１参照）とは異なる。
　本発明の実施の形態１によると、代替的な手法は、グループ・コンフィギュレーション情報が、ＢＳ１０２によって発信ＭＳ１０４と協調ＭＳ１０６の両方へマルチキャストされることである。ＢＳ１０２によって発信ＭＳ１０４及び協調ＭＳ１０６の両方へマルチキャストされるグループ・コンフィギュレーション情報の内容は、以下に挙げることができる。
　・　発信ＭＳ１０４のフロー識別子、
　・　協調ＭＳ１０６のフロー識別子、
　・　ユーザ・ビットマップ・サイズ、
　・　発信ＭＳ１０４のＵＢＩ、
　・　協調ＭＳ１０６のＵＢＩ、
　・　グループ識別子、
　・　割当て周期、及び
　・　ＭＩＭＯモード・セット、等
　本発明の実施の形態１によれば、グループ・コンフィギュレーション情報は、ＭＡＣ制御メッセージまたはＭＡＰ ＩＥのいずれかで送信され得る。
　（実施の形態２）
　本発明の実施の形態１によれば、発信ＭＳ１０４のＵＢＩを協調ＭＳ１０６に共有させることによって、グループ・リソース割当を開始する前の段階でグループ・コンフィギュレーション情報に追加の制御オーバヘッドが導入される可能性があるという欠点がある。
　図１に準拠して、前述したとおり、ＣｌｉＣｏに関与する発信ＭＳ１０４及び協調ＭＳ１０６は同一のデータ・バーストを処理するため、同一のＨＡＲＱバースト・サイズを有することになる。したがって、発信ＭＳ１０４及び協調ＭＳ１０６のいずれか一方に対するＨＡＲＱバースト・サイズ指示は不必要である。さらに、実際に必要とされるＵＢＩの長さは、ユーザ・ビットマップ・サイズに依存する。例えば、ユーザ・ビットマップ・サイズが８ビットである場合、５ビットのＵＢＩではなく３ビットのＵＢＩのみが実際に必要とされる。
　本発明の実施の形態２によれば、ＧＲＡをＣｌｉＣｏに適用する方法の基本概念は、ＢＳ１０２が、本発明の実施の形態１におけるグループ・コンフィギュレーション情報の代わりに、グループ・リソース割当情報を用いて、発信ＭＳ１０４のＵＢＩを協調ＭＳ１０６に共有させることである。より詳細には、ＢＳ１０２が発信ＭＳ１０４及び協調ＭＳ１０６にリソースを割り当てる場合、リソース割当ビットマップ中の協調ＭＳ１０６用の５ビットのリソース割当指示の可変部分が、発信ＭＳ１０４のＵＢＩを指示するために使用される。上記可変部分の長さはユーザ・ビットマップ・サイズに依存する。協調ＭＳ１０６用の上記５ビットのリソース割当指示の残りの部分は、協調ＭＳのリソース・サイズを指示するために使用される。ただし、協調ＭＳ１０６のリソース・サイズを指示するための方法は、ユーザ・ビットマップ・サイズに応じて異なる。
　本発明の実施の形態２によれば、発信ＭＳ１０４のＵＢＩはリソース割当てビットマップに組み込まれているので、グループ・コンフィギュレーション情報に追加の制御オーバヘッドが導入されることはない。
　本発明の実施の形態２による、４ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するビットマップの一例を図９に示す。図９を参照すると、リソース割当ビットマップ６０４の中で、協調ＭＳ１０６用の５ビットのリソース割当指示の最初の２ビット（例えば、「００」）が、協調ＭＳ１０６のＨＡＲＱバースト・サイズではなく、発信ＭＳ１０４のＵＢＩを指示するために使用され、最後の３ビット（例えば、「０１０」）が、協調ＭＳ１０６用のリソース・サイズを伝えるために使用される。なお、発信ＭＳ１０４用の５ビットのリソース割当指示の最初の２ビット（例えば、「１０」）は、発信ＭＳ１０４及び協調ＭＳ１０６の両方のＨＡＲＱバースト・サイズを伝えるために使用されることに留意されたい。
　本発明の実施の形態２による、４ビットのユーザ・ビットマップの場合における、協調ＭＳ１０６でグループ・リソース割当情報を受信するための方法７００を例示するフローチャートを図１０に示す。方法７００はステップ７０２で開始する。ステップ７０４において、協調ＭＳ１０６は、自機のＵＢＩに照らしてユーザ・ビットマップをチェックする。ステップ７０６では、協調ＭＳ１０６は、自機のフローが現在のフレームにスケジュールされているか否かを判定する。協調ＭＳ１０６のフローが現在のフレームにスケジュールされていれば、ステップ７０８において、協調ＭＳ１０６は、発信ＭＳ１０４のＵＢＩと自機のリソース・サイズを導出するために、自機のＵＢＩに照らしてリソース割当ビットマップをチェックする。ステップ７１０では、協調ＭＳ１０６は、自機のＨＡＲＱバースト・サイズを導出するために、発信ＭＳ１０４のＵＢＩに照らしてリソース割当てビットマップを再びチェックする。ステップ７１２で、協調ＭＳ１０６は、発信ＭＳ１０４のＵＢＩに応じて自機のＨＦＢＣＨインデックスを算出する。ステップ７０６において、協調ＭＳ１０６のフローが現在のフレームにスケジュールされていなければ、方法７００はステップ７１４で終了する。
　本発明の実施の形態２による、８ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためのビットマップの一例を図１１に示す。図１１を参照すると、リソース割当ビットマップ８０４の中で、協調ＭＳ１０６用の５ビットのリソース割当指示の最初の３ビットが、発信ＭＳ１０４のＵＢＩを指示するために使用され、最後の２ビットが、協調ＭＳ１０６の実際のリソース・サイズではなく、協調ＭＳ１０６の公称リソース・サイズを指示するために使用される。
　協調ＭＳの公称リソース指示から協調ＭＳ１０６の実際のリソース・サイズ指示を算出する手法はいろいろある。一つの手法では、協調ＭＳ１０６の実際のリソース・サイズ指示は、発信ＭＳ１０４のリソース・サイズ指示と協調ＭＳ１０６の公称リソース・サイズ指示とのビット単位の排他論理和演算の結果として得ることができる。図１１を参照すると、発信ＭＳ１０４のリソース・サイズ指示が「１１１」であり、協調ＭＳ１０６の公称リソース・サイズ指示が「０１」である。したがって、協調ＭＳ１０６の実際のリソース・サイズ指示は、「１１１　ＸＯＲ　０１ ＝ １１０」となる。別の手法では、協調ＭＳ１０６の実際のリソース・サイズ指示は、発信ＭＳ１０４のリソース・サイズ指示と協調ＭＳ１０６の公称リソース・サイズ指示とのビット単位の論理和または論理積の結果として得ることができる。
　本発明の実施の形態２による、８ビットのユーザ・ビットマップの場合における、協調ＭＳ１０６でグループ・リソース割当情報を受信するための方法９００を例示するフローチャートを図１２に示す。方法９００はステップ９０２で開始する。ステップ９０４において、協調ＭＳ１０６は、自機のＵＢＩに照らしてユーザ・ビットマップをチェックする。ステップ９０６で、協調ＭＳ１０６は、自機のフローが現在のフレームにスケジュールされているか否かを判定する。協調ＭＳ１０６のフローが現在のフレームにスケジュールされていれば、ステップ９０８において、協調ＭＳ１０６は、発信ＭＳ１０４のＵＢＩを導出するために、リソース割当てビットマップをチェックする。ステップ９１０では、協調ＭＳ１０６は、自機のＨＡＲＱバースト・サイズとリソース・サイズを導出するために、自機のＵＢＩと発信ＭＳ１０４のＵＢＩに照らしてリソース割当ビットマップを再びチェックする。ステップ９１２で、協調ＭＳ１０６は、発信ＭＳ１０４のＵＢＩにより自機のＨＦＢＣＨインデックスを算出する。ステップ９０６において、協調ＭＳ１０６のフローが現在のフレームにスケジュールされていなければ、方法９００はステップ９１４で終了する。
　本発明の実施の形態２によれば、８ビットのユーザ・ビットマップの場合と同様に、１６ビットのユーザ・ビットマップの場合には、リソース割当ビットマップ中で、協調ＭＳ１０６用の５ビットのリソース割当指示の最初の４ビットが、発信ＭＳ１０４のＵＢＩを指示するために使用され、最後の１ビットが、協調ＭＳ１０６の実際のリソース・サイズではなく、協調ＭＳ１０６の公称リソース・サイズを指示するために使用される。
　本発明の実施の形態２による、３２ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためのビットマップの一例を図１３に示す。図１３を参照すると、リソース割当てビットマップ１００４の中で、協調ＭＳ１０６用の５ビットのリソース割当指示の全部が、発信ＭＳ１０４のＵＢＩを指示するために使用される。協調ＭＳ１０６のリソース・サイズは、発信ＭＳ１０４用の３ビットのリソース・サイズ指示によって伝えられる。つまり、３２ビットのユーザ・ビットマップの場合には、発信ＭＳ１０４と協調ＭＳ１０６は常に同じリソース・サイズを有する。
　本発明の実施の形態２による、グループ・リソース割当情報を送信するためのＧＲＡ ＭＡＰ ＩＥの一例を表２に示す。
Figure JPOXMLDOC01-appb-T000002
　本発明の実施の形態２による、３２ビットのユーザ・ビットマップの場合における、協調ＭＳ１０６でグループ・リソース割当情報を受信するための方法１１００を例示するフローチャートを図１４に示す。方法１１００はステップ１１０２で開始する。ステップ１１０４において、協調ＭＳ１０６は、自機のＵＢＩに照らしてユーザ・ビットマップをチェックする。ステップ１１０６で、協調ＭＳ１０６は、自機のフローが現在のフレームにスケジュールされているか否かを判定する。協調ＭＳ１０６のフローが現在のフレームにスケジュールされていれば、ステップ１１０８において、協調ＭＳ１０６は、発信ＭＳ１０４のＵＢＩを導出するために、リソース割当てビットマップをチェックする。ステップ１１１０では、協調ＭＳ１０６は、自機のＨＡＲＱバースト・サイズとリソース・サイズを導出するために、発信ＭＳ１０４のＵＢＩに照らしてリソース割当ビットマップを再びチェックする。ステップ１１１２で、協調ＭＳ１０６は、発信ＭＳ１０４のＵＢＩに応じて、自機のＨＦＢＣＨインデックスを算出する。ステップ１１０６において、協調ＭＳ１０６のフローが現在のフレームにスケジュールされていなければ、方法１１００はステップ１１１４で終了する。
　協調ＭＳ１０６の視点からは、方法７００、９００及び１１００の間の違いは、自機のリソース・サイズを導出する方法にある。方法７００では、協調ＭＳ１０６のリソース・サイズは、自機自身のＵＢＩに照らして導出される。方法９００では、協調ＭＳ１０６のリソース・サイズは、自機自身のＵＢＩと発信ＭＳ１０４のＵＢＩとに照らして導出される。方法１１００では、協調ＭＳ１０６のリソース・サイズは、発信ＭＳ１０４のＵＢＩのみに照らして導出される。
　本発明の実施の形態２によれば、８ビットのユーザ・ビットマップの場合の代替的な手法は、リソース割当ビットマップの中で、協調ＭＳ１０６用の５ビットのリソース割当指示の最初の３ビットは、発信ＭＳ１０４のＵＢＩを指示するために使用されるが、最後の２ビットは、協調ＭＳ１０６の公称リソース・サイズではなく、協調ＭＳ１０６の実際のリソース・サイズを伝えるために使用される。同様に、１６ビットのユーザ・ビットマップの場合の代替的な手法は、リソース割当ビットマップの中で、協調ＭＳ１０６用の５ビットのリソース割当指示の最初の４ビットは、発信ＭＳ１０４のＵＢＩを指示するために使用されるが、最後の１ビットは、協調ＭＳ１０６の実際のリソース・サイズを指示するために使用される。
　本発明の実施の形態２によれば、４ビットのユーザ・ビットマップの場合の代替的な手法は、リソース割当ビットマップの中で、協調ＭＳ１０６用の５ビットのリソース割当指示の最初の２ビットは、発信ＭＳ１０４のＵＢＩを指示するために使用されるが、最後の３ビットは、協調ＭＳ１０６の実際のリソース・サイズではなく、協調ＭＳ１０６の公称リソース・サイズを指示するために使用される。協調ＭＳ１０６の実際のリソース・サイズは、発信ＭＳ１０４のリソース・サイズ指示と協調ＭＳ１０６の公称リソース・サイズ指示から上述した方式で導出することができる。
　本発明の実施の形態２によれば、３２ビットのユーザ・ビットマップの場合の代替的な手法は、リソース割当ビットマップの中の協調ＭＳ１０６の５ビットのリソース割当指示の全部が、発信ＭＳ１０４のＵＢＩを伝えるために使用されるが、協調ＭＳ１０６のリソース・サイズは常に予め決められた値に設定される。
　本発明の実施の形態２によれば、ＢＳ１０２によって発信ＭＳ１０４または協調ＭＳ１０６へユニキャストされるグループ・コンフィギュレーション情報の内容は、ＩＥＥＥ ８０２．１６ｍ草案標準（例えば、非特許文献１参照）と同じである。しかしながら、ＢＳ１０２によって発信ＭＳ１０４または協調ＭＳ１０６へマルチキャストされるグループ・リソース割当情報の内容は、ＩＥＥＥ ８０２．１６ｍ草案標準（例えば、非特許文献１参照）とは異なる。
　本発明の実施の形態２によれば、グループ・リソース割当情報は、マルチキャストＭＡＣ制御情報またはマルチキャストＭＡＰ ＩＥのいずれかで送信され得る。
　（実施の形態３）
　本発明の第１及び実施の形態２によれば、リソース割当ビットマップの中の発信ＭＳ１０４のＵＢＩ指示は、協調ＭＳ１０６のＵＢＩとは異なると仮定されている。以下では、リソース割当ビットマップの中の発信ＭＳ１０４のＵＢＩ指示が協調ＭＳ１０６のＵＢＩと同じである場合を取り上げる。
　本発明の実施の形態３による、４ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためのビットマップの一例を図１５に示す。図１５を参照すると、リソース割当ビットマップ１２０４の中で、協調ＭＳ１０６用の５ビットのリソース割当指示の最初の２ビットが、発信ＭＳ１０４のＵＢＩを指示するために使用される。発信ＭＳ１０４のＵＢＩ指示（例えば、「１０」）が協調ＭＳ１０６のＵＢＩと同じである場合には、様々な暗示を生じさせ得る。例えば、通信相手のＭＳ１０６は、その後のＮ個の連続割当期間にＵＬ／ＤＬデータ・バーストを送信／受信しないことを暗示し得る。ここでＮは予め決められている。または、Ｎの値は協調ＭＳ１０６用の５ビットのリソース割当指示の最後の３ビットによって指示される。あるいは、協調ＭＳ１０６が今後はＵＬ／ＤＬデータ・バーストを送信／受信しないことを暗示し得る。
　本発明の実施の形態３によれば、８ビット、１６ビット、または３２ビットのユーザ・ビットマップの場合において、リソース割当ビットマップ中の発信ＭＳ１０４のＵＢＩ指示が協調ＭＳ１０６のＵＢＩと同じである場合、４ビットのユーザ・ビットマップの場合と同様の暗示を生じさせ得る。
　（実施の形態４）
　本発明の実施の形態１，２，３によれば、発信ＭＳ１０４のＵＢＩ指示値の長さは、ユーザ・ビットマップのサイズに依存している。その結果、４ビットのユーザ・ビットマップの場合には、協調ＭＳ１０６のリソース・サイズを伝えるために３ビットが使用可能である。したがって、協調ＭＳ１０６へリソースを割り当てるために８個のリソース・サイズのセットの全部が使用可能となる。しかし、８ビット、１６ビット、または３２ビットのユーザ・ビットマップの場合には、協調ＭＳ１０６へリソースを割り当てるために８個のリソース・サイズのセットの一部しか使用できない。これは、ＢＳ１０２のスケジューリングの柔軟性を低下させる。
　本発明の実施の形態４による、８ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためのビットマップの一例を図１６に示す。図１６を参照すると、リソース割当ビットマップ１３０４の中で、協調ＭＳ１０６用の５ビットのリソース割当指示の最初の２ビットだけが、協調ＭＳ１０６のＵＢＩに相対する発信ＭＳ１０４のＵＢＩのオフセットを指示するために使用され、最後の３ビットが、協調ＭＳ１０６のリソース・サイズを指示するために使用される。
　本発明の実施の形態４による、グループ・リソース割当情報を送信するためのＧＲＡ ＭＡＰ ＩＥの一例を表３に示す。
Figure JPOXMLDOC01-appb-T000003
　本発明の実施の形態４によれば、８ビット、１６ビット、または３２ビットのユーザ・ビットマップの場合に、発信ＭＳ１０６のＵＢＩ指示のために２ビットだけが使用されるので、ＢＳ１０２が発信ＭＳ１０４と協調ＭＳ１０６のそれぞれのフローをグループに加える際に、いろいろな制約が課せられる必要がある。発信ＭＳ１０４と協調ＭＳ１０６のそれぞれのフローをグループに加える際に、ＢＳ１０２は、例えば、下記の制約を受けることがあり得る。  
　・　発信ＭＳ１０４のＵＢＩは協調ＭＳ１０６のＵＢＩよりも小さい、及び
　・　発信ＭＳ１０４のＵＢＩと協調ＭＳ１０６のＵＢＩとの差が４よりも大きい
　本発明の実施の形態４によれば、協調ＭＳ１０６のリソース・サイズを指示するために３ビットが使用されるので、８ビット、１６ビット、または３２ビットのユーザ・ビットマップの場合にも、協調ＭＳ１０６のリソースを割り当てるために、８個のリソース・サイズのセットの全部を使用できる。
　（実施の形態５）
　本発明の実施の形態４によれば、ＢＳ１０２が発信ＭＳ１０４と協調ＭＳ１０６のそれぞれのフローをグループに加えるときに、いくつかの制約が課せられる必要がある。これは、ＢＳ１０２のグループ・コンフィギュレーションの柔軟性を低下させる可能性がある。
　本発明の実施の形態５による、８ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためのビットマップの一例を図１７に示す。図１７を参照すると、リソース割当ビットマップ１４０４の中で、協調ＭＳ１０６用の５ビットのリソース割当指示の最初の２ビットが、発信ＭＳ１０４のＵＢＩの第１の部分を指示するために使用され、最後の３ビットが、協調ＭＳ１０６のリソース・サイズを指示するために使用される。
　本発明の実施の形態５による、グループ・リソース割当情報を送信するためのＧＲＡ ＭＡＰ ＩＥの一例を表４に示す。
Figure JPOXMLDOC01-appb-T000004
　本発明の実施の形態５によれば、ＢＳ１０２によって協調ＭＳ１０６へユニキャストされるグループ・コンフィギュレーション情報は、発信ＭＳ１０４のＵＢＩの第２の部分を含む。ＢＳ１０２によって協調ＭＳ１０６へユニキャストされるグループ・コンフィギュレーション情報の内容は、以下に挙げることができる。 
　・　協調ＭＳ１０６のフロー識別子、
　・　ユーザ・ビットマップ・サイズ、
　・　発信ＭＳ１０４のＵＢＩの第２の部分、
　・　協調ＭＳ１０６のＵＢＩ、
　・　グループＩＤ、 
　・　割当て周期、及び
　・　ＭＩＭＯモード・セット、等
　本発明の実施の形態５によれば、８ビットのユーザ・ビットマップの場合に、グループ・コンフィギュレーション情報及びグループ・リソース割当情報で通知される３ビットが、発信ＭＳ１０６のＵＢＩ指示のために使用され、ＢＳ１０２が発信ＭＳ１０４と協調ＭＳ１０６のそれぞれのフローをグループに加えるときに何の制約も課されない。
　本発明の実施の形態５によれば、発信ＭＳ１０４のＵＢＩの第１の部分は、発信ＭＳ１０４のＵＢＩのＬＳＢ（最下位ビット）側の２ビットであり得る。発信ＭＳ１０４のＵＢＩの第２の部分は、８ビット、１６ビット及び３２ビットのユーザ・ビットマップの場合にそれぞれ対応して、発信ＭＳ１０４のＵＢＩのＭＳＢ（最上位ビット）の１ビット、ＭＳＢ側の２ビット及びＭＳＢ側の３ビットであり得る。
　本発明の実施の形態５によれば、代替的に、発信ＭＳ１０４のＵＢＩの第１の部分は、発信ＭＳ１０４のＵＢＩのＭＳＢ側の２ビットであり得る。発信ＭＳ１０４のＵＢＩの第２の部分は、８ビット、１６ビット及び３２ビットのユーザ・ビットマップの場合にそれぞれ対応して、発信ＭＳ１０４のＵＢＩのＬＳＢの１ビット、ＬＳＢ側の２ビット及びＬＳＢ側の３ビットであり得る。本発明の上述した個々の実施形態によれば、協調ＭＳ１０６が自機のＨＦＢＣＨを算出するために発信ＭＳ１０４のＵＢＩを使用できるように、ＢＳ１０２は発信ＭＳ１０４のＵＢＩを 協調ＭＳ１０６に共有させる。ＢＳ１０２が協調ＭＳ１０６のＵＢＩを発信ＭＳ１０４に共有させるような、本発明の多様な変形及び／または修正が行なえることは当業者には当然理解されるであろう。
　本発明の上述した個々の実施形態によれば、発信ＭＳ１０４に加えて、１台の協調ＭＳ１０６だけがＣｌｉＣｏにかかわり合う。２台以上の協調ＭＳがＣｌｉＣｏにかかわり合い、そしてＢＳ１０２は、ＣｌｉＣｏに関与する発信ＭＳと複数の協調ＭＳのうちの一つのＵＢＩをその他のＭＳに共有させるような、本発明の多様な変形及び／または修正が行なえることは当業者には当然理解されるであろう。
　具体的な個々の実施形態として示した本発明のその他の多様な変形及び／または修正は、広義に記述された本発明の精神または範囲を逸脱しない限りにおいて行なえることは当業者には当然理解されるであろう。本文書に述べた個々の実施形態は、したがって、あらゆる点において例示であり、制限的ではないと見なされるべきある。
　なお、上記実施の形態では、本発明をハードウェアで構成する場合を例にとって説明したが、本発明はハードウェアとの連携においてソフトウェアでも実現することも可能である。
　また、上記実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるＬＳＩとして実現される。これらは個別に１チップ化されてもよいし、一部または全てを含むように１チップ化されてもよい。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。
　また、集積回路化の手法はＬＳＩに限るものではなく、専用回路または汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。
　さらには、半導体技術の進歩または派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
　２０１０年４月２０日出願の特願２０１０－０９７０２６の日本出願に含まれる明細書、図面および要約書の開示内容は、すべて本願に援用される。
　本発明は、移動体通信システム等に適用することができる。

Claims (20)

  1. 　複数の移動局と通信する基地局であって、
    　前記複数の移動局の各々に対するリソース割当情報を示す制御信号を生成する制御信号生成部と、
    　前記生成された制御信号を、前記複数の移動局へ送信する送信部と、を具備し、
    　前記複数の移動局の中の第１の移動局に対する制御信号は、前記複数の移動局の中の第２の移動局に関する情報を含む、
    　基地局。
  2. 　前記第２の移動局は前記基地局と直接通信を行う発信移動局であり、前記第１の移動局は前記基地局と前記発信移動局との間の通信のために利用される協調移動局であって、
    　前記協調移動局に対する制御信号は、前記発信移動局に関する情報を含む、
    　請求項１に記載の基地局。
  3. 　前記協調移動局が前記発信移動局と同じグループに加えられる場合、前記協調移動局に対する前記制御信号は、前記発信移動局に関する情報を含む、
    　請求項２に記載の基地局。
  4. 　前記発信移動局に関する情報は、前記協調移動局に対するリソース割当情報の中に含まれる、
    　請求項２に記載の基地局。
  5. 　前記発信移動局に関する情報は、前記協調移動局に対するバースト・サイズ情報と入れ換えられる、
    　請求項４に記載の基地局。
  6. 　前記発信移動局に関する情報のビット数は、前記発信移動局と同じグループに属する移動局の数に応じて変わる、
    　請求項２に記載の基地局。
  7. 　前記発信移動局と同じグループに属する移動局の数に応じて、前記協調移動局に対するバースト・サイズ情報のビット数が増加するのに伴い、かつ、前記協調移動局に対するリソース・サイズ情報のビット数が減少するのに伴い、前記発信移動局に関する前記情報のビット数は変わる、
    　請求項６に記載の基地局。
  8. 　前記協調移動局に対するリソース・サイズ情報のビット数が減少する場合、前記協調移動局の実際のリソース・サイズは、前記発信移動局のリソース・サイズと前記協調移動局の公称リソース・サイズのビット単位の演算結果として得られる、
    　請求項７に記載の基地局。
  9. 　前記協調移動局のリソース・サイズは、前記発信移動局のリソース・サイズと同じであり、前記発信移動局に関する情報は、前記協調移動局に対するバースト・サイズ情報及びリソース・サイズ情報と入れ換えられる、
    　請求項４に記載の基地局。
  10. 　前記協調移動局の実際のリソース・サイズは、前記発信移動局のリソース・サイズと前記協調移動局の公称リソース・サイズのビット単位の演算結果として得られる、
    　請求項４に記載の基地局。
  11. 　前記協調移動局のリソース・サイズは予め決められた値に設定され、前記発信移動局に関する情報は、前記協調移動局に対するバースト・サイズ情報及びリソース・サイズ情報と入れ換えられる、
    　請求項５に記載の基地局。
  12. 　前記発信移動局に関する情報は、前記発信移動局の識別情報である、
    　請求項２に記載の基地局。
  13. 　前記発信移動局に関する情報は、前記協調移動局の識別情報に相対する、前記発信移動局の識別情報のオフセットである、
    　請求項２に記載の基地局。
  14. 　他の移動局に関する情報を含む、自局に対する制御信号を受信する受信部と、
    　前記制御信号、及び、前記他の移動局に関する情報に応じて、送信リソースを算出するリソース算出部と、
    　を具備する移動局。
  15. 　前記他の移動局は基地局と直接通信を行う発信移動局であり、前記移動局は前記基地局と前記発信移動局との間の通信のために利用される協調移動局であって、
    　前記制御情報に含まれる前記他の移動局に関する情報は、前記発信移動局に関する情報であり、
    　前記発信移動局から受信した信号を、前記送信リソースを介して前記基地局へ送信する送信部をさらに具備する、請求項１４に記載の移動局。
  16. 　前記発信移動局に関する情報が前記協調移動局の識別情報を示す場合、前記送信部は、前記基地局への前記信号の送信を停止する、
    　請求項１５に記載の協調移動局。
  17. 　前記発信移動局に関する情報が前記協調移動局の識別情報を示す場合、前記送信部は、予め決められた期間または設定可能な期間の間、前記基地局への前記信号の送信を停止する、
    　請求項１５に記載の協調移動局。
  18. 　前記発信移動局に関する情報の一部分は、前記協調移動局に対するリソース割当情報の中に含まれ、前記発信移動局に関する情報のその他の部分は、前記協調移動局へ送信されるグループ・コンフィギュレーション情報の中に含まれる、
    　請求項２に記載の基地局。
  19. 　複数の移動局と通信する基地局において実行される送信方法であって、
    　前記複数の移動局の各々に対するリソース割当情報を示す制御信号を生成し、
    　前記生成された制御信号を、前記複数の移動局へ送信し、
    　前記複数の移動局の中の第１の移動局に対する制御信号は、前記複数の移動局の中の第２の移動局に関する情報を含む、
    　送信方法。
  20. 　移動局において実行される受信方法であって、
    　他の移動局に関する情報を含む前記移動局に対する制御信号を受信し、
    　前記制御信号、及び、前記他の移動局に関する情報に応じて、送信リソースを算出する、
    　受信方法。
PCT/JP2011/002313 2010-04-20 2011-04-20 基地局、移動局、協調移動局、送信方法及び受信方法 WO2011132413A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US13/638,729 US9031022B2 (en) 2010-04-20 2011-04-20 Base station, mobile station, coordinated mobile station, transmission method and reception method
JP2012511551A JP5669827B2 (ja) 2010-04-20 2011-04-20 基地局、移動局、協調移動局、送信方法及び受信方法
CN201180017170.5A CN102860119B (zh) 2010-04-20 2011-04-20 基站、移动台、发送方法及接收方法
US14/632,382 US9380572B2 (en) 2010-04-20 2015-02-26 Base station, mobile station, coordinated mobile station, transmission method and reception method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2010-097026 2010-04-20
JP2010097026 2010-04-20

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US13/638,729 A-371-Of-International US9031022B2 (en) 2010-04-20 2011-04-20 Base station, mobile station, coordinated mobile station, transmission method and reception method
US14/632,382 Continuation US9380572B2 (en) 2010-04-20 2015-02-26 Base station, mobile station, coordinated mobile station, transmission method and reception method

Publications (1)

Publication Number Publication Date
WO2011132413A1 true WO2011132413A1 (ja) 2011-10-27

Family

ID=44833954

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2011/002313 WO2011132413A1 (ja) 2010-04-20 2011-04-20 基地局、移動局、協調移動局、送信方法及び受信方法

Country Status (4)

Country Link
US (2) US9031022B2 (ja)
JP (2) JP5669827B2 (ja)
CN (1) CN102860119B (ja)
WO (1) WO2011132413A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014178430A1 (ja) * 2013-05-02 2014-11-06 株式会社Ｎｔｔドコモ ユーザ装置、基地局、発見リソース選択方法、及び制御信号送信方法
JP2017539105A (ja) * 2014-10-13 2017-12-28 テレフオンアクチーボラゲット エルエム エリクソン（パブル） Ｈａｒｑプロセスフィードバックのフレキシブルな設定
US10230499B2 (en) 2014-10-13 2019-03-12 Telefonaktiebolaget Lm Ericsson (Publ) HARQ feedback reporting based on mirrored information

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102783237A (zh) * 2010-03-01 2012-11-14 交互数字专利控股公司 用于执行混合每个站和每个流上行链路分配的方法和设备
US9301123B2 (en) * 2011-05-26 2016-03-29 Lg Electronics Inc. Method and apparatus for confirming validity of candidate cooperative device list for client cooperation in wireless communication system
KR101527670B1 (ko) * 2011-05-26 2015-06-09 엘지전자 주식회사 무선 통신 시스템에서 클라이언트 협력을 위한 연결 설정 방법 및 장치
US9549355B2 (en) * 2015-05-08 2017-01-17 Bandwidth.Com, Inc. Optimal use of multiple concurrent internet protocol (IP) data streams for voice communications
US9398165B2 (en) * 2015-05-08 2016-07-19 Bandwidth.Com, Inc. Optimal use of multiple concurrent internet protocol (IP) data streams for voice communications
JP6584929B2 (ja) * 2015-11-17 2019-10-02 株式会社東芝 無線通信装置及び無線ネットワーク
CN107547179A (zh) * 2016-06-23 2018-01-05 中兴通讯股份有限公司 物理层传输参数配置、获取方法及装置

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006094388A (ja) * 2004-09-27 2006-04-06 Ntt Docomo Inc 通信装置、通信システムおよび通信方法

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7016673B2 (en) * 2002-10-01 2006-03-21 Interdigital Technology Corporation Wireless communication method and system with controlled WTRU peer-to-peer communications
US7336923B2 (en) * 2003-12-03 2008-02-26 Intel Corporation Method, apparatus and system for extending wireless network coverage
US7917166B2 (en) 2006-06-16 2011-03-29 Samsung Electronics Co., Ltd. System and method for controlling power in a communication system
US8019373B2 (en) * 2006-06-16 2011-09-13 Samsung Electronics Co., Ltd System and method for controlling power in a communication system
WO2008114510A1 (ja) * 2007-03-19 2008-09-25 Panasonic Corporation 無線通信基地局装置および無線通信方法
GB0716028D0 (en) * 2007-08-16 2007-09-26 Fujitsu Ltd Communication systems
CN101553034B (zh) * 2008-03-31 2012-10-10 中兴通讯股份有限公司 资源分配方法
KR101548957B1 (ko) * 2008-07-24 2015-09-02 삼성전자주식회사 긴급 통화를 위한 무선 통신 시스템 및 이를 위한 방법

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006094388A (ja) * 2004-09-27 2006-04-06 Ntt Docomo Inc 通信装置、通信システムおよび通信方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
INUK JUNG ET AL.: "Study Report on Hierarchical Networks", 802.16PPC-10/0008R3, 17 January 2011 (2011-01-17) *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014178430A1 (ja) * 2013-05-02 2014-11-06 株式会社Ｎｔｔドコモ ユーザ装置、基地局、発見リソース選択方法、及び制御信号送信方法
JP2017539105A (ja) * 2014-10-13 2017-12-28 テレフオンアクチーボラゲット エルエム エリクソン（パブル） Ｈａｒｑプロセスフィードバックのフレキシブルな設定
US10230499B2 (en) 2014-10-13 2019-03-12 Telefonaktiebolaget Lm Ericsson (Publ) HARQ feedback reporting based on mirrored information
US10630428B2 (en) 2014-10-13 2020-04-21 Telefonaktiebolaget Lm Ericsson (Publ) Flexible configuration of HARQ process feedback
US11595157B2 (en) 2014-10-13 2023-02-28 Telefonaktiebolaget Lm Ericsson (Publ) Flexible configuration of HARQ process feedback

Also Published As

Publication number Publication date
US9380572B2 (en) 2016-06-28
JP5669827B2 (ja) 2015-02-18
JP2015080256A (ja) 2015-04-23
JPWO2011132413A1 (ja) 2013-07-18
CN102860119A (zh) 2013-01-02
US20150173053A1 (en) 2015-06-18
US9031022B2 (en) 2015-05-12
US20130021981A1 (en) 2013-01-24
JP5885817B2 (ja) 2016-03-16
CN102860119B (zh) 2015-07-29

Similar Documents

Publication Publication Date Title
JP5885817B2 (ja) 移動局及び受信方法
US10693599B2 (en) Method and apparatus for partial retransmission in wireless cellular communication system
US10298362B2 (en) Method and apparatus for partial retransmission in wireless cellular communication system
EP2109338B1 (en) Indicating the frame offset of Multicast Broadcast Service data bursts in an MBS-MAP message
US7570916B2 (en) Method and apparatus for providing and obtaining broadcast multicast service feedback
JP2024023630A (ja) 送信デバイス、受信デバイス、送信方法、受信方法及び集積回路
US20230120684A1 (en) Soft buffer management method and device of terminal in communication system
CN111149403A (zh) 无线蜂窝通信系统中传输上行链路控制信道的方法和设备
JP5567128B2 (ja) Ａｒｑフィードバック情報伝送及び受信方法
US20230337216A1 (en) Method and device for communication in wireless communication system supporting groupcast
US11399346B2 (en) Method and apparatus for controlling uplink transmission power by terminal for dual connectivity in wireless communication system
WO2018025493A1 (ja) 基地局、端末及び通信方法
EP3975627B1 (en) Uplink transmission power control method and device in wireless cellular communication system
JP5668072B2 (ja) 無線通信装置およびハイブリッド自動再送要求送信方法
EP4349101A1 (en) Support for an increased quantity of sidelink configured grants
US20230362932A1 (en) Method and apparatus for transmitting/receiving signal for groupcast in wireless communication system
US12004174B2 (en) Support for an increased quantity of sidelink configured grants

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 201180017170.5

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11771754

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2012511551

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 13638729

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11771754

Country of ref document: EP

Kind code of ref document: A1