US 2007/0201366 A1Application
System And Method Of Dynamic Qos Negotiation In Next Generation Network
Publication Date:2007-08-30
•17 Claims
•6 Drawing Sheets
Abstract
The present invention discloses a system and a method of dynamic QoS negotiation in NGN. The Resource and Admission Control Subsystem (RACS) provides intercommunication interfaces with Transport functional (TF) entity, Service Control Functional (SCF) entities, and Network Attachment Subsystem (NASS), and thereby, when a user terminal in NGN is to develop a service with QoS requirement, the RACS can obtain the QoS requirement parameters of a service, determine the admission control decision parameters in accordance with the QoS requirement parameters, and the RACS send the determined admission control decision parameters to the TF entity for execution, such that the QoS assurance for the service is realized. The present invention allows an end-to-end QoS negotiation in NGN in accordance with the availability of current transport network resources, and thereby can effectively improve the transport resource utilities. Therefore, the present invention can effectively ensure QoS of service transported in NGN.
Metadata
Inventor
- Enhui Liu
Application Information
Application Number:US 10/593,251
Filing Date:2005-09-07
Priority Date:2004-09-08
Classifications
IPC:
H04J1/16H04L12/56
Patent Drawings (6 sheets)
Description
Field of the Invention
[0001] The present invention relates to network communication technology field, especially to a system and method of dynamic QoS negotiation in NGN.
Background of the Invention
[0002] One of the characteristics of Next Generation Network (NGN) is that the service layer is separated from the transport layer, and the transport layer is usually implemented based on packet switching technology and optical technology. At present, the TISPAN workgroup of Europe Telecom Standard Institute (ETSI) has established a functional framework of NGN, that supports Fixed-Mobile Convergence, on the basis of Third Generation IP Multimedia Subsystem (3G IMS). As shown in FIG. 1 , the framework includes a service layer and an IP (Internet Protocol)-based transport layer.
[0003] As shown in FIG. 1 , the service layer is composed of Network Attachment Subsystem (NASS), Resource and Admission Control Subsystem (RACS), IPMultimedia Subsystem (IMS), PSTN/ISDN Emulation Subsystem (PES), other multimedia subsystems and applications, and common service components of those subsystems; the common service components include application servers, charging functions, user profile management, and security control, etc.
[0004] Under the control of NASS and RACS, the transport layer provides IP connections between NGN terminals, which hides the transport techniques used in access and core networks below IP layer. Those subsystems can be distributed in the administrative domains of network/service providers.
[0005] In an NGN environment, a critical component that provides support for end-to-end QoS control is RACS. The position of RACS in the overall framework of NGN and the interface relationship between the RACS and the external entities are shown in FIG. 2 . The RACS needs to have interfaces with the transport layer, customer premise equipments (CPEs), NASS, IMS, PES, other service subsystems, and RACSs in other networks. RACS provides admission control function; the admission control includes resource availability check based on the user profiles stored in NASS. Resource availability check means the admission control verifies whether the requested bandwidth is consistent with the subscribed bandwidth and the used bandwidth of each user.
[0006] Due to diversity and multimedia feature of NGN services, how to implement QoS control on user service on the basis of IP-based transport layer has become an important task in NGN technical research. To this end, Internet Engineering Task Force (IETF) has put forward Integrated Service/Resource Reservation Protocol (IntServ/RSVP), Differentiated Service (DiffServ), and their policy control models and mechanisms.
[0007] In IntServ/RSVP and its policy control model put forward by IETF and the Next Step IP Signaling (NSIS) draft that is being established, as shown in FIG. 3 , users can transfer QoS parameters to the network through dedicated resource reservation signaling, to request for an expected QoS assurance level. Due to the fact that both RSVP and NSIS operate on the transport layer and pass through the same route and path as the data flow does, it is required that the CPEs support either RSVP or NSIS protocol, so as to send explicit QoS requests to the network. Such a QoS assurance method is inapplicable for users who can not initiate explicit QoS requests to the network.
[0008] In actual applications, i.e., in the current network environments, most of the CPEs (i.e., users) do not support RSVP/NSIS protocol. In addition, even if new user terminals will support RSVP/NSIS protocol gradually, it is required to provide QoS requirements that can meet the users' traffic flow on the network side. However, the Policy Decision Function (PDF) performs admission control and gate control only based on user profile and the operator's management policy rules without checking the availability of network resources based on resource status; and, consequently, assured QoS can not be provided in accordance with the actual conditions of the network.
[0009] IETF has also put forward DiffServ and its policy control model, as shown in FIG. 4 . In detail, the user makes requests and negotiations with the network on QoS, by using either of the following two methods:
[0010] One method is: CPEs perform traffic classification, Diffserv marking, policing, and shaping for the user packets; the network equipment trusts the DiffServ marks in the user packets and performs Diffserv forwarding.
[0011] The other method is: users subscribe Service Level Agreement (SLA) with the network operator through an administrative approach; the SLA contains the required QoS parameters (e.g., bandwidth and DiffServ type) for user traffic. Network Management System (NMS) statically configures the QoS parameters requested by users onto edge devices of the network via policy control interface or network management interface. The edge devices perform traffic classification, Diffserv marking, policing, and shaping on the user packets in accordance with the QoS configuration; the core devices perform DiffServ forwarding in accordance with the DiffServ marks in the packets marked by the edge devices.
[0012] In DiffServ and its policy control model put forward by IETF, users perform QoS negotiation with the network in the management plane. In the network, the user QoS request is represented with the value of the Diffserv mark in the packet. Since a DiffServ mark has a length of only 3 bits, which can only reflect the relative requirements including QoS level and priority but can not transfer the user expected QoS parameters from end to end, including bandwidth, delay, jitter, and packet loss rate, etc.; therefore, the user traffic can only be provided with a relative QoS differentiation from the network. In addition, it is unable to implement QoS assurance for user service based on network resource availability as well.
Summary of the Invention
[0013] In the present invention, there is provided a system of dynamic QoS negotiation in NGN, including:
[0014] a Resource and Admission Control Subsystem (RACS), adapted to obtain and process resource reservation requests required for a media flow of a service transported in NGN, perform authentication and make admission control decisions based on operation policy rules, user profile, and availability of transport resources, and send the admission control decision parameters to a concerned transport functional (TF) entity for execution, wherein the reservation request contains QoS requirement parameters;
[0015] the transport functional entities, adapted to ensure QoS of the media flow of the service transferred in NGN according to the admission control decision parameters.
[0016] The system of dynamic QoS negotiation in NGN further includes:
[0017] a service control functional (SCF) entity, adapted to communicate with user terminals, obtain the QoS requirement parameters required for the service requested by a user terminal by parsing service signaling or determine the QoS requirement parameters according to the service policies, and send the QoS requirement parameters to the RACS.
[0018] The system of dynamic QoS negotiation in NGN further includes:
[0019] a Network Attachment Subsystem (NASS), adapted to manage and configure user access network, communicate with the RACS and the SCF entity, and provide the RACS and the SCF entity with user profile information associated with the service.
[0020] The present invention also provides a method of dynamic QoS negotiation in NGN, including:
[0021] A. obtaining by a RACS in NGN QoS requirement parameters required by a media flow of a service;
[0022] B. performing by the RACS admission control in accordance with the QoS requirement parameters and determining admission control decision parameters;
[0023] C. sending by the RACS the admission control decision parameters to a concerned transport functional (TF) entity at network boundary, executing by the transport functional entity at network boundary the admission control decision parameters to process and transfer the media flow of the service accordingly.
[0024] Wherein:
[0025] the RACS obtains the QoS requirement parameters of the media flow of the given service through a Service Control Functional (SCF) entity, a Network Attachment Subsystem (NASS), the TF entity, or a Network Management System (NMS).
[0026] When the service includes a plurality of media flows, it is needed to determine the QoS requirement parameters for each of the media flows respectively.
[0027] Before the step of obtaining by a RACS in NGN QoS requirement parameters required by a media flow of a service, the method further includes a step E:
[0028] initiating by a user terminal a service request to a SCF entity;
[0029] when the service request does not carry the QoS requirement parameters of the media flow of the service, determining by the SCF entity the type of the service in accordance with the service request, and determining the QoS requirement parameters required for the media flow of the service in accordance with the service type;
[0030] when the service request carries the QoS requirement parameters of the service, obtaining by the SCF entity the QoS requirement parameters of the media flow of the service by parsing the service request signaling.
[0031] If the user terminal is a fixed terminal, the step E further includes:
[0032] sending by the SCF entity a resource reservation request containing the QoS requirement parameters of the media flow of the service to the RACS via a corresponding interface with the RACS.
[0033] If the user terminal is a mobile terminal, the step E further includes:
[0034] Sending by the SCF entity a resource authentication request containing the QoS requirement parameters of the media flow of the service to the RACS via a corresponding interface with the RACS;
[0035] after the RACS authenticates successfully, notifying by the RACS the user terminal via the SCF entity;
[0036] initiating by the user terminal a resource reservation request to the TF entities of the network via a path-coupling QoS signaling carrying the QoS requirement parameters of the media flow of the service; handling by the TF entity at network boundary the QoS signaling and sending a resource reservation request containing the QoS requirement parameters of the media flow of the service to the RACS via a corresponding interface with the RACS.
[0037] If the token mechanism is used, after authenticating successfully, returning by the RACS an admission token to the user terminal via the SCF entity; carrying the admission token in a path-coupling QoS signaling and transferring the admission token to the RACS via a resource reservation request; checking by the RACS whether the resource reservation request has passed the authentication and searching for relevant information of the service in accordance with the admission token.
[0038] The RACS determines the admission control decision parameters through the following steps:
[0039] obtaining, by the RACS, the user profile information of the service and the policy rules information configured by the operator, making admission control decision for the QoS requirement parameters of the service based on the user profile information and the policy rules information, deciding whether to permit the media the flow of the service to enter into the transport network and to be treated with the requested QoS, and determining the admission control decision parameters.
[0040] The RACS may also determine the admission control decision parameters through the following steps:
[0041] obtaining by the RACS the current status information of the transport resources in the network, making admission control decision for the QoS requirement parameters of the media flow of the service based on above information, checking whether there are enough transport resources available in the network to meet the QoS requirement parameters of the media flow of the service, and determining the admission control decision parameters.
[0042] The admission control decision parameters include:
[0043] Gate control, bandwidth allocation, Differentiated Service Code Point (DSCP) mark, and outgoing aggregation path information.
[0044] The QoS parameters include:
[0045] bandwidth requirements for transferring the media flow of the service, as well as QoS classes indicating allowable delay, jitter, packet error rate and packet loss rate.
[0046] The method of dynamic QoS negotiation in NGN further includes:
[0047] directly initiating by the user terminal a resource reservation request to the TF entities for the media flow of the service via a path-coupling dedicated QoS signaling;
[0048] when the TF entity at network boundary receives the resource reservation request from the user terminal, sending by the entity a resource reservation request carrying the QoS requirement parameters of the media flow of the user service to the RACS, and executing the step C.
[0049] The method of dynamic QoS negotiation in NGN further includes:
[0050] Configuring, by the NMS or the NASS, gate control, bandwidth allocation, DSCP marking control, and outgoing aggregation path parameters onto the TF entity at network boundary via the RACS.
[0051] It can be seen from the above technical solution provided in the present invention that the present invention provides end-to-end dynamic QoS request and negotiation processing procedures for different types of user terminals in NGN. Through the interaction between users and network as well as the interaction between network service layer and transport layer, the present invention is applicable to dynamic QoS negotiation processing for user terminals with different capabilities and for different business models required by the operators; furthermore, the present invention mainly utilizes the RACS in NGN to perform QoS negotiation processing, so as to implement an end-to-end QoS negotiation processing in accordance with the availability of current network transport resources in NGN, and thereby improve resource utilities with QoS treatment. Therefore, the present invention can effectively ensure the QoS of service transferred in NGN.
Brief Description of the Drawings
[0052] FIG. 1 is a structural schematic diagram of NGN;
[0053] FIG. 2 is a schematic diagram of the external interface of RACS in NGN;
[0054] FIG. 3 is a schematic diagram of IntServ and its policy control model;
[0055] FIG. 4 is a schematic diagram of DiffServ and its policy control model;
[0056] FIG. 5 to FIG. 9 are flow charts of an embodiment of the method described in the present invention.
Detailed Description of the Embodiments
[0057] The key idea of the present invention is to utilize RACS to obtain QoS parameter information required for a media flow of given service requested by CPEs and determine the corresponding admission control decision parameters based on the QoS parameter information and resource availability information, and finally to utilize transport functional entity to execute the admission control decision parameters so as to process and transfer the media flow of the service accordingly, and thereby providing corresponding QoS assurance for services transferred in the network.
[0058] First, in the present invention, in view of the diversity of access technologies and CPEs in NGN, it is required to investigate how user terminals with different QoS negotiation abilities and employing different access technologies can request and negotiate QoS with the network dynamically, with support of different business models taken into account. Second, since the various administrative domains in NGN may employ different QoS technologies in data plane and business models, it is required to consider how to support the QoS requirements of user traffic across different administrative domains and different QoS technology domains.
[0059] To this end, first, the present invention provides a system of dynamic QoS negotiation in NGN. The structure of the system according to an embodiment of the present invention is shown in FIG. 5 , the system including:
[0060] a Resource and Admission Control Subsystem (RACS), which is adapted to obtain the QoS parameter information required by a media flow of a service transferred in NGN, determine admission control decision parameters based on the QoS parameter information and transport network resource availability information, and send the admission control decision parameters to concerned transport functional entities;
[0061] the RACS obtains the QoS parameter information mainly via a service control functional entity; the RACS can also obtain the QoS parameter information via NASS, or via the transport functional entities;
[0062] the transport functional entity, which is adapted to obtain admission control decision parameters sent from the RACS and execute the admission control decision parameters to implement QoS treatment for the media flow of the service transferred in NGN;
[0063] The service control functional entity, which is adapted to communicate with a user terminal to obtain directly or indirectly the QoS parameter information required by the service requested by the user terminal and send the QoS parameter information to the RACS;
[0064] when the user terminal is to develop a service, it has to initiate a service request to the service control functional entity first, and the request can carry the QoS parameter information required by the service; also, the service control functional entity can obtain the QoS parameter information of the media flow of the service through negotiation between the user terminal and the opposite user or an application server; in addition, the service control functional entity can determine the corresponding QoS parameter information in accordance with the type of the service requested by the user terminal;
[0065] a Network Attachment Subsystem (NASS), which communicates with the RACS and the service control functional entities to provide them user profile information associated with the service.
[0066] Based on the RACS and the interface relationship between the RACS and the external entities in NGN, the present invention provides a framework and a method to enable a user terminal (i.e., CPE) to request and negotiate QoS with the network in NGN environment, and thereby, through the interaction between the user terminal and the network as well as the interaction between the network service layer and the transport layer, to support QoS assurance for the services requested by user terminals with different QoS negotiation capabilities and various business models.
[0067] On the basis of above mentioned system, the present invention also provides a processing information flow to enable a user terminal to request and negotiate QoS with the network in NGN environment. As shown in FIG. 5 , the service control functional (SCF) entity is responsible for functions of service session setup, control, and termination in the service subsystems, such as call session control function (CSCF) in IP Multimedia Subsystem. The present invention utilizes the interaction between CPE and SCF entity or transport functional (TF) entity to transfer QoS request and acknowledge information, and utilizes the RACS to process the interaction and negotiation on QoS support between SCF entity and TF entity, so as to implement an end-to-end QoS control and thereby meet the QoS request of the user terminal.
[0068] In the present invention, in order to implement resource usage-based charging, the SCF entity and the RACS need to interact with the TF entity, to collect resource usage information for charging for the user service.
[0069] The present invention can support user terminals with different QoS negotiation capabilities and various business models.
[0070] User terminals can be classified into the following categories, regarding the different QoS negotiation capabilities:
[0071] 1. User terminals unable to send explicit QoS requests by way of any signaling;
[0072] 2. User terminals that support initiating resource reservation requests in dedicated QoS signaling, such as RSVP or NSIS;
[0073] 3. User terminals that support negotiating QoS requirement in service signaling such as Session Initiation Protocol/Session Description Protocol (SIP/SDP), etc.;
[0074] 4. User terminals that support negotiating QoS with cooperation of service signaling and dedicated QoS signaling.
[0075] The business models can be classified into three categories, regarding the QoS differentiation level:
[0076] 1. QoS differentiation at application flow level: before a media flow of a service with transport QoS requirements are started, the user terminal needs to initiate a definite QoS request to the network for the media flow; the media flow is treated in the network with the QoS parameters expected in the user QoS request; different media flows may be treated in the network at different QoS levels;
[0077] 2. QoS differentiation at service type level: the user does not need to initiate a QoS request explicitly, while the QoS requirement for the service is implied by the service type; the network is responsible for determining the QoS level required by the traffic flow in accordance with the service type; the traffic flows of different types of services may be treated at different QoS levels;
[0078] 3. QoS differentiation at user level: in accordance with the Service Level Agreement (SLA) signed between the user and the network operator, the user traffic flow will be treated at the QoS level expected in the SLA; the traffic flows of different users may be treated at different QoS levels.
[0079] The prevent invention provides several QoS request and negotiation processing flows for user terminals with different QoS capabilities and different business models; though those processing flows are the same in the fundamental principle, they are different in implementation approach; the operator can choose the appropriate QoS request and negotiation processing flow, in accordance with the QoS negotiation capability of the user terminal and the expected business model.
[0080] First, the fundamental principle of the method described in the present invention is described hereunder:
[0081] When the CPE is to develop a service requiring corresponding QoS assurance, the RACS in NGN obtains the corresponding QoS request information, performs authentication, and makes admission control decision for the QoS request information of the service. Since transport network status information such as network resource usage and network performance may be known in the RACS, the most reasonable admission control decision parameters can be determined for the corresponding service in accordance with the actual conditions of the network.
[0082] Now, the method provided in the present invention is described, with reference to the accompanying drawings and preferred embodiments. The embodiments involve QoS request and negotiation processing flows implemented in accordance with the user terminals with different QoS negotiation capabilities and business models, respectively. Hereunder the QoS request and negotiation processing flows will be described in several examples.
[0083] 1. When the business model is QoS differentiation at service type level, the QoS requirement of a user service will be implied by the service type; in addition, the QoS request will be initiated by an SCF entity or a signaling gateway as an agent of the user in accordance with the user service type.
[0084] A corresponding and specific QoS request and negotiation processing flow, i.e., a corresponding dynamic QoS negotiation processing flow as shown in FIG. 5 , includes the following steps:
[0085] step 51: the user initiates a service request, e.g., call setup request, to the network; wherein, it is not required to contain the QoS requirement parameters of the current service explicitly in the service request;
[0086] step 52: when the SCF entity or signaling gateway receives the user service request, it determines the QoS parameters required for the current service in accordance with the service type; the QoS parameters include: the bandwidth required for the current service as well as allowable delay, jitter, and packet loss rate, etc.;
[0087] at the same time, the SCF entity or signaling gateway needs to send a QoS request (containing the QoS parameter information) for the current service to the RACS as an agent of the user;
[0088] certainly, when a service includes a plurality of data flows at a time, it is required to determine the QoS parameters for each data flow and to send the corresponding QoS requests at the SCF entity or signaling gateway;
[0089] step 53: when the RACS receives the QoS request, it performs authentication and makes admission control decision on the received QoS request in accordance with user profile, operator-specific policy rules, and resource availability, to determine the corresponding admission control decision parameters;
[0090] in detail, when the RACS receives the QoS request, it is required to obtain the user profile and operator-specific policy rules, such as user identity information, SLA information, and the network configuration information corresponding to the user, etc.; in addition, RACS needs to check the availability of the current network resources, such as available bandwidth resource, occupied bandwidth resource, and network performance of the data flow path of the user in the network; after obtaining above information, the RACS can perform authentication and make admission control decision on the QoS request of the service in accordance with the obtained resource availability information;
[0091] in addition, when RACS determines to permit the service to be transported in the network in accordance with the requested QoS parameters, it sends admission control decision parameter information such as gate control, bandwidth allocation, (Differentiation Service Code Point) DSCP mark, and outgoing aggregation path information etc. to the TF entity at the boundary of the network for traffic forwarding;
[0092] the QoS request and negotiation flow provided in step 51 to step 53 is especially suitable for voice service and simple terminals.
[0093] 2. When the user terminal supports initiating explicit QoS requests to the network service layer via service signaling such as SIP/SDP etc., the specific dynamic QoS negotiation processing flow as shown in FIG. 6 includes:
[0094] first, the user terminal initiates a service request, e.g., call setup request, to the network; during the service setup process, the user terminal can negotiate the QoS parameters required for the current service with the opposite terminal or application server via service layer signaling (e.g., session description protocol of SIP or capability exchange protocol of H.323); the specific negotiation procedures may be identical to those in the prior art, and will not be defined in the present invention;
[0095] if a service includes a plurality of media flows, the corresponding QoS parameters have to be negotiated for each of the media flows respectively.
[0096] step 61: after the user terminal obtains the QoS parameters through negotiation, it sends a service request carrying the QoS parameters to the SCF entity;
[0097] step 62: when the SCF entity receives the user service request, it extracts the QoS parameters from the service request, and then forwards the QoS request to the RACS;
[0098] step 63: based on user profile, operator-specific policy rules, and resource availability, the RACS performs authentication and makes admission control decision on the received QoS request; when the RACS determines to permit media flows of the service to be transferred in the network in accordance with the requested QoS parameters, it sends gate control, bandwidth allocation, DSCP marking control, outgoing aggregation path control information, etc., to the TF entity at the boundary of the network for traffic forwarding.
[0099] The QoS request and negotiation processing flow provided in step 61 to step 63 is suitable for multimedia services and terminals.
[0100] 3. The User terminal initiates an explicit QoS request to the network service layer via a path-decoupling dedicated QoS signaling; the path-decoupling QoS signaling indicates that the QoS signaling path is independent to the user data flow path to which it provides service.
[0101] In that case, the specific dynamic QoS negotiation processing flow as shown in FIG. 7 includes:
[0102] step 71: the user initiates an explicit QoS request to the network service layer (i.e., SCF entity) via a path-decoupling dedicated QoS signaling for a data service at a time or a certain data service that requires QoS assurance; the QoS request contains the media flow identification information, such as source and destination addresses, port, and protocol type of the media flow, etc.;
[0103] step 72: when the SCF entity receives the QoS request, it performs authentication for the data service in accordance with the media flow identification information, and forwards the QoS request of the current service to the RACS after successful authentication;
[0104] Step 73: based on user profile, operator-specific policy rules, and resource availability, the RACS performs authentication and make admission control decision on the received QoS request after it receives the QoS request message; if the RACS determines to permit media flows of the service to be transferred in the network in accordance with the requested QoS parameters, it sends gate control, bandwidth allocation, DSCP marking control, outgoing aggregation path control commands, etc., to the TF entity at the boundary of the network for traffic forwarding.
[0105] The QoS request and negotiation processing flow described in step 71 to step 73 is suitable for point-to-point or point-to-multipoint data services that require QoS assured paths.
[0106] 4. When the user terminal performs a two-stage QoS request and negotiation via the cooperation of service signaling with path-coupling dedicated QoS signaling, the corresponding specific dynamic QoS negotiation processing flow as shown in FIG. 8 may be divided into two stages; the path-coupling QoS signaling indicates that the QoS signaling path is identical to the user data flow path to which it provides service; hereunder the two stages will be described:
[0107] In the first stage:
[0108] step 81: the user initiates a service request (e.g., call setup request) to the network via the SCF entity, and during the service setup process, negotiates the QoS parameters required for current service with the opposite user or application server via SDP or capability exchange of H.323;
[0109] if a service contains a plurality of media flows at a time, the corresponding QoS parameters need to be negotiated for each of the media flows;
[0110] step 82: when the SCF entity receives the service request of the user terminal, it extracts the QoS parameters to be negotiated from the request, and then sends a resource authentication request to the RACS;
[0111] step 83: when the RACS receives the resource authentication request, it obtains the user profile and operator-specific policy rules, and determines availability of the current network resources; then, based on the user profile, operator-specific policy rules, and availability of current transport resources, the RACS performs authentication on the received QoS request; if the RACS determines to permit the service to be transported in the network in accordance with the negotiated QoS parameters, it sends an acknowledgement and an admission token (i.e., Token) to the SCF entity;
[0112] step 84: when the SCF entity receives the admission token, it notifies the admission token to the corresponding user terminal;
[0113] It should be noted that the steps 82 to 84 in the first stage can be omitted in the case of a simplified procedure, and in this case, in the second stage, only the negotiated QoS requirement parameters are carried or processed, but the token is not needed to be carried or processed.
[0114] In the second stage:
[0115] step 85: the user terminal initiates a resource reservation request to the network transport layer via a path-coupling dedicated QoS signaling protocol (e.g., RSVP or NSIS), the request carrying the QoS requirement parameters negotiated in the service setup process and the admission token;
[0116] step 86: when the TF entity at network boundary receives the resource reservation request, it sends the admission token and the resource reservation request to the RACS;
[0117] step 87: when the RACS receives the QoS request, it performs admission control in accordance with the admission token in the request; and if the RACS determines to permit the media flow of the service for the user terminal to be transferred in the network in accordance with the negotiated QoS parameters, it sends a resource reservation response as well as gate control, bandwidth allocation, DSCP marking control, and outgoing aggregation path control commands, etc., to the TF entity at network boundary;
[0118] when the TF entity at network boundary receives the resource reservation response, it forwards or terminates the resource reservation request of the user.
[0119] The dynamic QoS negotiation processing flow described in step 81 to step 87 is especially suitable for mobile multimedia services and terminals.
[0120] In order to be compatible with the prior art, the present invention also provides the following two dynamic QoS negotiation processing flows.
[0121] The first one: if a user terminal directly initiates a resource reservation request to the network transport layer via a dedicated path-coupling QoS signaling, the employed dynamic QoS negotiation process as shown in FIG. 9 includes:
[0122] step 91: the user directly initiates the resource reservation request to the network transport layer (i.e., the TF entity at network boundary) via a dedicated path-coupling QoS signaling such as RSVP or NSIS etc.;
[0123] step 92: when the TF entity at network boundary receives the resource reservation request, it sends a resource reservation request carrying the user resource reservation request information to the RACS;
[0124] step 93: when the RACS receives the resource reservation request, it obtains the user profile, operator-specific policy rules, and availability of the current transport resources, and performs authentication and makes admission control decision on the received resource reservation request; if the RACS determines to permit the request, it sends a resource reservation response as well as gate control, bandwidth allocation, DSCP marking control, outgoing aggregation path control commands, etc., to the TF entity at network boundary; when the TF entity receives the resource reservation response, it forwards or terminates the resource reservation request of the user.
[0125] The dynamic QoS negotiation processing flow described in step 91 to step 93 is a QoS parameter transfer approach adapted for the compatibility with the IntServ/RSVP and its policy control model put forward by IETF as described in the prior art.
[0126] The second one: a dynamic QoS negotiation processing flow that is used when a user does not perform dynamic QoS negotiation with the network but subscribes a service level protocol (i.e. SLA) containing the QoS requirement parameters with the operator. The processing flow is detailed as: based on the QoS requirement parameters in the SLA subscribed by the user with the operator, the NMS or NASS configures the gate control, bandwidth allocation, DSCP marking control, and outgoing aggregation path control parameters onto the TF entity at network boundary via the RACS. That processing flow may be compatible with the QoS request and negotiation processing approach that is used in the Diffserv and its policy control model put forward by IETF, as described in the prior art.
[0127] Though the present invention is described with above preferred embodiments, the protective scope of the present invention shall not be restricted by those embodiments. Any technician skilled in the field can be easily suggested modifications or alternations to the present invention with the technical scope disclosed in the present invention; any of such modifications or alternations shall be covered by the protected scope of the present invention as defined by the claims accompanied hereunder.
Claims
1. A system of dynamic QoS negotiation in NGN, comprising:
a Resource and Admission Control Subsystem (RACS), adapted to obtain and process a resource reservation request required for a media flow of a service transferred in NGN, perform authentication and determine admission control decision parameters based on operation policy rules, user profile, and availability of transport resources, and send the admission control decision parameters to a concerned Transport Functional (TF) entity for execution, wherein said reservation request contains QoS requirement parameters;
the transport functional entity, adapted to ensure QoS of the media flow of the service transferred in NGN according to the admission control decision parameters.
2. The system as in claim 1, wherein the system further comprises:
a service control functional (SCF) entity, adapted to obtain the QoS requirement parameters required for the service requested by a user terminal by parsing service signaling or determine the QoS requirement parameters according to the service policies, and send the QoS requirement parameters to said RACS.
3. The system as in claim 1, wherein the system further comprises:
a Network Attachment Subsystem (NASS), adapted to manage and configure user access network, communicate with said RACS and said SCF entity, and provide said RACS and said SCF entity with user profile information associated with the service.
4. The system as in claim 1, wherein the RACS obtains the QoS requirement parameter information from the TF entity.
5. A method of dynamic QoS negotiation based on the system of dynamic QoS negotiation in NGN, comprising:
A. obtaining, by a Resource and Admission Control Subsystem (RACS) in NGN, QoS requirement parameters required by a service;
B. performing, by said RACS, admission control in accordance with the QoS requirement parameters, and determining admission control decision parameters;
C. sending, by said RACS, the admission control decision parameters to a transport functional (TF) entity at network boundary, and executing, by said transport functional entity at network boundary, the admission control decision parameters to process and transfer the media flow of the service accordingly.
6. The method as in claim 5, further comprising
obtaining, by said RACS, the QoS requirement parameters of the service through a Service Control Functional (SCF) entity, a Network Attachment Subsystem (NASS), the TF entity, or a Network Management System (NMS).
7. The method as in claim 5, wherein
when the service comprises a plurality of media flows, it is needed to determine the QoS requirement parameters for each of the media flows respectively.
8. The method as in claim 5, wherein, before the step of obtaining by a Resource and Admission Control Subsystem (RACS) in NGN QoS requirement parameters required by a service the method further comprising a step E:
initiating, by a user terminal, a service request to the SCF entity;
when the service request does not carry the QoS requirement parameters of the service, determining by the SCF entity the type of the service in accordance with the service request, and determining the QoS requirement parameters required for the service in accordance with the service type;
when the service request carries the QoS requirement parameters of the service, obtaining by the SCF entity the QoS requirement parameters of the service by parsing the service request.
9. The method as in claim 8, wherein when the user terminal is a fixed terminal, the step E further comprises:
the SCF entity sending a resource reservation request containing the QoS requirement parameters of the service to the RACS via a corresponding interface with the RACS.
10. The method as in claim 8, wherein when the user terminal is a mobile terminal, the step E further comprises:
sending, by the SCF entity, a resource authentication request containing the QoS requirement parameters of the service to the RACS via a corresponding interface with the RACS;
after authenticating successfully, notifying, by the RACS, the user terminal via the SCF entity;
initiating, by the user terminal, a resource reservation request to the TF entity of the network via a path-coupling QoS signaling carrying the QoS requirement parameters of the service; handling by the TF entity at network boundary the QoS signaling and sending a resource reservation request containing the QoS requirement parameters of the service to the RACS via a corresponding interface with the RACS.
11. The method as in claim 5, 8, or 10, wherein when a token mechanism is used, the method further comprises:
after authenticating successfully, returning by the RACS an admission token to the user terminal via the SCF entity; carrying the admission token in a path-coupling QoS signaling and transferring the admission token to the RACS via a resource reservation request; checking by the RACS whether the resource reservation request has passed the authentication and searching for relevant information of the service in accordance with the admission token.
12. The method as in claim 5, wherein said determining by the RACS the admission control decision parameters comprises:
obtaining, by the RACS, the user profile information of the service and the policy rules information configured by the operator, making admission control decision for the QoS requirement parameters of the service based on the user profile information and the policy rules information, deciding whether to permit the media flow of the service to enter into the transport network and to be treated with the requested QoS, and determining the admission control decision parameters.
13. The method as in claim 5 or 12, wherein determining by said RACS the admission control decision parameters comprises:
obtaining, by the RACS, the current status information of the transport resources in the network, making admission control decision for the QoS requirement parameters of the service based on above information, checking whether there are enough transport resources available in the network to meet the QoS requirement parameters of the service, and determining the admission control decision parameters.
14. The method as in claim 5, wherein the admission control decision parameters comprise:
gate control, bandwidth allocation, Differentiated Service Code Point mark, and outgoing aggregation path control information.
15. The method as in claim 5, wherein the QoS requirement parameters comprise:
bandwidth required for transporting the media flow of the service, as well as allowable delay, jitter, and packet loss rate.
16. The method as in claim 5, further comprising:
directly initiating, by the user terminal, a resource reservation request to the TF entity for the media flow of the developed service via a dedicated path-coupling QoS signaling;
upon receiving the resource reservation request from the user terminal, sending, by the TF entity at network boundary, a resource reservation request carrying the QoS requirement parameters of the media flow of the user service to the RACS, and executing step C.
17. The method in claim 5, further comprising:
configuring, by the NMS or the NASS, gate control, bandwidth allocation, DSCP marking control, and outgoing aggregation path control parameters onto the TF entity at network boundary via the RACS.