Automated Service Management for Semantic IP Multimedia System [S-IMS] ()
1. Introduction
ITU-T defines Next Generation Network (NGN) as follows [1]:
“A Next Generation Network (NGN) is a packet-based network which can provide services including Telecommunication Services and able to make use of multiple broadband, Quality of Service-enabled transport technologies such that the service-related functions are independent from underlying transport-related technologies. It offers unrestricted access by users to different service providers. It supports generalized mobility which will allow consistent and ubiquitous provision of services to users.” [2].
NGNs are commonly built around internet technologies such as Internet Protocol (IP) and Multiprotocol Label Switching (MPLS). As the result, there is a more well-defined separation between transportation (network) and application layer. The service provider can easily enable new services without considering the transportation layer, increasing the productivity and variation of services that can be enabled on NGN. One of the implementations of NGN is IP Multimedia System.
IP Multimedia System (thereafter IMS) provides the underlying infrastructure and foundation of the next generation networks [3]. The research proposes ontologybased architecture for automated service creation and management of IMS or namely Semantic Next Generation Network (SNGN). The service architecture is developed around the IMS functionalities and several majority protocols. The principle and outline of the converged technologies, different types of platforms and network elements are briefly described in the following sections to establish basic understanding on them.
2. Related Standards and Technology Overview
2.1. IP Mutimedia System
IMS is a standard defined by 3rd Generation Partnership Project (3GPP/3GPP2) to support convergence of different types of network, like GSM, WCDMA, CDMA2000, Wired broadband access and Wireless Mobile [3]. It also allows access to voice, video, messaging, data, and webbased technologies for the users in a mixed network. IMS implement Voice-over-IP (VoIP) based on a 3GPP standardized implementation of SIP which is an Internet Protocol (IP) based protocol. IMS based services will bring a new communicating experience to the users when no limitation on communication protocols are imposed. The users experience mixed mode communications, this include voice, images, video, text or any combination of these regardless whether the interactions are on mobile phone, internet phone or fixed-line phone. The experience can be further personalized to suit the liking of the user in a controlled manner.
The basic of IMS architecture consists of three layers:
1) Service Layer—includes Application Servers (AS) which hosts various types of value added services to the end users. Generic services defined in IMS such as SIP AS is implemented in service layer. It can also be 3rd party host/vendor exposing value added services to the end users.
2) Control Layer—IMS core network resides in control layer. The network control servers set up, manage, modify and release call and session in the network. The important servers are:
a) Home Subscriber Server (HSS) for user profiling, authentication and authorization.
b) Call Session Control Function (CSCF) which is a collective server or proxies for processing SIP signaling packets in IMS. This layer also handle provisioning, charging and operation and maintenance.
c) PSTN Gateways which handles internetworking between operator and other type of networking.
3) Connectivity Layer—Connectivity layer is where the physical transport layer resides. It comprises of switches, routers, access network and various physical network elements. The business benefits to the operators are the abilities to introduce new services to market faster in order to keep up with the ever challenging of the growing consumer markets in the mobility space. The horizontal architecture in providing the services enables reusability of the common services and functions for multiple applications. Service creation and provision process will be simplified to provide a wider space for creative and innovative ideas and for the service management to be realized.
2.2. Session Initiated Protocol
The Session Initiation Protocol (SIP) is an IETF-defined signaling protocol, widely used for controlling multimedia communication sessions such as voice and video calls over Internet Protocol (IP). SIP specification can be obtained from the Internet Engineer ing Task Force (IETF) Network Working Group under RFC 3261 [4].
SIP is an Application Layer protocol which is independent from the transport layer. It is designed to run on Transmission Control Protocol (TCP), User Datagram Protocol (UDP), or Stream Control Transmission Protocol (SCTP). In November 2000, 3GPP accepted SIP as the signaling protocol for IMS.
SIP also defines server elements under RFC 3261 [5].
The server elements are as per below.
1) User Agent User Agent is a logical network endpoint use to create or receive SIP messages. The User Agent can perform as User Agent Client (UAC), or User Agent Server (UAS). UAC is the receiving role which sends SIP messages, on the other hand, UAS is the sender role which handle SIP messages and response accordingly.
2) Proxy Server Proxy server plays the role of routing. It acts as both UAC and UAS by making request on behalf of other clients. It also acts as policy control to enforce call policy within the network.
3) Registrar A registration server which handles the REGISTER requesting for information. User Agent will be registered in the location service domain with one or more IP addresses to a SIP URI.
4) Redirect Server Generate redirect (3xx) response to the request receive, allowing SIP server to direct SIP session to external domains.
5) Session Border Controller Server between UA and SIP server for network topology hiding and NAT traverse.
6) Gateway SIP interfaces to other different type of network, for example Public Switching Telephony Network (PSTN).
2.3. Semantic Web Services
The W3C defines web service as a software system which supports interoperability interaction of machines over a network. The interface format describes the attributes of the service using Web Services Description Language (WSDL) [6,7] which is standard and machine readable. Systems interact with each other by consuming SOAP [8] messages, typically transported using HTTP with an XML serialization.
Semantic Web Services, just like the conventional web services, has the additional data mark-ups which are machine readable using ontology. An ontology is a formal, explicit specification of a shared conceptualisation [9]. Semantic Web Services uses Web Ontology Language (OWL) to describe the resources and properties of the service nature. The Semantic Web Services is discoverable through their description and input and output data type.
2.4. Web Service Web Modelling Ontology (WSMO)
Semantic Web Service is one of the ways to address the issue discussed. Semantic mark-up can be used for an automatic discovery, service composition and interoperability of the services.
The Web Service Modelling Ontology (WSMO) [10] is a conceptual model related to Semantic Web Services. It provides an ontology based framework, which supports the deployment and interoperability of Semantic Web Services. The formal language being used to provide syntactic and semantic for the WSMO is Web Service Modelling Language (WSML).
The four main components of WSMO:
Ontology—Define formal semantic description and allow the linking of machine to human terminology. It also gives information understandable to components, for both human and machines and provides meanings to other elements (goals, mediators and web services)
Goals—Define the client’s objective and needs when requesting for a Web Service. The requestor will express its goal in one hand to let human to understand the goal and in the other hand for the machine to interpret the nature of the request. The advantage of using the goal is that it does not require one to browse through the UDDI registry to find the appropriate service as the requester already provides a declarative description of what he wants.
Mediators—The connectors between components with mediation facilities. It provides interoperability between different communication protocols.
Web Services—Semantic description of Web Services which include functional capability and usage descriptions. If the requestor and the Web Service use the same ontology the matching between the goal and the capability can be directly established. However, in most cases, the requestor and the Web Service will be having its own ontology, making it a need to consult third party to check if the goal and capabilities can be matched. The third party needs to make sure that there are similarities in the goal and the capabilities before establishing connection.
The Web Service Execution Environment (WSMX) [11] is a reference implementation for WSMO designed to support dynamic discovery, invocation and composition of Web Services. Service provider can register their services in WSMX to make it available to the consumer, and subsequently, service requester can find the service they need in semantic environment.
3. Challenges
The challenge of SNGN is of the nature of the service environment. For WSMX, it’s dealing with single protocol, which is web service. There is no clear implementation in the WSMX to handle multiple protocols other than web service. The WSMX framework also does not provide detail on how to create and design for multiple protocols. This is the main challenge of bringing IMS into WSMX environment and to have a SNGN.
The IMS environment will be more complex than Web Services, as IMS environment is highly dependent on the underlying network and devices capability. As the relationship between network and devices alone can be complex, there is a need for semantic description to handle between network environment and device capabilities.
Besides that, the management of services provided in the IMS poses another challenge due to the heterogeneity of the service protocols, service requirements and specifications and service functionalities. Devices will change access technology from time to time (for example, from cellular network to WiFi, from video call to voice call) or transferring session to another device as the user could be logging into different devices in the same time. All this will have to be taken into consideration to meet the user experience and expectation. Services will need to be able to handle different protocol seamlessly to complete the service requirements without interrupting user experience. There will be a need for service management automation to match and consume the protocols and the services to simplify the process flow.
4. Use Cases of Semantic Next Generation Network
In order to explain better the real life situation of Next Generation Network user experience, this section describes a short narration of how automated service management and creation in NGN could enhance one’s personal life. Mr. Jimmy is a Google calendar user. He constantly updates his activities and meetings into the Google calendar as a reminder to himself. With the integration of IMS network and the calendaring service, one can explore further into behavior and contextual based call handling. For example, Mr. Jimmy had set a meeting appointment in the Google calendar from 10 am to 12 pm. In the calendar note, he had specified, “Please call my secretary”. When Mr. Sean try to call Mr. Jimmy at 11 am, based on the calendar event of Mr. Jimmy, he is not available due to the meeting and the calendar note specified to call his secretary, the call will be automatically routed to Mr. Jimmy’s secretary without any intervention. On Mr. Jimmy’s mobile, he will get an email notification or SMS notification saying that Mr. Sean tried to call him on what time and the call is being handled by his secretary. This can be further explored to handle the call differently based on the ontology of the user behavior based on what he is looking for in his calendar.
The other scenario based on the calendaring service will be that Mr. Jimmy can set his availability status as “Away From Office”, “Do Not Disturb”, “Call My Mobile”, “Contactable via SMS” and so on. If Mr. Sean calls Mr. Jimmy, depending on the status of availability of Mr. Jimmy, the call will be handled according to Mr. Jimmy’s preference. For example, “Away From Office” will route the office land line to Mr. Jimmy’s Mobile number, “Contactable via SMS” will convert the voice Memo as SMS text and deliver to Mr. Jimmy and so on.
The services can be further extended by taking the existing ontology and relate them through different services, for example, location map, food finding, event finder and so on. A related case will be when Mr. Jimmy set a golf appointment at evening; a food finding service will promote Mr. Jimmy to the popular place to dine around the golf venue, and with this, Mr. Jimmy can send invitation to his partners to have dinner together.
These scenarios are able to show the capability of linking multiple protocols and multiple services in semantic way and the comprehensive view of how advance service orchestration can be done over Semantic NGN.
5. Semantic IP Multimedia System (S-IMS) Architecture
5.1. Issues and Challenges in S-IMS
IMS is chosen as the one of the popular convergence platform in NGN. There are 3 main layers in the standard IMS architecture which are the Service Layer, Control Layer and Connectivity Layer. While in the Semantic Web Services, the semantic is built around the application layer through the enhancement of the WSDL description, UDDI directory services and the selection, searching and matching techniques.
To have a S-IMS, the following needs to be considered.
1) IMS default services: IMS common functions such as group list management, presence, provisioning, directory, charging and deployment. The number of the services will continue to grow, as the market demands grow. Hence, the built-in IMS functions require semantic descriptions to describe its capabilities and limitations. For example, presence of the user is described in semantic way which could include his location, latest activity, and interest depending on the location of the user.
2) Internetworking between service providers: IMS support the convergence between wired-line and wireless as well as legacy PSTN network. The application to support the different end user devices vary depending on the end device capability. The information of the device is not easy to capture and even maintaining them can be arduous. Besides, this will also be difficult for the service provider to capture the capabilities of the device to provide the matching services for different end devices. For example, the service provider can trigger a video call for smart phone with video capability and not on the legacy PSTN network. Building the ontology to describe the device and the service capability and availability will enhance the selection ability to select appropriate service.
3) Access-aware of network capabilities: One of the upmost requirements for IMS is to ensure smooth transition between network switching. Network information and status such as network latency, QoS, device support, bandwidth availability, is needed to determine the best effort in communication delivery. An ontology based description of the network will be helpful in making the accurate decision which usually depends on network condition.
The issue above are not exhaustive but sufficient to illustrate the needs of the ontology based support for managing service creation and management for IMS network. In the following section, we will be describing on the possible solution to manage the challenges tabled out.
A semantic-based IMS network is proposed to address the challenges of the existing pure IMS network. By injecting semantic description into IMS, we can automate the service creation and management of the IMS network. To integrate IMS with Semantic network, a proposal is to implement WSMX together with IMS network.
There are few major building blocks which need to be considered to achieve Semantic IP Multimedia System (S-IMS). Figure 1 shows the high level system architecture to achieve S-IMS.
User Agents (UAs) refer to the end user devices, which can be generalized as mobile phones, laptops, tablets, fixed network and so on. In IMS environment, UAs communicate to IMS network with SIP protocols.
To implement S-IMS, WSMX is introduced by integrating itself with IMS via Web Service Markup Language (WSML) [12]. WSMX will be responsible to handle semantic services required by IMS by abstracting services provided by various Application Service Providers, and perform semantic matching to the best qualified service to input back to the S-IMS network. Figure 2 shows more detailed components and interconnection between various network and server components to achieve S-IMS. There are various layers of services in S-IMS network. User Devices, Network Layer and IMS Control Layer are all well described in IMS network literature and will not be further elaborated here. What we are going to introduce here is Semantic SIP Layer and WSMX integration.
IMS Service Layer which consists of various SIP Application Server will be integrated with Semantic SIP Layer, which is managed by a J2EE Application Server. The J2EE Application server acts as integration point between IMS Service Layer and WSMX to merge the gap of the different domain. The J2EE Application server
Figure 1. High level S-IMS system diagram.
Figure 2. High level architecture system diagram of S-IMS reference model [13].
will manage SIP protocol, and translate the IMS User Agents, services, and network environment into semantic description for WSMX to process further.
WSMX will be responsible for appropriate service to achieve the requestor’s goal. A goal matching degree should be specified to determine the level of matching of the services, as the requestor might be satisfied to the services which can fulfil to some extend of the goal. The Application Service Provider could be located internally as provided by the 3rd party out of the domain or can even be a cloud service located elsewhere.
We will be focusing on J2EE AS and the integration with WSMX in the following section as this is the core focus of this project.
5.2. Integration of Building Blocks of S-IMS
There are 2 main building blocks in the S-IMS architectture as shown in Figure 3. The first part is J2EE application server which will interface with IMS and other protocols and to provide input to the later part. There are few service components which build the Semantic SIP J2EE AS, which are as the following:
1) SIP Manager To manage SIP protocols and or other types of Network protocols. This is the interceptor of SIP signal via SIP Servlet to determine the next action to be taken.
2) Service Decision Router The Service Decision Router will determine the needs of Semantic SIP by the nature of the request. There might be a case where request will be directly routed to SIP manager to response back to SIP AS where no translation is needed. Otherwise, the router will route SIP message to be processed by the next step.
3) Core Message Processor SIP Message Processor to determine the SIP message request and what need to be done to the message. This is the core engine to compose and decompose the SIP messages and to handle Semantic based SIP messages.
4) Semantic Translator A Translator which will pull out the Semantic description of the SIP message base on the request type for Core Message Processor to process the message further.
5) WSML Service Composition Engine The interface of J2EE AS to WSMX as to compose the WSML service to perform the actual request to WSMX.
6) Semantic Description Service A Semantic description database for various IMS network element to be located here. The semantic description database itself can be exposed as a Semantic Web Service by WSMX if needed.
For the later part, which is WSMX environment, will define the semantic description of the service and do semantic matching based on the input request. Figure 3 shows the basic and required components needed for WSMX environment to execute together with IMS network.
Figure 3. Detailed system design and components for Semantic IMS.
5.3. Integration Services into SNGN
To illustrate the operation of S-IMS, taking one of the scenario as an example, the operation comprises of the following steps.
1) Mr. Sean Call Mr. Jimmy.
2) A > MPLS > CSCF > Call handling.
Mr. Jimmy calendar set to Meeting, Meeting note saying “call my secretary”.
Construct Semantic description > Check B calendar > determine service.
3) Call route to Ms. Secretary, call connected between Mr. Sean and Ms. Secretary.
Call routing base on the service response > CSCF > Connect A and C.
4) SMS/Email notification sends to Mr. Jimmy.
Event based action > Send SMS/Email to notify Mr. Jimmy after call setup successful.
6. Enabling Service Management Automation in SNGN
6.1. Semantic Web Service NGN (S-WSNGN)
A standard web service protocol is chosen to standardize to communicate between IMS networks. The standard interface will be used to abstract the underlying possible of heterogeneous protocols for IMS network. A reference model by ECMA which proposed ECMA-348 provides a standardized abstraction layer of call and device control in communication environment.
A study on Web Service SIP (WSIP) [14] had been conducted and could be further extended to support more than one protocol in the NGN. WSNGN which will encapsulate the multiple underlying protocols will be easily extended to Semantic NGN environment, in this case, the semantic IMS.
Table 1 shows the extract of the call elements for answering a call, defined by ECMA-323 reference model. The WSDL reference by ECMA-323 needs to be further extended include semantic description of the call control to further understand the device, network and user profile as part of the automated service matching in S-IMS network. Table 2 shows part of the description of a call control which includes the semantic description.
To handle the call, the semantic representation will gather all the available connections of the destination call and according to the priority of the call type, a decision will be made to control and to route the call using the appropriate connection protocol and to handle the connection between caller and recipient. The consideration of device capabilities and network environment will also need to be described, to be able to have a semantic reference when deciding on how to handle the call.
6.2. Profile of Services in SNGN
As for IMS network, there are 3 major profiles in the network, which are:
1) User Agent The end devices, for example, mobile phone, smart phone, laptop, tablet, fixed network phone and so on.
2) Services The services provided by IMS network and services provided by 3rd party vendors.
3) Subscriber The end user which consumes the services through the
Table 1. An example of XML element specified in ECMA-323 [7] with XML data reference.
Table 2. An example of Semantic Description of call handling.
User Agent.
The 3 major profiles are inter-related, and can be described semantically. The profiles need to be defined properly in order for the S-IMS to operate in automated mode. The relationship of these 3 major profiles is described in Figure 4.
To further elaborate, a subscriber can have only one subscriber profile, which will keep track of the subscriber personal information. However, the same subscriber can have multiple devices, a smart phone, a tablet, together with a fixed network phone is a norm, which can be all converged into the same IMS network. Subscriber can subscribe to various services provided by IMS or 3rd party vendor, and different devices will have a different service profile depends on the device capability; some of the device might not be able to consume certain services.
Semantic description of the relationship of this 3 major profiles and the detailed description of each profile need to be identified to build ontology for S-IMS.
6.3. Service Protocol Matching and Routing
As IMS network introduced complexity of multiple protocols in the network, either SIP, HTTP, Web Services, and legacy connections such as SMPP protocol for SMSC, FTP for file transfer, a dynamic and self-disco-
Figure 4. High level relationship diagram in SNGN.
very service protocol matching and routing is needed as shown in Figure 5.
Service protocol matching and routing can be implemented using First Order Logic by defining the domain elements and relationship among them. The relationship among the domain elements will define the routing logic and apply the relevant mapping and transformation of the protocols to enable integration and interchangeable in the underlying data format. Given a scenario, when the receiver is not available to pick up the call, the system needs to send a notification SMS to the receiver and route the call to 3rd party. In this case, two different protocols will be involved, a SIP protocol to establish a call, and SMPP protocol to send SMS. Based on the service description, the system will apply routing and transformation logic in parallel, which will connect to send SMS via SMPP, and establish a call in a different leg.
6.4. Service Creation, Discovery and Matching
Service enablement plays an important role in IMS. IMS is very dependent on the capabilities of the rich services provided either by the telecommunication operator or 3rd party vendors to enjoy the full capabilities of IMS network. WSMX has a defined set of methodology to define service creation, discovery, and matching. However, there is a need to extend the implementation of WSMX into part of the IMS network to fully enable semantic services within IMS network. The management of the services then can reuse the practice by WSMX which compose of service creation, discovery and matching. The idea of the architecture will be similar to WSMX with the application into real IMS network.
7. Future Work and Conclusion
This paper defines the basic architecture of the Semantic IMS network and the application of it. By implementing such architecture design, automated service management through embedding the semantic service descriptions that can be referenced to the service ontology for service creation and management into the Next Generation Net-
Figure 5. Service Protocol routing and matching.
work, which will become Semantic Next Generation Network (SNGN).
There is much detailed work needs to be done in defining the Semantic profile for services, protocols and devices in the IMS network. We can also drill deeper into the automated protocols routing and mapping logic which will enable dynamic and automated mapping for various protocols in the IMS network.
8. Acknowledgements
This project is funded by Fundamental Research Grant Scheme by Ministry of Higher Education (FRGS/2010 under Project title: Ontology-based Service Creation and Management for Next Generation Network (OntoCreaMe-NGN).