Huawei TELLIN CRBT Technical Proposal for AXB April, 2010 Table of Contents 1Overview ....................................................................................................... 4 1.1Project Overview ...................................................................................................... 4 1.2Solution Overview .................................................................................................... 4 1.3AXB CRBT Network Topology after expansion .................................................... 5 1.43M H/W Centralized IP basedCRBT solution .................................................... 5 1.53MURP Solution (3M for centralized IP based CRBT) ..................................... 6 1.6USDP Service Management Platform Overview .................................................. 6 2Huawei TELLIN CRBT Value Proposition .................................................. 7 2.1Abundant Application and Large Capacity ............................................................ 7 2.2Rich Experience on Interconnecting with MSCs ................................................... 7 2.3Carrier-grade CRBT System................................................................................... 7 2.4Rich Service Features ............................................................................................. 7 2.5Global Presence serves you anytime, anywhere .................................................. 7 3CRBT Solution Proposal ............................................................................. 8 3.1Solution Overview .................................................................................................... 8 3.1.1Networking Architecture .............................................................................................. 8 3.1.2RBT Trigger and Routing ............................................................................................ 8 3.1.3CRBT Signaling Flow .................................................................................................. 9 3.2CRBT provisioning ................................................................................................. 10 3.2.1CRBT provisioning flow in MSC-based solution ...................................................... 10 3.3CRBT Charge Solution .......................................................................................... 13 3.3.1CRBT charging flow ................................................................................................... 13 3.4Requirement ........................................................................................................... 16 3.4.1Requirement for O-MSC ............................................................................................ 16 3.4.2Requirement for HLR ................................................................................................. 17 3.4.3Requirement for Billing .............................................................................................. 17 3.5CDR Specification ................................................................................................. 17 3.6I2000 System of TELLIN CRBT ........................................................................... 17 3.7The End to End Solution of CRBT ....................................................................... 18 3.8From 2G to 3G ....................................................................................................... 20 3.9Introduction of TELLIN CRBT system .................................................................. 20 3.9.1Logical architecture .................................................................................................... 20 3.9.2Platform Description .................................................................................................. 22 3.9.3Platform Reliability ..................................................................................................... 27 3.10Service Features .................................................................................................... 28 3.11Service provisioning and charging ....................................................................... 28 4Equipment Dimensioning ......................................................................... 28 4.1CRBT Calculation for Full IP Based ..................................................................... 28 1.1.2List of Service Requirement and Traffic Data .......................................................... 28 1.1.3Calculation result ....................................................................................................... 29 4.2CRBT Calculation for Upgrade the Existing System .......................................... 32 1.1.4Power Requirements ................................................................................................. 32 5Glossary ..................................................................................................... 33 6Appendix I .................................................................................................. 34 1Overview 1.1Project Overview This document is the technical proposal for the provision of a TELLIN CRBT system to AXB by Huawei Technologies Co., Ltd. (hereinafter referred to as HUAWEI). Huawei has comprehensively understand AXBs existing CRBT solutions challenges:: 1.The existing V5.0 CRBT (deployed in 2005) is constructed based on the HP platform. V5.0platformcannotprovidethemorediversityfeaturestomeetthemarkets need.HP Hardware has expired as well as maintenance cost is getting higher. 2.The CRBT service in AXB is growing very quickly so that the capacity needs to expand. 3.The existing AIP is dedicated in narrow board processing, It cant meet the futures IP trend solutions need. According to this,. Huawei proposes a centralized solution to meet the AXBs requirements: This centralized solution aims at the following key points: 1.Upgrade the existing V5.0 CRBT software platform to V6; The proposed V6 is able toprovide excellent features to attract more customers and Increase AXBs ARPU. . 2.In this project , According to AXBs request , Huawei proposed 1M Hardware and software expansion,1M Hardware swapfrom HP to ATAE as well as the platform software upgrade from V5 to V6. 1.2Solution Overview A complete CRBT solution consists of two major parts. One is service trigger and the other is service platform. Servicetrigger is to realizehowtoestablish thevoice trunk connectionwith service platform when the called party is a CRBT subscriber. As for a CRBT call, the network will identify the called party is a CRBT subscriberand thenbuild connection with the service platform to play CRBT to the calling party. We propose CRBT trigger solution as the proper one and introduce it with details in section 3.2 below. Service platform is where functions are provided. It mainly provides playback of CRBT tocallingparty,servicefeatures,servicesubscriptionandservicecharge.Huawei provides TELLIN CRBT system as the service platform in the proposed solution. 1.3AXB CRBT Network Topology after expansion 1.43M H/W Centralized IP basedCRBT solution Following is theProposedCentralized IP based CRBT solution architecture : This is a new ATAE solution to take over theold HPplatform , Management node and Call node will be Centralizedin Uday; 1.53MURP Solution (3M for centralized IP based CRBT) For the CRBT , Both of the voice channelsand signaling channels are conveyed by IP. The BICC capacity subscriber is 3M , andsignaling type will be BICC, software capacity is 2M; The main parameters based the traffic model are figured out as following. The 3M CRBT traffic parameter is in the following : No.Item2M Subscribers Capacity for URP 1BICC Msg. Qty. per second3675 2N-Band VP Chanel Qty. BICC12960 3RBT Call CAPS (BICC)500 4Management Call CAPS (BICC)25 5Signaling Bandwidth21.03Mbps 6Voice Bandwidth819.75Mbps All the MSC should have capability to read SS_Code data in SRI_Response and trigger split IAM. For the internal flow in CRBT system, the load balance will judge which server will deal with the CRBT request. 1.6USDP Service Management Platform Overview InTELLINCRBTsystem,theservicemanagementandoperationplatformadopts openandloosely-coupledstructure.ItconsistsofthreelayersincludingUSDP Platform, USDP API and Application Software from bottom to up. USDP Platform implements all the service logics and is the running platform. It also providestointerconnectwithIN/Billingsystemsforchargingfunctions.Basedon USDPPlatform,theservicelogicsareencapsulatedintoUSDPAPIs.TheseAPIs adoptSOAPprotocolwhichareinternationalopenstandardandeasilyusedfor development.ThetoplayerisApplicationSoftwarewhichisdevelopedwithUSDP APIs and it contains WEB/SMS/IVR/etc portals & enhanced features. Through this open structure, it can bring following major benefits for AXB: BesidesHuawei,AXBorotherthirdpartiescanalsobeengagedtodevelopuser interfaces easily with APIs. Improve the responding time for the customization of user interface. Easily make new access available to the CRBT service. IfitisSPtobuildtheuserinterface,SPcanpromoteCRBTservicetogetherwith AXB. 2Huawei TELLIN CRBT Value Proposition 2.1Abundant Application and Large Capacity Huawei started CRBT service R&D since 2002 and launched the first commercial site in China Mobile Shanghai on 17th May, 2003. Till now Huawei TELLIN CRBT system has been selected by more than 40 AXBs such as China Mobile in China, AIS in Thailand, MEGAFON in Russia, EMTEL in Mauritius, OI in Brazil, OPTIMUS in Portugal etc in more than 30 countries. The total capacity of Huawei contract CRBT worldwide has reached 100 million by Sep. 2005.. As Huawei has cooperated with so many AXBs, the rich experience can also help Huawei to fulfill this project successfully. 2.2Rich Experience on Interconnecting with MSCs Huawei TELLIN CRBT system has already interconnected with MSCs from most major vendors that include Ericsson, Nokia, Alcatel, Siemens, Nortel, Lucent etc. It provides Huawei rich experience to handle variety of network situation and propose most suitable solution for AXB. 2.3Carrier-grade CRBT System CRBT is the first content related voice service ever involved in the call flow. This kind of involvement fundamentally differentiates CRBT service from other traditional IVR services. IP is the core module of any CRBT system, as it directly interconnects with MSC. This requires IP to be as reliable and steady as the tandem MSC. And unlike other IVR service, CRBT is call related service, so that it also requires the IP to have massive exchange ability and carrier-grade stability. Huawei TELLIN CRBT system is designed based on Huawei NGN softswitch. Therefore, carrier-grade reliability is ensured by Huawei CRBT system. 2.4Rich Service Features Beside carrier-grade hardware platform, Huawei TELLIN CRBT system also provides rich service features: WEB/IVR/SMS portal, caller-based CRBT, time-based CRBT, caller group management, personal library, period of validity etc. With these abundant features, it can make AXBs CRBT service more competitive, easily used and more interesting so that it can attract more subscribers. 2.5Global Presence serves you anytime, anywhere 8 regional headquarters, 55 branch offices outside China with 3-level customer service system (HQ, Regional, local) guarantee the most effective and timely technical support for deployment and maintenance of the whole system. 3CRBT Solution Proposal 3.1Solution Overview 3.1.1Networking Architecture The signaling between MSC and CRBT are BICC protocol based IP network, to support the called party recognition on calling party switch, the network entities of different MSCs should have capability of reading SS_code from SRI response message and should be able to trigger split_IAM. 3.1.2RBT Trigger and Routing The RBT solution can support intelligent user and non-intelligent user. Register RBT subscribers SS_CODE(254) in HLR. When A call B, VMSCa will send SRI to HLR to get SS_CODE(254) of B. VMSCa will find that B is RBT subscriber and route the call to VMSCb. First VMSCb pages the called party, if the status is idle, VMSCa will originate a leg to connect RBT platform with prefix. Afterwards RBT platform plays the back tone of B to calling party. If called party answers, VMSCa will disconnect the link to RBT platform. Then the calling party and called party can communicate. 3.1.3CRBT Signaling Flow The O_MSC Server receives a call request from the caller, and then queries for the called roaming address and obtains the RBT subscription information of the called party. The O_MSC Server routes the call to the T_MSC Server based on the roaming number. After paging the called party, the T_MSC Server instructs the phone of the called party to ring and sends a notice to the O_MSC Server if the called party is idle. The O_MSC Server initiates a call to the URP. The URP triggers the RBT flow and plays the RBT specified by the called party to the O_MSC Server. The O_MSC Server transparently transmits the RBT to the calling party. After the called parity picks up the phone, the O_MSC Server releases the call to the URP. The conversation begins. 3.2CRBT provisioning 3.2.1CRBT provisioning flow in MSC-based solution MSC-based solution is the solution to upgrade MSC & HLR to provide triggering method for CRBT service. Normally SS_CODE is used to mark the attribute of RBT service in HLR. The detail case by case provisioning and charging description will be available in Apendix I. Network diagram OSSCRBTHLRCRMWEB/IVR/SMSInterface IIIInterface IInterface II CRBT provisioning system provides several convenient ways for end user to subscribe or unsubscribe CRBT service, for example: CRM system, WEB/IVR/SMS etc. This diagram shows that all the related entities in the CRBT provisioning flow. There are 3 entities and 3 interfaces. The 3 related entities are explained as follows: HLR --- to store information (include CRBT service flag) of RBT user OSS --- to provide interface between CRBT system and HLR CRBT --- to provide CRBT service The 3 related interfaces are explained as follows: Interface I --- provided by CRBT to OSS, usually it is HTTP messages. Interface II --- provided by OSS to CRBT, usually it is CDR or HTTP messages. Interface III --- provided by HLR to OSS, it is private interface provided by HLR vendor. The line arrow identifies the direction of message through that interface. CRBT will only provide the interface between OSS and CRBT system. Its OSS responsibility to interactive with other devices (e.g. HLR). Starting from CRM system--- real-time 1. Subscribe flow OSSCRBTHLRCRM21 When end user goes to business hall or dials the number of call center, he/she requests to subscribe to CRBT service, the provisioning flow as follows: OSS firstly accepts the request from CRM system, and OSS will invoke HTTP API (Interface I) to request CRBT to subscribe CRBT service for end user. When OSS invoke the subscribe HTTP API, OSS must pay attention to the parameter: usertype, it is important to CRBT system. After CRBT finish the operation successfully, OSS need to send mark request (Interface III) to HLR. In this flow, all the interfaces should work in real-time. 2. Unsubscribe flow--- real-time OSSCRBTHLRCRM12 When end user goes to business hall or dials the number of call center, he/she requests to unsubscribe to CRBT service, the provisioning flow as follows: OSS firstly accepts the request from CRM system, and OSS will send unmark request (Interface III) to HLR. After HLR finish the operation successfully, OSS will invoke HTTP API (Interface I) to request CRBT to unsubscribe CRBT service for end user. In this flow, all the interfaces should work in real-time. Starting from CRBT system --- real-time OSSCRBTHLRWEB/IVR/SMS12 Using IVR/WEB/SMS etc methods, end user can subscribe/unsubscribe CRBT service, the provisioning flow as follows: CRBT system accept users request firstly, and then CRBT system will send HTTP request (Interface II) to OSS. After receiving the request, OSS will deal with end users request and send mark/unmark request (Interfaces III) to HLR. Then OSS returns the success response to CRBT. CRBT will finish the subscribe/unsubscribe flow. In subscription flow, OSS must pay attention to the parameter: usertype, it is important to CRBT system. Exception dealing For any exception, OSS needs to send rollback request to the related entities before the exception point, for example: When end user goes to CRBT system by IVR/WEB/SMS etc, he/she requests to subscribe/unsubscribe to CRBT service CRBT system send request to OSS OSS will send mark/unmark request to HLR, but HLR isnt working normally, e.g. time out to response, or return failure code. So OSS should rollback all the processes which was completed before, and return failure code to CRBT system. 3.3CRBT Charge Solution 3.3.1CRBT charging flow Charging feature is providing a way for CRBT system to charge the subscriber based on the user type (Prepaid or Postpaid) including charging based on download or monthly fee of CRBT function. Network diagram CRBT subscriber can download songs through SMS/WEB/IVR etc. This diagram shows that all the related entities in the CRBT charging flow when CRBT subscriber downloads songs. There are 3 entities and 2 interfaces. The 3 related entities are explained as follows: OSS/RBI --- to provide non-real-time charging functionality for postpaid subscriber CRBT & Charge-GW --- to provide CRBT service. This device which usually been used to provide charge interface with external entities, such as OSS or IN. IN --- to provide real-time charging functionality for prepaid subscriber The 2 related interfaces are explained as follows: Interface I (CDR) --- between Charge-GW and OSS, usually it is CDR. Interface II (HTTP) --- between Charge-GW and IN, usually it is MML protocol. Charging flow Charging flow for postpaid subscriber Comment [W1]: When postpaid subscriber download songs, the charging flow as follows: The CRBT system will write CDR for charging a post paid user. The format of CDR is as attached below. Charging flow for prepaid subscriber When prepaid subscriber download songs, the charging flow as follows: CRBT system should charge for users download operation before downloading songs to his personal library, so CRBT system will send MML request to IN to deal with charging operation. Check CDR for pre paid users CRBT can also write a check CDR for the pre paid users. After IN charging is successful, CRBT will record the charging information in CDR and this can be ftpd to RBI for reconciliation. Identification of pre paid and post paid users The CRBT system will identify if the user is pre paid or post paid based on number segment concept. That is, IN the CRBT system, we can configure the MSISDN segment which belongs to pre paid numbers and the number segment which belong to post paid users. Based on this, CRBT system will send correct charging request. Monthly fee charging:- In the current system, month fee is calculated by IN. In the new solution, IN will not calculate month fee. RBTwillcalculatewhentochargetheusermonthfeefromnextmonth onwards. Comment [W2]: USDP MMLINSMP Comment [W3]: USDP check CDRIN Comment [W4]: New solution IN Whenaprepaiduseriseligibleformonthfeecollection, RBTwillsenda MML request to IN. Whenapostpaiduseriseligibleformonthfeecollection,RBTwillwrite CDR. Monthly fee model:- InCRBTsystemwecanconfigurethelengthofabillingcycle.Soifweconfigurethe billing cycle day as 7, the system will behave as follows. If the third charge try also fails, the user will be unsubscribed from the system. The number of retries can also be configured. 3.4Requirement 3.4.1Requirement for O-MSC Following the requirement for O-MSC 1.It can distinguish whether the call is RBTs call, according to the SS_CODE(254) in HLR. 2.It should support BICC protocol. For RBTs call, it should 3.First it pages the Called Party, if the status isnt idle, it will play the corresponding voice and release the call. Otherwise, just to continue. 4.If the status is idle, it will originate a leg to link the RBT platform, and RBT platform plays the back tone to the calling party. 5.When the called party answers, it will disconnect the link to RBT platform. Comment [W5]: 6.When O-MSC connected to RBT system, bi-direction voice channel should be provided so that RBT platform can get user key pressing. 7.All the MSCs and GMSCs have been upgraded to be able to support BICC protocol. 8.Terminated MSC should provide information for call waiting, call forwarding, announcement, so that the RBT system can distinguish all this case to do special operation. 9.MSC deal with all the charging for the call originated from POS subscriber or terminated to POS subscriber. 3.4.2Requirement for HLR HLR should save SS_CODE(254) for RBT subscriber. 3.4.3Requirement for Billing 1.The Billing system should charge the Postpaid subscriber for the CRBT service according to CRBT CDR. 3.5CDR Specification RBT CDR bills are generated by USDP. Different bill type has different structure, and the bill type is recognized by the first several letters of bill file name. 3.6I2000 System of TELLIN CRBT I2000 isusedtohandleeachelementssuchCRBT systemandprovidesthefollowing function. Uniform topology management The devices and structure of the entire network are displayed in the topology view. The topology view provides the entrance for maintaining and managing the NEs. Rich configuration management The I2000 provides the function of querying for and modifying the following data: Software configuration Hardware configuration Service configuration Traffic Overall performance analysis Comment [W6]: ACMACM Comment [W7]: The I2000 provides the function of collecting and displaying the performance data and the performance alarm; thus, the users can understand the system running in time. Centralized fault management The I2000 monitors the alarms of the entire network in real time, supports the sound and light alarms, and informs the users in various modes. Powerful security management The I2000 provides the secure and reliable policies for the following: Authorizing and authenticating users and user groups Encrypting the password The I2000 is located at the NE management level, all the NE management level systems provided by Huawei such as CRBT, SMSC, MMSC, MDSP, WISG, IN and so on, can be handled by I2000. The I2000 provides the interface for the connection of the NMS (Network Management System) via SNMP protocol. NMS is higher level system compared with I2000. The following figure shows the architecture of I2000 for AXB. Because AXB has already had I2000 server, so for the new added system, such CRBT, MMSC and WISG, only license is necessary, which is used to get permission to be handled by I2000. The existing i2000 server is V440 2CPU (1.28GHZ) and 4G Memory, which can handle about 700 NE(network elements). 3.7The End to End Solution of CRBT The current architecture is shown as follows, For MGW/MSC01: 4*E1 for signaling, 46*E1 for voice channels; For MGW/MSC02: 8*E1 for signaling, 80*E1 for voice channels; For MGW/MSC03: 4*E1 for signaling, 45*E1 for voice channels. After Upgradedby URP, the physical connection between URP and MGW/MSC is based IP network. The follow figure shows the architecture. Actually, the middle equipment is the centre router between URP and MGW/MSC. Because all the MGW and MSC will be upgraded to IP supported, the MGW and MSC will be connected with the centre router by IP network also. The previous T-MSC will become the pure Trunk MSC without any MGW, so the only oneMSCisproposedtoconnectwithCRBT,whichisG-MSCwithMGW.Allthe signalingchannelswillconnectionwithG-MSC,whileallthevoicechannelswill connect with the MGW. The bandwidth between URP and MSC is 21.03Mbps; The bandwidth between URP and MGW is 819.75Mbps. 3.8From 2G to 3G The solutions of CRBT system is completely IP based, the protocol for CRBT is BICC. For the current application and services, whatever 2G supports, 3G can also support. However,iftherearenewtypesofservicerequirement,forexample,videoRBT, someadditionalhardwaresuchasmultimediaboardswhichsupportvideoservice and video interface gateway (VIG) will be needed. Another example is Video Conference Service, which is a popular service provided in 3G network. Since this is a new type of service compared with the current IN application, additional hardware, software and protocol for this service are necessary, which will lead to additional cost. All in all, the current features of CRBT if provided in 2G network will be supported in 3G network totally. 3.9Introduction of TELLIN CRBT system 3.9.1Logical architecture Following is the logical architecture of Huawei TELLIN CRBT system, it contains switching module, call control server, user profile, content library and service management and operation platform. And they will be introduced one by one in section 3.3.2. TELLIN CRBT system Logical Architecture TELLIN CRBT Management Site CRBT call process flow To process a normal CRBT call, the interaction between each module of Huawei TELLIN CRBT system is as follows: MSC sends IAM to switching module. After processing IAM, switching module returns ACM/ANM and then sends a request to call control server through TCP/IP. Call control server translates the received message and invokes the call process logic, then it will send request with MSISDN of calling party and called party to user profile to query content ID. User profile returns the related content ID. And it is returned to switching module by call control server. After getting the content ID, switching module checks its cache firstly, if the related content is already there, it will plays it to MSC directly. Otherwise switching module sends request with content ID to content library to query the related content file. After getting content file returned from content library, switching module plays it to MSC. 3.9.2Platform Description The Signal and Switching Module in CRBT system is also called URP8100 (Universal Resource Platform). It provides the service trigger, signaling transparent transmission, signal tone detection, and call out functions of the CRBT service. The URP8100 contains two parts: Media Gateway Controller (MGC) and the Media Gateway (MGW). URP8100 MGC consists of the call control and media resource component. The following figure shows the structure of the URP8100. Structure of URP8100 a. MGC The MGC is the call control and media resource part of the URP8100, and is the crucial part. Its hardware is developed based on Huawei Open Standards Telecom Architecture (OSTA) platform and its software is developped based on Distributed Object-oriented Programmable Realtime Architecture (DOPRA) platform Hardware Physically MGC is composed of two parts. One is OSTA frame that forms the host of URP8100 MGC, providing the functions of service processing and resource management. The other is Back Administration Module (BAM) that builds up the background of URP8100 MGC, offering the OAM functions. Software The software system of MGC is composed of host software and terminal Operation and Maintenance(OAM) software The host software runs on the main processor of MGC and is designed to provide functions including signaling and protocol adaptation, call processing, service control, media resource management, media resource processing The terminal OAM software runs on the BAM and the workstations, along with the host software, it supports maintenance personnel to implement the following functions on the host including data management, equipment management, alarm management, performance measurement, signaling trace b. MGW The MGW is the TDM switching centre of the URP8100. It has a TDM switching capacity of 256K. Hardware Classified by functions there are four types of frames in MGW. The first one is main control frame that manages and maintains the entire equipment and accesses and processes services. The second one is service frame that provides the service bearer processing function. The third one is central switching frame that provides multi-frame cascading function when there are more than three frames. The fourth one is extended control frame that provides connection management and control function only, not any bearer service access or processing function. It is configured only in full configuration of the URP8100 MGW. Software The MGW software system consists of two main parts: Host software and Client software. The host software is responsible for bearer service processing, lower-layer base software and hardware management. The Client software and BAM module of the host software, esigned in client/server infrastructure, are responsible for routine maintenance and management of the host machine. The URP8100 has following main features: I. Abundant Media Resource Capabilities The URP8100 can provide rich narrowband resources for PSTN and PLMN, and rich broadband media resources for NGN and 3G networks. The resources include: Receiving and sending Dual Tone Multi-Frequency (DTMF) signals Sending signal tones Detecting signal tones Sending record announcement Recording G.711/G.729/G.726/G.723 voice codec In addition, the URP8100 provides functions such as subscriber interaction script, dynamic loading and management of media resources, and multi-lingual support. II. Large Capacity and High Integration Large capacity At the full configuration, the URP8100 supports: BHCA of 8,000k 256K switching capacity. 38,400narrowbandorbroadbandmediaresourcechannelsand60,480TDM trunks at the same time. High integration Each board can provide 240 narrowband channels Or 240 broadband channels Or two STM-1 optical interfaces of 126 E1 III. High Security To ensure the security of the network and all valid subscribers, the URP8100 equips a perfect security design against malicious attacks, illegal registrations, anonymous calls, wiretapping, stealing accounts and other illegal acts. Security Data Backs up data between active boards and standby boards in real time. Automaticallybacksupofthedatabaseoftheactiveprocessingunittoaflash memory. Security in the Aspect of Operations and Maintenance Verify both account and IP address in login. Manages multiple levels of subscriber authority. IV. Excellent Performance Measurement Functions The URP8100 provides excellent performance measurement (PM) functions, and supports many PM entities and customized PM tasks. The URP8100 uses lists and graphics to display the performance data in real time to fully reflect the traffic load status and the operation of itself. Several traffic measurement items can be combined according to your requirements. Items can be measured individually or together at a time. V. Convenient and Practical Operation and Maintenance The URP8100 provides convenient and practical operation and maintenance (OAM) functions as follows: Flexible and Diversified Management Modes The terminal system of the URP8100 works in a distributed Client/Server structure, providing many maintenance modes such as Graphical User Interface (GUI) and MML. The URP8100 can be accessed at the same time by multiple local and remote clients. Visualized Graphical User Interface The URP8100 provides OAM interfaces by using a unique navigation tree technology. In this way, many MML features and GUI advantages are retained, such as visualized, simple and quick to use, easy to access NMS, and easy to memorize. In addition, the URP8100 provides vivid graphical network component topology view and equipment panel, enabling visualized operation. Optimal Call Tracing, Signaling Tracing, Interface Tracing and Message Interpretation Functions A software tool of signaling analysis, which is independently developed by Huawei, is built in to offer customers with powerful fault analysis and location features. Realtime Fault Management Capability The system receives and displays network equipment fault report in real time, so that the maintenance personnel can diagnose the fault source rapidly and precisely and take proper measures to recover the system from the abnormal service. VI. High precious clock The URP8100 has stratum-2 and -3 clocks. It provides standard clock interfaces. It can retrieve clock reference source from BITS, and 8-kHz E1/T1 line clock through software control, ensuring the clock reliability of the system 1. Call control server Call control server contains CTI/FEP server and UI server. CTI/FEP server is to change messages of each CRBT phone call from switching module into internal messages and transfer them to UI server. UI server is to decide which ring back tone (content ID) should be played according to the information received. 2. User profile All the service related user data are stored in user profile for querying by call control logic and it adopts Oracle 9i database. 3. Content library Content library stores all content resource being used in CRBT service providing internal TCP/IP interface for voice resource system to query the content. 4. Service management and operation platform 1)Figure & Functions Service Management and Operation Platform This platform provides necessary functions for the management and operation of the CRBT service. End-user can use this platform to manage their personal profile. Content provider can use this platform to upload and manage content resources. AXB can use this platform to implement the management and operation of the CRBT service. This platform also provides various external interfaces to offer different access for the management as well as to integrate with billing or other back office system. As for more details of service features, please refer to Annex A. 2)Open Software Structure Based on USDP Service Management and Operation Platform Software Structure The diagram above shows the three layers of the service management and operation platform of Huawei TELLIN CRBT system. The bottom layer is USDP Platform. It implements all the CRBT service logics and is the running platform. It also can interconnect with IN or Billing system to charging for prepaid and postpaid subscribers. Above USDP Platform, it is the USDP API layer which is based on SOAP protocol. This layer encapsulates the capability set of USDP Platform into APIs. As SOAP is an international open standard, it is easily used for developing service. The top layer is CRBT Application Software which provides service features including WEB/IVR/SMS/ portals and enhanced features to end-user, AXB and CP. It is developed through calling USDP APIs. As these three layers are separate and independent with each other, this open and loosely-coupled architecture will bring tremendous flexibility to the CRBT service: a) Improve the responding time for the customization of user interfaces User interface can be changed constantly AXB can choose to let Huawei to provide some accesses like IVR/SMS/WEB andbyitselforwiththehelpofthirdpartytodevelopotheraccesseslike WAP/USSD etc. b) Easily make new access available to the CRBT service When new access technology (forexample -i-mode) come out in the future, CRBT service platform can support this new access without any modification c) If SP can build the user interface, SP will be able to promote the service together with AXB. In this project, based on AXB requirements, Huawei will provide USDP Platform and portals including WEB accesses. 3.9.3Platform Reliability 1.Platform Redundancy Powersupply,signalinglinkandnetworkequipmentshavebackupstoavoidpossible single-point fault. The URP8100adoptsactive/standbymode,load sharingandredundancyconfiguration for the boards; optimizes fault detection and isolation techniques of the boards and the system to improve the maintainability of the whole system. The URP8100 adopts alayeredandmodularstructurewithperformanceprotection,errortoleranceand fault monitoring. The URP8100 provides four levels of overload restrictions, dynamic code adjustment mode and traffic control to fully ensure the reliability of the system. In CRBT system, all servers adopt HP/IBM PC server or mini-computer. If using PC server, 2 PC servers are adopted with active-standby structure or load-sharing mechanism. If using mini-computer, the dual system can assure the high reliability. User profile database adopts disk array that works with RAID mechanism. Networkmanagementsystem HUAWEICRBTsystemadoptsI2000network managementsystemwhichcanbeaccessedthroughstandardSNMPprotocol. I2000 monitor all units of CRBT system in real time and provides fault management function. 1.Faults Handle Signaling link fault If single signaling link fault occurs, the backup one will still work and CRBT system can communicate with MSC normally to play CRBT. If all signaling links has faults, the MSC will detect it and revert back to the standard ring back tone. URP fault If single board has fault, the backup board will take over its service so that CRBT can still be played normally. If the whole URP is down, the MSC will also detect it and revert back to the standard ring back tone. CRBT call processing servers and database fault Comment [W8]: ??? If the active server fails, its work will be switched to the standby server and will not affect playing of CRBT. If both active server and standby server has fault and make the CRBT call processing flow fail, URP will detect it through getting no response or failure and sends REL to release the trunk with MSC. And then MSC will play the standard ring back tone only. Service management and operation platform fault If single server fails, the backup one will take over its work. If the whole platform has fault, it will affect all service management functions like subscription, charging etc, but it will not affect the CRBT call flow as it is not involved. Network fault management If any fault mentioned above occurs, it will be reported to I2000 system and raise related alarm to inform the system administrator. And also I2000 provides to monitor other faults of CRBT system. 3.10Service Features TELLIN CRBT system provides for AXB will cover all the current system features and functions. The detail of features and functions can be referred to TELLIN CRBT function list for AXB. 3.11Service provisioning and charging TELLIN CRBT system provides multi ways for end user to subscribe or unsubscribe CRBT service. These ways includes starting from CRM or starting from CRBT system. TELLIN CRBT system supports two kinds of service charge type. One is service monthly fee which is charged for a CRBT subscriber each month with fixed expense. The other is fee of purchasing CRBT which is charged for a CRBT subscriber every time when he downloads a CRBT from the system. TELLIN CRBT system can supports both POS subscriber and PPS subscriber. The details of charging and provisioning are already discussed in the preceding chapters. 4Equipment Dimensioning 4.1CRBT Calculation for Full IP Based 1.1.2List of Service Requirement and Traffic Data According to the requirement of AXB, we have the following basic traffic model: Basic Service Parameters ITEMVALUE BICC Subscriber3,000,000 MSCErlper0.03 Service Traffic Data Average Holding Time (s)Length of Ring Time (s) 9020 Other Data ITEMVALUE BICCMsg.Qty.perManagement Flow7 BICC Msg. Qty. per Call Flow7 Average Length of BICC Msg. (Byte)300 MSC-Erl per Sub0.03 Ratio of Call flow0.05 MHT of Management Call (S)120 Ratio of Internet Sub.20% Item 3M Capacity (OPS per second) Value15 This OPS (Operation per Second) is the total operation quantity per second of subscription service, un-subscriptionservice,managementsetting,managementdownload,servicesactiveand deactivate, RBT subscriber visiting WEB portal and non-RBT subscriber visiting WEB portal. 1.1.3Calculation result The following calculation is for is the calculation result. (RBT Platform BHCA per Sub. )= ((MSC-Erl per Sub.)/MHT)*3600* (Percentage of called traffic) =0.03/90*3600*50%=0.6 Subscriber Calledtrafficper subscriber 0.015 RBT Call CAPS (BICC) Call CAPS = RBT Sub.Qty. * Erl (average Erl of each sub.)/ MHT =3*600000/3600 =500 Management Call CAPS (BICC) Management Call CAPS = RBT Call CAPS * Percentage of Management Call =500*0.05 =25 BICC Msg. Qty BICCMSGQtypersecond=ManagementCallCAPS*BICCMsg.Qty.per Management Flow + RBT Call CAPS* BICC Msg. Qty. per Call Flow =(25+500)*7 =3675 VP Channel Qty. BICC N-Band VP Channel Qty. BICC = 120*Round(((RBT Call CAPS (BICC))* (Ring Time) + (Management Call CAPS (BICC))*(MHT of Management))/ (Load of Internal E1 (For VP CH.)/120))= 120*Round((500*20+25*120)/120)=12960 Signaling Bandwidth SignalingBandwidth (Mbps) (RBT Call CAPS+Management Call CAPS) * BICCMsg. Qty. per Call Flow * Average Length of Signaling Message*8/ Bandwidth signaling Utilize Ratio /1024/1024= (500+25)*7*300*8/0.4/1024/1024=21.03 ParameterValue Encoding Bandwidth45.2 Bandwidth Signaling Utilize Ratio0.4 Voice Channel Bandwidth VPChannelsBandwidth(Mbps)=(RBTCallCAPS*Ringtime+ManagementCall CAPS*MHTofManagementCalls)*EncodingBandwidth*1024/VPChannel Bandwidth Utilize Ratio /1024/1024 VP channels Bandwidth (Mbps)= (500*20+25*120)*45.2*1024/0.7/1024/1024 =819.75 ParameterValue Encoding Bandwidth45.2 VP Channel Bandwidth Utilize Ratio0.7 ATAE calculation formulas are as follows, a,CTI/FEP:2*Roundup (Call CAPS/800 + Management CAPS*MHT/8000) =2*Roundup(500/800+25*120/8000) =2 b,PortalBoardNumber=2*Roundup((BusyhourOPS)/(PerPortalCapacity OPS)*(Management Ratio)) =2*Roundup (15/60) =2 c,USDP Board Number = 2*Roundup ((Busy hour OPS)/(Per USDP Capacity)) =2*Roundup(15/44) =2 USDP board number has been increased to 5 to create more connections towards IN. d, VXML Board Number = Roundup(Management CAPS*(Transaction per Management CAPS)/Per VXML Capacity) =Roundup(25*15/80) =4 DB Board Number calculation Management DB/Call DB/Report DB TPS is including Call TPS and Management TPS. 1.Call TPS (Total subscribers)*(BHCA per sub)/3600*(transactions per CAPS) =3000000*0.6/3600*103 =51500 Transaction per CAPS is 103. 1.Management TPS: OPS* (Transaction per operation) =15*2653.3 =39799.5 The OPS is 15. Transaction per operation is 39799.5 So, the total TPS is39799.5+51500=91299 If the TPS is less than 95001, the DB board number is 2. But DB board number has been increased to 7 to cater enhance features and to co-host report server. The following table is the calculation result. No.ItemFor 2M Centralized 1FEP/CTI ATAE2 2Portal ATAE2 3VXML board2 4USDP ATAE5 5Management DB/Call Processing DB/Report DB 7 6Call DB/Management DB Storage 16*300Gb 7File Server Storage (URP for CRBT) 16*300Gb 4.2CRBT Calculation for Upgrade the Existing System 1.1.4Power Requirements For the totally new CRBT platform of 3M subscribers capacity DC Power (W) Total20,950 CRBT1,341 URP9,329 Rack1,060 NE9,220 Considering AXB required, Huawei proposal suggest that power can last 8 hour based on the output above. 5Glossary URPUniversal Resource Platform CRBTCustomized Ring Back Tone CTIComputer-Telecommunication Interface HLRHome Location Register INIntelligent Network BICCBearer Independent Call ControlIPIntelligent Peripheral ISUPISDN User Part MAPMobile Application Part MHTMean Holding Time MSCMobile Switching Center SCPService Control Point SMPService Management Point Sub.(RBT) Subscriber USDPUniversal Service Development Platform SPService Provider NMSNetwork Management System 6Appendix I Register Prepaid Register Prepaid Step1. Subscrlber send reglstrutlon request by sms/lvr/buslness hull Step2. RBT system lnsert subscrlber lnfo ln RBT DB Step3.RBT send provlslon request to OSS Agent Step4. OSS Agent knows the correct HLR from MSISDN/IMSI serles und sends MML commund to udd SS_code Step5.u) HLR sends response success/fullure. lf successful RBT system proceed b) lf HLR provlslon fulls, RBT rollbuck, log generuted Step6. If HLR provlslon successful RBT send churglng request to SMP (IN) vlu churglng gutewuy Step7.u) lf churglng full , RBT rollbuck ln HLR und RBT DB, log generuted b) lf churglng successful then proceed to generuted CDR Deregister Prepaid (System Step1. Subscrlptlon fee dute urrlves for CRBT subscrlber, CRBT system sends churglng request over MML (from churglng gutewuy to IN-SMP) for 3 consecutlve duys. Step2. u) If churglng ls successful subscrlber next blll dute ls upduted ln CRBT DB b) If churglng fulls for 3 consecutlve duys, then CRBT system proceed todereglster the subscrlber.RBT system chunges stutus of subscrlber ln DB Step3. RBT send request to OSS Agent Step4. OSS Agent knows the correct HLR from MSISDN/IMSI serles und sends MML commund to delete SS_code Step5.u) lf HLR de-provlslon fulls, RBT rollbuck, loggeneruted b) lf successful RBT system generutes CDR Deregister Prepaid (User Step1. Subscrlber send dereglstrutlon request by sms/lvr/buslness hull Step2. RBT system chunges stutus of subscrlber ln RBT DB Step3.RBT send request to OSS Agent Step4. OSS Agent knows the correct HLR from MSISDN/IMSI serles und sends MML commund to delete SS_code Step5.u) lf HLR de-provlslon fulls, RBT rollbuck, log generuted b) lf successful RBT system generutes CDR Monthly Fee (Subscription Fee) Process Flow for Prepaid Subscriber Step1. Subscrlptlon fee dute urrlves for CRBT subscrlber, CRBT system sends churglng request over MML (from churglng gutewuy to IN-SMP) for 3 consecutlve duys. Step2. u) If churglng ls successful subscrlber next blll dute ls upduted ln CRBT DB b) If churglng fulls for 3 consecutlve duys, then CRBT system proceed todereglster the subscrlber, RBT system chunges stutus of subscrlber ln DB Step3. RBT send request to OSS Agent Step4.OSS Agent knows the correct HLR from MSISDN/IMSI serles und sends MML commund to delete SS_code Step5.u) lf HLR de-provlslon fulls, RBT rollbuck, loggeneruted b) lf successful RBT system generutes CDR Deregister Prepaid (System Initiated) CRBT Prepaid Subscriber Lifecycle Monthly Fee (Subscription Fee) Process Flow for Prepaid Subscriber Prepaid Download Charging Request sending Flow Prepaid Subscriber Download Fee Charging Process Flow Step1. Subscrlber send downloud request by sms/lvr/buslness hull Step2. RBT system sends churglng request over MML (vlu churglng gutewuy) to IN SMP Step3.u) If churglng ls successful, the song ls downlouded ln the personul llbrury of the subscrlber. CDR ls generuted b) If churglng ls not successful, the song downloud fulls. Register Postpaid Register Postpaid Step1. Subscrlber send reglstrutlon request by sms/lvr/buslness hull Step2. RBT system lnsert subscrlber lnfo ln RBT DB Step3. RBT sends request to OSS Agent Step4. OSS Agent knows the correct HLR from MSISDN/IMSI serles und sends MML commund to udd SS_code Step5.u) lf HLR provlslon fulls, RBT rollbuck, log generuted b) lf successful RBT system generutes CDR Deregister Postpaid Deregister Postpaid Step1. Subscrlber send cuncel request by sms/lvr/buslness hull Step2. RBT system chunge subscrlber stutus ln RBT DB Step3.RBT sends request to OSS Agent Step4. OSS Agent knows the correct HLR from MSISDN/IMSI serles und sends MML commund to delete SS_code Step5.u) lf HLR provlslon fulls, RBT rollbuck, log generuted b) lf successful, RBT system generutes CDR Postpaid Monthly Fee flow Postpaid Monthly Fee flow Step1. Postpuld CRBT Subscrlber Monthly fee collectlng dute urrlves. Step2. RBT system generutes u CDR und sends lt to Bllllng System. Step3. Its Bllllng Systems responslblllty to do the rutlng und churglng of CRBT monthly fee. Postpaid Download CDR Generating Postpaid Subscriber Download Fee CDR Generation Process Flow Step1. Subscrlber send downloud request by sms/lvr/buslness hull Step2.The song ls downlouded ln the personul llbrury of the subscrlber. Step3. CDR ls generuted und sent to Bllllng system.