WO2015109691A1 - 一种多覆盖场景下的移动鲁棒性方法、基站和终端 - Google Patents

一种多覆盖场景下的移动鲁棒性方法、基站和终端 Download PDF

Info

Publication number
WO2015109691A1
WO2015109691A1 PCT/CN2014/077404 CN2014077404W WO2015109691A1 WO 2015109691 A1 WO2015109691 A1 WO 2015109691A1 CN 2014077404 W CN2014077404 W CN 2014077404W WO 2015109691 A1 WO2015109691 A1 WO 2015109691A1
Authority
WO
WIPO (PCT)
Prior art keywords
cell
message
coverage
identifier
base station
Prior art date
Application number
PCT/CN2014/077404
Other languages
English (en)
French (fr)
Inventor
方建民
韩立锋
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2015109691A1 publication Critical patent/WO2015109691A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/02—Arrangements for optimising operational condition
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/18—Negotiating wireless communication parameters
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/04—Arrangements for maintaining operational condition

Definitions

  • the present invention relates to the field of communications, and in particular, to a mobile robust optimization method, apparatus, and system for a cell to support multiple coverage scenarios. Background technique
  • the Third Generation Partnership Projects (3GPP) organization is in the evolution of the universal terrestrial radio access network (Evolved Universal Terrestrial) Radio Access Network, E-UT AN )
  • the system began to introduce the Self-Organized Network (SON) function.
  • the E-UTRAN includes an evolved Node B (eNB), and its corresponding core network (Core Network) includes a Mobile Management Entity (MME) and a Serving Gateway (S-GW).
  • MME Mobile Management Entity
  • S-GW Serving Gateway
  • the eNB and the CN are connected through the S1 interface, and the eNBs can be connected through the X2 interface.
  • An eNB can manage one or more cells (Cells).
  • SON includes Mobility Load Balancing Optimization (MLB) and Mobility Robustness Optimization (M O).
  • the MO includes problem detection (mainly with premature handover, late handover, handover to the wrong cell, etc.), statistical analysis of the detected MRO problem, according to statistical analysis (such as the occurrence of a certain MO problem within a certain period of time) Exceeding the set value, etc.) 3 parts of the negotiation and adjustment of the mobility parameters between the neighboring cells to reduce the Handover Failure (HOF) or the related radio link failure (Ralf Link Failure, RLF) .
  • the mobility parameter negotiation adjustment part can also be used for the MLB, and the MLB includes three parts of the load information report, the judgment analysis, the mobility parameter negotiation adjustment (or the direct selection of the UE handover).
  • Current MRO The assumption of the problem solution is that the coverage of the cell is constant, that is, the cell has only one coverage scenario.
  • a cell that supports multiple coverage scenarios refers to the same cell (that is, the same ECGI: E-UT AN Cell Global Identifier) has multiple coverage scenarios, and the coverage of the cell in each coverage scenario is different (eg, Figure 1).
  • the embodiments of the present invention are directed to providing a mobile robust optimization method in a multi-coverage scenario, including:
  • the base station receives the message, where the message carries the identifier of one or more cells and the coverage scenario identifier corresponding to the cell;
  • the base station analyzes the MO problem in different coverage scenarios according to the cell identifier and the coverage scenario identifier carried in the message.
  • the base station triggers the adjustment corresponding to the scenario. Mobility parameters.
  • the message is from a terminal or from a neighboring base station.
  • the MRO problem is a premature handover, a late handover or a handover to an error cell.
  • the mobility parameter adjustment condition refers to that the number of times the cell initiates an MRO problem in the coverage scenario exceeds a set value within a specified time.
  • the application also provides a base station, including:
  • the first receiving module is configured to receive a message, where the message carries an identifier of one or more cells and a coverage scene identifier corresponding to the cell;
  • the processing module is configured to: according to the cell identifier and the coverage scenario identifier carried in the message, the base station analyzes the MO problem in different coverage scenarios according to the cell statistics, and when the cell specifies the coverage scenario When the statistical analysis result meets the mobility parameter adjustment condition, the base station triggers adjustment of the corresponding mobility parameter.
  • the first receiving module is configured to receive the message from a terminal or from a neighboring base station.
  • the processing module is configured to detect the MRO problem as premature handover, late handover, and handover to the wrong cell.
  • the mobility parameter adjustment condition is that the number of times that the cell raises the M O problem in the coverage scenario exceeds the set value within a specified time.
  • the first receiving module and the processing module may perform a processing by using a central processing unit (CPU), a digital signal processor (DSP, a digital Singnal Processor), or a programmable logic array (FPGA, Field). - Programmable Gate Array) implementation.
  • CPU central processing unit
  • DSP digital signal processor
  • FPGA programmable logic array
  • FPGA Field Programmable Gate Array
  • the present application further provides a mobile robustness method in a multi-coverage scenario, including: receiving, by a terminal UE, a first message, where the first message carries a coverage scene identifier of a currently connected cell of the UE;
  • the UE sends a second message, where the second message carries the identifier of one or more cells saved by the UE and the coverage scenario identifier corresponding to the cell.
  • the manner of acquiring the coverage scenario identifier carried by the first message is any one of the following: obtaining from a radio resource control RRC reconfiguration message; and obtaining from a system information broadcast.
  • the second message is a UE Information Response message.
  • the application also provides a terminal, including:
  • the second receiving module is configured to receive a first message, where the first message carries the coverage scenario identifier of the currently connected cell of the UE;
  • the sending module is configured to send a second message, where the second message carries the identifier of one or more cells saved by the UE and the coverage scenario identifier corresponding to the cell.
  • the manner in which the coverage scenario identifier carried by the first message is obtained is any one of the following: obtained from an RRC reconfiguration message; and obtained from a system information broadcast.
  • the second message is a UE Information Response message.
  • the second receiving module and the sending module may perform central processing when performing processing
  • H CPU, Central Processing Unit
  • DSP Digital Singnal
  • the mobile robustness method, the base station, and the terminal in the multi-coverage scenario provided by the embodiment of the present invention include the coverage scenario identifier of the related cell in the case that the cell supports multiple coverage scenarios.
  • the coverage scenario identifier of the related cell in the case that the cell supports multiple coverage scenarios.
  • Figure 1 is a schematic diagram of a cell supporting multiple coverage scenarios.
  • Figure 3 shows the MRO flow diagram of the LF Report after the RRC connection reestablishment is completed.
  • Figure 4 shows the MRO flow diagram of the RLF Report after the RRC connection is established.
  • Figure 5 is a flow chart of the MRO of the application instance switching request with mobility information
  • Figure 6 is a structural diagram of a base station in the embodiment.
  • Fig. 7 is a structural diagram of a terminal in the embodiment. detailed description
  • the cell When the cell supports multiple coverage scenarios, the cell notifies the user equipment (UE, User Equipment) of the current coverage scenario, for example, by system information broadcast to all UEs, or by radio resource control (RRC, Radio Resource Control).
  • UE User Equipment
  • RRC Radio Resource Control
  • the message is sent to a certain UE, etc., to improve the accuracy of the MO problem detection and statistical analysis.
  • the identifier of the current coverage scenario is saved for the relevant cell, the identifier is included in the LF Report; when the UE sends the RRC connection reestablishment request message to the cell, if the UE saves the relevant cell
  • the identifier of the coverage scenario at that time is included in the request message.
  • the message should include the identifier of the current coverage scenario of the relevant cell; when the eNB sends the HANDOVER REQUEST message to the neighboring eNB. If the relevant cell supports multiple coverage scenarios, the message should include the identifier of the current coverage scenario of the relevant cell. To improve the accuracy of MRO problem detection and statistical analysis.
  • the eNB When the eNB sends a mobility update request (MOBILITY CHANGE REQUEST) message to the neighboring eNB, if the relevant cell supports multiple coverage scenarios, the identifier of the coverage scenario of the relevant cell should be included in the message. To clarify which current coverage is for the coverage scenario to improve the accuracy of the mobility parameter negotiation adjustment.
  • MOBILITY CHANGE REQUEST mobility update request
  • Step 201 The UE is connected to the cell 1.
  • the UE obtains the current coverage scenario identifier of the cell 1 from the system information broadcast.
  • Step 202 The UE fails to connect in the cell 1.
  • Step 203 The UE performs an RRC re-establishment attempt in the cell 2, and includes the identifier of the cell 1 and the coverage scenario identifier of the cell 1 in the RRC connection reestablishment request message sent to the cell 2.
  • Step 204 After the cell 2 receives the RRC reestablishment request message, the eNB (ie, eNB2) to which the cell 2 belongs can know that the UE has failed to connect in the cell 1 according to the content in the message, and the coverage scenario identifier of the cell 1 is 1 at that time.
  • the RLF INDICATION message is sent to the eNB of the cell 1 (ie, eNB1), and the identifier of the cell 1 and the current coverage scenario identifier of the cell 1 are 1, the identifier of the cell 2, and the current coverage scenario identifier of the cell 2 is 1.
  • Step 205 After receiving the RLF INDICATION message, the eNB1 may know that the UE has failed to connect in the cell 1 (covering the scenario 1 at the time) according to the content in the message, and performs an RRC reestablishment attempt in the cell 2 (at the time covering the scenario 1). . eNB1 queries its saved context and finds that the UE is tangential to cell 1 by cell 2, so it is determined that this is a premature handover from cell 2 (covering scene 1 at the time) to cell 1 (covering scene 1 at that time). And sending a HANDOVER REPORT message to the eNB of the cell 2 (ie, eNB2), including the identifiers of the cell 1 and the cell 2, and their current coverage scenario identifiers.
  • eNB2 ie, eNB2
  • Step 206 After receiving the HANDOVER REPORT message, the eNB2 performs statistical analysis on the detected MRO problem according to different coverage scenarios, and if it is found from the cell 2 (when the scenario 1 is covered) to the cell 1 (when the scenario 1 is covered) If the number of early handovers exceeds the set value within a certain period of time, it is considered that the corresponding mobility parameter between the cell 2 and the cell 1 needs to be adjusted.
  • Step 207 The eNB2 sends a mobility update request (MOBILITY CHANGE REQUEST) message to the eNB1, where the message includes the identifier of the cell 2 and the coverage scenario identifier of the cell 2 is 1, the identifier of the cell 1 and the coverage scenario identifier of the cell 1 are 1, to negotiate Adjust the mobility parameter corresponding to cell 2 (covering scenario 1) to cell 1 (covering scenario 1) to reduce premature handover of cell 2 to cell 1.
  • MOBILITY CHANGE REQUEST mobility update request
  • Step 301 The UE is connected in the cell 1, and the UE obtains the cell 1 from the RRC reconfiguration message.
  • the previous coverage scene is identified as 1.
  • Step 302 The UE fails to connect in the cell 1.
  • Step 303 The UE performs the RRC re-establishment in the cell 2, and the RRC connection re-establishment completion message sent to the cell 2 includes an indication of the available RLF report; the cell 2 receives the available RLF report included in the RRC connection re-establishment completion message. Instructing to send a UE Information Request message to the UE; after receiving the UE Information Request message, the UE includes the LF Report information in the UE Information Response message sent back to the cell 2, where the RLF Report information includes the identifier of the cell 1 and the cell 1 at the time The coverage scene is identified as 1.
  • Step 304 After receiving the RLF Report information, the eNB (ie, eNB2) to which the cell 2 belongs can know that the UE has failed to connect in the cell 1 according to the content thereof, and the coverage scenario identifier of the cell 1 is 1 at the time, and then the cell 1
  • the eNB (ie, eNB1) sends the RLF INDICATION message including the identifier of the cell 1 and the coverage scenario identifier of the cell 1 is 1, the identifier of the cell 2, and the current coverage scenario identifier of the cell 2 is 1.
  • Step 305 After receiving the RLF INDICATION message, the eNB1 may know that the UE has failed to connect in the cell 1 (covering the scenario 1 at the time) according to the content in the message, and the RRC reestablishment succeeds in the cell 2 (at the time covering the scenario 1). And finding that the UE is tangential to cell 1 by cell 2, and then determines that this is a premature handover from cell 2 (covering scene 1 at the time) to cell 1 (covering scene 1 at the time), and to cell 2
  • the eNB ie, eNB2 sends a HANDOVER REPORT message containing the identifiers of Cell 1 and Cell 2 and their current coverage scenario identifiers.
  • Step 306 After receiving the HANDOVER REPORT message, the eNB2 performs statistical analysis on the detected MRO problem according to different coverage scenarios, and if it is found from the cell 2 (when the scenario 1 is covered) to the cell 1 (when the scenario 1 is covered) If the number of early handovers exceeds the set value within a certain period of time, it is considered that the corresponding mobility parameter between the cell 2 and the cell 1 needs to be adjusted.
  • Step 307 eNB2 sends a mobility update request to eNB1 (MOBILITY CHANGE) REQUEST) message, the message includes the identifier of the cell 2 and the coverage scenario identifier of the cell 2 is 1, the identifier of the cell 1 and the coverage scenario identifier of the cell 1 are 1, to adjust the cell 2 (covering scenario 1) to the cell 1 by negotiation (covering the scenario) 1) Corresponding mobility parameters to reduce premature handover of cell 2 to cell 1.
  • Step 401 The UE is connected to the cell 1.
  • the UE obtains the current coverage scenario identifier of the cell 1 from the system information broadcast.
  • Step 402 The UE fails to connect in the cell 1.
  • Step 403 The UE enters an idle state after failing to perform an RRC reestablishment attempt in the cell 2.
  • Step 404 The UE performs the RRC establishment success in the cell 4, and the RRC connection setup complete message sent to the cell 4 includes an indication of the available RLF Report; the cell 4 receives the available RLF Report included in the RRC connection setup complete message. Instructing to send a UE Information Request message to the UE; after receiving the UE Information Request message, the UE includes the LF Report information in the UE Information Response message sent back to the cell 4, where the RLF Report information includes the identifier of the cell 1 and the current coverage of the cell 1
  • the scene identifier is 1, the identifier of the cell 2, and the coverage scenario identifier of the cell 2 at that time is 1.
  • Step 405 After the cell 4 receives the RLF Report information, the eNB (ie, eNB4) to which the cell 4 belongs can know that the UE has failed to connect in the cell 1 according to the content therein, and the coverage scenario identifier of the cell 1 is 1, and then the cell 1
  • the eNB (ie, eNB1) sends the RLF INDICATION message including the identifier of the cell 1 and the coverage scenario identifier of the cell 1 is 1, the identifier of the cell 2, and the coverage scenario identifier of the cell 2 is 1.
  • Step 406 After receiving the RLF INDICATION message, the eNB1 may know that the UE has failed to connect in the cell 1 (at the time covering the scenario 1) and the RRC reestablishment succeeded in the cell 2 (at the time covering the scenario 1) according to the content in the message. And find that the UE is tangential to cell 1 by cell 2, so it is determined that this is once from cell 2 (at the time covering scene 1) to cell 1 (when The time interval covers the premature handover of the scenario 1), and sends a HANDOVER REPORT message to the eNB (ie, eNB2) to which the cell 2 belongs, including the identifiers of the cell 1 and the cell 2 and their current coverage scenario identifiers.
  • the eNB ie, eNB2
  • Step 407 After receiving the HANDOVER REPORT message, the eNB2 performs statistical analysis on the detected MRO problem according to different coverage scenarios, and if it is found from the cell 2 (when the scenario 1 is covered) to the cell 1 (when the scenario 1 is covered) If the number of early handovers exceeds the set value within a certain period of time, it is considered that the corresponding mobility parameter between the cell 2 and the cell 1 needs to be adjusted.
  • Step 408 The eNB2 sends a mobility update request (MOBILITY CHANGE REQUEST) message to the eNB1, where the message includes the identifier of the cell 2 and the coverage scenario identifier of the cell 2 is 1, the identifier of the cell 1 and the coverage scenario identifier of the cell 1 are 1, to negotiate Adjust the mobility parameter corresponding to cell 2 (covering scenario 1) to cell 1 (covering scenario 1) to reduce premature handover of cell 2 to cell 1.
  • MOBILITY CHANGE REQUEST mobility update request
  • Step 501 The UE switches from the cell 2 to the cell 1, and the current coverage scenario identifier of the cell 2 is carried in the handover request message sent by the eNB (ie, eNB2) to which the cell 2 belongs to the eNB (ie, eNB1) to which the cell belongs.
  • the eNB ie, eNB2
  • the eNB ie, eNB1
  • Step 502 After receiving the handover request message, the eNB1 saves that the coverage scenario identifier of the cell 2 when the UE is handed over is 1, and the current coverage scenario identifier of the cell 1 is 1.
  • Step 503 The UE fails to connect in the cell 1.
  • Step 504 The UE performs an RRC re-establishment attempt in the cell 2.
  • Step 505 After receiving the RRC reestablishment request message, the eNB2 knows that the UE has failed to connect in the cell 1 according to the content in the message, and then sends an RLF INDICATION message to the eNB1.
  • Step 506 After receiving the RLF INDICATION message, the eNB1 may know that the UE has failed to connect in the cell 1 and performs an RRC re-establishment attempt in the cell 2 according to the content in the message. eNBl Querying the saved context, it is found that the UE is tangential to cell 1 by cell 2, and at the time of cell 2 coverage scenario 1, cell 1 coverage scenario 1, then it is determined that this is a secondary cell 2 (at that time coverage scenario 1) ) To the early handover to cell 1 (covering scenario 1 at the time), and send a HANDOVER REPORT message to eNB2 containing the identity of cell 1 and cell 2 and their current coverage scenario identifier.
  • Step 507 After receiving the HANDOVER REPORT message, the eNB2 performs statistical analysis on the detected MRO problem according to different coverage scenarios, and if it is found from the cell 2 (when the scenario 1 is covered) to the cell 1 (when the scenario 1 is covered) If the number of early handovers exceeds the set value within a certain period of time, it is considered that the corresponding mobility parameter between the cell 2 and the cell 1 needs to be adjusted.
  • Step 508 The eNB2 sends a mobility update request (MOBILITY CHANGE REQUEST) message to the eNB1, where the message includes the identifier of the cell 2 and the coverage scenario identifier of the cell 2 is 1, the identifier of the cell 1 and the coverage scenario identifier of the cell 1 are 1, to negotiate Adjust the mobility parameter corresponding to cell 2 (covering scenario 1) to cell 1 (covering scenario 1) to reduce premature handover of cell 2 to cell 1.
  • MOBILITY CHANGE REQUEST mobility update request
  • the present invention is described as follows from the perspective of a base station in conjunction with FIG. 6.
  • the present application further provides a base station 600, where the base station 600 includes:
  • the first receiving module 601 is configured to receive a message, where the message carries an identifier of one or more cells and a coverage scenario identifier corresponding to the cell; the first receiving module 601 receives the message from the terminal or from a neighboring base station, where The message is an RRC connection reestablishment complete message or a UE Information Response message;
  • the processing module 602 is configured to: according to the cell identifier and the coverage scenario identifier carried in the message, the base station analyzes the MO problem in different coverage scenarios according to the cell statistics, and the MO problem detected by the processing module includes a premature handover, a late handover, or Switching to the problem of the wrong cell; when the statistical analysis result of the specific coverage scenario of a certain cell meets the mobility parameter adjustment condition, the base station triggers adjustment of the corresponding mobility parameter; the mobility parameter adjustment condition refers to a certain cell in a certain Coverage field The number of times an MO problem caused by the scene exceeds the set value within a certain period of time.
  • This embodiment provides a method for robustness of a mobile in a multi-coverage scenario.
  • the method embodiment includes the following steps:
  • the UE receives the first message, where the first message information carries the coverage scenario identifier of the currently connected cell of the UE.
  • the manner in which the coverage scenario identifier is carried in the message may be obtained from the radio resource control RRC reconfiguration message or from the system. Obtained in the information broadcast, the UE may save the coverage scene identifier of the serving cell that has recently undergone during the mobile process;
  • the UE sends a second message, where the second message carries the identifier of one or more cells and the coverage scenario identifier of the cell, and the base station analyzes the coverage of the different coverage scenarios according to the received cell identifier and the coverage scenario identifier.
  • the MO problem wherein, the second message may be a UE Information Response message.
  • the embodiment further provides a terminal 700, including: a receiving module 701 and a sending module 702, where:
  • the second receiving module 701 is configured to receive a first message, where the first message carries a coverage scenario identifier of a currently connected cell of the UE;
  • the sending module 702 is configured to send a second message, where the second message carries an identifier of one or more cells and a coverage scenario identifier corresponding to the cell.
  • the manner in which the coverage scenario identifier that is carried by the first message is obtained is obtained from an RRC message or obtained from a system information broadcast.
  • the second message may be a UE Information Response message, where the UE Information Response message includes the RLF Report information, where the RLF Report information includes the identifier of one or more cells saved by the UE and the coverage scenario identifier of the cell pair.
  • the message includes the coverage scenario identifier of the relevant cell, to clarify that the current negotiation is For which coverage scenario is adopted, the accuracy of the mobility parameter negotiation adjustment is improved, and the accuracy of the MRO problem detection and statistical analysis is improved.

Landscapes

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

Abstract

本发明公开了一种多覆盖场景下的移动鲁棒性方法、基站和终端，该方法包括：基站接收消息，所述消息中携带一个或多个小区的标识以及小区对应的覆盖场景标识；所述基站根据消息中携带的小区标识和覆盖场景标识，按小区统计分析不同覆盖场景下的移动鲁棒性优化(MRO)问题；当小区指定覆盖场景的统计分析结果符合移动性参数调整条件时，所述基站触发调整对应的移动性参数。

Description

一种多覆盖场景下的移动鲁棒性方法、 基站和终端 技术领域
本发明涉及通讯领域， 具体涉及一种针对小区支持多种覆盖场景时的 移动鲁棒性优化方法、 装置和系统。 背景技术
为了减少对网络的人工干预， 降低运维成本， 同时提高网络的性能与 稳定性， 第三代伙伴计划 （ Third Generation Partnership Projects, 3 GPP )组 织在演进的通用陆地无线接入网 （ Evolved Universal Terrestrial Radio Access Network, E-UT AN ) 系统开始引入自组织网络（ Self-Organized Network, SON )功能。 E-UTRAN包括演进基站（ evolved Node B， eNB ), 其对应的 核心网（ Core Network, CN )包括移动管理实体 ( Mobile Management Entity, MME )和服务网关 （Serving Gateway, S-GW )等。 eNB和 CN之间通过 S 1接口连接， eNB之间可通过 X2接口连接。 一个 eNB可以管理一个或多 个小区 （Cell )。 SON 包括了移动负荷均衡优化（Mobility Load Balancing optimization, MLB )、 移动鲁棒' 1"生优 4匕 ( Mobility Robustness Optimization, M O )等内容。
M O包括问题检测（主要有过早切换、 过晚切换、 切换到错误小区等 问题）， 对检测到的 MRO问题进行统计分析， 根据统计分析情况（如某一 M O问题的发生次数在一定时间内超过设定值等）对相关的相邻小区间的 移动性参数进行协商调整等 3部分内容，以减少切换失败（ Handover Failure, HOF )或切换相关的无线链路失败（Radio Link Failure, RLF )。 其中的移 动性参数协商调整部分也可用于 MLB， MLB包括负荷信息报告、判断分析、 移动性参数协商调整（或直接选择 UE切换）等 3部分内容。 目前的 MRO 问题解决方案的假设前提是小区的覆盖范围是不变的， 即小区仅有一种覆 盖场景。 然而、 随着节能（ Energy Saving， ES )、 自适应天线系统（ Adaptive Antenna System, AAS )等技术的发展， 小区的覆盖范围可能是会经常变化 的， 即小区可以支持多种覆盖场景。 支持多种覆盖场景的小区是指同一个 小区（即同一个 ECGI: E-UT AN Cell Global Identifier )具有多种覆盖场景， 该小区处在每种覆盖场景时的覆盖范围都是不同的 （如图 1所示）。
因此， 针对小区支持多种覆盖场景时， 如何实现移动鲁棒性优化是本 发明所要描述的内容。 发明内容
有鉴于此， 本发明实施例希望提供一种多覆盖场景下的移动鲁棒性优 化方法， 包括：
基站接收消息， 所述消息中携带一个或多个小区的标识以及小区对应 的覆盖场景标识；
所述基站根据消息中携带的小区标识和覆盖场景标识， 按小区统计分 析不同覆盖场景下的 M O问题，当小区指定覆盖场景的统计分析结果符合 移动性参数调整条件时， 所述基站触发调整对应的移动性参数。
优选地， 所述消息来自终端或来自邻接基站。
优选地， 所述 MRO问题为过早切换、 过晚切换或切换到错误小区。 优选地， 所述移动性参数调整条件指， 小区在覆盖场景下引发的 MRO 问题的次数在指定时间内超过设定值。
本申请还提供了一种基站， 包括：
第一接收模块， 配置为接收消息， 所述消息中携带一个或多个小区的 标识以及小区对应的覆盖场景标识；
处理模块， 配置为所述基站根据消息中携带的小区标识和覆盖场景标 识，按小区统计分析不同覆盖场景下的 M O问题， 当小区指定覆盖场景的 统计分析结果符合移动性参数调整条件时， 所述基站触发调整对应的移动 性参数。
优选地， 所述第一接收模块， 配置为接收的所述消息来自终端或来自 邻接基站。
优选地， 所述处理模块， 配置为检测的 MRO问题为过早切换、 过晚切 换、 切换到错误小区。
优选地， 所述移动性参数调整条件是指， 小区在覆盖场景下引发的 M O问题的次数在指定时间内超过设定值。
所述第一接收模块、 所述处理模块在执行处理时， 可以釆用中央处理 器（CPU, Central Processing Unit ), 数字信号处理器（DSP， Digital Singnal Processor )或可编程逻辑阵列 （ FPGA， Field - Programmable Gate Array ) 实现。
本申请还提供了一种多覆盖场景下的移动鲁棒性方法， 包括： 终端 UE接收第一消息，所述第一消息携带 UE当前连接小区的覆盖场 景标识；
UE发送第二消息， 所述第二消息携带 UE保存的一个或多个小区的标 识以及小区对应的覆盖场景标识。
优选地， 所述第一消息携带的覆盖场景标识获取的方式为以下任意一 种： 从无线资源控制 RRC重配消息中获得； 从系统信息广播中获得。
优选地， 所述第二消息为 UE Information Response消息。
本申请还提供了一种终端， 包括：
第二接收模块， 配置为接收一第一消息，所述第一消息携带 UE当前连 接小区的覆盖场景标识；
发送模块， 配置为发送一第二消息，所述第二消息携带 UE保存的一个 或多个小区的标识以及小区对应的覆盖场景标识。 优选地， 所述第一消息携带的覆盖场景标识获取的方式为以下任意一 种： 从 RRC重配消息中获得； 从系统信息广播中获得。
优选地， 所述第二消息为 UE Information Response消息。
所述第二接收模块、 所述发送模块在执行处理时， 可以釆用中央处理
H ( CPU, Central Processing Unit )、 数字信号处理器（DSP， Digital Singnal
Processor )或可编程逻辑阵列 （ FPGA， Field - Programmable Gate Array ) 实现。
与现有技术相比， 本发明实施例提供的多覆盖场景下的移动鲁棒性方 法、 基站和终端， 在小区支持多种覆盖场景的情形下， 则在消息中包含相 关小区的覆盖场景标识， 以明确当前的协商是针对哪个覆盖场景的， 以提 高移动性参数协商调整的准确性，提高提高 MRO问题检测、统计分析的准 确性。 附图说明
图 1 为小区支持多种覆盖场景的示意图
图 2 为应用实例 RRC连接重建尝试的 MRO流程图；
图 3 为应用实例 RRC连接重建完成后上 LF Report的 MRO流程 图；
图 4 为应用实例 RRC连接建立完成后上 RLF Report的 MRO流程 图；
图 5 为应用实例切换请求带移动性信息的 MRO流程图；
图 6是实施例中基站的结构图；
图 7是实施例中终端的结构图。 具体实施方式
为使本发明的目的、 技术方案和优点更加清楚明白， 下面结合附图和 具体实施例对本发明所述技术方案作进一步的详细描述， 以使本领域的技 术人员可以更好的理解本发明并能予以实施， 但所举实施例不作为对本发 明的限定。 需要说明的是， 在不冲突的情况下， 本申请中的实施例及实施 例中的特征可以相互组合。
在小区支持多种覆盖场景时， 小区将当前覆盖场景的标识通知到用户 设备（UE， User Equipment ), 如通过系统信息广播发给所有 UE， 或通 过无线资源控制 （RRC， Radio Resource Control )重配消息发给某个 UE 等， 以提高 M O问题检测、 统计分析的准确性。
在 UE向小区上报 RLF Report时， 如果针对相关小区保存有当时的覆 盖场景的标识， 则将该标识包含在 LF Report中； 在 UE向小区发送 RRC 连接重建请求消息时， 如果针对相关小区保存有当时的覆盖场景的标识， 则将该标识包含在请求消息中。以提高 M O问题检测、统计分析的准确性。
在 eNB向相邻 eNB发送 RLF INDICATION, HANDOVER REPORT消 息时， 如果相关小区支持多种覆盖场景， 则应在消息中包含相关小区当时 的覆盖场景的标识； 在 eNB向相邻 eNB发送 HANDOVER REQUEST消息 时， 如果相关小区支持多种覆盖场景， 则应在消息中包含相关小区当前的 覆盖场景的标识。 以提高 MRO问题检测、 统计分析的准确性。
在 eNB 向相邻 eNB 发送移动性更新请求 （MOBILITY CHANGE REQUEST )消息时， 如果相关小区支持多种覆盖场景， 则应在消息中包含 相关小区的覆盖场景的标识。 以明确当前的协商是针对哪个覆盖场景的、 以提高移动性参数协商调整的准确性。
结合图 2的本发明的应用实例一描述如下：
步骤 201 : UE连接在小区 1 中， UE从系统信息广播中获得小区 1 当 前的覆盖场景标识为 1。
步骤 202: UE在小区 1中发生了连接失败。 步骤 203: UE在小区 2中进行 RRC重建尝试， 在向小区 2发的 RRC 连接重建请求消息中包含小区 1的标识、 及小区 1的覆盖场景标识为 1。
步骤 204:小区 2收到 RRC重建请求消息后，小区 2所属 eNB(即 eNB2 ) 根据消息中的内容可知道 UE在小区 1中发生了连接失败， 并且当时小区 1 的覆盖场景标识为 1， 于是向小区 1 所属 eNB (即 eNBl )发送 RLF INDICATION消息包含小区 1的标识及小区 1当时的覆盖场景标识为 1、小 区 2的标识及小区 2当前的覆盖场景标识为 1。
步骤 205: eNBl收到 RLF INDICATION消息后根据消息中的内容可知 道 UE在小区 1 (当时处覆盖场景 1 ) 中发生了连接失败并且在小区 2 (当 时处覆盖场景 1 )中进行了 RRC重建尝试。 eNBl查询其保存的上下文， 发 现该 UE是由小区 2切向小区 1的， 于是判定为这是一次从小区 2 (当时处 覆盖场景 1 )到小区 1 (当时处覆盖场景 1 ) 的过早切换， 并向小区 2所属 eNB (即 eNB2 )发 HANDOVER REPORT消息包含小区 1与小区 2的标识 及它们当时的覆盖场景标识。
步骤 206: eNB2收到 HANDOVER REPORT消息后，对检测到的 MRO 问题按不同覆盖场景分别进行统计分析， 如果发现从小区 2 (处覆盖场景 1 时）到小区 1 (处覆盖场景 1时）的过早切换数目在一定时间内超过设定值， 则认为需要调整小区 2与小区 1之间相应的移动性参数。
步骤 207: eNB2向 eNBl发送移动性更新请求（ MOBILITY CHANGE REQUEST ) 消息， 消息包含小区 2的标识及小区 2的覆盖场景标识为 1、 小区 1的标识及小区 1的覆盖场景标识为 1， 以协商调整小区 2 (覆盖场景 1 )到小区 1 (覆盖场景 1 )对应的移动性参数， 以减少小区 2到小区 1的 过早切换。
结合图 3的本发明应用实例二描述如下：
步骤 301 : UE连接在小区 1中， UE从 RRC重配消息中获得小区 1当 前的覆盖场景标识为 1。
步骤 302: UE在小区 1中发生了连接失败。
步骤 303: UE在小区 2中进行 RRC重建成功， 在向小区 2发的 RRC 连接重建完成消息中包含有可用 RLF Report的指示；小区 2收到 RRC连接 重建完成消息中包含的有可用 RLF Report的指示，向 UE发 UE Information Request消息； UE收到 UE Information Request消息后，在向小区 2回的 UE Information Response消息中包含 LF Report信息， RLF Report信息中包含 小区 1的标识、 及小区 1当时的覆盖场景标识为 1。
步骤 304: 小区 2收到 RLF Report信息后，小区 2所属 eNB (即 eNB2 ) 根据其中的内容可知道 UE在小区 1 中发生了连接失败， 并且当时小区 1 的覆盖场景标识为 1， 于是向小区 1 所属 eNB (即 eNBl )发送 RLF INDICATION消息包含小区 1的标识及小区 1当时的覆盖场景标识为 1、小 区 2的标识及小区 2当前的覆盖场景标识为 1。
步骤 305: eNBl收到 RLF INDICATION消息后根据消息中的内容可知 道 UE在小区 1 (当时处覆盖场景 1 ) 中发生了连接失败并且在小区 2 (当 时处覆盖场景 1 ) 中进行了 RRC重建成功， 并发现该 UE是由小区 2切向 小区 1的， 于是判定为这是一次从小区 2 (当时处覆盖场景 1 )到小区 1 (当 时处覆盖场景 1 ) 的过早切换， 并向小区 2 所属 eNB (即 eNB2 ) 发 HANDOVER REPORT消息包含小区 1与小区 2的标识及它们当时的覆盖场 景标识。
步骤 306: eNB2收到 HANDOVER REPORT消息后，对检测到的 MRO 问题按不同覆盖场景分别进行统计分析， 如果发现从小区 2 (处覆盖场景 1 时）到小区 1 (处覆盖场景 1时）的过早切换数目在一定时间内超过设定值， 则认为需要调整小区 2与小区 1之间相应的移动性参数。
步骤 307: eNB2向 eNBl发送移动性更新请求（ MOBILITY CHANGE REQUEST ) 消息， 消息包含小区 2的标识及小区 2的覆盖场景标识为 1、 小区 1的标识及小区 1的覆盖场景标识为 1， 以协商调整小区 2 (覆盖场景 1 )到小区 1 (覆盖场景 1 )对应的移动性参数， 以减少小区 2到小区 1的 过早切换。
结合图 4的应用实例三描述如下：
步骤 401 : UE连接在小区 1 中， UE从系统信息广播中获得小区 1 当 前的覆盖场景标识为 1。
步骤 402: UE在小区 1中发生了连接失败。
步骤 403: UE在小区 2中进行 RRC重建尝试失败后进入空闲态。
步骤 404: UE在小区 4中进行 RRC建立成功， 在向小区 4发的 RRC 连接建立完成消息中包含有可用 RLF Report的指示；小区 4收到 RRC连接 建立完成消息中包含的有可用 RLF Report的指示，向 UE发 UE Information Request消息； UE收到 UE Information Request消息后，在向小区 4回的 UE Information Response消息中包含 LF Report信息， RLF Report信息中包含 小区 1的标识及小区 1当时的覆盖场景标识为 1、小区 2的标识及小区 2当 时的覆盖场景标识为 1。
步骤 405: 小区 4收到 RLF Report信息后，小区 4所属 eNB (即 eNB4 ) 根据其中的内容可知道 UE在小区 1 中发生了连接失败， 并且当时小区 1 的覆盖场景标识为 1， 于是向小区 1 所属 eNB (即 eNBl )发送 RLF INDICATION消息包含小区 1的标识及小区 1当时的覆盖场景标识为 1、小 区 2的标识及小区 2当时的覆盖场景标识为 1。
步骤 406: eNBl收到 RLF INDICATION消息后根据消息中的内容可知 道 UE在小区 1 (当时处覆盖场景 1 ) 中发生了连接失败并且在小区 2 (当 时处覆盖场景 1 ) 中进行了 RRC重建成功， 并发现该 UE是由小区 2切向 小区 1的， 于是判定为这是一次从小区 2 (当时处覆盖场景 1 )到小区 1 (当 时处覆盖场景 1 ) 的过早切换， 并向小区 2 所属 eNB (即 eNB2 ) 发 HANDOVER REPORT消息包含小区 1与小区 2的标识及它们当时的覆盖场 景标识。
步骤 407: eNB2收到 HANDOVER REPORT消息后，对检测到的 MRO 问题按不同覆盖场景分别进行统计分析， 如果发现从小区 2 (处覆盖场景 1 时）到小区 1 (处覆盖场景 1时）的过早切换数目在一定时间内超过设定值， 则认为需要调整小区 2与小区 1之间相应的移动性参数。
步骤 408: eNB2向 eNBl发送移动性更新请求（ MOBILITY CHANGE REQUEST ) 消息， 消息包含小区 2的标识及小区 2的覆盖场景标识为 1、 小区 1的标识及小区 1的覆盖场景标识为 1， 以协商调整小区 2 (覆盖场景 1 )到小区 1 (覆盖场景 1 )对应的移动性参数， 以减少小区 2到小区 1的 过早切换。
结合图 5的本发明应用实例四描述如下：
步骤 501： UE从小区 2切换到小区 1， 在小区 2所属 eNB (即 eNB2 ) 向小区 1所属 eNB (即 eNBl )发的切换请求消息中携带小区 2当前的覆盖 场景标识为 1 。
步骤 502: eNBl收到切换请求消息后保存该 UE切换过来时的小区 2 的覆盖场景标识为 1、 及小区 1当前的覆盖场景标识为 1 。
步骤 503: UE在小区 1中发生连接失败。
步骤 504: UE在小区 2中进行 RRC重建尝试。
步骤 505: 小区 2收到 RRC重建请求消息后， eNB2根据消息中的内容 可知 UE在小区 1中发生了连接失败，于是向 eNBl发送 RLF INDICATION 消息。
步骤 506: eNBl收到 RLF INDICATION消息后根据消息中的内容可知 UE在小区 1中发生了连接失败并且在小区 2中进行了 RRC重建尝试。 eNBl 查询其保存的上下文， 发现该 UE是由小区 2切向小区 1的， 且当时小区 2 处覆盖场景 1、 小区 1处覆盖场景 1， 于是判定为这是一次从小区 2(当时处 覆盖场景 1)到小区 1(当时处覆盖场景 1)的过早切换， 并向 eNB2 发 HANDOVER REPORT消息包含小区 1与小区 2的标识及它们当时的覆盖场 景标识。
步骤 507: eNB2收到 HANDOVER REPORT消息后，对检测到的 MRO 问题按不同覆盖场景分别进行统计分析， 如果发现从小区 2 (处覆盖场景 1 时）到小区 1 (处覆盖场景 1时）的过早切换数目在一定时间内超过设定值， 则认为需要调整小区 2与小区 1之间相应的移动性参数。
步骤 508: eNB2向 eNBl发送移动性更新请求（ MOBILITY CHANGE REQUEST ) 消息， 消息包含小区 2的标识及小区 2的覆盖场景标识为 1、 小区 1的标识及小区 1的覆盖场景标识为 1， 以协商调整小区 2 (覆盖场景 1 )到小区 1 (覆盖场景 1 )对应的移动性参数， 以减少小区 2到小区 1的 过早切换。
为了实现上述方法， 结合图 6， 从基站角度对本发明进行描述如下： 本申请还提供了一种基站 600， 所述基站 600包括：
第一接收模块 601， 配置为接收消息， 所述消息中携带一个或多个小区 的标识以及小区对应的覆盖场景标识； 所述第一接收模块 601 接收所述消 息来自终端或来自邻接基站， 其中所述消息为 RRC 连接重建完成消息或 UE Information Response消息等；
处理模块 602，配置为所述基站根据消息中携带的小区标识和覆盖场景 标识，按小区统计分析不同覆盖场景下的 M O问题， 所述处理模块检测的 M O问题包括过早切换、 过晚切换或切换到错误小区等问题； 当某小区特 定覆盖场景的统计分析结果符合移动性参数调整条件时， 所述基站触发调 整对应的移动性参数； 所述移动性参数调整条件指某个小区在某个覆盖场 景下引发的某个 M O问题的次数在一定时间内超过设定值。
下述实施例从终端角度描述如下： 本实施例提供了一种多覆盖场景下 的移动鲁棒性方法， 本方法实施例包括以下步骤：
UE接收第一消息， 所述第一消息息携带 UE当前连接小区的覆盖场景 标识； 其中， 所述消息携带的覆盖场景标识获取的方式可以为从无线资源 控制 RRC重配消息中获得或从系统信息广播中获得， UE可以在移动过程 中最近经历的服务小区的覆盖场景标识保存下来；
UE发送第二消息， 所述第二消息携带 UE保存的一个或多个小区的标 识以及小区对应的覆盖场景标识， 基站根据接收的小区标识和覆盖场景标 识， 按小区统计分析不同覆盖场景下的 M O问题； 其中， 所述第二消息可 以是 UE Information Response消息。
为了实现上述方法， 结合图 7， 本实施例还提供了一种终端 700， 包括： 接收模块 701和发送模块 702， 其中：
所述第二接收模块 701 配置为接收第一消息， 所述第一消息携带 UE 当前连接小区的覆盖场景标识；
所述发送模块 702， 配置为发送第二消息， 所述第二消息携带 UE保存 的一个或多个小区的标识以及小区对应的覆盖场景标识。
可选地， 所述第一消息携带的覆盖场景标识获取的方式为从 RRC中配 消息中获得或从系统信息广播中获得。
所述第二消息可以为 UE Information Response消息， UE Information Response消息为包含 RLF Report信息， RLF Report信息中包含了 UE保存 的一个或多个小区的标识以及小区对于的覆盖场景标识。
以上所述， 仅为本发明的较佳实施例而已， 并非用于限定本发明的保 护范围。 工业实用性
本发明实施例提供的多覆盖场景下的移动鲁棒性方法、 基站和终端， 在小区支持多种覆盖场景的情形下， 则在消息中包含相关小区的覆盖场景 标识， 以明确当前的协商是针对哪个覆盖场景的， 以提高移动性参数协商 调整的准确性， 提高提高 MRO问题检测、 统计分析的准确性。

Claims

权利要求书
1、 一种多覆盖场景下的移动鲁棒性方法， 所述方法包括：
基站接收消息， 所述消息中携带一个或多个小区的标识以及小区对应 的覆盖场景标识；
所述基站根据消息中携带的小区标识和覆盖场景标识， 按小区统计分 析不同覆盖场景下的移动鲁棒性优化 MRO问题；
当小区指定覆盖场景的统计分析结果符合移动性参数调整条件时， 所 述基站触发调整对应的移动性参数。
2、 如权利要求 1所述的多覆盖场景下的移动鲁棒性方法， 其中， 所述 消息来自终端或来自邻接基站。
3、 如权利要求 1所述的多覆盖场景下的移动鲁棒性方法， 其中， 所述 M O问题为过早切换、 过晚切换或切换到错误小区。
4、 如权利要求 1所述的多覆盖场景下的移动鲁棒性方法， 其中， 所述 移动性参数调整条件指，小区在覆盖场景下引发的 M O问题的次数在指定 时间内超过设定值。
5、 一种基站， 所述基站包括：
接收模块， 配置为接收消息， 所述消息中携带一个或多个小区的标识 以及小区对应的覆盖场景标识；
处理模块， 配置为所述基站根据消息中携带的小区标识和覆盖场景标 识，按小区统计分析不同覆盖场景下的移动鲁棒性优化 M O问题， 当小区 指定覆盖场景的统计分析结果符合移动性参数调整条件时， 所述基站触发 调整对应的移动性参数。
6、 如权利要求 5所述的基站， 其中， 所述接收模块， 还配置为接收的 所述消息来自终端或来自邻接基站。
7、 如权利要求 5所述的基站， 其中， 所述处理模块， 还配置为检测的 M O问题为过早切换、 过晚切换、 切换到错误小区。
8、 如权利要求 5所述的基站， 其中， 所述移动性参数调整条件为： 小 区在覆盖场景下引发的 M O问题的次数在指定时间内超过设定值。
9、 一种多覆盖场景下的移动鲁棒性方法， 所述方法包括：
终端 UE接收第一消息，所述第一消息携带 UE当前连接小区的覆盖场 景标识；
UE发送第二消息， 所述第二消息携带 UE保存的一个或多个小区的标 识以及小区对应的覆盖场景标识。
10、 如权利要求 9所述的多覆盖场景下的移动鲁棒性方法， 其中， 所 述第一消息携带的覆盖场景标识获取的方式为以下任意一种：
从无线资源控制 RRC重配消息中获得；
从系统信息广播中获得。
11、 如权利要求 9 所述的多覆盖场景下的移动鲁棒性方法， 其中， 所 述第二消息为 UE Information Response消息。
12、 一种终端， 所述包括：
接收模块， 配置为接收第一消息， 所述第一消息携带 UE当前连接小区 的覆盖场景标识；
发送模块， 配置为发送第二消息， 所述第二消息携带 UE保存的一个或 多个小区的标识以及小区对应的覆盖场景标识。
13、 如权利要求 12所述的终端， 其中，
所述第一消息携带的覆盖场景标识获取的方式为以下任意一种： 从 RRC重配消息中获得；
从系统信息广播中获得。
14、如权利要求 12所述的终端，其中，所述第二消息为 UE Information Response消息。
PCT/CN2014/077404 2014-01-27 2014-05-13 一种多覆盖场景下的移动鲁棒性方法、基站和终端 WO2015109691A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201410040829.4A CN104811967B (zh) 2014-01-27 2014-01-27 一种多覆盖场景下的移动鲁棒性优化方法、基站和终端
CN201410040829.4 2014-01-27

Publications (1)

Publication Number Publication Date
WO2015109691A1 true WO2015109691A1 (zh) 2015-07-30

Family

ID=53680723

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2014/077404 WO2015109691A1 (zh) 2014-01-27 2014-05-13 一种多覆盖场景下的移动鲁棒性方法、基站和终端

Country Status (2)

Country Link
CN (1) CN104811967B (zh)
WO (1) WO2015109691A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107708160A (zh) * 2016-08-09 2018-02-16 中兴通讯股份有限公司 一种过早切换的检测方法及装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101932015A (zh) * 2009-06-19 2010-12-29 中兴通讯股份有限公司 切换参数调整方法及装置
CN102111780A (zh) * 2009-12-25 2011-06-29 中兴通讯股份有限公司 覆盖漏洞检测的实现方法、系统及基站
CN102264108A (zh) * 2010-05-25 2011-11-30 电信科学技术研究院 一种移动性参数的调整方法及设备
WO2013066237A1 (en) * 2011-11-04 2013-05-10 Telefonaktiebolaget L M Ericsson (Publ) Methods and network nodes for detecting short stay handover

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE602004021646D1 (de) * 2004-11-03 2009-07-30 Nokia Corp Inter-system-weiterreichung eines mobilen endgeräts, das mit einem ersten und zweiten funkzugangsnetz betreibbar ist
CN101527947B (zh) * 2008-03-06 2013-01-23 上海贝尔阿尔卡特股份有限公司 无线中继网络中为移动终端选择通信路径的方法和装置
CN101808354B (zh) * 2010-03-09 2012-12-26 西安电子科技大学 基于移动终端信息检测切换失败场景的方法
CN103167570B (zh) * 2011-12-19 2015-06-17 中国科学院声学研究所 一种室内蜂窝网络网中的切换触发与判决方法及系统
CN103476079B (zh) * 2013-09-23 2016-09-07 大唐移动通信设备有限公司 用于无线网络的切换控制方法以及切换控制装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101932015A (zh) * 2009-06-19 2010-12-29 中兴通讯股份有限公司 切换参数调整方法及装置
CN102111780A (zh) * 2009-12-25 2011-06-29 中兴通讯股份有限公司 覆盖漏洞检测的实现方法、系统及基站
CN102264108A (zh) * 2010-05-25 2011-11-30 电信科学技术研究院 一种移动性参数的调整方法及设备
WO2013066237A1 (en) * 2011-11-04 2013-05-10 Telefonaktiebolaget L M Ericsson (Publ) Methods and network nodes for detecting short stay handover

Also Published As

Publication number Publication date
CN104811967B (zh) 2019-08-30
CN104811967A (zh) 2015-07-29

Similar Documents

Publication Publication Date Title
US10986546B2 (en) Method, apparatus, and system for detecting a radio network problem
US10433188B2 (en) Control apparatus, base station apparatus, radio terminal, and method for updating neighbour relation table
EP3138327B1 (en) Methods and apparatuses for transmitting a handover report and an rlf report
JP5815140B2 (ja) 強化型接続リカバリの方法
EP2720487B1 (en) Cell information reporting
US10342066B2 (en) Method and apparatus for dual connectivity management
WO2013071856A1 (zh) 一种无线链路失败统计方法和相关装置及通信系统
WO2010121553A1 (zh) 小区间的重选参数和切换参数匹配的判断方法及装置
US20210314823A1 (en) Method for supporting indication of a failure event to a source access system
EP2512179A1 (en) Method for determining reason for too late handover to home base station
JP2013541287A (ja) ハンドオーバ失敗の処理方法及びユーザ装置
WO2011026366A1 (zh) 一种宏小区到家庭基站小区的切换方法及系统
WO2015109691A1 (zh) 一种多覆盖场景下的移动鲁棒性方法、基站和终端
CN116489673A (zh) 信息报告方法以及用户设备
WO2012013100A1 (zh) 一种用户设备及其上报rlf相关测量信息的方法
WO2024067624A1 (zh) 信息报告方法以及用户设备
WO2023005967A1 (zh) 切换信息报告方法以及用户设备
CN118042643A (zh) 信息报告方法以及用户设备
AU2014200751A1 (en) Method, apparatus and system for detecting a radio network problem
CN117395732A (zh) 切换信息报告方法以及用户设备
WO2013051984A1 (en) Accessibility measurements

Legal Events

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

Ref document number: 14879733

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14879733

Country of ref document: EP

Kind code of ref document: A1