A Scalable and Reliable OSS/BSS for User Migration in IMS #

: Telecommunications operators moving away from legacy networks towards next generation networks (NGN) are faced with the complex task of migrating not only users and services but modifying or designing and rebuilding supporting systems as well. New service delivery platforms (SDP) like IP multimedia subsystem (IMS) are fundamentally different compared to the old ones and require a novel approach from both the business and technology point of view. The main emphasis in the latter case is namely on operations support systems/business support systems (OSS/BSS) and the way these have to change in conjunction with the development of SDPs. The current paper addresses just this matter and is focused mainly on technical aspects and more specifically user migration. Different migration cases have been brought forth, clearly defining their differences while keeping in mind the issues of reliability and scalability since migration towards NGN for most operators will happen with great volumes. The migration process and its relation to supporting systems has been expanded upon to specify how and what has changed during the path towards NGN, especially with regards to users. Also a novel system for provisioning and migration has been discussed to illustrate a possible way for large scale user migration.


Introduction
Telecommunications operators in their path towards next generation networks (NGN) [1] are faced with the inevitable task of migrating services and users away from legacy networks such as public switched telephone network (PSTN) or public land mobile network (PLMN). This is aggravated by a small number of general, yet major reasons common to all operators. These are: (1) financial, (2) the overall development and direction taken by the operator and (3) technical support systems. The latter however comprises of a large volume of nuances to be solved before migration can be performed successfully. Keeping in mind the lastly made statement the current paper is focused specifically on technical issues from a user migration point of view. The paper has three main aims. Firstly, to elaborate on different user migration cases. The need for user migration and the way it is done depends on a specific service provider (SP) and the level of its commitment to voice over internet protocol (VoIP) solutions and next generation networks in general. There may be cases when users are migrated away from PSTN or for companies with longer experience in NGN the need to move users from one application server (AS) to another may be pertinent for example. Emanating from the fact that the dominant service delivery platform (SDP) in NGN for multimedia services is IP multimedia subsystem (IMS) [2], the migration cases will be considered keeping this in mind. The secondary aim of this paper is to outline operations support systems/business support systems (OSS/BSS) and analyze the role these systems play in user migration. OSS/BSS-s are complex and mostly tailor made systems that enable much more than simply managing users. A definitive list of OSS/BSS nodes and functions is impossible to enumerate and can only be confined to the need and imagination of the operator. Still, there are on a high level some general functions that a support system must fulfill which include monitoring, authentication, authorization and accounting (AAA), customer hardware management and management of supporting data. However, stemming from the focus of this paper the main emphasis has been directed towards user migration and provisioning related issues of OSS/BSS-s, hence only focusing on a small part of an entirety. Lastly, a possible system for user migration will be described in detail to show how large scale migration tasks could be successfully completed keeping in mind the matters of scalability, redundancy and load balancing. The structure of this paper is as follows: different user migration cases are expanded upon in Section II, followed by a discussion of related OSS/BSS issues in Section III. A detailed overview of a feasible system for user provisioning and migration is given in Section IV. The topic is concluded in the last section of the paper.

User Migration Cases
Migration, on a high level, suggests the transferring of users, data or services from one computer system or platform to another. Keeping this in mind and for the sake of clarity two main and one minor sub case for migration have been distinguished dwelling from the focus of this paper. Naturally more cases can be isolated depending on necessity. The following paragraphs will expand on these cases in more detail. Firstly, the most widespread and controversial case today which is the migration from legacy networks to IMS. SPs around the world are in the middle of this process and making progress at different rates. This type of clear-cut migration is in essence a change of paradigm for the clients in the way services are delivered. The transition to NGN and the strategies that different operators are using has been focused on in more detail in [3]. From a logical standpoint the process seems simple. The user must be deleted from a legacy network and created again in NGN. However, the technical aspects of this delete-create scenario are far more complicated. Service delivery to customers on a new platform will require the replacement of most, if not all, network elements which in terms means a completely new way of provisioning users. This will be discussed in detail in Section III. In the context of this section it is crucial to stress the importance of continuity in the sense that the customer must be migrated with a minimum amount of disruption, with the accompanying processes and services left unchanged or enhanced after the transition to NGN. To be brief, the migration process has to be as seamless as possible. The second case for migration is within the IMS. An example of this might be moving users from one application server to another. This scenario in fundamentally different from the previous. The preparations for the first migration case demand large amounts of resources from the operators, whilst preparing to migrate within the IMS, by rule of thumb, does not require ample amounts of resources. No major changes to the SDP have to be made or nothing completely new has to be designed, built or implemented. Given that the operator already has systems in place to provision users, the emphasis here is then directed to minor modifications of already working processes, software and/or hardware. The mentioned task is theoretically made easier taking into consideration that IMS is a standardized platform. However, even though this case might seem simpler than the first, real life applications often require making complex changes to a large number of intertwined nodes and systems of the SDP. Another nuance which separates preparing the support systems for migration in the second case from the first one is the fact that the migration process does not need to be based on the earlier mentioned delete-create method. There may be cases when migration could be achieved by a few or even a single modification, for example to the home subscriber server (HSS) trigger [4]. In addition to the two scenarios for migration already described in this section there is a third which cannot be referred to as migration per se, namely, this is affiliation of new clients for the operator. The matter of new affiliations could be considered a subset of migrating users from legacy networks to NGN due to the need for user provisioning and this fact makes it pertinent in light of the current paper.

Evolution of the OSS/BSS With the Transition to Next Generation Networks
Support systems for telecommunications operators and service providers are computer systems that deal with the networks themselves that are used to provide services to customers. OSS/BSS-s are constantly evolving with the development of technology and the service provider. This area has been researched in [5,6,7,8].
Due to the dissimilar and complex nature of communications networks deployed over time by different service providers the OSS/BSS becomes a crucial factor in migrating users to IMS. Although the interfaces towards IMS are well standardized, they are considered merely a means to an end, used by the tailor made migration system to exchange data through. SPs each interpret support systems in their own way depending on their individual needs and properties. Considering that in order for users and services to be provisioned in a new SDP all of the OSS/BSS nodes and functions mentioned in Section I must be operational. As mentioned earlier the current paper focuses only on a specific area of an OSS/BSS. This has to do with user provisioning and in no way does this refer to diminish the importance of any other part of a complete support system. Fig. 1 illustrates a high level overview of the difference between provisioning a user in a legacy network and in NGN. Three distinctions can be denoted: mainly manual provisioning, increased number of nodes in NGN and the need for a central component in next generation networks to manage the provisioning process, indicated as the provisioning system (PS). Maximum automation of the SPs processes has been considered a key factor in the transition to NGN [6]. Service providers operating in a pre-NGN environment had some major deficiencies in this area. First of all there was simply no need for full automation since the amount of nodes in the network was small and secondly the stovepipe nature of services made it extremely difficult. Fig. 1 and Fig. 2 illustrate this matter. The user provisioning system in PSTN, depicted in Fig. 2 shows the digital exchange (DE) to be virtually the only node to provision a user in. In comparison, Fig. 1 indicates an increase in the number of nodes within the SPs next generation network, therefore multiplying the operations of single users' provisioning and hence creating the demand for automation.  It comprises of several functional blocks, for example accounting, customer relationship management (CRM) and product, client database. User access to this front end is defined by rights. In the context of user provisioning we consider this entity to be the input and no distinction shall be made whether the initial provisioning data is entered manually or is taken from a different connected technical system. The input mediation (IM) receives work orders from the TMFE and verifies each specific task. Its main responsibility in pre-NGN scenarios was to keep track of the order queue and forward the orders accordingly. However, there have been significant modifications to the IM with the migration to next generation networks. It is now connected to a multitude of network registers and adjacent systems which make the actual changes in the SPs network. The data arrives to the IM mainly in the form of an extensible markup language (XML) document and is further parsed and inserted into multiple data tables. The provisioning tool (PT) and its Y number of identical and individual sub-blocks called command generators (CG) were used to access and modify the digital exchanges. A detailed description of the PT and CGs is disclosed in Section IV.

Nodes and Interfaces
Fig. 3 illustrates a system for user provisioning in IP multimedia subsystem with the TMFE and IM already explained in Section III. The buffer (BFR) block creates a structured query language (SQL) query after a constant predetermined time towards the IM to fill up the buffer with up to date information. The volume of the buffer is limited. Another task of the BFR is to exchange data between the previous and next step of the provisioning flow. Meaning, if the provisioning tool has completed a task the BFR will know about this and update the preceding block which is the input mediation. It is also possible that depending on the task the update may contain not only the fact of a task completion but specific relevant data as well. The provisioning tool is the central component of user provisioning. In addition to users, it can also be used to manage services and internet protocol (IP) interfaces. To be more specific it is used to create and delete users, attach services to users (changing the user profile), manage long distance configurations (for example in the case of adding a client account to a router) and lastly it can be used as a source of relevant information for fault management. The current paper addresses the PT only from a user provisioning point of view. As mentioned, the PT consists of several command generators. The reason for there being more than one CG lies in load distribution. Each CG polls a table within PT for pending work orders after a predetermined interval. All pending operations are initially placed in a single table and after a command generator obtains a task it marks this as "in operation" so no other CG can acquire it. During the fetching of tasks the CG also updates its own status. This ensures knowledge of the command generators' operational ability. In addition the CG updates its status every 10 seconds, thus indicating it is not out of order. The CGs work on a first come first served basis and if one of them stops working it will not affect the others. The tasks are executed based on a command identifier (ID). Each command ID is attributed a specific script to run and monitor the outcome. If a step in the script is completed and the results are as expected the following step will start. In case there is an error condition the script will stop or future steps might be skipped.
After the CG has completed the script, the work order table in PT is updated accordingly and in if an error condition was met, detailed information about the problem and the step at which it was encountered is also added. It is also worth noting that depending on the nature of the error, a notification is sent to an employee for further processing and enhancement of the system. The command generator operates as the main entity making relevant changes and queries to multiple IMS nodes. With regard to user provisioning the CGs access the ASs using either proprietary protocols or protocols based on the 3 rd generation partnership project (3GPP) or internet engineering task force (IETF) specifications, the domain name system (DNS) server using TELNET and the HSS using lightweight directory access protocol (LDAP). PT can also address the database (DB) or the process execution (PE) block using SQL. The DB houses data regarding the nodes in the SPs network. This includes for example data about the location of the nodes with access information. Translation information on how to translate SQL commands into commands understood by different nodes is also held in the DB. PE is used as an extension of the PT to access the application servers in order to minimize lag during specific tasks that might otherwise cause overload in the CG-s. The application servers, one of the main components of the service delivery platform, house specific data regarding services delivered to customers and are described in [2,9]. As illustrated in Fig. 3, the ASs can be accessed for modifications from the CG, PE and the service portal (SP). The service portal is an operator created web portal that clients can use to manage their own users and services in the ASs. Naturally, not every possible modification within the ASs can be done using the SP but simpler and frequently used operations have been made accessible here. For example changing the account name or omitting a single service from a user are operations that do not necessarily need the interference of the operator. With respect to user migration the customers' administrator can create, delete or modify a user. The SP uses simple object access protocol (SOAP) or XML configuration access protocol (XCAP) to communicate with the DB and through that with the application servers. Direct access from the service portal to an AS can also be possible using XCAP if such a requirement is posed by the operator. In case the database server is used, at first the IP address and the existence of the clients' administrator is checked to rule out any false use. Another check is made regarding user rights to certify that the administrator has proper authorization to make changes. After necessary verification an SQL procedure is initiated to make the actual changes. In case there is a failure in any of the procedures a rollback is made to ensure there will be no accounts with partial configuration.
The configuration server (CS) holds the data of customer premises equipment (CPE) for download. For the sake of clarity it must be noted that CPE in this case encompass desktop phones and routers. The equipment configuration data is pushed to the CS either through the DB or directly from the AS every time the configuration file is modified. File transfer protocol (FTP) is used in both cases. The DB is used in cases where the application server cannot create a configuration file that is directly understood by the CPE and therefore needs extra modifying. Customer premises equipment configuration data is sent to the CPEs by the CS after they have rebooted or as mentioned previously, modifications to the configuration data is made. To update router data, the CS initiates a TELNET session into the specified router and makes the changes. For desktop phones first a session initiation protocol (SIP) notify is sent to the phone indicating that the configuration data has been changed after which the phone uses hypertext transfer protocol secure (HTTPS) to get the latest configuration.

Modifications and Possibilities for Enhancement
The provisioning system will undergo minor changes every time the operator decides to modify user provisioning. These modifications are mostly derived from executive decisions such as to provision all new users with a different set of properties compared to an earlier set. A similar situation might also occur when an interface, be it standardized or proprietary, changes. In both mentioned cases most modifications will have to be made to the provisioning tool since this is the central part of the system. The issue of technically enhancing the system for user provisioning is currently seen as two-fold. Firstly, the system is subject to ordinary hardware related constraints like the lack of disk space or memory on the servers. Hence, this is the least resource demanding way to improve the system. The second alternative for overall system enhancement is from within the PT. There is a possibility to add new command generators. In addition to simply adding new CGs, there is valid reason to believe that modifying the algorithm how the tasks are allocated within the PT to the, currently identical and individual, CGs will provide an increase in system performance. However, this has not yet been analyzed in more detail. According to the current design if the command generator is free and is polling for a new task it updates its status in the PTs database to "looking for a task" and also checks if any of the other CGs are doing the same. If not and there are available tasks to complete it will take the first one. After this, the status of the CG in the database is again changed to "in operation". In case there are several idling CGs and these are all looking for new tasks, the next task will be given to the first CG (the CGs are numbered from 1…Y with the lowest number having the highest priority). The deficiency with this kind of logic is the complexity of it and the constant operation with the PTs database.

Conclusion
There are a few common hurdles all incumbent telecommunications operators must overcome to migrate successfully to next generation networks. First of all the operator needs to have sufficient recourses for the transition, secondly the migration is closely tied to the way the company is run on an executive level and how the development of it is seen. Finally, from a technical aspect, the support systems used, meaning the OSS/BSS must also make the transition from legacy to NGN. The support systems that an operator is using have to enable user migration cases with different levels of complexity. Users may be migrated away from legacy networks such as the PSTN just as they can be migrated within an already running NGN service delivery platform like the IMS. The current paper establishes that a user migration and provisioning system to fit all of the above mentioned demands that is also scalable and reliable, is feasible and such a suitable solution is described. It must be noted however that, depending on their background, different operators have differing views of what an OSS/BSS for NGN should be comprised of and how it should function. These are all arguments for the creation of an all-encompassing and flexible provisioning system. To be brief, the incumbent systems that facilitate user provisioning to next generation networks have retained some functionality from the pre-NGN environment but have thrived in complexity due to the increased number of nodes and functionalities in modern SDPs. Previously, provisioning a user did not require an entry to be made for example in HSS or DNS as it does today with IMS. The overall performance of the provisioning systems is difficult to assess before actual usage. Naturally, some test migration scenarios or user provisioning can be run on the system before going live but these are usually on a small scale and often without the presence of adjacent systems. So in essence the PS must have qualities like scalability and adaptability to be able to remain in operation for a longer period of time. The evolution of technology and ideas demand that the PS does the same.