Formalising the NGN Application Layer

Transcription

1 Formalising the NGN Application Layer Doron Horwitz and Prof. Hu Hanrahan Centre for Telecommunications Access and Services * School of Electrical and Information Engineering University of The Witwatersrand, Johannesburg, South Africa doron.horwitz@students.wits.ac.za, hu.hanrahan@wits.ac.za Abstract Development of applications based on call/session such as SIP is limited as it requires software programmers to possess detailed knowledge of telecommunications technologies. In addition, this type of application development leads to a telecommunications application layer with limited structure. This paper proposes a development approach based on direct interaction between a terminal and application server, thereby circumventing the reliance on messages traversing call/session entities within the network. This approach results in the transfer of development into an application layer with suitable abstractions. As a result, IT programmers who are unfamiliar with the underlying telecommunications network are supported by a robust software framework in which bearer connectivity control is abstracted and moved into the application layer. In implementing this modified development environment, telecommunications operators obtain additional control over the quality of s developed by 3 rd parties. A further benefit is that software programmers will no longer make use of call/session protocols in lieu of APIs or for tasks which are not related to session or bearer connectivity control. Index Terms s, application layer, bearer connectivity, I. INTRODUCTION A curious inconsistency exists in the telecommunications world: Next Generation Network (NGN) users and standardisation bodies are calling for rich, complex s [], but despite this, creation is not supported by a consistent, intuitive and robust framework. When one considers that simpler Intelligent Network (IN) s would take in the order of a year to be developed [2, pp 23], it would be expected that a more robust development environment would be required to reduce the time taken to produce more complex s. Developing s in the IN was a complicated process as it required an in depth understanding of the hardware which would execute the logic and also how the various physical entities in the network would interact with each other. However, development within these constraints was more justifiable as the IN was vertically integrated a telco would exclusively program s for its own network and also would not have to concern itself with converging various kinds of network technologies. * The centre is supported by Telkom SA Limited, Nokia Siemens Networks, Vodacom South Africa, Telsaf Data and the THRIP Programme of the Department of Trade and Industry. call/session bearer network Application Server call/session Fig.. The heavy use of call/session in modern infrastructures. The dotted line shows the path that messages travel between s and terminal applications. The structure of the modern development environment is drastically different to the legacy IN. Modern development needs to cater for users with more complex requirements and also for a more open, horizontally integrated programming environment. This infers that programmers needs to be more abstracted from the network than in the past, allowing them to focus on logic and preventing them from misusing the network at a low level. This effectively pushes s development up into an application layer. It will be shown that if this application layer is properly formalised that modern development is simplified and made more intuitive. II. CURRENT SERVICE DEVELOPMENT SHORTCOMINGS The IP Multimedia Subsystem (IMS) is being promoted as the core infrastructure of the modern interoperable telecommunications network which supports complex multimedia s [3]. However, its structure has been shown to add unnecessary overhead to the operation of the network and more complexity to the development of s [4]. Whilst the IMS does cater for Open Service Access (OSA) technologies, s for the IMS are developed primarily using the Session Initiation Protocol (SIP) [5, pp 33]. For programmability, it is inappropriate to use a protocol as an application programming interface (API) [2, pp 24-27], which is done by the IMS SIP application server (AS) to expose logical resources and functions of the network, as shown by the vertical arrows in figure. SIP is also

2 used for between applications in the AS and in the terminal as shown in by the horizontal arrows in figure. SIP is a protocol designed for creating, modifying, and terminating sessions with one or more participants [6] and not for sending messages between terminals and AS s. Some consequences of using SIP in these ways are described below. A. Too Complex for IT IMS programmers need to have proper understanding of SIP and thus telecoms oriented protocols. When one considers that an open network should allow for Information Technology (IT) developers (who are unfamiliar with the concepts of session ) to utilise telecoms network connections to enhance their applications with Computer Telephony Integration (CTI), using SIP to interface with the network would hinder the software development process. B. Inadequate Modelling and Leaky Abstraction An interface into a system is effectively a model of the system. An interface provides an abstracted description of the system with which one can interact to obtain a particular result. A distributed telecommunications system which has multiple entities frequently interacting with each other can be considered a complex system. From a complexity science perspective, a model must be at least as complex as the system of interest [7]. From a software perspective, this means that an interface must be correctly abstracted to provide a holistic and sufficiently complex model of the system which is decoupled from unnecessary implementation details. The IMS provides the IMS Service Control (ISC) reference point as the interface into underlying network functionality. The SIP AS interacts through this reference point only with the Serving Call Session Control Function (S-CSCF), and does not consider any interactions with the other IMS CSCFs, despite the fact that they are instrumental in the overall and session control. This means that the model of the network which the ISC reference point provides to the programmer is inadequately complex as it only provides a model of part of the system. Further, since the reference point uses SIP which is a telecoms oriented protocol, the programmer needs to have knowledge of the underlying network and thus the interface into the network is a leaky abstraction [8, pp 83]. This means that application logic in a SIP AS would not be correctly decoupled from the operation of the underlying network. C. Unstructured Environment There is a lot of commonality between the structure of different software applications. For example, many applications require a graphical user interface built with the same buttons and textfields. Reusability is a concept in software engineering which allows software components to be reused in different applications. Often, these reusable components are grouped into a framework whose task it is to dictate the architecture of an application [9, pp 26 28]. This is useful to businesses as it offers a means for ensuring consistency and quality by constraining a programmer to pre existing company practices. Also, the execution of applications developed within a framework differs from those that are not. Without a framework, the programmer has to implement the code required to initialise the application. Conversely, a framework initialises the application itself and then calls on the program logic developed by an outside programmer. This gives businesses a further level of control, allowing them to determine when and where application logic is called on. These ideas would be equally useful to telco development. This is especially true where 3 rd party programmers are developing s to be deployed within a telco s network. Telcos require quality guarantees which can be obtained by enforcing the use of a framework with reusable components. Implementing reusability with a protocol is problematic. For example, building reusable building blocks using SIP directly is not possible, as it provides very fine grained control and so does not provide a means for creating an abstracted view of the network. Attempting to group SIP messages into a reusable component would just result in an abstraction of SIP, which is not standardised by the SIP AS of the IMS. Following from this, it can be said that programming using SIP as opposed to a reusable call control API, is roughly analogous to programming in high level languages rather than assembly [2, pp 27]. III. APPLICATION LAYER Having outlined some major difficulties of programming s in the modern development environment, it is possible to move on to determining how the formalisation of an application layer firstly mitigates these problems and secondly allows for more robust, streamlined and simplified development. A. Definition Before defining the application layer, it is useful here to differentiate between a and an application in the telco context. For this discussion, a incorporates the entire operation of a particular supporting value added function of the network including the logic, between terminals and servers and the manipulation of the bearer functionality of the network when required by the. An application is the computer software implementation of the logic which resides in an AS. The application layer being discussed is similar to that of the Open Systems Interconnect (OSI) 7 layer model, and exists at top of the layered architecture within the technology neutral NGN framework developed in [8] (referred to from here on as the NGN framework ). This layer is the locus of logic where, in a sufficiently decoupled environment, the majority of development occurs. It is supported by the control function layer (SCF), which provides a means for controlling underlying network functions a Parlay/OSA gateway being an example of an entity falling in the SCF layer.

3 Application Server Watcher Presence Service Presentity Application Layer Signalling call/session network specific bearer network Technology Neutral API (A) Connect to presence and obtain presence status of all presentities to which the watcher is subscribed loop : Connect to Server 2: Authorise 3: Request Presence List 6: Provide 4: Subscribe to 5: Acknowledge Subscription For each of the presentities to which the watcher is subscribing Fig. 2. Improved infrastructure. Application layer is emphasised as call/session is reduced. The dotted line shows the path that messages travel between s and terminal applications. (B) Presentity updates status and relays this update 8: Update 7: Update B. Requirements The intention is, as far as possible, to move development into the application layer. To this end, three main ways of reducing leaky abstraction and simplifying development are discussed below. ) Reduction in Call/Session Signalling: It has already been shown that it is unsuitable to use call/session directly for application development. There is little reason for messages passing between applications in the network and terminals to be processed by call/session entities or formatted using call/session protocols. Instead, where there is a requirement for bearer connectivity, access into lower level network functions should be controlled using a technology neutral API shown in figure 2, which abstracts out the details required for call/session control. However, for the majority of, messages will travel directly from AS s to terminals and vice versa. This application layer is discussed further in section IV. 2) Improved Structure: As development moves into the application layer, a high degree of structure needs to be given to this layer. It is possible to group all the functionality discussed above (abstracted APIs) and which will be discussed below (bearer connectivity state and control and application layer ) into a structured framework. This framework is based on the structure proposed in [0] and provides reusable software units and a management component which prevents interaction and authorises access to s and the reusable software units. The framework approach also enforces structure on the applications developed by 3 rd parties enabling a telco to guarantee some level on software quality. The framework is detailed in section V. 3) Application Layer Bearer Connectivity Control: The use of abstracted interfaces into the call/session functions of the network can be enhanced further by moving bearer connectivity control completely into the application layer. Bearer connectivity here refers to any kind of multimedia connection including 2 party or multi party calls and voice and video streaming. As most s require some level of Fig. 3. Message sequence chart for a presence implemented using application layer. Two parts of the are shown: (A) the watcher subscribes to the presence state of a list of presentities and (B) a presentity updating its status to the watcher. All messages can be mapped onto single signals. session control or bearer connectivity, but the requirement is to ensure that the developer does not need a deep understanding of the underlying call/session technology, there must be a means to provide this control in a fashion oriented towards the application layer. If this is done correctly, as explained in section VI, a programmer is presented with a centralised, holistic layer with integrated control over call/session [0]. C. Telecoms Constraints The requirements for the application layer may seem to be in disagreement with some telco requirements. Telcos desire that s be developed to a high quality standard since end users of these s will direct all technical queries and complaints to the telco. Thus the telco is responsible for all 3 rd party developed s. Further, in order to generate revenue from s, a telco needs to add value to the to avoid becoming a bit-pipe. Since there is a move towards open development, telcos require strategies to ensure that they remain in the loop. The proposal for a structured application layer actually assists this by imposing structure and, by extension, quality on the software. Secondly, the framework is under the control of and maintained by the telco. Since the framework approach is followed, the telco can manage access into the reusable software units and also have full control over the execution of s. IV. DIRECT APPLICATION TO APPLICATION SIGNALLING A key aspect of reducing the unnecessary use of call/session is allowing applications and terminal applications to signal directly to each other as in figure 2. For s that require limited call/session functionality, such as a presence, the reliance on the bearer network is

4 UserProfileDatabase TerminalConnection UserProfile Service ContactAgent ServiceManager ReusableBuildingBlockManager Service A Service B Service C ReusableBuildingBlock RBB RBB 2 RBB 3 Fig. 4. UML Class diagram of application layer framework. reduced, if not completely circumvented. An example of this, given in figure 3, contrasts greatly with the IMS presence which makes heavy use of SIP messages traversing multiple call/session entities []. SIP/IMS messages are very fine grained and are not named according to the operations for which they are used by a. For example, in the IMS presence, multiple undescriptively named NOTIFY signals are used to update a presentity s presence state to a watcher. Instead, to further move away from the use of call/session, all application layer signals are named more descriptively according to the high level operations which they facilitate. This simplifies their use and also aids in debugging by allowing programmers to easily determine the purpose of each signal. An upshot of allowing an application in the terminal to signal directly to an AS is that bearer connections can be initiated in the application layer, which differs from legacy networks in which simple calls would not have to invoke any s at all. Thus, application layer allows call control to be a in itself. This necessitates the application layer bearer connectivity control discussed in section VI. Since the software framework discussed below is designed using object orientation, the approach is taken of naming signals according to software objects operations. For example, to add a new call leg to currently running bearer connection, a signal would be sent from the terminal indicating that the framework would have to call the addcallleg operation of a BearerConnection object. This necessitates the development of a protocol whose purpose is to marshall and transport method calls on remote objects a subject not covered in this paper but identified for further work. V. PROGRAMMING FRAMEWORK The relevance of the software engineering concept of a framework to the application layer has already been discussed in section II-C. Its structure is now detailed. Object orientation and technology neutrality are emphasised in its design by using the Uniform Modelling Language (UML). The classes and relationships shown in the UML class diagram of figure 4 represent the management structure of the framework. All applications are deployed within this framework, which also controls the access by terminals to them. The framework also enforces authorisation rules for allowing a to use the reusable software components. This and other functionality is expounded up in the description of the classes in the points below. The framework is made up of the following classes, grouped according to related functionality: ServiceManager this is the central class which controls the framework s overall running. This class facilitates communication between terminals and s and also acts to prevent interaction. A ServiceManager object is instantiated when the framework is initialised. All applications register with this object so that it can authorise terminals to use their functionality. Remote method calls from the terminal traverse this object, meaning that it also performs the resolution of network formatted signals into method calls. Service a programmer uses this class as the base of implementing logic. The class which contains the starting point of a s logic must inherit from the Service class and override a function which the manager will call on to instantiate the. The ServiceManager can then call methods from the Service instance according to requests from the terminal.

5 TerminalConnection, UserProfile and UserProfile- Database these classes act as the software representation of a terminal connected to the AS. The UserProfile- Database class is the technology neutral interface into the information about each user. When a terminal connects, a TerminalConnection object is instantiated and filled with a UserProfile object which contains the information obtained from the database about the registered user for the terminal, including access rights to specific s. ReusableBuildingBlock and ReusableBuildingBlock- Manager these classes serve to implement the reusability promoted by the framework. Sets of reusable functionality, such as the call control described in section VI, use the ReusableBuildingBlock class as the base of APIs they provide.the ReusableBuildingBlockManager controls access to the building blocks, from the points of view of authorisation and of simultaneous access by multiple s. It is useful to note that access can be controlled on a per and per user basis. VI. BEARER CONNECTIVITY STATE AND CONTROL Moving development into the application layer calls for bearer connectivity to be encapsulated as a component in the framework. To do this, two aspects must be considered. Firstly, the programmer must be provided with a means to signal to the network to setup, maintain and teardown a bearer connection which can be performed using the Parlay APIs. However, Parlay has inadequate structure, does not implement software reuse and offers no guidance on application layer usage [0]. Since the same patterns of API calls are often used for common tasks, the approach of encapsulating these sets of Parlay API calls into reusable building blocks will be taken. This further abstracts the programmer away from underlying network technology. The second aspect of bearer connectivity control is that of monitoring the state of a bearer connection. This is usually maintained in the lower layers of the network, requiring that the developer query the underlying network using call/session, API calls or web requests. This increases the complexity of maintaining a bearer connection: the application first has to query the network for the state of the connection and then when it has determined that a particular operation will not be invalid according to the current state of the connection, it then performs this operation. With this approach it is difficult to guarantee that the correct operations will be executed according to the current state. Bearer connectivity control and state need to be coupled. It follows that the view of the state should be moved with bearer connectivity control into the application layer. In this way it is easier to integrate the two. For example, it is possible to use programming exceptions found in modern programming languages if the application attempts to call an operation which is unsuitable to the current state, then an exception will be thrown before the application attempts to interact with the underlying network. This also allows a telco to ensure that CallLeg Terminal Fig. 5. BearerConnection VideoStream ReusableBuildingBlock BearerConnectivityRBB MediaStream AudioStream CallState Call control reusable building block API the bearer connectivity control is not misused by a 3 rd party developer. Bearer connectivity control lends itself to being controlled using object orientation and is thus represented with the UML of figure 5 and encapsulated within the framework as a reusable building block in the following manner: a BearerConnection is made up of multiple CallLeg and associated Terminal objects. Since various stream types are supported, each stream originating at a terminal is represented with an object inheriting from the MediaStream base class. The bearer connectivity state is represented with a CallState object which encapsulates the call state model developed in [2]. Any operation performed on the BearerConnection is checked against the CallState object, to ensure that no invalid state transitions occur. VII. CONCLUSION The shortcomings of the current development environment have been addressed by developing a framework which as far as possible circumvents the requirement for inefficient and inapplicable call/session. This framework also adds structure to the infrastructure in which programmers can create s, which is an important aspect of moving development into the application layer and allowing telcos to enforce quality control on 3 rd party developed s. The introduction of direct application to application and the relocation of bearer connectivity control and state monitoring into the application layer enhance the framework s structure and make for a high level of simplification in NGN development. This results in programmers not requiring knowledge of telecommunications technologies in order to implement logic yet still being afforded holistic and integrated control over low level network functionality. REFERENCES [] ITU-T, Recommendation Y.220: Next Generation Networks - Service aspects: Service capabilities and architecture, International Telecommunications Union, Geneva, April 2007.

6 [2] R. Jain, J.-L. Bakker, and F. Anjum, Programming Converged Networks: Call Control in Java, XML, and Parlay/OSA. USA: John Wiley & Sons Inc, [3] MSF, MSF-ARCH FINAL: MSF Release 4 - Physical Architecture, MultiService Forum, September [4] P. Moodley and H. Hanrahan, Evaluation of the IMS-based MSF architecture against network architectural requirements, in Proceedings of the Southern African Telecommunications and Networks Conference - SATNAC 2008, South Africa, September [5] G. Camarillo and M. A. García-Martín, The 3G Multimedia Subsystem (IMS) Merging The Internet and The Cellular Worlds. England: John Wiley & Sons Ltd, [6] J. Rosenberg et al., SIP: Session Initiation Protocol, Internet Engineering Task Force, RFC326, June [Online]. Available: [7] K. A. Richardson, P. Cilliers, and M. Lissack, Complexity Science: A Grey Science for the Stuff in Between, in Proceedings of the first International Conference on Systems Thinking in Management, Geelong, Australia, November 2000, pp [8] H. Hanrahan, Network Convergence - Services, Applications, Transport, and Operations Support. John Wiley & Sons, Ltd, [9] E. Gamma et al., Design Patterns: Elements of Reusable Object- Oriented Software. Addison-Wesley, 995. [0] B. Fricke and H. Hanrahan, The Development of a Structured Approach to Service Provisioning in a Parlay Environment, in Proceedings of Southern African Telecommunication Networks and Applications Conference (SATNAC), Cape Town, South Africa, September [] 3GPP, TS 23.4: Technical Specification Group Services and System Aspects; Presence Service; Architecture and functional description (Release 8), 3rd Generation Partnership Project, June [2] D. Vannucci and H. Hanrahan, OSA/Parlay-X Extended Call Control Telecom Web Services, in Proceedings of the th International Conference on Intelligence in Service Delivery Networks - ICIN 2007, Bordeaux, France, October Doron Horwitz completed a bachelors degree in Information Engineering at the University of the Witwatersrand in He is presently pursuing an MSc (Electrical Engineering) degree at The University of the Witwatersrand. Hu Hanrahan is a Professor of Emeritus at The University of the Witwatersrand. He led the Centre for Telecommunications Access and Services (CeTAS), a research and advanced teaching centre devoted to improving knowledge and practice in telecoms access and s.