QoS Issues in Converged Networks

1 QoS Issues in Converged Networks and Service Transformation of Operators
Quality of Service (QoS) plays an important role in the converged networks. Different services require different QoS, which indicates QoS is correlative to services.

    Many operators, especially the fixed network operators, are currently facing an awkward situation of communication traffic increasing but business income falling. The operators desire to transform from extensive bandwidth operation to intensive QoS-guaranteed multi-services operation. In this way, the operators can not only charge communication (bandwidth) fee, but also offer the QoS-guaranteed services, including the real-time services such as IP phone, 3D games and IPTV services, with special charges. Moreover, the QoS-guaranteed value-added communication services are the new service growth points that bring new bandwidth revenue.
There is no complete set of QoS transport resource control mechanism that is controlled and triggered by services on the existing networks. Both the International Telecommunication Union (ITU) and the Telecoms & Internet Converged Services & Protocols for Advanced Networks (TISPAN) are involved in working out solutions and standards for service-related QoS strategies, resource control, service assurance and accounting[1-2].

2 Architecture of QoS Controlling on Converged Network
The architecture of QoS control is shown in Figure 1, where the key component is the Resource and Admission Control Function (RACF), located between the service layer and transport network. It ensures the QoS requirements of the Service Control Function (SCF) at the service layer by controlling the system resources of the transport network.

    The RACF is aimed at providing real-time application-driven and policy-based transport resource management for all kinds of services in different transport networks. The RACF provides the SCF with an abstract transport network architecture, and it makes the service layer unnecessary to know network topology, network links, resource utilization and QoS mechanism of the transport network. It is not, however, limited to only support IMS application services.

    The RACF executes policy-based transport resource control according to the request of the SCF, determines available transport resources, makes admission decisions, and applies the control policy to the transport functional entity for execution. It interacts with the transport function for the purpose of fulfilling the following functions: bandwidth reservation and allocation, packet filtering, traffic classification, QoS marking, traffic shaping, priority handling, Network Address Translation (NAT), and firewall control. Moreover, it interacts with the Network Attachment Control Function (NACF) to get the subscriber profile, takes the current situation of transport network resources into account, and finally makes the policies for transport resource control.

    The RACF implements the following QoS control functions:

• To control the QoS-related transport resources within packet networks and at the network boundaries
• To support different access and core transport technologies, while hiding network technological and administrative details from the SCF
• To support QoS-capable user equipment
• To support resource and admission control within an administrative domain and between administrative domains
• To act as the arbitrator for QoS-related transport resource negotiation between the SCF and transport functions
• To support both relative QoS control, such as Differentiated Services (DiffServ), and absolute QoS control, such as Integrated Services InterServ (InterServ)
• To verify the availability of end-to-end transport resources
• To support the QoS policies for various media stream and users
• To support QoS signalling
• To authorize requests for QoS, and to operate only on the authorized requests for QoS
• To support Network Address Port Translation (NAPT) control and various firewall modes
• To support NAT traversal
• To export information for supporting accounting based on resources usage and QoS handling
• To support different methods for resource-based admission control
• To support service priority handling
  

3 QoS Service Modes and Resource Control in  Converged Network

3.1 QoS Capability of User Equipment
The user equipment can be categorized into three types:

    (1) Type 1: User Equipment without QoS Negotiation Capability
    This type of user equipment (such as game terminals) has no QoS negotiation capabilities at either the transport or service layers. It can communicate with the SCF for service initiation, but cannot directly request QoS resources.

    (2) Type 2: User Equipment with QoS Negotiation Capability at Service Layer
    This type of user equipment (such as SIP phone) can perform QoS negotiation through service signaling, but is unaware of QoS attributes specific to the transport layer. The service QoS only concerns applications-related QoS.

    (3) Type 3: User Equipment with QoS Negotiation Capability at Transport layer
    This type (such as UMTS user equipment) supports transport signaling similar to the Resource Reservation Protocol (RSVP). Hence, it is able to directly negotiate QoS at the transport layer with transport equipment.

3.2 Resource Control Modes
The RACF is required to support the following QoS resource control modes:

    (1) Push Mode
    The RACF makes the authorization and resource control decision according to the policy, and instructs the transport functional entity to execute the decision.

    (2) Pull Mode
    The RACF makes the authorization according to the policy, and upon the request of the transport functional entity, re-authorizes the resource request and responds with the final resource control decision for execution.

3.3 QoS Control Processes

3.3.1 QoS Resource Control Process in Push Mode
The push mode is suitable for all types of user equipment; Types 1 and 2 can only adopt the push mode.

    User equipment Type 1 has no QoS negotiation capability. The SCF is responsible for deriving the QoS needs of the requested service and sending a request to the RACF for QoS resource authorization and reservation.

    Type 2 supports QoS negotiation at the service layer. The SCF is responsible for extracting the service QoS request from the service signaling and sending it to the RACF for QoS authorization and resource reservation.

    Type 3 adopts the same QoS resource control process as Type 2. However, it requires the RACF to send authorization and QoS resource reservation information to the transport functional entity in advance. The transport-layer QoS signaling sent by user equipment can be used to invoke QoS resources in the transport functional entity and execute the QoS policy.

    The detailed process is depicted in Figure 2 with the illustrations below.

    (1) The user equipment sends a service request (such as a SIP request) to the SCF. The service request may include QoS requirement parameters.

    (2) The SCF derives or extracts the QoS requirement parameters from the request, and then sends a resource reservation request that contains the explicit QoS requirement parameters to the RACF to ask for QoS authorization and resource reservation.

    (3) The RACF gives authorization and implements admission control according to the policy, resource situation and subscriber profiles stored in the NACF. If the resource reservation request is granted, the RACF pushes gate control, packet QoS marking and bandwidth allocation decisions to the transport functional entity.

3.3.2 QoS Resource Control Process in Pull Mode
The pull mode is only applied to the user equipment Type 3. This equipment can initiate an explicit QoS resource reservation request directly to the transport function through the QoS signaling at the transport layer, following a dedicated transport path. But the QoS resource reservation needs pre-authorization of the SCF.

    Detailed control process is depicted in Figure 3 with the illustrations given below.

    (1) The user equipment sends a service request (such as a SIP request) to the SCF. The request may include QoS requirement parameters.

    (2) The SCF derives or extracts the QoS requirement parameters from the service request, and then sends a resource reservation request that contains the QoS requirement parameters to the RACF, with a purpose to ask for QoS authorization and resource reservation.

    (3) The RACF gives authorization according to the policy. If the resources are authorized, an authorization token will be assigned to this service and the user equipment will be informed. However, the use of an authorization token is optional.

    (4) The user equipment sends an explicit QoS request for resource reservation directly to the transport function through the QoS signaling at the transport layer. This request includes the explicit QoS parameters for the transport layer and the authorization token that was assigned before.

    (5) Upon receiving the QoS request, the transport function sends a request to the RACF for resource reservation and admission control, in which the authorization token may be contained.

    (6) The RACF gives authorization and implements admission control according to the policy, resource availability and subscriber profiles stored in the NACF. If the resource reservation request is granted, the RACF pushes gate control, packet QoS marking and bandwidth allocation decisions to the transport functional entity.

4 TISPAN’s QoS Implementation Architecture and Research Plans
The European Telecommunications Standards Institute (ETSI) merged the Services and Protocol for Advanced Network (SPAN) organization, focusing on fixed-network standards, and the Telecommunications and Internet Protocol Harmonization over Networks (TIPHON) organization, focusing on Voice over Internet Protocol (VoIP) research, into a new committee called TISPAN in September 2003. The  TISPAN is responsible for all aspects of standardization for present and future converged networks including VoIP networks and NGN. It emphasizes network convergence so that fixed network and wireless users can communicate seamlessly. As a result, operators can provide fixed and mobile services through a public network. Based on the IMS architecture, TISPAN proposes the NGN system architecture and logical functional structure, and reuses the IMS R6 specifications as much as possible. However, the TISPAN NGN should support many access technologies, including all kinds of Digital Subscriber Lines (xDSL), Wireless Local Area Network (WLAN) and Local Area Network. The purpose is to make IMS become a common platform based on SIP and support multiple access technologies covering both fixed and mobile networks.

    TISPAN is mapping out relevant NGN specifications, and has finished TISPAN-NGN R1[3].

    TISPAN proposes the Resource and Admission Control Subsystem (RACS) architecture to implement QoS control with details shown in Figure 4.

    The functions of the RACS are mostly equivalent to those of the RACF as mentioned above. The RACS has two functional entities: Service-based Policy Decision Function (SPDF) and Access-Resource and Admission Control Function
(A-RACF). The Application Function (AF) is an abstract of the service layer. The Network Attachment Subsystem (NASS)[4] is equivalent to the NACF. The transport functional entities include the Border Gateway Function (BGF), IP edge device (such as BRAS) and access node (such as DSLAM).

    The SPDF are mainly responsible for:

• Checking if the request received from the AF is consistent with the local policy;
• Authorizing the requested resources for the AF;
• Determining the location of the BGF and A-RACF;
• Asking the A-RACF for the requested resources and admission control;
• Asking the BGF for the requested resources and NAT control enforcement;
• Hiding details of the transport layer from the AF.
  

    The A-RACF mainly implements admission control and policy assembly.

    (1) Admission Control
    When the A-RACF receives a resource reservation request from the SPDF, it obtains subscription information of the subscriber from the NASS first. Then, it will decide whether to allow the requested resource reservation or not,  taking the local policy and access network situation into account.

    (2) Policy Assembly
    The A-RACF provides the Resource Control Enforcement Function (RCEF) with an explicit policy description, or offers a pre-defined policy ID, which will be mapped into the specific L2/L3 transport policies. For practical networking, one SPDF may control multiple A-RACF entities and is responsible for QoS policy decisions of the entire network. Each A-RACF is capable of managing a specific access network. It adopts corresponding transport QoS policies to perform management and control functions, and to hide network structure and QoS attributes of the access network.
The BGF is a user-plane gateway, performing both QoS policy enforcement and NAT functions. It fulfills gateway control of media stream, packet marking, resource allocation, NAT traversal and traffic statistics. The RCEF has similar QoS management functions to the BGF except for not having the NAT traversal function. The Layer 2 Termination Function (L2TF) is the control point for L2 communication between the user and terminating equipment.

    The TISPAN has released RACS R1, while R2 is in the developing process. The following interfaces already have been standardized: Gq’ between the AF and SPDF[5], Rq between the SPDF and A-RACF[6], and e4 between the NASS and A-RACF[7]. Moreover, these three interfaces adopt  and expand the Diameter protocol. In addition to them, the interface Ia between the SPDF and BGF adopts and expands H.248[8]. However, there are no standard for Re and Ra between the A-RACF and the access network by now. Besides, standards for transport QoS enforcement entities such as the RCEF and L2TP have not been made. As for the fixed access network, there are no complete QoS control solutions by now. TISPAN plans to cooperate with the DSL forum to finish the RACS control specifications for the DSL access network first, and then make those for the Ethernet, Passive Optical Networks (xPON), WLAN and Worldwide Interoperability for Microwave Access (WiMAX) access networks, and eventually build a unified QoS control architecture for the converged network.

5 Conclusions
The IMS-based QoS resource control architecture is an important solution to QoS issues in the converged network. Based on the architecture, some operation problems currently encountered by fixed operators can be solved.  For instance, it is possible for operators to develop various multimedia services with ensured QoS (such as 3D games). Therefore, it is beneficial for the operator to transform from a bandwidth service provider to a true communication service operator. Moreover, the solution helps operators provide diversified value-added communication services.

    This article has discussed the QoS control architecture for the converged network, QoS service modes and resource control. It has also introduced TISPAN’s efforts on standardization. The IMS-based QoS control architecture is urgently needed by the converged network, especially by the fixed network. However, the architecture and relevant standards require further research in the future.

References
[1] ITU-T Y.2111. Resource and admission control functions in next generation networks [S]. 2006.
[2] ETSI ES 282 003. Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN): Resource and Admission Control Subsystem (RACS):Functional architecture [S]. 2006.
[3] ETSI TR 180 001.Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN):NGN Release 1:Release definition[S].2006.
[4] Shen Min, Shi Xiaofeng, Li Mingdong. Research Status of Network Attachment Subsystem in NGN [J]. ZTE Communications, 2006,12(5):26-29.
[5] ETSI TS 183 017. Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN):Resource and Admission Control: DIAMETER protocol for session based policy setup information exchange between the Application Function (AF) and the Service Policy Decision Function (SPDF): Protocol specification [S]. 2006.
[6] ETSI ES 283 026. Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN): Resource and Admission Control: Protocol for QoS reservation information exchange between the Service Policy Decision Function (SPDF) and the Access-Resource and Admission Control Function (A-RACF) in the resource and protocol specification [S]. 2006.
[7] ETSI ES 283 034. Telecommunications and Internet converged Services and Protocols for Advanced Networks (TISPAN): Network Attachment Sub-System (NASS): e4 interface based on the DIAMETER protocol [S]. 2006.
[8] ETSI ES 283 018. Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN): Resource and Admission Control: H.248 profile for controlling Border Gateway Functions (BGF) in the Resource and Admission Control Subsystem (RACS): Protocol specification [S]. 2006.

Manuscript received: 2006-11-09

[Abstract] The convergence of telecom networks requires an improved Quality of Service (QoS) solution. The introduction of the QoS resource control architecture based on the IP Multimedia Subsystem (IMS) framework is a way to solve QoS problems in the converged networks. Services, QoS guarantee, resource control and accounting functions are integrated into this IMS-based QoS control architecture. It is a solution to the problems currently facing the fixed network operators, helping them offer more QoS-guaranteed multimedia services such as 3D games, and make a transition from bandwidth providers to genuine telecom services providers.