CN100459813C - Method for obtaining service failure reason in heterogeneous network - Google Patents

Abstract

The key ideal of the invention is: when the bottom layer entity transaction failures, the bottom layer entity reports the failure transaction and its reason information to the upper layer entity; according to the reported information, the upper layer entity gets the failure transaction and its reason. By the invention, the upper layer entity can select appropriate processing modes according to the different failure reasons.

Description

Method for Obtaining the Cause of Transaction Failure in Heterogeneous Network

technical field

The invention relates to the communication field, in particular to acquisition of transaction failure reasons in a heterogeneous network.

Background technique

With the development of communication technology, various new network technologies continue to emerge. In order to ensure the communication quality of terminals when switching and roaming among heterogeneous networks such as IEEE 802.11, IEEE 802.15, IEEE 802.16, 3GPP, and 3GPP2, IEEE The 802 wireless working group established the IEEE 802 switching research group - Handoff ECSG, which was later officially named the IEEE 802.21 working group. It enables client devices to automatically select the most cost-effective network connection type and access point when roaming or switching between networks, and can achieve seamless switching without user intervention. It supports switching between heterogeneous networks. User experience for mobile devices.

The implementation architecture of the 802.21 protocol is shown in Figure 1, and its coverage includes:

1. Define a mobile node (MN) architecture that can provide transparent continuity services during heterogeneous link layer handover. The architecture is based on the mobility management protocol stack that supports handover in network elements. The 802.21 protocol does not include architectural implementation details and guidance on preferred implementations.

2. A group of handover-related functions and a new entity are defined in the mobility management protocol stack, namely the Media Independent Handover Function (MIHF) entity.

3. Defines additional MAC layer SAPs and related primitives for each specific access technology, which helps to collect link layer information and control link behavior during handover.

4. Define a set of media-independent service access points (SAPs) and related primitives for accessing MIHF, including:

(1) Media-independent information service, which provides an information model and an information base to effectively make handover decisions.

(2) Media-independent command service, which is used for users to issue commands to control handover-related link behaviors.

(3) Media-independent event service, which includes events and triggers generated by local and remote interfaces.

The upper layers of the MIH make handover decisions and link selection based on input and context from the MIH.

The MIHF provides mobility support for mobile nodes and logical layers in the mobility management protocol stack of network elements, which assist and facilitate the handover decision process. Simplifying the identification of handover occurrence conditions and the discovery of effective handover information are key objectives of MIHF. MIHF provides high-level abstract services, and provides a set of well-defined interfaces. The service primitives exposed by these interfaces are independent of specific access technologies; to communicate.

At present, the Media Independent Handover Function (MIHF) entity mainly assists and promotes the seamless handover of terminals between heterogeneous networks through media-independent event services, media-independent command services, and media-independent information services, reducing handover delay and data loss, and enhancing user experience. The media-independent event service supports local events and remote events of the same media type. Remote events between different media stacks are not supported. The local event refers to: the MIH propagated by the L2 data link layer (MAC or wireless link, etc.) to the local protocol stack or transmitted by the local MIH to the local L3MP (Layer 3 Mobility Management Protocol). The local protocol stack may be located at the mobile terminal side or at an access point such as an AP or a BS at the network side. The remote event refers to propagation from the MIH or L3MP to the MIH or L3MP layer at the opposite end.

The event can be used to indicate the change of the transmission behavior of the L2 data link layer or the transition of the predicted state, or indicate the management behavior or command of the network side. The more important events are: Link_Up (link establishment), Link_Down (link disconnection), Link_Going_Down (link will be disconnected), Link_Handover_Imminient (link switching start), Link_Parameters_Change (link layer parameter change), etc. The source of the event includes the L2 data link layer, PHY or MIHF. According to different sources, events can be further divided into: Link events (events whose source is the MIH lower layer) and MIH events (events whose source is the MIHF layer). The destination of the Link event includes the MIH of the local protocol stack and/or the MIH of the remote protocol stack, etc.; the destination of the MIH event includes the local and/or remote layer 3, or other upper layer entities. The destination end of the event adopts a dynamic registration mechanism, such as registering a specific event of interest through Link_Event_Register.request (link event registration request) and Link_Event_Register.confirm (link event registration confirmation) messages. Before initiating an event registration request, the event destination needs to obtain a list of Link events and a list of MIH events. At present, the destination of the event mainly obtains the Link event list through Link_Event_Discover.request (link event discovery request) and Link_Event_Discover.confirm (link event discovery confirmation) messages, and through MIH_Capability_Discover.request (MIH capability discovery request) and MIH_Capability_Discover.confirm (MIH Capability Discovery Confirm) message to obtain a list of MIH events.

The prior art related to the present invention describes the discovery, registration and deregistration process of local events, as shown in Figure 2:

First, the upper-level entity requests the supported events from the underlying entity through the Event_Discover.request (event discovery request) message, and the underlying entity transmits the events it supports to the upper-level entity through the Event_Discover.confirm (event discovery confirmation) message, and then the upper-level entity passes Event_Register .request (event registration request) and Event_Register.confirm (event registration confirmation) messages to register interested events, or through Event_Deregister.request (event deregistration request) and Event_Deregister.confirm (event deregistration confirmation) messages to register events to log out. When an event occurs in the underlying entity, the underlying entity notifies the upper layer entity through Link_Event.indiction (link event indication) and MIH_Event.indiction (MIH event indication) messages.

In the prior art, the upper-level entities of the system can receive media-independent event services only after registering the events of the lower-level entities. The registration of upper-level events is divided into MIH event registration and Link event registration. The event registration process is as follows: first, the upper-level entity of the system, such as MIH User, sends a MIH_Event_Register.request (MIH event registration request) message to the MIH layer, and then the MIH layer passes Link_Event_Register The .request (link event registration request) message initiates an event registration request to the underlying entity, and the underlying entity confirms the registered event and its status to the MIH layer through the Link_Event_Register.confirm (link event registration confirmation) message, and the MIH layer then passes The MIH_Event_Register.confirm (MIH event registration confirmation) message notifies the upper layer entity of the event registration, such as MIH User (MIH user). The Link_Event_Register.confirm message and the MIH_Event_Register.confirm message only include EventSource (the location where the underlying entity generates the event) and ResponseEventList (event list) information elements, but do not include the failure reason for the failure of the registration event, so the MIH User cannot register the event according to the Causes of failure to be dealt with reasonably. In summary, it can be seen that the prior art has the following defects:

The upper-layer entity of the system cannot obtain the failure reason of the registration event failure, so the upper-layer entity cannot make reasonable processing according to the reason of the registration event failure.

Contents of the invention

The purpose of the present invention is to provide a method for obtaining the reasons for transaction failures in a heterogeneous network. When the underlying entity registration event or logout event fails, the upper layer entity of the system can obtain the failure reasons of these failed transactions, so that it can be based on different The cause of the failure can be determined, and a reasonable processing method can be selected to improve the switching efficiency of the system.

The purpose of the present invention is achieved through the following technical solutions:

The present invention provides a method for obtaining the cause of transaction failure in a heterogeneous network, which includes:

A. When the underlying entity of the system fails to process a transaction, the underlying entity reports the failed transaction and the failure reason information of the failed transaction to the upper entity;

B. The upper-layer entity obtains the failed transaction and the failure reason of the failed transaction according to the information reported by the lower-layer entity.

Wherein, the step A specifically includes:

A1. When the underlying entity of the system fails to process a transaction, the underlying entity reports the failed transaction and the failure reason information of the transaction to the MIH layer entity;

A2. The MIH layer entity transmits the failed transaction and failure cause information of the transaction to the upper layer entity.

Wherein, the step A1 specifically includes:

When the underlying entity of the system fails to register an event, the underlying entity reports the registration failure event and the corresponding failure reason information to the MIH layer entity through the Link_Event_Register.confirm message;

or,

When the underlying entity of the system fails to deregister the event, the underlying entity reports the deregistration failure event and the corresponding failure reason information to the MIH layer entity through the Link_Event_Deregister.confirm message.

Wherein, the step A2 specifically includes:

After the MIH layer entity receives the information reported by the bottom layer entity of the system, the MIH layer entity reports the registration or deregistration failure event and the corresponding failure reason information to the upper layer entity through the MIH_Event_Register.confirm message or MIH_Event_Deregister.confirm message.

Wherein, the Link_Event_Register.confirm message, Link_Event_Deregister.confirm message, MIH_Event_Register.confirm message or MIH_Event_Deregister.confirm message includes:

The ReasonFailEventList parameter for the failure to register an event or unregister an event.

Wherein, the ReasonFailEventList parameters include:

The failure reason information corresponding to the registration event failure transaction or the failure reason information corresponding to the logout event failure transaction.

Wherein, the Link_Event_Register.confirm message or MIH_Event_Register.confirm message also includes:

A transaction, an event source corresponding to the transaction, and execution result information of the transaction, the transaction includes a registration event or a logout event.

Wherein, the step B also includes:

The upper entity processes the failed transaction according to different reasons for the failure of the failed transaction.

As can be seen from the technical solution provided by the present invention above, when the transaction in the underlying entity of the system fails in the present invention, the underlying entity reports the failed transaction and the failure cause information of the failed transaction to the upper-level entity; The information reported by the entity acquires the failed transaction and the failure reason of the failed transaction. When the underlying entities fail to register events or logout events, the upper-level entities of the system can obtain the failure reasons of these failed transactions, so that they can choose a reasonable processing method according to different failure reasons, thereby improving the switching efficiency of the system.

Description of drawings

Figure 1 is a schematic diagram of the implementation architecture of the 802.21 protocol;

Fig. 2 is the process of discovery, registration and deregistration of local events in the prior art;

Fig. 3 is a flow chart of the first embodiment provided by the present invention.

Detailed ways

The present invention provides a method for obtaining the cause of transaction failure in a heterogeneous network, the core of which is: when the transaction fails in the bottom entity of the system, the bottom entity reports the failed transaction and the cause information of the transaction failure to the upper entity; The upper-layer entity obtains the failed transaction and the failure reason of the failed transaction according to the information reported by the lower-layer entity.

The main idea of the first embodiment provided by the present invention is: by carrying in the Link_Event_Register.confirm message and MIH_Event_Register.confirm message of the prior art the parameter ReasonFailEventList indicating that the registration event failed, the transaction failed, so that the upper-level entity obtains the transaction failure of the bottom-level entity The reasons, the process is still shown in Figure 3, including:

Step 1. The upper entity of the system sends MIH_Capability_Discover.request (MIH capability discovery request) to the MIH layer, and then the MIH layer initiates a capability discovery request to the underlying entity through a Link_Event_Discover.request (link event discovery request) message.

Step 2, the underlying entity reports its supported event information to the MIH entity through the Link_Event_Discover.confirm (link event discovery confirmation) message, and the MIH entity reports relevant information to the upper layer entity through the MIH_Capability_Discover.confirm (MIH capability discovery confirmation).

Step 3, when the upper layer entity of the system decides to register the event of interest according to the event situation reported by the underlying entity, it sends MIH_Event_Register.request (MIH event registration request) to the MIH layer, and then the MIH layer passes Link_Event_Register.request (link event registration request) message to initiate an event registration request to the underlying entity.

Step 4, the underlying entity reports the execution status of the event registration and the failure reason of the corresponding failed transaction to the MIH layer through the Link_Event_Register.confirm (link event registration confirmation) message, and the MIH layer then passes the MIH_Event_Register.confirm (MIH event registration confirmation) message Notify the upper layer entity of the information, such as MIH User (MIH User).

In this step, when the underlying entity of the system fails to register an event, the underlying entity sends the transaction, the event source of the transaction, the execution result information of the transaction, and the failure reason of the corresponding failed transaction through the Link_Ever_Register.confirm message and other information are reported to the MIH layer entity. After the MIH layer entity receives the information reported by the bottom layer entity of the system, the MIH layer entity transmits the relevant information to the upper layer entity through the MIH_Ever_Register.confirm message. The Link_Ever_Register.confirm message and the MIH_Ever_Register.confirm message include parameters of EventSource (event source), ResponseEventList (event response list) and ReasonFailEventList (registration event failure reason list).

The EventSource parameter records the location where the bottom layer generates the event. The ResponseEventList parameter records the event list and the execution result of the transaction, such as the registration result, and the definition of the event list is as shown in Table 1:

name value ResponseEventList For each bit, when the bit is 1, it means that the corresponding event registration is successful Bit #0: Link UpBit #1: Link DownBit #2: Link Going DownBit #3: Link DetectedBit #4: Link Parameters ChangeBit #5: Link Event RollbackBit #6: Link SDU Transmit SuccessBit #7: Link SDU Transmit FailureBit #8~31: Reserved

Table 1

It can be seen from Table 1 that each bit in the event list represents the execution result of the transaction, such as the success or failure of the registration result and other related information. When the transaction execution result is successful, this bit is set to 1; when the transaction execution result is failure, this bit is set to 0.

Among them, the ReasonFailEventList parameter represents the failure reason of the failed transaction, and the definition of the table is shown in Table 2:

FailCount ReasonId【1】 … ReasonId【FailCount】

Table 2

In Table 2, FailCount indicates the number of failed transactions, and the value range corresponds to the number of events defined by ResponseEventList. Reasonld is the failure reason of failed transactions in ResponseEventList, arranged in order, and its type can be bytes or other types.

In addition to the structure described in Table 2, the ReasonFailEventList parameter can also adopt other data structures, and can also be integrated into the ResponseEventList parameter. Its essence is to explain the cause of failure for each failed transaction.

Similarly, when the upper-layer entity of the system decides to initiate a deregistration of an uninterested event based on the event situation reported by the underlying entity, then perform step 5, that is, send a MIH_Event_Deregister.request (MIH event deregister request) to the MIH layer, and then the MIH layer passes Link_Event_Deregister The .request (link event logout request) message initiates an event logout request to the underlying entity.

Step 6, the underlying entity reports to the MIH layer the execution result of the event cancellation transaction and the failure reason of the corresponding cancellation event failure transaction to the MIH layer through the Link_Event_Deregister.confirm (link event deregister confirmation) message, and the MIH layer then passes the MIH_Event_Deregister.confirm( The MIH event logout confirmation) message notifies the upper layer entity of the information, such as MIH User (MIH user).

The Link_Event_Deregister.confirm and MIH_Event_Deregister.confirm messages also include the information in step 4, which will not be described in detail here.

Afterwards, the upper entity processes the transaction according to different failure reasons of the failed transaction reported by the bottom entity. For example, assuming that the event registration transaction fails because the transaction source supporting the event registration transaction does not exist, then the upper entity will cancel the event registration transaction and enable other switching strategies; if the event registration transaction fails The reason is due to interference or other reasons, then the upper entity may choose to re-register, and so on. In this way, the system can work more reasonably and effectively, thereby improving the switching efficiency of the system.

The above is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art within the technical scope disclosed in the present invention can easily think of changes or Replacement should be covered within the protection scope of the present invention. Therefore, the protection scope of the present invention should be determined by the protection scope of the claims.

Claims (8)

1, obtain the method for service failure reason in a kind of heterogeneous network, it is characterized in that, comprising:

A, after the failure of the bottom entity handles affairs of system, will the fail failure cause information of affairs and described failure affairs of bottom entity reports upper layer entity;

The information that B, described upper layer entity report according to described bottom entity is obtained the failure cause of failure affairs and described failure affairs.

2, method according to claim 1 is characterized in that, described steps A specifically comprises:

A1, after the failure of the bottom entity handles affairs of system, will the fail failure cause information of affairs and described affairs of bottom entity reports the MIH layer entity;

A2, described MIH layer entity pass to described upper layer entity with the failure cause information of described failure affairs and described affairs.

3, method according to claim 2 is characterized in that, described steps A 1 specifically comprises:

After the bottom registers entities incident failure of system, the bottom entity reports the MIH layer entity by Link_Event_Register.confirm message with registration failure incident and corresponding failure cause information;

Or,

After the bottom entity of system was annotated the incident failure that disappears, the bottom entity will nullify turkey by Link_Event_Deregister.confirm message and corresponding failure cause information reports the MIH layer entity.

4, method according to claim 2 is characterized in that, described steps A 2 specifically comprises:

After the MIH layer entity received the information that the bottom entity of system reports, the MIH layer entity will register or nullify turkey by MIH_Event_Register.confirm message or MIH_Event_Deregister.confirm message and corresponding failure cause information reports described upper layer entity.

5, according to claim 3 or 4 described methods, it is characterized in that, comprise in described Link_Event_Register.confirm message, Link_Event_Deregister.confirm message, MIH_Event_Register.confirm message or the MIH_Event-Deregister.confirm message:

The reason tabulation ReasonFailEventList parameter of registered events or Logout Events failure.

6, method according to claim 5 is characterized in that, described ReasonFailEventList parameter comprises:

Failure cause information corresponding or the corresponding failure cause information of Logout Events failure affairs with registered events failure affairs.

7, method according to claim 5 is characterized in that, also comprises in described Link_Event_Register.confirm message or the MIH_Event_Register.confirm message:

Affairs, and the execution result information of the event source of corresponding described affairs and described affairs, described transaction packet explanatory note in brackets volume incident or Logout Events.

8, method according to claim 1 is characterized in that, described step B also comprises:

Upper layer entity is handled described failure affairs according to the different reasons of failure affairs failure.

Images