WO2009065360A1 - Method, system and equipment for the end-to-end qos application - Google Patents

Abstract

The invention discloses a method for the end-to-end QoS application, comprises: the universal opening interface system receives the QoS application sent from the application server, and generates a QoS request that sending to the policy and charging control PCC system; the universal opening interface system sends the generated QoS request to the PCC system, and receives a QoS distribution result sent by the PCC system. The invention also discloses a system for the end-to-end quality of service QoS application. According to the usage of the embodiments of the invention, the PCC system opens a dynamic QoS interface for the universal opening interface system, and realizes that the dynamic QoS capabilities of the WiMAX system open functions for the third party application via the USI interface. The upper layer application entity provides the QoS information needed by the service to the PCC system via the USI system, realizes the transfer and negotiation of the QoS information of the upper layer entity and the PCC system, realizes the opening of the QoS capabilities of the access network, and the end-to-end QoS guarantee from the upper layer to the access network.

Description

 Application method, system and device for end-to-end OoS application The application is filed on November 19, 2007, and the application number is 200710169715.X, the invention name is "an end-to-end QoS application method, system" The priority of the Chinese Patent Application, the entire disclosure of which is incorporated herein by reference. Technical field

 The embodiments of the present invention relate to the field of network technologies, and in particular, to a method, system, and device for applying end-to-end QoS. Background technique

 The USI (Universal Services Interface) system is an interface for WiMAX (Worldwide Interoperability Microwave Access Forum) to open its business capabilities to third-party applications in or outside the network. By calling the service capabilities provided by USI, third-party application development will be easier for WiMAX access users, and it will be more convenient to provide personalized services for WiMAX access users. The ability of WiMAX networks to be opened through USI systems includes QoS (Quality of Service), location services, and so on.

 Application-driven QoS means that applications can dynamically change the QoS (such as bandwidth, etc.) that users access to the network. The application's dynamic change to QoS can be a temporary change (defining a valid time) or as the default QoS each time the user connects to the network.

The PCC (Policy and Charging Control) system is a resource allocation and control framework defined by the 3GPP (3rd Generation Partnership Project) for network QoS and charging control. The PCC mainly includes a PCRF (Policy and Charging Rule Function), a PCEF (Policy and Charging Enforcement Function), and an SPR (Subscription Profile Repository) module. The main functions are policy decision, policy execution, user data storage (PCRF needs) User data information is requested from the SPR for policy decisions). WiMAX introduces the PCC architecture into WiMAX networks for QoS and charging control. The PCC system introduced by the WiMAX network adds a PDF (Policy Distribution Function) module between the PRCF and the PCEF. The PDF is a logical function module (when deployed, it can be deployed with the PCRF). The PCC system of the network realizes interworking; PDF and PCRF are connected by Gx interface, and the function of PDF is to hide the distributed characteristics and mobile characteristics of the WiMAX network policy enforcement point (PCEF) from the PCRF. The PCEF is divided into A-PCEF and C-PCEF according to the location of the network: A-PCEF is located in the access network to perform QoS and charging of the access network; C-PCEF is located in the core network, and the core network is executed. QoS and billing.

 In the process of implementing the present invention, the inventors found that the prior art has the following disadvantages: The WiMAX network lacks a secure QoS application interface and interface calling procedure suitable for opening to third-party applications, thereby opening up the QoS capability of the WiMAX network, resulting in QoS. Information cannot be dynamically communicated and negotiated between upper-layer applications and WiMAX networks.

Summary of the invention

 An embodiment of the present invention provides an end-to-end QoS application method, system, and device, which are used to implement an application server such as an ASP (Application Service Provider)/iASP (Internet ASP, Internet Application Service Provider). The USI system applies to end-to-end QoS.

 To achieve the above objective, an embodiment of the present invention provides an end-to-end QoS application method, including the following steps:

 The universal open interface system receives the QoS request sent by the application server, and generates a QoS request sent to the policy and charging control system;

 The universal open interface system sends the generated QoS request to the policy and charging control system, and receives the QoS allocation result sent by the policy and charging control system.

An embodiment of the present invention further provides an end-to-end QoS application system, including: an application server entity, configured to receive a user request, and implement a general open interface system The body sends a QoS request;

 a general open interface system entity, configured to generate a QoS request according to the received QoS request sent by the application server entity, and send the QoS request to the policy and charging control system entity; receive the QoS allocation result sent by the policy and charging control system entity ;

 The policy and charging control system entity is configured to receive the QoS request sent by the universal open interface system entity and return a QoS allocation result.

 Embodiments of the present invention also provide a universal open interface system entity for end-to-end QoS applications, including:

 a QoS request generating unit, configured to generate a QoS request sent to the policy and charging control system entity according to the QoS request sent by the application server entity;

 And a receiving unit, configured to receive a QoS allocation result sent by the policy and charging control system entity.

 An embodiment of the present invention further provides an application server for an end-to-end QoS application, including:

 a request receiving unit, configured to receive a user request;

 The address obtaining unit is configured to obtain an address of the universal open interface system entity, and send a QoS application to the acquired address according to the user request received by the request receiving unit.

 Embodiments of the present invention have the following advantages over the prior art:

 Through the policy and charging control, the PCC system opens the dynamic QoS interface to the universal open interface USI system, and realizes the dynamic QoS capability of the WiMAX system to open the function to the third party through the USI interface. The upper application entity provides the QoS information required by the service to the PCC system through the USI system, realizes the transmission and negotiation of the QoS information of the upper application entity and the PCC system, realizes the opening of the dynamic QoS capability of the access network, and the application and access from the upper layer. End-to-end QoS guarantee. DRAWINGS

1 is a flowchart of a method for applying end-to-end QoS in Embodiment 1 of the present invention; 2 is a schematic diagram of roaming of a USI system in Embodiment 1 of the present invention;

 FIG. 3 is another schematic diagram of the USI system roaming in the first embodiment of the present invention; FIG. 4 is a schematic diagram of the USI system roaming in the first embodiment of the present invention; FIG. Flow chart of the application method of the end QoS;

 6 is a structural diagram of an end-to-end QoS application system in Embodiment 3 of the present invention. detailed description

 The embodiments of the present invention will be further described below in conjunction with the accompanying drawings and embodiments. In the first embodiment of the present invention, an end-to-end QoS application method is provided, as shown in FIG. 1, including:

 Step sl01: The user terminal accesses the WiMAX network, and the user terminal and the application server complete application layer interaction (such as registration and authentication of the user terminal in the application server), and trigger the QoS application on the application server.

 Step sl02: The application server initiates a QoS application to the USI system.

 Step sl03: The USI system authenticates the QoS request, and after the authentication is passed, generates a QoS request according to the QoS application and sends the QoS request to the PCC system.

 Step sl04: The PCC system performs QoS allocation according to the received QoS request, and returns the QoS allocation result to the USI system.

 Step sl05: The USI system sends the QoS allocation result to the application server. In the embodiment of the present invention, in step s04, if the access network resource is insufficient or the subscription QoS of the user does not meet the requirements of the application server, the PCC system may reject the QoS request of the USI system or perform QoS reduction, and the PCC system returns the result of the QoS authorization. Or the reduced QoS is given to the USI system, and the USI system returns the received result to the application server.

 The specific implementation processes of the above steps slO1 to sl05 are separately described below. Step sl01, the user terminal accesses the WiMAX network, and triggers on the application server.

QoS application.

Specifically, the step sioi further includes: (1) The user establishes a WiMAX IP-CAN (IP Connectivity Access Network IP) path. In the IP-CAN establishment process, the PCEF sends a request PCC Rules to the PCRF, where the request carries the IP-CAN type requested by the user. (here WiMAX) and user identity, the user identity may include a user NAI (Network Access Identifier) and/or an IP address.

 (2) The request is forwarded via PDF. The PDF stores the information sent by the PCEF and forwards the request to the corresponding PCRF. This step is optional.

 (3) The PCRF obtains the QoS and PCC Rules of the user according to the IP-CAN type and the user identification information.

 (4) The PCRF performs user authentication and policy decision of IP-CAN. After passing, the PCC Rules matching the IP-CAN (with QoS information to be implemented) is returned to the PDF, and the PCRF stores the user and the corresponding PCC Rules information.

 (5) The PDF is stored after receiving the PCC Rules and will be forwarded to the PCEF.

 (6) The PCEF executes the received PCC Rules to complete the establishment of the IP-CAN.

 (7) After the IP-CAN is established, the user terminal initiates a service request to the application server by interacting with the application server, for example, playing a video, triggering the QoS request logic of the application server.

 Step sl02, the application server sends a QoS request to the USI system.

 In this embodiment of the present invention, the QoS request may be an Apply QoS message. Table 1 is a content of an Apply QoS message according to an embodiment of the present invention, where QoSIdentifier and DefaultQoS (default QoS) are parameters that must be carried, and other parameters are optional. For details, refer to the description in Table 1.

 Table 1: Definition of Apply QoS Messages

 Field Type Optional Description

 The parameters are described in Table 2, in registering user-independent default QoS.

When the UserlD comprehensive type parameter is sent to the USI system, the user information parameter is not carried. In other cases, the user information must be carried. Information parameter

 QoSIdentifier String Type No Used to identify whether this QoS Request is the default QoS: 0, non-default QoS; 1 , Default QoS

 When the value is 1, the USI system searches for the saved default QoS configuration based on the QoSIdentifier.

DefaultQoS Boolean Type No

 Data, if the QoS parameter is carried in the application, the default QoS configuration is updated, otherwise the QoS application is performed according to the queried default QoS configuration data.

 When DefaultQoS is 1 to identify the default QoS, it is used to identify whether to implement the default QoS to

ModifyExistingSess

 Boolean type 疋 Current user session: ion

 0, not implemented; 1 , implementation When DefaultQoS is 0, this parameter does not carry

 QoS request parameters, see Table 3

QoSProperties synthetic type 疋

 Description in

 Used for associated billing with the network

Chargingldentifier string type 疋

 Identification

 Application server can use this word

The SpecificAction enumeration type section requires the USI system to provide event notification, billing data, etc. Can be more than one, value:

 Chaging-Identifier-Exch ange(l): Requires the network side to provide a charging identifier for association charging.

 Loss-Bearer-Notify(2): Notify the application server when the bearer is lost

 Recovery-Bearer-Notify (3): notify the application server when the bearer is restored

 Release-Bearer-Notify(4)

): Notify the application server when the bearer is released

 Establish-Bearer-Notify(

5): Notify the application server when the bearer is established

 The value is 0 ~ 8 , which is consistent with the definition of the priority of the ETSI TS183 017 specification. For details, refer to the specification definition. Where 0 is the absence of this parameter

ReservationPriority enumeration type 疋

 The value is saved. When this item is not provided, the value is 0. This parameter is ignored if the PCC system does not support this QoS priority mode.

ServiceURN string type 疋 is used to identify emergency calls The content of UserlD (user terminal identifier) is the user ID (such as the user access network identifier NAI) and/or the user's IP address (IPv4 or IPv6 address), and the user ID is composed of the username (username) and the domain name (realm). Partially, for the purpose of protecting user privacy, the user ID provided to the application server may use a literally meaningless specific string instead of the username part, for example using the user's pseudonym NAI ( pseudonym NAI) address, pseudonym NAI and user real The mapping of the NAI is stored in the server of the user's home network (such as AAA (Authentication, Authorization and Accounting) server), and the USI system or the PCC system receives the pseudonym NAI provided by the application server, if needed. To query the real NAI of the user, the server (AAA server) that stores the user NAI correspondence can be queried to the user's real NAI to further verify the user identity or obtain user configuration information. In addition to using the user access network identifier (NAI) as the user ID scheme, the USI system can also generate a user ID identifier (user terminal identifier) for the user, where the domain name part carries the USI system domain name information, and the USI system maintains the user ID. The USI system provides the user ID identifier to the user, and carries the user ID identifier in the service request initiated by the user.

 In the embodiment of the present invention, the description of User1D in Table 1 is as shown in Table 2 below: Table 2: Description of UserlD

In the embodiment of the present invention, the description of QoSProperties in Table 1 is as shown in Table 3 below: Table 3: Description of QoSProperties

 Field Type Optional Description

Duration Non-negative integer 时 Duration of QoS implementation (ie, effective time), in seconds; USI system returns QoS request upon receiving PCC system The timing starts after success, and the QoS request is initiated to the PCC system when the duration is reached. The application server may not issue the parameter, but the application server completes the timing function, and the QoS request is sent after the time is expired. In addition, the application server may also implement the maximum traffic upper limit control function, and the QoS request is sent when the traffic reaches a certain limit.

 UpStreamSpeed non-negative integer

 疋 Please ask for the upstream bandwidth rate, in bits per second; if there are multiple copies of Me Rate

 The diaComponentDescription parameter is the sum of the upstream bandwidths of these parameters. If there is only one Media ComponentDescription parameter with the maximum upstream bandwidth parameter, this parameter can also be ignored.

 DownStreamSpe non-negative integer

 疋 Please ask for the downstream bandwidth rate, in bits per second; if there are multiple copies of Med edRate

 The iaComponentDescription parameter is the sum of the downstream bandwidths of these parameters. If there is only one Media ComponentDescription parameter with the maximum downstream bandwidth parameter, this parameter can also be ignored.

 MediaCompone synthesis type 疋 media component description, can be multiple copies, ntDescription see table 4 description

 String type 疋 Use SDP (IETF defined meeting

The mediaFlowDesc description protocol, the latest is the media stream information described by RFC45 riptionlnSDPFor 66); if the mat contains the MediaComponentD escription parameter, the MediaFlow DescriptionlnSDPFormat parameter is not necessary to carry. Application service Can choose to send MediaFlow

 DescriptionlnSDPFormat or MediaComponentDescripti on for the USI system, if the MediaFlowDescriptionlnS DPFormat is sent, the MediaComponentD escription parameter (for the USI system to the PCC system) is generated by the USI system Me diaFlowDescriptionlnSDPFor mat.

 OtherProperties Undefined 疋 Other required extended parameters

The MediaComponentDescription parameter is consistent with the Media-Component-Description parameter defined in the 3GPP Rx interface specification in the prior art, that is, the definition and use of each sub-parameter in the Media-Comp onent-Description is the same as described in the specification. If the QoSProperties parameter carries the MediaFlowDescriptionlnSDPFormat parameter and does not carry the MediaComponentDescription parameter, when the USI system is connected to the PCRF of the PCC system, the USI system refers to the SDP (Sessi on Description Protocol) defined by the 3GPP PCC QoS Parameter Mapping Specification according to the MediaFlowDescriptionlnSDPFor mat parameter. The session description protocol) to the mapping method of the value of the Media-Component-Descri ption, the MediaCompo nentDescription configuration parameter is generated, and then sent to the PCRF through the Rx interface; if the USI system is connected to the PDF/PCEF of the PCC system These two parameters can also be left without carrying.

 In the embodiment of the present invention, the description of the MediaComponentDescription is as shown in Table 4 below.

 Table 4: Description of MediaComponentDescription

(Media-Component-Description can have multiple copies, each with a serial number)

 Media-Sub-Component The media type of the sub-component can be multiple. For details, refer to the definition of 3GPP Rx interface specification (29214). This parameter can describe one-way or two-way ip flow and describe the filter information and bandwidth information of the i stream. , specific reference table 5

 AF-Application-Identifier 疋 Business Type ID

 The Media-Type 疋 value is as follows:

 AUDIO (0): Voice

 VIDEO (1): Video

 DATA (2): data

 APPLICATION (3): Application

 CONTROL (4): Control

 Max-Requested-Bandwidth-UL 疋 Maximum upstream IP bandwidth requested (bits/second)

 Max-Requested-Bandwidth-DL 疋 Maximum upstream and downstream IP bandwidth requested (bits/second)

 Flow-Status 疋 Enumeration type, used to indicate the status of the IP flow. The values are as follows:

 ENABLED-UPLINK (0) : ENABLED-DOWNLINK (1)

ENABLED (2)

 DISABLED (3)

 REMOVED (4)

 Reservation-priority 疋 Enumeration type, the value is as follows:

 DEFAULT (0)

 PRIORITY-ONE (1)

 PRIORITY-TWO (2)

PRIORITY-THREE (3) PRIORITY-FOUR (4)

 PRIORITY-FIVE (5)

 PRIORITY-SIX (6)

 PRIORITY-SEVEN (7) where 0 is the default value for this parameter and is specifically defined in the ETSI TS 183 017 specification.

 RS-Bandwidth 疋 In a session module, the maximum bandwidth used by the receiving end to receive RTCP reports, unit bits/second, can refer to the description of RS in RFC 3556.

 RR-Bandwidth 疋 In a session module, the maximum bandwidth, unit bits/second, used by the sender to send RTCP reports. Refer to RFC 3556 for a description of RRs.

 Codec-Data 疋 Multiple copies, refer to the definition of 3GPP Rx Interface Specification (29214) In the embodiment of the present invention, the Media-Sub-Component parameters are as shown in Table 5 below: Table 5: Parameters about Media-Sub-Component

When the Media-Sub-Component is correct.

 Flow-Usage 疋 Enumeration type, which identifies the purpose of the IP flow. The values are as follows:

 NO INFORMATION (0, default)

 RTCP (1)

 AF— SIGNALLING (2)

 Max-Requested-Bandwidth-UL 疋 Requested maximum upstream IP bandwidth

 (bits per second), which has a higher priority than the Max-R equested-Bandwidth-UL parameter in Media-Comp onent-Description. When both sides are configured, the one in Media-Sub-Component will prevail.

 Max-Requested-Bandwidth-DL 疋 Maximum upstream and downstream IP bandwidth requested

 (bits/sec), which has a higher priority than the Max-R equested-Bandwidth-DL parameter in Media-Comp onent-Description. When both sides are configured, the one in Media-Sub-Component will prevail.

In this step, the application server obtains the USI system address as follows: The application server according to the network access identifier (NAI) or IP address range carried in the user request, such as the user's HoA (MS Home Address) address Get the USI system address of the user and send a QoS request to the address. Specifically, the application server may establish a correspondence between the user ID or the IP address range and the USI address according to the USI interface related information provided by the WiMAX network provider, so that the application server obtains the corresponding relationship according to the user ID information in the QoS request. Obtain the USI address; or query the DNS (Domain Name System) according to the domain name information in the user ID to obtain the address of the user USI; The request directly carries the user-owned USI address information.

 In the case of user roaming, the application server obtains the USI system address as follows: The USI address obtained by the application server may be the USI address of the user's visited network, or the USI address of the user's home network. For example, when the application server obtains the USI address according to the HoA address information, if the HA of the user accessing the CSN (Connected Service Network) network establishes a connection with the user terminal and provides the mobile IP service for the user, the application server obtains the user visit. USI address. If the application server obtains the USI address according to the content carried in the service request sent by the user to the application server, the user's home network USI address may be the user's visited network USI address, depending on the user's network configuration to the user terminal USI address. And the USI address of the user's home network is obtained by the user's NAI information. For these situations, the USI system is required to support the processing of user roaming.

 The USI system roaming plan is as follows:

 Solution 1: When the application server sends a QoS request to the USI system (H-USI) of the home network of the user, the USI system of the home network queries the user's home AAA server (H-AAA) for the current location information (visiting the network address) of the user. Sending the QoS request to the USI system (V-USI) of the visited network, wherein the interface between the home network USI system and the visited network USI system can use the interface of the USI system and the application server (the USI system receiving the application server message is responsible for forwarding) The application server requests), or uses the interface between the USI system and the PCC system (the USI system that receives the USI sending message is responsible for forwarding to the corresponding PCC system). The above process is shown in Figure 2.

 Solution 2: When the application server sends a QoS request to the USI system of the home network of the user, the USI system of the home network sends a QoS request to the PCC system (H-PCC) of the home network, and the PCC system of the home network discovers that the user roams. The QoS request is sent to the PCC system (V-PCC) of the user visited network (eg, the PCRF through the home network sends the request to the PCRF of the visited network). The above process is shown in Figure 3.

Solution 3: When the application server sends a QoS request to the USI system of the user visited network, the USI system of the visited network sends the QoS request to the visiting network PCC system, and the PCC system of the visited network requests the PCC system of the user home network to make a policy decision. The PCC system belonging to the network processes according to the user data, and returns the processing result to the PCC system of the visited network for policy execution. The above process is shown in Figure 4. Step s10: The USI system authenticates the QoS application, and after the authentication is passed, generates a QoS request according to the QoS application and sends the QoS request to the PCC system.

 Specifically, the authentication mode may be a prior art such as a certificate, and if it is a certificate mode, the QoS application is required to carry the certificate information. After the USI system authenticates the QoS application, the QoS request generated by the QoS application is sent to the PCC system through the interface between the USI system and the PCC system.

 The connection point between the USI system and the PCC system is as follows: The USI system and the PCC system may have multiple connection point schemes:

 When the USI system is connected to the PCRF of the PCC system, in order to reduce the modification of the PCC system, the USI and PCRF connection interfaces can use the Rx interface defined by the 3GPP to send QoS requests to the PCRF. Of course, other interfaces can also be used. When the connection interface between the USI and the PCRF uses the Rx interface defined by the 3GPP, the USI system converts the QoS request into the Rx interface QoS request according to the received QoS request, and then combines the interface type with the PCC system, and then sends the generated QoS request to the PCC system. . In the embodiment of the present invention, the USI system and

When the PCRF is connected, the USI can convert the QoS request to send after the authentication is passed.

The AA-Request message of the Rx (diameter protocol) interface is sent to the PCRF. In the embodiment of the present invention, the USI implementation conversion is as shown in Table 6 below:

 Table 6: Description of the USI implementation transformation

Usil .ns l .com

Origin-Realm No The domain (Realm) address of the originating session of the USK diameter session. For reference, RFC3588, example: ns l .com

 Destination-Realm No The domain (Realm) address of the PCC system (the destination of this diameter session), refer to RFC3588, example: nsp2.com

 AF-Application-Identifier 业务 Service type provided by the application server

 Media-Component-Description 疋 See step sl02

 MediaComponentDescription field description section, fill in this field with MediaComponentDescription in QoSProperites in applyQoS, if it is carrying MediaFlowDescription

 InSDPFormat parameter without carrying Ψ

 For the MediaComponentDescription parameter, the USI system refers to the 3gpp PCC QoS Parameter Mapping Specification (29213) specification to generate the MediaComponentDescription parameter.

 AF-Charging-Identifier 疋 The USI system generates a charging identifier to fill in this item, which is used to associate with the bearer.

 SIP-Forking-Indication 疋 No need to carry

Specific-Action 疋 enumeration type, the value is [0, 5]. See the definition of 3GPP Rx interface specification ( 29214 ). The USI fills in the field according to the value of Specific-Action in the applyQoS request. Subscription-ID 疋 fill in the applyQoS request

 UserlD's NAI address

 Reservation-Priority 疋 Enumeration type, the values are as follows:

 DEFAULT (0)

 PRIORITY-ONE (1)

PRIORITY-TWO (2)

PRIORITY-THREE (3)

PRIORITY-FOUR (4)

PRIORITY-FIVE (5)

PRIORITY-SIX (6)

PRIORITY-SEVEN (7) where 0 is the default value for this parameter, as specified in the ETSI TS183 017 specification. If the application-Priority is included in the applyQoS request, it is filled in after the USI review (the USI system may modify this value according to the configuration information), or the value is filled in by the USI system according to the configuration information; the MediaComponentDescription in the applyQoS message also contains The Reservation-Priority parameter also needs to be reviewed by the USI system and may be modified according to the configuration. If the PCC system does not support this parameter, the USI system can also transparently transmit or ignore this parameter.

 Framed-IP-Address 疋 ^ The userlD of the applyQoS request contains an IPv4 address, and this field is filled in.

Framed-IPv6-Prefix 疋 ^ The userlD of the applyQoS request contains the IPv6 address, then fill in this item.

Service-URN 疋 is used to identify emergency calls, carried in applyQoS requests

If the USI system is connected to the PDF/PCEF of the PCC system, the USI system implements some functions of the PCRF relative to the connection PCRF: Complete the policy decision, according to the user's configuration data (the USP system and the PCC system save the user policy SPR functional entity) The interface generates a PCC Rules that conforms to the user session, completes the conversion of the application server's QoS request to the PCC rule, and generates the corresponding PCC Rules according to the 3GPP Gx interface specification; requires synchronization with the QoS data maintained on the PCEF; and requires the user to access In the network, PDF/PCEF sends IP-CAN session related information to the USI system, and the USI system records user IP-CAN session information. To reduce the modification of the PCC system, the interface between the USI system and the PDF/PCEF can use the Gx interface defined by 3GPP. In the embodiment of the present invention, after receiving the QoS application sent by the application server, the USI system may send a PDF to the PDF through a Re-Auth-Request (RAR) message of the Gx interface (the diameter protocol). The USI conversion relationship is as shown in Table 7 below:

 Description of the USI conversion relationship

Refer to RFC3588, example: nsp2.com

Destination-Host No The host (Host) address of the PCC system (the destination of this diameter session), refer to RFC3588, for example: pccl .nsp2.com

 Re-Auth-Request-Type No Value 0 or 1, for specific reference RFC3588

Origin-State-Id 疋 Non-negative integer, refer to RFC3588

The event-trigger 疋 Enum type requires more than one event reported by the PCEF. According to the Specific-Action value in applyQoS, the value of the Event-Trigger is defined corresponding to the 3GPP Gx interface specification.

 Charging-Rule-Remove PC PCC Rules information to be deleted, which can be carried in multiple copies, carried over when the QoS request is aborted, generated according to the 3GPP Gx interface specification (29212);

 Charging-Rule-Install PC PCC Rules information to be executed, which can be carried in multiple copies, when requesting QoS requests, generated according to 3GPP Gx Interface Specification (29212);

 QoS-Information 疋 See Table 8, also available on specific PCC

QoS-Information is carried in the Rules (the QoS-Information parameter is also included in the Charging-Rule-Install parameter). When both are present, the ones carried in the Charging-Rule-Install are taken as the standard. In the embodiment of the present invention, the definition of QoS-Information is as shown in Table 8 below: Table 8: Definition of QoS-Information

The method defined by the parameter mapping standard (29213) maps to the bearer QoS, and according to the QoS data configuration (consistent with the PCEF), the index of the QoS data configuration on the PCEF is obtained.

 Max-Requested-Bandwidth-UL 疋 The maximum upstream bandwidth based on the request of applyQoS, refer to the 3GPP 29213 specification.

 Max-Requested-Bandwidth-DL 最大 The maximum downlink bandwidth based on the requestQoS request. For details, refer to the 3GPP 29213 specification.

 Guaranteed-Bitrate-UL 最大 The maximum guaranteed upstream bandwidth based on the request of applyQoS, refer to the 3GPP 29213 specification.

Guaranteed-Bitrate-DL 最大 Maximum guaranteed upstream bandwidth based on requestQoS request, refer to 3GPP 29213 specification

The Bearer-Identifier is bound by the PCEF #, so this parameter does not carry the QoS message requested by the USI system and the request QoS message sent by the USI system to the PCC system. The USI system is required to complete the conversion function. The USI system open interface bearer protocol can be web services protocol, SIP, HTTP, etc., and the interface between the USI system and the PCC system is the diameter protocol (Rx or Gx interface), so the USI system is also required to support multiple interface protocol stacks at the same time. (eg web services and diameter ). In order to simplify the processing of the USI system, the USI system can also directly open the diameter interface of the PCC system to the application server, so that the USI system does not need to perform interface conversion and protocol conversion as described above, but this solution requires the application server to support Rx or It is a Gx interface and a diameter, which imposes high requirements on the application server and limits the use of the USI system by the application server. In step s04, the PCC system performs dynamic QoS allocation according to the request for receiving the QoS, and returns the result to the USI system. After the PCC system receives the QoS request sent by the USI system, if the USI system is connected to the PCRF, the PCRF finds the corresponding IP-CAN session according to the network access identifier or IP address of the user in the request, and carries the QoS carried in the request. The parameter is authenticated. If the QoS parameter is applicable to the user, the PCRF sends the PCC Rules to the PCEF to implement the QoS parameter, and returns the result to the USI system through the AA-Avide message of the Rx interface. If the USI system is connected to the PDF/PCEF, the USI system looks up the registered IP-CAN session according to the user ID or IP, finds the diameter session corresponding to the IP-CAN registration through the IP-CAN session, and passes the request information through the diameter session ( The Gx interface is sent to the PDF/PCEF for Qos implementation, and the PDF/PCEF returns the result to the USI system via the Re-Auth-Answer message of the Gx interface.

 In the embodiment of the present invention, the definition of the AA-Ask message is as shown in Table 9 below:

 Table 9: Definition of the AA- Answer message

Made the following extensions:

 INVALID — SERVICE — INFO

RMATION (5061)

 FILTER — RESTRICTIONS

(5062)

 REQUESTED— SERVICE—

NOT— AUTHORIZED

(5063)

 DUPLICATED— AF—SESSI

ON (5064)

 Access-Network-Charging-Identi 计费 Accounting ID for access network fier

 Access-Network-Charging- Addr 计费 The billing address of the access network ess

 Error-Message 疋 Error message

 Error-Reporting-Host 疋 Reporting the wrong host address In the embodiment of the present invention, the definition of the Re-Auth-Answer message is as shown in Table 10 below: Table 10: Definition of the Re-Auth- Answer message

3 xxx (Protocol Errors)

 4xxx (Transient Failures) 5xxx (Permanent Failure) For example, 2001 indicates that the request was successfully processed.

 Experimental-Result 疋 The vendor-defined return value can refer to the definition of RFC3588. The 3GPP Rx interface specification (29214) has the following extensions:

 INVALID— SERVICE— INFOR MATION (5061)

 FILTER— RESTRICTIONS (5062)

 REQUESTED— SERVICE— NO T— AUTHORIZED (5063) DUPLICATED— AF— SESSION (5064)

 Origin-State-Id 参加 Participates in the definition of RFC3588, and the value is consistent with the Re-Auth-Request message.

Event-Trigger 疋 value is consistent with Re-Auth-Request message

 Charging-Rule-Report 疋 Reference 3GPP 29212 Specification, PCC

 Rule Billing Status Report

 Access-Network-Charging- 接入 Access network billing address

Address

 Access-Network-Charging-I 接入 Access network charging identifier

dentifier-Gx

Error-Message error message Error-Reporting-Host 疋 Reporting the wrong host address

After receiving the QoS execution result returned by the PCC system (AA-Answer or Re-Auth-Answer message), the USI system returns a success or failure response to the application server according to the Result-Code field. If it fails, the error may be further changed. The -Message field is reported to the application server together.

 Further, in the embodiment of the present invention, the USI system processes the charging identifier: when the USI system sends an applyQoS request to the PCC system, the charging identifier carried by the USI system is used to generate an accounting identifier, and the charging system uses the charging. The identifier identifies the current USI request session, and the charging identifier is globally unique. The charging identifier can be generated by using all existing algorithms that generate a globally unique identifier, for example, using a USI session identifier and receiving a USI request time combination. The charging identifier is generated, or the charging identifier is generated by using the combination of the requesting party identifier and the time. The USI system associates the application server with the USI charging identifier, and the access network charging identifier and the charging identifier of the USI system. Such association can be used for billing settlement of the USI system and the application server as needed, and the USI system and The billing and settlement of the access network; if the USI system is required, the access network may be associated with the charging identifier of the application server to complete the charging association and settlement between the access network and the application server. The application server can also request the USI system to report the accounting identifier of the USI system for the application server to perform settlement between the USI system and the application server. The purpose of introducing the USI charging identifier is to block the charging identifier of the access network from the application server, and the application server only needs to

The USI system performs fee settlement for interface calls. Step sl05: After receiving the QoS allocation result sent by the PCC system, the USI system sends the QoS allocation result to the application server.

 In the embodiment of the present invention, the QoS allocation result may be sent to the application server by using an ACK message.

 The definition of the ACK message is as shown in Table 11 below:

Table 11: Definition of ACK message

ResultCode String type No See RFC 3588 definition, as follows:

 Lxxx (Informational)

2xxx (Success)

 3 xxx (Protocol Errors)

4xxx (Transient

Failures)

 5xxx (Permanent Failure)

 For example, 2001 indicates that the request was successfully processed.

 ErrorMessage String Type 疋 Error Message

 The invention is applicable not only to WiMAX systems, but also to other access systems, such as 3G systems, WLAN systems, and the like. This article only uses the WiMAX system as an example. In other systems (3G, WLAN, etc.), as long as the network deploys the PCC system and the general open service interface system (USI or OSA), the universal open service interface system can also be implemented using the interfaces and processes used by the present invention. Open to the application server's QoS capabilities to establish end-to-end QoS control and bearer. In the embodiment of the present invention, the QoS termination process may be as follows:

 The application server initiates the termination of the QoS application. For example, the user terminal initiates the termination of the service request to the ASP/iASP application server, and the ASP/iASP application server can initiate the terminateQoS request to the USI system, and the USI system terminates the QoS application through the PCC system. The terminateQoS request carries the QoSIdentifier parameter, and the value can be the same as that in the Apply QoS request. The terminateQoS method is described in Table 17 below: Table 17: Description of the terminateQoS method

After the USI system receives the terminateQoS request or the time indicated by the Duration parameter in the Apply QoS request, it initiates a pause or terminates the QoS request to the PCC system:

 When the USI system is connected to the PCC system through the Rx interface, if the type parameter in the terminateQoS message is DISABLED, the AA-Request (AAR) message of the Rx interface is sent, and the AA-Request that sends the QoS request differs from the Flow-Status field configuration. DISABLED; If the type type is REMOVED, the USI system sends a Session-Termination-Request (STR) message to terminate the user session, and after the PCC system returns the termination success, the USI system returns a termination success message to the ASP/iASP application server. Then terminate the session with the ASP/iASP application server. In the embodiment of the present invention, the parameters in the Session-Termination-Request message are as shown in Table 18 below.

 Table 18: Parameters in the Session- Termination-Request message

Refer to the definition of RFC3588, 3GPP

 The Rx interface specification ( 29214 ) has been extended as follows:

 INVALID— SERVICE— INFOR MATION (5061)

 FILTER— RESTRICTIONS (5062)

 REQUESTED— SERVICE— NO T— AUTHORIZED (5063) DUPLICATED— AF— SESSION (5064)

 Origin-State-Id 参加 Participates in the definition of RFC3588, and the value is consistent with the Re-Auth-Request message.

Event-Trigger 疋 value is consistent with Re-Auth-Request message

 Charging-Rule-Report 疋 Reference 3GPP 29212 Specification, PCC

 Rule Billing Status Report

 Access-Network-Charging- 接入 Access network billing address

 Address

 Access-Network-Charging-I 接入 Access network charging identifier

 dentifier-Gx

 Error-Message 疋 Error message

 Error-Reporting-Host 疋 Error reporting host address

When the USI system is connected to the PCC system through the Gx interface, the Re-Auth-Request (RAR) message is sent. In the case of the type DISABLED in the terminateQoS message, the difference from the Re-Auth-Request that sends the QoS request is FLOW-STATUS. Is DISABLED ; if type is REMOVED, then FLOW-STATUS is configured as REMOVED, and after the PCC system returns to terminate successfully, the USI system returns a success message to the ASP/iASP application server, and then terminates the session with the ASP/iASP application server.

 After receiving the termination QoS request message, the PCC system uninstalls the PCC Rules of the configuration QoS of the session, and returns a termination success message to the USI system after the termination succeeds, carrying the return value and other information (such as error information and error message). The host address, etc., is similar to the return message of the Apply QoS request. For details, refer to the Rx interface or the Gx interface specification defined by the 3GPP, and no detailed description will be given here.

The PCC system implements an end-to-end QoS solution:

 The QoS guarantee of the user terminal to the ASN (Access Service Network) GW (Gateway Way) is performed by the ASN GW (A-PCEF). This part is a prior art and has a detailed description in the WiMAX standard. It will not be described in detail in the present invention. The guarantee between the ASN GW and the HA (Home Agent). If the HA (C-PCEF) performs the QoS guarantee function, this part is implemented by the HA to guarantee the QoS. Otherwise, it is executed by the ASN GW (A-PCEF). QoS policy, and implement QoS on the tunnel between the ASN GW and the HA by implementing the DiffServ border gateway function, configuring the corresponding QoS class label in the DSCP field of the IP header between the ASN GW and the HA, or The ASN GW is responsible for establishing a QoS guarantee channel with the HA through the RSVP protocol.

There are several solutions to the QoS problem that the external network carries over with the ASP/iASP application server: 1) The PCRF of the WiMAX network has a signaling interface with the PCEF of the external network, and the PCRF sends a QoS policy to the PCEF, the external network. PCEF implements policies to implement QoS; 2) When there is no PCEF on the external network or there is no PCC interface between the WiMAX network and the external network, HA (C-PCEF) acts as the border gateway of the network and is responsible for implementing the WiMAX network between the ASP/iASP application servers. QoS, when the external network supports the DiffServ service, C-PCEF acts as the DiffServ border gateway to implement the differential QoS (DiffServ QoS) service between the ASP/iASP application servers. If the external network supports the Integrated QoS (InteServ QoS) service, C-PCEF can use RSVP Protocol to implement QoS service to ASP/iASP application server; 3) If HA does not support C-PCEF function or C-PCEF function does not support QoS policy execution, then ASN GW (A-PCEF) is required for QoS Implementation, modify the IP header of the user data, identify the QoS identifier in the DSCP field, or the ASN GW is responsible for establishing the RSVP path with the ASP/iASP application server. At the same time, the ASN GW also has QoS responsible for tunnel communication between the HAs, as described in the previous paragraph.

 The embodiments of the present invention are further described below in conjunction with specific application scenarios. In the second embodiment of the present invention, the application server provides the video message mailbox service to the WiMAX user as an example. When the application server plays the multimedia video message to the user, the application server applies the one-way QoS guarantee IP link to the user terminal to the USI system. The application process is shown in Figure 5, including:

 Step s501: The application server sends an apply QoS request to the USI system.

 The application of the apply QoS request in XML is as follows. The request message can be carried by using bearer signaling such as HTTP (Hypertext Transfer Protocol), Web Services, SIP (Session Initiation Protocol), etc.: <?xml Version:" 1.0"?>

 <usi xmlns="urn:wimax:params:xml:ns:usi" version="0"

State="full">

 <usi func=" apply QoS" id="Gld5ad">

 <UserID>

 <Nai>pseudonyms@nspl .com</Nai>

 <Ipv6>5555: : bbb:ccc:ddd </Ipv6>

 </UserID >

 <QoSIdentifier>ql23456789</QoSIdentifier>

 <DefaultQoS>0</DefaultQoS>

 <QosProperties>

 <Duration>900</Druation>

 <UpStreamSpeedRate>0</UpStreamSpeedRate>

<!-

— >

 <SpecificAction>4</SpecificAction> 〈! - report the bearer release event

—>

 <ReservationPriority>4</ReservationPriority> <! --Priority 4

— >

 </usi>

 In the above message content, the func field carrying the request method takes the value of applyQoS, and the representation method is used to apply for QoS, and the session id identifier of the QoS application is represented by id="Bld5ad" in the example.

 Carry the user ID (userlD), the user ID is the pseudonym NAI address, and the user IP is an IPv6 HoA address. In addition, the QoS identifier is used to identify the QoS request, and the application server can use the identifier to request an update request from the USI (such as changing parameters).

 In addition, the optional parameter DefaultQoS indicates whether the user uses the Default QoS data of the service, and the network side (the USI system) stores the QoS data of the service request for the user, and implements the default QoS parameter; if the network side does not store When the QoS parameters and service data in the request are stored, if the request is not carried, an error message is returned to the application server.

 In addition, in the QoSProperties parameter: Carrying the optional parameter Duration indicates the duration of implementation of the IP flow for the QoS request, and the USI system performs timing according to this parameter, and sends abort QoS request when the time exceeds this time, and notifies the application server; carries optional parameters UpStreamSpeedRate identifies the maximum rate of the uplink; carries the optional parameter DownStreamSpeedRate to identify the maximum downlink rate; carries the optional parameter MediaComponentDescription to describe the specific QoS request data, which is consistent with the 3GPP Rx interface specification. For details, refer to the specification.

 In addition, the optional parameter Chargingldentifier is used for the application server to notify the network side of the application's charging identifier.

In addition, the optional parameter SpcificAction is used to indicate the time and data that the application server requires to report on the network side. In the example, the bearer loss and bearer release event are reported. In addition, the optional parameter Reservation-Priority is used to indicate the priority processing required by the application server for the request. The definition of the priority is the same as that defined in the existing specification. If the USI system does not support, the parameter may not be carried. Step s502: The USI system invokes authentication and sends an AA-Request request to the PCC system.

 Specifically, the USI system receives the request and sends an AA-Request request to the PRCF module of the PCC system through the Rx interface by using the interface authentication of the application server, and each AVP (Attribute Value Pair) value (diameter protocol) As shown in Table 12 below:

 Table 12: AVP Values in AA-Request Requests

The value of Media-Component-Description is shown in Table 13 below: Table 13: Values of Media-Component-Description

Media-Sub-Component value 3⁄4 port is shown in Table 14 below:

 Table 14: Values of Media-Sub-Component

Step s503: After the PCRF of the PCC system receives the AA-Request message, it finds the pair. After the QoS request is reviewed, the PCC Rules (the QoS information carrying the request) is sent and executed. After the successful execution result is received, the successful result information is returned to the USI system through the AA-Ask message.

 The value of the AA- Answer message is shown in Table 15 below:

 Table 15: Values of the AA- Answer message

 Note: Result-Code is the 2001 message request to perform the complete success step s504, after the USI system receives the success message returned by the PCRF of the PCC system, it starts timing according to the Duration parameter configuration carried in the request (at the time of reaching it is to send the abort QoS request to The PCC system), and the successful result is returned to the application server through the Ack message.

 The Ack message is described in XML as follows:

 <?xml version:" 1.0"?>

 <usi xmlns="urn:wimax:params:xml:ns:usi" version="0"

State="full">

 <usi func="ack" id="fild5ad">

 <ResultCode>2001 </ResultCode>

</usi> In the third embodiment of the present invention, the difference from the second embodiment is that the application server carries the MediaFlowDescriptionlnSDPFormat parameter to the USI in the apply QoS message. The system, the USI system sends an apply QoS request to the PCRF through the Rx interface AA-Request message according to the mapping of the received MediaFlowDescriptionlnSDPFormat parameter to the Rx interface parameter.

 The request for the apply QoS request described in XML is as follows.

 <usi xmlns="urn:wimax:params:xml:ns:usi" version="0"

State="full">

 <usi func=" apply QoS" id="Gld5ad">

 <UserID>

 <ID>pseudonyms@nspl .com</ID>

 <Ipv6>5555: : bbb:ccc:ddd </Ipv6>

 </UserID >

 <QoSIdentifier>ql23456789</QoSIdentifier>

 <DefaultQoS>0</DefaultQoS>

 <QosProperties>

 <Duration>900</Druation>

 <UpStreamSpeedRate>0</UpStreamSpeedRate> about 200k byte ~>

 < MediaFlowDescriptionlnSDPFormat >

 <c>IN IP6 5555 : : aaa :bbb : ccc : ddd</c>

 <a>recvonly</a>

 <m>video 5560 RTP/AVP 99</m>

 <a>rtpmap:99 h263-1998/90000</a>

 <b>AS:1600</b>

 </MediaFlowDescriptionInSDPFormat > </QoSProperties>

 <ChargingIdentifier>c 123456789</ Chargingldentifier> <SpecificAction>2</SpecificAction> 〈! - Reporting bearer loss events

-- > <SpecificAction>4</SpecificAction>< !—Reports the bearer release event

-- >

 <ReservationPriority>4</ReservationPriority> <! --Priority 4

-- >

 </usi>

 Note: The definition of c, a, m, b fields in the MediaFlowDescriptionlnSDPFormat field is consistent with the description of the SDP specification (rfc4566) defined by the IETF standard: c describes the connection data, a describes the parameter configuration, m describes the media parameters, and b describes the bandwidth parameters. Alternatively, the SDP information can be directly provided as a field information in the MediaFlowDescriptionlnSDPFormat field, without the numerator field (c, a, m, b, etc.).

The USI system converts to get the Media-Component-Description according to the received MediaFlowDescriptionlnSDPFormat parameter, as shown in Table 16.

 Table 16: Media-Component-Description based on received SDP conversion

ENABLED DOWNLINK

Reservation-priority is not available and can be empty

The USI system sends the converted Media-Component-Description as a parameter of the AA-Request message to the PCRF. The subsequent processing is consistent with the description in the second embodiment and will not be described in detail.

 In Embodiment 4 of the present invention, an application server is provided to register a default QoS parameter to

The method of the USI system. After the registration is completed, the application server does not need to carry specific QoS parameters when applying for QoS, and a QoS index can be used. The applyQoS message is used to register the default QoS function as follows:

 <?xml version:" 1.0"?>

 <usi xmlns="urn:wimax:params:xml:ns:usi" version="0"

State="full">

 <usi func=" applyQoS" id="Gld5ad">

 <QoSIdentifier>ql23456789</QoSIdentifier>

 <DefaultQoS>K/DefaultQoS>

 <ModifyExistingSession>0</ModifyExistingSession> <!--label i only registers the default QoS parameters 1 >

 <QosProperties>

 <UpStreamSpeedRate>0</UpStreamSpeedRate>

About 200k byte- ->

 <MediaComponentDescription Media-Component-Number= 1 >

<Application-Identifier>MultiMediaMail</Application-Identifier>

<Media-Type> 1 </Media-Type><! - identify VIDEO type one> DL>

L>

 <Flow- Status> 1 </Flow- Status>< ! -- indicates

ENABLED-DOWNLINK— >

 <Reservation-priority>4</Reservation-priority> </MediaComponentDescription>

 </QoSProperties>

 </usi>

After receiving the information, the USI system knows that the request is to save the QoS default configuration parameters to the WiMAX network through the configuration of the DefaultQoS and ModifyExistingSession parameters. The USI system is responsible for maintaining the relationship between the QoS default parameters and the QoS index. If the user information is carried in the request, the default QoS parameter belongs to the user. Otherwise, the default parameter can be used by all users. The USI system returns to the application server after it has succeeded. If ModifyExistingSession is configured to 1 (need to carry the UserlD parameter), then the USI system is required to send the request to the PCC system to modify the QoS of the session the user is making.

 Through the above method provided by the embodiment of the present invention, the dynamic QoS interface is opened by the PCC system to the USI system, and the dynamic QoS capability of the WiMAX system is opened to the third-party application through the USI interface. The upper application entity provides the QoS information required by the service to the PCC system through the USI system, realizes the transmission and negotiation of the QoS information of the upper application entity and the PCC system, realizes the opening of the dynamic QoS capability of the access network, and the application and access from the upper layer. End-to-end QoS guarantee. An embodiment of the present invention further provides an end-to-end QoS application system, as shown in FIG. 6, including:

The application server entity 10 is configured to receive a user request and send a QoS request to the universal open interface system entity. The universal open interface system entity 20 is configured to generate a QoS request according to the received QoS request sent by the application server entity 10, and send the QoS request to the PCC system entity 30; and receive the QoS allocation result sent by the PCC system entity 30.

 The PCC system entity 30 is configured to receive the QoS request sent by the universal open interface system entity 20 and return a QoS allocation result.

 The application server entity 10 further includes:

 a request receiving unit 11 , configured to receive a user request;

 The address obtaining unit 12 is configured to obtain an address of the universal open interface system entity, and send a QoS request to the acquired address according to the user request received by the request receiving unit 11.

 The universal open interface system entity 20 further includes:

 The QoS request generating unit 21 is configured to generate a QoS request sent to the PCC system entity 30 according to the QoS application sent by the application server entity 10;

 The converting unit 22 is configured to convert the QoS request generated by the QoS request generating unit 21 and send the QoS request to the PCC system entity 30.

 The receiving unit 23 is configured to receive a QoS allocation result sent by the PCC system entity 30. Through the above system and device provided by the embodiment of the present invention, the dynamic QoS interface is opened by the PCC system to the USI system, and the dynamic QoS capability of the WiMAX system is opened to the third-party application through the USI interface. The upper application entity provides the QoS information required by the service to the PCC system through the USI system, realizes the transmission and negotiation of the QoS information of the upper application entity and the PCC system, realizes the opening of the dynamic QoS capability of the access network, and the application and access from the upper layer. End-to-end QoS guarantee.

Through the description of the above embodiments, those skilled in the art can clearly understand that the present invention can be implemented by hardware, or by software plus necessary general hardware platform. Based on such understanding, the technical solution of the present invention may be embodied in the form of a software product, which may be stored in a non-volatile storage medium (which may be a CD-ROM, a USB flash drive, a mobile hard disk, etc.), including several The instructions are for causing a computer device (which may be a personal computer, server, or network device, etc.) to perform the methods described in various embodiments of the present invention. In conclusion, the above description is only the preferred embodiment of the present invention and is not intended to limit the scope of the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and scope of the present invention are intended to be included within the scope of the present invention.

Claims

Rights request

An end-to-end quality of service QoS application method, comprising: a universal open interface system receiving a QoS application sent by an application server, and generating a QoS request sent to a policy and charging control PCC system;

 The universal open interface system transmits the generated QoS request to the PCC system and receives a QoS assignment result sent by the PCC system.

 2. The method of claim 1, wherein the method further comprises:

 Generating a universal open interface system charging identifier, and associating the universal open interface system charging identifier with the application server and the access network charging identifier;

 Adding the universal open interface system charging identifier to the QoS request.

3. The method for applying end-to-end QoS according to claim 1, further comprising:

 Obtaining media parameters from the description of the received session description protocol;

 Converting the media parameters into media component description parameters supported by the PCC system and adding them in the QoS request.

 4. The method for applying end-to-end QoS according to claim 1, further comprising:

 Generating a user terminal identifier, where the identifier includes an access network identifier and an address of the user terminal;

 Adding the user terminal identity to the QoS request.

 The method for applying the end-to-end QoS according to claim 1, wherein when the universal open interface system receives the QoS implementation duration field included in the QoS request sent by the application server, the receiving the PCC system sends the After the QoS assignment result, it also includes:

 The effective time after the QoS request is successfully applied is controlled according to the QoS implementation duration field carried in the QoS request sent by the application server.

6. The method for applying end-to-end QoS according to claim 1, wherein: Before receiving the QoS application sent by the application server, the method further includes:

 Receiving, by the application server, a user request, obtaining an address of the universal open interface system, and sending a QoS application to the address according to the user request;

 The application server obtains the address of the universal open interface system, which is specifically:

 Acquiring the user identifier or address carried in the user request, and obtaining the address of the universal open interface system according to the correspondence between the address of the pre-established universal open interface system and the user identifier or the IP address range; or

 Querying the domain name system DNS according to the domain name information in the user identifier carried in the user request, and obtaining the address of the universal open interface system; or

 Parsing the address of the generic open interface system directly carried in the user request.

 The end-to-end QoS application method according to claim 6, wherein when the user is a roaming user, the universal open interface system sends the generated QoS request to the PCC system, specifically:

 After receiving the QoS application sent by the application server, the universal open interface system of the user home network queries the user home server for the user visit network address, and sends the QoS application to the universal open interface system of the user visited network, where the user visits the network. The universal open interface system sends the generated QoS request to the PCC system; or the universal open interface system of the user home network receives the QoS request sent by the application server, and sends the generated QoS request to the PCC system of the user home network, the user The PCC system of the home network discovers user roaming, and sends the QoS request to the PCC system of the user visiting the network; or

 After receiving the QoS application sent by the application server, the universal open interface system of the user visits the network sends the generated QoS request to the PCC system of the user visited network, and the PCC system of the user visited the network sends the generated QoS to the PCC system of the user home network. Requesting, and receiving an allocation result returned by the PCC system of the home network.

 The method for applying the QoS according to claim 1, wherein before receiving the QoS application sent by the application server, the method further includes:

 Receiving the default QoS registered by the application server;

The QoS application sent by the receiving application server is specifically: Receiving a QoS index sent by the application server according to the user request; acquiring the QoS application according to the QoS index and the default QoS.

 The method for applying the end-to-end QoS according to claim 1, wherein the sending the generated QoS request to the PCC system by the universal open interface system is specifically: when the universal open interface system passes the Rx interface When the policy of the PCC system is connected to the charging decision function PCRF, the QoS request is converted into a request message, and the converted request message is sent to the PCRF through the Rx interface; or

 When the universal open interface system is connected to the policy distribution function PDF/policy and charging execution function PCEF of the PCC system through a Gx interface, converting the QoS request into a policy and charging control rule, by using the Gx interface The policy and charging control rules are sent to the PDF/PCEF.

 10. The method for applying the QoS according to claim 9, wherein the receiving the QoS allocation result sent by the PCC system is specifically:

 When the universal open interface system is connected to the PCRF of the PCC system by using the Rx interface, receiving a response message sent by the PCRF through the Rx interface, where the response message carries a QoS allocation result; or

 And when the universal open interface system is connected to the PDF/PCEF of the PCC system by using the Gx interface, receiving an answer message sent by the PDF/PCEF through the Gx interface, where the response message carries a QoS allocation result.

 The method of claim 1, wherein the receiving the QoS allocation result sent by the PCC system further includes:

 The universal open interface system sends the QoS assignment result to the application server; the QoS assignment result includes an authorization to directly the QoS request, or a tampering of the QoS request.

 The method for applying the end-to-end QoS according to claim 11, wherein after the universal open interface system sends the QoS assignment result to the application server, the method further includes:

The universal open interface system receives the termination QoS request sent by the application server, or the valid time after the QoS request application succeeds, the universal open interface The system sends a request to the PCC system to suspend or terminate QoS.

 13. An end-to-end QoS application system, comprising: an application server entity, configured to receive a user request, and send a QoS request to a general open interface system entity;

 The universal open interface system entity is configured to generate a QoS request according to the received QoS request sent by the application server entity, and send the QoS request to the policy and charging control PCC system entity; and receive the QoS allocation result sent by the PCC system entity;

 The PCC system entity is configured to receive a QoS request sent by the universal open interface system entity and return a QoS allocation result.

 The end-to-end QoS application system of claim 13, wherein the application server entity further comprises:

 a request receiving unit, configured to receive a user request;

 The address obtaining unit is configured to obtain an address of the universal open interface system entity, and send a QoS application to the acquired address according to the user request received by the request receiving unit.

 The end-to-end QoS application system of claim 13, wherein the universal open interface system entity further comprises:

 a QoS request generating unit, configured to generate, according to the QoS request sent by the application server entity, a QoS request sent to the PCC system entity;

 And a receiving unit, configured to receive a QoS allocation result sent by the PCC system entity.

The end-to-end QoS application system of claim 15, wherein the universal open interface system entity further comprises:

 And a converting unit, configured to convert the QoS request generated by the QoS request generating unit to the PCC system entity.

 17. A general open interface system entity for end-to-end QoS applications, comprising:

 a QoS request generating unit, configured to generate a QoS request sent to the policy and charging control system entity according to the QoS request sent by the application server entity;

a receiving unit, configured to receive the QoS sent by the policy and charging control system entity Assign results.

 18. The universal open interface system entity of claim 17, further comprising:

 And a converting unit, configured to convert the QoS request generated by the QoS request generating unit to the policy and charging control system entity.

 19. An application server for end-to-end QoS application, comprising:

 a request receiving unit, configured to receive a user request;

 An address obtaining unit, configured to obtain an address of a general open interface system entity, and send a QoS application to the acquired address according to the user request received by the request receiving unit