Control and Management of Home Networks Using a CORBA Enabled Residential Gateway

Transcription

1 Control and Management of Home Networks Using a CORBA Enabled Residential Y.C. Shou 1, R. Prasad, S. Mohapi and H.E. Hanrahan Centre for Telecommunications Access and Services School of Electrical and Information Engineering University of the Witwatersrand, Johannesburg {y.shou, r.prasad, s.mohapi, h.hanrahan}@ee.wits.ac.za Abstract This paper focuses on the problem of how to provide home network users a way to access the TINA services using a CORBA-enabled Residential. It proposes a standardised service architecture for the Next Generation Network. Additionally intelligent control and management schemes at the RGW are addressed. Issues such as billing, bandwidth allocation and error correction are highlighted in this paper. Keywords: Home Network, Residential, Multimedia, Management, Billing, NGN, TINA, DPE, VoIP. I. INTRODUCTION Today, the number of people that own multiple computers in the home is increasing. Also access to high bandwidth, broadband connections is becoming common to home users. Connections not only carry data, but also telephony, video and audio. For home users, a home network structure is emerging, as supporting hardware and software is being developed. In the last decade, the Internet and its services have emerged and have demonstrated that there is a mass market for information and multimedia services. IP technology and the Internet telephony are now in a major convergence with Telecommunications. The substitution of circuit switching with packet switching is rapidly increasing [1]. Hence there is a high expectation for the Next Generation Network (NGN), which is a single, multi-service, data-centric network that manages and controls services at different qualities and costs on an open control and service platform. Each service provider in the NGN architecture is likely to use a different access technology with different interfaces. To successfully offer the advanced services to residences, a given service provider needs to have a wise strategy for effectively connecting to the home terminals. A device that can provide efficient interfacing of network interface with multiple home network devices is needed. This concept has lead to the creation of the residential gateway (RGW). A RGW is a device that provides middleware interworking between an access network and a separate home network with protocol and format conversion [2]. It also allows different streams of information to be routed intelligently throughout the home. Hence the RGW is significant in provision of NGN services to the Customer Premises Environment (CPE). It is envisaged that the future NGN will be built on a Distributed Processing Environment (DPE) based network, to reduce the amount of centralised processing. The RGW thus needs to have certain intelligence to collaborate with the DPE-based network architecture. This paper presents work in progress on research into control and management of NGN service provision to the home network with CORBA-enabled RGW. Control and management are examined from two points of view: firstly, network side users and second, from the customer premises point of view. The focus hence falls on the control-intensive types of services such as enhanced Voice over IP (VoIP) or conferencing services. The proposed network aims to illustrate its ability to gain access to the TINA services using the conferencing service developed to date. Section II focuses on the issues that have been addressed for service provision via the RGW and the evolution of RGW control. Section III explains the complex management issues associate with conferencing services. Section IV outlines access, business and accounting model of the TINA architecture. Section V describes the proposed network structure that implements the advanced services from TINA. II. RESIDENTIAL GATEWAY (RGW) Arango and Huitema [3] proposed the Call Agent / Media (MGW) architecture based on the idea 1 This work is supported by Telkom SA Limited, Siemens Telecommunications and the THRIP Program of the Department of Trade and Industry.

2 of physically separating call control from media and bearer control. It makes sense in many applications to decompose the gateway into a central control portion and peripherals on which the media terminates. Hence the MGWs can be located between analogue / switched circuit and packet network, from the very edge of the network to the core. For example MGWs are located between packet and legacy networks, CPE and access networks and the access and core networks as shown in Figure 1. With this new architecture, the RGW was then designed. A. Architectural Network Structure The RGW is the interface between the Customer Premises Environment (CPE) and the Access Network. An overall view of the NGN network structure is also illustrated in Figure1. The CPE cloud represents multiple media terminals in the network hidden behind the RGW. With the RGW, multiple terminals can gain access via a single medium. The RGW uses access control in both directions across the CPE boundary. The RGW also performs several media functions such as converting the legacy phone to VoIP. Equipment inside the CPE cloud is managed by the RGW. The management functions facing the network side and facing the customer side may be in different jurisdictions. For example, the QoS of the CPE is managed by the RGW when the QoS of access network or core network is managed by Telcos. The RGW is essential from a service control and management point of view. B. Customers Premises issues Several control and management issues for the RGW are important from the customer premises viewpoint. 1) Fault Detection and Correction The detection and correction of logical faults occurring in the home network is also a major task of the RGW. The RGW has to detect problems on any of its logical connections and provide a troubleshooting model. A systematic approach works best for troubleshooting. This approach could be as follows: define the specific symptoms, identify all potential problems that could be causing the symptoms, then systematically eliminate each potential problem (from the most likely to the least likely) until the symptoms are no longer present. 2) Billing Accounting A distributed billing system is believed to be a solution for the NGN service billing crises. The cost of the central billing system is enormous compared to that of the distributed billing system. Hence the RGW needs to perform part of the billing process to cut down the workload on the central server. 3) Personal Profiles access management Personal details of the subscribers such as service subscription, billing records and type of broadband connection are required to initiate and set up a service session. The access management information can be downloaded to the RGW as required. The subscribers can also request for their personal billing records or service history. 4) Quality of Service The RGW must be able to secure the QoS level of the media or data stream. It is crucial for most of the realtime multimedia applications such as video conferencing, IP phone, VoD. The RGW should have an intelligent interface for the customer or the service provider to specify the QoS requirements for the specific services. 5) Dynamic Bandwidth Allocation The issues of bandwidth allocation arise due to the competition for available bandwidth between various functional terminals in CPE. The problem of having both internal and inter-communication on the same network has to be resolved. The RGW will need to assign the available bandwidth in an intelligent way such as giving each type of service or communication a priority level and allocate the available bandwidth accordingly. GW Controller GW Controller GW Controller PSTN Telephone CPE Residential Access Network Access Core Netwrok Media GW Internet Modem Fax Service Provider Figure1 Architectural view of NGN network

3 6) Security The security issues can be separated into two different parts. First of all, the RGW must be able to provide a secured connection for the services, implementing endto-end encryption. Secondly, the RGW system must have a protection scheme against hackers or even the users from changing the billing records or other confidential information. C. Residential Control Four stages of approach to provide control over the RGW are proposed in figure 2. Each of the stage is described briefly in the following section. The initial stage of the development represents the call agent control scheme. The CA is simply an intelligent device that controls and manages the residential / media gateways. The communication between the CA and the gateways is built on the master-slave approach as exemplified by Megaco / H.248. The master / slave approach allows the network gateway functions to be distributed or decomposed into intelligent CA and RGW parts. Application intelligence, such as call control is contained in the functional control server (CA). The RGW handles the connection setup, packets routing within the CPE and media conversion. It also implements peer-to-peer protocols to interact with other functional elements (e.g. other CAs, Gatekeepers, Trunking s) in the system and manage all feature interactions. Stage two of the RGW scenario is related to the development of the Softswitches. A Softswitch is a complex software that is able to provide several management functionalities over gateways. Softswitches can access the application services via a standard Application Programming Interface (API). APIs should present the control operations in more programmer-friendly ways. The Softswitch also provides another API, to interface with numerous controlling protocols for IP networks. This API has the ability to translate the signalling messages into different protocols that it supports. For example, it can convert the IAM message from ISUP protocol to the INVITE message in SIP. Ongoing development projects for Softswitch incorporate JAIN and Parlay system where JAIN plans to have ten different network protocol adapters. Parlay defines its API in Interface Definition Language (IDL) that allows the DPE environment between the Softswitch and the application services. Hence the services can be developed in a dynamic way. The third stage (3A) is the main focus of this paper. The RGW has the DPE wrapped around the Controller. The gateway controller talks to both application services and the media gateways through DPE. Also, the adapters are sited at the resource element. Thus there is no need for any protocol interpretation on the controller side. Instead, the gateway controller contains intelligence to carry out several management functionalities, essentially operating as a Network Management Node (NMN) in the DPE-based NGN architecture. The final stage (3B) of this development process represents the ideal case for the NGN where all resource elements are DPE-enabled. Media gateways will communicate with one another through APIs. This architecture allows for specialisations of function and economies of scale and is expected to become the architecture of choice in next generation converged voice/data IP networks. III. CONFERENCING SERVICES Video conferencing is to be implemented as a use case as it offers numerous management and control issues that need to be addressed. Conferencing has complex session initiations due to the multiparty aspects and the setup of links to the various parties. From a media Application Server Call Agent Residential GW Megaco/MGCP Application Server API DPE Softswitch API MGCP SIP INAP Q 931 Residential GW Network Management Node Application Server Adapter MGCP,SIP... RGW DPE DPE Intelligent Controller RGW API Stage 1 Stage 2 Stage 3A Stage 3B Figure 2 Residential Control Development Stages

4 streaming viewpoint the video and audio streams need to be synchronised and treated as a single thread so as to present coherent data to the users. Multicasting aspects must be addressed to allow for efficient use of channel bandwidth and prevent multiple streams from being broadcast from the same RGW to multiple parties. The administrative control features also have to be tackled. The features include the power to reject a incoming request, to terminate a conferencing session and to handover the administrative control. Apart from the functionality mentioned above, additional management functionality such as meet me conference, end meeting, cost allocation and billing aspects, needs to be developed. Due to conferencing service s complexity in control and management issues, it was chosen to test the designed network. A. Voice Over IP (VoIP) Voice over IP is the major segment of the conferencing services. This section discusses the concepts for VoIP technology, also the methodology to setup a VoIP call over the legacy PSTN network. VoIP uses the Internet Protocol (IP) to transmit voice as packets over an IP network. So VoIP can be achieved on any data network that uses IP, like the Internet, intranet and Local Area Networks (LANs). A Network structure that supports of the VoIP calls to a PSTN subscriber is shown in figure 1. The RGW provides the customer with a medium to the IP network for the IP calls. The CA handle the call control functionalities and route the packets to the media gateway. The MGW provides an interface between trunks on the Public Switched Telephone Network (PSTN) and a VoIP network. A trunk can be a DS0, T1, or E1 line. Multiple sophisticated telephone services can be realised through provision over NGN network. This is a consequence of the fact that development and deployment of new services is far easier on IP than on a PSTN network. VoIP thus provides a competitive threat to providers of traditional telephone services that will clearly stimulate improvements in cost and function throughout the industry. IV. TINA SERVICE ARCHITECTURE Currently, there is no emphasis on the control and management issues for the NGN services. This is where the Telecommunications Information Networking Architecture (TINA) can assist in providing a management model for the NGN service provision. TINA service architecture defines a management framework that supports different stakeholders assuming their different business roles, i.e. consumer, retailer, service provider, broker and connectivity provider. With this service management model, it is much easier to manage and control the services The TINA service architecture consists of a set of concepts, principles, rules and guidelines for constructing, deploying, and operating TINA services. The behaviour of the elements in a TINA environment is modelled by components that operate in a Distributed Processing Environment (DPE) and interact via interfaces [4]. The overall objective of the TINA service architecture is to support the most general case of business administrative domains, interacting with one another over a DPE, to offer business objects or applications for commercial gain. Hence the service architecture is explained in the following sections. A. Access Session TINA services are accessed based on the concept of an access session. The function of an access session is to create a temporary relationship among a group of objects that are assigned to collectively fulfil a task for a period of time. As such, the session represents an abstract, simplified view of the management and usage of the computational objects and their shared information [5]. Consumer Domain Access Usage Access Session Retailer Domain Service Session Communication Session Access Session Figure 3. TINA Service Architecture Consumer /3rd Party Domain A session has various purposes, such as access and authentication, provision of a service. Figure 3 shows a fundamental concept within TINA: the separation of access and usage and the separation of communication sessions. The clear separation between access and usage provided by the service architecture allows very flexible support of service composition [6]. Hence the TINA session model allows complex service interactions in application such as conferencing. In this project, the service provision will concentrate on the conferencing services between two end users. The service consumers will need only to initiate an access session to TINA from each end of network. The TINA

5 service retailer domain will then handle the authentication of the services and transportation of the media stream. B. Business Model There are five different business roles defined in the TINA service model to deal with the general commercial service provision circumstances. The five business roles are namely the consumer, the retailer, the third party provider, the broker and the connectivity provider. The consumers are the customers that use TINA services. The retailer introduces focus on customer and service management including service subscription, customers profile and accounting status information management [7]. The connectivity provider delivers the requested services within an acceptable QoS level specified by the user. The third party service provider supports the retailers or other service providers with services. The broker provides different kinds of information to different business roles for different purposes. For example, the consumer can interact with the broker to get references to available retailers. The advantages of having a clearly defined business model is that the software components required for each business role can be developed separately. The processing is then distributed over the DPE. The business model aims to give an additional structure, which eases the application of TINA in a multistakeholder, multi-vendor environment. The means of implementation of services via the RGW, as required in the project, is thus clearly defined by the TINA Business Model. C. Accounting Domain The dynamic, flexible and distributed nature of TINA services poses a great challenge to traditional accounting concepts and to their resource level mechanisms. TINA aims to present a more flexible, reliable and distributed accounting system with with additional features and functionalities, which have not been possible with the traditional accounting architecture. In the layered TINA service architecture, the accounting management components in each level constitute an accounting management domain. Three major computational objects (CO) are recognized in this accounting structure. First of all, an object to be metered is represented as an Accountable Object (AO). In this accounting architecture, the metering cycle is treated in a more object-oriented manner, where metering is handled by each individual accountable object rather than by a separate metering cycle. As a result, metering is considered distributed activities of accountable objects, and it does not appear as a separate accounting cycle. Secondly, each defined accounting domain consists of one Metering Manager. The Metering Manager receives and logs the accounting events reported by the Accountable Object. Lastly, Accounting Policy Manager exists in each accounting domain to maintain the accounting policies for the services provided. The TINA accounting model will be implemented on the RGW. With a CORBA enabled RGW, it is possible to create an AO for each service application. Then each service usage can be metered and billed separately. V. DESIGN NETWORK IMPLEMENTATION This work in progress paper focuses on developing a network architecture that provides the end users the accessibility to NGN services. Various service control and management functions can be carried out using a advanced intelligent RGW. This section explains the proposed solution that can be implemented in a real world situation. A. Physical Network Implementation The following network design is proposed to meet all the above tasks in the laboratory. The network outlined in figure 4 is the network structure implemented for this project. It can demonstrate the situation where two or more end-users can have conferencing services over the Internet (IP network). Also, certain add-on services (e.g. Billing information, Customized Call Forward settings) provided by TINA can be accessed through the TINA interface. Web Camera End User IP Phone Residential TINA Interface Transport Network TINA Softwitch Residential TINA Interface Web Camera End User IP Phone Figure 4 The designed network structure for this project

6 B. Residential Interface to TINA Network Due to in-built capability limitations of the available commercial RGW, an external PC is required to interface with the TINA Network. It is used to simulate the ideal CORBA-enabled RGW that might be manufactured in the future. The RGW must also have the ability to create an accountable object for each service application. The accountable objects perform metering of service events and reports to the service provider at the end of each service session. The enhanced RGW also needs to have the ability to initiate request for TINA services. Hence it must contain the Assess Session User Application (asuap) service component of the TINA service model. It implements the access-session human user interface in the user domain and supports incoming requests from the provider domain. In the context of the voice service, this interface is used to alert the user of an incoming call request. This interface is generic and is used by any service offering that requires provider requests to be delivered to the user. With the CORBA-enabled RGW, it is possible to set up a DPE all the way to the consumer domain. There is no need for API-to-Protocol adapters for every protocol as it is in the Softswitch. This allows the Softswitch, applications, control and management and consumer domain to be protocol independent as shown in figure 2 stage 3A. VII. REFERENCES [1] H. Jennifer, Residential s & Home Networks, last update: 11 th Mar 2001 [2] D.L. Waring, K. Kerpez, S. Galli, S.G. Ungar, Home Networks and Internet Appliances Shape Service Provider Access Architectures, Telcordia Technology, [3] M. Arango and C. Huitema, Simple Control Protocol (SGCP) version1.0, Bellcore, may, [4] Service Architecture, Version 5.0, TINA- Consortium, June 1997 [5] K. Eilers, R.A. Achterberg and H.E. Hanrahan, A TINA Implementation for Controlling Streamed Voice Services, en-eilers.doc, last visit: 11/3/2000. [6] Service Component Specifications, Version 1.0b, TINA-Consortium, January 1998 [7] TINA Business Model and Reference Points, Version 4.0, TINA-Consortium, May 1997 C. Value added services from SATINA Enhanced VoIP in the SATINA platform will be implemented to demonstrate RGW interfacing with the TINA services. Conferencing will be additionally used to exhibit control and management aspects of the NGN / RGW configuration. The use of further advanced services can then be implemented to give insight into how future services can be deployed. VI. CONCLUSION New service demands are emerging in the enhancedservices marketplace. Current technologies do not provide for management of the services and serviceintegration. Intelligent service management and controlling issues with RGW have been examined. TINA service access architecture and the accounting model were described in detail. It has been shown that TINA can provide simple mechanisms to add ancillary services and service-integration. This paper presented an approach to a conferencing service implementation using TINA. The designed network configurations employed to simulate the real world service provision condition were discussed.