WO2007121675A1 - Method,device and system for realizing mih capability discovery - Google Patents

Abstract

A method for realizing media independent handover(MIH) capability discovery is provided. The method includes: receiving the MIH capability discovery request which is transmitted by network element. The MIH capability discovery request includes request type which represents the network element scope that the transmitter wants to discover MIH capability; getting the MIH capability information which correponds to the request type and transmitting it to the network element. Then the problem that the network element in prior art can not determine the mode of transmitting the capability discovery message according to requirement is solved, and the network element can notify other network element how to process the message through capability discovery request message.

Description

 Method, device and system for realizing media independent switching capability discovery

 This application claims priority to Chinese Patent Application No. 200610077644.6, entitled "Method for Realizing Media-Independent Switching Capability Discovery in Heterogeneous Network Switching", submitted to the Chinese Patent Office on April 21, 2006. The content is incorporated herein by reference. Technical field

 The present invention relates to the field of communications technologies, and in particular, to a method, device, and system for implementing media independent handover (MIH) capability discovery.

Background technique

 At present, the development of communication technology is changing with each passing day, and various new access technologies are emerging one after another. Since the networks corresponding to various access technologies usually have their own suitable coverage and application scenarios, terminals supporting multiple access technologies have emerged in order to realize ubiquitous communication services. Networks that use different access technologies are called heterodyne networks. There are many heterogeneous networks, such as IEEE ( Institute of Electrical and Electronic Engineers) 802.3, IEEE 802.11 and IEEE 802.16, and 3GPP (3rd Generation Partnership Project). The cellular networks provided by the organization and 3GPP2 are heterogeneous networks.

 A terminal that supports multiple access technologies, ie, supports multiple heterogeneous networks, has a problem that must be addressed: How the terminal seamlessly switches and roams among the heterogeneous networks it supports. In response to this problem, the existing Mobile IP Protocol (MIP) technology can be considered to have achieved Layer 3 mobility, so that the terminal can guarantee the upper layer after the network address changes, that is, after the heterogeneous network handover occurs. Business continuity. However, the use of the MIP technology still has a period in which the terminal and the network's underlying link are completely disconnected, and thus affects the QoS (Quality of Service) performance of the service, such as QoS delay and jitter.

 In view of the above problems, the current purpose of IEEE 802.21 is to help implement network switching at the link layer, and to minimize the QoS performance of the service during the handover process to improve the user's mobile experience.

In order to achieve the seamlessness and continuity of heterogeneous network handover, IEEE 802.21 introduces a new protocol function layer in the existing mobility management protocol stack, namely media independent switching function (MIHF, MIH Function). MIHF It mainly provides some key services, namely MIH, Media Independent Event Service, MIH, Media Independent Command Service and MIH, Media Independent Information. Service) to help the terminal to switch.

 MIHF is logically defined as a thin layer in the mobility management protocol stack of the terminal and network, acting as a helper and booster in the handover decision. On the terminal side, MIHF provides the necessary information to the upper layer that needs to make handover decisions and how to effectively make handover decisions. The upper layer makes handover decisions and link selection based on MIHF input and context, so that seamless handover can be achieved. The location of MIHF and its key services in the protocol stack is shown in Figure 1.

 The MIH protocol used for MIHF layer communication between different network elements includes MIH capability discovery, MIH remote registration, and MIH message interaction. Through the MIH capability discovery process, each network element in the communication system can determine which other network element can support MIHF and its support level. The degree of support is usually indicated by the MIH capability list, and the MIH capability discovery process includes capability discovery handshake and capability announcement. Through the MIH Remote Registration Protocol, MIHFs in different network elements can register with each other to accept media-independent switching messages and remote events. The MIH message interaction protocol specifies the format of the packet, the message format, and the message.

 The reason why the MIH capability discovery process is required is that if the network elements in the communication system do not know each other's MIH capabilities and other information, the communication information will be confused when interpreting the interaction information, thereby affecting the interoperability of the communication system. . The network element in the communication system includes a terminal and a network entity such as a Point of Attachment (PoA), an Access Router (A, Access Router), and the network elements in the communication system usually come from different vendors. It is difficult for each other to know in advance whether they can support MIHF and their respective support for MIHF. Therefore, in order to realize the handover of a heterogeneous network, the network element in the communication system first needs to find out which network element can support MIHF and the degree of support to MIHF through the MIH capability discovery process.

 In the prior art, there are two implementations of the MIH capability discovery. One solution is that a network element in a communication system broadcasts its own MIH capability through a media medium, for example, can broadcast its own MIH capability through a beacon (beacon) in 802.11 and a DCD (downlink channel descriptor) in 802.16. .

 Another implementation is to define request and response messages for MH capability discovery, and corresponding message interaction flows. The following describes the message and interaction process of the solution.

In the prior art, a capability discovery request message (MIH_Capability_ Discover request) is defined. And MIH-capability-recovery response, MIHF-capable network elements can use these two messages to complete MIH capability discovery. For the network element that initiates the request, if you know the address of other network elements that you want to discover, you can fill in the address of other network elements in the destination address field of the capability discovery request message and perform unicast; if you don't know, You can fill in the address of the source address field of the capability discovery request message and then broadcast it. The network element that received the request message returns a response message. In addition, the network element may also actively send the MIH-Capability-Review response message in a broadcast manner, and notify other network elements of the MIH capability of the local network element.

 The above MIH-Capability-Discover request message has the same structure as the MIH-Capability-Execution response message, as shown in Table 1. Both of these messages include four fields, where SupportedEventList represents a list of supported events, SupportedCommandList represents a list of supported commands, SupportedTransportList represents the manner in which supported MIH messages are transmitted, and SupportedlSQueryTypeList represents a supported type of information service query.

 Table 1

 The terminal discovers which network element in the communication system supports MIHF by using the MIH-Capability-Expo request message, and the timing of the message flow is as shown in FIG. 2.

As shown in Figure 2, the terminal sends an MIH-Capability-Experiment request message to the PoA 1 directly connected to itself. The PoA 1 is the PoS (Point of Service) of the service network, and the PoS is the MN in the network. (Mobile Node, mobile node) Provides the network element of the MIH service. PoA 1 directly forwards the message to other surrounding network PoAs, including PoA 2, PoA 3, and AR. Among them, in a system such as WiMAX (World Interoperability for Microwave Access) or WLAN (Wireless Local Area Network), the PoS may be in the AR, and the AR in FIG. 2 is The AR of the PoS is set. Among these three network elements, PoA 3 is not a PoS and does not have MIH capability, so it will not reply. MIH—Capability—The Discover response message; PoA 2 and AR are PoSs with MIH capability, thus returning MIH—Capability—Discover response message. PoA 1 forwards the received MIH-Capability-Experience response message to the terminal.

 In fact, Figure 2 shows only one signal flow that may occur in accordance with the prior art. Because a network element may receive multiple processing after receiving the MIH-Capability-Exam request message. One is to broadcast to other network elements that it knows, as shown by PoA 1 in Figure 2, after receiving the MIH-Capability-Experience request message sent by the terminal, PoAl sends PoA 2, PoA 3 and AR The message is forwarded and the received MIH_Capability-Experience response message is forwarded to the terminal. The other is to return the MIH_Capability-Discover response message directly to the sender. PoA 2 and AR in Figure 2 directly return the response message. Of course, there may be other processing manners, for example, the received request message may be forwarded to other network elements by broadcast, and the related information of the MIHF may be returned by the response message.

 In the prior art, after the network element receives the MIH-Capability-Exposion request message, what kind of processing is performed by the network element itself, which may cause confusion in the message processing.

 For example, after the terminal wants to receive the request message, the terminal broadcasts the message to obtain the MIH capability of other network elements in the geographical location of the terminal, but the service PoA may only return its own MIH capability, and the terminal cannot obtain the terminal. Its required MIH capability information. For example, the terminal only needs the non-serving PoA to return its own MIH capability, and the non-serving PoA may broadcast the request message to other network elements, which may cause a network storm.

Summary of the invention

 In view of this, the embodiments of the present invention provide a method and apparatus for implementing MIH capability discovery in a heterogeneous network handover, so that the network element can obtain desired MIH capability information while reducing the possibility of a broadcast storm.

 A method for implementing media-independent handover capability discovery according to the embodiment of the present invention includes: receiving a capability discovery request of a peer network element carrying a request type, where the request type indicates a network element range in which the peer network element needs to discover the MIH capability ;

 The MIH capability information of the network element corresponding to the request type is obtained and sent to the peer network element.

Another method for implementing MIH capability discovery according to an embodiment of the present invention includes: Sending a capability discovery request carrying a request type to the peer network element, where the request type indicates a network element range in which the network element needs to discover the MIH capability;

 The MIH capability information of the network element corresponding to the request type is received from the peer network element.

 An embodiment of the present invention provides an apparatus for implementing MIH capability discovery, including:

 a request receiving unit, configured to receive a capability discovery request of the peer network element, where the capability discovery request includes a request type, and indicates a network element range in which the peer network element needs to discover the MIH capability;

 The MIH capability information unit is configured to obtain MIH capability information of the corresponding network element according to the request type;

 The request response unit is configured to send the MIH capability information obtained by the MIH capability information unit to the network element.

 An embodiment of the present invention provides another apparatus for implementing MIH capability discovery, including:

 a request sending unit, configured to send a capability discovery request to the peer network element; the capability sending request carrying the request type, indicating that the network element needs to discover the network element range of the MIH capability;

 The response receiving unit is configured to receive MIH capability information of the network element corresponding to the request type from the peer network element.

 The embodiment of the invention further provides a system for implementing MIH capability discovery, including:

 a first network element, configured to send a capability discovery request carrying a request type to the second network element, where the request type indicates a network element range in which the network element needs to discover the MIH capability, and receives the request type from the second network element. MIH capability information of the corresponding network element;

 The second network element is configured to receive the capability discovery request sent by the first network element, obtain MIH capability information of the network element corresponding to the request type, and send the MIH capability information to the first network element.

The embodiment of the present invention notifies the receiver network element of the network element range in which the network element of the capability discovery request is required to obtain the MIH capability information by carrying the request type in the capability discovery request, so that the receiver network element performing the capability discovery request can be configured according to The request type performs message processing, so that on one hand, the capability discovery request message of the initiator due to the receiver not broadcasting the terminal such as the service PoA can be solved, so that the information returned to the initiator is insufficient, that is, insufficient The information is used by the initiator for the selection of the handover policy; on the other hand, it can also avoid the potential threat of network storm caused by the inappropriate broadcast and forwarding of the capability discovery request message by the network element such as other non-service PoA. DRAWINGS

 1 is a schematic diagram of a positional relationship of a MIHF and its key services in a protocol stack in the prior art; FIG. 2 is a diagram showing an example of a message flow sequence of a capability discovery request in the prior art;

 3 is a flowchart of an embodiment of a capability discovery method according to the present invention;

 4 is a message flow sequence diagram of an example 1 of the capability discovery method according to the present invention;

 5 is a message flow sequence diagram of an example 2 of the capability discovery method according to the present invention;

 6 is a message flow timing diagram of Example 3 of the capability discovery method according to the present invention;

 FIG. 7 is a schematic structural diagram of an embodiment of a system for implementing MIH capability discovery according to the present invention. detailed description

 In the prior art, since there is no field in the MIH-Capability-Exam request message, it is used to indicate how the message receiver should process the received capability discovery request message, and there is no mechanism in the prior art to determine. Whether the network element of different roles needs to broadcast the request message after receiving the capability discovery request message, thus causing confusion in the processing of the capability discovery request message. In the embodiment of the present invention, the sender network element of the capability discovery request message carries the request type in the message, which is used to notify the receiver of the message, which MIH capability information of the network element is desired, or to notify the receiver of what needs to be performed. The MIH capability discovery of the network element; the receiver obtains the MIH capability information of the corresponding network element according to the request type and returns it to the sender.

 The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

 In the embodiment of the capability discovery method of the present invention, a request type field may be added to the currently existing MIH-Capability-Examine request message, and the field may be configured with multiple identifiers according to requirements, and each identifier corresponds to a request type. Each request type represents a message processing scheme of the recipient. One possible implementation is to add an optional field named ActionCode to Table 1 above. The message format after adding this field can be as shown in Table 2. The specific definition of this field can be as shown in Table 3.

ActionCode Action Code(244)

ActionCode Action Code (244)

 (optional)

 Table 2

 table 3

 In the implementation manner shown in Table 3, when the ActionCode is 0, the capability discovery request message is a unicast message, and the sender only needs to obtain the MIH capability information of the receiver; when the ActionCode is 1, the sender hopes. The receiver broadcasts the message to other network entities to obtain MIH capability information of other network entities.

 When the request type field is used to carry the request type in the MIH-capability-exermination request message, the processing flow of the method for the capability discovery method of the present invention is as shown in FIG. 3, which corresponds to the following steps:

 Step 301: The network element (ie, the sender) that initiates the capability discovery request sets the corresponding identifier of the current required request type in the request type field when sending the capability discovery request message to other network elements.

 Step 302: The network element (ie, the receiving MIHF network element) that receives the capability discovery request message and has MIHF performs a corresponding MIH capability discovery processing procedure according to the identifier in the request type field of the message.

 Step 303: The network element that initiates the capability discovery request obtains the MIH capability information of the related network element according to the processing result in step 302.

 The flow of the above method embodiment will be described in detail below with specific examples. The request type field settings shown in Table 3 are used in the following examples.

 Example 1 of the method of the present invention:

The network element in the communication system can send the MIH_Capability_Discovei' request with the ActionCode field 0 when the receiver that only needs the capability discovery request message returns its own MIH capability information. The message, the network element that received the request message directly returns its MIH capability information. Figure 4 shows the message flow timing diagram of Example 1, which corresponds to the following steps:

 Step 401: The network element 1 sends an MIH_Capability_Discover request message to the network element 2, and only needs to obtain the MIH capability information of the other party, and the ActionCode field in the message is 0.

 The MIH capability information usually includes information on whether or not to support MIHF, and information on the degree of support of the MIHF.

 Step 402: The network element 2 finds that the ActionCode field in the MIH-Capability-Discovering Request message is 0, and directly returns an MIH-Capability-Reference response message, and the message carries its own MIH capability information.

 The message flow timing shown in Figure 4 is typically used for the MIHF capability discovery process between two peer network elements. For example, the terminal and service PoA only need to know the MIH capability information of the peer. Or the PoA in the two heterogeneous networks only need to know the MIH capability of the other party. For example, the service network PoA needs to obtain the MIH capability information of other network PoAs.

 Example two of the method of the present invention.

 When the terminal wants to obtain the MIH capability information of the network element in the other heterogeneous network in the area, the process shown in FIG. 5 may be used, and the terminal initiates the capability discovery request. In FIG. 5, PoA 1, PoA 2, and PoA 3 are PoS, PoA 4 does not have PoS function. The process corresponds to the following steps:

 Step 501: The terminal sends an MIH_Capability_Discover request message to the service PoA, that is, PoAl.

 Since the terminal wants to obtain the MIH capability information of the PoA in all other heterogeneous networks in the location area, the ActionCode field in the message is set to 1.

 Step 502: After determining that the ActionCode field in the received MIH_Capability_Examine Request message is 1, the PoAl broadcasts the message to a heterogeneous network around it, and sets the ActionCode field in the message to 0.

Step 503: The PoA with the MIHF in the surrounding heterogeneous network, that is, the PoA2 and the PoA3, after receiving the MIH_Capability_Experiment request message, determine that the ActionCode field in the message is 0, and directly return the MIH_Capability to the PoAl. Discover response message, and carry its own MIH capability information in the message. Since PoA4 does not have MIHF, it cannot respond, so it is not processed. Step 504: The PoAl forwards the received MIH_Capability-Discover response message, including the MIH_Capability-Discover response message from the PoA2 and the PoA3, to the terminal.

 Through the above steps, the terminal can obtain the MIH capability information of the PoA in all other heterogeneous networks in the location area.

 As shown in Figure 5, the terminal initiates a capability discovery request. The terminal needs the service PoA to forward the MIH-Capability-Discover request message sent by the terminal. Therefore, the ActionCode field of the MIH-Capability-Exam request message is set to 1. If the PoA initiates the capability discovery request in the communication system, the message may not be forwarded by the receiver, so the ActionCode field of the MIH-Capability-Exam request message may be set to 0, where the network receiving the request message is received. The element can be another PoA or a terminal.

 As mentioned earlier, multiple identities can be set for the added ActionCode to identify different request types and recipient processing schemes. In addition to the above two types of identification, other identifiers may be set by the manager of the communication system according to specific operational needs. For example, if the sender needs to obtain the MIH capability information of the network element in all heterogeneous networks, an identifier may be added to the ActionCode, for example, the identifier 2 is added to indicate that the sender wants the receiver to return its MIH capability information, and the MIH_Capability—The Discover request message is broadcast. In this way, after receiving the MIH_Capability_Discover request message with the ActionCode field of 2, the network element that receives the message returns an MIH__Capability_Discover response message carrying its own MIH capability information, and forwards the request message to other network elements, and The MIH-Capability-Review response messages returned by these network elements are forwarded to the sender.

 The terminal initiates the request as an example. 6 is a message flow timing diagram of Example 3 of the method embodiment of the present invention. In FIG. 6, ΡοΑ 1, PoA 2, and PoA 3 are PoS, and PoA 4 does not have a PoS function. As can be seen from Figure 6, the difference between Figure 5 and that of Figure 5 is that PoAl sends its MIH capability information to the terminal through the MIH-Capability-Exposure response message.

 As can be seen from the above description, in addition to the above-mentioned several identification manners, other identifiers may be set for the ActionCode as needed to indicate other request types and corresponding receiver processing schemes, and the MIH_Capability_Experiment request message is received. The network element performs corresponding processing according to the identifier.

In addition, in the networking environment of the communication system, there may also be a certain network element for some reason. The action code field is set in the MIH-Capability-Execution request message. To ensure that the processing of the message is not caused by each network element, the following solution can be adopted:

 After receiving the MIH_Capability-Exam request message, each network element determines whether the ActionCode field in the message has a request type identifier. If yes and identifiable, the corresponding processing is performed according to the identifier; if not, or not, the identifier is unrecognizable. Then, according to the role of the network element and the sender network element, whether to forward the message is determined. The processing of the message by the network element of the role may be determined by the administrator of the communication system. For example, if the network element is a service PoA, and the received request message is a capability discovery request message sent by the terminal, then The network element sends the request message to other surrounding network elements by broadcast. If it is not the former case, for example, the service PoA network element receives the request message sent by other network elements, and does not perform forwarding processing, but directly returns its MIH capability information to the sender through the response message.

 A person skilled in the art can understand that all or part of the steps in implementing the above method embodiments can be completed by a program instructing related hardware, and the program can be stored in a readable storage medium, and the program can be executed when executed. All or part of the steps in the above method embodiments are included. The storage medium shield may be a read only memory, a random access memory, a magnetic disk, an optical disk, or the like.

 FIG. 7 is a schematic structural diagram of a system for implementing MIH capability discovery according to the present invention. The system includes a network element 700 and a network element 800. The network element 700 is a sender network element of a capability discovery request, and the network element 800 The recipient network element for the capability discovery request. The network element 700 includes a request transmitting unit 710 and a response receiving unit 720. The network element 800 includes a request receiving unit 810, a request response unit 830, and an MIH information capability unit 820.

 The request sending unit 710 of the network element 700 sends a capability discovery request to the network element 800. The capability discovery request includes a request type, and indicates a network element range in which the network element 700 needs to discover the MIH capability, that is, the MIH of the network element that the network element 700 wants to obtain. Capability information. The request receiving unit 810 of the network element 800 receives the capability discovery request sent by the network element 700, and outputs the request type in the request to the MIH capability information unit 820.

The MIH capability information unit 820 obtains the MIH capability information of the corresponding network element according to the request type in the capability discovery request sent by the network element 700, and outputs the acquired MIH capability information to the request response unit 830. The request type may be the first type, indicating that the network element 700 wishes to obtain the network element 800. The MIH capability information may be a second type, indicating that the network element 700 wishes to obtain the MIH capability information of the other network element, and may be the third type, indicating that the network element 700 wishes to obtain the MIH capability information of the network element 800 and other network elements; The network element is a network element other than the network element that sends and receives the capability discovery request. The MIH capability information unit 820 may include the local network element information sub-unit 821 and other network element information sub-units 822. When the request type is the first type and the third type, the local network element information sub-unit 821 acquires the MIH capability of the network element 800. The information is output to the request response unit 830; when the request type is the second type and the third type, the other network element information sub-unit 822 acquires the MIH capability information of the other network elements and outputs the same to the request response unit 830.

 The request response unit 830 of the network element 800 transmits the MIH capability information of the local network element and/or other network elements output by the MIH capability information unit 820 to the response receiving unit of the network element 700.

 The network element 700, which is the sender of the capability request, may be a terminal or a PoS, and the network element 800, which is the recipient of the capability discovery request, is generally PoS.

 In addition, any person skilled in the art can understand that the PoS network element in the communication system can be used not only as the receiver network element of the capability discovery request, but also as the sender network element. In other words, the PoS network element in the communication system can include each of the network element 700 and the network element 800.

 In the embodiment of the present invention, the sender of the capability discovery request carries the request type in the capability discovery request, and the network element range of the network element that the sender network element of the capability discovery request wishes to obtain the MIH capability information is notified to the receiver network element, so that the receiver network element can The message processing according to the request type can solve the capability discovery request message of the initiator due to the receiver not broadcasting the terminal such as the service PoA, so that the information returned to the initiator is insufficient; A potential threat of network storms is caused by improperly broadcasting and forwarding of capability discovery request messages by network elements such as other non-serving PoAs.

 The above description is only a preferred embodiment of the solution of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalents, and improvements made within the spirit and scope of the present invention are intended to be included within the scope of the appended claims.

Claims

Rights request  A media-independent handover MIH capability discovery method, comprising: receiving a capability discovery request of a peer network element carrying a request type, where the request type indicates a network element that the peer network element needs to discover the MIH capability Scope  The MIH capability information of the network element corresponding to the request type is obtained and sent to the peer network element.  The method according to claim 1, wherein, when the request type is the first type, the obtaining the MIH capability information of the network element corresponding to the request type is: obtaining the MIH capability of the local network element. information.  The method according to claim 2, wherein, when the request type is the second type, the obtaining the MIH capability information of the network element corresponding to the request type is specifically: obtaining the MIH capability of the other network element Information; the other network element is a network element other than the network element that sends and receives the capability discovery request.  The method according to claim 2, wherein, when the request type is the third type, the obtaining the MIH capability information of the network element corresponding to the request type is: obtaining the local network element and other networks. The MIH capability information of the element; the other network element is a network element other than the network element that sends and receives the capability discovery request.  The method according to claim 3 or 4, wherein the obtaining MIH capability information of other network elements includes -.  Sending a capability discovery request carrying a request type to another network element, where the request type is a first type;  Receives its own MIH capability information returned by other NEs.  The method according to any one of claims 1 to 5, wherein the capability discovery request is an MIH capability discovery request message MIH_Capability_Experiance request; the carrying request type is passed in MIH-Capability_Discover The request type field is added to the request message. The MIH capability information of the network element is sent to the peer network element by using the MIH capability discovery response message MIH_Capability_Extract Response.  7. A method for implementing MIH capability discovery, characterized by comprising: Sending a capability discovery request carrying a request type to the peer network element, where the request type indicates the local network element The range of network elements that need to discover MIH capabilities;  The MIH capability information of the network element corresponding to the request type is received from the peer network element.  The method according to claim 7, wherein the request type includes: a first type, where the network element that the network element needs to discover the MIH capability is the peer network element;  The second type indicates that the network element that the network element needs to discover the MIH capability is another network element; or the third type indicates that the network element that the network element needs to discover the MIH capability is the peer network element and other network elements; The element is a network element other than the network element that sends and receives the capability discovery request.  The method according to claim 7 or 8, wherein the capability discovery request is an MIH capability discovery request message MIH_Capability_Experiance request; the carrying request type is in an MIH_Capability_Examination request message. The request type field is implemented. The MIH capability information of the network element is obtained by receiving the MIH capability discovery response message MIH_Capability_Extract Response.  10. An apparatus for implementing MIH capability discovery, characterized by comprising:  a request receiving unit, configured to receive a capability discovery request of the peer network element, where the capability discovery request includes a request type, and indicates a network element range in which the peer network element needs to discover the MIH capability;  The MIH capability information unit is configured to obtain MIH capability information of the corresponding network element according to the request type;  The request response unit is configured to send the MIH capability information obtained by the MIH capability information unit to the peer network element.  The device according to claim 10, wherein the request type comprises: a first type, wherein the network element that the peer network element needs to discover the MIH capability is the network element;  The second type indicates that the network element that the peer network element needs to discover the MIH capability is the other network element; or the third type indicates that the network element that the peer network element needs to discover the MIH capability is the network element and other network elements; The network element is a network element other than the network element that sends and receives the capability discovery request.  The device according to claim 11, wherein the MIH capability information unit comprises:  The network element information subunit is configured to obtain MIH capability information of the local network element when the request type is the first type or the third type; Other network element information subunits, configured to obtain when the request type is the second type or the third type MIH capability information of other network elements.  The device according to any one of claims 10 to 12, wherein the device further comprises:  a request sending unit, configured to send a capability discovery request, where the capability sending request carries a request type, and indicates a network element range in which the network element needs to discover the MIH capability;  The response receiving unit is configured to receive a response to the capability discovery request, where the MIH capability information of the network element corresponding to the request type is included.  14. Apparatus according to claim 10, wherein said apparatus is a service point PoS.  15. An apparatus for implementing MIH capability discovery, comprising:  a request sending unit, configured to send a capability discovery request to the peer network element; the capability sending request carrying the request type, indicating that the network element needs to discover the network element range of the MIH capability;  The response receiving unit is configured to receive MIH capability information of the network element corresponding to the request type from the peer network element.  16. Apparatus according to claim 15 wherein the apparatus is a PoS or a terminal. 17. A system for implementing MIH capability discovery, comprising:  The first network element is configured to send, to the second network element, a capability discovery request that carries the request type, where the request type indicates that the network element needs to discover the MIH capability, and receives and clears from the second network element. Find the MIH capability information of the network element corresponding to the type;  The second network element is configured to receive the capability discovery request sent by the first network element, obtain MIH capability information of the network element corresponding to the request type, and send the MIH capability information to the first network element.