WO2009082839A1

WO2009082839A1 - A method for guaranteeing route set data consistency in ultra mobile broadband system

Info

Publication number: WO2009082839A1
Application number: PCT/CN2007/003838
Authority: WO
Inventors: Gang Chen; Wanshuai Zhang; Zihua Xu; Zhiwei Peng
Original assignee: Zte Corporation
Priority date: 2007-12-27
Filing date: 2007-12-27
Publication date: 2009-07-09
Also published as: CN101796792B; CN101796792A

Abstract

A method for guaranteeing route set data consistency in Ultra Mobile Broadband (UWB) system is disclosed. In the method, an evolution base station eBS in the Route Set of the terminal AT sends a RouteMap request to the terminal AT for getting RouteMap data; when the AT receives the RouteMap request, it returns a RouteMap message which bears the current last RouteMap data to the eBS; after the eBS receives the RouteMap message, it compares the RouteMap data before the RouteMap request with the RouteMap data after the RouteMap request; if the two data not consistent, the eBS triggers initiatively the AT to broadcast the RouteMap message that bears the current last RouteMap data of the AT again to all the members in the Route Set. By optimizing the process flow for RouteMapRequest message, Route Set data is always consistent between eBSs, so the consistency in the access network for Route Set information of AT is improved and maintained.

Description

Method for guaranteeing data consistency of route collection in super mobile broadband system

Technical field

The present invention relates to a mobile communication technology, and in particular to a method for ensuring consistency of route set information in an Ultra Mobile Broadband (UMB) system.

Background technique

In a UMB system, when a pilot of an extended base station (eBS, extended base station) is located in an active set of an terminal (AT, Access Terminal), there is a route of the eBS corresponding thereto. ( Route ) is located in the route set of the AT, and in the eBS, there is also a Route corresponding to the AT. From the perspective of the AT, a Route refers to an instance of a protocol stack corresponding to an eBS, and communication between the AT and the eBS is performed between pairs of Route instances located in the AT and the eBS, respectively. When the AT and the multiple eBSs have an interaction relationship, the route instances of all eBSs form a route set (Route Set). In the Route Set, a Route is represented on the data organization as: <RouteID, ANID> binary relation mapping table. RoutelD is assigned by the AT when the Route is created, and the ANID belongs to the configuration data, which contains the IP address information of the eBS. The entire Route Set is saved using a route map ( RouteMap ), and each record in the table corresponds to a Route.

In a UMB system, there are at most two eBSs that interact with the AT air interface: FLSE (forward link service eBS) and RLSE (reverse link service eBS), which carry forward and reverse air interface messages and data, respectively. The interaction between other eBS and AT needs to be tunneled over the IP layer through FLSE and RLSE. The acquisition of the communication IP address between eBS depends on the eBS correctly acquiring the Route Set information of the AT. From the Route Set information. The ANID of each eBS is used to obtain an IP address. In the air interface message of the UMB system, the AT synchronizes the Route Set data in the access network by sending RouteMap information to the eBS located in its Route Set. The transmission of RouteMap information will occur in the following two situations:

1 180700254 1. The Add or Delete operation occurs in the Route Set. At this time, the AT broadcasts the RouteMap message to all eBS members in the Route Set, and updates the Route Set data synchronously in the access network.

2. An eBS located in the AT's Route Set actively sends a RouteMap request message to the AT. At this time, the AT only returns the RouteMap information to the eBS that sent the request.

As shown in Figure 1, the process is as follows:

Step 101: The eBS sends a RouteMap request message to the AT.

In step 102, the AT returns the RouteMap data to the eBS.

The problem with this process is: If there is a change in the RouteSet of the AT, there will be two cases when the new RouteMap message is broadcast to the eBS. The first is that the eBS has not received the latest RouteMap message (for example, because of a link failure), The second type is when the eBS obtains the latest RouteMap data through the RouteMap request message (for example, after the link is restored), so that the RouteMap data obtained after the routeMap request is sent is inconsistent with the RouteMap data before the request is sent, and this means the RouteSet of the AT. Data may be inconsistent in the access network, which may cause failure of FLSE/RLSE handover and abnormal communication between eBS. Summary of the invention

The technical problem to be solved by the present invention is to provide a method for guaranteeing the consistency of Route set data in a UMB system. By optimizing the RouteMapRequest message processing flow, the problem that the Route Set data is inconsistent between eBSs is solved.

The technical solutions are as follows:

A method for guaranteeing consistency of route collection data in a super mobile broadband system, the steps comprising:

(1) The route set of the terminal AT An enhanced base station eBS in the Route Set sends a route map RouteMap request to the terminal AT to obtain the RouteMap data;

(2) returning, after the AT receives the RouteMap request, a RouteMa message to the eBS, where the AT currently carries the latest RouteMap data of the AT;

(3) After receiving the RouteMap message, the eBS compares the RouteMap data saved before the RouteMap request with the RouteMap data carried in the currently received RouteMap message, and when the eBS is inconsistent, the eBS actively triggers the AT re-routes to its Route Set

2 180700254 All members in the eBS broadcast the RouteMap message;

(4) The AT broadcasts a RouteMap message to all member eBSs in the Route Set, where the AT currently carries the latest RouteMap data of the AT.

Further, in the step (1), the RouteMap request message sent by the eBS to the AT includes a UnicastOrBroadcast field, and the value of the UnicastOrBroadcast field is used to indicate that the RouteMap request message is separately requested to acquire RouteMa data.

Further, in step (3), the eBS triggers the AT to re-send a RouteMap message to all member eBSs in its Route Set by using a RouteMap request message sent to the AT, where the value of the UnicastOrBroadcast field is used to indicate the location. The AT broadcasts the RouteMap data to all member eBSs in the Route Set.

Further, in step (1), when the UnicastOrBroadcast=0, the RouteMap message indicating the response as the RouteMap request message only needs to be separately sent to the requester.

Further, in step (3), when UnicastOrBroadcast=l, the AT is instructed to broadcast RouteMap data to all member eBSs in the Route Set.

Further, in step (3), when it is found that the RouteMap data saved before the RouteMap request is consistent with the RouteMap data carried in the currently received RouteMap message, the eBS does not process, and the process ends.

The correctness of the Route Set information is one of the foundations of the FMX/RLSE handover of the UMB system and the routing communication between the eBS. The present invention proposes an improvement on the processing flow of the RouteMap request message, and solves the above-mentioned existing Route Set by optimizing the RouteMapRequest message processing flow. The inconsistency between the data in the eBS, through the above-mentioned path of the invention, improves and maintains the consistency of the AT's Route Set information in the access network. BRIEF abstract

1 is a schematic diagram of a UMB RouteMap request flow in the prior art;

2 is a flow chart of the improved UMB RouteMap request in the present invention;

3 is a flow chart of a preferred embodiment of the improved UMB RouteMap request flow in the present invention.

3 180700254 Preferred embodiment of the invention

In the UMB air interface message definition, the RouteMap request message is RouteMapRequest, and the RouteMap data is requested through the RouteMap request message. In the technical solution of the present invention, after a certain eBS sends a RouteMap request message to obtain the latest RouteMap information of the AT, it compares whether the RouteMap data before and after the request is consistent. If an inconsistency is found, the AT is notified and the AT is triggered again to all the Route Sets. The member eBS broadcasts the latest RouteMap data and re-synchronizes the Route Set data in the access network.

As shown in Figure 2, the flow chart of the improved UMB RouteMap request is described in detail below with reference to the accompanying drawings.

Step 201: The eBS 1 is located in the Route Set of the AT, and sends a RouteMap request to the AT to obtain the RouteMap data.

Step 202: After receiving the RouteMap request, the AT returns a RouteMap message to the eBS1, where the AT carries the latest RouteMap data of the AT;

Step 203: After receiving the RouteMap message, the eBS1 compares the RouteMap data saved before the RouteMap request with the RouteMap data carried in the RouteMap message just received, and checks whether the RouteMap data is consistent. If not, proceed to step 204. When it is found that the RouteMap data saved before the RouteMap request is consistent with the RouteMap data carried in the currently received RouteMap message, the eBS does not process, and the process ends;

After eBS1 obtains the RouteMap data by sending a RouteMap request to the AT, if the eNode1 finds that the obtained RouteMap data is inconsistent with the RouteMap data saved before the RouteMap request, it indicates that the Routemap data may be inconsistent on the access network side (or In the case of unsynchronized), the eBS1 will actively trigger the AT to perform the full-route RouteMap data synchronization.

Step 204, the eBS1 notifies the AT to re-broadcast to all members of the Route Set eBS

RouteMap message, and carries the current latest RouteMap data of AT;

Step 205: The AT broadcasts a RouteMap message to all members of the Route Set eBS, and carries the latest RouteMap data of the AT.

4 180700254 Any eBS extracts the RouteMap data to the AT when it is needed. If the inconsistency is found, there may be inconsistency in the entire site RouteMap data. Compared with the whole network, the repeated check of an eBS should not be a problem. After the above processing, the AT's Route Set data can maintain data consistency in the access network.

As shown in Table 1, it is a schematic diagram of the format modification of the UMB RouteMapRequest message in the embodiment. Table 1 below describes the modified UMB RouteMapRequest message in detail.

Table 1

a: original RouetMapRequest message format b: new RouteMapRequest message format

Modified UMB air interface RouteMapRequest message format adds a field

UnicastOrBroadcast, this field is used to indicate whether RouteMapRequest is an eBS requesting to obtain RouteMap data separately, or to require AT to broadcast RouteMap data to all members eBS in the Route Set. When UnicastOrBroadcast=0, it indicates that the RouteMap message responding to the RouteMapRequest message only needs to be sent to the requester separately. When UnicastOrBroadcast=l, it indicates that the AT needs to broadcast the RouteMap message to all members of the Route Set eBS.

As shown in Fig. 3, it is a flow chart of the UMB RouteMap request in the preferred embodiment. The UMB RouteMap request flow in the preferred embodiment will be described in detail below with reference to the accompanying drawings.

Step 301: The eBS1 is located in the Route Set of the AT, and the eBS1 sends a RouteMapRequest request message to the AT, where the request message is UnicastOrBroadcast=0, and the response RouteMap message only needs to be separately sent to the requester eBS1;

If UnicastOrBroadcast=l, it indicates that the AT needs to broadcast the RouteMap message to all members of the Route Set eBS. Step 302: After receiving the RouteMapRequest request message, the AT returns a RouteMap message to the eBS1, where the AT carries the latest RouteMap data of the AT;

5 180700254 Step 303: After receiving the RouteMap message, the eBS1 compares whether the RouteMap data before and after the request is consistent. If not, the process proceeds to step 304. When comparing the RouteMap data saved before the RouteMapRequest request message and the currently received RouteMap message, When the carried RouteMap data is consistent, the eBS does not process, and the process ends; in step 304, the eBS1 sends a RouteMapRequest request message to the AT, where the message is UnicastOrBroadcast=l, and the AT is notified to re-route the RouteMap data to all member eBSs in the Route Set;

Step 305: The AT broadcasts a RouteMap message to all member eBSs in its Route Set, and transmits the current latest RouteMap data of the AT to all eBSs.

Industrial applicability

The present invention improves the processing flow of the RouteMap request message. By optimizing the RouteMapRequest message processing flow, the Route Set data is always consistent among the eBSs, and the consistency of the AT Route Set information in the access network is improved and maintained.

6 180700254

Claims

Claim

1. A method for guaranteeing consistency of route collection data in a super mobile broadband system, the steps comprising:

(2) After receiving the RouteMap request, the AT returns a RouteMap message to the eBS, where the AT is currently carrying the latest RouteMap data;

(3) After receiving the RouteMap message, the eBS compares the RouteMap data saved before the RouteMap request with the RouteMap data carried in the currently received RouteMap message, and when the eBS is inconsistent, the eBS actively triggers the The AT re-sends the RouteMap message to all member eBSs in its Route Set;

The method according to claim 1, wherein in the step (1), the RouteMap request message sent by the eBS to the AT includes a UnicastOrBroadcast field, and the

The value of the UnicastOrBroadcast field is used to indicate that the RouteMap request message is a separate request to obtain RouteMap data.

The method according to claim 2, wherein in step (3), the eBS triggers the AT to re-route the RouteMap message to all member eBSs in its Route Set by using a RouteMap request message sent to the AT. The value of the UnicastOrBroadcast field is used to indicate that the AT broadcasts RouteMap data to all member eBSs in the Route Set.

The method according to claim 2, wherein in step (1), when the UnicastOrBroadcast=0, the RouteMap message indicating the response as the RouteMap request message only needs to be separately sent to the requester.

5. The method according to claim 3, wherein in step (3),

When UnicastOrBroadcast-1, the AT is instructed to broadcast RouteMap data to all member eBSs in the Route Set.

6. The method according to claim 1, wherein in step (3), when

7 180700254 When it is found that the RouteMap data saved before the RouteMap request is consistent with the RouteMap data carried in the currently received RouteMap message, the eBS does not process, and the process ends.

8 180700254