Handover requested and controlled by the mobile station in a broadband wireless access communication system
Abstract
A system and method for performing a handover operation in a broadband wireless access (BWA) communication system. The BWA communication system includes a serving BS (Base Station),(Subscriber Station), and a plurality of neighbor BSs adjacent to the serving BS. The SS handover method upon receiving a handover request from the SS in the BWA communication system includes the steps of: a) receiving from the serving BS information of the plurality of neighbor BSs; b) measuring CINRs (Carrier to Interference and Noise Ratios) of pilot signals transferred from the neighbor BSs upon receipt of the neighbor BSs information; c) transmitting to the serving BS a handover request signal along with pilot signal CINR information of the neighbor BSs; d) upon receipt of the handover request signal, receiving from the serving BS information of a handover enable target BS contained in the neighbor BSs; and e) performing a handover function from the serving BS to the target BS.
Term
Term ended
Projected expiry passed 8 March 2024, 2.5 years ago.
- Priority
- Filed
- Published
- Projected expiry
- Today
34 claims: 5 independent, 29 dependent
- 1A subscriber station (SS) handover method upon receiving a handover request from the SS in a BWA (Broadband Wireless Access) communication system comprised of a serving BS (Base Station) and a plurality of neighbor BSs adjacent to the serving BS, comprising the steps of:a) receiving from the serving BS information relating to the plurality of neighbor BSs;b) measuring CINRs (Carrier to Interference and Noise Ratios) of pilot signals transferred from the neighbor BSs upon receipt of the information relating to the neighbor BSs;c) transmitting a handover request signal to the serving BS along with pilot signal CINR information of the neighbor BSs;d) receiving from the serving BS information of a target BS from among the neighbor BSs;and e) performing a handover function from the serving BS to the target BS.
- 6A serving BS (Base Station) handover method upon receiving a handover request from an SS (Subscriber Station) in a BWA (Broadband Wireless Access) communication system comprised of a serving BS and a plurality of neighbor BSs adjacent to the serving BS, comprising the steps of:a) transmitting to the SS information relating to the neighbor BSs;b) receiving a handover request signal containing CINR (Carrier to Interference and Noise Ratio) information of pilot signals of the neighbor BSs from the SS;c) determining if the neighbor BSs contained in the handover request signal can support a handover function for the SS, and selecting a target BS acting as a handover target of the SS from among neighbor BSs capable of supporting the handover function for the SS;and d) transmitting a response signal associated with the handover request signal of the SS along with the target BS information, and informing the target BS of a handover ready state of the SS.
- 12An SS (Subscriber Station) handover method upon receiving a handover request from the SS (Subscriber Station) in a BWA (Broadband Wireless Access) communication system comprised of a serving BS (Base Station) and a plurality of neighbor BSs adjacent to the serving BS, comprising the steps of:a) receiving from the serving BS information relating to the plurality of neighbor BSs and handover condition information;b) measuring CINRs (Carrier to Interference and Noise Ratios) of pilot signals transferred from the neighbor BSs upon receipt of the neighbor BSs information;c) selecting a plurality of candidate BSs corresponding to the handover condition information from among the neighbor BSs, and transmitting a handover request signal to the serving BS along with pilot signal CINR information of the candidate BSs;d) upon receipt of the handover request signal, receiving from the serving BS information of a target BS from among the candidate BSs;and e) performing a handover function from the serving BS to the target BS.
- 17A handover method upon receiving a handover request from an SS (Subscriber Station) in a BWA (Broadband Wireless Access) communication system comprised of a serving BS (Base Station) and a plurality of neighbor BSs adjacent to the serving BS, comprising the steps of:a) controlling the serving BS to transmit to the SS information of the neighbor BSs and handover condition information;b) controlling the SS to measure CINRs (Carrier to Interference and Noise Ratios) of pilot signals transferred from the neighbor BSs according to the neighbor BSs information;c) controlling the SS to determine a plurality of candidate BSs corresponding to handover condition information from among the neighbor BSs, and transmitting to the serving BS a handover request signal along with pilot signal CINR information of the candidate BSs;d) if the serving BS receives the handover request signal from the SS, determining if the neighbor BSs contained in the handover request signal can support a handover function for the SS, and selecting a target BS acting as a handover target of the SS from among candidate BSs capable of supporting the handover function for the SS;e) controlling the serving BS to transmit a response signal associated with the handover request signal to the SS along with the target BS information, and informing the target BS of a handover ready state of the SS;and f) controlling the SS to perform a handover operation from the serving BS to the target BS according to the target BS information contained in the handover request response signal.
- 26A handover apparatus upon receiving a handover request from the SS (Subscriber Station) in a BWA (Broadband Wireless Access) communication system comprised of a serving BS (Base Station) and a plurality of neighbor BSs adjacent to the serving BS, comprising:the serving BS, which transmits information of the neighbor BSs and handover condition information to the SS, determines if the neighbor BSs contained in the handover request signal can support a handover function for the SS upon receiving the handover request signal from the SS, selects a target BS acting as a handover target of the SS from among candidate BSs capable of supporting the handover function for the SS, transmits a response signal associated with the handover request signal to the SS along with the target BS information, and informs the target BS of a handover ready state of the SS;and the SS, which measures CINRs (Carrier to Interference and Noise Ratios) of pilot signals transferred from the neighbor BSs according to the neighbor BSs information, selects a plurality of candidate BSs corresponding to handover condition information from among the neighbor BSs, transmits a handover request signal to the serving BS along with pilot signal CINR information of the candidate BSs, and performs a handover operation from the serving BS to the target BS according to the target BS information contained in the handover request response signal.
Independent claims5
92 paragraphs in 4 sections, as filed
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to a broadband wireless access communication system, and more particularly to a system and method for performing a handover operation upon receipt of an SS (Subscriber Station) request in a BWA (Broadband Wireless Access) communication system using an OFDM (Orthogonal Frequency Division Multiplexing) scheme.
2. Description of the Related Art
Intensive research is being conducted into the 4G (4th Generation) communication system, one of the next generation communication systems, to provide a plurality of users with specific services having a variety of QoSs (Quality of Services) at a transfer rate of about 100 Mbps. Presently, the 3G (3rd Generation) communication system provides a transfer rate of about 384kbps in an outdoor channel environment having a relatively poor channel environment, and provides a maximum transfer rate of about 2Mbps in an indoor channel environment having a relatively good channel environment. A wireless Local Area Network (LAN) system and a wireless Metropolitan Area Network (MAN) system have been designed to provide a transfer rate of 20~50 Mbps. The 4G communication system provides the wireless LAN and MAN systems a relatively high transfer rate with mobility and QoS, and many secondory developers are conducting intensive research into high-speed services to be provided from the 4G communication system.
However, the wireless MAN system is suitable for a high-speed communication service in that it has a wide coverage area and supports a high-speed transfer rate, but it does not consider the mobility of a subscriber station (SS) at all, so that there is no consideration of the need for a handover operation (i.e., a cell selection operation) caused by the movement of the SS. The communication system currently considered in IEEE (Institute of Electrical and Electronics Engineers) 802.16a specification acts as a specific communication system for performing a ranging operation between the SS and a base station (BS). The communication system considered in the IEEE 802.16a specification will hereinafter be described with reference to Fig. 1.
Fig. 1 is a block diagram illustrating a BWA communication system using an OFDM/OFDMA (Orthogonal Frequency Division Multiplexing / Orthogonal Frequency Division Multiple Access) scheme. In more detail, Fig. 1 depicts the IEEE 802.16a communication system.
The wireless MAN system acting as a BWA communication system has a much wider coverage area and a much higher transfer rate than the wireless LAN system. In case of adapting the OFDM scheme and the OFDMA scheme to a physical channel of the wireless MAN system to provide the wireless MAN system with a broadband transmission network, this application system is referred to as an IEEE 802.16a communication system. The IEEE 802.16a communication system applies the OFDM/OFDMA scheme to the wireless MAN system, such that it transmits a physical channel signal using a plurality of sub-carriers, resulting in high-speed data transmission. The IEEE 802.16e communication system has been designed to consider the mobility of an SS in the IEEE 802.16a communication system. There is no detailed specification for the IEEE 802.16e communication system.
Referring to Fig. 1, the IEEE 802.16a communication system has a single cell structure, and is composed of a BS 100 and a plurality of SSs 110, 120, and 130 managed by the BS 100. Signal transmission/reception among the BS 100 and the SSs 110, 120, and 130 can be established using the OFDM/OFDMA scheme. A downlink frame structure for use in the IEEE 802.16a communication system will hereinafter be described with reference to Fig. 2.
Fig. 2 is a conceptual diagram illustrating the downlink frame structure for use in the BWA communication system using the OFDM/OFDMA scheme. In more detail, Fig. 2 depicts a downlink frame structure for use in the IEEE 802.16a communication system.
Referring to Fig. 2, the downlink frame includes a preamble field 200, a broadcast control field 210, and a plurality of TDM (Time Division Multiplexing) fields 220 and 230. A synchronous signal (i.e., a preamble sequence) for acquiring synchronization between the BS and the SSs is transmitted via the preamble field 200. The broadcast control field 210 is composed of a DL(DownLink)_MAP field 211 and a UL(UpLink)_MAP field 213. The DL_MAP field 211 is adapted to transmit the DL_MAP message, and a plurality of IEs (Information Elements) contained in the DL_MAP message are shown in the following Table 1: <tables id="tabl0001" num="0001"><table frame="all"><title>[Table 1]</title><tgroup cols="3" colsep="1" rowsep="1"><colspec colnum="1" colname="col1" colwidth="52.50mm" /><colspec colnum="2" colname="col2" colwidth="52.50mm" /><colspec colnum="3" colname="col3" colwidth="52.50mm" /><thead valign="top"><row rowsep="1"><entry namest="col1" nameend="col1" align="center">Syntax</entry><entry namest="col2" nameend="col2" align="center">Size</entry><entry namest="col3" nameend="col3" align="center">Notes</entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" align="left">DL MAP Message Format() {</entry><entry namest="col2" nameend="col2" /><entry namest="col3" nameend="col3" /></row><row><entry namest="col1" nameend="col1" align="left">Management Message Type=2</entry><entry namest="col2" nameend="col2" align="left">8 bits</entry><entry namest="col3" nameend="col3" /></row><row><entry namest="col1" nameend="col1" align="left">PHY Synchronization Field</entry><entry namest="col2" nameend="col2" align="left">Variable</entry><entry namest="col3" nameend="col3" align="left">See appropriate PHY specification</entry></row><row><entry namest="col1" nameend="col1" align="left">DCD Count</entry><entry namest="col2" nameend="col2" align="left">8 bits</entry><entry namest="col3" nameend="col3" /></row><row><entry namest="col1" nameend="col1" align="left">Base Station ID</entry><entry namest="col2" nameend="col2" align="left">48 bits</entry><entry namest="col3" nameend="col3" /></row><row><entry namest="col1" nameend="col1" align="left">Number of DL MAP Element n</entry><entry namest="col2" nameend="col2" align="left">16 bits</entry><entry namest="col3" nameend="col3" /></row><row><entry namest="col1" nameend="col1" align="left">Begin PHY Specific section {</entry><entry namest="col2" nameend="col2" /><entry namest="col3" nameend="col3" align="left">See applicable PHY section</entry></row><row><entry namest="col1" nameend="col1" align="left"> for (I=1; i<=n; i+t)</entry><entry namest="col2" nameend="col2" /><entry namest="col3" nameend="col3" align="left">For each DL_MAP element 1 to n</entry></row><row><entry namest="col1" nameend="col1" align="left">DL_MAP Information Element( )</entry><entry namest="col2" nameend="col2" align="left">Variable</entry><entry namest="col3" nameend="col3" align="left">See corresponding PHY specification</entry></row><row><entry namest="col1" nameend="col1" align="left"> if! (byte boundary) {</entry><entry namest="col2" nameend="col2" /><entry namest="col3" nameend="col3" /></row><row><entry namest="col1" nameend="col1" align="left"> Padding Nibble</entry><entry namest="col2" nameend="col2" align="left">4 bits</entry><entry namest="col3" nameend="col3" align="left">Padding to reach byte boundary</entry></row><row><entry namest="col1" nameend="col1" align="left"> }</entry><entry namest="col2" nameend="col2" /><entry namest="col3" nameend="col3" /></row><row><entry namest="col1" nameend="col1" align="left"> }</entry><entry namest="col2" nameend="col2" /><entry namest="col3" nameend="col3" /></row><row><entry namest="col1" nameend="col1" align="left"> }</entry><entry namest="col2" nameend="col2" /><entry namest="col3" nameend="col3" /></row><row rowsep="1"><entry namest="col1" nameend="col1" align="left"> }</entry><entry namest="col2" nameend="col2" /><entry namest="col3" nameend="col3" /></row></tbody></tgroup></table></tables>
With reference to the above Table 1, the DL_MAP message includes a Management Message Type field indicative of a plurality of IEs (i.e., transmission message type information); a PHY (PHYsical) Synchronization field established in response to a modulation or demodulation scheme applied to a physical channel in order to perform synchronization acquisition; a DCD count field indicative of count information in response to a DCD (Downlink Channel Descriptor) message configuration variation containing a downlink burst profile; a Base Station ID field indicative of a Base Station Identifier; and a Number of DL_MAP Element n field indicative of the number of elements found after the Base Station ID. Particularly, the DL_MAP message (not shown in Table 1) includes information associated with ranging codes allocated to individual ranging processes to be described later.
The UL_MAP field 213 is adapted to transmit the UL_MAP message, and a plurality of IEs contained in the UL_MAP message are shown in the following Table 2: <tables id="tabl0002" num="0002"><table frame="all"><title>[Table 2]</title><tgroup cols="2" colsep="1" rowsep="1"><colspec colnum="1" colname="col1" colwidth="78.75mm" /><colspec colnum="2" colname="col2" colwidth="78.75mm" /><thead valign="top"><row rowsep="1"><entry namest="col1" nameend="col1" align="center">Syntax</entry><entry namest="col2" nameend="col2" align="center">Size</entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" align="left">UL MAP Message Format(){</entry><entry namest="col2" nameend="col2" /></row><row><entry namest="col1" nameend="col1" align="left"> Management Message Type=3</entry><entry namest="col2" nameend="col2" align="left">8 bits</entry></row><row><entry namest="col1" nameend="col1" align="left"> Uplink Channel ID</entry><entry namest="col2" nameend="col2" align="left">8 bits</entry></row><row><entry namest="col1" nameend="col1" align="left"> UCD Count</entry><entry namest="col2" nameend="col2" align="left">8 bits</entry></row><row><entry namest="col1" nameend="col1" align="left"> Number of UL MAP Element n</entry><entry namest="col2" nameend="col2" align="left">16 bits</entry></row><row><entry namest="col1" nameend="col1" align="left"> Allocation Start Time</entry><entry namest="col2" nameend="col2" align="left">32 bits</entry></row><row><entry namest="col1" nameend="col1" align="left"> Begin PHY Specific section {</entry><entry namest="col2" nameend="col2" /></row><row><entry namest="col1" nameend="col1" align="left"> for (i=1; i<n; i+n)</entry><entry namest="col2" nameend="col2" /></row><row><entry namest="col1" nameend="col1" align="left"> UL MAP Information Element( )</entry><entry namest="col2" nameend="col2" align="left">Variable</entry></row><row><entry namest="col1" nameend="col1" align="left"> Connection ID</entry><entry namest="col2" nameend="col2" /></row><row><entry namest="col1" nameend="col1" align="left"> UIUC</entry><entry namest="col2" nameend="col2" /></row><row><entry namest="col1" nameend="col1" align="left"> Offset -</entry><entry namest="col2" nameend="col2" /></row><row><entry namest="col1" nameend="col1" align="left"> }</entry><entry namest="col2" nameend="col2" /></row><row><entry namest="col1" nameend="col1" align="left"> }</entry><entry namest="col2" nameend="col2" /></row><row><entry namest="col1" nameend="col1" align="left"> }</entry><entry namest="col2" nameend="col2" /></row><row rowsep="1"><entry namest="col1" nameend="col1" align="left">}</entry><entry namest="col2" nameend="col2" /></row></tbody></tgroup></table></tables>
With reference to Table 2, the UL_MAP message includes a Management Message Type field indicative of a plurality of IEs (i.e., transmission message type information); an Uplink Channel ID field indicative of a used Uplink Channel ID; a UCD (Uplink Channel Descriptor) count field indicative of count information in response to a UCD message configuration variation containing an uplink burst profile; and a Number of UL_MAP Element n field indicative of the number of elements found after the UCD count field. In this case, the uplink channel ID can only be allocated to a Media Access Control (MAC) sub-layer.
The UIUC (Uplink Interval Usage Code) area records information indicative of the usage of offsets recorded in the offset area. For example, provided that 2 is recorded in the UIUC area, a starting offset for use in the initial ranging process is recorded in the offset area. Provided that 3 is recorded in the UIUC area, a starting offset for use in either the bandwidth request ranging or the maintenance ranging process is recorded in the offset area. The offset area records a starting offset value for use in either the initial ranging process or the maintenance ranging process according to the information recorded in the UIUC area. Physical channel characteristic information to be transferred from the UIUC area is recorded in the UCD.
Provided that the SS results in a ranging failure, a predetermined backoff value is set up to increase the probability of success in the next trial, and the ranging process is re-performed after the lapse of a predetermined time corresponding to the backoff time. In this case, information needed for determining the backoff value is contained in the UCD message. The aforementioned UCD message configuration is shown in the following Table 3: <tables id="tabl0003" num="0003"><table frame="all"><title>[Table 3]</title><tgroup cols="3" colsep="1" rowsep="1"><colspec colnum="1" colname="col1" colwidth="52.50mm" /><colspec colnum="2" colname="col2" colwidth="52.50mm" /><colspec colnum="3" colname="col3" colwidth="52.50mm" /><thead valign="top"><row rowsep="1"><entry namest="col1" nameend="col1" align="center">Syntax</entry><entry namest="col2" nameend="col2" align="center">Size</entry><entry namest="col3" nameend="col3" align="center">Notes</entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" align="left">UCD-Message Format(){</entry><entry namest="col2" nameend="col2" /><entry namest="col3" nameend="col3" /></row><row><entry namest="col1" nameend="col1" align="left">Management Message Type=0</entry><entry namest="col2" nameend="col2" align="left">8 bits</entry><entry namest="col3" nameend="col3" /></row><row><entry namest="col1" nameend="col1" align="left">Unlink channel ID</entry><entry namest="col2" nameend="col2" align="left">8 bits</entry><entry namest="col3" nameend="col3" /></row><row><entry namest="col1" nameend="col1" align="left">Configuration Change Count</entry><entry namest="col2" nameend="col2" align="left">8 bits</entry><entry namest="col3" nameend="col3" /></row><row><entry namest="col1" nameend="col1" align="left">Mini-slot size</entry><entry namest="col2" nameend="col2" align="left">8 bits</entry><entry namest="col3" nameend="col3" /></row><row><entry namest="col1" nameend="col1" align="left">Ranging Backoff Start</entry><entry namest="col2" nameend="col2" align="left">8 bits</entry><entry namest="col3" nameend="col3" /></row><row><entry namest="col1" nameend="col1" align="left">Ranging Backoff End</entry><entry namest="col2" nameend="col2" align="left">8 bits</entry><entry namest="col3" nameend="col3" /></row><row><entry namest="col1" nameend="col1" align="left">Request Backoff Start</entry><entry namest="col2" nameend="col2" align="left">8 bits</entry><entry namest="col3" nameend="col3" /></row><row><entry namest="col1" nameend="col1" align="left">Request Backoff End</entry><entry namest="col2" nameend="col2" align="left">8 bits</entry><entry namest="col3" nameend="col3" /></row><row><entry namest="col1" nameend="col1" align="left">TLV Encoded Information for the overall channel</entry><entry namest="col2" nameend="col2" align="left">Variable</entry><entry namest="col3" nameend="col3" /></row><row><entry namest="col1" nameend="col1" align="left">Begin PHY Specific Section {</entry><entry namest="col2" nameend="col2" /><entry namest="col3" nameend="col3" /></row><row><entry namest="col1" nameend="col1" align="left"> for (i=1; i<n; i+n)</entry><entry namest="col2" nameend="col2" /><entry namest="col3" nameend="col3" /></row><row><entry namest="col1" nameend="col1" align="left"> Uplink Burst Descriptor</entry><entry namest="col2" nameend="col2" align="left">Variable</entry><entry namest="col3" nameend="col3" /></row><row><entry namest="col1" nameend="col1" align="left"> }</entry><entry namest="col2" nameend="col2" /><entry namest="col3" nameend="col3" /></row><row><entry namest="col1" nameend="col1" align="left"> }</entry><entry namest="col2" nameend="col2" /><entry namest="col3" nameend="col3" /></row><row rowsep="1"><entry namest="col1" nameend="col1" align="left">}</entry><entry namest="col2" nameend="col2" /><entry namest="col3" nameend="col3" /></row></tbody></tgroup></table></tables>
With reference to the Table 3, the UCD message includes a Management Message Type field Indicative of a plurality of IEs (i.e., transmission message type information); an Uplink Channel ID field indicative of a used Uplink Channel Identifier; a Configuration Change Count field counted by the BS; a mini-slot size field indicative of the number of mini-slots of the uplink physical channel; a Ranging Backoff Start field indicative of a backoff start point for an initial ranging process, i.e., an initial backoff window size for the initial ranging process; a Ranging Backoff End field indicative of a backoff end point for the initial ranging process, i.e., a final backoff window size; a Request Backoff Start field indicative of a backoff start point for establishing contention data and requests, i.e., an initial backoff window size; and a Request Backoff End field indicative of a backoff end point for establishing contention data and requests, i.e., a final backoff window size. In this case, the backoff value indicates a kind of standby time which is a duration time between the start of SS's access failure and the start of SS's re-access time. If the SS fails to execute an initial ranging process, the BS must transmit the backoff values indicative of standby time information for which the SS must wait for the next ranging process to the SS. For example, provided that a specific number of 10 is determined by the "Ranging Backoff Start" and "Ranging Backoff End" fields shown in Table 3, the SS must pass over 2<sup>10</sup> access executable chances (i.e., 1024 access executable chances) and then execute the next ranging process according to a Truncated Binary Exponential Backoff Algorithm.
The TDM fields 220 and 230 indicate fields corresponding to timeslots allocated using a TDM/TDMA (Time Division Multiplexing / Time Division Multiple Access) scheme. The BS transmits broadcast information to be broadcast to SSs managed by the BS over the DL_MAP field 211 using a predetermined center carrier. The SSs monitor all the frequency bands having been previously allocated to individual SSs upon receipt of a power-on signal, such that they detect a pilot channel signal having the highest signal intensity, i.e., the highest pilot CINR (Carrier to Interference and Noise Ratio). It is determined that the SS belongs to a specific BS which has transmitted the pilot channel signal with the highest pilot CINR. The SSs check the DL_MAP field 211 and the UL_MAP field 213 of the downlink frame having been transmitted from the BS, such that they recognize their own uplink and downlink control information and specific information indicative of a real data transmission/reception position.
The downlink frame structure for use in the IEEE 802.16a communication system has been disclosed with reference to Fig. 2. An uplink frame structure for use in the IEEE 802.16a communication system will hereinafter be described with reference to Fig. 3.
Fig. 3 is a conceptual diagram illustrating an uplink frame structure for use in a BWA communication system using an OFDM/OFDMA scheme. In more detail, Fig. 3 depicts an uplink frame structure for use in the IEEE 802.16a communication system.
Prior to describing the uplink frame structure shown in Fig. 3, three ranging processes for use in the IEEE 802.16a communication system, i.e., an initial ranging process, a maintenance ranging process (also called a period ranging process), and a bandwidth request ranging process will hereinafter be described in detail.
First, the initial ranging process will be described in detail.
The initial ranging process for establishing synchronization acquisition between the BS and the SS establishes a correct time offset between the SS and the BS, and is adapted to control a transmission power (also called a transmit power). In more detail, the SS is powered on, and receives the DL_MAP message, the UL MAP message, and the UCD message to establish synchronization with the BS in such a way that it performs the initial ranging process to control the transmission power between the BS and the time offset. In this case, the IEEE 802.16a communication system uses the OFDM/OFDMA scheme, such that the ranging procedure requires a plurality of ranging sub-channels and a plurality of ranging codes. The BS allocates available ranging codes to the SS according to objectives of the ranging processes (i.e., the ranging process type information). This operation will hereinafter be described in detail.
The ranging codes are created by segmenting a PN (Pseudorandom Noise) sequence having a length of 2<sup>15</sup>-1 bits into predetermined units. Typically, one ranging channel is composed of two ranging sub-channels each having a length of 53 bits, PN code segmentation is executed over the ranging channel having the length of 106 bits, resulting in the creation of a ranging code. A maximum of 48 ranging codes RC#1~RC#48 can be assigned to the SS. More than two ranging codes for every SS are applied as a default value to the three ranging processes having different objectives, i.e., an initial ranging process, a period ranging process, and a bandwidth request ranging process. In this way, a ranging code is differently assigned to the SS according to each objective of the three ranging processes. For example, N ranging codes are assigned to the SS for the initial ranging process as denoted by a prescribed term of "N RC (Ranging Codes) for Initial Ranging", M ranging codes are assigned to the SS for the periodic ranging process as denoted by a prescribed term of "M RCs for maintenance ranging", and L ranging codes are assigned to the SS for the bandwidth request ranging process as denoted by a prescribed term of "L RCs for BW-request ranging". The assigned ranging codes are transmitted to the SSs using the DL MAP message, and the SSs perform necessary ranging procedures using the ranging codes contained in the DL_MAP message.
Second, the period ranging process will be described in detail.
The period ranging process is periodically executed such that an SS which has controlled a time offset between the SS and the BS, and a transmission power in the initial ranging process can control a channel state associated with the BS. The SS performs the period ranging process using the ranging codes assigned for the period ranging process.
Third, the bandwidth request ranging process will be described.
The bandwidth request ranging process is adapted to enable the SS, which has controlled a time offset between the SS and the BS, and a transmission power in the initial ranging process, to request a bandwidth allocation from the BS in such a way that the SS can communicate with the BS.
Referring to Fig. 3, the uplink frame includes an initial maintenance opportunity field 300 using the initial and period ranging processes, a request contention opportunity field 310 using the bandwidth request ranging process, and an SS scheduled data field 320 composed of uplink data of a plurality of SSs. The initial maintenance opportunity field 300 includes a plurality of access burst fields each having real initial and period ranging processes, and a collision field in which there is a collision between the access burst fields. The request contention opportunity field 310 inludes a plurality of bandwidth request fields each having a real bandwidth request ranging process, and a collision field in which there is a collision between the bandwidth request ranging fields. The SS scheduled data fields 320 are each composed of a plurality of SS scheduled data fields (i.e., SS 1 scheduled data field ~ SS N scheduled data field). The SS transition gap is positioned between the SS scheduled data fields (i.e., SS 1 scheduled data field ~ SS N scheduled data field).
Fig. 3 has disclosed the uplink frame structure for the IEEE 802.16a communication system. A ranging procedure for the IEEE 802.16a communication system using an OFDM scheme will hereinafter be described with reference to Fig. 4.
Fig. 4 is a flow chart illustrating the ranging procedure between the SS and the BS in a BWA communication system using the OFDM scheme.
Referring to Fig. 4, the SS 400 monitors all of its own predetermined frequencies upon receipt of a power-on signal, such that it detects a pilot channel signal having the highest signal intensity, i.e., the highest pilot CINR (Carrier to Interference and Noise Ratio). It is determined that SS 400 belongs to a specific BS 420 which has transmitted the pilot channel signal with the highest pilot CINR. The SS 400 receives a downlink frame preamble from the BS 420, such that it acquires system synchronization with the BS 420.
Upon establishing synchronization between the SS 400 and the BS 420, the BS 420 transmits the DL_MAP message and the UL_MAP message to the SS 400 at steps 411 and 413, respectively. As previously shown in Table 1, the DL_MAP message includes a variety of information, for example, requisite information for establishing synchronization between the SS 400 and the BS 420 in a downlink direction and configuration information of a physical channel capable of receiving a variety of messages transmitted to a plurality of SSs 400 over a downlink channel. As previously shown in Table 2, the UL_MAP message informs the SS 400 of SS scheduling interval information and physical channel configuration information, etc.
The DL_MAP message is periodically broadcast from the BS to all the SSs. In the case where the SS 400 can continuously receive the periodically-broadcast DL MAP message, it is assumed that the SS is synchronized with the BS. The SSs receiving the DL_MAP message can receive all the messages transmitted over a downlink channel.
As stated above in Table 3, if the SS results in an access failure, the BS transmits the UCD message containing available backoff value indication information to the SS.
In case of performing the above ranging process, the SS 400 transmits an RNG_REQ (Ranging Request) message to the BS 420 at step 415. The BS 420 receiving the RNG_REQ message transmits an RNG_RSP (Ranging Response) message containing information for controlling a variety of factors (e.g., frequency, time, and transmission power) to the SS 400 at step 417.
The RNG_REQ message configuration is shown in the following Table 4: <tables id="tabl0004" num="0004"><table frame="all"><title>[Table 4]</title><tgroup cols="3" colsep="1" rowsep="1"><colspec colnum="1" colname="col1" colwidth="52.50mm" /><colspec colnum="2" colname="col2" colwidth="52.50mm" /><colspec colnum="3" colname="col3" colwidth="52.50mm" /><thead valign="top"><row rowsep="1"><entry namest="col1" nameend="col1" align="center">Syntax</entry><entry namest="col2" nameend="col2" align="center">Size</entry><entry namest="col3" nameend="col3" align="center">Notes</entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" align="left">RNG-REQ Message Format() {</entry><entry namest="col2" nameend="col2" /><entry namest="col3" nameend="col3" /></row><row><entry namest="col1" nameend="col1" align="left">Management Message Type=4</entry><entry namest="col2" nameend="col2" align="left">8 bits</entry><entry namest="col3" nameend="col3" /></row><row><entry namest="col1" nameend="col1" align="left">Downlink Channel ID</entry><entry namest="col2" nameend="col2" align="left">8 bits</entry><entry namest="col3" nameend="col3" /></row><row><entry namest="col1" nameend="col1" align="left">Pending Until Complete,</entry><entry namest="col2" nameend="col2" align="left">8 bits</entry><entry namest="col3" nameend="col3" /></row><row><entry namest="col1" nameend="col1" align="left">TLV Encoded Information</entry><entry namest="col2" nameend="col2" align="left">Variable</entry><entry namest="col3" nameend="col3" align="left">TLV specific</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" /></row></tbody></tgroup></table></tables>
With reference to Table 4, the Downlink Channel ID field indicates a downlink channel ID contained in the RNG-REQ message received in the SS via the UCD. The Pending Until Complete field indicates priority information of a transmission ranging response. In more detail, if the Pending Until Complete field is set to "0", a previous ranging response has priority. Otherwise, if the Pending Until Complete field is not set to "0", a current transmission ranging response has priority.
A detailed configuration of the RNG_RSP message to the RNG REQ message shown in Table'4 is shown in Table 5: <tables id="tabl0005" num="0005"><table frame="all"><title>[Table 5]</title><tgroup cols="3" colsep="1" rowsep="1"><colspec colnum="1" colname="col1" colwidth="52.50mm" /><colspec colnum="2" colname="col2" colwidth="52.50mm" /><colspec colnum="3" colname="col3" colwidth="52.50mm" /><thead valign="top"><row rowsep="1"><entry namest="col1" nameend="col1" align="center">Syntax</entry><entry namest="col2" nameend="col2" align="center">Size</entry><entry namest="col3" nameend="col3" align="center">Notes</entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" align="left">RNG_RSP_Message Format() {</entry><entry namest="col2" nameend="col2" /><entry namest="col3" nameend="col3" /></row><row><entry namest="col1" nameend="col1" align="left">Management Message Type=5</entry><entry namest="col2" nameend="col2" align="left">8 bits</entry><entry namest="col3" nameend="col3" /></row><row><entry namest="col1" nameend="col1" align="left">Uplink Channel ID</entry><entry namest="col2" nameend="col2" align="left">8 bits</entry><entry namest="col3" nameend="col3" /></row><row><entry namest="col1" nameend="col1" align="left">TLV Encoded Informatipm</entry><entry namest="col2" nameend="col2" align="left">Variable</entry><entry namest="col3" nameend="col3" align="left">TLV specific</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" /></row></tbody></tgroup></table></tables>
With reference to Table 5, the Uplink Channel ID field indicates an uplink channel ID contained in the RNG_REQ message.
Fig. 4 has disclosed the ranging process when the IEEE 802.16a communication system uses the OFDM scheme. A ranging procedure for the IEEE 802.16a communication system using the OFDMA scheme will hereinafter be described with reference to Fig. 5. In this case, the IEEE 802.16a communication system contains a dedicated ranging interval in order to enable the IEEE 802.16a communication system to more effectively perform the ranging process using the OFDMA scheme, so that it may transmit the Ranging-Code instead of the RNG_REQ message according to a ranging code transmission scheme in the dedicated ranging interval.
Referring to Fig. 5, the BS 520 transmits the DL_MAP message and the UL_MAP message to the SS 500 at steps 511 and 513, respectively. Detailed operations of steps 511 and 513 are equal to those of steps 411 and 413. The communication system using the OFDMA scheme of Fig. 5 transmits a ranging code instead of the RNG-REQ message having been described in Fig. 4 at step 515. The BS 520 receiving the ranging code transmits the RNG_RSP message to the SS 500 at step 517.
New information must be added to the RNG_RSP message such that information corresponding to the ranging code transmitted to the BS can be recorded in the RNG_RSP message. The aforementioned new information to be added to the RNG_RSP message is composed of a ranging code (i.e., a received ranging CDMA code), a ranging symbol (i.e., an OFDM symbol in the received ranging CDMA code), a ranging sub-channel (i.e., a ranging sub-channel in the received ranging CDMA code), and a ranging frame number (i.e., a frame number in the received ranging CDMA code).
As described above, the IEEE 802.16a communication system operates on the basis of a fixed state of a current SS (i.e., there is no consideration given to the mobility of the SS) and a single cell structure. However, the IEEE 802.16e communication system has been defined as a system for considering the SS's mobility in the IEEE 802.16a communication system, such that the IEEE 802.16e communication system must consider the SS's mobility in a multi-cell environment. In order to provide the SS's mobility in the multi-cell environment, individual operating modes of the SS and the BS must be converted . However, the IEEE 802.16e communication system has not proposed a new method for the SS's mobility in the multi-cell environment. In conclusion, a handover system considering both an idle state and a communication service execution mode must be developed to provide mobility to an SS in a IEEE 802.16e communication system .
SUMMARY OF THE INVENTION
Therefore, the present invention has been made in view of the above problems, and it is an object of the present invention to provide a system and method for performing a handover operation in a BWA communication system.
It is another object of the present invention to provide a system and method for performing a handover operation upon receipt of an SS request signal in a BWA communication system.
In accordance with one aspect of the present invention, the above and other objects can be accomplished by the provision of a subscriber station (SS) handover method upon receiving a handover request from the SS in a BWA (Broadband Wireless Access) communication system comprised of a serving BS (Base Station) and a plurality of neighbor BSs adjacent to the serving BS, comprising the steps of: a) receiving from the serving BS information relating to the plurality of neighbor BSs; b) measuring CINRs (Carrier to Interference and Noise Ratios) of pilot signals transferred from the neighbor BSs upon receipt of the information relating to the neighbor BSs; c) transmitting a handover request signal to the serving BS along with pilot signal CINR information of the neighbor BSs; d) upon receipt of the handover request signal, receiving from the serving BS information of a target BS inform among the neighbor BSs; and e) performing a handover function from the serving BS to the target BS.
In accordance with another aspect of the present invention, there is provided a serving BS (Base Station) handover method upon receiving a handover request from an SS (Subscriber Station) in a BWA (Broadband Wireless Access) communication system comprised of a serving BS and a plurality of neighbor BSs adjacent to the serving BS, comprising the steps of: a) transmitting to the SS information relating to 'the neighbor BSs; b) receiving from the SS a handover request signal containing CINR (Carrier to Interference and Noise Ratio) information of pilot signals of the neighbor BSs; c) determining if the neighbor BSs contained in the handover request signal can support a handover function for the SS, and selecting a target BS acting as a handover target of the SS from among neighbor BSs capable of supporting the handover function for the SS; and d) transmitting a response signal associated with the handover request signal of the SS along with the target BS information, and informing the target BS of a handover ready state of the SS.
In accordance with yet another aspect of the present invention, there is provided an SS (Subscriber Station) handover method upon receiving a handover request from the SS in a BWA (Broadband Wireless Access) communication system comprised of a serving BS (Base Station) and a plurality of neighbor BSs adjacent to the serving BS, comprising the steps of: a) receiving from the serving BS information relating to the plurality of neighbor BSs and handover condition information; b) measuring CINRs (Carrier to Interference and Noise Ratios) of pilot signals transferred from the neighbor BSs upon receipt of the neighbor BSs information; c) selecting a plurality of candidate BSs corresponding to the handover condition information from among the neighbor BSs, and transmitting a handover request signal to the serving BS along with pilot signal CINR information of the candidate BSs; d) upon receipt of the handover request signal, receiving from the serving BS information of a target BS from among the candidate BSs; and e) performing a handover function from the serving BS to the target BS.
In accordance with yet another aspect of the present invention, there is provided a handover method upon receiving a handover request from an SS (Subscriber Station) in a BWA (Broadband Wireless Access) communication system comprised of a serving BS (Base Station) and a plurality of neighbor BSs adjacent to the serving BS, comprising the steps of: a) controlling the serving BS to transmit to the SS information of the neighbor BSs and handover condition information; b) controlling the SS to measure CINRs (Carrier to Interference and Noise Ratios) of pilot signals transferred from the neighbor BSs according to the neighbor BSs information; c) controlling the SS to determine a plurality of candidate BSs corresponding to handover condition information from among the neighbor BSs, and transmitting to the serving BS a handover request signal along with pilot signal CINR information of the candidate BSs; d) if the serving BS receives the handover request signal from the SS, determining if the neighbor BSs contained in the handover request signal can support a handover function for the SS, and selecting a target BS acting as a handover target of the SS from among candidate BSs capable of supporting the handover function for the SS; e) controlling the serving BS to transmit a response signal associated with the handover request signal to the SS along with the target BS information, and informing the target BS of a handover ready state of the SS; and f) controlling the SS to perform a handover operation from the serving BS to the target BS according to the target BS information contained in the handover request response signal.
In accordance with yet another aspect of the present invention, there is provided a handover apparatus upon receiving a handover request from the SS (Subscriber Station) in a BWA (Broadband Wireless Access) communication system comprised of a serving BS (Base Station) and a plurality of neighbor BSs adjacent to the serving BS, comprising: the serving BS, which transmits information of the neighbor BSs and handover condition information to the SS, determines if the neighbor BSs contained in the handover request signal can support a handover function for the SS upon receiving the handover request signal from the SS, selects a target BS acting as a handover target of the SS from among candidate BSs capable of supporting the handover function for the SS, transmits a response signal associated with the handover request signal to the SS along with the target BS information, and informs the target BS of a handover ready state of the SS; and the SS, which measures CINRs (Carrier to Interference and Noise Ratios) of pilot signals transferred from the neighbor BSs according to the neighbor BSs information, selects a plurality of candidate BSs corresponding to handover condition information from among the neighbor BSs, transmits a handover request signal to the serving BS along with pilot signal CINR information of the candidate BSs, and performs a handover operation from the serving BS to the target BS according to the target BS information contained in the handover request response signal.
BRIEF DESCRIPTION OF THE DRAWINGS
The above and other objects, features and other advantages of the present invention will be more clearly understood from the following detailed description taken in conjunction with the accompanying drawings, in which: <ul id="ul0001" list-style="none" compact="compact"><li>Fig. 1 is a block diagram illustrating a conventional BWA (Broadband Wireless Access) communication system using an OFDM/OFDMA scheme;</li><li>Fig. 2 is a conceptual diagram illustrating a conventional downlink frame structure for use in a BWA communication system using an OFDM/OFDMA scheme;</li><li>Fig. 3 is a conceptual diagram illustrating a conventional uplink frame structure for use in a BWA communication system using an OFDM/OFDMA scheme;</li><li>Fig. 4 is a flow chart illustrating a conventional ranging process between an SS and a BS in a BWA communication system using an OFDM scheme;</li><li>Fig. 5 is a flow chart illustrating a conventional ranging process between an SS and a BS in a BWA communication system using an OFDMA scheme;</li><li>Fig. 6 is a block diagram illustrating a BWA communication system using an OFDM/OFDMA scheme to perform a variety of functions in accordance with a preferred embodiment of the present invention;</li><li>Fig. 7 is a flow chart illustrating a handover procedure upon receiving a handover request from an SS in a BWA communication system using an OFDM scheme in accordance with a preferred embodiment of the present invention;</li><li>Fig. 8 is a flow chart illustrating a handover procedure upon receiving a handover request from an SS in a BWA communication system using an OFDMA scheme in accordance with a preferred embodiment of the present invention;</li><li>Fig. 9 is a block diagram illustrating an internal configuration of the SS for performing inventive functions in accordance with a preferred embodiment of the present invention;</li><li>Fig. 10 is a flow chart illustrating operations of the SS in accordance with a preferred embodiment of the present invention; and</li><li>Fig. 11 is a flow chart illustrating operations of a serving BS in accordance with a preferred embodiment of the present invention.</li></ul>
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
Now, preferred embodiments of the present invention will be described in detail with reference to the annexed drawings. In the drawings, the same or similar elements are denoted by the same reference numerals even though they are depicted in different drawings. In the following description, a detailed description of known functions and configurations incorporated herein will be omitted when it may obscure the subject matter of the present invention.
Fig. 6 is a block diagram illustrating a BWA communication system using an OFDM/OFDMA scheme to perform a variety of functions in accordance with a preferred embodiment of the present invention.
Prior to describing the BWA communication system shown in Fig. 6, it is noted that the present invention adapts the IEEE 802.16e communication system using an OFDM/OFDMA scheme as a representative example. It is also noted that an IEEE 802.16e communication system acting as a communication system for considering the mobility of an SS in the IEEE 802.16a communication system has not been developed yet. Provided that the SS's mobility is considered in the IEEE 802.16a communication system, it is possible to consider the multi-cell structure and an SS's handover operation (i.e., a cell selection operation) between the multi-cells. Therefore, the present invention provides the IEEE 802.16e communication system as shown in Fig. 6.
Referring to Fig. 6, the IEEE 802.16e communication system includes a multi-cell structure, i.e., a plurality of cells 600 and 650. In more detail, the IEEE 802.16e communication system includes a first BS 610 for managing the cell 600, a second BS 640 for managing the cell 650, and a plurality of SSs 611, 613, 630, 651, and 653. Signal transmission/reception among the BSs 610 and 640 and the SSs 611, 613, 630, 651, and 653 is established using the OFDM/OFDMA scheme. Among the subscriber stations 611,613,630,651,and 653, the subscriber station 630 is located in a boundary region, or a handover region, between the cell 600 and the cell 650. Therefore, it is necessary to support a handover of the subscriber station 630 in order to support mobility of the subscriber station 630 .
In general, and according to an embodiment of the present invention an SS for use in the BWA communication system receives a plurality of signals from a plurality of BSs. The SS detects individual CINRs (Carrier to interference and Noise Ratios) of the received pilot signals. The SS selects a specific BS, which has transmitted a pilot channel having the highest CINR from among CINRs of the pilot signals, and determines the selected BS to be a serving BS (i.e., an active BS) to which the SS belongs. In more detail, the SS selects a BS having the best reception state from among a plurality of BSs transmitting the pilot signals, and recognizes the selected BS as its own serving BS. For the convenience of description, the term "Active BS" or "Serving BS" may be employed in the present invention for illustrative purposes.
The SS which has selected the active BS receives a downlink frame and a uplink frame from the active BS. The detailed configurations of the downlink frame and the uplink frame received from the active BS have been disclosed in the prior art, so that they will herein be omitted for the convenience of description. The present invention must add new IEs (Information Elements) to the DL_MAP message provided from the IEEE 802.16a / IEEE 802.16e communication system in such a way that it can support a handover operation upon receiving a request from the SS. A detailed configuration of the DL_MAP message for supporting the handover operation upon receipt of the SS's request is shown in the following Table 6: <tables id="tabl0006" num="0006"><table frame="all"><title>[Table 6]</title><tgroup cols="4" colsep="1" rowsep="1"><colspec colnum="1" colname="col1" colwidth="39.37mm" /><colspec colnum="2" colname="col2" colwidth="39.37mm" /><colspec colnum="3" colname="col3" colwidth="39.37mm" /><colspec colnum="4" colname="col4" colwidth="39.37mm" /><thead valign="top"><row rowsep="1"><entry namest="col1" nameend="col1" align="left">MAC management message</entry><entry namest="col2" nameend="col2" align="left">Parameter</entry><entry namest="col3" nameend="col3" align="left">Multi</entry><entry namest="col4" nameend="col4" align="left">Content</entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" morerows="9" align="left">DL_MAP</entry><entry namest="col2" nameend="col2" align="left">Neighbor list BS Num</entry><entry namest="col3" nameend="col3" align="left">Common</entry><entry namest="col4" nameend="col4" align="left">Number of Neighbor list BSs</entry></row><row><entry namest="col2" nameend="col2" align="left">Neighbor list Info</entry><entry namest="col3" nameend="col3" align="left">1 to Neighbor list BS Num</entry><entry namest="col4" nameend="col4" /></row><row><entry namest="col2" nameend="col2" align="left">Neighbor list BS ID</entry><entry namest="col3" nameend="col3" /><entry namest="col4" nameend="col4" align="left">IDs of Neighbor list BSs</entry></row><row><entry namest="col2" nameend="col2" align="left">Neighbor Frequency</entry><entry namest="col3" nameend="col3" /><entry namest="col4" nameend="col4" align="left">Frequencies of Neighbor BSs</entry></row><row><entry namest="col2" nameend="col2" align="left">Neighbor Frequency offset</entry><entry namest="col3" nameend="col3" /><entry namest="col4" nameend="col4" align="left">Frequency offsets of Neighbor BSs</entry></row><row><entry namest="col2" nameend="col2" align="left">Neighbor Frame offset</entry><entry namest="col3" nameend="col3" /><entry namest="col4" nameend="col4" align="left">Frequency offsets of Neighbor list BSs</entry></row><row><entry namest="col2" nameend="col2" align="left">Measurement Info</entry><entry namest="col3" nameend="col3" align="left">Common</entry><entry namest="col4" nameend="col4" /></row><row><entry namest="col2" nameend="col2" align="left">Pilot min CINR</entry><entry namest="col3" nameend="col3" /><entry namest="col4" nameend="col4" align="left">Minimum value containable in Neighbor list</entry></row><row><entry namest="col2" nameend="col2" align="left">MAX_T</entry><entry namest="col3" nameend="col3" /><entry namest="col4" nameend="col4" align="left">Maximum time during which BSs contained in Neighbor list remain below pilot min CINR</entry></row><row rowsep="1"><entry namest="col2" nameend="col2" align="left">MIN_T</entry><entry namest="col3" nameend="col3" /><entry namest="col4" nameend="col4" align="left">Minimum time during which BS having the highest pilot CINR among BSs in the Neighbor list remains at a value higher than pilot CINR of active BS</entry></row></tbody></tgroup></table></tables>
With reference to the above Table 6, the number of neighbor BSs (denoted by "Neighbor list BS Num") indicates the number of neighbor BSs contained in the neighbor list. The neighbor list field indicates the list of neighbor BSs of the active BS. The Neighbor list Info field indicates neighbor BSs contained in the neighbor list, i.e., a plurality of neighbor BSs from a first neighbor BS to the last neighbor BS. The neighbor list information denoted by "Neighbor list Info" includes a Neighbor list BS ID field, a Neighbor Frequency field, a Neighbor Frequency Offset field, and a Neighbor Frame Offset field. The Neighbor list BS ID field indicates IDs of individual BSs contained in the neighbor list. The Neighbor Frequency, field indicates a center frequency of a corresponding neighbor BS. The Neighbor Frequency Offset field indicates a frequency offset of a corresponding neighbor BS. The neighbor frame offset field indicates a frame offset of a corresponding neighbor BS. The Measurement Info field includes a minimum pilot signal CINR (Pilot min CINR) field, a maximum time (MAX_T) field and a minimum time (MIN_T) field. The Pilot min CINR field is adapted as a reference for selecting neighbor BSs containable in the Neighbor list Info field from among a plurality of BSs of the IEEE 802.16e communication system. In more detail, only BSs transmitting pilot signals each higher than the Pilot min CINR can be adapted as neighbor BSs contained in the neighbor list. The MAX_T field indicates a maximum time for enabling each neighbor BS to have a pilot signal CINR of less than the Pilot min CINR. In more detail, the neighbor BSs must transmit pilot signals higher than the Pilot min CINR. If the pilot signal less than the Pilot min CINR is transmitted during the MAX_T time, a corresponding neighbor BS is removed from the neighbor list. In this way, if the neighbor BS capable of transmitting the pilot signal having the Pilot min CINR during the MAX_T time has been removed from the neighbor list, there is no need for the SS to measure an unnecessary pilot CINR. The MIN_T time indicates a minimum time during which the highest pilot CINR from among a plurality of pilot CINRs of the neighbor BSs must be higher than a pilot CINR of the active BS. In more detail, in order to control the SS to be handed over from the active BS to a specific neighbor BS (i.e., a target BS), a CINR of a pilot signal transmitted from the target BS must be higher than that of the other pilot signal transmitted from the active BS during more than the MIN_T time.The MIN_T is set in order to prevent a ping-pong phenomenon in which the subscriber station sends a handover request to the base station each time a CINR of a received pilot channel is higher than a CINR of the active base station. In this case, it should be noted that the MAX_T time and the MIN_T time may be differently determined according to state and channel condition information of individual BSs in the IEEE 802.16e communication system.
A ranging request step during which the SS having received the DL_MAP message and the UL_MAP message requests the ranging process from the active BS and a ranging response step during which a response signal to the ranging request is transmitted to the SS which has transmitted the ranging request are equal to those of the prior art, such that their detailed description will herein omitted for the convenience of description. The SS having successfully established the ranging process wirelessly communicates with the active BS. The handover process in response to the SS request signal during the wireless access communication time between the SS and the active BS will hereinafter be described with reference to Fig. 7.
Fig. 7 is a flow chart illustrating the handover procedure upon receiving a handover request from the SS in the IEEE 802.16e communication system using the OFDM scheme in accordance with a preferred embodiment of the present invention.
Referring to Fig. 7, upon establishing system synchronization between an SS 701 and a serving BS (also called an active BS) 702, the serving BS 702 transmits the DL_MAP message and the UL_MAP message to the SS 701 at steps 711 and 712, respectively. The DL_MAP message format and the UL_MAP message format have been disclosed in Table 6 and Table 2, respectively, such that their detailed description will herein be omitted. The SS 701 receives the DL MAP message to detect information of neighbor BSs of the SS 701, such that the SS 701 measures CINRs of the pilot signals received from the neighbor BSs at step 731.
The SS 701 temporarily stops receiving transmission data of the serving BS 702. In more detail, the SS 701 measures CINRs of the pilot signals received from the neighbor BSs during a reception interrupt time of the transmission data of the serving BS 702. In this case, the SS 701 does not measure individual CINRs of the pilot signals received from all the neighbor BSs contained in the neighbor list contained in the DL_MAP message, and is adapted to measure only CINRs of pilot channel signals received from the neighbor BSs excluded by the MIN_T time. The method for measuring the CINRs of the pilot signals received from the neighbor BSs will be described in detail.
The SS 701 establishes synchronization with individual neighbor BSs using a variety of information of neighbor BSs contained in the neighbor list of the DL_MAP message. Upon establishing synchronization with the neighbor BSs, the SS 701 measures CINRs of pilot signals received from the neighbor BSs.
The SS 701 having measured the CINRs of the pilot signals received from the neighbor BSs determines whether it is handed over to another BS instead of the serving BS 702. The handover determination step of the SS 701 will be described in detail. At least one of the CINRs of pilot signals received from the neighbor BSs must satisfy the MAX_T condition. Provided that the CINRs of the pilot signals received from the neighbor BSs contained in the neighbor list are less than the minimum pilot CINR denoted by "Pilot min CINR" during more than the MAX_T time, corresponding pilot signals are removed from the neighbor list, such that the MAX_T condition must be satisfied. In this case, the neighbor BSs which have satisfied the MAX_T condition are each called a candidate BS (i.e., a target BS). If the MAX_T condition has been satisfied, the SS 701 determines whether CINRs of pilot signals transmitted from the neighbor BSs are greater than a CINR of a pilot signal received from the serving BS 702. If it is determined that the pilot signal CINR received from the serving BS 702 is greater than individual CINRs of the pilot signals received from the neighbor BSs, the SS 702 does not request the handover operation from the serving BS 702. Otherwise, if it is determined that the pilot signal CINR received from the serving BS 702 is less than CINRs of the pilot signals received from the neighbor BSs, the SS 701 requests the handover operation from the serving BS 702. Needless to say, the SS 701 requests the handover operation from the serving BS 702 on the condition that a neighbor BS satisfying the MIN_T condition is found. The reason why the SS 701 requests the handover operation from the serving BS 702 on the condition that the MIN_T time condition has been satisfied is to prevent the aforementioned pingpong phenomenon from being generated.
If the handover operation has been determined, the SS 701 transmits a handover request (HO_REQ) message to the serving BS 702 at step 713. The HO_REQ message format is shown in Table 7: <tables id="tabl0007" num="0007"><table frame="all"><title>[Table 7] '</title><tgroup cols="4" colsep="1" rowsep="1"><colspec colnum="1" colname="col1" colwidth="39.37mm" /><colspec colnum="2" colname="col2" colwidth="39.37mm" /><colspec colnum="3" colname="col3" colwidth="39.37mm" /><colspec colnum="4" colname="col4" colwidth="39.37mm" /><thead valign="top"><row rowsep="1"><entry namest="col1" nameend="col1" align="center">MAC management message</entry><entry namest="col2" nameend="col2" align="center">Parameter</entry><entry namest="col3" nameend="col3" align="center">Multi</entry><entry namest="col4" nameend="col4" align="center">Content</entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" morerows="4" align="left">HO_REQ</entry><entry namest="col2" nameend="col2" align="left">Uplink Channel ID</entry><entry namest="col3" nameend="col3" align="left">common</entry><entry namest="col4" nameend="col4" align="left">Uplink channel ID contained in message</entry></row><row><entry namest="col2" nameend="col2" align="left">Neighbor list BS carrier frequency</entry><entry namest="col3" nameend="col3" align="left">1 to Neighbor list BS Num</entry><entry namest="col4" nameend="col4" align="left">carrier frequencies of neighbor BSs</entry></row><row><entry namest="col2" nameend="col2" align="left">CINR of neighbor list BS</entry><entry namest="col3" nameend="col3" /><entry namest="col4" nameend="col4" align="left">Pilot CINRs of Neighbor list BSs</entry></row><row><entry namest="col2" nameend="col2" align="left">QoS</entry><entry namest="col3" nameend="col3" align="left">common</entry><entry namest="col4" nameend="col4" align="left">Service category information of MS</entry></row><row rowsep="1"><entry namest="col2" nameend="col2" align="left">BW request</entry><entry namest="col3" nameend="col3" align="left">common</entry><entry namest="col4" nameend="col4" align="left">BW Information of MS</entry></row></tbody></tgroup></table></tables>
Prior to describing Table 7, it should be noted that neighbor BSs act as target BSs after receiving a handover request from the SS 701, such that they are the same as the target BSs after the SS has generated the handover request. Referring to Table 7, the Neighbor list BS carrier frequency field indicates carrier frequencies of neighbor BSs (i.e., target BSs) which have received the handover request from the SS 701. The CINR of neighbor list BS field indicates CINRs of pilot signals transmitted from the neighbor BSs. The QoS field indicates a quality of service (QoS) desired by the SS 701. The BW request field indicates a bandwidth requested in response to the QoS desired by the SS 701. In this case, the QoS is composed of a variety of service grades, i.e., an Unsolicited Grant Service (UGS), a Real-Time Polling Service (rtPS), a Non-Real-Time Polling Service (nrtPS), and a Best Effort Service (BE). The serving BS 702 having received the handover request message from the SS 701 arranges neighbor BSs contained in the handover request message. There are a variety of possible methods for arranging the neighbor BSs. As stated above, the CINR of the neighbor BS which stops measuring the CINR of the pilot signal using the SS 701 is set to "0". The serving BS 702 may configure information of the arranged neighbor BSs in the form of a list, and may store the list-formatted information.
The serving BS 702 arranging the neighbor BSs sequentially transmits an HO_CONNECTION_REQ (Handover Connection Request) message to corresponding neighbor BSs (i.e., target BSs) according to the arranged order of the neighbor BSs at steps 714 and 716. The HO_CONNECTION_REQ message format is shown in the following Table 8: <tables id="tabl0008" num="0008"><table frame="all"><title>[Table 8]</title><tgroup cols="4" colsep="1" rowsep="1"><colspec colnum="1" colname="col1" colwidth="39.37mm" /><colspec colnum="2" colname="col2" colwidth="39.37mm" /><colspec colnum="3" colname="col3" colwidth="39.37mm" /><colspec colnum="4" colname="col4" colwidth="39.37mm" /><thead valign="top"><row rowsep="1"><entry namest="col1" nameend="col1" align="center">MAC management message</entry><entry namest="col2" nameend="col2" align="center">Parameter</entry><entry namest="col3" nameend="col3" align="center">Multi</entry><entry namest="col4" nameend="col4" align="center">Content</entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" morerows="3" align="left">HO_CONNE CTION_REQ</entry><entry namest="col2" nameend="col2" align="left">Target BS ID</entry><entry namest="col3" nameend="col3" align="left">common</entry><entry namest="col4" nameend="col4" align="left">Target BS ID</entry></row><row><entry namest="col2" nameend="col2" align="left">CID</entry><entry namest="col3" nameend="col3" align="left">common</entry><entry namest="col4" nameend="col4" align="left">Terminal CID in Serving BS</entry></row><row><entry namest="col2" nameend="col2" align="left">QoS,</entry><entry namest="col3" nameend="col3" align="left">common</entry><entry namest="col4" nameend="col4" align="left">Service category information of MS</entry></row><row rowsep="1"><entry namest="col2" nameend="col2" align="left">BW request</entry><entry namest="col3" nameend="col3" align="left">common</entry><entry namest="col4" nameend="col4" align="left">BW to be assigned to MS</entry></row></tbody></tgroup></table></tables>
With reference to Table 8, the Target BS ID indicates ID information of the target BS. The CID (Connection ID) is a connection CID assigned from the serving BS 702 to the SS 701. The QoS field indicates a quality of service (QoS) desired by the SS 701. The BW request field indicates a bandwidth requested in response to the QoS desired by the SS 701. The reason why the serving BS 702 transmits the HO_CONNECTION_REQ message to the target BSs (i.e., a target BS1 703 and a target BS2 704) is to determine whether or not a QoS and a bandwidth associated with the service desired by the SS 701 can be satisfied.
If the target BSs 703 and 704 receive the HO_CONNECTION_REQ message, they transmit the HO_CONNECTION_RSP (Handover Connection Response) message to the serving BS 702 at steps 715 and 717. A representative example of the HO _CONNECTION_RSP message format is shown in the following Table 9: <tables id="tabl0009" num="0009"><table frame="all"><title>[Table 9]</title><tgroup cols="4" colsep="1" rowsep="1"><colspec colnum="1" colname="col1" colwidth="39.37mm" /><colspec colnum="2" colname="col2" colwidth="39.37mm" /><colspec colnum="3" colname="col3" colwidth="39.37mm" /><colspec colnum="4" colname="col4" colwidth="39.37mm" /><thead valign="top"><row rowsep="1"><entry namest="col1" nameend="col1" align="center">MAC management message</entry><entry namest="col2" nameend="col2" align="center">Parameter</entry><entry namest="col3" nameend="col3" align="center">Multi</entry><entry namest="col4" nameend="col4" align="center">Content</entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" morerows="2" align="left">HO_CONNE CTION_RSP</entry><entry namest="col2" nameend="col2" align="left">Target BS ID</entry><entry namest="col3" nameend="col3" align="left">common</entry><entry namest="col4" nameend="col4" align="left">Target BS ID</entry></row><row><entry namest="col2" nameend="col2" align="left">CID</entry><entry namest="col3" nameend="col3" align="left">common</entry><entry namest="col4" nameend="col4" align="left">Terminal CID in Serving BS</entry></row><row rowsep="1"><entry namest="col2" nameend="col2" align="left">ACK/NACK</entry><entry namest="col3" nameend="col3" align="left">common</entry><entry namest="col4" nameend="col4" align="left">HO approval or disapproval</entry></row></tbody></tgroup></table></tables>
With reference to Table 9, the Target BS ID field indicates ID information of the target BS transmitting the HO _CONNECTION_RSP, the CID is a connection ID used for the serving BS 702 of the SS 701. The ACK/NACK field indicates HO (handover) approval or disapproval information of the SS 701. In more detail, in the case where the ACK message is contained in the HO_CONNECTION_RSP message, a corresponding target BS is able to provide the SS 701 with a handover function. In the case where the NACK message is contained in the HO_CONNECTION_RSP message, a corresponding target BS is unable to provide the SS 701 with the handover function. As shown in Fig. 7, the target BS1 703 transmits the HO_CONNECTION_RES message containing the NACK field indicative of an handover support disable state for the SS 701. It is assumed that the target BS2 704 transmits the HO _CONNECTION_RSP message containing the ACK field indicative of a handover support enable state for the SS 701.
The HO_CONNECTION_REQ message and the HO_CONNECTION_RSP message are sequentially transmitted as shown in Fig. 7, but they may also be transmitted simultaneously if needed.
Upon receiving the HO_CONNECTION_RSP message from the target BSs, the serving BS 702 detects the ACK/NACK field contained in the received HO_CONNECTION_RSP message, such that it sets the target BS (i.e., the target BS2 704) which has transmitted the HO_CONNECTION_RSP message containing the ACK field to a last target BS to which the SS 701 is handed over. Thereafter, the serving BS 702 transmits the HO_RSP (Handover Response) message containing the last target BS information to the SS 701 at step 718. The HO_RSP message includes information of the last target BS to which the SS 701 is handed over. A representative example of the HO_RSP message is shown in Table 10: <tables id="tabl0010" num="0010"><table frame="all"><title>[Table 10]</title><tgroup cols="4" colsep="1" rowsep="1"><colspec colnum="1" colname="col1" colwidth="39.37mm" /><colspec colnum="2" colname="col2" colwidth="39.37mm" /><colspec colnum="3" colname="col3" colwidth="39.37mm" /><colspec colnum="4" colname="col4" colwidth="39.37mm" /><thead valign="top"><row rowsep="1"><entry namest="col1" nameend="col1" align="center">MAC management message</entry><entry namest="col2" nameend="col2" align="center">Parameter</entry><entry namest="col3" nameend="col3" align="center">Multi</entry><entry namest="col4" nameend="col4" align="center">Content</entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" morerows="1" align="left">HO RSP</entry><entry namest="col2" nameend="col2" align="left">Target BS ID</entry><entry namest="col3" nameend="col3" align="left">common</entry><entry namest="col4" nameend="col4" align="left">Target BS ID</entry></row><row rowsep="1"><entry namest="col2" nameend="col2" align="left">Target BS carrier frequency</entry><entry namest="col3" nameend="col3" align="left">common</entry><entry namest="col4" nameend="col4" align="left">Carrier frequency of Target BS</entry></row></tbody></tgroup></table></tables>
With reference to Table 10, the Target BS ID field indicates ID information of the last target BS to which the SS 701 is handed over. The Target BS carrier frequency field indicates a carrier frequency of the last target BS. The serving BS 702 having transmitted the HO_RSP message transmits an HO_CONNECTION_CFM (Handover Connection Confirmation) message to the last target BS (i.e., the target BS2 704) at step 719. In this case, the HO_CONNECTION_CFM message indicating that the SS 701 will be handed over to the last target BS 704 is transmitted. A representative example of the HO_CONNECTION_CFM message is shown in Table 11: <tables id="tabl0011" num="0011"><table frame="all"><title>[Table 11]</title><tgroup cols="4" colsep="1" rowsep="1"><colspec colnum="1" colname="col1" colwidth="39.37mm" /><colspec colnum="2" colname="col2" colwidth="39.37mm" /><colspec colnum="3" colname="col3" colwidth="39.37mm" /><colspec colnum="4" colname="col4" colwidth="39.37mm" /><thead valign="top"><row rowsep="1"><entry namest="col1" nameend="col1" align="center">MAC management message</entry><entry namest="col2" nameend="col2" align="center">Parameter</entry><entry namest="col3" nameend="col3" align="center">Multi</entry><entry namest="col4" nameend="col4" align="center">Content</entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" align="left">HO CONNEC</entry><entry namest="col2" nameend="col2" align="left">Target BS ID</entry><entry namest="col3" nameend="col3" align="left">common</entry><entry namest="col4" nameend="col4" align="left">Target BS ID</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" align="left">TION CFM</entry><entry namest="col2" nameend="col2" align="left">CID I</entry><entry namest="col3" nameend="col3" align="left">common</entry><entry namest="col4" nameend="col4" align="left">Terminal CID in Serving BS</entry></row></tbody></tgroup></table></tables>
With reference to Table. 11, the Target BS ID field indicates ID information of a neighbor BS (i.e., the last target BS) receiving the HO_CONNECTION_CFM message. The CID indicates a connection ID assigned from the serving BS 702 to the SS 701. The serving BS 702 having transmitted the HO_CONNECTIN_CFM message to the target BS2 704 releases a link connected to the SS 701 at step 734.
The target BS2 704 transmits the DL_MAP message and the UL_MAP message to the SS 701 at steps 720 and 721, respectively. The DL_MAP message and the UL_MAP message include updated information of the SS 701. The SS 701 having received the DL_MAP message and the UL_MAP message transmits an RNG_REQ (Ranging Request) message to the target BS2 704 at step 722. The target BS2 704 having received the RNG_REQ message transmits the RNG_RSP message acting as a response message associated with the RNG_REQ message to the SS 701 at step 723.A detailed process performed in the steps 720 to 723 is identical to the process performed in the steps 411 to 417 illustrated in Fig. 4. Therefore, a detailed description of these steps will not be given again herein.
Fig. 7 has disclosed the handover procedure upon receiving a handover request from the SS in the IEEE 802.16e communication system using the OFDM scheme. Fig. 8 is a flow chart illustrating a handover procedure upon receiving a handover request from the SS in the IEEE 802.16e communication system using the OFDMA scheme in accordance with a preferred embodiment of the present invention.
Prior to describing Fig. 8 in detail, it should be noted that steps 811 to 821 and steps 831 to 834 shown in Fig. 8 are equal to steps 711 to 721 and steps 731 to 734 shown in Fig. 7, respectively, such that their detailed description will herein be omitted. Because the OFDMA scheme is applied to Fig. 8, the SS 801 transmits a ranging code instead of the RNG_REQ message to the last target BS (i.e., the target BS2 804) at step 822. The target BS2 804 having received the ranging code transmits the RNG_RSP message acting as a response associated with the ranging code to the SS 801 at step 823. In more detail, the handover procedure of Fig. 7 is substantially equal to that of Fig. 8, however, the IEEE 802.16e communication system transmits the RNG REQ message according to the OFDM scheme in Fig. 7 scheme whereas it transmits the ranging code according to the OFDMA scheme in Fig. 8. Fig. 8 has disclosed the handover procedure upon receipt of a handover request from the SS in the IEEE 802.16e communication system using the OFDMA scheme. The SS internal configuration for performing inventive functions will hereinafter be described with reference to Fig. 9.
Fig. 9 is a block diagram illustrating the SS internal configuration for performing inventive functions in accordance with a preferred embodiment of the present invention. Referring to Fig. 9, the SS internal configuration includes a matched filter 900, a reception power measurement unit 910, a reception power comparator 920, a controller 930, and a transmitter 940. The matched filter 900 determines whether a PN (Pseudo Noise) code for synchronization detection is synchronized or not, and outputs a predetermined energy value according to the determined result. In this case, the correlator may also be adapted as the matched filter 900. The matched filter 900 compares the received synchronization detection PN code with a unique PN code of the SS, and outputs the energy value in association with the same PN code. In more detail, the matched filter 900 sequentially enters a reception signal of the SS in a predetermined window, and performs a predetermined bit operation in parallel to the unique PN code value, resulting in the sum of the bit-operation values. Therefore, if the reception signal of the SS is equal to the unique PN code value stored in the SS, this condition is called an auto-correlation state, such that a maximum energy value is generated. If the SS reception signal is different from the unique PN code value, this condition is called an inconsistent synchronization state, such that a relatively low energy value is generated. 1 Typically, the output energy values are compared with a predetermined threshold value so that it is determined whether the auto-correlation state is established. In conclusion, the output value of the matched filter 900 is compared with the predetermined threshold value so that the presence or absence of the auto-correlation state can be determined.
If the reception power measurement unit 910 is synchronized with a pilot signal received from each neighbor BS via the matched filter, the reception power measurement Unit 910 measures the reception power of the received pilot signal. The reception power measurement unit 910 measures the CINR of the received pilot signal, and transmits the measured CINR of the pilot signal to the reception power comparator 920. Upon receiving CINRs of the pilot signals from the reception power measurement unit 910, the reception power comparator 920 compares the received pilot signal CINRs of the neighbor BSs with a predetermined threshold value (i.e., a Pilot min CINR). If at least one pilot signal CINR from among pilot signal CINRs transmitted from the neighbor BSs is greater than the threshold value, the reception power comparator 920 goes to the next step. In more detail, it is determined whether at least one pilot signal CINR from among the neighbor BSs' pilot signal CINRs is greater than a pilot signal CINR of the serving BS. If it is determined that a neighbor BS having a pilot signal CINR greater than that of the serving BS is found, information of a neighbor BS having the pilot signal CINR greater than that of the serving BS is transmitted to the controller 930. The controller 930 determines whether the SS transmits its own handover request to the serving BS according to information received from the reception power comparator 920.
In more detail, if the CINRs of the pilot signals transmitted from the neighbor BSs are greater than that of the other pilot signal transmitted from the serving BS, the controller 930 generates a handover request signal of the SS. In this case, although there is no description in the drawings, it should be noted that the MAX_T and MIN_T conditions must be satisfied in the handover request process. The controller 930 generates a handover request (HO_REQ) message by controlling the transmitter 940, and transmits the generated handover request message to the serving BS. The transmitter 940 generates the HO_REQ message upon receiving a control command from the controller 930, and transmits the HO_REQ message to the serving BS.
Fig. 9 has disclosed the SS internal configuration according to the present invention. Operations of the SS will hereinafter be described with reference to Fig. 10. Fig. 10 is a flow chart illustrating operations of the SS in accordance with a preferred embodiment of the present invention. Referring to Fig. 10, the SS reads the DL_MAP message received from the serving BS at step 1000, reads the UL_MAP message received from the serving BS at step 1002, and reads the neighbor BS list information contained in the DL_MAP message at step 1004. If the SS reads the neighbor BSs information at step 1004, it sets an ID "i" indicative of the number of the neighbor BSs to "0" (i.e., i=0) at step 1004.
The SS adds a number of 1 to a variable "i" (i.e., i = i+1), measures a CINR of a pilot signal transmitted from the i-th neighbor BS at step 1006, and goes to step 1008. In this case, it is assumed that the neighbor BSs' number transmitted from the serving BS is in the range from "BS_1" to "MAX_BS_NUM". Therefore, the SS measures a pilot signal CINR for the neighbor BSs' number "BS_1" at step 1006, and determines whether the number of the neighbor BS having measured the pilot signal CINR is equal to or greater than "MAX_BS_NUM" at step 1008. If it is determined the number of the measured neighbor BS is equal to or greater than "MAX_BS_NUM" at step 1008, the SS goes to step 1010. Otherwise, if it is determined that the number of the measured neighbor BS is less than "MAX_BS_NUM" at step 1008, the SS returns to step 1006.
If it is determined that the value of MAX_Neighbor BS CINR is equal to or less than the pilot signal CINR of the serving BS, the SS returns to step 1000. Otherwise, if it is determined that the value of MAX_Neighbor BS CINR is greater than the pilot signal CINR of the serving BS, the SS determines its own handover request, and goes to step 1012.
The SS transmits the HO_REQ message to the serving BS at step 1012. The detailed configuration of the HO_REQ message has been disclosed in the aforementioned Table 7. The SS receives the HO_RSP message associated with the HO_REQ message from the serving BS at step 1014, and goes to step 1016. The detailed configuration of the HO_RSP message has been disclosed in the aforementioned Table 10. The SS reads ID and carrier frequency information of the last target BS from among the HO_RSP message at step 1016, and goes to step 1018. In this case, the last target BS acts as a specific BS to which the SS is handed over.
The SS converts an SS frequency into a target BS frequency, and goes to step 1020, such that data transmission/reception between the SS and the serving BS is interrupted and the SS can communicate with the last target BS. The SS reads the DL_MAP message received from the last target BS at step 1020, and goes to step 1022. The SS reads the UL_MAP message received from the last target BS, and goes to step 1024. The SS communicates with the last target BS at step 1024, and terminates its handover operation.
Fig. 10 has disclosed operations of the SS according to the present invention. Operations of the serving BS will hereinafter be described with reference to Fig. 11. Fig. 11 is a flow chart illustrating operations of a serving BS in accordance with a preferred embodiment of the present invention. The serving BS transmits the DL_MAP message to the SS at step 1100, and transmits the UL_MAP message to the SS at step 1102.
The serving BS receives the HO_REQ message from the SS at step 1104, and goes to step 1106. The detailed configuration of the HO_REQ message has been disclosed in the aforementioned Table 7. The serving BS arranges CINRs of the pilot signals of the neighbor BSs in other of descending magnitude, and goes to step 1108. In this case, the CINRs of the pilot signals of the neighbor BSs are contained in the HO_REQ message. As stated above, the neighbor BSs for commanding the SS to measure the pilot signal CINR act as candidate BSs which satisfy the MAX_T and MIN_T conditions, such that each candidate BS has a signal greater than a Pilot min CINR (i.e., a minimum pilot signal CINR). As previously stated in Fig. 10, it is assumed that the number of neighbor BSs of the SS is in the range from BS_1 to MAX_BS_NUM. In addition, the ID "i" indicative of the number of the neighbor BSs is set to "0" (i.e., i=0) at step 1106. The ID indicative of the number "i" of the neighbor BSs is determined in the order of the pilot CINRs.
The serving BS transmits the HO_CONNECTION_REQ message to the neighbor BS having the greatest pilot CINR from among the arranged neighbor BSs at step 1108. The detailed configuration of the HO_CONNECTION_REQ message has been shown in the aforementioned Table 8.
The serving BS receives the HO_CONNECTION_RSP message indicative of a response to the HO CONNECTION REQ message from the neighbor BS which have transmitted the HO CONNECTION REQ message at step 1110, and goes to step 1112. The detailed configuration of the HO_CONNECTION_RSP message has been disclosed in the aforementioned Table 9. The serving BS determines whether there is a neighbor BS capable of supporting a handover function of the SS in a plurality of neighbor BSs transmitting the SS handover request signals. In more detail, the serving BS determines whether the ACK message is contained in the HO_CONNECTION_RSP message. If it is determined that a specific neighbor BS from among the neighbor BSs can support the handover service for, the SS, the serving BS goes to step 1116. Otherwise, if it is determined that none of the neighbor BSs is able to support the handover service for the SS, the serving BS goes to step 1114. The serving BS selects a neighbor BS with the second greatest pilot CINR from among the neighbor BSs and increases the variable "i" by one (i.e., i = i + 1) at step 1114, and returns to step 1108.
The serving BS transmits the HO_RSP message to the SS at step 1116, and goes to step 1118. The detailed configuration of the HO_RSP message has been disclosed in the aforementioned Table 10. The serving BS transmits the HO_CONNECTION_CFM message to a neighbor BS (i.e., the last target BS) capable of supporting the handover function at step 1118, and returns to step 1120. The detailed configuration of the HO_CONNECTION_CFM message has been disclosed in the aforementioned Table 11. Needless to say, the serving BS may first transmit the HO_CONNECTION_CFM message to the last target BS, or may transmit the HO_RSP message to the SS. The serving BS releases the link connected to the SS at step 1120, and terminates its handover operation.
As apparent from the above description, the present invention enables the SS based on a multi-cell structure to perform the handover operation, resulting in a guarantee of the SS's mobility. In more detail, the conventional SS performs a communication function in a single cell, such that it must cancel the link connected to a BS currently communicating with the SS when the SS moves to the other cell. Furthermore, the conventional SS must newly set up a communication mode with a new BS, such that it must newly perform the initial ranging process. However, in order to solve the aforementioned problems of the conventional SS, the present invention performs the handover process without performing the initial ranging process with the new BS, resulting in reduction of a data communication interruption time.
Although the preferred embodiments of the present invention have been disclosed for illustrative purposes, those skilled in the art will appreciate that various modifications, additions and substitutions are possible, without departing from the scope and spirit of the invention as disclosed in the accompanying claims.
Contents4
12 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| USRE46643E | Cited by | United States of America | Applicant |
| US12127264B2 | Cited by | United States of America | Applicant |
| US12289158B2 | Cited by | United States of America | Applicant |
| US11672018B2 | Cited by | United States of America | Applicant |
| EP2582177B1 | Cited by | European Patent Office (EPO) | Examiner |
| US9532336B2 | Cited by | United States of America | Applicant |
| WO2007078042A3 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| WO2009142939A1 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| USRE48478E | Cited by | United States of America | Applicant |
| CN100399781C | Cited by | China | Search report |
| EP2255462A4 | Cited by | European Patent Office (EPO) | Search report |
| USRE46679E | Cited by | United States of America | Applicant |
| WO2009142939A1 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| USRE46714E | Cited by | United States of America | Applicant |
| US9705624B2 | Cited by | United States of America | Applicant |
| US8509791B2 | Cited by | United States of America | Applicant |
| WO2007078042A2 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| EP2255462A1 | Cited by | European Patent Office (EPO) | Search report |
| US9806838B2 | Cited by | United States of America | Applicant |
| US10159059B2 | Cited by | United States of America | Applicant |
| USRE48326E | Cited by | United States of America | Applicant |
| US11129067B2 | Cited by | United States of America | Applicant |
| US10517120B2 | Cited by | United States of America | Applicant |
| US8359035B2 | Cited by | United States of America | Applicant |
| US11336385B2 | Cited by | United States of America | Applicant |
| USRE46602E | Cited by | United States of America | Applicant |
| US10187170B2 | Cited by | United States of America | Applicant |
| US9775177B2 | Cited by | United States of America | Applicant |
| US8301107B2 | Cited by | United States of America | Applicant |
| US9560650B2 | Cited by | United States of America | Applicant |
| US10659183B2 | Cited by | United States of America | Applicant |
| WO2007128243A1 | Cited by | World Intellectual Property Organization (WIPO) | Search report |
| US8085703B2 | Cited by | United States of America | Applicant |
| US10939473B2 | Cited by | United States of America | Applicant |
| EP2136589A2 | Cited by | European Patent Office (EPO) | Search report |
| EP2136589A3 | Cited by | European Patent Office (EPO) | Search report |
| WO0027051A2 | Cites | World Intellectual Property Organization (WIPO) | Examiner |
| US5267261A | Cites | United States of America | Examiner |
| WO9943178A1 | Cites | World Intellectual Property Organization (WIPO) | Search report |
20 members in 9 offices
Priority claims5
| Document | Office | Kind | Date |
|---|---|---|---|
| 20030014641 | Republic of Korea | A | |
| 20030014641 | Republic of Korea | A | |
| 2003014641 | Republic of Korea | – | |
| 2003014641 | – | – | – |
| KR20030014641 | – | – | – |
Members20
| Document | Office | Kind | |
|---|---|---|---|
| AU2004217201A1 | Australia | A1 | |
| CA2517827A1 | Canada | A1 | |
| KR20040079659A | Republic of Korea | A | |
| WO2004079948A1 | World Intellectual Property Organization (WIPO) | A1 | |
| US2004185853A1 | United States of America | A1 | |
| EP1469697A2This record | European Patent Office (EPO) | A2 | |
| EP1469697A3 | European Patent Office (EPO) | A3 | |
| RU2005128046A | Russian Federation | A | |
| CN1754329A | China | A | |
| JP2006517753A | Japan | A | |
| KR100665425B1 | Republic of Korea | B1 | |
| RU2305900C2 | Russian Federation | C2 | |
| AU2004217201B2 | Australia | B2 | |
| US7363038B2 | United States of America | B2 | |
| US2008159231A1 | United States of America | A1 | |
| JP4584150B2 | Japan | B2 | |
| CA2517827C | Canada | C | |
| CN1754329B | China | B | |
| EP1469697B1 | European Patent Office (EPO) | B1 | |
| US10271248B2 | United States of America | B2 |
39 legal events, as 4 offices reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | Office | |
|---|---|---|---|
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Patent expired after termination of 20 yearsExpiredPE20 | PE20 | GB | |
| Expiry of rightR071 | R071 | DE | |
| Annual fee paid to national office [announced via postgrant information from national office to epo]GrantedPGFP | PGFP | EP | |
| Annual fee paid to national office [announced via postgrant information from national office to epo]GrantedPGFP | PGFP | EP | |
| Annual fee paid to national office [announced via postgrant information from national office to epo]GrantedPGFP | PGFP | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Notification of lapseLapsedST | ST | FR | |
| No opposition filedOpposition26N | 26N | EP | |
| No opposition filed within time limitOppositionORIGINAL CODE: 0009261PLBE | PLBE | EP | |
| Information on the status of an ep patent application or granted ep patentGrantedSTATUS: NO OPPOSITION FILED WITHIN TIME LIMITSTAA | STAA | EP | |
| No opposition filed against granted patent, or epo opposition proceedings concluded without decisionGrantedR097 | R097 | DE | |
| Dpma publication of mentioned ep patent grantGrantedR096 | R096 | DE | |
| Designated contracting statesAK | AK | EP | |
| European patent grantedGrantedFG4D | FG4D | GB | |
| (expected) grantORIGINAL CODE: 0009210GRAA | GRAA | EP | |
| Grant fee paidORIGINAL CODE: EPIDOSNIGR3GRAS | GRAS | EP | |
| Intention to grant announcedINTG | INTG | EP | |
| Information on inventor provided before grant (corrected)RIN1 | RIN1 | EP | |
| Information on inventor provided before grant (corrected)RIN1 | RIN1 | EP | |
| Information on inventor provided before grant (corrected)RIN1 | RIN1 | EP | |
| Information provided on ipc code assigned before grantRIC1 | RIC1 | EP | |
| Despatch of communication of intention to grant a patentORIGINAL CODE: EPIDOSNIGR1GRAP | GRAP | EP | |
| Amendment of ipc main classPREVIOUS MAIN CLASS: H04Q0007380000R079 | R079 | DE | |
| Appeal procedure closedAppealORIGINAL CODE: EPIDOSNNOA9EAPBT | APBT | EP | |
| Party data changed (applicant data changed or rights of an application transferred)RAP1 | RAP1 | EP | |
| Appeal reference modifiedAppealORIGINAL CODE: EPIDOSCREFNEAPAF | APAF | EP | |
| Date of receipt of statement of grounds of appeal recordedAppealORIGINAL CODE: EPIDOSNNOA3EAPBR | APBR | EP | |
| Appeal reference recordedAppealORIGINAL CODE: EPIDOSNREFNEAPBK | APBK | EP | |
| Date of receipt of notice of appeal recordedAppealORIGINAL CODE: EPIDOSNNOA2EAPBN | APBN | EP | |
| Designation fees paidAKX | AKX | EP | |
| Designated contracting statesAK | AK | EP | |
| Request for extension of the european patentAX | AX | EP | |
| Search report despatchedORIGINAL CODE: 0009013PUAL | PUAL | EP | |
| Request for examination filed17P | 17P | EP | |
| Designated contracting statesAK | AK | EP | |
| Request for extension of the european patentAX | AX | EP | |
| Public reference made under article 153(3) epc to a published international application that has entered the european phaseORIGINAL CODE: 0009012PUAI | PUAI | EP |
Numbers
- Publication
- 1469697
- Publication, DOCDB
- 1469697
- Publication, EPODOC
- EP1469697
- Application
- 4005476
- Application, DOCDB
- 04005476
- Application, EPODOC
- EP20040005476
Titles3
- German
- Handover ausgelöst und kontrolliert durch die Mobilfunkstation in einem drahtlosen Breitbandzugriffssystem
- English
- Handover requested and controlled by the mobile station in a broadband wireless access communication system
- French
- Transfert intercellulaire demandé et contrôlé par la station mobile dans un système à accès sans fil et a large bande
Classification
- CPC, 6
- H04W36/0085
- H04W36/304
- H04W36/0061
- H04W36/08
- H04W36/0083
- H04B17/345
- IPC, 3
- H04B7 26
- H04W36 00
- H04W36 08
Designated states2
- Contracting states, 1
- Türkiye
- Extension states, 1
- North Macedonia