CN1870624A - Method and device for implementing service reqiring between coordinate entity in network - Google Patents

Abstract

The invention relates to a method and a device for realizing service requests between peer entities in a network. The core of the method of the present invention is: the peer entity in the network receives the service request message carrying the flow information and the service quality parameter information, and the entity selects the bearer network route according to the flow information and the service quality parameter information, and calculates the resources. The service request message is sent to the downstream entity; and when the downstream entity can satisfy the service request, a response message is sent to the upstream entity, otherwise. Respond promptly to the upstream BCFE to reject the response. The invention establishes a service request mechanism between peer entities of the RACS, which can calculate the entire resource and select a path that meets the service request, thereby reserving reliable resource configuration for the service request. At the same time, a service request response mechanism between peer entities of RACS and a method for rejecting requests between peer entities are also established, which improves the service request mechanism.

Description

Method and device for realizing service request between peer entities in network

technical field

The invention relates to the technical field of network communication, in particular to a method and a device for realizing service requests between peer entities in a network.

Background technique

As the scale of the Internet network continues to increase, various network services emerge one after another, and various advanced multimedia systems emerge in an endless stream. As a result, the Internet network needs to frequently send high-burst FTP (File Transfer Protocol) or files containing images. Multimedia services such as HTTP (Hypertext Transfer Protocol) for files. For real-time services on the network, since they are sensitive to characteristics such as network transmission delay and delay jitter, when the network sends services such as FTP or HTTP, it has a relatively large impact on real-time services. Moreover, multimedia services also occupy a large amount of network bandwidth, making it difficult to reliably transmit key services that require guaranteed bandwidth in existing networks.

For guaranteeing the QoS (quality of service) problem of described real-time business and key business transmitted in the network, ITU has proposed a functional model of IP signaling requirement, as shown in Figure 1, described functional model mainly comprises: SCFE (session Functional Entity), BCFE (Bearer Control Functional Entity), SFE (Switching Functional Entity), CCI (Connection Control Interface), NCI (Network Control Interface) and SCI (Switching Control Interface).

The functional role of each functional entity in FIG. 1 will be described respectively below.

(1) SCFE: End users apply for services by interacting with SCFE;

SCFE initiates a QoS request, and SCFE usually determines the communication configuration parameters, such as bandwidth, QoS and other parameter information; if a set of acceptable parameters can be negotiated, SCFE will use the services provided by BCFE to establish, maintain and disconnect network resources to provide Agreed configuration, namely negotiated arrangement (negotiated configuration).

(2) BCFE: responsible for establishing, modifying and releasing network resources to provide agreed configurations;

BCFE receives service flow-based QoS requests from SCFE, and after path analysis, BCFE sends path analysis results to SFE;

Depending on the selected QoS control mode, in order to analyze QoS requests and generate QoS configuration data, BCFE needs to know certain network topology information and resource status information.

(3) SFE: used to cross-connect the virtual connection established on one port with the virtual connection established on another port;

Through one or more such cross-connections on each SFE between users, a virtual connection between users is finally generated; the characteristics of the virtual connection are based on the call parameters negotiated with SCFE, and its routing is determined by BCFE; by The SFE controlled by the BCFE generates or releases cross-connections according to the instructions received on the SCI interface.

(4) CCI: CCI is the interface between the call/session layer and the bearer control plane of the transport layer.

(5) NCI: NCI is the interface between BCFE and BCFE.

(6) SCI: The SCI is the interface between the transport layer bearer control plane and the transport plane.

At present, for the IP signaling function model shown in Figure 1, only the functional roles of the above-mentioned corresponding functional entities are defined, but the interaction process and mutual interaction between each functional entity in the specific application process are not defined. The specific information carried in the message and each piece of information. Therefore, if the model shown in Figure 1 needs to be used in practical applications, it is also necessary to define the messages that need to be exchanged between functional entities, the information carried in the messages, the corresponding business processing procedures, and so on.

Contents of the invention

In view of the above-mentioned problems in the prior art, the purpose of the present invention is to provide a method and device for implementing service requests between peer entities in the network, which can provide reliable resource allocation for service requests.

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

The invention provides a method for implementing service requests between peer entities in the network, including:

A. A peer entity in the network receives a service request message carrying flow information and quality of service parameter information;

B. The entity selects a bearer network route according to flow information and service quality parameter information, calculates resources, and sends the service request message to a downstream entity.

The peer entities mentioned include:

The bearer control functional entity BCFE in the resource access control subsystem RACS.

The flow information includes: service type, service source IP address and destination IP address information.

Described step B specifically comprises:

When the entity determines that it is not a terminating entity according to the information carried in the service request message, it selects a bearer network route according to the flow information and service quality parameter information carried in the service request message, calculates resources, and sends the service request message to the downstream entity .

Described step B also includes:

The entity sends the route information of the bearer network selected by it to the downstream entity along with the service request message.

The first and last entities of the service request are determined according to the source IP address and destination IP address carried in the service request message.

The method also includes:

Two adjacent upstream and downstream entities record each other's identification address.

The present invention also provides a device for implementing service requests between peer entities in the network, including:

The service request processing module is used to receive a service request message, select a bearer network route according to the flow information and service quality parameter information carried in the service request message, and calculate resources;

The forwarding module is configured to send the request message to the downstream entity according to the route determined by the service request processing module.

The device is located at: BCFE in the RACS system.

Based on the above method for service request, the present invention also provides a method for realizing service request response between peer entities in the network, including:

After the downstream entity among the peer entities receives the service request message sent by the upstream entity, if the downstream entity can satisfy the service request, it sends a response message to the upstream entity.

The response message carries the information of the service request that the downstream entity can satisfy.

The response message also includes: path information.

The path information includes: a set of path information determined by the entity according to the information carried in the received service request message.

In the method of the present invention, when the service request message received by the downstream entity contains multiple sets of service quality parameters, the downstream entity should carry the selected set of service quality parameters in the response message and send it to the upstream entity.

In the method of the present invention, the downstream entity sends the response message to the upstream entity according to the recorded address information of the upstream entity.

The present invention provides a device for implementing service request response between peer entities in a network, the device comprising:

Business request response processing module: receiving a business request message sent by an upstream entity, and constructing a business request response message when it is determined that the business request can be satisfied;

Forwarding module: sending the response message constructed by the service request response processing module to the upstream entity.

Based on the method for the above service request, the present invention also provides a method for rejecting requests between peer entities in the network, including:

When the downstream entity among the peer entities cannot satisfy the request, the downstream entity returns a rejection response message to the upstream entity.

The method of the present invention specifically includes:

When the downstream entity sends a rejection response message to the upstream entity, it determines the address of the upstream entity according to the identification address of the adjacent entity recorded in the downstream entity.

The rejection response message includes: the execution result is rejection and/or reason for rejection.

The reasons why the request is rejected include: insufficient resources, no available path, timeout, illegal operation and/or the request is an unknown object.

The rejection response message sent by the downstream entity is sequentially sent to the requesting source entity.

The method further includes: the source entity sending the rejection response message to a session function entity SCFE.

It can be seen from the above-mentioned technical solution provided by the present invention that the present invention establishes a service request mechanism between peer entities BCFE of RACS, which can calculate the entire resource and select a route that meets the service request, thereby reserving a reliable service request. resource allocation.

The invention also establishes a service request response mechanism between peer entities BCFE of the RACS, perfects the service request mechanism, and ensures the reliability of the service request.

The invention also realizes the rejection mechanism of the request between the BCFE peers of the RACS, and can feed back the rejection response to the terminal user in time, thereby enhancing the reliability of resource transmission between peer entities.

Description of drawings

FIG. 1 is a schematic structural diagram of an IP signaling function model;

Fig. 2 is a flowchart of the method of the present invention;

Fig. 3 is a schematic structural diagram of a device for realizing a service request according to the present invention;

Fig. 4 is a schematic diagram of the process of realizing a service request response according to the present invention;

FIG. 5 is a schematic structural diagram of a device for implementing a service request response according to the present invention;

Fig. 6 is a schematic diagram of the rejection process of the request of the present invention.

Detailed ways

The main purpose of the present invention is to improve the protocol between peer RACS (Resource Access Control Subsystem) entities, and propose a mechanism for realizing service requests between peer RACS entities. By calculating the entire resource, a route that meets the business request can be selected, thereby reserving a reliable resource configuration for the business application.

In the network, BCFE usually performs resource calculation and selects an appropriate route to complete the operation of the service request.

In order to have a further understanding of the present invention, the method described in the present invention will be described in detail below in conjunction with the accompanying drawings.

The specific implementation of the method of the present invention is shown in Figure 2, comprising the following steps:

Step 21: After receiving the service request message, the upstream BCFE determines the corresponding downstream entity, selects a bearer network route and calculates resources.

The upstream BCFE shall select bearer network routes and calculate resources within its management domain.

Wherein, the service request message carries flow information, QoS parameters and other information;

The flow information includes information such as service type, source IP address and destination IP address of the service;

The QoS parameters include bandwidth parameters and the like.

Therefore, the upstream BCFE selects a route according to the flow information and QoS parameters carried in the received service request message, and determines the bearer network route according to the selected route and the flow information and QoS parameters carried in the service request message, and calculates resource.

Step 22: The upstream BCFE sends the service request message to the downstream BCFE.

After the upstream BCFE determines the bearer network routing information and calculates resources, it sends the service request message to its downstream BCFE.

When the upstream BCFE sends a service request message to the downstream BCFE, it may also send the determined bearer network path information to the downstream BCFE.

Wherein, the upstream BCFE can determine its corresponding downstream BCFE according to the destination IP address in the service request message.

In order to ensure the accuracy of the BCFE’s response message to its upstream BCFE or event notification to the upstream BCFE, during the process of sending a service request message, two adjacent BCFEs can record each other’s identification address. Among them, the first BCFE only records its The identification address of the downstream BCFE, the last BCFE only records the identification address of its upstream BCFE, and the other BCFEs record the identification addresses of the two adjacent BCFEs.

Step 23: After receiving the service request message, the downstream BCFE selects a bearer network route, calculates resources, and transmits the service request message carrying information such as flow information and service quality parameters to its downstream BCFE. And so on, until the request message is transmitted to the terminating BCFE.

After receiving the service request message, the downstream BCFE selects a bearer network route in its own management domain and calculates resources according to the source address, destination address, and QoS parameters carried in the service request message.

In addition, in order for the BCFE to know the route selection conditions of all upstream BCFEs and the final route selection results, after the upstream BCFE determines the route of the bearer network, it sends the route information of the bearer network together with the service request message to downstream BCFE.

After the downstream BCFE determines the bearer network route, it can add the selected bearer network route information to the bearer network route information issued by the upstream BCFE to form new bearer network route information.

By analogy, until each BCFE determines the corresponding bearer network routing information for the service request, a complete bearer network routing information is formed.

In practical applications, when a terminal user has a service request, it first sends a service request message to the SCFE;

After receiving the service request message, the SCFE determines the configuration parameters of the communication resources, such as flow information, QoS parameters, etc., according to the content of the request;

Wherein, the flow information includes information such as service type, source IP address and destination IP address of the service;

QoS parameters include bandwidth parameters and the like.

After SCFE decides the resource configuration parameters, it sends the service request message carrying information such as flow information and QoS parameters to a BCFE in the bearer layer according to the protocol or other methods;

The BCFE that receives the service request message determines the first BCFE of the service request according to the source IP address carried in the service request message;

Then, the BCFE that receives the service request message sends the service request message to the first BCFE, and the first BCFE performs bearer network routing selection and calculates resources according to the above process, and sends the service request message to the corresponding downstream BCFE;

After the downstream BCFE selects the bearer network route and calculates resources, it sends the service request message to its downstream BCFE until the service request message is sent to the last BCFE. The service request between peer RACS entities described in the present invention The operation process ends, thus completing the whole process of the service request.

The first and last entities of the service request in the present invention can be determined according to the source IP address and destination IP address carried in the service request message, and the last entity is the terminal entity of the service request message.

The present invention also provides a device for implementing service requests between peer entities in the network, as shown in FIG. 3 , which specifically includes: a service request processing module and a forwarding module.

The service request processing module is mainly used to receive service request messages, select bearer network routes and calculate resources according to the flow information and service quality parameter information carried in the service request messages.

The forwarding module is mainly used to send the request message to the downstream entity according to the route determined by the business request processing module.

Said device may be located at the BCFE in the RACS system.

To sum up, the present invention establishes a service request mechanism between peer entities BCFE of RACS, which can select a route that meets service requests by calculating the entire resource, thereby reserving reliable resource configuration for service requests.

Based on the service request method provided by the present invention, the present invention also proposes a mechanism for implementing service request responses between peer RACS entities. When the upstream entity receives the response message sent by the downstream entity, the upstream entity can confirm that the resource reservation is completed and the service request is successful.

In the network, the operation of service request and request response is usually performed by BCFE.

In order to have a further understanding of the present invention, the method described in the present invention will be described in detail below in conjunction with the accompanying drawings.

The specific implementation of the method of the present invention is shown in Figure 4, comprising the following steps:

Step 41: The upstream BCFE sends a service request message to the downstream BCFE.

After the upstream BCFE finishes processing the service request message, that is, completes route selection, resource calculation and path determination, determines the corresponding downstream BCFE, and then sends the service request message to its downstream BCFE;

The service request message carries information such as flow information, QoS parameters and path information related to the service request;

Wherein, the flow information includes information such as the service type, the source IP address of the service, and the address of the destination IP;

The QoS parameters include bandwidth parameters, etc.;

The path information refers to: a set of path information determined by all BCFEs according to received service request messages.

Step 42: After receiving the service request message, the downstream BCFE sends a response message to the upstream BCFE if the service request can be satisfied.

After the downstream BCFE receives the service request message, if the service request can be satisfied, it will perform resource and path calculation and route selection;

Then, the downstream BCFE determines its corresponding upstream BCFE, and sends a service request response message to the upstream BCFE.

Since the adjacent BCFEs have recorded each other's identification addresses during the process of implementing service requests, the downstream BCFEs can determine their corresponding upstream BCFEs according to the recorded identification addresses.

The service request response message sent by the downstream BCFE to the upstream BCFE should contain the content of the service request that can be satisfied, including: service quality parameters, flow information, and path information.

When the service request message received by the downstream BCFE contains a variety of service quality levels, and there are service quality levels acceptable to the downstream BCFE among these service quality levels, the downstream BCFE can select the service quality level and send it The selected service quality level is carried in the response message and sent to the upstream BCFE, such as:

A service request message indicates that the bandwidth requirement of the service is 10M, and at the same time indicates that if the bandwidth requirement cannot be met, a bandwidth of 5M is also acceptable;

After the downstream BCFE receives the above service request message, it finds that the resource calculation cannot meet the 10M bandwidth requirement, but can meet the 5M bandwidth requirement. Therefore, the service request response message sent by the downstream BCFE to the upstream BCFE should indicate the reserved actual The bandwidth is 5M.

In practical applications, the business request response process is usually completed as follows:

After all BCFEs determine a path that meets the service requirements according to the service request message, starting from the last BCFE, they send service request response messages to the upstream BCFE one by one, and the service request response messages contain service quality parameters, flow information and path information.

During the entire service request response process, only when all upstream BCFEs receive the service request response message sent by their downstream BCFE, the service request is considered successful; otherwise, as long as any upstream BCFE does not receive the said response message , the service request is considered to have failed.

The present invention also provides a device for realizing service request response between peer entities in the network, as shown in FIG. 5 , which specifically includes: a service request response processing module and a forwarding module.

The business request response processing module is mainly used to receive a business request message sent by an upstream entity, and construct a business request response message when it is determined that the business request can be satisfied.

The response message of the service request constructed by the service request response processing module may include information such as flow information, QoS parameters and path information related to the service request. When the business request message received by the business request response processing module contains multiple service quality levels, and there are service quality levels acceptable to the BCFE in these service quality levels, the business request response processing module should select it The QoS level is carried in the response message.

The forwarding module is mainly used to send the response message constructed by the service request response processing module to the upstream entity. Said device may be located at the BCFE in the RACS system.

In a word, the present invention also establishes a service request response mechanism between peer entities BCFE of the RACS, perfects the service request mechanism, and thus ensures the reliability of the service request.

In addition, based on the service request method, the present invention also proposes a request rejection mechanism between peer RACS entities.

In the process of RACS business operation, it may happen that after a business request is sent, the request cannot be satisfied due to some reasons. At this time, the system is required to feed back the message that the request is rejected to the end user in time, so that the end user can timely Take other steps to resolve the issue. Below with reference to Fig. 6, the method for rejecting the request between RACS entities of the present invention is described, taking the Qos request as an example, the rejecting operation of the request specifically includes:

An end user (not shown in the figure) sends a Qos request. The end user first applies for a service by interacting with the SCFE. The SCFE determines the communication configuration parameters, such as flow information, Qos parameters, etc., and then the SCFE initiates the request. Send the request to the BCFE. After receiving the above request, the BCFE allocates resources for the request and selects a route. After the upstream BCFE allocates resources for the request and completes the route selection, it sends the request message to the downstream BCFE. Ensure the accuracy of the response message to the upstream BCFE or the event notification to the upstream BCFE. During the process of sending the request message, two adjacent BCFEs record each other’s identification address. Among them, the source BCFE only records the identification address of its downstream BCFE, and the last BCFE only records the identification address of its upstream BCFE, and other BCFEs record the identification addresses of its two adjacent BCFEs. After receiving the request message, the downstream BCFE allocates resources for the request and selects a route, and so on, until each BCFE completes the processing of the request. This process is the normal processing process of the request, but in the actual operation process, due to some reasons, each BCFE often cannot satisfy the request, that is, the request is rejected. At this time, in order to facilitate the end user to process the request in a timely manner, the The rejection response should be responded to the end user in a timely manner, and the following processing methods can be used to solve it:

After the downstream BCFE receives the Qos request message sent by the upstream BCFE, if the request cannot be satisfied, it will promptly respond to the upstream BCFE with a response that the request is rejected. The response message includes notifying that the provision execution result is rejection and the corresponding rejection reason, The reason for the rejection can be insufficient resources, no available path, timeout, illegal operation, unknown object, etc. It can be known from the above request process that each BCFE records the address of the adjacent BCFE. When the downstream BCFE sends the rejection response to the upstream For BCFE, first find the upstream BCFE according to the address of the upstream BCFE recorded by the downstream BCFE, and then send the rejection response. And so on until the rejection should be sent to the source BCFE, and the source BCFE will then send the rejection response to the SCFE, and finally respond to the end user.

Therefore, the present invention realizes the request rejection function between BCFEs, so that end users can get the message that the request is rejected in time, so as to process the request, and enhance the reliability of network transmission.

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

Claims (22)

1. A method for implementing service requests between peer entities in a network, characterized in that it comprises: A. A peer entity in the network receives a service request message carrying flow information and quality of service parameter information; B. The entity selects a bearer network route according to flow information and service quality parameter information, calculates resources, and sends the service request message to a downstream entity. 2. The method for implementing service requests between peer entities in the network according to claim 1, wherein the peer entities include: The bearer control functional entity BCFE in the resource access control subsystem RACS. 3. The method for implementing service requests between peer entities in the network according to claim 1, wherein the flow information includes: service type, service source IP address and destination IP address information. 4. The method for implementing service requests between peer entities in the network according to any one of claims 1 to 3, characterized in that the step B specifically includes: When the entity determines that it is not a terminating entity according to the information carried in the service request message, it selects a bearer network route according to the flow information and service quality parameter information carried in the service request message, calculates resources, and sends the service request message to the downstream entity . 5. The method for implementing service requests between peer entities in the network according to any one of claims 1 to 3, characterized in that, said step B further comprises: The entity sends the route information of the bearer network selected by it to the downstream entity along with the service request message. 6. The method for implementing a service request between peer entities in any one of claims 1 to 3, characterized in that: according to the source IP address and destination IP address carried in the service request message, determine The first and last entity of the service request. 7. The method for implementing service requests between peer entities in the network according to any one of claims 1 to 3, characterized in that the method further comprises: Two adjacent upstream and downstream entities record each other's identification address. 8. A device for implementing service requests between peer entities in a network, characterized in that it includes: The service request processing module is used to receive a service request message, select a bearer network route according to the flow information and service quality parameter information carried in the service request message, and calculate resources; The forwarding module is configured to send the request message to the downstream entity according to the route determined by the service request processing module. 9. The device for implementing service requests between peer entities in the network according to claim 8, characterized in that the device is located at: BCFE in the RACS system. 10. A method for implementing a service request response between peer entities in a network, comprising: After the downstream entity among the peer entities receives the service request message sent by the upstream entity, if the downstream entity can satisfy the service request, it sends a response message to the upstream entity. 11. The method for implementing a service request response between peer entities in a network according to claim 10, wherein the response message carries information on service requests that can be satisfied by downstream entities. 12. The method for implementing service request response between peer entities in the network according to claim 11, characterized in that the response message further includes: path information. 13. The method for implementing a service request response between peer entities in the network according to claim 12, wherein the path information includes: the path information determined by the entity according to the information carried in the received service request message A collection of path information. 14. The method for implementing service request response between peer entities in the network according to any one of claims 10 to 13, characterized in that: when the service request message received by the downstream entity contains multiple sets of service quality parameters , the downstream entity shall carry the selected set of QoS parameters in the response message and send it to the upstream entity. 15. The method for implementing service request response between peer entities in the network according to any one of claims 10 to 13, characterized in that: the downstream entity sends the upstream entity the address information of the upstream entity according to its records response message. 16. A device for realizing service request response between peer entities in a network, characterized in that the device includes: Business request response processing module: receiving a business request message sent by an upstream entity, and constructing a business request response message when it is determined that the business request can be satisfied; Forwarding module: sending the response message constructed by the service request response processing module to the upstream entity. 17. A method for rejecting requests between peer entities in a network, comprising: When the downstream entity among the peer entities cannot satisfy the request, the downstream entity returns a rejection response message to the upstream entity. 18. The method for rejecting requests between peer entities in the network according to claim 17, characterized in that the method specifically comprises: When the downstream entity sends a rejection response message to the upstream entity, it determines the address of the upstream entity according to the identification address of the adjacent entity recorded in the downstream entity. 19. The method for rejecting requests between peer entities in the network according to claim 17, wherein the rejection response message includes: the execution result is rejection and/or the reason for rejection. 20. The method for rejecting requests between peer entities in the network according to claim 19, wherein the reasons for the rejection of the request include: insufficient resources, no available path, timeout, illegal operation and/or the request is unknown object. 21. The method for rejecting requests between peer entities in the network according to claim 17, characterized in that, the rejection response messages sent by the downstream entities are sequentially sent to the requesting source entities. 22. The method for rejecting requests between peer entities in the network according to claim 21, further comprising: the source entity sending the rejection response message to the SCFE.

Images