Open API for QoS control in Next Generation Networks · 2005-09-12 · UTS: INSTITUTE for INFORMATION & COMMUNICATION TECHNOLOGIES S. Lee, J. Leaney, T. O’Neill, M. Hunter, “Open

UTS: IICT where information and communication meet research

UTS:INSTITUTE for INFORMATION & COMMUNICATION TECHNOLOGIES

Open API for QoS control in Next Generation Networks

Samson LeeAsia-Pacific Network Operations and Management Symposium (APNOMS’05)

September 27-30, 2005, Okinawa JAPAN

AbstractOpening up telecommunications networks allows operators to develop and deploy new services that utilize the underlying capabilities of the network. Open Service Access and the Parlay APIs are gaining wide industry acceptance for basic service capabilities such as call control and user location. However, next generation services will require the use of additional advanced service capabilities such as Quality of Service, multicasting and VPN provisioning. This paper focuses on Open APIs for Quality of Service control, and analyzes the existing Parlay Connectivity Manager as an interface to the expected requirements based on recent drafts from ETSI TISPAN’s Resource Admission Control Subsystem. We describe the strengths and weaknesses of the existing API specifications and provide suggestions about changes that are needed to improve the specification. Furthermore, we describe our efforts to date in implementing a prototype of the specifications and experience in utilizing the prototype to develop an example QoS-aware application.

295


S. Lee, J. Leaney, T. O’Neill, M. Hunter, “Open API for QoS control in Next Generation Networks”, 27-30 September 2005, APNOMSS2005 Okinawa, JAPAN

Introduction

Background / SignificanceNew revenue by opening telecom networks. Recent development and standardisation of open APIs (e.g. JAIN, Parlay/OSA) is enabling new value-added applications utilising telecom capabilities that were previously closed to third parties.Need to extend existing open APIs to include new NGN service capabilities. Maturity of open APIs increasing in fixed and mobile telephony (e.g. call-control and user-location). What about emerging capabilities including QoS, resource / admission control, multicasting and VPNs.?

Research ObjectivesTo develop a practical and open API that enables value-added applications to access NGN service capabilities. Focus on open API for QoS control.ContributionsA working prototype, simulation environment and example applications to validate and demonstrate the proposed API.

ETSIETSI3GPP3GPP

ParlayParlay

Call ControlU

ser InteractionM

essaging Loca

tion

Cha

rgin

g

Pres

ence

/Ava

ilabi

lity

Terminal C

apabilities

Acco

untin

g

1. IntroductionRecently, there has been an enormous increase in efforts to “open up” telecommunications networks for application development [1]. In opening up the network, new business models emerge where applications can be developed and provided by enterprises outside the traditional network operator domain. This new business model, combined with the fact that applications can be built using standardized Application Programming Interfaces (APIs) with off-the-shelf IT technology and tools, will result in new applications reaching the market with drastically reduced development cycles.The Open Service Access (OSA) and Parlay API initiatives specify a set of open standardized APIs that allow applications access to network functionality by packaging and presenting the service capabilities in a manageable fashion. Originally defined within the Parlay Group [2] and standardized by the Third Generation Partnership Program (3GPP) [3] and European Telecommunications Standards Institute (ETSI) [4], the APIs provide a technology agnostic abstraction of functions including call control, location and user interaction among others. There are currently more than 208 announced products implementing the OSA/Parlay APIs [5], including 26 gateways and 76 value-added applications, with support from a growing number of over 65 member organizations who are vendors, service providers and independent software developers.Clearly, the OSA/Parlay APIs are gaining wide acceptance in industry. However, current uses in both fixed [6, 7] and mobile [8] networks are focused on telephony-type applications, particularly with call control capabilities. Next Generation Networks will have advanced service capabilities such as QoS with admission control, multicasting and VPN provisioning. Next generation applications such as video on demand and bandwidth on demand will require access to these advanced service capabilities.The focus of this paper is on an open API for application-controlled QoS, and specifically analyses the strengths and weaknesses of the existing OSA/Parlay Connectivity Manager Service Capability Feature (SCF), which has been “stable” in the specification for a while, but not as widely supported as other SCFs. In spite of this lack of implementation, there is general agreement [9] by the Parlay Joint Working Group (consisting of members from ETSI, 3GPP and Parlay) about the need to continue research on an API for application-controlled QoS.

296



Open Service Access (Parlay/OSA)PL

MN

PSTN

/ISD

N

Dat

a/IP

CA

TV

2. Open Service AccessOpen Service Access (OSA) is the term given to a set of open standardized Application Programming Interfaces (APIs) that enables telecommunications network operators to develop and deploy services more quickly by using modern software technologies such as Java and Web Services to create telecommunications applications. The OSA/Parlay APIs are jointly developed and published by the Parlay Group, ETSI and 3GPP, and form the API layer of the 3GPP IP Multimedia Subsystem (IMS).An API describes a packaged collection of prewritten procedures (or classes and methods) that programmers can incorporate into their own software [10]. It defines how programmers see the resources of a particular computing system (which may be a single machine or a collection of machines cooperating together). Open APIs have freely available specifications, as opposed to closed APIs with characteristics that are not made known publicly or made known only in part. Open APIs have a variety of implementations, as opposed to products available from only a single vendor. Open APIs have wide acceptance among users and infrastructure suppliers, precisely because specifications and implementations are so easy to obtain.The OSA/Parlay APIs consist of the Framework and a number of Service Capability Features (SCFs). The Framework provides the ability for the network operator to negotiate with the application provider. It provides the initial point of contact to the application to discover the services that are offered by the network that can be utilized by the application. It also considers all security precautions required. The SCFs consist of a large number of individual interfaces that are designed to allow the application provider access to the capabilities within the network, examples being Call Control, Mobility Management and Presence and Availability Management.As far as the ability to program new services goes, the API defines the capabilities and limitations of the network. If the network functionality is not available to programmers via the API, then generally only the vendors of the individual elements (switches, network databases, etc.) have access to that functionality and can create new services using those functions. Fortunately, the OSA/Parlay Framework allows additional SCFs to be registered. These additional SCFs may be standardized or non-standardized.To date, these SCFs have been focused on telephony services with basic functionality such as call-control and user-location. For a full list of the APIs, refer to the OSA/Parlay specifications. There is a need to extend existing open APIs to include additional advanced NGN service capabilities such as QoS control, described in the following sections.

297



QoS control in Next Generation Networks

OSA/ParlayConnectivity Manager• An existing API to set up

QoS paths in a network• QoS paths called Virtual

Provisioned Pipes (VPrP)• Template-based (e.g. gold,

silver, bronze)• Specification “stable” for a

number of years• Not widely adopted

TemplateList

QoSTemplate:

PipeQoSInfoProvisionedQoSInfoValidityInfoDsCodepoint

Parlay GatewayApplication

SAP A

SAP B

SAP C

SAP DVPrP

Parlay API

…getQoSMenu()getTemplateList()getTemplate()getPipeQoSInfo()setPipeQoSInfo()getProvisionedQoSInfo()setProvisionedQoSInfo()getValidityInfo()setValitifyInfo()createVPrP()…

SAPList

VPrPList

QoSTemplate:


QoSTemplate:


…getEnterpriseNetwork()getVPrN()getVPrPList()getVPrPID()getSlaID()getProvisionedQoSInfo()getValidityInfo()getPipeQoSInfo()getDsCodepoint()getStatus()…

…getEnterpriseNetwork()getSiteList()getSite()getSAPList()getSiteID()getSiteLocation()getSiteDescription()getSAPIPSubnet()getIPSubnet()…

3. QoS Control in Next Generation NetworksNext Generation Networks will have advanced service capabilities such as QoS, multicasting and VPN provisioning. These advanced service capabilities will need to be utilized by applications in order to provide innovative next generation multimedia services. In this paper, we focus on an open API for QoS control. As a starting point, we describe the existing OSA/Parlay Connectivity Manager in Section 3.1, and analyze it compared to requirements from the ETSI TISPAN NGN architecture described in Section 3.2.3.1 OSA/Parlay Connectivity ManagerConnectivity Manager [11] SCF includes the APIs between the enterprise operator and the provider network for the two parties to establish QoS parameters for enterprise network packets traveling through the provider network.The Connectivity Manager SCF provides tools for the enterprise operator to set up a Provisioned QoSservice in the provider network. The QoS measures used in the enterprise network are outside the scope of the service. The API does not require any specific QoS method to be used in the enterprise network, nor in the provider network. However, in order for Provisioned QoS service to be applied to packets arriving from the enterprise network into the provider network, the packets have to be marked using Diffserv Codepointmarking. Once the packets are so marked, they can utilize the QoS service provisioned in the provider network.APIs provide the enterprise network operator on-line access to provision QoS measures that control the enterprise’s own traffic passing through the provider network. Using APIs the operator can create virtual provisioned pipes (VPrPs) in the provider network to carry the enterprise traffic and support it with pre-specified quality of service attributes. A VPrP can be thought of as a Virtual Leased Line (VLL) provisioned to deliver pre-specified QoS. The provider may offer to the enterprise operator a set of templates that are used by the operator to specify a VPrP. For instance, the provider may offer templates for video conferencing, audio conferencing, Gold Service, Silver Service, etc. Using these templates the operator can select and provision a VPrP that specifies the quality of service attributes for this VPrP.Elements that can be specified for a VPrP include attributes such as packet delay and packet loss. Characteristics of traffic that enters the VPrP at its access point to the provider network can be also specified with attributes such as maximum rate and burst rate.The Connectivity Manager has been classified as “stable” for a number of years. However, it is still not being widely adopted and is unsuitable as an application interface for ETSI TISPAN RACS, described next. The Connectivity Manager, only partly satisfies the requirements, but it is still useful to study because it incorporates all the benefits of the OSA/Parlay Framework.

298




ETSI TISPAN RACS(Resource Admission Control Subsystem)• Policy Control• Resource reservation• Admission Control• Network Address Translation• Firewall Traversal

AFs

CPE ATMaggregation

EdgeRouter Ethernet

Aggregation

CPE

RACF

Access Segment AggregationSegment

Access Nodes

EdgeRouter

Gq *

AFs

CPE ATM

aggregation

EdgeRouter Ethernet

Aggregation

CPE

RACS


Access Nodes

EdgeRouter

AAANASS

AFs

CPE ATMaggregation

EdgeRouter Ethernet

Aggregation

CPE

RACF


Access Nodes

EdgeRouter

Gq *

AFs

CPE ATM

aggregation

EdgeRouter Ethernet

Aggregation

CPE

RACS


Access Nodes

EdgeRouter

AAANASS

RACS high-level architecture

3.2 ETSI TISPAN RACSTISPAN (Telecoms & Internet Converged Services & Protocols for Advanced Networks) is the ETSI core competence centre for fixed networks and for migration from switched circuit networks to packet-based networks with an architecture that can serve in both [4]. TISPAN is responsible for all aspects of standardization for present and future converged networks including the NGN (Next Generation Network) and including, service aspects, architectural aspects, protocol aspects, QoS studies, security related studies, mobility aspects within fixed networks, using existing and emerging technologiesIn an effort to standardize NGNs, ETSI TISPAN has proposed the Resource Admission Control Subsystem (RACS). RACS is the NGN subsystem responsible for elements of policy control, resource reservation and admission control. RACS also includes support for Network Address Translator (NAT) and Firewall (FW) traversal.The requirements of RACS are still under development, but recent drafts describe the following points. These requirements are expected to evolve as work is progressed, but they should still provide an early indication of what to expect. The following points also includes comments about the strengths and weaknesses of the existing OSA/Parlay Connectivity Manager SCF.

(Text for next slide)Requirement 3.2.1 – RACS controls resources in access networks supported by TISPAN in accordance with access network capabilities. As one example, for xDSL access, this includes the last-mile and the aggregation network. RACS sets the bearer/transport function with network-level attributes that match to the service (Bandwidth, QoS, etc).QoS service capabilities available at the access and edge of the network include Differentiated Service and MPLS-based Traffic Engineering at the edge. Since these are technology-specific examples that may require specific knowledge of the network, the network functions need to be abstracted for the open API to be used at an application level.Requirement 3.2.2 – RACS shall provide a mechanism to Application Functions (AFs) to reserve resources in the access network. RACS reserves resources on behalf of AFs.Applications could access the RACS mechanism via an open API such as OSA/Parlay. The open API would be logically located at a layer above the Gq interface.Requirement 3.2.3 – RACS shall offer services to Application Functions (AFs) that may reside in different administrative domains.There needs to be a framework for AFs to be authenticated, authorized and accounted (AAA) for. This concept of allowing third party Application Service Providers access to RACS services through an open API is the intention of OSA/Parlay Framework.Requirement 3.2.4 – As the interface between AF and RACS can be inter-operator, the RACS shall be able to authenticate and authorize the AF.This could also be achieved through the Parlay Framework, which provides the AAA capability for AFs.(Text continued in next slide)…

299




ETSI TISPAN RACS Requirements Connectivity Mgr1. Controls resources of access network capabilities PASS2. Application Function (AF) reservations PASS3. AF in multiple administrative domains PASS4. Authentication and authorisation of AF PASS5. Traffic directionality, symmetry, multicasting LIMITED6. AF notification of resource change FAIL7. AF modification of existing reservations FAIL8. Admission feedback for AF LIMITED9. Export charging information PASS10. Push and Pull control mechanism PASS11. Session aware PASS12. Dependency on network for policy enforcement PASS13. Priorities for multiple/conflicting requests PASS

No multicasting

Synchronous Feedback Only

… (Text continued from previous slide)Requirement 3.2.5 – RACS shall support QoS requests for uni- and bi-directional, symmetric and asymmetric, unicastand multicast, up- and downstream trafficExisting OSA/Parlay Connectivity Manager does not support QoS requests for multicast traffic. This needs to be included in the requirements specification of the open API.Requirement 3.2.6 – RACS shall notify AF in case of the resource previously allocated is forced relinquished. This may be triggered by an administrative decision or a faulty condition.Existing OSA/Parlay Connectivity Manager does not support notification of resource changes. Notification would be assisted by OSA/Parlay Framework. Notification can be synchronous or asynchronous. There is a need to formalize how this feedback mechanism is specified.Requirement 3.2.7 – RACS shall support requests from Application Functions to modify the parameters of their existing reserved resource. This case may result in a new admission control step and/or installing new policiesExisting OSA/Parlay Connectivity Manager does not support modification of VPrPs. This needs to be included in the open API requirements. Accordingly, applications could dynamically react to QoS notifications, or modify existing QoSparameters.Requirement 3.2.8 – RACS shall provide feedback messages to the AF either approving or rejecting the QoS reservation, commit or modify requests.Existing OSA/Parlay Connectivity Manager provides synchronous feedback messages, i.e. results are returned immediately. If the result is “pending”, then the application will need to poll in order to obtain an updated status. Instead of this, a request/response mechanism or asynchronous operation is recommended.Requirement 3.2.9 – RACS shall be able to export charging information and session metricsCharging could be done through OSA/Parlay Charging SCF. Modifications to the existing Charging SCF may be required.Requirement 3.2.10 – RACS shall support Push and Pull mechanisms for service based and network policy control depending on the type of access network.Application Server controlled or user controlled QoS. This means that QoS Requests, Notifications and Modifications could be done by either the Application Server or directly by the end-user.Requirement 3.2.11 – RACS is aware of session in terms of bearer flows and its defined media components.This means the RACS is able to interact with the Call Session Control Function (CSCF). Perhaps this could be done at the application level by using the Call Control SCF in conjunction with the proposed open API for QoS control.Requirement 3.2.12 – TISPAN access network is responsible for policy enforcement. The RACS assumes that police enforcement shall assure that the associated user traffic remains in accordance with the policy decision.Enforcement is done by the network. So there is a dependency on the QoS functions working properly in the underlying network. We are publishing our work on Policy Based Network Management in separate papers, including [12].Requirement 3.2.13 – The AF shall be able to signal priorities for QoS requests to the RACS. RACS must be able to react on such prioritization request from an AF by modifying allocated resources.If there are multiple requests from an AF, then each request can be assigned a priority. In the case of multiple requests, the RACS subsequently reacts to the request with highest priority. In the case of single requests, the RACS doesn't need the AF specified priority.

300



An Improved open-API for QoS control

Problems with OSA/Parlay Connectivity Manager1. No support for modification of existing VPrP2. No support for notification of network changes3. No support for multicasting4. No support for asynchronous feedbackAdmission control scheme is unsatisfactory!

Our improved open-API for QoS control1. Added modifyVPrP() methods for modification of existing VPrP2. Added callback interfaces (IpAppXXX) for notification of network changes3. Added multicast element in TpPipeQoSInfo4. callback interfaces allow asynchronous feedback

4. An improved open-API for QoS controlThe previous section described some of the expected requirements for QoS control as well as how the existing OSA/Parlay Connectivity Manager is inadequate to satisfy the requirements. Following are some suggestions for changes to the specifications, and what we have done to facilitate the research and development of such an improved open-API for QoS control.4.1 Suggestions for OSA/Parlay Connectivity ManagerConnectivity Manager is unable to meet RACS requirements because:1. It is unclear how to modify an existing VPrP since there are no set/modifyVPrP methods in IpVPrP(Req#7).2. There is no support for notification of network changes to application (Req#6). Instead, application can only poll the server for network changes. There are no callback interfaces (IpAppXX) for notification -notification requires callback interface.3. There is no support for multicasting (Req#5).4. When createVPrP() is called, it returns a reference to the new virtual provisioned pipe interface, which may or may not include yet the decision of the provider to the request. If the decision is made immediately, then there is in effect admission control feedback messages. If the decision is not made immediately, then there is no admission control feedback messages - the application is not notified when the decision is made. Therefore, the current admission control scheme is unsatisfactory (Req#8).Additionally:5. There are only synchronous methods defined, which means immediate results are always expected. There is a possibility that QoS templates are stored externally to the server, and there may be a delay in retrieving the templates. It is recommended in the OSA/Parlay specifications that synchronous methods are only used when a method does not require the server to contact other nodes in the network.

301




Prototype Scenario• OSA/Parlay Gateway

– Implements simplified Framework interfaces

– Implements prototype open API for QoS control (based on Parlay/OSA Connectivity Manager)

• Next Generation Network– Alcatel 7750 Service Router (SR)– Featuring advanced QoS, VPN and

multicasting service capabilities– L2/L3 VPNs, MPLS, VPLS

• Application Server– Running example application

4.2 Prototype Scenario4.2.1 High Level ArchitectureWe demonstrate the practicality of our open API for QoS by implementing a prototype scenario consisting of an OSA/Parlay Gateway, simulated Next Generation Network and an example QoS-aware multimedia application.The OSA/Parlay Gateway holds the implementation of our improved QoS API, as well as a simplified version of the Framework interfaces. The simplified Framework is the initial contact for the example application. The Parlay specifications do not mandate the use of any specific client/server technology such as CORBA or Java Remote Method Invocation (RMI). Interface descriptions are provided in IDL, Java and WSDL (deprecated). We chose to use RMI because of its simplicity, and because we will not be requiring non-Java applications for our prototype scenario.For the purposes of the prototype, we assume that the Next Generation Network has the required service capabilities for QoS and multicasting. Our network will be based on the capabilities provided by Alcatel’s state-of-the-art 7750 Service Router (SR) [13]. The figure also depicts OSS Applications and Service Manager elements, which are external to the prototype. They are included in the figure to show the logical location of the Parlay gateway compared to the existing management tools.The Application Server runs our example application, which will be described later.

302



An Improved open-API for QoS controlClass Diagram of prototype open-API for QoS control

Callback interfaces for asynchronous admission feedback and notification of resource changes

Supports modificationof existing reservations

+admissionFeedback()

«Interface»<<new>> IpAppVPrN

+reportNotification()

«Interface»<<new>> IpAppVPrP

1 *

+getQoSMenu()+getEnterpriseNetwork()

«Interface»IpQoSManager

+getTemplate()+getTemplateList()

«Interface»IpQoSMenu

+getTemplateType()+getDescription()+setSlaID()+getPipeQoSInfo()+setPipeQoSInfo()+getValidityInfo()+setValidityInfo()+setProvisionedQoSInfo()+getProvisionedQoSInfo()+getDsCodepoint()

«Interface»IpQoSTemplate

+getSiteList()+getVPrN()+getSite()

«Interface»IpEnterpriseNetwork

+getVPrPList()+getVPrP()+createVPrP()+deleteVPrP()+<<new>> modifyVPrP()

«Interface»IpVPrN

+getVPrPID()+getSlaID()+getStatus()+getProvisionedQoSInfo()+getValidityInfo()+getPipeQoSInfo()+getDsCodepoint()

«Interface»IpVPrP

+getSAPList()+getSiteID()+getSiteLocation()+getSiteDescrption()+getIPSubnet()+getSAPIPSubnet()

«Interface»IpEnterpriseNetworkSite

1

1

1

*

1

*

1 *

1

1

1

1

4.2.2 Class Diagram of Prototype improved open-API for QoS controlThe top level IpQoSManager interface provides operations to get IpQoSMenu and IpEnterpriseNetworkmenu interfaces.The enterprise operator uses the IpQoSMenu interface to browse and configure pre-defined templates that describe the QoS parameters. The parameters in each template consists of the following datatypes: TpPipeQoSInfo, which defines the pipe’s directionality, service multicasting, service origin, service destination, forward load and reverse load; TpProvisionedQoSInfo, which defines the delay, loss, jitter and excess load action; and TpValidityInfo, which defines the time, duration, days of week, and months for which the template is valid. The templates are negotiated in an off-line process, and values can be specified by either the network provider or enterprise operator.The enterprise operator uses the IpEnterpriseNetwork menu interface to browse the list of its sites and SAPs(maintained by the network provider), and to manage its VPrN. Operations are provided to list, get details of, delete and modify current VPrPs, as well as to request the creation of new VPrPs. The status of VPrPs can be active, pending or disallowed. Details of each active VPrP contains the currently provided QoSparameters, which may be different to requested. Details of each pending or disallowed VPrP contains the requested QoS parameters. QoS parameters are defined by the datatypes described previously.If the enterprise operator chooses to use asynchronous feedback for admission control, an instance of IpAppVPrN is created on the application side. A reference to this application callback interface is passed to the network provider’s IpVPrN interface. When createVPrP() or modifyVPrP() is called by the application, the application expects to receive feedback through its callback interface. When the admission control feedback is required (e.g. a previously rejected request was successfully admitted after a retry), admissionFeedback() is called by the Parlay gateway. The callback interface then forwards the event to the application logic.Similarly, if the enterprise operator chooses to use asynchronous feedback for notification of resource changes, an instance of IpAppVPrP is created on the application side for each VPrP. A reference to this application callback interface is passed to the network provider’s corresponding VPrP interface. When the Parlay gateway needs to notify the application about a resource change (e.g. resource previously allocated is force relinquished), reportNotification() is called. The callback interface then forwards the event to the application logic.

303




Network element capabilities• Simulated Service Routers

– A very simplified simulation model– Inputs: String(s) representing

configuration parameters– Outputs: String(s) representing

dummy network status• QoS pipes

– MPLS label switched paths– Epipe Service

• Multicasting– Virtual Private LAN Service

• Requires get / set parameters defined in:

– ProvisionedQoSInfo• delayDescriptor, lossDescriptor• jitterDescriptor, excessLoadAction

– PipeQoSInfo• directionality, serviceMulticast• serviceOrigin, serviceDestination• forwardLoad, reverseLoad

– ValidityInfo• validFrom, validPeriod• validDailyFrom, validDailyPeriod• validDayOfWeek, validMonth

4.2.3 Network element capabilitiesAlcatel 7750SR is the state-of-the-art in service router technology, featuring advanced QoS and VPN capabilities. Although the 7750SR has many other features, we are concentrating on the QoS control aspect in this paper.7750 SR routers use QoS policies to control how QoS is handled at distinct points in the service delivery model within the device. There are different types of QoS policies that cater to the different QoS needs at each point in the service delivery model. QoS policies define classification rules for how traffic is mapped to queues; the forwarding class queues, queue parameters used for policing, shaping, and buffer allocation; and QoS marking/interpretation.If the service core network is oversubscribed, a mechanism to traffic-engineer a path through the core network and reserve bandwidth must be used to apply strict control over the delay and bandwidth requirements of high-priority traffic. In the 7750 SR, Resource Reservation Protocol with Traffic Engineering (RSVP-TE) can be used to create a path defined by a Multi Protocol Label Switching (MPLS) Label Switched Path (LSP) through the core. Premium services are then mapped to the LSP with care exercised not to oversubscribe the reserved bandwidth. If the core network has sufficient bandwidth, it is possible to effectively support the delay and jitter characteristics of high-priority traffic without utilizing traffic engineered paths, as long as the core treats high-priority traffic with the proper Per Hop Behavior (PHB).It must be noted that the 7750SR in conjunction with 5620 Service Aware Manager already opens the management modules for an OSS application via an XML interface. This OSS interface allows provisioning of services and policies, integration into existing multi-vendor OSS systems, fault management, equipment and inventory management. However, this “open” interface is only useful for the operator who wishes to integrate the management functions of the 7750 SR into an OSS. It does not open up the network functions to third party service providers who could use these new functions in creating innovative new applications.The value of our contribution is that by utilizing standardized OSA/Parlay open APIs, it is possible to open up the advanced 7750SR functions such as VPNs and QoS policies to an increasing number of applications, while keeping third party access manageable. A major benefit is that the new open API leverages the existing strengths of the OSA/Parlay Framework for ensuring secure, measurable and billable access to the advanced service capabilities.We used simulated Alcatel 7750SR devices, which meant that the actual configuration of network QoSpolicies is not functioning yet, but are simulated with text output messages indicating the parameters that would be sent to the network element.We are not testing the performance of the 7750SR’s switching capabilities. The performance of the 7750SR has already been documented in independent third-party reports from [14].

304



Example QoS-aware application• Application-controlled QoS using Open

Service Access• Live streaming video• On-demand streaming video• On-demand match statistics and player

information• Towards a fully converged network – services

integrated with PSTN, 3G mobiles, Internet, (SMS, MMS), etc.

• Web-based application developed on Java platform utilising the open API prototype.

• Service provider now has access to an exciting new network function

• Operator is able to effectively provide open access as well as manage the usage of this new network function


4.3 Example QoS-aware applicationThe purpose of providing an example QoS-aware application is to demonstrate that service providers couldeasily and practically use this open API as a part of their applications in order to make the most out of the functionality of next generation networks. These service capabilities that were previously inaccessible have been packaged and presented in a fashion that is open, practical, and manageable along with the benefits of the OSA/Parlay Framework.The application scenario is an advanced entertainment portal / enhanced interactive broadband digital television with instant video on demand. It is a fully converged video system with additional features such as electronic program guide reminders via phone and text messaging. The open API is essentially used to provide feedback to the application so that the application may respond as it wishes. The application not only uses the proposed QoS API, but also takes advantage of the existing call control and user location APIs.After the service is authenticated and registered with the Framework, the application is able to discover and request access to the prototype API. In our example QoS-aware application, QoS and bandwidth parameters can be requested and modified on demand by the application in a very practical way. Additionally, the application is able to react to feedback provided by the API. The application is shielded from the complexity of the underlying protocols and is able to utilize the benefits of QoS through an easy to use API.At the same time, the application could also access other functions such as Call Control and Messaging. By including this SCF, the service provider is able to provide a value-added service that takes advantage of convergence between different networks. The user could be provided with a service that operates transparently between IP, PSTN and mobile technologies. For example, if the application is unable to establish a QoS tunnel at the time due to insufficient resources. It could send the user an SMS when resources become free, or make a call to the user through VoIP / mobile or fixed line.

305



Summary and Future Work

• Open Service Access enables new applications• Analysis of OSA/Parlay Connectivity Manager

– Does not satisfy ETSI TISPAN RACS requirements• We proposed an improved open API for QoS control

– Application Function modification of existing reservations– Asynchronous messaging

• Application Function notified on unexpected network resource change• Application Function notified when admission control requires feedback

– Multicasting• Prototype implementation and example application to demonstrate

practicality

• Currently working on Parlay X Web Services QoS Control API

6. Summary and Future WorkWe described Open Service Access for controlling QoS in Next Generation Networks. We analyzed the ETSI TISPAN RACS as an expected list of requirements and the suitability of an existing OSA/Parlay Connectivity Manager API for providing QoS control. Suggestions to the specification were made based on this analysis, and our prototype was described along with an example application to demonstrate the practicality and openness of the system. Future work will be to enhance the prototype API and gain more experience in the practicality of developing real applications with the API. More efficient methods for mapping the high level API functions to low level device commands, such as with policy-based network management needs to be examined. We are currently working on Parlay X Web Services QoS control API.

References[1] A.-J. Moerdijk and L. Klostermann, "Opening the Networks with Parlay/OSA: Standards and Aspects Behind the APIs," IEEE Network, pp. 58-64, 2003.[2] The Parlay Group, "Parlay APIs 4.0 and Parlay X Web Services," Whitepaper 2002.[3] 3GPP, "TSG Core Network and Terminals WG5," http://www.3gpp.org/TB/CT/CT5/CT5.htm 2005.[4] ETSI TISPAN, "Webpage," http://portal.etsi.org/tispan/ 2004.[5] Z. Lozinski, "Parlay Product Catalog," 28 May 2004.[6] K. Turner, E. H. Magill, and D. J. Marples, Communications Services: The Technology of Call Control: Wiley, John & Sons, Incorporated, January 2002.[7] R. Jain, F. Anjum, and J.-L. Bakker, Programming Converged Networks: Call Control in JTAPI, JAIN, and Parlay/OSA: Wiley, John & Sons, Incorporated, November 2003.[8] P. Golding, Next Generation Wireless Applications: Wiley, John & Sons, Incorporated, May 2004.[9] Joint Working Group, "Barcelona Meeting Report," http://www.3gpp.org/ftp/tsg_cn/WG5_osa/TSGN5_29_Barcelona/Docs/N5-040708%20DRAFT%20A%20Report_CN5_29_Barcelona.zip 2004.[10] S. M. Mueller, APIs and Protocols for Convergent Network Services. NY: McGraw-Hill, 2002.[11] The Parlay Group, "ETSI ES 202 915-10 OSA API Part 10: Connectivity Manager SCF," 2004.[12] N. Sheridan-Smith, J. Leaney, T. O'Neill, and M. Hunter, "A Policy-Driven Autonomous System for Evolutive and Adaptive Management of Complex Services and Networks," presented at 12th Annual IEEE International Conference and Workshop on the Engineering of Computer Based Systems (ECBS), Greenbelt, Maryland, USA, 2005.[13] Alcatel, "Alcatel 7750SR Service Router Product Literature," http://www.alcatel.com/products/productsummary.jhtml?repositoryID=/x/opgproduct/a7750sr.jhtml 2005.[14] P. Shippam and P. Ridgewell, "Next-Generation Routers: A Comprehensive Product Analysis," Heavy Reading 2004.

306

Documents

Open API for QoS control in Next Generation Networks · 2005-09-12 · UTS: INSTITUTE for INFORMATION & COMMUNICATION TECHNOLOGIES S. Lee, J. Leaney, T. O’Neill, M. Hunter, “Open