WO2016062021A1 - 业务能力探测方法及装置 - Google Patents
业务能力探测方法及装置 Download PDFInfo
- Publication number
- WO2016062021A1 WO2016062021A1 PCT/CN2015/075915 CN2015075915W WO2016062021A1 WO 2016062021 A1 WO2016062021 A1 WO 2016062021A1 CN 2015075915 W CN2015075915 W CN 2015075915W WO 2016062021 A1 WO2016062021 A1 WO 2016062021A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- network element
- feedback information
- specified services
- service
- request message
- Prior art date
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
Definitions
- the present invention relates to the field of communications, and in particular to a method and apparatus for detecting a service capability.
- the device can be detected by the Device-Watchdog-Request (DWR)/Device-Watchdog-Answer (DWA) device on the Diameter link. Whether the entity is available.
- the basic protocol also proposes the concept of primary peers and secondary peers, and fails replacement and failure recovery through DWR/DWA message detection.
- FIG. 1 is a schematic diagram of a Diameter primary peer working normally or after starting a Fail Back according to the related art.
- a Diameter peer entity and a primary peer and a secondary peer are shown.
- the Diameter connection is established separately.
- the Diameter peer entity generally performs data processing with the primary peer, while the Diameter peer entity establishes a Diameter connection with the secondary peer, but generally Diameter data processing is not possible.
- the Fail Over process the failure replacement policy, occurs, at which point the secondary peer acts as the primary peer and continues to communicate with the Diameter peer.
- FIG. 2 is a schematic diagram of the normal operation of the secondary peer after the Diameter starts Fail Over according to the related art.
- the Fail Back process is initiated, that is, the failure recovery strategy is made to become the primary peer again, and returns to the state of FIG.
- the method of detecting a link on a link between peers and performing a failover according to the detection result has the following disadvantages: the failure replacement and the failure recovery policy are only suitable for the scenario where the link is automatically switched, and the originating service cannot effectively intervene. This is because one end of the network element cannot know the services supported by the other end network element.
- the present invention provides a method and a device for detecting a service capability, so as to at least solve the problem in the related art that a network element at one end cannot learn the service supported by the network element at the other end.
- a service capability detecting method including: a first network element sends a first probe request message to a second network element, where the first probe request message is used to detect the first Whether the second network element supports one or more specified services; the first network element receives the first feedback information sent by the second network element, where the first feedback information is used to indicate the second network element pair The support situation of the one or more specified services.
- the method further includes: the first network element sends a second probe request message to the third network element, where the second probe request message is used to detect whether the third network element supports the one Or a plurality of specified services; the first network element receives the second feedback information sent by the third network element, where the second feedback information is used to indicate that the third network element is to the one or more Specifying the support status of the service; the first network element determines that the third network element is a backup network element of the second network element.
- the method further includes: after the first network element sends the first probe request message for a predetermined number of times or does not receive the first feedback information within a predetermined duration, the first The network element determines that the second network element is unavailable; and/or, the first network element does not receive the second feedback information after sending the second probe request message for a predetermined number of times or within a predetermined duration In case, the first network element determines that the third network element is unavailable.
- the sending, by the first network element, the first probe request message to the second network element, or the sending, by the first network element, the second probe request message to the third network element includes: Transmitting, by the first network element, the first probe request message to the second network element according to a pre-configured period; and/or, the first network element sending the foregoing to the third network element according to a pre-configured period Second probe request message.
- the method further includes: the first feedback information includes one of: the second network element supports all specified services in the one or more specified services, and the second network element pairs The specified service in the one or more specified services is not supported, and the second network element supports a part of the specified service in the one or more specified services; and/or the second feedback information includes one of the following: The third network element supports all the specified services in the one or more specified services, and the third network element does not support the specified service in the one or more specified services, and the third network element does not support the third network element. Supporting a portion of the specified services in the one or more specified services.
- first network element, the second network element, and the third network element are both Diameter entities.
- the method further includes: the first network element sends the first probe request message and/or the second probe request message by using a routing proxy entity DRA; and/or, the first network element passes the The routing proxy entity DRA receives the first feedback information and/or the second feedback information.
- the method further includes: sending, by the first network element, the first designated service to the second network element Processing, where the first designated service is a service message supported by the second network element; when the first feedback information indicates that the first designated service is a service that is not supported by the second network element, The first network element sends the first designated service to the third network element for processing.
- the method further includes: when the first feedback information indicates that the second network element resumes supporting the first designated service, the first network element sends the first designated service to the The second network element.
- the method further includes: when the first network element determines that the second network element and the third network element both support the second designated service, the first network element according to the load sharing policy The second designated service is sent to the second network element and the third network element for processing.
- a method for detecting a service capability including: receiving, by a second network element, a first probe request message sent by a first network element, where the first probe request message is used for detecting Whether the second network element supports one or more specified services; the second network element detects the service capability supported by the second network element, determines whether the second network element supports the one or more specified services, and generates the first The second network element sends the first feedback information to the first network element.
- the method further includes: the third network element receives the second probe request message sent by the first network element, where the second probe request message is used to detect whether the third network element supports one or a plurality of specified services; the third network element detects the service capability supported by the third network element, determines whether the third network element supports the one or more specified services, and generates second feedback information; the third network element The second feedback information is sent to the first network element, where the third network element is a backup network element of the second network element.
- the method further includes: after the second network element receives the first probe request message for a predetermined number of times or does not send the first feedback information within a predetermined duration, determining, by the second network element, The second network element is unavailable; and/or, the third network element determines, after receiving the second probe request message, reaches the predetermined number of times, or does not send the second feedback information within a predetermined duration. The third network element is unavailable.
- the receiving, by the second network element, the first probe request message sent by the first network element or the second network element receiving the second probe request message sent by the first network element includes: The second network element is based on Receiving, by the pre-configured period, the first network element to send the first probe request message; and/or, the third network element receiving the first network element to send the second probe request message according to a pre-configured period .
- the method further includes: the first feedback information includes one of: the second network element supports all specified services in the one or more specified services, and the second network element pairs The specified service in the one or more specified services is not supported, the second network element supports a part of the specified service in the one or more specified services; and/or the second feedback information includes one of the following: The third network element supports all the specified services in the one or more specified services, and the third network element does not support the specified service in the one or more specified services, and the third network element supports A portion of the one or more designated services specifies a service.
- first network element, the second network element, and the third network element are both Diameter entities.
- the method further includes: the second network element receives the probe request message by using a routing proxy entity DRA, and/or the second network element sends the first feedback information by using the routing proxy entity DRA And sending to the first network element; and/or the third network element receives the probe request message by using a routing proxy entity DRA, and/or the third network element uses the routing proxy entity DRA to The second feedback information is sent to the first network element.
- the method further includes: at the first When the feedback information indicates that the second network element does not support the first designated service, the first designated service is performed by the third network element.
- the method further includes: when the first feedback information indicates that the second network element resumes supporting the first designated service, the first designated service is performed by the second network element.
- the method further includes: when the first feedback information and the second feedback information indicate that the second designated service is supported, the second network element and the third network element are executed according to a load sharing policy The second designated service.
- a service capability detecting apparatus is further applied to the first network element, including: a first sending module, configured to send a first probe request message to the second network element, where The first probe request message is configured to detect whether the second network element supports one or more specified services, and the first receiving module is configured to receive the first feedback information sent by the second network element, where the first The feedback information is used to indicate that the second network element supports the one or more specified services.
- the device further includes: a second sending module, configured to send a second probe request message to the third network element, where the second probe request message is used to detect whether the third network element supports the One or more
- the second receiving module is configured to receive the second feedback information sent by the third network element, where the second feedback information is used to indicate that the third network element specifies the one or more a service support situation; a determining module, configured to determine that the third network element is a backup network element of the second network element.
- the first feedback information includes one of: the second network element supports all specified services in the one or more specified services, and the second network element supports the one or more specified services The specified service is not supported, and the second network element supports a part of the specified service in the one or more specified services; and/or the second feedback information includes one of the following: the third network element Supporting all the specified services in the one or more specified services, the third network element does not support the specified service in the one or more specified services, and the third network element supports the one or more Part of the designated business in a specified business.
- first network element, the second network element, and the third network element are both Diameter entities.
- a service capability detecting apparatus including: a first receiving module, where the first receiving module is applied to the second network element, and is configured to receive the first sending by the first network element a probe request message, where the first probe request message is used to detect whether the second network element supports one or more specified services; the first detecting module, the first detecting module is applied to the second network element And determining, according to the service capability supported by the second network element, whether the second network element supports the one or more specified services, and generating first feedback information; the first sending module, the first sending module is applied to the The second network element is configured to send the first feedback information to the first network element.
- the device further includes: a second receiving module, where the second receiving module is applied to the third network element, and is configured to receive a second probe request message sent by the first network element, where the second The probe request message is used to detect whether the third network element supports one or more specified services, and the second detection module is applied to the third network element to determine the service capability supported by the second network element. Whether the third network element supports the one or more specified services, and generates second feedback information; the second sending module, the second sending module is applied to the third network element, and is configured to The second network element is sent to the first network element, where the third network element is a backup network element of the second network element.
- the first feedback information includes one of: the second network element supports all specified services in the one or more specified services, and the second network element supports the one or more specified services The specified service is not supported, and the second network element supports a part of the specified service in the one or more specified services; and/or the second feedback information includes one of the following: the third network element supports All the specified services in the one or more specified services, the third network element does not support the specified service in the one or more specified services, and the third network element supports the one or more Specifies a part of the specified business in the business.
- first network element, the second network element, and the third network element are both Diameter entities.
- the first network element sends a first probe request message to the second network element, where the first probe request message is used to detect whether the second network element supports one or more specified services; the first network element receives the first The first feedback information sent by the second network element, where the first feedback information is used to indicate that the second network element supports the one or more specified services.
- the problem in the related art is that the one-end network element cannot learn the service supported by the other end network element, and the one-end network element can learn the service supported by the other end network element.
- FIG. 1 is a schematic diagram of a working operation of a Diameter primary peer in accordance with the related art or after starting a Fail Back;
- FIG. 2 is a schematic diagram of normal operation of a secondary peer after a Diameter is started according to the related art
- FIG. 3 is a flowchart of a service capability detecting method according to an embodiment of the present invention.
- FIG. 4 is a structural block diagram of a service capability detecting apparatus according to an embodiment of the present invention.
- FIG. 5 is a structural block diagram 1 of a service capability detecting apparatus according to an embodiment of the present invention.
- FIG. 6 is a flowchart 1 of a service capability detecting method according to an embodiment of the present invention.
- FIG. 7 is a structural block diagram 2 of a service capability detecting apparatus according to an embodiment of the present invention.
- FIG. 8 is a structural block diagram 3 of a service capability detecting apparatus according to an embodiment of the present invention.
- FIG. 9 is a schematic diagram of an available end-to-end keep-alive Diameter network element entity according to an embodiment of the present invention.
- FIG. 10 is a schematic diagram of an available end-to-end primary server network element entity according to an embodiment of the present invention.
- FIG. 11 is a schematic diagram of an available end-to-end standby server network element entity according to an embodiment of the present invention.
- FIG. 12 is a schematic diagram of two server network element entities available for end-to-end load sharing according to an embodiment of the present invention.
- FIG. 3 is a flowchart of a service capability detection method according to an embodiment of the present invention. As shown in FIG. 3, the process includes the following steps:
- Step S302 The first network element sends a first probe request message to the second network element, where the first probe request message is used to detect whether the second network element supports one or more specified services.
- Step S304 The first network element receives the first feedback information sent by the second network element, where the first feedback information is used to indicate that the second network element supports the one or more specified services.
- the first network element sends a second network element to the second network element to support the probe request message of the specified service, and the second network element feeds back the specified service supported by the second network element to the first network element, thereby solving the related technology.
- a network element at one end cannot know the problem caused by the service supported by the other end network element. In this way, one end network element can learn the services supported by the other end network element.
- the above steps also provide the possibility for the implementation of other services. For example, in the related art, if the client network element cannot learn the services supported by the server-side network element, if a client network element entity needs to support the server network element entity, For a service disaster tolerance function, you need to manually control the processing of business messages. Through the above steps, the client can learn the situation supported by the server network element, and the client can select the required server network element, thereby implementing functions such as disaster recovery.
- An alternative embodiment below utilizes the above steps to achieve disaster tolerant processing.
- the first network element sends a second probe request message to the third network element, where the second probe request message is used to detect whether the third network element supports the one or more specified services;
- the network element receives the second feedback information sent by the third network element, where the second feedback information is used to indicate that the third network element supports the one or more specified services. Therefore, the first network element obtains the support for the specified service by the second network element and the third network element of the standby network element, and the first network element can control the specified service according to the obtained result.
- the first probe request message and the second probe request message may be the same probe request message or different probe request messages.
- the second network element or the third network element is further determined to be available. Specifically, the first network element does not receive the first probe request message after the predetermined number of times is sent or within a predetermined period of time. In the case of the first feedback information, the first network element determines that the second network element is unavailable; and/or, the first network element does not receive the second after transmitting the second probe request message for a predetermined number of times or within a predetermined duration In the case of feedback information, first The network element determines that the third network element is unavailable. When the first network element confirms that the second network element/third network element is unavailable, the second network element/third network element is not sent.
- the first network element may send the probe request message to the other network element in a periodic manner.
- the first network element sends the first probe request message to the second network element according to the pre-configured period; and/or, A network element sends a second probe request message to the third network element according to a pre-configured period.
- the second network element or the third network element performs feedback by using the first feedback information and the second feedback information, where the first feedback information and the second feedback information are only used to identify the two feedback information, and should not be Understand any other limitations.
- These two feedback information can include various information and can be configured according to actual needs.
- the first feedback information may include one of: the second network element supports all specified services in the one or more specified services, and the second network element is in the one or more specified services. The second network element supports a part of the specified service in the one or more specified services.
- the second feedback information may include one of the following: the third network element supports the one. Or all the specified services in the specified service, the third network element does not support the specified service in the one or more specified services, and the third network element supports the part of the specified service in the one or more specified services.
- the first network element may perform the first designation.
- the service is sent to the second network element for processing, where the first designated service is a service message supported by the second network element, and the third network element is used as the backup network element of the second network element, where the first feedback information indicates the first designated service.
- the first network element sends the first designated service to the third network element for processing.
- the first network element when the first feedback information indicates that the second network element resumes supporting the first designated service, the first network element sends the first designated service to the second network element to perform processing of the first designated service. In addition, when the second network element does not support the specified service, the backup network element of the second network element performs the processing of the designated service.
- the third network element is used as the backup network element of the second network element, and the two network devices can perform the shared processing on the specified services.
- the second network element and the third network are determined in the first network element.
- the first network element sends the second specified service to the second network element and the third network element for processing according to the load sharing policy.
- the second designated service and the first designated service may be the same service, or may be different services.
- the first network element, the second network element, and the third network element involved in the foregoing may all be Diameter entities.
- the Diameter entity For certain types of entities, for example, the Diameter entity, it is impossible to detect whether the path of the Diameter client entity to reach the Diameter server after being transited by the Diameter Route Agent (DRA) is reachable.
- DRA Diameter Route Agent
- the first network element may send the first probe request message and/or the second probe request message through the routing proxy entity DRA. In another optional embodiment, the first network element may also receive the first feedback information and/or the second feedback information through the routing proxy entity DRA.
- a service capability detecting device is also provided, which is used to implement the foregoing embodiments and optional embodiments, and details are not described herein.
- the term “module” may implement a combination of software and/or hardware of a predetermined function.
- the apparatus described in the following embodiments is preferably implemented in software, hardware, or a combination of software and hardware, is also possible and contemplated.
- FIG. 4 is a structural block diagram of a service capability detecting apparatus according to an embodiment of the present invention.
- the apparatus is applied to a first network element, and FIG. 4 includes: a first sending module 42 configured to send a first probe request message to a second network element.
- the first probe request message is used to detect whether the second network element supports one or more specified services.
- the first receiving module 44 is configured to receive the first feedback information sent by the second network element, where the first feedback information Used to indicate the support of the second network element to the one or more specified services.
- the apparatus further includes: a second sending module 52, configured to send a second probe request message to the third network element, where The second probe request message is used to detect whether the third network element supports the one or more specified services.
- the second receiving module 54 is configured to receive the second feedback information sent by the third network element, where the second feedback information is used.
- the determining module 56 is configured to determine that the third network element is a backup network element of the second network element.
- the first feedback information may include one of the following: the second network element supports all the specified services in the one or more specified services, and the second network element is in the one or more specified services. The specified service is not supported, and the second network element supports a part of the specified service in the one or more specified services; and/or the second feedback information includes one of the following: the third network element supports the one or more specified services All the specified services in the third network element are not supported by the specified service in the one or more specified services, and the third network element supports part of the designated services in the one or more specified services.
- the first network element, the second network element, and the third network element may all be Diameter entities.
- FIG. 6 is a flowchart 1 of a method for detecting a service capability according to an embodiment of the present invention. As shown in FIG. 6, the process includes the following steps:
- Step S602 The second network element receives the first probe request message sent by the first network element, where the first probe request message is used to detect whether the second network element supports one or more specified services.
- Step S604 the second network element detects the service capability supported by the second network element, determines whether the second network element supports the one or more specified services, and generates first feedback information.
- Step S606 The second network element sends the first feedback information to the first network element.
- the second network element detects the service capability supported by the first network element according to the received probe request message of the first network element, determines its support for the specified service, and feeds back the specified service supported by the second network to the first network.
- the problem is solved in the related art, because one end network element cannot know the service supported by the other end network element, and then one end network element can learn the service supported by the other end network element.
- the above steps also provide the possibility for the implementation of other services. For example, in the related art, if the client network element cannot learn the services supported by the server-side network element, if a client network element entity needs to support the server network element entity, For a service disaster tolerance function, you need to manually control the processing of business messages. Through the above steps, the client can learn the situation supported by the server network element, and the client can select the required server network element, thereby implementing functions such as disaster recovery.
- the third network element receives the second probe request message sent by the first network element, where the second probe request is sent.
- the message is used to detect whether the third network element supports one or more specified services; the third network element detects the service capability supported by the third network element, determines whether the third network element supports the one or more specified services, and generates second feedback information;
- the third network element sends the second feedback information to the first network element, where the third network element is a backup network element of the second network element.
- the first probe request message and the second probe request message may be the same probe request message or different probe request messages.
- the second network element or the third network element may be determined to be available. Specifically, the second network element does not receive the first probe request message after a predetermined number of times or within a predetermined duration. If the first feedback information is sent, determining that the second network element is unavailable; and/or, the third network element does not send the second feedback information after receiving the second probe request message for a predetermined number of times or within a predetermined duration In the case, it is determined that the third network element is unavailable.
- the second network element or the third network element may receive the first network element to send the probe request message in a periodic manner.
- the second network element receives the first network element to send the first probe request message according to the pre-configured period.
- the third network element receives the first network element to send the second probe request message according to the pre-configured period.
- the second network element or the third network element performs feedback by using the first feedback information and the second feedback information, where the first feedback information and the second feedback information are only used to identify the two feedback information, and should not be Understand any other limitations.
- These two feedback information can include various information and can be configured according to actual needs.
- the first feedback information may include one of: the second network element supports all specified services in the one or more specified services, and the second network element is in the one or more specified services. The second network element supports a part of the specified service in the one or more specified services.
- the second feedback information may include one of the following: the third network element supports the one. Or all the specified services in the specified service, the third network element does not support the specified service in the one or more specified services, and the third network element supports the part of the specified service in the one or more specified services.
- the second network element and the third network element send the first feedback information and the second feedback information to the first network element, that is, after the first network element learns the support situation of the second network element and the third network element for the designated service
- the first feedback information indicates that the second network element does not support the first designated service (for example, the second network element temporarily disables the support for the first designated service)
- the third network executes the first specified service.
- the backup network element of the second network element performs the processing of the designated service.
- the first designated service is performed by the second network element.
- the third network element is used as the backup network element of the second network element, and the two network devices can perform the shared processing on the specified services.
- the first feedback information and the second feedback information indication support the second.
- the second network element and the third network element perform the second designated service according to the load sharing policy.
- the second designated service and the first designated service may be the same service, or may be different services.
- the first network element, the second network element, and the third network element involved in the foregoing may all be Diameter entities.
- the Diameter entity For certain types of entities, for example, the Diameter entity, it is impossible to detect whether the path of the Diameter client entity to reach the Diameter server after being transited by the Diameter Route Agent (DRA) is reachable.
- DRA Diameter Route Agent
- the second network element or the third network element may receive, by the routing proxy entity DRA, the first network element to send the first probe request message and/or the second probe request message.
- the second network element or the third network element may also send the first feedback information and/or the second feedback information through the routing proxy entity DRA.
- a service capability detecting device is also provided, which is used to implement the foregoing embodiments and optional embodiments, and details are not described herein.
- the term “module” may implement a combination of software and/or hardware of a predetermined function.
- the apparatus described in the following embodiments is preferably implemented in software, hardware, or a combination of software and hardware, is also possible and contemplated.
- FIG. 7 is a block diagram showing the structure of a service capability detecting apparatus according to an embodiment of the present invention.
- the apparatus includes: a first receiving module 72, where the first receiving module 72 is applied to the second network element, and is configured to receive the first a first probe request message sent by a network element, where the first probe request message is used to detect whether the second network element supports one or more specified services; the first detecting module 74, the first detecting module 74 is applied to the second network
- the first sending module 76, the first sending module 76 is applied to the second network element, is configured to detect the service capability supported by the second network element, and determine whether the second network element supports the one or more specified services, and generate the first feedback information. And configured to send the first feedback information to the first network element.
- FIG. 8 is a structural block diagram 3 of a service capability detecting apparatus according to an embodiment of the present invention.
- the apparatus further includes: a second receiving module 82, where the second receiving module 82 is applied to the third network element, and is configured to receive a second probe request message sent by the first network element, where the second probe request message is used to detect whether the third network element supports one or more specified services; the second detection module 84, the second detection module 84 is applied to the first
- the third network element determines whether the third network element supports the one or more specified services and generates the second feedback information by detecting the service capability supported by the third network element.
- the second sending module 86 and the second sending module 86 are applied to the third network.
- the element is configured to send the second feedback information to the first network element, where the third network element is a backup network element of the second network element.
- the first feedback information includes one of: the second network element supports all specified services in the one or more specified services, and the second network element specifies the one or more specified services.
- the service is not supported, and the second network element supports a part of the specified service in the one or more specified services; and/or the second feedback information includes one of the following: the third network element supports all of the one or more specified services.
- the designated service, the third network element does not support the specified service in the one or more specified services, and the third network element supports part of the specified service in the one or more specified services;
- the first network element, the second network element, and the third network element are all Diameter entities.
- the following takes an example of a first network element, a second network element, and a third network element as Diameter entities in combination with an optional embodiment.
- This alternative embodiment proposes a method for detecting an end-to-end Diameter physical network element.
- the heartbeat detection message of a set of service levels is used to sense whether the target Diameter entity service is available.
- FIG. 9 is a schematic diagram of an end-to-end keep-alive detection Diameter network element entity according to an embodiment of the present invention. As shown in FIG. 9 , the optional embodiment may include the following steps:
- Step S902 the Diameter entity A sends a keepalive detection request message Keep Alive Request (KAR) to the DRA;
- KAR Keep Alive Request
- Step S904 the DRA forwards the KAR message to the Diameter entity B;
- Step S906 the Diameter entity B detects that it has the ability to process the service, and returns a Keep Alive Answer (KAA) to the DRA;
- KAA Keep Alive Answer
- step S908 the DRA forwards the KAA message to the Diameter entity A.
- Diameter entity A knows that entity B has the processing capability to handle certain types of services.
- Diameter entity B has a standby disaster-tolerant entity C.
- the Diameter entity A also determines that the entity C also has the processing capability for processing a certain type of service through the above-mentioned KAR/KAA interaction method, so that the Diameter entity A can be based on the disaster tolerance policy.
- This type of service message is sent to entity B or entity C.
- the optional embodiment proposes a method for detecting whether the network element entity is available end-to-end, and detecting by adding a set of end-to-end detection messages.
- the specific implementation of the present embodiment is not limited to the method of detecting the KAR and the KAA message.
- Some service interfaces can re-use the existing message for the keep-alive detection, such as policy and charging control (PCC).
- PCC policy and charging control
- the architecture may use a Re-Auth-Request (RAR) ⁇ Re-Auth-Answer (RAA) for detection.
- RAR Re-Auth-Request
- RAA Re-Auth-Answer
- KAR keep-alive check messages
- KAA keep-alive check messages
- the Session-Id can increase the application identifier of the upper interface (if the Auth-Application-Id is carried, it does not increase).
- the high 32-bit system startup time can be specially processed, such as taking a value of 0, so as to ensure that the Session-Id value of the KAR probe message is fixed.
- the KAR message carries the keepalive capability Auth-Application-Id between the source host and the destination host device. This indicates that the local Diameter implementation needs to detect which capabilities of the peer are still available.
- the Result-Code will return all support (DIAMETER_SUCCESS, 2001). If only some of the service capabilities are supported, the partial support will be returned (DIAMETER_LIMITED_SUCCESS, 2002). If not, the application will not be returned. Support (DIAMETER_APPLICATION_UNSUPPORTED, 3007).
- the process of detecting whether an end-to-end entity is available by using the above message may include the following steps:
- Step S1101 The Diameter local entity A pre-configures the keep-alive detection period Tp (if set between 5 seconds and 120 seconds) and the number of detection times Tw (if set to 0 to 10 times, if set to 0, it means that the live maintenance is not required. Message detection), does not reply to the pause detection duration (if set to 0 ⁇ 0xFFFF hours, 0 is always detected, 0xFFFF is no longer detected, other time is the pause period);
- Step S1102 The Diameter local entity A sends a keep-alive detection request message KAR, and sets a timer to a Tp period.
- Step S1103 If there is a DRA device, the DRA forwards the KAR message to the Diameter destination entity B;
- Step S1104 The Diameter destination entity B detects that it has the ability to process the service, and restores the three values of the foregoing RAA, and carries the service capability supported by the local end in the KAA;
- Step S1105 If there is a DRA device, the DRA forwards the KAA message to the Diameter entity A;
- Step S1106 The Diameter local entity A receives the KAA message. If the KAA result is partially supported or not supported, the capability of the KAR message and the KAA message is compared, indicating that the service capability of the KAR message does not appear in the KAA. Entity B does not support, and the subsequent Diameter local entity A no longer sends unsupported service messages to the Diameter destination entity B.
- Step S1107 The Tp period is up, the timer is reset to the Tp period, and the number of detection non-recovery times is cleared, and steps S1102 to S1106 are repeated.
- step S1106 the KAA message is not received by the Diameter local entity A in the Tp period, and the exception processing flow is started:
- step S1101 the TAA message is not received in the Tp period to the Diameter local entity A, and then the KAR message is sent in step S1102, and the number of non-responses is increased by one;
- step S1102 the number of non-response detections reaches the set Tw, and the interval is determined according to the length of the non-response pause detection period and then re-detected.
- FIG. 10 and FIG. 11 respectively show the available end-to-end primary server network element entities and the end-to-end standby server network element entities, and then To implement disaster recovery switching, the disaster recovery switch can include the following steps:
- Step S1201 According to the detection method of the first embodiment, the local entity A of FIG. 10 detects that the entity B is available;
- Step S1202 The local entity A sends a service message to the entity B for processing;
- Step S1203 According to the detection method of the first embodiment, the local entity A in FIG. 11 detects that the entity B is unavailable;
- Step S1204 According to the detection method of the first embodiment, the local entity A of FIG. 11 detects that the entity C is available;
- Step S1205 The local entity A sends a service message to the entity C according to the configuration of the destination disaster recovery handover.
- the DR can be switched back, and the DR is switched back. That is, during the normal processing of the service process by the standby server entity C, the active server entity B is detected, and the local entity A is detected. If the DR is configured, the local entity A sends a service message to the active server entity B.
- the DR can include the following steps:
- Step S1301 According to the detection method of step S1101 to step S1107, the local entity A in FIG. 10 detects that the entity B is available;
- Step S1302 The local entity A sends a service message to the entity B for processing;
- Step S1303 According to the detection method of the first embodiment, the local entity A in FIG. 11 detects that the entity B is unavailable;
- Step S1304 According to the detection method of the first embodiment, the local entity A in FIG. 11 detects that the entity C is available;
- Step S1305 The local entity A sends the service message to the entity C according to the configuration of the destination disaster recovery handover.
- Step S1306 According to the detection method of the first embodiment, the local entity A in FIG. 10 re-detects that the entity B is available;
- Step S1307 The local entity A determines whether to perform disaster recovery and switchback according to the configuration requirements of the disaster recovery, and if the disaster recovery needs to be switched back to the entity B;
- Step S1308 The local entity A sends a service message to the entity B for processing.
- Load sharing can also be implemented in this alternative embodiment.
- Load sharing that is, during the normal processing of the service processes of the two destination server entities B and C, the local entity A detects that the server entity B and the entity C are available to an application, and whether the local entity A performs the requirements according to the planning or configuration policy.
- the load balancing is performed.
- the local entity A sends a service message to the server entity B and the entity C according to the load sharing policy.
- the load sharing can include the following steps:
- Step S1401 According to the detection method of the first embodiment, the local entity A of FIG. 12 detects that the entity B and the entity C are available;
- Step S1402 The local entity A sends a service message to the entity B according to the load sharing policy, and the load sharing policy includes a policy according to the percentage of the message, the number of messages, and the type of the application;
- Step S1403 The local entity A sends a service message to the entity C according to the load sharing policy.
- the client network element entity can control whether the service is sent to the primary server network element entity or the standby server network element entity.
- modules or steps of the present invention described above can be implemented by a general-purpose computing device that can be centralized on a single computing device or distributed across a network of multiple computing devices. Alternatively, they may be implemented by program code executable by the computing device such that they may be stored in the storage device by the computing device and, in some cases, may be different from the order herein.
- the steps shown or described are performed, or they are separately fabricated into individual integrated circuit modules, or a plurality of modules or steps thereof are fabricated as a single integrated circuit module.
- the invention is not limited to any specific combination of hardware and software.
- the first probe request message is sent to the second network element by using the first network element, where the first probe request message is used to detect whether the second network element supports one or more
- the first network element receives the first feedback information sent by the second network element, where the first feedback information is used to indicate that the second network element supports the one or more specified services.
- the problem in the related art is that the one-end network element cannot learn the service supported by the other end network element, and the one-end network element can learn the service supported by the other end network element.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了业务能力探测方法及装置,其中,该方法包括:第一网元向第二网元发送第一探测请求消息,其中,第一探测请求消息用于探测第二网元是否支持一个或多个指定业务;第一网元接收第二网元发送的第一反馈信息,其中,第一反馈信息用于指示第二网元对上述一个或多个指定业务的支持情况。通过本发明解决了相关技术中由于一端网元无法获知另一端网元所支持的业务导致的问题,进而实现了一端网元可以获知另一端网元所支持的业务。
Description
本发明涉及通信领域,具体而言,涉及业务能力探测方法及装置。
根据RFC3588 Diameter基础协议,可以通过Diameter链路上发送设备看门狗请求(Device-Watchdog-Request,简称为DWR)/设备看门狗响应(Device-Watchdog-Answer,简称为DWA)检测对等端实体是否可用。同时,基础协议也提出了首要对等端和次要对等端概念,并通过DWR/DWA消息检测进行失败替换和失败恢复。
图1是根据相关技术的Diameter首要对等端正常工作或启动Fail Back后工作示意图,如图1所示,在系统正常通信过程中,Diameter对等实体与首要对等端和次要对等端分别建立Diameter连接,在Diameter对等实体间进行数据处理过程中,Diameter对等实体一般与首要对等端进行数据处理,而Diameter对等实体虽然与次要对等端也建立Diameter连接,但一般不能进行Diameter数据处理。一旦首要对等端由于过载或其他原因处理失败,引起Fail Over过程,即失败替换策略,此时,次要对等端就会充当首要对等端,继续与Diameter对等实体进行通信。图2是根据相关技术的Diameter启动Fail Over后次要对等端正常工作示意图,如图2所示,当原先的首要对等端恢复了其处理能力后,就会与Diameter对等实体重新建立连接,达到稳定状态后启动故障回复(Fail Back)过程,即失败恢复策略,使其重新成为首要对等端,又返回到图1的状态。
在对等端实体间链路上检测链路,并根据检测结果进行失败倒换方法存在如下缺点:失败替换和失败恢复策略只适合链路自动切换的场景,发起侧业务无法有效干预。这是由于一端网元无法获知另一端网元所支持的业务导致的。
针对相关技术中,由于一端网元无法获知另一端网元所支持的业务导致的问题,还没有提出有效的解决方案。
发明内容
本发明提供了一种业务能力探测方法及装置,以至少解决相关技术中由于一端网元无法获知另一端网元所支持的业务导致的问题。
根据本发明的一个实施例,提供了一种业务能力探测方法,包括:第一网元向第二网元发送第一探测请求消息,其中,所述第一探测请求消息用于探测所述第二网元是否支持一个或多个指定业务;所述第一网元接收所述第二网元发送的第一反馈信息,其中,所述第一反馈信息用于指示所述第二网元对所述一个或多个指定业务的支持情况。
进一步地,所述方法还包括:所述第一网元向第三网元发送第二探测请求消息,其中,所述第二探测请求消息用于探测所述第三网元是否支持所述一个或多个指定业务;所述第一网元接收所述第三网元发送的第二反馈信息,其中,所述第二反馈信息用于指示所述第三网元对所述一个或多个指定业务的支持情况;所述第一网元确定所述第三网元为所述第二网元的备用网元。进一步地,所述方法还包括:所述第一网元在发送所述第一探测请求消息达到预定次数之后或者在预定时长内未收到所述第一反馈信息的情况下,所述第一网元确定所述第二网元不可用;和/或,所述第一网元在发送所述第二探测请求消息达到预定次数之后或者在预定时长内未收到所述第二反馈信息的情况下,所述第一网元确定所述第三网元不可用。
进一步地,所述第一网元向所述第二网元发送所述第一探测请求消息或者所述第一网元向所述第三网元发送所述第二探测请求消息包括:所述第一网元根据预先配置的周期向所述第二网元发送所述第一探测请求消息;和/或,所述第一网元根据预先配置的周期向所述第三网元发送所述第二探测请求消息。
进一步地,所述方法还包括:所述第一反馈信息包括以下之一:所述第二网元支持所述一个或多个指定业务中的所有指定业务、所述第二网元对所述一个或多个指定业务中的指定业务均不支持、所述第二网元支持所述一个或多个指定业务中的部分指定业务;和/或,所述第二反馈信息包括以下之一:所述第三网元支持所述一个或多个指定业务中的所有指定业务、所述第三网元对所述一个或多个指定业务中的指定业务均不支持、所述第三网元支持所述一个或多个指定业务中的部分指定业务。
进一步地,所述第一网元、所述第二网元和所述第三网元均为Diameter实体。
进一步地,所述方法还包括:所述第一网元通过路由代理实体DRA发送所述第一探测请求消息和/或第二探测请求消息;和/或,所述第一网元通过所述路由代理实体DRA接收所述第一反馈信息和/或所述第二反馈信息。
进一步地,所述第一网元接收所述第一反馈信息和所述第二反馈信息之后,所述方法还包括:所述第一网元将第一指定业务发送至所述第二网元进行处理,其中,所述第一指定业务是所述第二网元支持的业务消息;在所述第一反馈信息指示所述第一指定业务为所述第二网元不支持的业务时,所述第一网元将所述第一指定业务发送至所述第三网元进行处理。
进一步地,所述方法还包括:在所述第一反馈信息指示所述第二网元恢复支持所述第一指定业务时,所述第一网元将所述第一指定业务发送至所述第二网元。
进一步地,所述方法还包括:在所述第一网元确定所述第二网元和所述第三网元均支持第二指定业务时,所述第一网元根据负荷分担策略将所述第二指定业务发送给所述第二网元和所述第三网元进行处理。
根据本发明的另一个实施例,还提供了一种业务能力探测方法,包括:第二网元接收第一网元发送的第一探测请求消息,其中,所述第一探测请求消息用于探测所述第二网元是否支持一个或多个指定业务;所述第二网元检测自身支持的业务能力,确定所述第二网元是否支持所述一个或多个指定业务,并生成第一反馈信息;所述第二网元将所述第一反馈信息发送给所述第一网元。
进一步地,所述方法还包括:第三网元接收所述第一网元发送的第二探测请求消息,其中,所述第二探测请求消息用于探测所述第三网元是否支持一个或多个指定业务;所述第三网元检测自身支持的业务能力,确定所述第三网元是否支持所述一个或多个指定业务,并生成第二反馈信息;所述第三网元将所述第二反馈信息发送给所述第一网元;其中,所述第三网元为所述第二网元的备用网元。
进一步地,所述方法还包括:所述第二网元在接收到所述第一探测请求消息达到预定次数之后或者在预定时长内未发送所述第一反馈信息的情况下,则确定所述第二网元不可用;和/或,所述第三网元在接收到所述第二探测请求消息达到预定次数之后或者在预定时长内未发送所述第二反馈信息的情况下,则确定所述第三网元不可用。
进一步地,所述第二网元接收所述第一网元发送的所述第一探测请求消息或者所述第三网元接收所述第一网元发送的所述第二探测请求消息包括:所述第二网元根据
预先配置的周期接收所述第一网元发送所述第一探测请求消息;和/或,所述第三网元根据预先配置的周期接收所述第一网元发送所述第二探测请求消息。
进一步地,所述方法还包括:所述第一反馈信息包括以下之一:所述第二网元支持所述一个或多个指定业务中的所有指定业务、所述第二网元对所述一个或多个指定业务中的指定业务均不支持、所述第二网元支持所述一个或多个指定业务中的部分指定业务;和/或所述第二反馈信息包括以下之一:所述第三网元支持所述一个或多个指定业务中的所有指定业务、所述第三网元对所述一个或多个指定业务中的指定业务均不支持、所述第三网元支持所述一个或多个指定业务中的部分指定业务。
进一步地,所述第一网元、所述第二网元和所述第三网元均为Diameter实体。
进一步地,所述方法还包括:所述第二网元通过路由代理实体DRA接收所述探测请求消息,和/或所述第二网元通过所述路由代理实体DRA将所述第一反馈信息发送给所述第一网元;和/或所述第三网元通过路由代理实体DRA接收所述探测请求消息,和/或所述第三网元通过所述路由代理实体DRA将所述第二反馈信息发送给所述第一网元。
进一步地,所述第二网元和所述第三网元向所述第一网元发送所述第一反馈信息和所述第二反馈信息之后,所述方法还包括:在所述第一反馈信息指示所述第二网元不支持第一指定业务时,由所述第三网元执行所述第一指定业务。
进一步地,所述方法还包括:在所述第一反馈信息指示所述第二网元恢复支持所述第一指定业务时,由所述第二网元执行所述第一指定业务。
进一步地,所述方法还包括:在所述第一反馈信息和所述第二反馈信息指示均支持第二指定业务时,所述第二网元和所述第三网元根据负荷分担策略执行所述第二指定业务。
根据本发明的一个实施例,还提供了一种业务能力探测装置,应用于第一网元,包括:第一发送模块,设置为向第二网元发送第一探测请求消息,其中,所述第一探测请求消息用于探测所述第二网元是否支持一个或多个指定业务;第一接收模块,设置为接收所述第二网元发送的第一反馈信息,其中,所述第一反馈信息用于指示所述第二网元对所述一个或多个指定业务的支持情况。
进一步地,所述装置还包括:第二发送模块,设置为向第三网元发送第二探测请求消息,其中,所述第二探测请求消息用于探测所述第三网元是否支持所述一个或多
个指定业务;第二接收模块,设置为接收所述第三网元发送的第二反馈信息,其中,所述第二反馈信息用于指示所述第三网元对所述一个或多个指定业务的支持情况;确定模块,设置为确定所述第三网元为所述第二网元的备用网元。
进一步地,所述第一反馈信息包括以下之一:所述第二网元支持所述一个或多个指定业务中的所有指定业务、所述第二网元对所述一个或多个指定业务中的指定业务均不支持、所述第二网元支持所述一个或多个指定业务中的部分指定业务;和/或,所述第二反馈信息包括以下之一:所述第三网元支持所述一个或多个指定业务中的所有指定业务、所述第三网元对所述一个或多个指定业务中的指定业务均不支持、所述第三网元支持所述一个或多个指定业务中的部分指定业务。
进一步地,所述第一网元、所述第二网元和所述第三网元均为Diameter实体。
根据本发明的另一个实施例,还提供了一种业务能力探测装置,包括:第一接收模块,所述第一接收模块应用于第二网元,设置为接收第一网元发送的第一探测请求消息,其中,所述第一探测请求消息用于探测所述第二网元是否支持一个或多个指定业务;第一检测模块,所述第一检测模块应用于所述第二网元,设置为检测自身支持的业务能力,确定所述第二网元是否支持所述一个或多个指定业务,并生成第一反馈信息;第一发送模块,所述第一发送模块应用于所述第二网元,设置为将所述第一反馈信息发送给所述第一网元。
进一步地,所述装置还包括:第二接收模块,所述第二接收模块应用于第三网元,设置为接收所述第一网元发送的第二探测请求消息,其中,所述第二探测请求消息用于探测所述第三网元是否支持一个或多个指定业务;第二检测模块,所述第二检测模块应用于所述第三网元,用检测自身支持的业务能力,确定所述第三网元是否支持所述一个或多个指定业务,并生成第二反馈信息;第二发送模块,所述第二发送模块应用于所述第三网元,设置为将所述第二反馈信息发送给所述第一网元;其中,所述第三网元为所述第二网元的备用网元。
进一步地,所述第一反馈信息包括以下之一:所述第二网元支持所述一个或多个指定业务中的所有指定业务、所述第二网元对所述一个或多个指定业务中的指定业务均不支持、所述第二网元支持所述一个或多个指定业务中的部分指定业务;和/或所述第二反馈信息包括以下之一:所述第三网元支持所述一个或多个指定业务中的所有指定业务、所述第三网元对所述一个或多个指定业务中的指定业务均不支持、所述第三网元支持所述一个或多个指定业务中的部分指定业务。
进一步地,所述第一网元、所述第二网元和所述第三网元均为Diameter实体。
通过本发明,采用第一网元向第二网元发送第一探测请求消息,其中,第一探测请求消息用于探测第二网元是否支持一个或多个指定业务;第一网元接收第二网元发送的第一反馈信息,其中,第一反馈信息用于指示第二网元对上述一个或多个指定业务的支持情况。解决了相关技术中由于一端网元无法获知另一端网元所支持的业务导致的问题,进而实现了一端网元可以获知另一端网元所支持的业务。
此处所说明的附图用来提供对本发明的进一步理解,构成本申请的一部分,本发明的示意性实施例及其说明用于解释本发明,并不构成对本发明的不当限定。在附图中:
图1是根据相关技术的Diameter首要对等端正常工作或启动Fail Back后工作示意图;
图2是根据相关技术的Diameter启动Fail Over后次要对等端正常工作示意图;
图3是根据本发明实施例的业务能力探测方法的流程图;
图4是根据本发明实施例的业务能力探测装置的结构框图;
图5是根据本发明实施例的业务能力探测装置的结构框图一;
图6是根据本发明实施例的业务能力探测方法的流程图一;
图7是根据本发明实施例的业务能力探测装置的结构框图二;
图8是根据本发明实施例的业务能力探测装置的结构框图三;
图9是根据本发明实施例的端到端保活检测Diameter网元实体可用示意图;
图10是根据本发明实施例的端到端主服务器网元实体可用示意图;
图11是根据本发明实施例的端到端备服务器网元实体可用示意图;
图12是根据本发明实施例的端到端负荷分担的两个服务器网元实体可用示意图。
下文中将参考附图并结合实施例来详细说明本发明。需要说明的是,在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互组合。
在本实施例中提供了一种业务能力探测方法,图3是根据本发明实施例的业务能力探测方法的流程图,如图3所示,该流程包括如下步骤:
步骤S302,第一网元向第二网元发送第一探测请求消息,其中,第一探测请求消息用于探测第二网元是否支持一个或多个指定业务;
步骤S304,第一网元接收第二网元发送的第一反馈信息,其中,第一反馈信息用于指示第二网元对该一个或多个指定业务的支持情况。
通过上述步骤,第一网元向第二网元发送第二网元是否支持指定业务的探测请求消息,第二网元将其所支持的指定业务反馈给第一网元,从而解决了相关技术中由于一端网元无法获知另一端网元所支持的业务导致的问题,进而实现了一端网元可以获知另一端网元所支持的业务。通过上述步骤也为其他业务的实现提供了可能,例如,在相关技术中,由于客户端网元无法获知服务器端网元所支持的业务,如果某客户端网元实体需要支持服务器网元实体的某种业务容灾功能,则需要人为控制业务消息的处理。通过上述步骤,客户端可以获知服务器网元所支持的情况,则客户端可以自行选择需要的服务器网元,进而可以实现诸如容灾等功能。
下面的一个可选实施例利用了上述步骤从而实现了容灾的处理。
在该可选实施例中,第一网元向第三网元发送第二探测请求消息,其中,第二探测请求消息用于探测第三网元是否支持该一个或多个指定业务;第一网元接收第三网元发送的第二反馈信息,其中,第二反馈信息用于指示第三网元对该一个或多个指定业务的支持情况。从而,第一网元获取了第二网元及其备用网元第三网元对指定业务的支持情况,基于此第一网元可以根据获取到的该结果对指定业务进行控制。其中,第一探测请求消息和第二探测请求消息可以为相同的探测请求消息也可以为不同的探测请求消息。
在一个可选实施例中,还可以对第二网元或者第三网元是否可用进行判断,具体地,第一网元在发送第一探测请求消息达到预定次数之后或者在预定时长内未收到第一反馈信息的情况下,第一网元确定第二网元不可用;和/或,第一网元在发送第二探测请求消息达到预定次数之后或者在预定时长内未收到第二反馈信息的情况下,第一
网元确定第三网元不可用。在第一网元确认第二网元/第三网元不可用的情况下,就不会为第二网元/第三网元发送业务。
第一网元可以按周期向其他网元发送探测请求消息,在一个可选实施例中,第一网元根据预先配置的周期向第二网元发送第一探测请求消息;和/或,第一网元根据预先配置的周期向第三网元发送第二探测请求消息。
在上述实施例中,第二网元或者第三网元通过第一反馈信息和第二反馈信息来进行反馈,第一反馈信息和第二反馈信息仅仅是为了标识这两个反馈信息,不应当理解为任何的其他限定。这两个反馈信息可以包括各种信息,根据实际的需要进行配置即可。在一个可选实施例中,第一反馈信息可以包括以下之一:第二网元支持该一个或多个指定业务中的所有指定业务、第二网元对该一个或多个指定业务中的指定业务均不支持、第二网元支持该一个或多个指定业务中的部分指定业务;在另一个可选实施例中,第二反馈信息可以包括以下之一:第三网元支持该一个或多个指定业务中的所有指定业务、第三网元对该一个或多个指定业务中的指定业务均不支持、第三网元支持该一个或多个指定业务中的部分指定业务。
在第一网元接收第一反馈信息和第二反馈信息之后,即第一网元获知了第二网元和第三网元对指定业务的支持情况之后,第一网元可以将第一指定业务发送至第二网元进行处理,其中,第一指定业务是第二网元支持的业务消息,第三网元作为第二网元的备用网元,在第一反馈信息指示第一指定业务为第二网元不支持的业务时(例如,第二网元临时关闭了对该第一指定业务的支持),第一网元将第一指定业务发送至第三网元进行处理。在另一可选实施例中,在第一反馈信息指示第二网元恢复支持第一指定业务时,第一网元将第一指定业务发送至第二网元进行第一指定业务的处理。进而实现了在第二网元不支持指定业务时,由第二网元的备用网元进行该指定业务的处理。
第三网元作为第二网元的备用网元,两者可以对共同支持的指定业务进行分担处理,在另一个可选实施例中,在第一网元确定第二网元和第三网元均支持第二指定业务时,第一网元根据负荷分担策略将第二指定业务发送给第二网元和第三网元进行处理。其中,第二指定业务与上述第一指定业务可以为相同的业务,也可以为不同的业务。
上述的实施例及可选实施方式可以适用于各种实体,例如,在一个可选实施例中,上述涉及到的第一网元、第二网元和第三网元可以均为Diameter实体。
对于某些类型的实体,例如,Diameter实体,是无法检测Diameter客户端实体通过路由代理(Diameter Route Agent,简称为DRA)中转后到达Diameter服务器的路径是否可达的。
在一个可选的实施例,第一网元可以通过路由代理实体DRA发送第一探测请求消息和/或第二探测请求消息。在另一个可选实施例中,第一网元也可以通过路由代理实体DRA接收第一反馈信息和/或第二反馈信息。
在本实施例中还提供了一种业务能力探测装置,该装置用于实现上述实施例及可选实施方式,已经进行过说明的不再赘述。如以下所使用的,术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现,但是硬件,或者软件和硬件的组合的实现也是可能并被构想的。
图4是根据本发明实施例的业务能力探测装置的结构框图,该装置应用于第一网元,如图4包括:第一发送模块42,设置为向第二网元发送第一探测请求消息,其中,第一探测请求消息用于探测第二网元是否支持一个或多个指定业务;第一接收模块44,设置为接收第二网元发送的第一反馈信息,其中,第一反馈信息用于指示该第二网元对该一个或多个指定业务的支持情况。
图5是根据本发明实施例的业务能力探测装置的结构框图一;如图5所示,该装置还包括:第二发送模块52,设置为向第三网元发送第二探测请求消息,其中,第二探测请求消息用于探测第三网元是否支持该一个或多个指定业务;第二接收模块54,设置为接收第三网元发送的第二反馈信息,其中,第二反馈信息用于指示第三网元对该一个或多个指定业务的支持情况;确定模块56,设置为确定第三网元为第二网元的备用网元。
在一个可选的实施例中,第一反馈信息可以包括以下之一:第二网元支持该一个或多个指定业务中的所有指定业务、第二网元对该一个或多个指定业务中的指定业务均不支持、第二网元支持该一个或多个指定业务中的部分指定业务;和/或,第二反馈信息包括以下之一:第三网元支持该一个或多个指定业务中的所有指定业务、第三网元对该一个或多个指定业务中的指定业务均不支持、第三网元支持该一个或多个指定业务中的部分指定业务。
在另一个可选的实施例中,第一网元、第二网元和第三网元可以均为Diameter实体。
上述实施例及可选实施方式是从发起探测请求消息的一侧描述的,下面从接收探测请求消息的一侧进行描述。
在本实施例中提供了另一种业务能力探测方法,图6是根据本发明实施例的业务能力探测方法的流程图一,如图6所示,该流程包括如下步骤:
步骤S602,第二网元接收第一网元发送的第一探测请求消息,其中,第一探测请求消息用于探测第二网元是否支持一个或多个指定业务;
步骤S604,第二网元检测自身支持的业务能力,确定第二网元是否支持该一个或多个指定业务,并生成第一反馈信息;
步骤S606,第二网元将第一反馈信息发送给第一网元。
通过上述步骤,第二网元根据接收到的第一网元的探测请求消息,检测自身支持的业务能力,确定其对指定业务的支持情况,并将其所支持的指定业务反馈给第一网元,从而解决了相关技术中由于一端网元无法获知另一端网元所支持的业务导致的问题,进而实现了一端网元可以获知另一端网元所支持的业务。通过上述步骤也为其他业务的实现提供了可能,例如,在相关技术中,由于客户端网元无法获知服务器端网元所支持的业务,如果某客户端网元实体需要支持服务器网元实体的某种业务容灾功能,则需要人为控制业务消息的处理。通过上述步骤,客户端可以获知服务器网元所支持的情况,则客户端可以自行选择需要的服务器网元,进而可以实现诸如容灾等功能。
在确定第二网元的备用网元为第三网元的情况下,在一个可选实施例中,第三网元接收第一网元发送的第二探测请求消息,其中,第二探测请求消息用于探测第三网元是否支持一个或多个指定业务;第三网元检测自身支持的业务能力,确定第三网元是否支持该一个或多个指定业务,并生成第二反馈信息;第三网元将该第二反馈信息发送给该第一网元;其中,第三网元为该第二网元的备用网元。其中,第一探测请求消息和第二探测请求消息可以为相同的探测请求消息也可以为不同的探测请求消息。
在一个可选实施例中,还可以对第二网元或者第三网元是否可用进行判断,具体地,第二网元在接收到第一探测请求消息达到预定次数之后或者在预定时长内未发送第一反馈信息的情况下,则确定第二网元不可用;和/或,第三网元在接收到第二探测请求消息达到预定次数之后或者在预定时长内未发送第二反馈信息的情况下,则确定第三网元不可用。
第二网元或第三网元可以按周期接收第一网元发送探测请求消息,在一个可选实施例中,第二网元根据预先配置的周期接收第一网元发送第一探测请求消息;和/或,第三网元根据预先配置的周期接收第一网元发送第二探测请求消息。
在上述实施例中,第二网元或者第三网元通过第一反馈信息和第二反馈信息来进行反馈,第一反馈信息和第二反馈信息仅仅是为了标识这两个反馈信息,不应当理解为任何的其他限定。这两个反馈信息可以包括各种信息,根据实际的需要进行配置即可。在一个可选实施例中,第一反馈信息可以包括以下之一:第二网元支持该一个或多个指定业务中的所有指定业务、第二网元对该一个或多个指定业务中的指定业务均不支持、第二网元支持该一个或多个指定业务中的部分指定业务;在另一个可选实施例中,第二反馈信息可以包括以下之一:第三网元支持该一个或多个指定业务中的所有指定业务、第三网元对该一个或多个指定业务中的指定业务均不支持、第三网元支持该一个或多个指定业务中的部分指定业务。
在第二网元和第三网元向第一网元发送第一反馈信息和第二反馈信息之后,即第一网元获知了第二网元和第三网元对指定业务的支持情况之后,在一个可选实施例中,在第一反馈信息指示第二网元不支持第一指定业务时(例如,第二网元临时关闭了对该第一指定业务的支持),由第三网元执行第一指定业务。进而实现了在第二网元不支持指定业务时,由第二网元的备用网元进行该指定业务的处理。在另一可选实施例中,在第一反馈信息指示第二网元恢复支持第一指定业务时,由第二网元执行该第一指定业务。
第三网元作为第二网元的备用网元,两者可以对共同支持的指定业务进行分担处理,在一个可选实施例中,在第一反馈信息和第二反馈信息指示均支持第二指定业务时,第二网元和第三网元根据负荷分担策略执行第二指定业务。其中,第二指定业务与上述第一指定业务可以为相同的业务,也可以为不同的业务。
上述的实施例及可选实施方式可以适用于各种实体,例如,在一个可选实施例中,上述涉及到的第一网元、第二网元和第三网元可以均为Diameter实体。
对于某些类型的实体,例如,Diameter实体,是无法检测Diameter客户端实体通过路由代理(Diameter Route Agent,简称为DRA)中转后到达Diameter服务器的路径是否可达的。
在一个可选的实施例,第二网元或者第三网元可以通过路由代理实体DRA接收第一网元发送第一探测请求消息和/或第二探测请求消息。在另一个可选实施例中,第
二网元或者第三网元也可以通过路由代理实体DRA发送第一反馈信息和/或第二反馈信息。
在本实施例中还提供了一种业务能力探测装置,该装置用于实现上述实施例及可选实施方式,已经进行过说明的不再赘述。如以下所使用的,术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现,但是硬件,或者软件和硬件的组合的实现也是可能并被构想的。
图7是根据本发明实施例的业务能力探测装置的结构框图二,如图7所示,该装置包括:第一接收模块72,第一接收模块72应用于第二网元,设置为接收第一网元发送的第一探测请求消息,其中,第一探测请求消息用于探测第二网元是否支持一个或多个指定业务;第一检测模块74,第一检测模块74应用于第二网元,设置为检测自身支持的业务能力,确定第二网元是否支持该一个或多个指定业务,并生成第一反馈信息;第一发送模块76,第一发送模块76应用于第二网元,设置为将第一反馈信息发送给第一网元。
图8是根据本发明实施例的业务能力探测装置的结构框图三,如图8所示,该装置还包括:第二接收模块82,第二接收模块82应用于第三网元,设置为接收第一网元发送的第二探测请求消息,其中,第二探测请求消息用于探测该第三网元是否支持一个或多个指定业务;第二检测模块84,第二检测模块84应用于第三网元,用检测自身支持的业务能力,确定第三网元是否支持该一个或多个指定业务,并生成第二反馈信息;第二发送模块86,第二发送模块86应用于第三网元,设置为将第二反馈信息发送给第一网元;其中,第三网元为第二网元的备用网元。
在一个可选实施例中,第一反馈信息包括以下之一:第二网元支持该一个或多个指定业务中的所有指定业务、第二网元对该一个或多个指定业务中的指定业务均不支持、第二网元支持该一个或多个指定业务中的部分指定业务;和/或第二反馈信息包括以下之一:第三网元支持该一个或多个指定业务中的所有指定业务、第三网元对该一个或多个指定业务中的指定业务均不支持、第三网元支持该一个或多个指定业务中的部分指定业务;
在一个可选实施例中,第一网元、第二网元和第三网元均为Diameter实体。
下面以第一网元、第二网元和第三网元均为Diameter实体为例结合一个可选的实施例进行说明。
本可选实施例提出了一种检测端到端Diameter实体网元可用的方法,通过规定一组业务层面的心跳探测消息来感知目标Diameter实体业务是否可用。
图9是根据本发明实施例的端到端保活检测Diameter网元实体可用示意图,本可选实施例提出的如图9所示,可以包括以下步骤:
步骤S902,Diameter实体A发送保活检测请求消息Keep Alive Request(KAR)给DRA;
步骤S904,DRA转发KAR消息给Diameter实体B;
步骤S906,Diameter实体B检测自身有处理该业务能力,就回送一个Keep Alive Answer(KAA)给DRA;
步骤S908,DRA将KAA消息转发给Diameter实体A。
这样Diameter实体A就知道实体B具有处理某类业务的处理能力。
假定Diameter实体B存在一个备用容灾的实体C,Diameter实体A也同样通过上述KAR/KAA交互的方法确定实体C也具有处理某类业务的处理能力,这样Diameter实体A就可以根据容灾策略将该类业务消息发送到实体B或实体C。
与现有协议标准相比,本可选实施例提出了一种端到端检测网元实体是否可用的方法,通过增加了一组端到端的探测消息进行检测。
本可选实施例的具体实施方式不限于KAR、KAA消息检测的方式,某些业务接口可以复用已存在的消息进行保活探测,如策略和计费控制(Policy and Charging Control,简称为PCC)架构中可采用推送重授权请求(Re-Auth-Request简称为RAR)\重授权应答(Re-Auth-Answer,简称为RAA)进行探测。
在本可选实施例定义了一对保活检查消息KAR、KAA消息,KAR、KAA消息定义如下:
Session-Id除了按照RFC3588协议规定的<DiameterIdentity>;<high 32bits>;<low 32bits>[;<optional value>]可选项内容可增加上接口应用标识(若携带Auth-Application-Id,可不增加),同时高32位取系统启动时间可以作特别处理,如取0值,这样确保KAR探测消息的Session-Id值固定不变。
KAR消息同时携带源主机和目的主机设备间的保活能力Auth-Application-Id,表明本端Diameter实现需要探测对端哪些能力仍然可用。
如果目标Diameter设备支持KAR携带的所有能力,Result-Code则回送全部支持(DIAMETER_SUCCESS,2001),若只支持部分业务能力,则回送部分支持(DIAMETER_LIMITED_SUCCESS,2002),若都不支持,则回复应用不支持(DIAMETER_APPLICATION_UNSUPPORTED,3007)。
采用上述消息检测端到端实体是否可用的流程可以包括如下步骤:
步骤S1101:Diameter本端实体A预先配置保活探测周期Tp(如设置在5秒至120秒之间)、探测次数Tw(如设置为0至10次,设置为0,则表示不用发保活消息探测)、不回复暂停检测时长(如设置为0~0xFFFF小时,0为一直探测,0xFFFF为不再探测,其它时间为暂停周期);
步骤S1102:Diameter本端实体A发送保活检测请求消息KAR,并设置定时器为Tp周期;
步骤S1103:若存在DRA设备,DRA转发KAR消息至Diameter目的端实体B;
步骤S1104:Diameter目的端实体B检测自身有处理这些业务能力,回复前述RAA的三种取值,并在KAA中携带本端支持的业务能力;
步骤S1105:若存在DRA设备,DRA转发KAA消息转发给Diameter实体A;
步骤S1106:Diameter本端实体A收到KAA消息,若KAA结果为部分支持或不支持,比较KAR消息和KAA消息的能力携带情况,说明KAR消息中业务能力没在KAA中出现的能力Diameter目的端实体B不支持,后续Diameter本端实体A不再向Diameter目的端实体B发送不支持的业务消息;
步骤S1107:Tp周期到,重新设置定时器为Tp周期,并将探测不回复次数清零,重复步骤S1102~步骤S1106。
在步骤S1106,在Tp周期到Diameter本端实体A未收到KAA消息,启动异常处理流程:
在步骤S1101,在Tp周期到Diameter本端实体A未收到KAA消息,再重复步骤S1102发送KAR消息,同时探测不回复次数加1;
在步骤S1102,探测不回复次数达到设置的Tw,根据不回复暂停检测时长决定间隔多长时间再重新探测。
基于上述步骤分别检测出端到端主、备服务器网元实体是否可用,图10和图11分别表示端到端主服务器网元实体可用、端到端备服务器网元实体可用的示意图,进而可以实现容灾切换,该容灾切换可以包括如下步骤:
步骤S1201:按照实施例一的检测方法,图10本端实体A检测到实体B可用;
步骤S1202:本端实体A发送业务消息至实体B处理;
步骤S1203:按照实施例一的检测方法,图11本端实体A检测到实体B不可用;
步骤S1204:按照实施例一的检测方法,图11本端实体A检测到实体C可用;
步骤S1205:本端实体A根据目的端容灾切换的配置,将业务消息发送至实体C处理;
在容灾切换之后,在本可选实施例还可以实现容灾切回,容灾切回,即在备用服务器实体C正常处理业务流程期间,检测到主用服务器实体B可用,本端实体A根据容灾的配置要求决定是否进行容灾切回,若需要进行容灾切回,本端实体A发送业务消息至主用服务器实体B,该容灾切回可以包括如下步骤:
步骤S1301:按照上述步骤S1101至步骤S1107的检测方法,图10中的本端实体A检测到实体B可用;
步骤S1302:本端实体A发送业务消息至实体B处理;
步骤S1303:按照实施例一的检测方法,图11中的本端实体A检测到实体B不可用;
步骤S1304:按照实施例一的检测方法,图11中的本端实体A检测到实体C可用;
步骤S1305:本端实体A根据目的端容灾切换的配置,将业务消息发送至实体C处理;
步骤S1306:按照实施例一的检测方法,图10中的本端实体A重新检测到实体B可用;
步骤S1307:本端实体A根据容灾的配置要求决定是否进行容灾切回,若需要容灾切回实体B;
步骤S1308:本端实体A发送业务消息至实体B处理。
在本可选实施例还可以实现负荷分担。负荷分担,即在两个目的服务器实体B和C正常处理业务流程期间,本端实体A检测到服务器实体B和实体C对某种应用均可用,本端实体A根据规划或配置策略要求是否进行负荷分担,若需要进行负荷分担,本端实体A按照负荷分担策略发送业务消息至服务器实体B和实体C。该负荷分担可以包括如下步骤:
步骤S1401:按照实施例一的检测方法,图12本端实体A检测到实体B和实体C可用;
步骤S1402:本端实体A根据负荷分担策略将业务消息发送到实体B,负荷分担策略包括按消息百分比、消息数目、应用类型等策略;
步骤S1403:本端实体A根据负荷分担策略将业务消息发送到实体C。
综上所述,存在一组探测端到端是否可达的消息,能够从客户端网元实体发出,在服务器网元实体接收处理。若客户端能收到正确响应就能确认客户端到服务器网元实体可达。同时,根据到主备服务器网元实体网元是否可达的状态,客户端网元实体就可以控制业务发往主服务器网元实体,还是备服务器网元实体。
显然,本领域的技术人员应该明白,上述的本发明的各模块或各步骤可以用通用的计算装置来实现,它们可以集中在单个的计算装置上,或者分布在多个计算装置所组成的网络上,可选地,它们可以用计算装置可执行的程序代码来实现,从而,可以将它们存储在存储装置中由计算装置来执行,并且在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤,或者将它们分别制作成各个集成电路模块,或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样,本发明不限制于任何特定的硬件和软件结合。
以上所述仅为本发明的可选实施例而已,并不用于限制本发明,对于本领域的技术人员来说,本发明可以有各种更改和变化。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
基于本发明的实施例提供的上述技术方案,通过采用第一网元向第二网元发送第一探测请求消息,其中,第一探测请求消息用于探测第二网元是否支持一个或多个指定业务;第一网元接收第二网元发送的第一反馈信息,其中,第一反馈信息用于指示第二网元对上述一个或多个指定业务的支持情况。解决了相关技术中由于一端网元无法获知另一端网元所支持的业务导致的问题,进而实现了一端网元可以获知另一端网元所支持的业务。
Claims (28)
- 一种业务能力探测方法,包括:第一网元向第二网元发送第一探测请求消息,其中,所述第一探测请求消息用于探测所述第二网元是否支持一个或多个指定业务;所述第一网元接收所述第二网元发送的第一反馈信息,其中,所述第一反馈信息用于指示所述第二网元对所述一个或多个指定业务的支持情况。
- 根据权利要求1所述的方法,其中,所述方法还包括:所述第一网元向第三网元发送第二探测请求消息,其中,所述第二探测请求消息用于探测所述第三网元是否支持所述一个或多个指定业务;所述第一网元接收所述第三网元发送的第二反馈信息,其中,所述第二反馈信息用于指示所述第三网元对所述一个或多个指定业务的支持情况;所述第一网元确定所述第三网元为所述第二网元的备用网元。
- 根据权利要求1或2所述的方法,其中,所述方法还包括:所述第一网元在发送所述第一探测请求消息达到预定次数之后或者在预定时长内未收到所述第一反馈信息的情况下,所述第一网元确定所述第二网元不可用;和/或,所述第一网元在发送所述第二探测请求消息达到预定次数之后或者在预定时长内未收到所述第二反馈信息的情况下,所述第一网元确定所述第三网元不可用。
- 根据权利要求1或2所述的方法,其中,所述第一网元向所述第二网元发送所述第一探测请求消息或者所述第一网元向所述第三网元发送所述第二探测请求消息包括:所述第一网元根据预先配置的周期向所述第二网元发送所述第一探测请求消息;和/或,所述第一网元根据预先配置的周期向所述第三网元发送所述第二探测请求消息。
- 根据权利要求2所述的方法,其中,所述方法还包括:所述第一反馈信息包括以下之一:所述第二网元支持所述一个或多个指定业务中的所有指定业务、所述第二网元对所述一个或多个指定业务中的指定业务均不支持、所述第二网元支持所述一个或多个指定业务中的部分指定业务;和/或,所述第二反馈信息包括以下之一:所述第三网元支持所述一个或多个指定业务中的所有指定业务、所述第三网元对所述一个或多个指定业务中的指定业务均不支持、所述第三网元支持所述一个或多个指定业务中的部分指定业务。
- 根据权利要求1所述的方法,其中,所述第一网元、所述第二网元和所述第三网元均为Diameter实体。
- 根据权利要求5所述的方法,其中,所述方法还包括:所述第一网元通过路由代理实体DRA发送所述第一探测请求消息和/或第二探测请求消息;和/或,所述第一网元通过所述路由代理实体DRA接收所述第一反馈信息和/或所述第二反馈信息。
- 根据权利要求5所述的方法,其中,所述第一网元接收所述第一反馈信息和所述第二反馈信息之后,所述方法还包括:所述第一网元将第一指定业务发送至所述第二网元进行处理,其中,所述第一指定业务是所述第二网元支持的业务消息;在所述第一反馈信息指示所述第一指定业务为所述第二网元不支持的业务时,所述第一网元将所述第一指定业务发送至所述第三网元进行处理。
- 根据权利要求8所述的方法,其中,所述方法还包括:在所述第一反馈信息指示所述第二网元恢复支持所述第一指定业务时,所述第一网元将所述第一指定业务发送至所述第二网元。
- 根据权利要求5所述的方法,其中,所述方法还包括:在所述第一网元确定所述第二网元和所述第三网元均支持第二指定业务时,所述第一网元根据负荷分担策略将所述第二指定业务发送给所述第二网元和所述第三网元进行处理。
- 一种业务能力探测方法,包括:第二网元接收第一网元发送的第一探测请求消息,其中,所述第一探测请求消息用于探测所述第二网元是否支持一个或多个指定业务;所述第二网元检测自身支持的业务能力,确定所述第二网元是否支持所述一个或多个指定业务,并生成第一反馈信息;所述第二网元将所述第一反馈信息发送给所述第一网元。
- 根据权利要求11所述的方法,其中,所述方法还包括:第三网元接收所述第一网元发送的第二探测请求消息,其中,所述第二探测请求消息用于探测所述第三网元是否支持一个或多个指定业务;所述第三网元检测自身支持的业务能力,确定所述第三网元是否支持所述一个或多个指定业务,并生成第二反馈信息;所述第三网元将所述第二反馈信息发送给所述第一网元;其中,所述第三网元为所述第二网元的备用网元。
- 根据权利要求11或12所述的方法,其中,所述方法还包括:所述第二网元在接收到所述第一探测请求消息达到预定次数之后或者在预定时长内未发送所述第一反馈信息的情况下,则确定所述第二网元不可用;和/或,所述第三网元在接收到所述第二探测请求消息达到预定次数之后或者在预定时长内未发送所述第二反馈信息的情况下,则确定所述第三网元不可用。
- 根据权利要求11或12所述的方法,其中,所述第二网元接收所述第一网元发送的所述第一探测请求消息或者所述第三网元接收所述第一网元发送的所述第二探测请求消息包括:所述第二网元根据预先配置的周期接收所述第一网元发送所述第一探测请求消息;和/或,所述第三网元根据预先配置的周期接收所述第一网元发送所述第二探测请求消息。
- 根据权利要求12所述的方法,其中,所述方法还包括:所述第一反馈信息包括以下之一:所述第二网元支持所述一个或多个指定业务中的所有指定业务、所述第二网元对所述一个或多个指定业务中的指定业务均不支持、所述第二网元支持所述一个或多个指定业务中的部分指定业务;和/或所述第二反馈信息包括以下之一:所述第三网元支持所述一个或多个指定业务中的所有指定业务、所述第三网元对所述一个或多个指定业务中的指定业务均不支持、所述第三网元支持所述一个或多个指定业务中的部分指定业务。
- 根据权利要求11所述的方法,其中,所述第一网元、所述第二网元和所述第三网元均为Diameter实体。
- 根据权利要求15所述的方法,其中,所述方法还包括:所述第二网元通过路由代理实体DRA接收所述探测请求消息,和/或所述第二网元通过所述路由代理实体DRA将所述第一反馈信息发送给所述第一网元;和/或所述第三网元通过路由代理实体DRA接收所述探测请求消息,和/或所述第三网元通过所述路由代理实体DRA将所述第二反馈信息发送给所述第一网元。
- 根据权利要求15所述的方法,其中,所述第二网元和所述第三网元向所述第一网元发送所述第一反馈信息和所述第二反馈信息之后,所述方法还包括:在所述第一反馈信息指示所述第二网元不支持第一指定业务时,由所述第三网元执行所述第一指定业务。
- 根据权利要求18所述的方法,其中,所述方法还包括:在所述第一反馈信息指示所述第二网元恢复支持所述第一指定业务时,由所述第二网元执行所述第一指定业务。
- 根据权利要求15所述的方法,其中,所述方法还包括:在所述第一反馈信息和所述第二反馈信息指示均支持第二指定业务时,所述第二网元和所述第三网元根据负荷分担策略执行所述第二指定业务。
- 一种业务能力探测装置,应用于第一网元,包括:第一发送模块,设置为向第二网元发送第一探测请求消息,其中,所述第一探测请求消息用于探测所述第二网元是否支持一个或多个指定业务;第一接收模块,设置为接收所述第二网元发送的第一反馈信息,其中,所述第一反馈信息用于指示所述第二网元对所述一个或多个指定业务的支持情况。
- 根据权利要求21所述的装置,其中,所述装置还包括:第二发送模块,设置为向第三网元发送第二探测请求消息,其中,所述第二探测请求消息用于探测所述第三网元是否支持所述一个或多个指定业务;第二接收模块,设置为接收所述第三网元发送的第二反馈信息,其中,所述第二反馈信息用于指示所述第三网元对所述一个或多个指定业务的支持情况;确定模块,设置为确定所述第三网元为所述第二网元的备用网元。
- 根据权利要求22所述的装置,其中,所述第一反馈信息包括以下之一:所述第二网元支持所述一个或多个指定业务中的所有指定业务、所述第二网元对所述一个或多个指定业务中的指定业务均不支持、所述第二网元支持所述一个或多个指定业务中的部分指定业务;和/或,所述第二反馈信息包括以下之一:所述第三网元支持所述一个或多个指定业务中的所有指定业务、所述第三网元对所述一个或多个指定业务中的指定业务均不支持、所述第三网元支持所述一个或多个指定业务中的部分指定业务。
- 根据权利要求21所述的装置,其中,所述第一网元、所述第二网元和所述第三网元均为Diameter实体。
- 一种业务能力探测装置,包括:第一接收模块,所述第一接收模块应用于第二网元,设置为接收第一网元发送的第一探测请求消息,其中,所述第一探测请求消息用于探测所述第二网元是否支持一个或多个指定业务;第一检测模块,所述第一检测模块应用于所述第二网元,设置为检测自身支持的业务能力,确定所述第二网元是否支持所述一个或多个指定业务,并生成第一反馈信息;第一发送模块,所述第一发送模块应用于所述第二网元,设置为将所述第一反馈信息发送给所述第一网元。
- 根据权利要求25所述的装置,其中,所述装置还包括:第二接收模块,所述第二接收模块应用于第三网元,设置为接收所述第一网元发送的第二探测请求消息,其中,所述第二探测请求消息用于探测所述第三网元是否支持一个或多个指定业务;第二检测模块,所述第二检测模块应用于所述第三网元,用检测自身支持的业务能力,确定所述第三网元是否支持所述一个或多个指定业务,并生成第二反馈信息;第二发送模块,所述第二发送模块应用于所述第三网元,设置为将所述第二反馈信息发送给所述第一网元;其中,所述第三网元为所述第二网元的备用网元。
- 根据权利要求26所述的装置,其中,所述第一反馈信息包括以下之一:所述第二网元支持所述一个或多个指定业务中的所有指定业务、所述第二网元对所述一个或多个指定业务中的指定业务均不支持、所述第二网元支持所述一个或多个指定业务中的部分指定业务;和/或所述第二反馈信息包括以下之一:所述第三网元支持所述一个或多个指定业务中的所有指定业务、所述第三网元对所述一个或多个指定业务中的指定业务均不支持、所述第三网元支持所述一个或多个指定业务中的部分指定业务。
- 根据权利要求25所述的装置,其中,所述第一网元、所述第二网元和所述第三网元均为Diameter实体。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410577272.8A CN105591831A (zh) | 2014-10-24 | 2014-10-24 | 业务能力探测方法及装置 |
CN201410577272.8 | 2014-10-24 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2016062021A1 true WO2016062021A1 (zh) | 2016-04-28 |
Family
ID=55760183
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2015/075915 WO2016062021A1 (zh) | 2014-10-24 | 2015-04-03 | 业务能力探测方法及装置 |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN105591831A (zh) |
WO (1) | WO2016062021A1 (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113992695A (zh) * | 2020-07-09 | 2022-01-28 | 华为技术有限公司 | 网元设备间业务协同的方法和网元设备 |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112104644B (zh) * | 2020-09-11 | 2023-04-28 | 维沃移动通信有限公司 | Ims请求消息的发送方法和装置 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101094237A (zh) * | 2007-07-30 | 2007-12-26 | 中兴通讯股份有限公司 | 一种ip多媒体子系统中网元间的负荷分担方法 |
CN101621476A (zh) * | 2009-08-17 | 2010-01-06 | 中兴通讯股份有限公司 | Diameter链路的建立方法和Diameter网元 |
CN101631360A (zh) * | 2009-08-19 | 2010-01-20 | 中兴通讯股份有限公司 | 负载均衡的实现方法、装置和系统 |
CN103856488A (zh) * | 2008-05-13 | 2014-06-11 | 华为技术有限公司 | 一种设备能力交互的方法、系统和装置 |
Family Cites Families (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101237383A (zh) * | 2007-01-31 | 2008-08-06 | 华为技术有限公司 | 一种传输组播信息及授权组播业务的方法和系统 |
US8201219B2 (en) * | 2007-09-24 | 2012-06-12 | Bridgewater Systems Corp. | Systems and methods for server load balancing using authentication, authorization, and accounting protocols |
EP2218010B1 (en) * | 2007-12-01 | 2019-07-03 | Alcatel-Lucent USA Inc. | Ims diameter router with load balancing |
US9749404B2 (en) * | 2008-04-17 | 2017-08-29 | Radware, Ltd. | Method and system for load balancing over a cluster of authentication, authorization and accounting (AAA) servers |
CN101977396B (zh) * | 2010-10-22 | 2014-11-05 | 中兴通讯股份有限公司 | 多媒体消息业务中实现网元业务切换的系统及方法 |
CN102480495A (zh) * | 2010-11-23 | 2012-05-30 | 中兴通讯股份有限公司 | 一种网元间标示协议版本的处理方法及系统 |
CN102271366A (zh) * | 2011-08-29 | 2011-12-07 | 大唐移动通信设备有限公司 | 一种Diameter节点的消息传输方法及装置 |
CN102984761B (zh) * | 2012-11-28 | 2016-05-11 | 大唐移动通信设备有限公司 | 一种设备能力信息的传输及获取方法、装置 |
US9680764B2 (en) * | 2013-04-06 | 2017-06-13 | Citrix Systems, Inc. | Systems and methods for diameter load balancing |
-
2014
- 2014-10-24 CN CN201410577272.8A patent/CN105591831A/zh active Pending
-
2015
- 2015-04-03 WO PCT/CN2015/075915 patent/WO2016062021A1/zh active Application Filing
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101094237A (zh) * | 2007-07-30 | 2007-12-26 | 中兴通讯股份有限公司 | 一种ip多媒体子系统中网元间的负荷分担方法 |
CN103856488A (zh) * | 2008-05-13 | 2014-06-11 | 华为技术有限公司 | 一种设备能力交互的方法、系统和装置 |
CN101621476A (zh) * | 2009-08-17 | 2010-01-06 | 中兴通讯股份有限公司 | Diameter链路的建立方法和Diameter网元 |
CN101631360A (zh) * | 2009-08-19 | 2010-01-20 | 中兴通讯股份有限公司 | 负载均衡的实现方法、装置和系统 |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113992695A (zh) * | 2020-07-09 | 2022-01-28 | 华为技术有限公司 | 网元设备间业务协同的方法和网元设备 |
CN113992695B (zh) * | 2020-07-09 | 2022-12-27 | 华为技术有限公司 | 网元设备间业务协同的方法和网元设备 |
Also Published As
Publication number | Publication date |
---|---|
CN105591831A (zh) | 2016-05-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP3202086B1 (en) | State replication of virtual network function instances | |
TWI642282B (zh) | 錯誤恢復方法及應用其之物聯網系統與充電系統 | |
CN110536330B (zh) | 一种ue迁移方法、装置、系统及存储介质 | |
JP5863942B2 (ja) | ウィットネスサービスの提供 | |
CN106330475B (zh) | 一种通信系统中管理主备节点的方法和装置及高可用集群 | |
JP5101734B2 (ja) | トンネル管理方法、トンネル管理装置および通信システム | |
WO2016082710A1 (zh) | 一种呼叫控制方法、Diameter协议转发设备及系统 | |
EP3622670B1 (en) | Connectivity monitoring for data tunneling between network device and application server | |
CN104468506A (zh) | 会话状态检测方法及装置 | |
CN109150659B (zh) | 一种处理器及bfd报文传输方法 | |
CN109495345A (zh) | 一种bfd处理方法及网络设备 | |
JP2020521409A (ja) | Netconfセッション状態の検出方法、装置及びコンピュータ読取可能な記録媒体 | |
CN106797330A (zh) | 用于监测内容递送网络(cdn)的方法、业务监测器(tm)、请求路由器(rr)和系统 | |
WO2011157146A2 (zh) | 通信设备间的主备倒换方法、通信设备和系统及服务请求设备 | |
WO2018201757A1 (zh) | 一种通信方法、设备、系统和计算机存储介质 | |
CN105307217A (zh) | 网元间链路弹性处理方法及装置 | |
WO2016062021A1 (zh) | 业务能力探测方法及装置 | |
CN104243473B (zh) | 一种数据传输的方法以及装置 | |
CN107222883B (zh) | 无线控制器备份方法、备份切换方法、装置及系统 | |
EP4084573A1 (en) | Network connection reestablishment method and device, storage medium, and electronic device | |
WO2016180177A1 (zh) | 一种实现在线计费的方法、系统及装置 | |
CN106936784B (zh) | Sip注册方法、终端及系统 | |
JP2011166245A (ja) | ネットワークシステム、ゲートウェイ装置切替方法、第1のトンネル終端ゲートウェイ装置および第2のトンネル終端ゲートウェイ装置 | |
WO2016201973A1 (zh) | 一种容灾方法、装置及通信系统 | |
WO2017000122A1 (zh) | 一种双栈地址管理方法及第一网元 |
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: 15853336 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: 15853336 Country of ref document: EP Kind code of ref document: A1 |