1. Copyright 2008 Page 1 of 8
CDMA Wireless Intelligent Network for Advanced Short
Messaging Services
Shameer KC
TATA Consultancy Services
Limited
TCS Nortel Technology Labs.
Park West2, Borivali, Mumbai
+91 22 6779 9865
shameer.kc@tcs.com
ABSTRACT
This whitepaper details the feasibility of implementing an
intelligent CDMA network, which can be used to implement
various value added SMS services in future.
The research proposes implementation and deployment of a basic
WIN-SMS framework, which can be used for developing value
added services in the future. The similar implementation shall be
considered in other wireless networks also such as GSM and
UMTS.
1. Introduction to Wireless Intelligent
Networks
The concept of Wireless Intelligent Networks came from the
Advanced Intelligent Network (AIN), which is used in telecom
networks (Wireline, ISDN, GSM etc…). In this conceptual
framework, the service functionality is distributed among various
components of a network. Using well-defined interfaces, various
distributed functional entities communicate with each other to
provide advanced services to the end user. These services are
termed “intelligent” because they often make use of subscriber
information, current date and time, network resources, and other
tools to provide sophisticated services which are designed to be
customizable by the service provider and/or end user.
Some of the most commonly used WIN network entities in
CDMA are:
- Intelligent Peripheral (IP): Provides connection-
oriented services through the PSTN. It may perform
functions such as digit collection, voice collection,
announcements, custom ring back tones etc. The IP
may or may not be part of Service Node (SN).
- Service Control Point (SCP): SCP is a real-time
database and transaction processor, which is capable of
retrieving/launching queries from/to the MSC to
perform real time customer or application service logic.
- Service Node (SN): Service Node is a combination of
SCP and IP.
Following are the WIN Functional Entities from call processing
perspective:
- Service Control Function (SCF): This entity
commands call control functions in the processing of
WIN provided and custom service requests. This entity
usually resides in the SCP.
- Call Control Function (CCF): Provides call and
service processing and control. This usually resides in
the MSC.
- Service Switching Function (SSF): This entity is
associated with CCF and provides the set of functions
required for interactions between CCF and SCF. This
usually resides in the MSC.
2. WIN Network Architecture
The diagram below depicts a typical CDMA Wireless Intelligent
Network.
Figure 1: Network Architecture for a CDMA Wireless
Intelligent Network
Various entities in the network are connected using ANSI-41
links.
- MSC: Serves the basic purpose of call processing. The
MSC also acts as the Service Control Function, based
on the
- HLR: Serves as the permanent database, which stores
the subscriber’s static profile, as well as the
information about current serving MSC.
- Message Center: Acts as the gateway for routing SMS
between various nodes in the network. For a mobile
subscriber, the routing information to the Message
Voice Link
Signaling Link
Service Node
SCP
IP MSC
HLR
Message
Center

2. Copyright 2008 Page 2 of 8
Center is stored in the HLR profile. This is
downloaded to the MSC during profile updates (mobile
registration, profile changes by the service provide in
HLR etc…).
- Service Node: Includes both SCP and IP entities as
described earlier.
For providing connection services such as announcements, ring
back tones etc, voice trunks exist between the IP and MSC, while
all other nodes perform only messaging.
The existing CDMA WIN standards (IS-826) are implemented
mainly based on the voice call processing model. That is, the
WIN framework is used only for voice calls as of today.
Following are some of the call processing services implemented
based on WIN:
- Prepaid Billing
- Announcements
- Customized Ring Back Tones
- Advanced Features such as call forwarding etc, which
are profile based.
3. WIN Triggers, Detection Points and
Service Controlling
Many of the CDMA service providers use the WIN network
model to implement pre-paid solutions to the customers. In these
networks, the intelligence regarding the pre-paid customer
services is always stored on the Intelligent Peripheral, since the
existing MSC’s were designed mainly to serve the purpose of
core call processing. However, with the advance of WIN
technologies the SCF functionality was built into the MSC’s,
which would act based on the commands received from the WIN
SCP.
3.1 WIN Call Model at the MSC
WIN standards divides the basic MSC call processing model to
the following two halves:
- Originating Call Model: This includes processing of
the events from the originator’s perspective. For
example, processing of origination message, translation
etc… are part of the OCM half of the call.
- Terminating Call Model: Includes processing of
various events from the terminator’s perspective.
Examples include processing of page response, answer
etc…
For a basic call, we have an OCM half and a TCM half plus
there are some additional processing that are common to both the
halves.
3.2 Trigger Detection Points
CDMA call processing consists of multiple events for a single
call. For example, in case of a mobile to mobile voice call,
following are the major events that occur:
1. Originator dials the digits.
2. Upon validating the originator, he is assigned to a
traffic channel.
3. MSC Routes the call based on the digits dialed by the
originator.
4. MSC attempts to locate the terminator based on
translation.
5. MSC Pages the terminator in case of local terminators.
6. Upon receipt of page response, MSC orders the mobile
to traffic channel.
7. Upon answer, voice path is established between
originator and terminator.
WIN Call Processing model works on the same concepts. The
model defines various points in a call that can eventually lead to
communicating with the SCP. These are called “Trigger
Detection Points”. For example, if we consider the above mobile
to mobile scenario, the receipt of origination message from the
originator shall be considered as a Trigger Detection Point.
The trigger detection points in call scenarios are defined by the
existing WIN standards.
3.3 WIN Messages
The existing WIN standards define a set of messages that are
built on top of the existing ANSI-41 protocol. Some of the
messages are:
- Origination Requestion,
- AnlyzedInfo.
- T_Busy
- T_NoAnswer
- T_Answer
- O_Answer
- O_CalledPartyBusy
- O_NoAnswer
All these messages are built as a TCAP application, which
allows the messages either to be uni-directional or bi-directional.
In case of uni-directional messages, the MSC sends the message
to the SCP but do not wait for the response.
3.4 WIN Triggers
A WIN Trigger is a mapping between a trigger detection point
and a WIN message. The WIN trigger identifies the action to be
taken when the call processing reaches a specific detection point.
For example, if the service provider requires to send ORREQ
Message to the SCP upon Origination message detection point,
the detection point is armed with a WIN trigger, that specifies
ORREQ message to be sent with the address of the SCP.
Following are the minimal requirements for a WIN Trigger:
- Detection Point information: Indicates at which point in
call the MSC should send the message.
- Outgoing message name: Determines which message to
be sent to the SCP.

3. Copyright 2008 Page 3 of 8
- Wait-For-Response-From-SCP: Determines if this is a
uni-directional or bi-directional message. In case of bi-
directional messages, Call processing continues based
on the information SCP sends in the response message.
Example Scenario:
Consider a pre-paid subscriber without enough balance
attempting to originate a call. Since he is pre-paid user, the
service provider arms the call with the following WIN-Trigger
- Detection Point = Origination Message
- Outgoing Message = ORREQ
- Wait-For_Response-From-SCP = Yes.
When MSC receives origination message, it identifies that the
call is armed with a WIN trigger. It sends the ORREQ message
to SCP and waits for response. Upon receipt of orreq return
result, the call processing continues based on the parameters
received in the message.
When user does not have enough balance, the SCP would inform
about this to MSC via the Action Code parameter in the return
result and the call will be taken down immediately.
WIN Standards define two types of WIN triggers:
- Office Wide Triggers: If the triggers apply to all calls
processed through the MSC. Typical application
include emergency call/1-800 call processing, where
the call gets routed based on the information received
from the SCP (call should get routed to the nearest
police station).
- Profile based Triggers: The WIN trigger information
is stored in the HLR and gets downloaded to the MSC
upon registrations and profile updates. This is used
mainly for pre-paid services (not all subscribers
currently served may be pre-paid).
3.5 Advantages with WIN Based Services
There are many advantages while using WIN based services
including:
- It is easier to implement value added services: For
example, if the customer would like to come up with
some new services, the development is required only
on the SCP node (for example, providing voice SMS
etc…).
- A Common platform for Billing: Eases the task of
Billing especially in markets like India, where pre-paid
usage is very high compared to post paid services.
3.6 Disadvantages/Restrictions with WIN
- There is a major hit on the capacity (both network
utilization as well as processing power). Compared to
basic call processing, there are many more messaging
involved with WIN call processing.
- WIN is implemented only for voice services as of
today. Data Services such as SMS are not supported.
4. CDMA Data Delivery Services
There are multiple CDMA features that deal with delivery of
data between the mobile subscriber and various entities in
network such as:
- SMS Origination
- SMS Termination
- LCS, OTAPA, OTASP etc…
Out of these, SMS origination and termination are features that
are subscribed by the end user. But LCS, OTAPA and OTASP
are services that are not subscribed by end user (system provided
features).
Service providers do Billing for SMS origination and termination
features. As of today, this is done at the Message Center, which
does not have information about the end user’s profile. For
example, if a prepaid mobile’s balance has become zero due to a
voice call, the SMS may still get processed.
4.1 SMS Call flows
The diagram below depicts a basic mobile to mobile SMS call
flow.
Figure 2: CDMA SMS End to End Call Flow
1. When the user attempts to originate a short message,
the Originator’s Serving MSC/VLR receives the
origination message. This includes parameters such as
SMS Bearer data and Destination Digits.
2. The originator’s Serving MSC/VLR already has the
profile downloaded from HLR during registration.
Upon validating the request and identifying that SMS
Origination is allowed for this user, the MSC sends
SMDPP invoke to the Message Center. There are
multiple ways of identifying the route to Message
Center:
12. SMS_O Ack
11. smdpp return result
3. SMSREQ
1. SMS Origination
10. Smdpp return result
9. SMS Ack
8. SMS Deliver
7. Page Response
6. Page Request
4. SMSREQ
5. SMDPP Invoke
2. SMDPP Invoke
Originator Orig MSC-S Term MSC-
S
TerminatorMC Term HLR

4. Copyright 2008 Page 4 of 8
a. SMS Direct Routing: In this case, MSC
routes based on the Destination Digits. This
is used when Originator is not billed for the
message (SMS billing always occur at the
Message Center).
b. Indirect Routing: In this case, MSC routes the
message based on the originator’s profile.
This is used when originator has to be billed
for SMS. The Message Center has the logic
to route the message to route to terminator’s
Message Center in this case.
c. Special routing based on destination digits:
This is normally used in case of special digits
used in case of voting systems, such as Tele-
voting. This is done to prevent any kind of
network congestion and always takes priority
over Indirect Routing.
3. The Message Center requests the terminator’s HLR
requesting for the current serving MSC’s
information (HLR keeps track of the latest serving
MSC during registration requests).
4. HLR Sends the serving MSC address to the Message
sender via return result, so that the Message Center can
route the message to the MSC directly.
5. Message Center sends the SMS text using SMS
Delivery Point to Point message to the Serving MSC of
terminator.
6. The MSC-S attempts to locate the mobile by sending
Page request.
7. The mobile responds to the page.
8. Upon receipt of page response, the MSC delivers the
message to the mobile.
9. The mobile sends an acknowledgment indicating that it
receives the message.
10. MSC informs the message center about the SMS being
successful.
11. MC tandems the message to the originating MSC side.
12. MSC-S Of originator informs the mobile about SMS
being success via the acknowledgment.
4.2 Voice Call v/s SMS Processing
Though both voice and SMS processing have lots of common
factors, there are many differences as well.
Similarities:
1. Both are subscribed features. The mobile user needs to
subscribe to both features separately (though both are
considered as default services today).
2. Both features are used heavily in the market.
Differences:
1. In the existing networks, voice calls are allowed
directly in between the originator and terminator.
However, in case of SMS, this always happen as two
separate transactions. For mobile to mobile SMS, first
transaction occurs between MSC and Message center
and then between Message Center and terminator.
2. In case of voice calls, the system requires dedicate
voice path connected between originator and terminator
(though this has been optimized with packet networks).
In case of SMS, no dedicated resources are required.
3. Voice call cannot be stored as such for later delivery
(though voice mail functionality allows this). However,
an SMS can be delivered later also as the storage is not
a major issue (low chunk of data).
4. Most of existing MSC’s do not support SMS Billing
while voice call billing can be done at MSC. In case of
pre-paid, voice call Billing is done normally at the
SCP, while SMS Billing is done at Message Center.
5. Implementing WIN for SMS
The proposal is to enhance the existing CDMA WIN network to
support Data Delivery Services in addition to the existing voice
call processing. This has the following advantages:
- A Common billing platform in the entire CDMA
network (SCP).
- Implementation of advanced services such as SMS
Forwarding, or features similar to voice calls (FA,
MAH etc…).
With the advances in SMS processing (Verizon Wireless
estimates 11 SMS messages per single call against the existing 1
SMS per 4 calls), implementation of advanced data services
based on WIN model provides cutting edge to the service
provider, to provide SMS based services.
This proposal looks at enhancing existing WIN and SMS
frameworks to support WIN processing for SMS scenarios.
To support WIN for SMS, this whitepaper details the following:
- Trigger Detection Points for SMS.
- Implementing SMS WIN Triggers.
o Messaging
o New parameters.
- SMS WIN Trigger Processing
- Call Scenarios and use cases
- Advanced Features.
- Advantages and disadvantages of WIN-SMS
Functionality
6. Trigger Detection Points for SMS
Similar to existing voice call processing, this proposal suggests
new trigger detection points to be identified for SMS call
scenarios. Following are a list of trigger detection points
possible:
SMS Origination Call Half:
1. SMS Origination Message DP (Trigger Event= MSC-S
Of Originator receives SMS Origination message).
2. SMS Origination success DP (Trigger Event= smdpp
return result received from Message Center, with no
Cause Code received).

5. Copyright 2008 Page 5 of 8
3. SMS Origination Failure DP (Trigger Event= smdpp
return result received from Message Center, with a
cause code received).
4. SMS Origination Delayed Success DP (Trigger
Event=SMDPP invoke arrived with an
Acknowledgment. A message that was delayed earlier
due to terminator being inactive was delivered
successfully later).
SMS Termination Call Half:
1. SMS Request Received DP (active at HLR, Trigger
Event=SMSREQ invoke arrives indicating an SMS is
pending delivery).
2. SMS Notification Received DP (active at HLR, MSC,
Trigger Event=A mobile accesses the System and it is
identified that an SMS message is pending for this
mobile, SMS Delivery Pending Flag is set).
3. SMS Delivery Received DP (active at MSC, Trigger
Event = SMDPP invoke message arrives with Bearer
Data for termination).
4. SMS Page Response DP (active at MSC, Trigger Event
= Page response received from mobile).
5. SMS Delivery Ack DP (active at MSC, Trigger Event =
SMS Acknowledgment received from Mobile).
6. SMS Delivery Failure DP (active at MSC, Trigger
Event = SMS Delivery timeout, cause code received
from mobile).
Besides these, the existing trigger detection points such as
Location update and profile update can also be re-used by various
SMS services.
Following table provides a list of advanced features that can use
the above defined SMS Trigger Detection Points.
Figure 3: SMS Trigger Detection Points and Uses
Trigger Detection
Point
Typical Applications that can use the
DP
SMS Origination
Message DP
Prepaid Billing:
If user does not have sufficient
Balance, block the message
right away. This could also
include providing the user
with a custom warning
message, For example “Please
recharge your mobile to
originate SMS. Current
balance: Rs.0.50”.
Alternate Routing of SMS:
In case of any special digits
feature being active on SCP, it
can command the MSC to
consider alternate routing for
the current SMS.
Alternate Billing for SMS:
The SCP shall decide on
which Billing Scheme to be
used for this call. For
example, SMS to home
network and other networks
may have different Billing
rate.
SMS Origination
Success DP
Prepaid Billing:
Originator can be billed at this
DP since the SMS was
delivered successfully.
SMS Origination
Failure DP
Alternate text for SMS Failures:
Similar to
announcements/treatments in
voice calls, the SCP platform
may provide alternate text for
failure cases.
SMS Origination
Delayed Success DP
Prepaid Billing.
SMS Request
Received DP
Alternate Routing:
This trigger shall be used to
implement SMS Forwarding.
WIN Already allows SCP
based forwarding for voice
calls and similar functionality
shall be allowed here.
SMS Notification
Received DP
Missed Call Alert:
In case mobile has a missed
call from a MIN, the same
shall be sent as a new SMS to
the mobile.
SMS Delivery
Received DP
Similar to SMS Request Received DP.
The same functionality shall be provided
either by using MSC or HLR.
SMS Page Response
DP
Any pending Notification:
In case of any announcement,
message waiting etc, this DP
shall be used by the service.
However, this may not apply
to mobiles that are already
active in a call.
SMS Delivery Ack
DP
Prepaid Billing.
SMS Delivery
Failure DP
Alternate text for SMS Failures.
7. Implementing SMS WIN Triggers
The various trigger detection points defined above need to be
armed with WIN triggers to define the action to be performed by
the SCF during SMS processing. This includes the following:

6. Copyright 2008 Page 6 of 8
- Defining messages that can be sent to the SCP.
- Defining the set of parameters to be included in the
corresponding messages.
- Defining compatibility between messages and detection
points.
7.1. Messaging for SMS-WIN
Enhancements
There are two options that can be considered regarding the
messages to be allowed for SMS-WIN Processing:
1. Define and Implement a new set of messages, which
can be used only for WIN-SMS Processing.
2. Make use of the existing WIN messages by including
additional parameters.
Option 1: Implementing new messages
A new set of messages that will be used only for SMS processing
shall be implemented. Following are the set of new messages
that shall be considered:
1. WIN SMS-O Query: This can be used as a generic
message that can be armed on any of the SMS
Originating detection points mentioned above.
2. WIN SMS-T Query: This can be used as a generic
message that can be armed on any of the SMS
Terminating detection points.
Since the new messages will be used only for SMS related
triggers, this provides the simplest way to implement the
triggers. This also ensures that the numbers of interactions are
very less.
However, the initial implementation could be higher for this
option as the nodes (HLR, MSC and SCP) need to support totally
new messages.
Option 2: Enhancing existing WIN messages for SMS-
WIN Processing
This option suggests using existing WIN messages for SMS-WIN
processing also. Following existing messages shall be considered
for implementing the functionality:
- Origination Request.
- Analyzed Info Origination.
- Analyzed Info Termination.
- T-Answer
- O-Answer.
Though this option provides lesser initial implementation cost,
the maintenance cost may be on the higher end when more and
more services are being built on top of the SMS-WIN framework.
Handling interactions may be an overhead as this option
introduces coupling between Voice and SMS functionality.
Preferred Option
Option 1 is recommended based on the advantages mentioned
above.
7.2. Message Parameters
The basic SMS-WIN framework to be introduced need not
introduce all new parameters as the functionality can be provided
by the existing parameter set.
Following are the list of parameters that need to be included in
the various messages:
- Calling Party Digits.
- Dialed Digits.
- Tele-service Identifier.
- Cause Code.
- Action Code.
- Redirection Indicator (In case of redirection required).
- Billing Identifier.
- SMS Bearer Data.
Future services that use the basic WIN-SMS framework may
need to introduce new parameters based on the new functionality
required. The above parameters are selected for the basic
framework considering the following services:
- SMS Prepaid Billing at SCP.
- SMS Alternate Routing.
7.3. SMS WIN Trigger Provisioning
Similar to office based and profile based voice call triggers, SMS
can also support profile based and office based triggers.
For example, SMS Special routing (Tele-voting) can be
considered as an office wide WIN triggers. Pre-paid Billing
Triggers need to be implemented as profile based, because the
same system may serve both prepaid as well as postpaid
customers.
For implementing profile based triggers, the following changes
are required:
- HLR Functionality:
o Should support provisioning of the triggers
for a mobile subscriber.
o Should support including the WIN Trigger
information in the profile update and
registration messages. This helps the serving
MSC to know the set of SMS WIN Triggers
that the subscriber has.
- MSC/VLR:
o Should be enhanced to store the set of profile
triggers active for the subscriber.
8. Enhancements to process SMS-WIN
Triggers
Following is a basic procedure that the SCF should follow while
processing an SMS related event.
Processing of an SMS related event:

7. Copyright 2008 Page 7 of 8
IF Is this a WIN-SMS Trigger Detection Point?
TRUE:
For all office based triggers armed at this TDP:
Process block “Processing of WIN Trigger at
TDP” based on the priority list.
Retrieve the subscriber’s VLR profile.
For all profile based triggers armed on this TDP:
Process block “Processing of WIN Trigger at
TDP” based on the priority list.
FALSE:
Go Ahead with processing
ENDIF;
Block: “Processing of WIN Trigger at this TDP”:
For all messages mentioned in the trigger:
DO
Build the set of parameters.
Send the message to route provisioned in the profile.
IF this is a bi-directional message
THEN
Wait for the response from SCP to do next action;
ENDIF;
ENDDO;
9. Call Scenarios and Use cases
9.1. SMS Origination Case
Following is the call flow example for SMS Origination case:
Figure 4: SMS Origination with WIN Triggers
1. The end user originates an SMS.
2. The MSC comes to know that WIN-SMS Triggers are
active on the originator. It queries the SCP to see if the
user has enough balance to process this message.
3. SCP has the intelligence to see if the user has the
required balance to originate and SMS and responds
back with the Action Code. In case of insufficient
balance, SCP may send a cause code indicating to take
down the SMS call.
4. Upon identifying that the mobile can originate an SMS,
the MSC sends the message to Message Center.
5. Message Center has the logic to route the message to
destination and it receives a response indicating the
message has been successful.
6. Message Center informs the MSC about the SMS being
delivered successfully.
7. MSC knows that the transaction completed. It is time
to bill the originator for SMS origination and sends the
indication to SCP.
8. SCP performs the billing logic and sends back return
result.
9. MSC Sends acknowledgment to the originator
indicating the SMS being successful.
9.2. SMS Termination Case
Figure 5: SMS Termination with WIN Triggers
9.3. SMS Termination – Forwarding Case
Figure 6: SMS Termination Forwarding with WIN Triggers
10. Application examples that can use SMS-
WIN Framework
Following are a list of services that can be built by using the
SMS-WIN framework.
10.1. Prepaid Billing
Prepaid billing service shall make use of the SMS WIN
Framework. The billing logic for voice SMS calls reside on the
SCP as of today but SMS Billing is still done at Message Center.

8. Copyright 2008 Page 8 of 8
This feature can make use of the new triggers proposed to
implement a common Billing platform.
10.2. Missed Call Alerting
The existing SMS standards and implementation supports
delivery of any pending SMS as soon as the mobile accesses the
system later. The WIN triggers if active at this point can trigger
the SCP to provide any missed call alert detail to the MSC via a
new SMS transaction at this point.
10.3. SMS Forwarding
Similar to voice call forwarding, SMS forwarding can be allowed
by the concept of alternate routing. The alternate routing
information can be provided by the SCP in case the SMS
Delivery Failure DP is hit and a trigger is armed at this DP.
10.4. SMS Group Terminations
Similar to Flexible Alerting for voice calls, SMS termination to
group members can be implemented. The group information can
be provided to the MSC during SMS Delivery Received DP
processing.
11. Analyzing the SMS-WIN Framework
Advantages
- A framework, which can be used to build multiple
value added services.
- Multiple value added services can be implemented
based on the WIN SMS framework.
Disadvantages
- High as multiple nodes needs to be enhanced.
Standardization
The enhancements proposed in this whitepaper involve multiple
nodes such as SCP, MSC, HLR and VLR. Also, there are
multiple hardware vendors and they may or may not implement
all nodes used in the CDMA network.
Thus, it is mandatory that a common standard is developed for
WIN-SMS framework so that the feature can be implemented
without any compatibility concerns during deployment.
12. Acknowledgments
My special thanks to:
- Aakanksha Vasanth (a.vasanth@tcs.com) for reviewing
the initial version and encouraging to go ahead with the
paper.
- Prasad Sawant (prasad.sawant@tcs.com) for providing
valuable suggestions on the initial version.
13. References
[1] CDMA IS-826 Standards for Wireless Intelligent Networks.
[2] CDMA IS-637 Standards for Short Message Services.
[3] CDMA2000 Standards.
[4] Nortel Technical Publication on CDMA Short Messaging
Services.
[5] Nortel Technical Publication on CDMA WIN Overview.