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 CN201180017170.5A priority Critical patent/CN102860119B/zh
Priority to JP2012511551A priority patent/JP5669827B2/ja
Priority to US13/638,729 priority patent/US9031022B2/en
Publication of WO2011132413A1 publication Critical patent/WO2011132413A1/ja
Priority to US14/632,382 priority patent/US9380572B2/en

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W72/00Local resource management
    • H04W72/12Wireless traffic scheduling
    • H04W72/121Wireless traffic scheduling for groups of terminals or users
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W72/00Local resource management
    • H04W72/20Control channels or signalling for resource management
    • H04W72/23Control channels or signalling for resource management in the downlink direction of a wireless link, i.e. towards a terminal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W72/00Local resource management
    • H04W72/30Resource management for broadcast services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W88/00Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02Terminal devices
    • H04W88/04Terminal 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

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

Description

基地局、移動局、協調移動局、送信方法及び受信方法
 本発明は、クライアント協調動作を行う、基地局、移動局、協調移動局、送信方法及び受信方法に関する。
 IEEE(Institute of Electrical and Electronics Engineers、電気電子技術者協会)802.16ワーキンググループは、IMT(International Mobile Telecommunications)-アドバンスト次世代携帯電話システムの諸要件を満たす802.16m無線インタフェース仕様を作成中である。IEEE 802.16m草案標準(例えば、非特許文献1参照)に基づいて、WiMAX(Worldwide Interoperability for Microwave Access)フォーラムは、WiMAX リリース2.0 MSP(Mobile System Profile)及びPICS(Protocol Implementation Conformance Statement)を考案中である。IEEE 802.16m標準並びにWiMAXリリース2.0 MSP及びPICSは、2011年早期には仕上げられると見込まれる。
 また、IEEE802.16ワーキンググループは、802.16m/WiMAX2.0を超える将来の802.16/WiMAXネットワークの構想設計を開始した。将来の802.16/WiMAXネットワークは、大型画面の機器、マルチメディア・アプリケーション並びにさらに増加する接続ユーザ及び機器によって拍車をかけられる移動通信データ・トラフィックの爆発的な増加をサポートするものになるだろうという共通の認識が、802.16/WiMAXコミュニティの間にはある。また、将来の802.16/WiMAXネットワークは、例えば、802.11/Wi-Fi(Wireless Fidelity)等の他の無線技術と効率的に連携動作するものになるであろう。
 将来の802.16/WiMAXネットワークは、スループットやSE(Spectral Efficiency)等の様々な性能指標値に関して、802.16mネットワークと比較して大幅に改良されたものになるであろう。例えば、都市区域におけるカバレッジを想定した場合、将来の802.16/WiMAXネットワークは、UL(Uplink,アップリンク)とDL(Downlink,ダウンリンク)の両方で、802.16m/WiMAX2.0ネットワークの2倍のSEをセルエッジでの目標にしている(例えば、非特許文献2参照)。802.16m/WiMAX2.0ネットワークは、4´2アンテナ構成で少なくとも0.06bps/Hz/秒のDLのセルエッジでのSEと2´4アンテナ構成で少なくとも0.03bps/Hz/秒のULのセルエッジでのSEをもつことに留意されたい。
 例えば、CliCo(Client Collaboration、クライアント協調動作)等の協調技術は、無線通信システムのセルエッジでのSE及びネットワーク全体のエネルギー効率の大幅な改良を確かなものにした。CliCoは、無線環境においてクライアント同士がデータを合同で送信/受信するために交信する技術である(例えば、非特許文献3参照)。CliCoでは、BSとクライアント間で複数の経路を介して情報を送信/受信するために、クライアント・クラスタリング(Client Clustering)及びピアツーピア(Peer-to-Peer)通信が利用される。その結果、設備コストの増加なしに、セルエッジでのSEを向上させることができる。さらに、劣悪なチャネルを有するクライアントの電池を長持ちさせることができる。
 CliCoを行う典型的な無線通信システム100を例示する図を図1に示す。無線通信システム100は、BS(Base Station,基地局)102と、例えば、MS104及びMS106の複数のMS(Mobile Station,移動局)とを含む構成を採る。
 典型的なBS102を例示するブロック図を図2に示す。BS102は、ここではWiMAXによる通信機能のみを装備し、WiMAX PHYブロック130とWiMAX MACブロック120からなる。WiMAX MACブロック120は、WiMAX OFDMA(Orthogonal Frequency Division Multiple Access)ベースの媒体アクセス制御(Media Access Control:MAC)プロトコルを実行する。WiMAX PHYブロック130は、WiMAX MACブロック120の制御の下で、WiMAX OFDMAベースの物理層プロトコルを実行する。
 図2を参照すると、WiMAX MACブロック120はさらに、制御部122、スケジューラ124、メッセージ生成部126及びメッセージ処理部128を含む構成を採る。制御部122は、一般的なMACプロトコル動作を制御する。スケジューラ124は、制御部122の制御の下で、各MSへのリソースの割当をスケジュールする。メッセージ生成部126は、スケジューラ124からリソース割当スケジューリング情報を受け取ると、データ・パケット及びDL制御情報を生成する。メッセージ処理部128は、制御部122の制御の下で、複数のMSから受信したデータ・パケット及びUL制御情報を分析し、その分析結果を制御部122へ報告する。
 メッセージ生成部126によって生成されたデータ・パケット及びDL制御情報は、WiMAX PHYブロック130内のOFDMA送信器(図2では図示せず)を介してBS102によって複数のMSへ送信されることに留意されたい。メッセージ処理部128によって分析されるデータ・パケット及びUL制御情報は、WiMAX PHYブロック130内のOFDMA受信器(図2では図示せず)を介してBS102によって受信される。
 図2を参照すると、メッセージ生成部126内には、HFBCH(HARQフィードバック・チャネル)生成部132とリソース割当生成部134とが存在する。ここで、HARQはハイブリッド自動再送要求(Hybrid Automatic Repeat Request)を表す。HFBCH生成部132は、ULデータ送信に対するHARQフィードバック情報(例えば、ACK/NACK)を通知する、ULデータ送信に対するHARQフィードバック・チャネルを生成する。リソース割当生成部134は、複数のMSの各々へのリソース割当情報を通知する、UL/DLデータ送信のためのリソース割当制御情報を生成する。
 GRA(Group Resource Allocation)の観点では、リソース割当生成部134によって生成されるリソース割当制御情報は、グループ・コンフィギュレーション(Group Configuration)情報並びにDL/ULでのGRA送信のためのHFBCHのインデックス情報を含むグループ・リソース割当情報を含み得る。HFBCH生成部132によって生成されるHFBCHは、ULでのGRA送信に対するHARQフィードバック情報を含み得る。
 図2を参照するとメッセージ処理部128内には、HFBCH分析部136が存在する。HFBCH分析部136は、DLでのデータ送信に対して受信したHFBCHを分析し、その対応するDLデータ送信が成功したか否かを判断する。GRAの観点では、HFBCH分析部136は、受信したUL制御情報からDLでのGRA送信に対するHARQフィードバック情報を導出し得る。
 典型的なMS104を例示するブロック図を図3に示す。MS104は、WiMAX及びWi-Fiの両方による通信機能を装備し、WiMAX PHYブロック142、Wi-Fi PHYブロック144、WiMAX MACブロック146、Wi-Fi MACブロック148、及びGLL(Generic Link Layer)ブロック150から構成される。WiMAX MACブロック146は、WiMAX OFDMAベースのMAC(媒体アクセス制御)プロトコルを実行する。WiMAX PHYブロック142は、WiMAX MACブロック146の制御の下で、WiMAX OFDMAベースの物理層プロトコルを実行する。Wi-Fi MACブロック148は、Wi-Fi CSMA/CA(Carrier Sense Multiple Access with Collision Avoidance)ベースのMAC(媒体アクセス制御)プロトコルを実行する。Wi-Fi PHYブロック144は、Wi-Fi MACブロック148の制御の下で、Wi-Fi OFDM(Orthogonal Frequency Division Multiplexing)/DSSS(Direct Sequence Spread Spectrum)ベースの物理層プロトコルを実行する。GLLブロック150は、異種のWiMAXリンクとW-Fiリンクとの間の連携動作を管理するものとして機能する。
 図3を参照すると、WiMAX MACブロック146はさらに、制御部154、メッセージ生成部152、及びメッセージ処理部156を含む構成を採る。制御部154は、一般的なMACプロトコル動作を制御する。メッセージ生成部152は、制御部154の制御の下で、UL制御情報及びデータ・パケットを生成する。メッセージ処理部156は、制御部154の制御の下で、BS102から受信したデータ・パケット及びDL制御情報を分析し、その分析結果を制御部154へ供給する。
 メッセージ生成部152によって生成されたデータ・パケット及びUL制御情報は、WiMAX PHYブロック142内のOFDMA送信器(図3では図示せず)を介して、MS104からBS102へ送信されることに留意されたい。メッセージ処理部156によって分析されるデータ・パケット及びDL制御情報は、WiMAX PHYブロック142内のOFDMA受信器(図3では図示せず)を介してMS104によって受信される。
 図3を参照すると、メッセージ処理部156内には、リソース分析部151とHFBCH分析部153とが存在する。HFBCH分析部153は、ULでのデータ送信に対して受信したHFBCHを分析し、その対応するULデータ送信が成功したか否かを判断する。リソース分析部151は、受信したリソース割当制御情報を分析し、MS104に対して特定されたリソース割当情報を導出する。ULデータ送信の場合には、制御部154の制御の下でメッセージ生成部152によって生成されたデータ・パケットは、次に、導出されたリソース割当情報に従って、MS104からBS102へ送信される。DLデータ送信の場合には、BS102からMS104へ送信されたデータ・パケットは、次に、導出されたリソース割当情報に従ってMS104によって受信される。
 GRAの観点では、メッセージ処理部156内のリソース分析部151は、受信したリソース割当制御情報から、グループ・コンフィギュレーション情報並びにDL/ULでのGRA送信のためのHFBCHのインデックス情報を含むグループ・リソース割当情報を導出し得る。HFBCH分析部153は、受信したHFBCHから、ULでのGRA送信に対するHARQフィードバック情報を導出し得る。
 図3を参照すると、メッセージ生成部152内にはHFBCH生成部155が存在する。HFBCH生成部155は、DLでのデータ送信に対するHARQフィードバック情報を含むHARQフィードバック・チャネルを生成する。GRAの観点では、HFBCH生成部155は、DLでのGRA送信に対するHARQフィードバック・チャネルを生成し得る。
 典型的なMS106を例示するブロック図を図4に示す。MS106もまた、WiMAX及びWi-Fiの両方による通信機能を装備し、MS104と全く同様の構成と機能性を有する。MS104とMS106との主な相違点は、MS106とは異なり、MS104のWi-Fi MACブロック148内には図3に示したとおり、スケジューラ158があることであり、このスケジューラはCliCoのための協調動作スケジューリングのために使用される。
 図1を参照すると、BS102は、 WiMAXリンク108a及び108bを介してMS104と通信し、WiMAXリンク110a及び110bを介してMS106と通信する。MS104は、ピアツーピアWi-Fiリンク112a,112bを介してMS106と通信する。また、MS104は、利用可能であれば、例えば、WiMAX、ブルートゥース、または60 GHz mmW(ミリ波)等の他の無線技術を介してMS106と通信してもよい。
 CliCoは、無線通信システム100のDL及びULの両方で実現可能であることに留意されたい。一例として、無線通信システム100におけるULでのCliCoの動作を以下に説明する。
 図1を参照すると、BS102とMS104との間のWiMAXリンク108aの信号品質が悪くなると、MS104は、近隣探索、協調機選択/割当等のULでのCliCo手順を開始することができる。BS102とMS106との間のWiMAXリンク110aの信号品質が良ければ、MS104は、MS106を協調機として選択できる。CliCoのコンテクストでは、MS104は発信MSと呼ばれ、MS106は協調MSと呼ばれる。
 CliCoは、様々な状況において起こり得る。例えば、発信MS104がカフェテリア内の奥の方にあるとすると、そのため、発信MS104へのWiMAXリンクの信号品質が非常に悪いことがあり得る。一方、協調MS106は、発信MS104に比べて、カフェテリアの窓または入口に非常に近いところにあるとすれば、協調MS106は発信MS104よりも非常に良いWiMAXリンクの信号品質を有し得る。
 図1に示したCliCoを行う無線通信システム100に適用され得る、典型的なフレーム構成200を例示する図を図5に示す。図5を参照すると、フレーム202及びフレーム212の各々は、8個のサブフレームからなる。そのうちの5個はDLサブフレームであり、その他はULサブフレームである。
 ULでのCliCoに関する限り、フレーム202の最初のDLサブフレーム204中において、BS102は、CliCoに関与する発信MS104と協調MS106とを含む、BS102に接続された複数の移動局へ制御情報を示すMAP 220を送信することができる。MAP220は、複数のMAP IE(Information Element:情報要素)からなる。MAP IEの一部はULデータ送信に対するHARQフィードバック情報を通知することができ、MAP IEの一部はDL/ULデータ送信のためのリソース割当情報を通知することができる。HARQフィードバック情報を通知する、MAP220中の1個のMAP IEが、ULデータ送信に対する1つのHBFCHを形成する。
 フレーム202の最初のDLサブフレーム204と最初のULサブフレーム206との間の期間208中に、発信MS104と協調MS106は、HFBCHインデックス情報を含むそれぞれのリソース割当情報を得るために、MAP220をそれぞれ復号する必要がある。また、発信MS104は、ピアツーピアWi-Fiリンク112aを介して、ULデータ・バースト250を協調MS106へ送信する必要がある。
 発信MS104がWiMAX リンク108bを介してBS102により送信されたMAP220の復号に成功しているならば、発信MS104は、その受信したリソース割当情報に従って、フレーム202の最初のULサブフレーム206中においてWiMAXリンク108aを介してULデータ・バースト250をBS102へ送信する。他方、協調MS106がWiMAXリンク110bを介してBS102により送信されたMAP220の復号に成功していて、かつ、ピアツーピアWi-Fiリンク112aを介して発信MS104により送信されたULデータ・バースト250の受信に成功しているならば、協調MS106は、その受信したリソース割当情報に従って、WiMAXリンク110aを介して同一のULデータ・バースト250をBS102へ同時に送信する。その結果、BS102は、受信信号の品質を向上させるために、WiMAXリンク108aとWiMAXリンク110aとから受信したULデータ・バースト250の2個のコピーを合成できる。
 フレーム212の2番目のDLサブフレーム214中において、BS102は、CliCoに関与する発信MS104及び協調MS106を含む、BS102に接続された複数の移動局へMAP240を送信することができる。上述のとおり、MAP240中の一部を成すHFBCHsは、フレーム202の最初のULサブフレーム206中において発信MS104及び協調MS106が送信したULデータ・バースト250に対するHARQフィードバック情報を通知することができる。
 フレーム212の2番目のDLサブフレーム214と最初のULサブフレーム216の間の期間218中に、発信MS104及び協調MS106は、期間208中においてMAP220を復号することによって得られる、それぞれのHFBCHインデックス情報に従って、ULデータ・バースト250に対するHARQフィードバック情報を得るために、MAP240中の対応するHFBCHsをそれぞれ復号する必要がある。
 HARQフィードバック情報が、フレーム202の第1のULサブフレーム206中において発信MS104及び協調MS106が送信したULデータ・バースト250をBS102が正常に復号していないことを示す場合、フレーム212の最初のULサブフレーム216中において、発信MS104及び協調MS106は、ULデータ・バースト250を再送する必要があり得る。
 上述したとおり、将来の802.16/WiMAXネットワークは、爆発的な移動通信データ・トラフィックをサポートしなくてはならない。さらに、将来の802.16/WiMAXネットワークは、VoIP(Voice over Internet Protocol)等の移動通信インターネット・アプリケーションの実感品質(Quality of Experience)を向上させなくてはならない。VoIPは周期的なトラフィック・パターンをもち、比較的固定したペイロード・サイズであることを考えると、例えば、PA(Persistent Allocation)及びGRAといった、特にVoIPの実感の品質を向上させるために、様々なPHY/MACメカニズムが設計された。本発明では、CliCoへのGRAの適用を取り上げる。
 IEEE 802.16m草案標準(例えば非特許文献1参照)で規定されたGRAメカニズムは、CliCoに対応していない。しかし、GRAメカニズムは、CliCoに容易に対応可能である。
 IEEE 802.16m草案標準(例えば非特許文献1参照)によれば、GRAメカニズムは、制御オーバヘッドを節減するために、あるグループとしての複数のユーザにリソースを割り当てる。このリソース割当はトランスポート・フロー(Transport flow)単位である。図1を参照すると、GRAをCliCoに適用する方法は、二つの操作からなる。すなわち、i)BS102は、発信MS104及び協調MS106のそれぞれのフローをあるグループに加える、または発信MS104及び協調MS106のそれぞれのフローをあるグループから削除する。ii)BS102は、同一グループ内の発信MS104及び協調MS106のそれぞれのフローにリソースを割り当てる。
 IEEE 802.16m草案標準(例えば非特許文献1参照)によれば、発信MS104(または協調MS106)のフローをあるグループに加えるときに、BS102は、ユニキャストMAC制御メッセージ中でグループ・コンフィギュレーション情報を発信MS104(または協調MS106)へ送信する。同一グループ内の発信MS104及び/または協調MS106のそれぞれのフローにリソースを割り当てる場合、BS102は、マルチキャストMAP IEでHFBCHインデックス情報を含むグループ・リソース割当情報を発信MS104及び協調MS106へ送信する。ユニキャストMAC制御メッセージ中で送信されるグループ・コンフィギュレーション情報とマルチキャストMAP IEで送信されるグループ・リソース割当情報は、図2に示したメッセージ生成部126によって生成されることに留意されたい。
 IEEE 802.16m草案標準(例えば非特許文献1参照)によれば、ユニキャストMAC制御メッセージ中で送信されるグループ・コンフィギュレーション情報は、対応するマルチキャストMAP IEで送信されるグループ・リソース割当情報を解釈するために使用され得る。グループ・コンフィギュレーション情報の内容は、次のものを含む。
 ・ フロー識別子(Flow identifier)、
 ・ ユーザ・ビットマップ・サイズ(User bitmap size)、
 ・ UBI(User Bitmap Index,ユーザ・ビットマップ・インデックス)、
 ・ グループ識別子(Group identifier)、 
 ・ 割当て周期(Allocation periodicity)、及び
 ・ MIMO(Multiple Input Multiple Output)モード・セット(MIMO mode set)、等
 フロー識別子は、MSのフローのうちのどのフローがグループに加えられるのかをMSに通知するために使用され、4ビットのサイズを有する。ユーザ・ビットマップ・サイズは、マルチキャストMAP IEで送信されるユーザ・ビットマップに使用されるビット数を示す。ユーザ・ビットマップ・サイズは、4ビット、8ビット、及び32ビットのうちの一つをとる。UBIは、ユーザ・ビットマップ中のMSのフローのインデックスを示し、5ビットのサイズを有する。グループ識別子は、MSのフローが加えられるDL/ULグループを一意に識別し、12ビットのサイズを有する。割当て周期は、対応するグループ・リソース割当情報を通知するマルチキャストMAP IEが送信される頻度を指定し、周期は1フレーム、2フレーム、4フレーム及び8フレームのうちの一つであり得る。MIMOモード・セットは、当グループ中でサポートされているMIMOモードを伝える。
 発信MS104と協調MS106に向けたグループ・コンフィギュレーション情報の主な違いは、発信MS104と協調MS106のそれぞれのUBIが異なることである。さらに、グループ・コンフィギュレーション情報は発信MS104と協調MS106へユニキャスト(unicast)されるので、協調MS106は発信MS104のUBIを知らないし、逆の場合もそうである。
 IEEE 802.16m草案標準(例えば非特許文献1参照)によれば、グループ・コンフィギュレーション情報は、4個のHARQバースト・サイズ(HARQ burst size)のセットをさらに含み得る。例えば、4個のHARQバースト・サイズのセットは、{6バイト、8バイト、9バイト、10バイト}であり得る。バースト・サイズは、複数のFEC(Forward Error Correction)ブロックに分割可能である、符号化されたパケットのサイズであることに留意されたい。バースト・サイズは、適用できる場合、バースト当たり及び/またはFECブロック当たりのCRC(Cyclic Redundancy Code)の追加を含み得る。
 また、4個のHARQバースト・サイズのそれぞれに対応して、グループ・コンフィギュレーション情報は、8個のリソース・サイズを含み得る。例えば、9バイトのHARQバースト・サイズについては、8個のリソース・サイズのセットは、{1LRU、2LRUs、3LRUs、4LRUs、5LRUs、6LRUs、7LRUs、8LRUs}となり得る。ここで、LRUは論理的リソース単位(Logical Resource Unit)を表わす。6バイト、8バイト、10バイトの他の3個のHARQバースト・サイズのそれぞれについては、8個のリソース・サイズのセットは、異なることもあるし、または9バイトのHARQバースト・サイズと同じこともある。
 IEEE 802.16m草案標準(例えば非特許文献1参照)によれば、グループ・リソース割当情報の一部は、マルチキャストMAP IEで送信されるビットマップによって運ばれる。IEEE 802.16m草案標準[1]による、一部のグループ・リソース割当情報を通知する典型的なビットマップを例示する図を図6に示す。一部のグループ・リソース割当情報を通知するために使用されるビットマップは二つある。一つはユーザ・ビットマップ302であり、もう一つはリソース割当ビットマップ304である。
 IEEE 802.16m草案標準(例えば非特許文献1参照)によれば、ユーザ・ビットマップ302は、現在のフレームにスケジュールされるのはどのフローであるかを伝えるためにフロー当たり1ビットを使用する。図6を参照すると、発信MS104のUBIは「00000」であるのでユーザ・ビットマップ302の1ビット目を参照する。協調MS106のUBIは「00011」であるのでユーザ・ビットマップ302の4ビット目を参照する。したがって、発信MS104及び協調MS106両方のそれぞれのフロー(データに相当)はリソース割当ビットマップ304で指示され、現在のフレームに送信される。
 図6を参照すると、リソース割当ビットマップ304は、複数の5ビットのリソース割当指示を含む構成を採り、各リソース割当指示は特定のスケジュールされたフローに対応する。5ビットのリソース割当指示の各々において、最初の2ビットはHARQバースト・サイズを伝えるために使用され、最後の3ビットはリソース・サイズを伝えるために使用される。
 図6を参照すると、HARQバースト・サイズは4個のバースト・サイズの種類{6バイト、8バイト、9バイト、10バイト}から選択され、「00」, 「01」、「10」、「11」によって指示される。図6では発信MS104及び協調MS106両方とも「10」で示されるため、両方のHARQバースト・サイズは9バイトである。発信MS104及び協調MS106のリソース・サイズは、それぞれ、「111」と「001」によって示される。したがって、発信MS104及び協調MS106のリソース・サイズは、それぞれ、8LRUsと2LRUsであり得る。
 IEEE 802.16m草案標準(例えば非特許文献1参照)によれば、ユーザ・ビットマップ302及びリソース割当ビットマップ304に加えて、複数のMIMOモードがグループ中でサポートされる場合、MIMOビットマップと呼ばれる他のビットマップが使用され得る。
 IEEE 802.16m草案標準(例えば非特許文献1参照)による、グループ・リソース割当情報を送信するための典型的なGRA MAP IEを例示する表を表1に示す。
Figure JPOXMLDOC01-appb-T000001
 さらに、IEEE 802.16m草案標準(例えば非特許文献1参照)によれば、グループ内のスケジュールされたフローについてのHFBCHインデックスは、そのUBI及び表1に示したHFAオフセットの予め決められた関数である。換言すると、発信MS104及び協調MS106のそれぞれが、表1に示したGRA MAP IEを復号後、自機のUBIにより自機のHFBCHインデックスを算出することができる。
 IEEE 802.16m草案標準(例えば非特許文献1参照)において、発信MS104(または協調MS106)がリソース割当情報を受信する方法400を例示するフローチャートを図7に示す。方法400はステップ402で開始する。ステップ404において、発信MS104(または協調MS106)は、自機のUBIに照らしてユーザ・ビットマップをチェックする。ステップ406では、発信MS104(または協調MS106)は、自機のフローが現在のフレームでスケジュールされているか否かを判定する。発信MS104(または協調MS106)のフローが現在のフレームにスケジュールされていれば、ステップ408において、発信MS104(または協調MS106)は、次に、自機のHARQバースト・サイズとリソース・サイズを導出するために、自機のUBIに照らしてリソース割当てビットマップをチェックする。その後、ステップ410で、発信MS104(または協調MS106)は、自機のUBIに応じて自機のHFBCHインデックスを算出する。ステップ406で、発信MS104(または協調MS106)のフローが現在のフレームにスケジュールされていなければ、方法400はステップ412で終了する。
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
 IEEE 802.16m草案標準(例えば非特許文献1参照)によれば、CliCoに関与する発信MS104及び協調MS106の両方が同一のデータ・バーストを処理する。発信MS104及び協調MS106の両方に用いる一つのHFBCHがあれば十分である。しかしながら、同一グループにおいてUBIが異なるため、発信MS104及び協調MS106は2つの異なるHFBCHを有する。これは、貴重なHFBCHリソースを浪費することになる。
 本発明の目的は、同一データ・バーストを処理する複数のMSに対して一つのHBCHを使用することで、不必要なHFBCHリソースの浪費を避けることができる基地局、移動局、協調移動局、送信方法及び受信方法を提供することである。
 本発明の一態様によれば、複数の移動局(MSs)と通信する基地局(BS)は、上記複数のMSsの各々に対するリソース割当情報を示す制御信号を生成する制御信号生成部と上記複数のMSsへ上記制御信号を送信する送信部を含む構成をとり、ある移動局(MS)に対する制御信号は、他のMSに関する情報を含む。
 本発明の一態様によれば、BSは、発信MSと、BSと上記発信MSとの間の通信のために利用される協調MSを含む複数のMSsと通信し、上記複数のMSsの各々に対するリソース割当情報を示す制御信号を生成する制御信号生成部と、上記複数のMSsへ上記制御信号を送信する送信部を具備し、上記協調MSに対する制御信号は、上記発信MSに関する情報を含む。
 本発明の一態様によれば、上記協調MSのフローが上記発信MSと同じグループに加えられる場合、上記協調MSに対する制御信号は、上記発信MSに関する情報を含む。
 本発明の一態様によれば、上記発信MSに関する情報は、上記協調MSに対するリソース割当情報の中に含まれる。
 本発明の一態様によれば、上記発信MSに関する情報は、上記協調MSに対するバースト・サイズ情報と入れ換えられる。
 本発明の一態様によれば、上記発信MSに関する情報のビット数は、上記発信MSと同じグループに属するMSsの数に応じて変わる。
 本発明の一態様によれば、上記発信MSと同じグループに属するMSsの数に応じて、上記協調MSに対するバースト・サイズ情報のビット数が増加するのに伴い、かつ、上記協調MSに対するリソース・サイズ情報のビット数が減少するのに伴い、上記発信MSに関する情報のビット数は変わる。
 本発明の一態様によれば、上記協調MSに対するリソース・サイズ情報のビット数が減少する場合、上記協調MSの実際のリソース・サイズは、上記発信MSのリソース・サイズと上記協調MSの公称リソース・サイズのビット単位の演算結果として得られる。
 本発明の一態様によれば、上記協調MSのリソース・サイズは、上記発信MSのリソース・サイズと同じであり、上記発信MSに関する情報は、上記協調MSに対するバースト・サイズ情報及びリソース・サイズ情報と入れ換えられる。
 本発明の一態様によれば、上記協調MSの実際のリソース・サイズは、上記発信MSのリソース・サイズと上記協調MSの公称リソース・サイズのビット単位の演算結果として得られる。
 本発明の一態様によれば、上記協調MSのリソース・サイズは予め決められた値に設定され、上記発信MSに関する情報は、上記協調MSに対するバースト・サイズ情報及びリソース・サイズ情報と入れ換えられる。
 本発明の一態様によれば、上記発信MSに関する情報は、上記発信MSの識別情報である。
 本発明の一態様によれば、上記発信MSに関する情報は、上記協調MSの識別情報に相対する、上記発信MSの識別情報のオフセットである。
 本発明の一態様によれば、MSは、他のMSに関する情報を含む、自機に対する制御信号を受信する受信部と、上記制御信号、及び、上記他のMSに関する情報に応じて、送信リソースを算出するリソース算出部を具備する。
 本発明の一態様によれば、BSと発信MSとの間の通信のために利用される協調MSは、上記発信MSに関する情報を含む自協調MSに対する制御信号を受信する受信部、上記制御信号、及び、上記発信MSに関する情報に応じて、送信リソースを算出するリソース算出部、及び上記発信MSから受信した信号を、上記送信リソースを介して上記BSへ送信する送信部を具備する。
 本発明の一態様によれば、上記発信MSに関する情報が上記協調MSの識別情報を示す場合は、上記送信部は、上記BSへの上記信号の送信を停止する。
 本発明の一態様によれば、上記発信MSに関する情報が上記協調MSの識別情報を示す場合は、上記送信部は、予め決められた期間または設定可能な期間の間、上記BSへの上記信号の送信を停止する。
 本発明の一態様によれば、上記発信MSに関する情報の一部分は、上記協調MSに対するリソース割当情報の中に含まれ、上記発信MSに関する情報のその他の部分は、上記協調MSへ送信されるグループ・コンフィギュレーション情報の中に含まれる。
 本発明の一実施形態によれば、複数のMSsと通信するBSにおいて実行される送信方法は、上記複数のMSsの各々に対するリソース割当情報を示す制御信号を生成し、上記複数のMSsへ上記制御信号を送信し、あるMSに対する制御信号は、他のMSに関する情報を含む。
 本発明の一実施形態によれば、発信MSと、BSと上記発信MSとの間の通信のために利用される協調MSを含む複数のMSsと通信する基地局(BS)において実行される送信方法は、上記複数のMSsの各々に対するリソース割当情報を示す制御信号を生成し、上記複数のMSsへ上記制御信号を送信し、上記協調MSに対する制御信号は、上記発信MSに関する情報を含む。
 本発明の一実施形態によれば、MSにおいて実行される受信方法は、他のMSに関する情報を含む自機に対する制御信号を受信し、上記制御信号及び上記他のMSに関する情報に応じて送信リソースを算出する。
 本発明の一実施形態によれば、BSと発信MSとの間の通信のために利用される協調MSにおいて実行される受信方法は、上記発信MSに関する情報を含む自機に対する制御信号を受信し、上記制御信号及び上記発信MSに関する情報に応じて、送信リソースを算出し、上記発信MSから受信した信号を、上記送信リソースを介して上記BSへ送信する。
 本発明の上記及びその他の特徴と利点は、添付の図面とともに本発明の以下の詳細な説明を参照し、添付の特許請求の範囲を参照することで、よりよく理解されることになろう。
 本発明は同一データ・バーストを処理する複数のMSsに対して一つのHBCHを使用するので、不必要なHFBCHリソースの浪費を避けることができる。
CliCo(クライアント協調動作)を行う無線通信システムの一例を示す図 BS(基地局)の一例を示すブロック図 発信MS(移動局)の一例を示すブロック図 協調MS(移動局)の一例を示すブロック図 フレーム構成の一例を示す図 従来技術による、一部のグループ・リソース割当情報を通知するビットマップの一例を示す図 従来技術による、発信MS(または協調するMS)でグループ・リソース割当情報を受信する方法を例示するフローチャート 本発明の実施の形態1に係る協調するMSでグループ・リソース割当情報を受信する方法を例示するフローチャート 本発明の実施の形態2に係る4ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためビットマップの一例を示す図 本発明の実施の形態2に係る4ビットのユーザ・ビットマップの場合における、協調するMSでグループ・リソース割当情報を受信する方法を例示するフローチャート 本発明の実施の形態2に係る8ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためビットマップの一例を示す図 本発明の実施の形態2に係る8ビットのユーザ・ビットマップの場合における、協調するMSでグループ・リソース割当情報を受信する方法を例示するフローチャート 本発明の実施の形態2に係る32ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためのビットマップの一例を示す図 本発明の実施の形態2に係る32ビットのユーザ・ビットマップの場合における、協調するMSでグループ・リソース割当情報を受信する方法を例示するフローチャート 本発明の実施の形態3に係る4ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためのビットマップの一例を示す図 本発明の実施の形態4に係る8ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためのビットマップの一例を示す図 本発明の実施の形態5に係る8ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためのビットマップの一例を示す図
 以下、本発明の実施の形態について、添付図面を参照して詳細に説明する。本願明細書に援用する周知の機能及び構成の詳細な説明は、明確かつ簡潔にするために省略した。
 (実施の形態1)
 本発明の実施の形態1によれば、図1に準拠して、GRAをCliCoに適用する方法の基本概念は、BS102が、グループ・コンフィギュレーション情報を用いて、発信MS104のUBIを協調MS106に共有させることである。より詳細には、BS102が協調MS106のフローをグループに加えるとき、BS102によって協調MS106へユニキャストされるグループ・コンフィギュレーション情報は、発信MS104のUBIをも含む。BS102によって協調MS106へユニキャストされるグループ・コンフィギュレーション情報の内容は、以下に挙げることができる。
 ・ 協調MS106のフロー識別子、
 ・ ユーザ・ビットマップ・サイズ、
 ・ 発信MS104のUBI、
 ・ 協調MS106のUBI、
 ・ グループ識別子、 
 ・ 割当て周期、及び
 ・ MIMOモード・セット、等
 本発明の実施の形態1によれば、協調MS106は発信MS104のUBIを知るので、協調MS106は、自機のHFBCHインデックスを導出するために、自機自身のUBIの代わりに発信MS104のUBIを使用することができる。その結果、同一のHFBCHのみが、CliCoに関与する発信MS104及び協調MS106の両方に割り当てられる。したがって、不必要なHFBCHリソースの浪費が避けられる。
 本発明の実施の形態1による、協調MS106でリソース・スケジューリング情報を受信するための方法500を例示するフローチャートを図8に示す。方法500はステップ502で開始する。ステップ504において、協調MS106は、自機のUBIに照らしてユーザ・ビットマップをチェックする。ステップ506では、協調MS106は、自機のフローが現在のフレームにスケジュールされているか否かを判定する。協調MS106のフローが現在のフレームにスケジュールされていれば、ステップ508において、協調MS106は、自機のHARQバースト・サイズ及びリソース・サイズを導出するために、自機のUBIに照らしてリソース割当ビットマップをチェックする。ステップ510では、協調MS106は、発信MS104のUBIに応じて自機のHFBCHインデックスを算出する。ステップ506で、協調MS106のフローが現在のフレームにスケジュールされていなければ、方法500はステップ512で終了する。
 本発明の実施の形態1によれば、BS102によって発信MS104へユニキャストされるグループ・コンフィギュレーション情報の内容と、BS102によって発信MS104及び協調MS106へマルチキャストされるグループ・リソース割当情報の内容とは、IEEE 802.16m草案標準(例えば、非特許文献1参照)と同じである。しかしながら、BS102によって協調MS104へユニキャストされるグループ・コンフィギュレーション情報の内容は、IEEE 802.16m草案標準(例えば、非特許文献1参照)とは異なる。
 本発明の実施の形態1によると、代替的な手法は、グループ・コンフィギュレーション情報が、BS102によって発信MS104と協調MS106の両方へマルチキャストされることである。BS102によって発信MS104及び協調MS106の両方へマルチキャストされるグループ・コンフィギュレーション情報の内容は、以下に挙げることができる。
 ・ 発信MS104のフロー識別子、
 ・ 協調MS106のフロー識別子、
 ・ ユーザ・ビットマップ・サイズ、
 ・ 発信MS104のUBI、
 ・ 協調MS106のUBI、
 ・ グループ識別子、
 ・ 割当て周期、及び
 ・ MIMOモード・セット、等
 本発明の実施の形態1によれば、グループ・コンフィギュレーション情報は、MAC制御メッセージまたはMAP IEのいずれかで送信され得る。
 (実施の形態2)
 本発明の実施の形態1によれば、発信MS104のUBIを協調MS106に共有させることによって、グループ・リソース割当を開始する前の段階でグループ・コンフィギュレーション情報に追加の制御オーバヘッドが導入される可能性があるという欠点がある。
 図1に準拠して、前述したとおり、CliCoに関与する発信MS104及び協調MS106は同一のデータ・バーストを処理するため、同一のHARQバースト・サイズを有することになる。したがって、発信MS104及び協調MS106のいずれか一方に対するHARQバースト・サイズ指示は不必要である。さらに、実際に必要とされるUBIの長さは、ユーザ・ビットマップ・サイズに依存する。例えば、ユーザ・ビットマップ・サイズが8ビットである場合、5ビットのUBIではなく3ビットのUBIのみが実際に必要とされる。
 本発明の実施の形態2によれば、GRAをCliCoに適用する方法の基本概念は、BS102が、本発明の実施の形態1におけるグループ・コンフィギュレーション情報の代わりに、グループ・リソース割当情報を用いて、発信MS104のUBIを協調MS106に共有させることである。より詳細には、BS102が発信MS104及び協調MS106にリソースを割り当てる場合、リソース割当ビットマップ中の協調MS106用の5ビットのリソース割当指示の可変部分が、発信MS104のUBIを指示するために使用される。上記可変部分の長さはユーザ・ビットマップ・サイズに依存する。協調MS106用の上記5ビットのリソース割当指示の残りの部分は、協調MSのリソース・サイズを指示するために使用される。ただし、協調MS106のリソース・サイズを指示するための方法は、ユーザ・ビットマップ・サイズに応じて異なる。
 本発明の実施の形態2によれば、発信MS104のUBIはリソース割当てビットマップに組み込まれているので、グループ・コンフィギュレーション情報に追加の制御オーバヘッドが導入されることはない。
 本発明の実施の形態2による、4ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するビットマップの一例を図9に示す。図9を参照すると、リソース割当ビットマップ604の中で、協調MS106用の5ビットのリソース割当指示の最初の2ビット(例えば、「00」)が、協調MS106のHARQバースト・サイズではなく、発信MS104のUBIを指示するために使用され、最後の3ビット(例えば、「010」)が、協調MS106用のリソース・サイズを伝えるために使用される。なお、発信MS104用の5ビットのリソース割当指示の最初の2ビット(例えば、「10」)は、発信MS104及び協調MS106の両方のHARQバースト・サイズを伝えるために使用されることに留意されたい。
 本発明の実施の形態2による、4ビットのユーザ・ビットマップの場合における、協調MS106でグループ・リソース割当情報を受信するための方法700を例示するフローチャートを図10に示す。方法700はステップ702で開始する。ステップ704において、協調MS106は、自機のUBIに照らしてユーザ・ビットマップをチェックする。ステップ706では、協調MS106は、自機のフローが現在のフレームにスケジュールされているか否かを判定する。協調MS106のフローが現在のフレームにスケジュールされていれば、ステップ708において、協調MS106は、発信MS104のUBIと自機のリソース・サイズを導出するために、自機のUBIに照らしてリソース割当ビットマップをチェックする。ステップ710では、協調MS106は、自機のHARQバースト・サイズを導出するために、発信MS104のUBIに照らしてリソース割当てビットマップを再びチェックする。ステップ712で、協調MS106は、発信MS104のUBIに応じて自機のHFBCHインデックスを算出する。ステップ706において、協調MS106のフローが現在のフレームにスケジュールされていなければ、方法700はステップ714で終了する。
 本発明の実施の形態2による、8ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためのビットマップの一例を図11に示す。図11を参照すると、リソース割当ビットマップ804の中で、協調MS106用の5ビットのリソース割当指示の最初の3ビットが、発信MS104のUBIを指示するために使用され、最後の2ビットが、協調MS106の実際のリソース・サイズではなく、協調MS106の公称リソース・サイズを指示するために使用される。
 協調MSの公称リソース指示から協調MS106の実際のリソース・サイズ指示を算出する手法はいろいろある。一つの手法では、協調MS106の実際のリソース・サイズ指示は、発信MS104のリソース・サイズ指示と協調MS106の公称リソース・サイズ指示とのビット単位の排他論理和演算の結果として得ることができる。図11を参照すると、発信MS104のリソース・サイズ指示が「111」であり、協調MS106の公称リソース・サイズ指示が「01」である。したがって、協調MS106の実際のリソース・サイズ指示は、「111 XOR 01 = 110」となる。別の手法では、協調MS106の実際のリソース・サイズ指示は、発信MS104のリソース・サイズ指示と協調MS106の公称リソース・サイズ指示とのビット単位の論理和または論理積の結果として得ることができる。
 本発明の実施の形態2による、8ビットのユーザ・ビットマップの場合における、協調MS106でグループ・リソース割当情報を受信するための方法900を例示するフローチャートを図12に示す。方法900はステップ902で開始する。ステップ904において、協調MS106は、自機のUBIに照らしてユーザ・ビットマップをチェックする。ステップ906で、協調MS106は、自機のフローが現在のフレームにスケジュールされているか否かを判定する。協調MS106のフローが現在のフレームにスケジュールされていれば、ステップ908において、協調MS106は、発信MS104のUBIを導出するために、リソース割当てビットマップをチェックする。ステップ910では、協調MS106は、自機のHARQバースト・サイズとリソース・サイズを導出するために、自機のUBIと発信MS104のUBIに照らしてリソース割当ビットマップを再びチェックする。ステップ912で、協調MS106は、発信MS104のUBIにより自機のHFBCHインデックスを算出する。ステップ906において、協調MS106のフローが現在のフレームにスケジュールされていなければ、方法900はステップ914で終了する。
 本発明の実施の形態2によれば、8ビットのユーザ・ビットマップの場合と同様に、16ビットのユーザ・ビットマップの場合には、リソース割当ビットマップ中で、協調MS106用の5ビットのリソース割当指示の最初の4ビットが、発信MS104のUBIを指示するために使用され、最後の1ビットが、協調MS106の実際のリソース・サイズではなく、協調MS106の公称リソース・サイズを指示するために使用される。
 本発明の実施の形態2による、32ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためのビットマップの一例を図13に示す。図13を参照すると、リソース割当てビットマップ1004の中で、協調MS106用の5ビットのリソース割当指示の全部が、発信MS104のUBIを指示するために使用される。協調MS106のリソース・サイズは、発信MS104用の3ビットのリソース・サイズ指示によって伝えられる。つまり、32ビットのユーザ・ビットマップの場合には、発信MS104と協調MS106は常に同じリソース・サイズを有する。
 本発明の実施の形態2による、グループ・リソース割当情報を送信するためのGRA MAP IEの一例を表2に示す。
Figure JPOXMLDOC01-appb-T000002
 本発明の実施の形態2による、32ビットのユーザ・ビットマップの場合における、協調MS106でグループ・リソース割当情報を受信するための方法1100を例示するフローチャートを図14に示す。方法1100はステップ1102で開始する。ステップ1104において、協調MS106は、自機のUBIに照らしてユーザ・ビットマップをチェックする。ステップ1106で、協調MS106は、自機のフローが現在のフレームにスケジュールされているか否かを判定する。協調MS106のフローが現在のフレームにスケジュールされていれば、ステップ1108において、協調MS106は、発信MS104のUBIを導出するために、リソース割当てビットマップをチェックする。ステップ1110では、協調MS106は、自機のHARQバースト・サイズとリソース・サイズを導出するために、発信MS104のUBIに照らしてリソース割当ビットマップを再びチェックする。ステップ1112で、協調MS106は、発信MS104のUBIに応じて、自機のHFBCHインデックスを算出する。ステップ1106において、協調MS106のフローが現在のフレームにスケジュールされていなければ、方法1100はステップ1114で終了する。
 協調MS106の視点からは、方法700、900及び1100の間の違いは、自機のリソース・サイズを導出する方法にある。方法700では、協調MS106のリソース・サイズは、自機自身のUBIに照らして導出される。方法900では、協調MS106のリソース・サイズは、自機自身のUBIと発信MS104のUBIとに照らして導出される。方法1100では、協調MS106のリソース・サイズは、発信MS104のUBIのみに照らして導出される。
 本発明の実施の形態2によれば、8ビットのユーザ・ビットマップの場合の代替的な手法は、リソース割当ビットマップの中で、協調MS106用の5ビットのリソース割当指示の最初の3ビットは、発信MS104のUBIを指示するために使用されるが、最後の2ビットは、協調MS106の公称リソース・サイズではなく、協調MS106の実際のリソース・サイズを伝えるために使用される。同様に、16ビットのユーザ・ビットマップの場合の代替的な手法は、リソース割当ビットマップの中で、協調MS106用の5ビットのリソース割当指示の最初の4ビットは、発信MS104のUBIを指示するために使用されるが、最後の1ビットは、協調MS106の実際のリソース・サイズを指示するために使用される。
 本発明の実施の形態2によれば、4ビットのユーザ・ビットマップの場合の代替的な手法は、リソース割当ビットマップの中で、協調MS106用の5ビットのリソース割当指示の最初の2ビットは、発信MS104のUBIを指示するために使用されるが、最後の3ビットは、協調MS106の実際のリソース・サイズではなく、協調MS106の公称リソース・サイズを指示するために使用される。協調MS106の実際のリソース・サイズは、発信MS104のリソース・サイズ指示と協調MS106の公称リソース・サイズ指示から上述した方式で導出することができる。
 本発明の実施の形態2によれば、32ビットのユーザ・ビットマップの場合の代替的な手法は、リソース割当ビットマップの中の協調MS106の5ビットのリソース割当指示の全部が、発信MS104のUBIを伝えるために使用されるが、協調MS106のリソース・サイズは常に予め決められた値に設定される。
 本発明の実施の形態2によれば、BS102によって発信MS104または協調MS106へユニキャストされるグループ・コンフィギュレーション情報の内容は、IEEE 802.16m草案標準(例えば、非特許文献1参照)と同じである。しかしながら、BS102によって発信MS104または協調MS106へマルチキャストされるグループ・リソース割当情報の内容は、IEEE 802.16m草案標準(例えば、非特許文献1参照)とは異なる。
 本発明の実施の形態2によれば、グループ・リソース割当情報は、マルチキャストMAC制御情報またはマルチキャストMAP IEのいずれかで送信され得る。
 (実施の形態3)
 本発明の第1及び実施の形態2によれば、リソース割当ビットマップの中の発信MS104のUBI指示は、協調MS106のUBIとは異なると仮定されている。以下では、リソース割当ビットマップの中の発信MS104のUBI指示が協調MS106のUBIと同じである場合を取り上げる。
 本発明の実施の形態3による、4ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためのビットマップの一例を図15に示す。図15を参照すると、リソース割当ビットマップ1204の中で、協調MS106用の5ビットのリソース割当指示の最初の2ビットが、発信MS104のUBIを指示するために使用される。発信MS104のUBI指示(例えば、「10」)が協調MS106のUBIと同じである場合には、様々な暗示を生じさせ得る。例えば、通信相手のMS106は、その後のN個の連続割当期間にUL/DLデータ・バーストを送信/受信しないことを暗示し得る。ここでNは予め決められている。または、Nの値は協調MS106用の5ビットのリソース割当指示の最後の3ビットによって指示される。あるいは、協調MS106が今後はUL/DLデータ・バーストを送信/受信しないことを暗示し得る。
 本発明の実施の形態3によれば、8ビット、16ビット、または32ビットのユーザ・ビットマップの場合において、リソース割当ビットマップ中の発信MS104のUBI指示が協調MS106のUBIと同じである場合、4ビットのユーザ・ビットマップの場合と同様の暗示を生じさせ得る。
 (実施の形態4)
 本発明の実施の形態1,2,3によれば、発信MS104のUBI指示値の長さは、ユーザ・ビットマップのサイズに依存している。その結果、4ビットのユーザ・ビットマップの場合には、協調MS106のリソース・サイズを伝えるために3ビットが使用可能である。したがって、協調MS106へリソースを割り当てるために8個のリソース・サイズのセットの全部が使用可能となる。しかし、8ビット、16ビット、または32ビットのユーザ・ビットマップの場合には、協調MS106へリソースを割り当てるために8個のリソース・サイズのセットの一部しか使用できない。これは、BS102のスケジューリングの柔軟性を低下させる。
 本発明の実施の形態4による、8ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためのビットマップの一例を図16に示す。図16を参照すると、リソース割当ビットマップ1304の中で、協調MS106用の5ビットのリソース割当指示の最初の2ビットだけが、協調MS106のUBIに相対する発信MS104のUBIのオフセットを指示するために使用され、最後の3ビットが、協調MS106のリソース・サイズを指示するために使用される。
 本発明の実施の形態4による、グループ・リソース割当情報を送信するためのGRA MAP IEの一例を表3に示す。
Figure JPOXMLDOC01-appb-T000003
 本発明の実施の形態4によれば、8ビット、16ビット、または32ビットのユーザ・ビットマップの場合に、発信MS106のUBI指示のために2ビットだけが使用されるので、BS102が発信MS104と協調MS106のそれぞれのフローをグループに加える際に、いろいろな制約が課せられる必要がある。発信MS104と協調MS106のそれぞれのフローをグループに加える際に、BS102は、例えば、下記の制約を受けることがあり得る。  
 ・ 発信MS104のUBIは協調MS106のUBIよりも小さい、及び
 ・ 発信MS104のUBIと協調MS106のUBIとの差が4よりも大きい
 本発明の実施の形態4によれば、協調MS106のリソース・サイズを指示するために3ビットが使用されるので、8ビット、16ビット、または32ビットのユーザ・ビットマップの場合にも、協調MS106のリソースを割り当てるために、8個のリソース・サイズのセットの全部を使用できる。
 (実施の形態5)
 本発明の実施の形態4によれば、BS102が発信MS104と協調MS106のそれぞれのフローをグループに加えるときに、いくつかの制約が課せられる必要がある。これは、BS102のグループ・コンフィギュレーションの柔軟性を低下させる可能性がある。
 本発明の実施の形態5による、8ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためのビットマップの一例を図17に示す。図17を参照すると、リソース割当ビットマップ1404の中で、協調MS106用の5ビットのリソース割当指示の最初の2ビットが、発信MS104のUBIの第1の部分を指示するために使用され、最後の3ビットが、協調MS106のリソース・サイズを指示するために使用される。
 本発明の実施の形態5による、グループ・リソース割当情報を送信するためのGRA MAP IEの一例を表4に示す。
Figure JPOXMLDOC01-appb-T000004
 本発明の実施の形態5によれば、BS102によって協調MS106へユニキャストされるグループ・コンフィギュレーション情報は、発信MS104のUBIの第2の部分を含む。BS102によって協調MS106へユニキャストされるグループ・コンフィギュレーション情報の内容は、以下に挙げることができる。 
 ・ 協調MS106のフロー識別子、
 ・ ユーザ・ビットマップ・サイズ、
 ・ 発信MS104のUBIの第2の部分、
 ・ 協調MS106のUBI、
 ・ グループID、 
 ・ 割当て周期、及び
 ・ MIMOモード・セット、等
 本発明の実施の形態5によれば、8ビットのユーザ・ビットマップの場合に、グループ・コンフィギュレーション情報及びグループ・リソース割当情報で通知される3ビットが、発信MS106のUBI指示のために使用され、BS102が発信MS104と協調MS106のそれぞれのフローをグループに加えるときに何の制約も課されない。
 本発明の実施の形態5によれば、発信MS104のUBIの第1の部分は、発信MS104のUBIのLSB(最下位ビット)側の2ビットであり得る。発信MS104のUBIの第2の部分は、8ビット、16ビット及び32ビットのユーザ・ビットマップの場合にそれぞれ対応して、発信MS104のUBIのMSB(最上位ビット)の1ビット、MSB側の2ビット及びMSB側の3ビットであり得る。
 本発明の実施の形態5によれば、代替的に、発信MS104のUBIの第1の部分は、発信MS104のUBIのMSB側の2ビットであり得る。発信MS104のUBIの第2の部分は、8ビット、16ビット及び32ビットのユーザ・ビットマップの場合にそれぞれ対応して、発信MS104のUBIのLSBの1ビット、LSB側の2ビット及びLSB側の3ビットであり得る。本発明の上述した個々の実施形態によれば、協調MS106が自機のHFBCHを算出するために発信MS104のUBIを使用できるように、BS102は発信MS104のUBIを 協調MS106に共有させる。BS102が協調MS106のUBIを発信MS104に共有させるような、本発明の多様な変形及び/または修正が行なえることは当業者には当然理解されるであろう。
 本発明の上述した個々の実施形態によれば、発信MS104に加えて、1台の協調MS106だけがCliCoにかかわり合う。2台以上の協調MSがCliCoにかかわり合い、そしてBS102は、CliCoに関与する発信MSと複数の協調MSのうちの一つのUBIをその他のMSに共有させるような、本発明の多様な変形及び/または修正が行なえることは当業者には当然理解されるであろう。
 具体的な個々の実施形態として示した本発明のその他の多様な変形及び/または修正は、広義に記述された本発明の精神または範囲を逸脱しない限りにおいて行なえることは当業者には当然理解されるであろう。本文書に述べた個々の実施形態は、したがって、あらゆる点において例示であり、制限的ではないと見なされるべきある。
 なお、上記実施の形態では、本発明をハードウェアで構成する場合を例にとって説明したが、本発明はハードウェアとの連携においてソフトウェアでも実現することも可能である。
 また、上記実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるLSIとして実現される。これらは個別に1チップ化されてもよいし、一部または全てを含むように1チップ化されてもよい。ここでは、LSIとしたが、集積度の違いにより、IC、システムLSI、スーパーLSI、ウルトラLSIと呼称されることもある。
 また、集積回路化の手法はLSIに限るものではなく、専用回路または汎用プロセッサで実現してもよい。LSI製造後に、プログラムすることが可能なFPGA(Field Programmable Gate Array)や、LSI内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。
 さらには、半導体技術の進歩または派生する別技術によりLSIに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
 2010年4月20日出願の特願2010-097026の日本出願に含まれる明細書、図面および要約書の開示内容は、すべて本願に援用される。
 本発明は、移動体通信システム等に適用することができる。

Claims (20)

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

Priority Applications (4)

Application Number Priority Date Filing Date Title
CN201180017170.5A CN102860119B (zh) 2010-04-20 2011-04-20 基站、移动台、发送方法及接收方法
JP2012511551A JP5669827B2 (ja) 2010-04-20 2011-04-20 基地局、移動局、協調移動局、送信方法及び受信方法
US13/638,729 US9031022B2 (en) 2010-04-20 2011-04-20 Base station, mobile station, coordinated mobile station, transmission method and reception method
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
JP2010097026 2010-04-20
JP2010-097026 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 株式会社Nttドコモ ユーザ装置、基地局、発見リソース選択方法、及び制御信号送信方法
JP2017539105A (ja) * 2014-10-13 2017-12-28 テレフオンアクチーボラゲット エルエム エリクソン(パブル) Harqプロセスフィードバックのフレキシブルな設定
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
EP2543224A1 (en) * 2010-03-01 2013-01-09 InterDigital Patent Holdings, Inc. Method and apparatus for performing hybrid per station and per flow uplink allocations
WO2012161532A2 (ko) * 2011-05-26 2012-11-29 엘지전자 주식회사 무선 통신 시스템에서 클라이언트 협력을 위한 연결 해제 방법 및 장치
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
US9549355B2 (en) * 2015-05-08 2017-01-17 Bandwidth.Com, Inc. Optimal use of multiple concurrent internet protocol (IP) data streams for voice communications
US9357079B2 (en) * 2015-05-08 2016-05-31 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
US7231220B2 (en) * 2002-10-01 2007-06-12 Interdigital Technology Corporation Location based method and system for wireless mobile unit communication
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
JPWO2008114510A1 (ja) * 2007-03-19 2010-07-01 パナソニック株式会社 無線通信基地局装置および無線通信方法
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 株式会社Nttドコモ ユーザ装置、基地局、発見リソース選択方法、及び制御信号送信方法
JP2017539105A (ja) * 2014-10-13 2017-12-28 テレフオンアクチーボラゲット エルエム エリクソン(パブル) Harqプロセスフィードバックのフレキシブルな設定
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
US20130021981A1 (en) 2013-01-24
JP5669827B2 (ja) 2015-02-18
US20150173053A1 (en) 2015-06-18
JP2015080256A (ja) 2015-04-23
JP5885817B2 (ja) 2016-03-16
CN102860119A (zh) 2013-01-02
CN102860119B (zh) 2015-07-29
JPWO2011132413A1 (ja) 2013-07-18
US9031022B2 (en) 2015-05-12

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) Arqフィードバック情報伝送及び受信方法
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) 基地局、端末及び通信方法
EP4349101A1 (en) Support for an increased quantity of sidelink configured grants
EP3975627B1 (en) Uplink transmission power control method and device in wireless cellular communication system
JP5668072B2 (ja) 無線通信装置およびハイブリッド自動再送要求送信方法
US20230362932A1 (en) Method and apparatus for transmitting/receiving signal for groupcast in wireless communication system

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