Ad Code



Function of OTAF in GSM Network

Function of OTAF in GSM Network : OTAF stand for Over The Air Subscriber Provisioning which is an entity that interfaces to the Customer Care to support service-provisioning activities. The OTAF interfaces with the MSC to send to MS orders, which are necessary to complete the provisioning on the handset / Mobile Terminal. The OTAF supports two functions which are: OTASP – Over The Air Subscriber Provisioning and OTAPA – Over The Air Parameter Administration.

The OTAF (OTASP/OTAPA) platform are placed at two or more locations (Suppose city X and city Y) which shall serve the provisioning requirements of all the subscribers spread over all circles. For providing an automated CSC function, a set of 6 IVRs (3 at City X & 3 at City Y) shall be put in place. These IVRs shall interface with OTAF, over a TCP/IP network, using a “proprietary” protocol for communication. One more things important to mention here that the OTAF-IVRs shall be connected to all the MSCs via respective ILTs of those circles. 

Function of OTAF

MSC to / from OTAF/IVR traffic

For the purpose of OTAF/IVR, the whole network is divided in two regions – West & North regions form one OTAF/IVR region and served by OTAF/IVR located in City X, whereas the South & East regions form other OTAF/IVR region and served by the OTAF/IVR located in City Y. In City X and City Y each, there shall be 3 OTAF/IVR platforms.

All the MSCs in one circle shall route the OTAF/IVR traffic to the ILT switch in that circle. Each ILT, of an OTAF/IVR region shall then route this traffic directly to OTAF/IVR in the same region.

MSC to IP/IVR traffic

All the MSCs in a circle shall route the traffic for IP/IVR to the ILT switch in that circle. The ILTs in all circles shall then route the traffic directly to the IP/IVR, which shall centrally be located at major metro City X (Head Office of the telecom industry).

Provisioning of handsets

Below I am going to introduce some important points-

MDN - Mobile Directory Number : A unique Mobile Directory Number (MDN) is assigned to each subscriber. This is used for call termination. The MDNs are assigned based on the numbering plan used in the network.

MIN - Mobile Identification Number : The MIN (Mobile Identification Number) is used to identify a mobile subscriber uniquely in the CDMA wireless network. All the services to which a subscriber has subscribed and other parameters are mapped to one MIN in the databases maintained in the network (e.g. HLR). The MIN allotment and it’s management is very crucial in Reliance’s network for proper routing of a call.

ESN - Electronic Serial Number : All the Mobile Stations (MS) are uniquely identified using it’s Electronic Serial Number (ESN. The ESN is the Hardware Equipment Identification number, which is hard coded into the MS at the time of manufacturing.

TRN Number : TRN (Temporary Reference Number) is also a routable number such as a MDN. This is used for handset provisioning using OTAF.  The TRN is used for any OTAF call that is routed to the IVR. This TRN is allotted by the MSC for the OTAF session. The OTAF uses to initiate an OTASP session with the MSC that has generated the TRN.

SPC - Service programming Code : Service programming Code (SPC) protects the NAM programming and PRL. In general it prevents unauthorized modification of provisioning parameters in the handset. SPC is a secret code assigned to the wireless handset and is known to the authorized network entity maintaining the database. The handset vendors would assign an SPC, for each handset, which would be different from the default value (all “0” s).

NAM and PRL : For activation the handset needs  to be  provisioned with the NAM (Number Assignment Module). There are many parameters, which are put in the handset primarily from the network perspective.  The most important parameter that has to programmed in NAM is the MIN.  This means that the ESN of subscriber’s handset has to be mapped, on one to one basis, with the MIN.

HLR/AUC ( Home Location register / Authentication Center) : HLR is a database that stores and manages subscribers’ profiles. It contains all the details of the subscriber information (e.g., Electronic Serial Number (ESN), Mobile Identification Number (MIN), etc. and the restrictions for call making eligibility etc.). All supplementary services that the subscriber subscribes to, too need to be registered in the HLR.

The HLR, has the AUC function incorporated. The AUC is an entity that manages the authentication information related to the MS. The AUC prevents mobile fraud by "authenticating" subscriber MSs upon registrations, call origination, call termination, and flash request.

Interface Definition between the OTAF-IVR and CRM 

All the communication between OTAF-IVR and CRM is based on TCP/IP, and shall work in both LAN and WAN environments-

Queries are originated by OTAF-IVR and addressed to the CRM.
Responses are replies by the CRM to the OTAF-IVR
Fields that arrive in responses, and not expected by the IVR, are ignored assuming these are for future use.
There could be more than one pending queries with the CRM, and to associate the responses correctly to the query, the first field in the query is also returned along with the response as session identifier.

1.The CRM associates the CAF, MDN and MIN when the order is processed in the CRM system.

2.The subscriber charges the battery and dials *** (given number) to initiate provisioning from the freshly purchased handset. In case of separate purchase of handset and the subscription, in order to meet the SLA, the subscriber will be advised to use the OTAF process after XX hours, so as to provide the differential for CAF registration i.e. association of CAF/ESN/MDN to be recorded in the database. 

3.The handset analyzes the PRL pre-programmed by the OEM, and latches to service provider network.

4.The MSC identifies it to be the OTASP call, routes the call to the OTAF-IVR assigning it a TRN (Temporary Reference Number). 

5.The OTAF-IVR answers the incoming call, collects the TRN from MSC, and begins playing the welcome message. (The OTAF-IVR asks the subscriber to select a language for the interaction by offering him choice from 1 to 9, default is English+ or any other language joined prompts, i.e. announcement in English can be followed by user language).

6.The OTAF-IVR sends the TRN to the OTAF, and requests for the ESN. 

7.On receiving the ESN from the OTAF, the OTAF-IVR sends the first query to the CRM. 

The CRM sends the RSN, SPL, NSPL, MDN, NAM, EStatus for the input ESN as follows: 

Valid values and meanings of the EStatus
0 = Entry for this ESN not found. Inform user and terminate call.  
1 = Entry for this handset exists in Service provider database. Valid phone, proceed normal. 
2 = Entry found, but handset is marked blacklisted. Inform user and terminate call.  
3 = Handset is already successfully provisioned. Play the MDN and terminate. 
4 = Handset is already assigned to a CAF, proceed OTASP without prompting for CAF#. 
5 = Form not received from user, inform user to call later and terminate call, don’t increment attempt counter
6 to 9 are reserved for future use. 
From the CRM database perspective, EStatus of 1 and 5 both mean that the ESN hasn’t been linked to the CAF. The difference between these statuses is in how OTAF-IVR deals with them. In case of EStatus of 1, OTAF-IVR will prompt the customer for the CAF# whereas in the case of EStatus of 5, OTAF-IVR will terminate the call. These two statuses are kept so as to allow the flexibility of whether the customer should be prompted for the CAF#. Based on the business decision, handsets will be populated in the CRM database either with the EStatus of 1 or 5.

8.The OTAF IVR validates the received inputs, and if CStatus-

0- Plays a message “Sorry, your Subscription Form is not yet registered. Kindly contact the Service Representative where you submitted the subscription form. It usually takes 1 day for registration”, disconnect the call, jump to Q3. 
1- Plays a message “Kindly hold on, till I program your handset. Please do not disconnect, %Music”, jump to OTASP.  
2- Plays a message “Sorry, this is an invalid registration number. Kindly contact the Service Representative where you submitted the subscription form. It usually takes 1 day for registration”, disconnect the call, jump to Q3.  
3- Plays a message “You have already programmed a handset using this CAF. If you are sure this is incorrect, Kindly contact the Service Representative or nearest service provider dealer to register your complaint.” and disconnect the call, jump to Q3. 4 to 9 are reserved for future use. 

9.OTASP - If OTAF-IVR successfully provisions the handsets with NAM and commits the handset to the database, OTAF frames the Q3 as follows- 
Valid values of RES are
0 = Handset Provisioning Failure
1 = Handset Provisioning Success
2-9 Reserved for future use.

10.The CRM replaces the “Estatus” and “Counter” values in its database.

11.If the Ack=1, the OTAF-IVR plays the prompt that the handset is successfully provisioned. Voice call is terminated and an SMS is sent to the customer. If  ACK=0 then it means CRM says that the commit has failed and OTAF-IVR shall play a provisioning failure prompt to subscriber and close the call.

Last Word

Dear friends, how did you like this article, tell me by commenting, if you also want to know about the call flow, then you can send me this related request. I have tried my best to give complete information about the OTAF, if you are satisfied with the given information then forward it to others as well.

Post a Comment