WO2009086702A1

WO2009086702A1 - A system and method for implementing a dynamic quality of service request based on a single service

Info

Publication number: WO2009086702A1
Application number: PCT/CN2008/000062
Authority: WO
Inventors: Zhongyu Gu
Original assignee: Zte Corporation
Priority date: 2008-01-09
Filing date: 2008-01-09
Publication date: 2009-07-16

Abstract

A method for implementing a dynamic quality of service request (QoS) based on a single traffic includes that: when a customer premises equipment receives a dynamic QoS request for a single service suggested by the user, authenticates the identity information of the user, corresponding service and QoS request information about the service which are included in the dynamic QoS request, if the user is an authorized user and the QoS request information is contained in the scope of the QoS signing information of user, a corresponding QoS policy is generated and performed. A system for implementing above method includes a dynamic request collection (DRC) function except for the conventional network-side equipments, after receiving the dynamic QoS request transmitted from the customer premises network/equipment, the DRC function sends the request to a policy decision function, and forwards the QoS policy deployment respondence transmitted from the policy decision function to the customer premises network/equipment. By applying the invention, the QoS ensurance for a single service can be obtained by introducing DRC.

Description

System and method for implementing dynamic service shield volume request based on a single service

Technical field

The present invention relates to the field of communications, and more particularly to a system and method for implementing dynamic quality of service QoS requests based on a single service.

Background technique

The QoS guarantee scheme for IP networks, after undergoing Int-Serv (Integrated Service Model) and Diff-Serv (Differentiated Service Model), although it can provide some guarantee measures to basically meet the needs of network applications, but at the carrier-class QoS On the assurance side, we are still unable to provide a satisfactory solution. To this end, major standardization organizations have developed new solutions. The basic idea of these solutions is to perform Call Admission Control (CAC) for the user's business needs. According to the resource requirements of the service, if the existing network resource can guarantee the service requirement, the service is accessed and the QoS of the service is guaranteed; if the resource cannot meet the service requirement, the service is denied access. A typical solution is the RACF (Resource and Admission Control Function) proposed by ITU-T (International Telecommunication Union-Telecommunication Standardization Sector) and ETSI TISPAN (Telecommunications and Internet Convergence Service and Advanced Network under the European Telecommunications Standards Institute) Protocol Group) RACS (Resource and Admission Control Subsystem). The following is a brief introduction to the idea of guaranteeing QoS implementation.

Figure 1 shows the RACS functional structure diagram proposed by ETSI TISPAN.

The main functional entities in the RACS are SPDF (Service-based Policy Decision Function) and x-RACF (Generic-Resource and Admission Control Function). Specifically, after receiving the service QoS request information from the AF (Application Function), the SPDF determines whether the network can satisfy the service Q _0S request according to the resource decision information obtained from the x-RACF. If it can be satisfied, accept the service; otherwise, refuse to accept the service. From the aspect of guaranteeing the implementation of QoS requests, there are several functional entities related to RACS, including: 1), NASS (Network Attachment Subsystem), used to store user service subscription information, etc.

2), RCEF (Resource Control Enforcement Function) and BGF (Border Gateway Function) are respectively used to implement the implementation of the QoS policy;

3), AF, typical application is IMS (IP Multimedia Subsystem).

In the early days of development, RACS focused on the admission control of broadband access. Currently, it has begun to further support the control of the core backbone network and supports the interworking of multiple management domains to support a wider range of end-to-end QoS implementations.

Figure 2 shows the functional structure of the RACF proposed by ITU-T.

The RACF includes several functional entities such as PD-FE (Policy Decision Function Entity) and TRC-FE (Transmission Resource Control Function Entity). After receiving the QoS request sent by the SCF (Service Control Function), the PD-FE makes a decision based on the network resources grasped by the TRC-FE.

The specific decision of the RACF can be described as: Determine whether to access the related service according to the information of the user or user service and the existing resources of the network. If the access is determined, that is, the network resource can satisfy the user's QoS request, the implementation of the QoS can be guaranteed; otherwise, when the resource cannot satisfy the user's QoS request, the user's access is denied.

According to the specific implementation of RACS and RACF, they are mainly applicable to session-based services. Before the service starts, the connection is first established by signaling, and the QoS is guaranteed according to the QoS requirement information carried by the signaling.

Although RACS/RACF also supports the delivery of QoS policies for users, it is difficult to achieve non-session services (that is, services that do not need/do not need to establish a signaling-based service connection channel before the service starts). More precise control like session business.

Figure 3 shows a typical QoS request flow for implementing non-session services. Take RACF as an example to illustrate, including the following steps:

1. When the initial registration, the CPE (Customer Premises Equipment) sends a user information authentication request to the NACF (Network Attachment Control Function). 2. After the NACF passes the CPE authentication, the QoS subscription information of the user is sent to the PD-FE.

3. The PD-FE performs the QoS resource availability check interaction with the TRC-FE according to the user QoS subscription information; or the TRC-FE can automatically trigger the availability check of the QoS resource if the network situation changes during the execution of the policy;

4. If the network can satisfy the QoS request of the user, the PD-FE generates a related QoS policy for the user, and performs the next step. If the requirement cannot be met, the steps (a) and (b) can be performed according to the actual situation of the network. Any step:

(a) refusing the user's access, notifying the user that the access failed or the network is unable to provide the required service, ending;

(b) re-select a QoS policy/request, return to step 4;

5. The PD-FE sends the QoS policy to the PE-FE (policy enforcement function entity); the QoS policy should include but not limited to the following elements: Service flow description information (such as IP quintuple or service category, etc.) ), QoS related information (such as: gating, QoS level, uplink bit rate, downlink bit rate, etc.);

6. Optionally, the PE-FE returns a response to the PD-FE.

7. The PD-FE replies to the NACF that the QoS policy (which may be modified) has been deployed;

8. The NACF replies to the CPE with a user information authentication response, indicating that the user can access;

9. The user transmits the traffic; the PE-FE controls the traffic of the user by using the already installed QoS policy;

10. The user service ends or the network resources are released due to reasons such as the network.

In this process, user QoS can only be used as a whole to make a distinction between non-session services (such as ordinary Internet services, etc.), but not for specific, single services. For example, general user QoS subscription information is generally described as parameters such as supported bandwidth, and priority QoS (Internet Telephony), Video (Audio) and other services are guaranteed in this bandwidth, while ordinary Internet access services have lower priority. And roughly allocated a range of parameters such as bandwidth. If the user needs to open multiple web pages at the same time, and the download speed of some of the web pages is different from other ones, that is, if there is a different or explicit QoS guarantee, the current technical architecture is used. It is impossible to achieve.

In the process of using the network, I often encounter such a situation: When downloading a data, the download speed at the beginning is several hundred K or tens of K, and then the rate is reduced a lot, which seriously affects the work efficiency (of course, this The reason is complex, involving many factors, providing end-to-end QoS guarantees can be solved); on the other hand, we need to provide clear bandwidth requirements for certain browsing/downloading services, which can improve our efficiency without A browser is QoS-guaranteed, but it requires a special application for those businesses that are of interest to the user. In other words, users need to control in real time according to their own decisions. This allows for a better integration and coordination between demand, efficiency and price.

In response to this problem, RACF/RACS is currently unable to provide a solution. Even if the QoS policy is delivered in a refinement, it is impossible to determine which services the user needs to access because of the contract, but cannot give a five-tuple that can distinguish the services. Therefore, it is impossible to give a specific QoS policy.

Summary of the invention

The technical problem to be solved by the present invention is to provide a system and method for realizing dynamic QoS request for a single service, so as to solve the problem that RACS/RACF is difficult to support specific, single services, especially in traditional INTERNET Internet browsing services. , the problem of QoS guarantee for a single service.

To solve the above problems, the present invention provides a method for implementing a dynamic service quality QoS request based on a single service, including:

After receiving the dynamic QoS request for the single service proposed by the user, the network side device first authenticates the identity data of the user, the related service, and the QoS request information related to the service included in the dynamic QoS request, such as When the user is a legitimate user and the QoS request information is within the scope of the QoS subscription information of the user, a corresponding QoS policy is generated and executed.

Further, the above method may also have the following features:

a, user side device / network CPE / CPN to dynamic request collection function DRC sends the dynamic QoS request for a single service;

b. After receiving the dynamic QoS request, the DRC and the network attaching function NACF/NASS Interacting, authenticating the dynamic QoS request, and sending the dynamic QoS request to the policy decision function PD-FE/SPDF after the authentication is passed; or directly sending the received dynamic QoS request to the The PD-FE/SPDF, interacting with the NACF/NASS by the PD-FE/SPDF, authenticating the dynamic QoS request, performing the step c after the authentication is passed; checking the interaction, In the case of a dynamic QoS request, a corresponding QoS policy is generated and delivered to the policy enforcement and transmission control function PE-FE/RCEF, which is executed by the PE-FE/RCEF.

Further, the foregoing method may further have the following steps: Step c further includes the following steps: d. The PE-FE/RCEF sends a policy to the PD-FE/SPDF to send a response;

e. The PD-FE/SPDF feeds back the execution result of the current application to the CPE/CPN through the DRC.

Further, the foregoing method may further have the following features: In step b, if the user is a legitimate user and the QoS request information is within the scope of the QoS subscription information of the user, the authentication is passed.

Further, the foregoing method may further have the following features: In step b, if the user is an illegal user, the application is rejected, and the process ends; if the user is a legitimate user but the QoS request information exceeds the user If the scope of the QoS subscription information is rejected, the application is rejected and the process ends or the QoS subscription information is modified according to the application of the user at the time of signing, and the modified QoS subscription information is saved in the NACF/NASS.

Further, the foregoing method may further have the following feature: the QoS request information includes any one of the following or any combination thereof:

1), explicit or implicit service indication, the explicit service indication includes the IP address of the destination, information related to the service; and the implicit service indication includes the destination domain name;

2) The specific requirements of the QoS parameters, including: bandwidth, delay, delay jitter or packet loss rate;

3), the comprehensive strategy tips: when the cumulative application exceeds the preset indicators, how to deal with the strategy;

4) a time-related parameter that begins or terminates execution of the QoS request. Time; or a time period during which the QoS request is executed.

Further, the foregoing method may further have the following features: Step b, if the QoS request information includes a domain name of the destination end, the DRC converts the domain name of the destination end into the IP address information of the destination end, A dynamic QoS request is sent to the PD-FE/SPDF.

Further, the foregoing method may further have the following feature: if the QoS request information includes a start time parameter, in step b, when the start time comes, the DRC sends the dynamic QoS request to the Said PD-FE/SPDF.

Further, the foregoing method may further have the following feature: after the QoS application of the single service is executed, when the user cancels the QoS policy, the method includes the following steps: The network side device receives the dynamic QoS revocation request of the single service proposed by the user. After that, the identity information of the user included in the dynamic QoS revocation request and the information of the QoS request to be revoked are first authenticated, for example, the user is a legitimate user and the QoS request information to be revoked is the QoS being executed. The policy then revokes the corresponding QoS policy.

Further, the foregoing method may further have the following features: The steps of the user revoking the QoS policy include:

A. The CPE/CPN sends the dynamic QoS revocation request to the DRC.

After receiving the dynamic QoS revocation request, the DRC interacts with the NACF/NASS to authenticate the dynamic QoS revocation request, and sends the dynamic QoS revocation request to the authentication after the authentication is passed. Transmitting, by the PD-FE/SPDF, the received dynamic QoS revocation request to the PD-FE/SPDF, and interacting with the NACF/NASS by the PD-FE/SPDF, The dynamic QoS revocation request is authenticated, and after the authentication is passed, step C is performed;

C. The PD-FE/SPDF sends a message to the PE-FE/RCEF to revoke the QoS policy, and the PE-FE/RCEF revokes the QoS policy.

Further, the foregoing method may further have the following features: after the step C, the method further includes the following steps: D. The PE-FE/RCEF sends a policy to send a response to the PD-FE/SPDF;

Further, the above method may further have the following features: In step B, if the user is legal If the user and the QoS request information to be revoked is the QoS policy being executed, the authentication is passed. Further, the foregoing method may further have the following features: In step B, if the user is an illegal user or the QoS request information to be revoked is not a QoS policy being executed, the current revocation request is rejected, and the process ends.

Further, the foregoing method may further have the following feature: if the QoS revocation request information includes an end time, in step B, when the end time comes, the DRC sends the dynamic QoS revocation request to The PD-FE/SPDF; if the QoS request information includes a time to terminate execution of the QoS request, when the time comes, the DRC sends the dynamic QoS revocation request to the PD-FE/ SPDF.

Further, the above method may also have the following features:

In step e or E, the PD-FE/SPDF also sends the execution result of the application to the NACF NASS.

Further, the above method may also have the following features:

In steps a, e, A, and E, the CPE/CPN communicates with the DRC through a dynamic request proxy DRA; the DRA is implemented through a client program or an operator portal.

The present invention also provides a system for implementing dynamic quality of service QoS request based on a single service, including user side equipment/network CPE/CPN, network attachment function NACF/NASS, service function SCF/AF, policy execution and transmission control function PE -FE/RCEF and corresponding resource admission control function RACF/resource admission control subsystem RASS including policy decision function PD-FE/SPDF and resource control function TRC-FE/x-RACF,

The system further includes a dynamic request collection function DRC; the DRC is configured to receive a dynamic QoS request sent by the CPE/CPN to the user including the user's identity data, related services, and QoS request information related to the service. Afterwards, the dynamic QoS request is sent to the PD-FE/SPDF; and is further configured to forward the QoS policy to the CPE/CPN after receiving the QoS policy deployment response sent by the PD-FE/SPDF.

Further, the foregoing system may further have the following features: the DRC is further configured to authenticate identity data and QoS request information of the user, if the user is a legitimate user and the QoS The request information is within the scope of the user's QoS subscription information, and is used to send the dynamic QoS request to the PD-FE/SPDF.

Further, the above system may further have the following features: the system further includes a dynamic requesting proxy DRA, wherein the CPE/CPN communicates with the DRC through the DRA; the DRA is implemented or operated by a client program The portal implementation of the business.

Further, the above system may also have the following features: The DRC is implemented by an independent functional entity or by other functional entities in the RACF/RACS architecture.

In summary, with the present invention, by introducing a dynamic QoS request collection function, QoS guarantee for a specific, single service can be obtained. BRIEF abstract

1 is a structural diagram of a RACS function proposed by TISPAN in the prior art;

2 is a structural diagram of a RACF function proposed by the ITU-T in the prior art;

3 is a flowchart of implementing a non-service QoS request in an RACF in the prior art; FIG. 4 is a system structure diagram for implementing a dynamic QoS application according to an embodiment of the present invention;

FIG. 5 is a flowchart of implementing a dynamic QoS application according to an embodiment of the present invention;

FIG. 6 is a flowchart of implementing dynamic QoS request revocation in an embodiment of the present invention. Preferred embodiment of the invention

In order to implement dynamic QoS application in the RACF/RACS system, a dynamic collection function DRC (Dynamic Request Collector) needs to be added to the RACF/RACS system, as shown in Figure 4. The DRC can receive the user's QoS requests in real time and send them to the PD-FE/SPDF so that the PD-FE/SPDF can obtain the same QoS requests as from the Service Function Entity (AF/SCF).

In order to use the above dynamic QoS request function, a human-computer interaction interface must be provided for the user to perform dynamic QoS application. In Figure 4, using DRA (Dynamic Request Agent, Dynamic A request agent) to implement the interface function.

From a specific implementation point of view, the DRC can be an independent functional entity, or it can be implemented by extending other functional entities in the RACF/RACS architecture (such as AF/SCF, PD-FE/RCEF, etc.).

DRA can also be implemented in different ways, which can be implemented through the client program or the operator's portal.

The technical solution of the present invention will be described in more detail below with reference to the accompanying drawings and embodiments.

Embodiment 1: A user implements a dynamic QoS application through a DRA client program.

In this implementation case, the DRA is implemented by a client program. The specific process is shown in Figure 5, including the following steps:

1. After the user passes the initial access authentication, during the service use, the QoS requirements for a single, specific service appear. For example, if you are dissatisfied with the download speed of the existing large files, you want to apply for higher bandwidth. When the download rate is increased, the DRA client program is started, and the user fills in the dynamic QoS application through the interface provided by the DRA, and the application includes the user identity data and the corresponding service and QoS request information related to the service.

The QoS request information may include, but is not limited to, the following features:

a), explicit or implicit service indication, the explicit service indication includes (source and) the IP address of the destination, the information related to the service, such as the protocol type, etc.; and the implicit service indication may be the destination domain name, etc. ;

b), bandwidth, delay, delay jitter or packet loss rate, etc. QoS parameters specific requirements; c), comprehensive strategy tips. For example, when the cumulative application exceeds the preset metric, how to deal with it: Suppose the original bandwidth allocation is 128K for 2 IP phones, 2M for Video, 896K for normal Internet access, if the user is applying for a 3M When bandwidth is used to ensure access to the Internet, it is necessary to preempt the existing 2M bandwidth that is being used for Video, or to re-apply for a bandwidth policy directive. d ), time-related parameters. The parameter may be the time to start or terminate the execution of the QoS request; or it may be a time period during which the QoS request is executed.

2. The DRA client passes the dynamic QoS application submitted by the user through the interface between it and the DRC. Rh, transmitted to the DRC. In Rh, the interface can use existing protocols, or it can extend existing protocols according to specific conditions. The specific functions of the interface include implementing secure and reliable transmission of information between the DRA and the DRC;

3. After receiving the dynamic QoS application, the DRC needs to perform corresponding processing, which may include, but is not limited to, the following:

a), from the reliable and credible aspects of the information, the encryption of the dynamic QoS application and other steps;

b) authenticating the identity of the user carried by the dynamic QoS application and the dynamic QoS request information;

Specifically, the DRC interacts with the network attach function (NACF/NASS) to authenticate the user identity data and the QoS request information included in the application, to determine whether the user is a legitimate user, and whether the user has the right to apply for dynamic QoS. And whether the dynamic QoS request exceeds the subscription information range of the user. If it is an illegal user, or the user does not have the right to apply for dynamic QoS, the request is rejected, and the process ends; if the user has the right to apply for dynamic QoS and the dynamic QoS request does not exceed the scope of the user's subscription, step 4 is performed; Have the right to request dynamic QoS, but if the request exceeds the scope of the user's subscription, you can reject the request and end it, or modify the user's subscription information according to the application of the user at the time of signing, and apply for the dynamic QoS of the user. NACF/NASS registration;

Optionally, the authentication work can also be performed through the policy decision function in step 5 (such as the functional entity PD-FE/SPDF in RACF/RACS).

c), the domain name to IP address conversion function, etc.; When the service is applied, the user needs to submit the IP address of the specific destination to implement the QoS policy. However, ordinary users often do not know the IP address of the destination end, but only know the domain name. This requires the DRC to complete the work of converting the destination domain name into the destination IP address, thereby facilitating the user's use;

d), processing time-related parameters. If the start time indicated by the time parameter included in the dynamic QoS request is not the current time, but is a certain time in the future, the time is counted by the DRC. Triggers the sending of relevant dynamic QoS requests to policy decision functions after the time has elapsed. If the time information in the dynamic QoS application also includes the termination time, then the termination time comes. The DRC sends a policy revocation request to the policy decision function, and the specific policy revocation process will be described in detail below;

4. The DRC sends the dynamic QoS request to the policy decision function;

After the policy decision function receives the dynamic QoS application, if the DRC has authenticated the user identity and the dynamic QoS request in step 3, step 6 is performed; otherwise, the above-mentioned authentication work is performed by the policy decision function, including The following steps: The policy decision function interacts with the network attach function (if the user subscription information has been downloaded from the network attach function into the policy decision function entity, the interaction process may be omitted), the user identity data included in the application and The QoS request message is authenticated to determine whether the user is entitled to the dynamic QoS request and whether the dynamic QoS request exceeds the subscription information range of the user. If the user has the right to apply for dynamic QoS and the dynamic QoS request does not exceed the user's subscription scope, go to step 6. If the user does not have the right to apply for dynamic QoS (that is, the user does not have this function in the network attachment function), then the user is denied. If the user has the right to make a dynamic QoS request, but the request exceeds the scope of the user's subscription, the user may refuse to end the request, or modify the user's subscription information according to the application of the user at the time of signing, and The modified subscription information is saved in the NACF NASS;

6. The policy decision function and the resource control function perform resource availability check interaction to determine whether there are enough resources in the network;

7. The policy decision function makes a specific decision. If there are enough resources in the network to satisfy the QoS request, it generates the relevant QoS policy and performs the next step; if not, rejects the request, and performs step 10.1;

8. The policy decision function sends the generated QoS policy to the policy execution function;

Specific strategies may include IP quintuple (source IP address, destination IP address, source port number, destination port number, protocol number) and information about processing policies.

9. After the policy execution function installs the foregoing QoS policy, it provides feedback to the policy decision function. 10.1. The policy decision function sends a QoS policy deployment response to the DRC, where the policy decision function accepts or rejects the result information of the dynamic QoS request.

10.2, optionally, the policy decision function also notifies the network attachment control function of the above result information;

11. The DRC feeds back the received QoS policy deployment response to the DRA client. DRA guest The client can display relevant result information to the user to notify the user whether the application is successful;

12. The user sends traffic. In the case of a successful application, the user can obtain the required QoS guarantee.

Implementation 2: The user implements the application through the portal.

In this implementation case, the user implements the application through the portal function of the operator. The specific process includes the following steps:

1. After the user passes the initial access authentication, during the service use, the QoS requirements for a single, specific service appear, for example, because of the dissatisfaction with the download speed of the existing large files, it is desirable to apply for higher bandwidth to improve. In efficiency, the user logs in to the portal of the dynamic QoS application, and the user fills in the dynamic QoS application through the interface provided by the portal, and the application includes the user identity data and the corresponding service and QoS request information related to the service;

The QoS request information may include but is not limited to the following features:

a), explicit or implicit service indication, the explicit service indication includes the IP address of the destination, information related to the service, etc.; and the implicit service indication includes the destination domain name, etc.; b), bandwidth, delay The specific requirements of QoS parameters such as delay jitter or packet loss rate; c), the prompt of the comprehensive strategy, for example, how to handle the strategy when the accumulated application exceeds the preset indicator;

d ), time-related parameters. The parameter may be the time to start or terminate the execution of the QoS request; or it may be a time period during which the QoS request is executed.

2. Since the DRA is implemented through the portal, the QoS request can be directly submitted to the DRC;

After the DRC receives the dynamic QoS request, the processing flow of the subsequent functional entities is similar to that in the implementation example 1. Only in step 11, the execution result is displayed on the DRA portal.

The method for terminating the dynamic QoS application or exiting the dynamic QoS application can be implemented using a process similar to the application. Or you can combine the time parameters to determine the start and end time of the application to achieve the start and end of the appointment. Implementation Case 3: Termination/Revocation of Dynamic QoS Request.

This embodiment takes the DRA as a client implementation as an example.

After the user has applied for a dynamic QoS, the application can be revoked. The specific process is shown in Figure 6. Includes the following steps:

1. The user performs a dynamic QoS revocation request through the DRA client function, where the application includes user identity data, corresponding service, and QoS revocation request information related to the service; the QoS revocation request information may include at least but not limited to The following characteristics: a), explicit or implicit service indication, explicit service indications include the IP address of the destination, information related to the service, etc.; and the implicit service indication includes the destination domain name; b) , specific requirements of QoS parameters such as bandwidth, delay, delay jitter or packet loss rate; c), the prompt of the comprehensive strategy, for example, how to handle the strategy when the accumulated application exceeds the preset indicator;

d ), time-related parameters. The parameter may be when the QoS revocation request is started. Carrying the above parameters only serves as an indication, so as to carry out detailed information description, mainly for fear of canceling the occurrence of an error. Alternatively, the dynamic application information that the user can revoke can be listed on the DRA for the user to select to revoke, and the QoS revocation request information only needs to include the information of the dynamic application information to be revoked, such as the number.

2. The DRA client sends the dynamic QoS revocation request to the DRC through the interface with the DRC;

3. After receiving the application, the DRC needs to do the corresponding processing, which may include but is not limited to including the following:

a), from the consideration of the reliability and credibility of the information, the step of encrypting the dynamic QoS revocation request;

b) authenticating the identity of the user carried in the dynamic QoS revocation request and the dynamic QoS revocation request information. Specifically, the following steps are included:

Bl) The DRC interacts with the network attachment function (NACF/NASS), first included in the application The user identity data in the user is authenticated to determine whether the user has the right to cancel the dynamic QoS application; if the right is right, go to step 4; otherwise, refuse to cancel the application, and end the processing flow;

B2) determining whether the dynamic QoS revocation request included in the application matches the content of the previous dynamic application;

If it does not match, reject the request and end the processing flow;

If they match, register the user's dynamic application;

Optionally, the authentication work can also be performed in step 5 by a policy decision function (such as the functional entity PD-FE/SPDF in RACF/RACS);

c) , processing time-related parameters. If the start time indicated by the time parameter included in the dynamic QoS revocation request is not the current time, but a certain time in the future, the DRC is used for timing. After the time is up, trigger again, and perform step 4;

4. The DRC sends the dynamic QoS revocation request to the policy decision function.

After the policy decision function receives the above dynamic QoS revocation request, if the DRC has authenticated the user identity and the dynamic QoS revocation request in step 3, step 6 is performed; otherwise, the policy decision function performs the above authentication work. The method includes the following steps: The policy decision function performs authentication processing on the dynamic QoS revocation request, and specifically includes:

a) The policy decision function interacts with the network attach function (if the user subscription information has been downloaded from the network attach function to the policy decision function entity, the interaction process can be omitted), the user identity is authenticated, and the user is mainly judged whether the user The dynamic QoS application has the right to revoke; if it has the right, the next step is executed; otherwise, the application is rejected, and the processing flow is terminated;

b) judging whether the dynamic QoS revocation request submitted by the customer is consistent with the content of the previous dynamic application; if not, rejecting the request and ending the processing flow;

If they match, register the user's dynamic QoS revocation request and perform the next step;

6. The policy decision function makes specific decisions and may generate related QoS policies. In general, the policy related to the application can be deleted directly. The main reason here is that the deletion of the dynamic application policy may affect the QoS policy of other services of the user. To this end, optional, it may be necessary to interact with the network attachment function NACF/NASS; 7. The policy decision function issues a related deletion strategy to the policy execution function;

8. After the policy execution function is undoed, the policy decision function is fed back;

9.1. The policy decision function notifies the DRC to report the execution result of this application;

9.2. Optionally, the policy decision function should also notify the network attachment control function NACF/NASS about the execution result;

10. The DRC will report the execution result of this application to the DRA client. The DRA client can display the relevant execution results to the user.

Similarly, the undo function can also be implemented through the operator's portal website. Specifically, refer to the implementation case two and three for corresponding processing.

Implementation Case 4: Dynamic QoS Request Modification.

For some reason, the user may need to modify the QoS request for dynamic application. For example, suppose the user subscribes to a bandwidth of 10M, of which 6M is already occupied by the IPTV (Internet TV) service, and the user dynamically applies for an Internet 2M bandwidth. After the IPTV service is over, the user can increase the bandwidth of the broadband Internet access to 8M according to the specific situation. This requires modification of existing dynamic QoS requests.

In fact, the process of applying for a dynamic change is similar to the case of a dynamic application. The main difference is that there are more judgments, such as whether there is already a modified application. It is not described here.

Industrial applicability

In summary, with the present invention, by introducing a dynamic QoS request collection function, QoS guarantee for a specific, single service can be obtained.

Claims

Claim

A method for realizing a dynamic service shield QoS request based on a single service, characterized in that

2. The method according to claim 1, characterized in that it comprises the following steps: a. User side device/network CPE/CPN sends a dynamic QoS request to a dynamic request collection function to the single service;

After receiving the dynamic QoS request, the DRC interacts with the network attach function NACF/NASS to authenticate the dynamic QoS request, and sends the dynamic QoS request to the policy decision after the authentication is passed. Functioning PD-FE/SPDF; or directly transmitting the received dynamic QoS request to the PD-FE/SPDF, and interacting with the NACF/NASS by the PD-FE/SPDF, for the dynamic QoS Request for authentication, after the authentication is passed, perform step c;

c. The PD-FE/SPDF performs a resource availability check interaction with the resource control function TRC-FE/x-RACF, and generates a corresponding QoS policy and delivers the policy to the policy if the dynamic QoS request is satisfied. The execution and transmission control function PE-FE/RCEF is executed by the PE-FE/RCEF.

3. The method of claim 2, wherein

Step c also includes the following steps:

d. The PE-FE/RCEF sends a response to the PD-FE/SPDF sending policy;

4. The method of claim 2, wherein

In step b, if the user is a legitimate user and the QoS request information is within the scope of the QoS subscription information of the user, the authentication is passed.

5. The method of claim 2, wherein

In step b, if the user is an illegal user, the application is rejected, and the process ends; if the user is a legitimate user but the QoS request information exceeds the QoS subscription information range of the user, the application is rejected. And the process ends or the QoS subscription information is modified according to the application of the user at the time of signing, and the modified QoS subscription information is saved to the NACF NASS.

6. The method of claim 2, wherein

The QoS request information includes any one of the following or any combination thereof:

3). Tips for comprehensive strategy: How to deal with the strategy when the accumulated application exceeds the preset indicator;

4) Time-related parameter, which is the time to start or terminate the execution of the QoS request; or a time period during which the QoS request is executed.

7. The method of claim 6 wherein:

In the step b, if the QoS request information includes the domain name of the destination, the DRC converts the domain name of the destination end into the IP address information of the destination end, and then sends the dynamic QoS request to the PD-FE/ SPDF.

8. The method of claim 6 wherein:

If the QoS request information includes a start time parameter, in step b, when the start time comes, the DRC sends the dynamic QoS request to the PD-FE/SPDFo.

9. The method of claim 1 wherein:

After the QoS request of the single service is executed, when the user cancels the QoS policy, the method includes the following steps: The network side device receives the dynamic QoS revocation request of the single service proposed by the user. After that, the identity information of the user included in the dynamic QoS revocation request and the information of the QoS request to be revoked are first authenticated, if the user is a legitimate user and the QoS request information to be revoked is the QoS being executed. The policy then revokes the corresponding QoS policy.

10. The method of claim 9 wherein:

The steps for the user to revoke the QoS policy include:

A. The CPE/CPN sends the dynamic QoS revocation request to the DRC.

After receiving the dynamic QoS revocation request, the DRC interacts with the NACF NASS to authenticate the dynamic QoS revocation request, and sends the dynamic QoS revocation request to the office after the authentication is passed. The PD-FE/SPDF; or directly send the received dynamic QoS revocation request to the PD-FE/SPDF, and the PD-FE/SPDF interacts with the NACF/NASS, for the dynamic The QoS revocation request is authenticated, and after the authentication is passed, step C is performed;

11. The method of claim 10, wherein

After step C, the following steps are also included:

D. The PE-FE/RCEF sends a policy to the PD-FE/SPDF to send a response;

12. The method of claim 10, wherein

In step B, if the user is a legitimate user and the QoS request information to be revoked is a QoS policy being executed, the authentication is passed.

13. The method of claim 10, wherein

In step B, if the user is an illegal user or the QoS request information to be revoked is not the QoS policy being executed, the revocation request is rejected, and the process ends.

14. The method of claim 6 or 10, wherein

If the QoS revocation request information includes an end time, in step B, when the end time comes, the DRC sends the dynamic QoS revocation request to the PD-FE/SPDF; if the QoS request information includes a time to terminate execution of the QoS request, the DRC sends the dynamic QoS revocation request to the PD-FE/SPDF when the time comes.

15. The method of claim 3 or 11, wherein

In step e or E, the PD-FE/SPDF also sends the execution result of the application to the NACF/NASS.

16. The method of claim 2, 3, 10 or 11 wherein:

17. A system for implementing dynamic quality of service QoS requests based on a single service, including user side equipment/network CPE/CPN, network attachment function NACF/NASS, service function SCF/AF, policy execution and transmission control function PE-FE/ RCEF and corresponding resource admission control function RACF/resource admission control subsystem RASS including policy decision function PD-FE/SPDF and resource control function TRC-FE/x-RACF, characterized in that

Also including a dynamic request collection function DRC; the DRC is configured to receive the

After the CPE/CPN sends a dynamic QoS request including the user's identity data, related services, and QoS request information related to the service, the dynamic QoS request is sent to the PD-FE/SPDF; After receiving the QoS policy deployment response sent by the PD-FE/SPDF, it forwards it to the CPE/CPN.

18. The system of claim 17 wherein:

The DRC is further configured to authenticate the identity data and QoS request information of the user. If the user is a legitimate user and the QoS request information is within the scope of the QoS subscription information of the user, it is used to The dynamic QoS request is sent to the PD-FE/SPDF.

19. The system of claim 17 wherein:

The system further includes a dynamic requesting proxy DRA, and the CPE/CPN communicates with the DRC through the DRA; the DRA is implemented by a client program or by an operator's portal.

20. The system of claim 17 wherein: The DRC is implemented as an independent functional entity or by other functional entities in the RACF/RACS architecture.