WO2012023161A1

WO2012023161A1 - A method and apparatus for carrier aggregation preparation control in a mobile communications system

Info

Publication number: WO2012023161A1
Application number: PCT/JP2010/005150
Authority: WO
Inventors: Hong Tat Toh
Original assignee: Panasonic Corporation
Priority date: 2010-08-20
Filing date: 2010-08-20
Publication date: 2012-02-23

Abstract

In order for a Mobile Terminal to setup Carrier Aggregation (CA) configuration, it needs to provide relevant information for the network to identify the suitable serving cells candidates from other carrier frequency, e.g. the Physical Cell identity (PCI), the Carrier Frequency (Freq). This information should be used by Base Station (e.g. eNB) to determine the suitable serving cells from other carrier frequency in order to perform CA setup configuration. However, having the needs for Mobile Terminal to measure and report these cells information to Base Station after connection establishment, it results in Mobile Terminal with CA capable to experience slower data rate services due to delay in CA setup configuration process. The present invention provides a method to generate and upload the list of potential serving cells information from each carrier frequency to Base Station. Making use of this information, Base Station can decide the suitable serving cell from each carrier frequency to be accessed by Mobile Terminal. This obviates the extra operation before the CA setup procedure. The present invention also provides variants to enable Base Station to control the uploading scheme; and to monitor the validity of the uploaded cells information for Mobile Terminal in high mobility environment. With this mechanism, experience of slower data rate services by Mobile Terminal due to delay in CA setup procedure can be avoided.

Description

A METHOD AND APPARATUS FOR CARRIER AGGREGATION PREPARATION CONTROL IN A MOBILE COMMUNICATIONS SYSTEM

This invention pertains to mobile communications network. More specifically, it relates to upload a list of potential cells candidates information within mobile's vicinity to network. Such information should assist early setup configuration for carrier aggregation in a mobile communication system.

In a mobile communication system (e.g. 3GPP Long-term Evolution, LTE Advanced), a Mobile Terminal has the capable to connect to multiple cells of different carrier frequency simultaneously. This connection capability is known as Carrier Aggregation (CA). In another words, the CA capable Mobile Terminal can simultaneously receive or/and transmit data using multiple carrier frequencies, also refer as Component Carrier (CC) hereafter. With multiple CCs established, the CA capable Mobile Terminal can achieve a wider transmission bandwidth (e.g. up to 100MHz). For each connected cells from each CC, the CA capable Mobile Terminal will treat these connected cells as serving cells. Such serving cells can be categorized as one Primary cell (Pcell) and multiples Secondary cells (Scells). Hence, the Base Station can allocate more radio resources through these multiple serving cells to Mobile Terminal. Thus, this enable CA capable Mobile Terminal to experience a higher data rate service performance after connection establishment. Before connection establishment, due to the cells coverage from each carrier frequency may be different, the Mobile Terminal in idle mode will measure these carrier frequencies broadcasted for cell reselection procedure. Therefore, to setup CA configuration, the Base Station shall need to collect the measured results of neighboring cells from different carrier frequencies reported from Mobile Terminal after proceed to connected mode.

[NPL 1] 3GPP TS23.401 SAE
[NPL 2] 3GPP TS36.331 RRC Protocol
[NPL 3] 3GPP TS36.304 IDLE Mode
[NPL 4] 3GPP TS24.301 NAS

This imply that for Base Station to make CA support decision (i.e. setup CA configuration), the Mobile Terminal in connected mode is required to perform measurement and report the measured results of different CCs to Base Station. Based on the reported measured results, Base Station can then determine the suitable Scells candidate from each CC before Mobile Terminal in connected mode can receive CA setup configuration information. Thus, this would take long time for Base Station to make CA support decision for Mobile Terminal after connected establishment. Therefore, the CA capable Mobile Terminal will expect to experience service with slower data rate before Base Station can provide services with CA support (i.e. provide wider transmission bandwidth) after connection establishment.

A possible approach is to setup CA configuration for CA capable Mobile Terminal after connection establishment without waiting for the reported measured results as inputs to influence the Base Station to make CA support decision. However, this could not guarantee that CA capable Mobile Terminal can experience high data rate service after connection establishment. This is because Base Station does not know the radio condition of the cells coverage within Mobile Terminal's vicinity, e.g. Mobile Terminal may be at cell edge of a CC which could not provide high data rate for Mobile Terminal due to bad radio condition.

It is obvious the above problems require an uploaded list of potential cells candidates scheme for early setup CA configuration for Mobile Terminal in connected mode such that service with slower data rate experience by Mobile Terminal can be resolved.

It is an object of the invention to solve the above discussed problems. In particular, the present invention relates to upload a list of potential Scells candidate to Base Station such that for Base Station to make CA support decision to Mobile Terminal during or just after connection establishment without further delay. This invention introduces a list of potential Scells candidate information which is a list of Inter-Frequency Measurement Information (IFMI), as generate and upload to the Base Station by Mobile Terminal before reporting. The IFMI consists of the list of individual cell measurement information (e.g. Physical Cell Identity (PCI), Carrier Frequency (Freq) & cell signal strength (RSRP/RSRQ)) such that the measured cells from different CCs are within Mobile Terminal's vicinity. To generate IFMI, the Mobile Terminal should perform measurement based on broadcasted information and determine the potential Scells candidate information. How the behavior of generating the IFMI by Mobile Terminal and uploaded of the IFMI to be adopted in network entities was explained. When IFMI is generated, the Mobile Terminal would provide this IFMI to the Base Station via uplink dedicated signaling. The Base Station could adopt this IFMI to perform CA support decision based on the list of potential Scells from each CC transmitted from the Mobile Terminal. In this object, based on IFMI that included the PCI and Freq information of the potential Scells, the uploaded potential Scells configured in the uploading configuration message by Mobile Terminal is sufficient for Base Station to decide which reported candidate cell as the potential Scell for that particular CC. Thus, extra operation in collecting measured results of the neighboring cells from different carrier frequencies by Base Station from Mobile Terminal is removed by the present invention. Therefore, Base Station can make CA support decision to Mobile Terminal during or just after connection establishment without further delay.

Another object of the present invention is to enable Base Station to control the needs for uploading the potential Scells information from Mobile Terminal as it is necessary for Mobile Terminal in idle mode to perform inter-frequency measurement on neighbor cells even if the serving cell radio quality is above a broadcasted threshold. Thus, this would enable Mobile Terminal to monitor on inter-frequency neighbor cells and generate IFMI.

Another object of the present invention is to monitor the validity of the uploaded cells information for Mobile Terminal in high mobility environment since the surrounding measured potential Scells candidates from different CCs could change quite often.

FIG.1 illustrates the system architecture that adopts the uploading scheme to generate IFMI parameter according to the present invention. FIG.2 illustrates an operation sequence of the present invention in generating IFMI parameter for eNodeB (eNB) in the architecture as shown in FIG.1. FIG.3A illustrates an example architecture of a eNB that implements the present invention. FIG.3B illustrates an operation logic for the eNB to use the IFMI parameter. FIG.4A illustrates an example architecture of a Mobile Terminal that implements the present invention. FIG.4B illustrates an operation logic of the Mobile Terminal to generate the IFMI parameter. FIG.5 illustrates an operation logic for the Mobile Terminal to mandate measurement on cells from other carrier frequencies upon request. FIG.6 illustrates an operation logic for the Mobile Terminal in high mobility environment to monitor the validity of the uploaded potential Scells information parameter.

Description of Embodiment

(Embodiment 1)
With reference to Figure 1, a mobile communication system (100) that the present invention can apply to is presented. The Mobile Communication System (100) includes a number of cells from different carrier frequency (106, 108, 110) with the cells coverage of different deployment area. This multiple cells deployment from different carrier frequency is manage by a Base Station known as eNodeB (eNB) (102). The Mobile Terminal (104) is connected to the eNB (eNB) (102) in macro cell (106).

It is obvious to anyone skilled in the art that in other variants of the architecture, the cells coverage from different carrier frequency that is manage by the same eNB can be adopted in different deployment scenario (e.g. femto/pico cell is deployed within a macro cell and these cells are manage by the same eNB). This would not affect the general principle of the present invention.

As shown in Figure 1, the Mobile Terminal (104) is communicating with the eNB (102). The eNB (102) provides operator's services to the Mobile Terminal (104) with multiple cells coverage (106, 108, 110) of different carrier frequency. This multiple cells coverage enable eNB (102) to provide a wider transmission bandwidth to the Mobile Terminal (104).

With reference to Figure 2, an operation sequence of the eNB (102) to obtain the uploaded Inter-Frequency Measurement Information (IFMI) from the Mobile Terminal (104) during or just after the connection establishment procedure is illustrated.

As shown in Figure 2, upon the Mobile Terminal (104) camped on eNB (102) with serving cell coverage (106), the Mobile Terminal (104) will receive a Scell_Thresholds parameter via broadcast control signaling (202). The Scell_Thresholds parameter is adopt to limit the number of potential Scells from each carrier frequency, refer as component carrier (CC) hereafter; to be uploaded to eNB (102). For example, a typical Scell_Thresholds parameter entry may consider the following options:

Option 1: Minimum Threshold, Maximum threshold
E.g. Signal strength of the detected cell above the maximum threshold will be consider as a potential Scell candidate; Signal strength of the detected cell above the minimum threshold but below maximun threshold will be consider as a possible Scell candidate;

Option 2: Absolute Threshold
E.g. Signal strength of the detected cell above this threshold will be consider as a potential Scell candidate.

Option 3: Relative Threshold
E.g. Signal strength of the detected cell which fall within the threshold range will be consider as a potential Scell candidate.

Based on the measurement criteria broadcast in system information (204), the Mobile Terminal (104) will perform cell measurement on other CCs within the Mobile Terminal's (104) vicinity, similar to that specified in <3>. The Mobile Terminal (104) will start to detect neighboring cells of each CC and measure the signal strength of the detected cells (206, 208). The measured results of these detected cells from each CC will be stored by the Mobile Terminal (104) to generate the IFMI (210).

In Generate IFMI (210), the Mobile Terminal (104) should adopt the Scell_Thresholds parameter to generate the list of potential Scells information, e.g. Physical Cell identity (PCI), Carrier Frequency (Freq), Cell signal strength (e.g. RSRP/RSRQ) from the list of stored measured results of the detected cells from each CC. The Mobile Terminal (104) will determine the potential Scells by checking against the signal strength of these detected cells with the value of the Scell_Thresholds parameter. Upon the signal strength of the detected cell is above the value of the Scell_Thresholds parameter, the Mobile Terminal (104) will consider that detected cell of the CC as a potential Scell candidate for that CC. Thus, this enable the Mobile Terminal (104) to limit the number of potential Scells with good radio quality from each CC, also refer as IFMI hereafter, to be uploaded to the eNB (102) upon uploading is triggered. For example, a typical IFMI entry may include the following information:
Freq-1 IFMI-1 ::= [PCI-1, RSRP-1/RSRQ-1];
IFMI-2 ::= [PCI-2, RSRP-2/RSRQ-2];
Freq-2 IFMI-3 ::= [PCI-3, RSRP-3/RSRQ-3];
Freq-3 IFMI-4 ::= [PCI-5, RSRP-5/RSRQ-5];
IFMI-5 ::= [PCI-6, RSRP-6/RSRQ-6];

For the trigger of uploading the IFMI to eNB (102), it can be based on the following approach: 1) Implicit Trigger; or 2) Conditional Trigger. For Implicit Trigger approach, the Mobile Terminal (104) should include the IFMI if available and upload to eNB (102) either during the connection establishment procedure or just after connection establishment procedure via an uplink dedicated signaling. For Conditional Trigger approach, the network entity (e.g. eNB (102)) can control the uploading by configuring a conditional trigger parameter, e.g. a threshold parameter to check whether the number of potential Scells has exceeded or a requested parameter such a Boolean flag, to Mobile Terminal (104). In this case, the Mobile Terminal (104) will only upload the IFMI to eNB (102) upon the conditional trigger parameter has met the uploading criteria.

Upon the trigger for uploading IFMI has met, the Mobile Terminal (104) should configure the IFMI and transmit to eNB (102) via Uplink Control Signaling (212), e.g. RRC Connection Request, RRC Connection Setup Complete, Measurement Report as defined in <2>; or new uplink message.

Upon receiving the IFMI (212), the eNB (102) should stored the IFMI and use this configured information to make CA support decision for the Mobile Terminal (104). Based on the received IFMI and realize that the Mobile Terminal (104) is CA capable, the eNB (102) should adopt the IFMI to assist CA support decision procedure. The eNB (102) should check if there is any CA-able CC which is suitable for the Mobile Terminal (104) to support CA setup procedure, present within the IFMI. If present, the eNB (102) should decide the Scell from the list of potential Scells within this CA-able CC for Mobile Terminal (104). The decision of selecting the Scell from each CC as make by eNB (102) could be based on load balancing condition, efficient resource utilization, etc. For example, based on radio quality of the list of potential Scells of each CC, the Scell with the best radio quality is consider as a suitable Scell candidate for that CC to support CA setup procedure. However, if that Scell is currently experience high traffic flows, the eNB (102) will not select that Scell of the CC to support CA setup for the Mobile Terminal (104) due to Mobile Terminal (104) may not able to experience services with high data rate if connected to that Scell. Thus, the eNB (102) should select the Scell with the next best radio quality of that CC such that the traffic loads is bearable.

It is obvious to anyone skilled in the art that there can be alternative methods to verify if that Scell is suitable or not to support CA setup for the Mobile Terminal (104). This does not affect the general principle of the present invention.

By adopting the IFMI to assist the CA setup procedure, the eNB (102) could obviate the extra operation before decide on the intended Scell from each CC as suitable Scell for Mobile Terminal (104) to support CA setup procedure. The eNB (102) should configure the CA setup configuration information and measurement configuration, if required, and transmit to Mobile Terminal (104) via downlink dedicated signaling (214), e.g. RRC Connection Reconfiguration message as defined in <2>. Thus, with IFMI, CA support decision could be decided by eNB (102) faster and the Mobile Terminal (104) will not experience services with slower data rate due to delay in setup CA configuration for Mobile Terminal (104) after connection establishment.

It is obvious there are other operations involved in the process, e.g. as those defined in the Mobile Terminal (104) based on connection reestablishment procedure in <2>. However, for illustration purpose, the above sequence does not show all the steps. It is obvious to anyone skilled in the art that the additional operation steps do not affect the general principle of the present invention.

With reference to Figure 3A, an architecture of the eNB (102) that implements the present invention is shown.

As shown in the figure, the eNB (102) comprises two major components, namely the Scells List Management Unit (302) and the CA Management Unit (306).

Among them the CA Management Unit (306) is in charge of handling all the CA setup management related signaling between the Mobile Terminal (104) and eNB (102). The protocol used between them is as specified in <2>.

The Scells List Management Unit (302) is in charge of managing the IFMI of the list of potential Scells from each CC as provided from Mobile Terminal (104) via Uplink Control Signaling (212) and adopts the IFMI to assist in CA setup procedure. For example, when a uplink dedicated signaling is transmitted from the Mobile Terminal (104) as shown in Figure 2, the CA Management Unit (306) will consult the Scells List Management Unit (302) via interface (304) of whether the Mobile Terminal (104) should treat this list of potential Scells from each CC as suitable Scell for Mobile Terminal (104) by checking if the CCs are CA-able for the Mobile Terminal (104) to support CA setup as well as the traffic and radio quality condition of the Scell from each CC. Based on this checking procedure, the Scells List Management Unit (302) could identify the suitable Scell from each CC to be supported by the Mobile Terminal (104) for CA setup procedure. The Scells List Management Unit (302) will pass the outcome of the checking result to CA Management Unit (306) via interface (304). The CA Management Unit (306) would then decide on the intended Scell from each CC for CA setup configuration to the Mobile Terminal (104). The CA configuration information is configured to Mobile Terminal (104) via downlink dedicated signaling, as shown in Figure 2.

With reference to Figure 3B, an example logic used by the Scells List Management Unit (302) and the CA Management Unit (306) is presented.

As shown in the figure, the Scells List Management Unit (302) will be notified of the IFMI by the CA Management Unit (306), as in step 308.

Once notified of the IFMI, the Scells List Management Unit (302) will store the IFMI, as in step 310. If the Scells List Management Unit (302) already has a stored copy of IFMI, the latest received IFMI should be used instead. In another words, the Scells List Management Unit (302) will replace the stored copy with the newly received copy of IFMI, as in step 310. The IFMI should be used to assist eNB (102) to perform CA support decision procedure, as in step 312.

In step 312, the Scells List Management Unit (302) will perform a suitability check procedure based on the stored IFMI; and the status of CC which is CA-able or not for the Mobile Terminal (104). Based on the stored IFMI, the eNB (102) should decide which CC within the stored IFMI is CA-able for Mobile Terminal (104). If that checked CC is non CA-able to Mobile Terminal (104), the eNB (102) will proceed to check on other available CCs. After deciding the checked CC is CA-able for Mobile Terminal (104) to perform CA setup procedure, the eNB (102) will monitor the Scells condition from that CC, e.g. Scell traffic condition, Scell radio quality, before deciding which is the suitable cell of that CC as Scell candidate for Mobile Terminal (104) to support CA setup procedure, as in step 314. The eNB(102) will then include the suitable Scell of that CC as the serving cell for that CC, as in step 316, such that it will be used for CA setup procedure. Upon there is still available CCs present, as in step 318, the eNB (102) will proceed to continue checking on the available CCs and Scells from the available CCs. On the other hand, if there is no available CC, the eNB (102) will pass all the serving cell information from each CC to CA Management Unit (306) via interface (304).

In step 320, the CA Management Unit (306) should decide the serving cell of each CC and generate the CA setup configuration information to Mobile Terminal (104) via a downlink dedicated signaling, as in step 322, e.g. RRC Connection Reconfiguration as defined in <2>.

It is obvious to anyone skilled in the art that the Scells List Management Unit (302) can take into account other information in performing the check procedure against with IFMI, e.g. Mobile Terminal's (104) location, previous camped on cell information, etc.

With reference to Figure 4A, an example architecture of the Mobile Terminal (104) that implements the present invention is presented.

As shown in the diagram, there are three major components in the Mobile Terminal (104), namely the Cell Measure Control Unit (CMCU) (402), Scells List Generate Unit (SLGU) (406) and Upload Scells Control Unit (USCU) (410).

The CMCU (402) is in charge of handling the detected and measured cells based on the trigger of cell measure on other CCs. When the radio quality of current camped on cell by Mobile Terminal (104) is below certain signal strength threshold, similar to that specified in <3>, the Mobile Terminal (104) should perform the cell measurement procedure on other CCs. Once the cells from other CCs are detected and measured within the Mobile Terminal's (104) vicinity, the CMCU (402) will pass these measured cells from other CCs to SLGU (406) via interface (404).

The SLGU (406) is in charge of generating the IFMI. The SLGU (406) will use the broadcasted Scell_Thresholds parameter to check against with the radio quality of each measured cells from each CC. Upon the radio quality of the measured cell from each CC is above the value of the Scell_Thresholds parameter, the Mobile Terminal (104) will generate and store the list of potential Scells for each CC. The SLGU (406) will continue to generate and store the IFMI based on the cell measured that satisfy the Scell_Thresholds criteria. Upon the trigger for uploading IFMI has met, the SLGU (406) will pass the IFMI to USCU (410) via interface (408).

The USCU (410) is in charge of uploading the IFMI as stored in the Mobile Terminal (104) to the eNB (102) via uplink dedicated signaling, as shown in Figure 2. The protocol used between them is as specified in <2>.

With reference to Figure 4B, an example logic used by the Cell Measure Control Unit (CMCU) (402), Scells List Generate Unit (SLGU) (406) and Upload Scells Control Unit (USCU) (410) is presented.

As shown in the figure, the CMCU (402) will perform cell measurement procedure, as in step 412. When the camped on cell by Mobile Terminal (104) is below certain signal strength threshold, similar to that specified in <3>, as in step 414, the CMCU (402) will trigger cell measurement on other CCs. Otherwise, the Mobile Terminal (104) will continue to monitor current camped on cell radio quality. Upon triggered of cell measurement on other CC has met, the CMCU (402) will perform measurement on cells from other CCs and stored the measured results of the measured cells, as in step 416. The CMCU (402) will pass the stored measured results to SLGU (406) via interface (404).

The SLGU (406) will determine the list of potential Scells from each CC by checking against with the broadcasted Scell_Thresholds parameter, as in step 418. When the radio quality of the measured cell from each CC is above the value of the Scell_Thresholds parameter, the Mobile Terminal (104) will consider this measured cell is a potential Scell for that CC. If the radio quality is below the value of the Scell_Thresholds parameter, the SLGU (406) will continue to seek the stored measured cells for any potential Scells candidate. Once the potential Scells candidates are determined, the SLGU (406) will start to generate the list of potential Scells information, also refer as IFMI hereafter; as in step 420. For example, upon a new potential Scell candidate is determine, the Mobile Terminal (104) will categorize the Scell entry based on per carrier frequency.

It is obvious there would have other alternative to manage the entry allocation for IFMI, e.g. categorize based on same signal strength parameter, categorize based on same PCI with different carrier frequency, etc. It is obvious to anyone skilled in the art that the other alternative of managing the IFMI does not affect the general principle of the present invention.

Upon the IFMI is generated, the SLGU (406) will check if the uploading of the IFMI has triggered or not, as in step 422. For example, when the generated IFMI is available upon Mobile Terminal (104) is ongoing establishing connection, the Mobile Terminal (104) will trigger this uploading scheme by making an implicit reporting with special reporting cause either during or just after connection establishment. Alternatively, the eNB (102) could configure a uploading criteria parameter to solely monitor for this uploading scheme. Such parameter could be based on a threshold to act as a trigger to monitor if the number of potential Scells from each CC has exceeded the threshold level; or parameter could be based on a boolean flag whereby eNB (102) could request Mobile Terminal (104) to upload IFMI when available either during or just after connection establishment.

It is obvious there are other methods to trigger the upload of IFMI, e.g. periodic upload by network configured, etc. It is obvious to anyone skilled in the art that the other alternative of trigger the upload for IFMI does not affect the general principle of the present invention.

In step 422, when the uploading criteria has yet triggered, the SLGU (406) will continue to measure cells from other CCs and check if that measured cell is a potential Scell candidate or not. Otherwise, the SLGU (406) will pass the generated IFMI to USCU (410) via interface (408).

The USCU (410) will configure the generated IFMI in a report message, as in step 424 and upload this report to eNB (102) via uplink dedicated signaling, e.g. RRC Connection Request, RRC Connection Setup Complete, Measurement report, as defined in <2>, or new uplink message, as in step 426.

The validity for IFMI before being uploaded to eNB (102) from Mobile Terminal (104) should be based on certain condition. For example, the following options could be adopted to assure generated IFMI is valid: 1) Before establishing connection and Mobile Terminal (104) has not perform any idle mode mobility procedure; 2) Before establishing connection and Mobile Terminal (104) has already perform idle mode mobility procedure, Mobile Terminal (104) should re-generate a new set of IFMI before establishing connection.

It is obvious there are other methods to assure the IFMI validity, e.g. periodic update of IFMI to eNB (102) from Mobile Terminal (104) trigger establishing connection and before completion of connection establishment, etc. It is obvious to anyone skilled in the art that the other alternative of updating the IFMI does not affect the general principle of the present invention.

(Embodiment 2)
In the previous description, the Mobile Terminal (104) would trigger the uploading of the IFMI when the criteria had met. However, there will be scenarios whereby the Mobile Terminal (104) is situated near to eNB (102) such that the Mobile Terminal (104) is experience good radio quality from the camped on cell. Thus, Mobile Terminal (104) may not perform cell measurement on other CCs.

In this case, upon proceeding to connected mode, Mobile Terminal (104) may not have available measured results of neighboring cells from other CCs; and hence, Mobile Terminal (104) is not able to determine list of potential Scells information and upload to eNB (102) during or just after connection establishment. To solve the above issue, with reference to Figure 5, an alternative behavior for Mobile Terminal (104) to upload IFMI is presented.

As shown in the figure, an example logic for Mobile Terminal (104) to check and upload the IFMI is presented. This figure is based on Figure 4B. Therefore only the difference is explained here.

To perform cell measurement procedure on other CCs, the Mobile Terminal (104) will perform a checking procedure against with a configured control parameter, as in step 502. For example, a "Boolean" flag is configured to Mobile Terminal (104) by setting True or False. When flag set as True, the broadcasted threshold criteria, which is adopt to check whether Mobile Terminal (104) should perform measurement on neighboring cells of other CCs or not, is ignored, and Mobile Terminal (104) will proceed to perform measurement on cells of other CCs. When flag set as False, the Mobile Terminal (105) should obey the broadcasted threshold criteria, similar to that specified in <3>. An alternative approach is to configure two different types of CC, namely 1) CA-able carrier frequency and 2) Non CA-able carrier frequency from eNB (102) to Mobile Terminal (104). For example, the eNB (102) could broadcast two separate list of CCs to Mobile Terminal (104). Upon a list of broadcasted CC is set as CA-able carrier frequency, the Mobile Terminal (104) will ignore the broadcasted threshold criteria and start to perform measurement on neighboring cells from these CA-able carrier frequency. Otherwise, the Mobile Terminal (104) should obey the broadcasted threshold criteria, similar to that specified in <3>.

In step 502, this control parameter is configured by eNB (102) and transmits to Mobile Terminal (104) via broadcast control signaling, e.g. System Information Block as defined in <2>. When the Mobile Terminal (104) received the control parameter which is intend to ignore broadcasted threshold criteria, the Mobile Terminal (104) will start to perform measurement on neighboring cells from other CCs. Otherwise, the Mobile Terminal (104) will wait until the broadcasted threshold criteria has met before start performing measurement on neighboring cells from other CCs. Thus, the issue of not available list of potential Scells information for uploading by Mobile Terminal (104) during or just after connection establishment is resolved.

It is obvious that control the measurement on neighboring cells from other CCs by eNB (102) is just one of the possible approaches. There may be alternative approaches, such as when the Mobile Terminal (104) detects a new carrier frequency which is not present in the broadcasted system information; the Mobile Terminal (104) will start to perform measurement on neighboring cells of that new carrier frequency as well as the other carrier frequency that is present in the broadcasted system information.

With this new behavior, most of the processing sequence and logic described earlier still apply, except for the additional checking procedure of ignoring the broadcasted threshold criteria for Mobile Terminal (104) to take into account if eNB (102) has requested.

It is obvious to anyone skilled in the art that the above variance does not change the general principle of the present invention.

(Embodiment 3)
In the previous description, the scenario encounter by Mobile Terminal (104) is related to low mobility environment. However, there will be scenarios whereby the Mobile Terminal (104) is in a high mobility environment, e.g. Mobile Terminal (104) is in a moving vehicle.

In this case, the generated IFMI by the Mobile Terminal (104) before uploading to eNB (102) would become invalid very frequent. This implies that upon uploading triggered criteria is met; the Mobile Terminal (104) may upload an obsolete IFMI to eNB (102) during or just after connection establishment. To solve the above issue, with reference to Figure 6, an alternative behavior for Mobile Terminal (104) to manage IFMI in high mobility environment is presented.

As shown in the figure, an example logic for Mobile Terminal (104) to change the uploading scheme of IFMI is presented. This figure is based on Figure 4B. Therefore only the difference is explained here.

Upon the trigger of uploading the IFMI has met, the Mobile Terminal (104) should perform a checking procedure on the validity of the IFMI generated by the Mobile Terminal (104), as in step 602. In step 602, a control parameter is configured to Mobile Terminal (104) to check if the generated IFMI by the Mobile Terminal (104) is valid or not. For example, adopt a configured time duration parameter to monitor the generated IFMI by the Mobile Terminal (104) is still continue to remain above a certain threshold over a span time interval. The "threshold" can refer as 1) number of potential Scells; or 2) radio quality of potential Scell.

Upon the Mobile Terminal (104) has determined the generated IFMI is still valid after uploading triggered criteria has met, the Mobile Terminal (104) will configure the generated IFMI in a report message, as in step 424. Otherwise, the Mobile Terminal (104) will terminate the uploading of the generated IFMI in the report message, as in step 604. In this case, the Mobile Terminal (104) should stop uploading the generated IFMI to eNB (102), as in step 606. Thus, eNB (102) would not be able to use IFMI to make CA support decision for Mobile Terminal (104). For example, upon a time duration parameter is configured, the Mobile Terminal (104) should check for the validity of IFMI by monitoring the threshold over a span time interval. Upon the IFMI become invalid, the Mobile Terminal (104) will stop uploading the IFMI to eNB (102) and consider no potential Scells candidate within Mobile Terminal's (104) vicinity. Thus, the eNB (102) will only based on normal measurement reporting from Mobile Terminal (104) after established connection to make CA support decision.

It is obvious that terminate the upload of IFMI is just one of the possible approaches. There may be alternative approaches, such as upon realize the Mobile Terminal (104) is in a high mobility situation, the eNB (102) can simply ignore the uploaded IFMI and consider the CA setup procedure should based on normal measurement reporting from Mobile Terminal (104) after connection establishment.

With this new behavior, most of the processing sequence and logic described earlier still apply, except for the additional checking procedure for Mobile Terminal (104) to take into account of the IFMI validity before uploading the IFMI to eNB (102).

Claims

A mobile terminal comprising:
a generating section that generate a list of inter-frequency measurement information during or just after a connection establishment based on measured results obtained from a cell measurement in idle mode; and
a uploading section that upload the list of inter-frequency measurement information to a base station
The mobile terminal according to claim 1, further comprising a updating section that update the list of inter-frequency measurement information before uploading to the base station upon current list of inter-frequency measurement information become invalid.
A base station comprising:
a storing section that stores inter-frequency measurement information; and
a using section that use the inter-frequency measurement information to make a carrier aggregation support decision for a mobile terminal at early stage of connection setup.
The base station according to claim 3, further comprising a controlling section that controls a number of uploading cells information from a mobile terminal based on configuring a threshold for limiting the cells to be uploaded.
The base station according to claim 3, further comprising a controlling section that controls the need of uploading the list of inter-frequency measurement information from a mobile terminal by introducing a configured trigger mechanism.
The base station according to claim 3, further comprising a enforcing section that enforces a mobile terminal to ignore a broadcasted threshold criteria which enable the mobile terminal to start monitoring neighbor cells from other carrier frequency.
The base station according to claim 3, further comprising a monitoring section that monitors the validity of the list inter-frequency measurement information generated from a mobile terminal upon the mobile terminal is in high mobility.