Call Processing

9/21/2004 11:00 AM
CDMA Call Processing

From the RCS Perspective
Steve Meier skmeier@lucent.com
21 September 2004
9/21/2004 11:00 AM
What is RCS?
! !
RCS is the central controller for a single cell site (or base station) A cell site is the collection of air interface equipment serving up to six antenna faces with up to eleven carriers. In the logical view, the RCS is part of the cell site.
Logical View
MSC
PSTN
ECPC
DCS or RNC
Backhaul Facilities
CellSite CellSite
Cell Site
RCS
RCS-CCC Interface
CellSite
CCCs CCCs CCCs RF Components
Air Interface
mobile station
21 September 2004
Lucent Technologies, Inc. -PROPRIETARY-
The RCS is logically part of the Base Station. Physically, this is not necessarily true. In the Flexent architecture, the RCS is physically located in the MSC, controlling remotely located base station equipment. RCS stands for Radio Cluster Server. For call processing, the Flexent RCS has the same role as the RCC in the old Series II cell site in fact, the Call Processing code is common. These days, we prefer to use the term RCS to cover both RCS and RCC. In a lot of the documents and code, youll see the term RCC used to mean both RCS and RCC.
9/21/2004 11:00 AM
Physical View
MSC
PSTN
ECPC
DCS or RNC
AP RCS
X.25 Signaling Link
Series II
Cell Site
ECPC-RCS Interface
LAPD Signaling Links
BTS
URC RCS-CCC Interface URC URC RF Components
RCC
TDM Bus CCCs CCCs CCCs RF Components
21 September 2004
Physically, the RCS functionality resides in different places depending on the type of cell site. For Series II, the physical view matches the logical view. The RCS functionality runs on a processor (the CPU) which is physically located in the cell site. Every Series II cell site has its own dedicated CPU. For Flexent, the RCS is just a unix process running on an Application Processor which is physically located with the MSC. A single AP may contain many different RCSs, each controlling a different cell site.
9/21/2004 11:00 AM
Series 2 vs. Flexent

Series 2 Architecture
Subcell (up to 10 per cell) TDM bus ecpc Data link CSN RCC CCC Packet Pipes (1 per CCC) 5E Architecture Equivalency CCC CEs CEs BBA BBA CCC CEs BBA 3 sectors x 1 Carrier
Flexent CDMA ModCell 1/2/3 Architecture

AP Data link ecpc RCS CEs CEs 5E Packet Pipes (up to 6 per CRC) CBR CBR CDM (up to 11 per RCS) CRC CEs CBR 3 sectors x 1 Carrier
CCC = CRC BBA = CBR RCC = RCS Subcell = Module
21 September 2004
The original implementation of CDMA was on the Series 2 Cell. Later on, that code was ported to the Flexent platform, first the microcell, then the Modular Cell, and most recently the OneBTS. The RCS Call Processing software is a common code library that is generalized to work with all of these hardware platforms. The hardware components that provide certain functionalities are arranged differently in the various platforms, and they have different names. But for call processing purposes, abstractions can be made and generalized to cover all the variations. In Series II, the central control of the cell runs in the Radio Control Complex or RCC, which is a processor physically located in the cell itself. In Flexent, the same role is fulfilled by the Radio Cluster Server or RCS, which is a Unix process running on an application processor or AP, which is usually located remotely from the cell. A single AP can control up to 20 individual modcells, so there can be 20 RCS processes running in one AP. A single CDMA carrier with 3 sectors in the Series II is served by one "Subcell". The subcell contains a set of 3 CDMA Cluster Controllers (CCCs), each of which contains a set of Channel Elements (CEs). The 3 CCCs are interconnected with 3 Radios (BBAs), one for each antenna face. In the flexent Modcell, a single carrier with 3 sectors is served by a module or CDM. A single CRC controls all three sectors, with a set of CEs and three radios (CBRs), one for each sector. The Flexent CRC is equivalent to the Series II CCC, the Flexent CBR is equivalent to the Series II BBA. In Series II, each CCC has one single packet pipe, but there are three CCCs in a subcell, hence 3 packet pipes in a subcell. In Flexent, the single CRC in each module can have up to 6 packet pipes. RCS call processing generalizes this by allowing for both multiple CCC/CRCs per carrier and multiple packet pipes per CCC/CRC.
9/21/2004 11:00 AM
Modcell 1/2/3 vs. OneBTS (Modcell 4.0)

Flexent CDMA ModCell 1/2/3 Architecture
AP Data link ecpc RCS CEs CEs 5E Packet Pipes (up to 6 per CRC) Architecture Equivalency CBR CBR CDM (up to 11 per RCS) CRC CEs CBR 3 sectors x 1 Carrier
CDMA OneBTS Architecture

AP Data link ecpc RCS URC URC Packet Pipes (frame relay or ATM) CEs CEs UCR UCR OneBTS Assemblage (up to 4) URC CEs UCR
URC = CRC = CCC MCR or UCR = CBR = BBA RCS = RCS = RCC OneBTS = Module = Subcell
3 sectors x 2 Carrier
With MCR: 6 sectors x 11 Carrier
5E
21 September 2004
The OneBTS architecture further expands the model. OneBTS still maintains the Flexent architecture, with the RCS functionality at the remotely located AP. The big difference is that the radios can handle multiple carriers at the same time. The OneBTS radios are called Universal CDMA Radios or UCRs. Since each oneBTS frame can handle multiple carriers, and therefore more calls, there are multiple Universal Radio Controllers or URCs per frame, whereas the modcell had only a single CRC per frame. RCS Call Processing now generalizes this to allow for multiple carriers and multiple sectors per CCC, and at the same time to allow for multiple CCCs per sector-carrier. The latest generation of Radio in the oneBTS is the Multi-Carrier Radio or MCR. Eventually it may be capable of supporting up to 11 carriers, so a single assemblage would be capable of up to 6 sectors x 11 carriers.
9/21/2004 11:00 AM
The RCS Call Processing Mission

!
CDMA Call Processing in the RCS is:

"
Resource Administration
#
Air-Interface and Cell Resources
" "
Intermediary between ECP and Cluster Call Processing Soft Handoff Management
#
Intra-Cell and Inter-Cell coordination
21 September 2004
RCS does a number of things for CDMA call processing. The major area is resource administration. There are a number of resources involved in a CDMA call. Many are managed by the ECP, but the air interface and resources involved in a call at the cell are managed by RCS call processing. The RCS is an intermediary between the ECP and the cluster, the CCCs. In a lot of cases the ECP needs to tell the mobile to do something or it needs to receive information from a mobile. The air interface messages go from the mobile to the CCC and vice versa. Those messages need to get to and from the ECP. To get there they go through the RCS. The RCS may do some manipulation of those messages, add some value or translate things, but basically it is acting as a middle man. This is the case at call setup time when you're trying to set up an origination or termination. The RCS relays messages back and forth. The other interesting thing that RCS does in a CDMA call is manage soft handoff. CDMA is a lot different from AMPS and TDMA in that handoffs happen directly between cells. The RCSs on two different cells have to talk to each other to set up handoffs and manage the handoffs. The RCS is the principle entity that makes soft handoffs happen.
9/21/2004 11:00 AM
The RCS Call Processing Mission

!
CDMA Call Processing in the RCS is not:

" " "
ECPC functions: Subscriber operations, Network resources, tones/announcements, mobility management Cluster functions: Air Interface operations, traffic processing, Signaling DCS functions: Frame Selection, Vocoding, RLP
21 September 2004
Some of the things that the ECP does, and RCS does not get involved in, is anything that has to do with specific subscribers, subscriber database, specific features-- those are all managed by the ECP. Anything to do with network features like trunks especially trunks going out to the public network or resources at the 5ESS like speech handlers and intersystem trunks are all dealt with by the ECP. The cell knows nothing about tones or announcements. It's up to the ECP and 5ESS to manage tones and announcements. Mobility management is an ECP function that the cell knows nothing about. The ECP keeps track of where mobiles are, where they register. Individual base stations don't keep track of mobiles except while they're active on a call on a traffic channel. The RCS doesn't get involved in things that the CCC, the cluster, does. The CCC deals with the real details of the air interface actually formatting the messages and communicating with the mobile, layer two acknowledgements, that kind of thing. The RCS is shielded from that level of detail. Traffic processing is also done in the cluster and RCS also doesn't get involved in that. It doesn't get involved in anything that happens on a frame by frame basis. On a CDMA call, voice for example is converted into digital form and frames of data are sent every 20 milliseconds, 50 frames per second. The CCC has to process every one of those frames going in both directions. So there's a lot of code in the cell that deals with individual frames of data between the mobile and the network. The RCS sees things when calls are set up or handoffs are done but it doesn't see individual frame by frame activity. RCS also does not do frame selection or vocoding. Thats done at the DCS or RNC. The RCS is not the same as the BSC in the IOS architecture (or the RNC in the UMTS architecture). BSC functionality is split among the RCS (call control and resource administration), CCC (signaling and traffic processing), and the DCS (frame selection, vocoding, RLP).
9/21/2004 11:00 AM
Basic CDMA Call (Simplex)

Zone Trunk SH Trunk 5E-DCS land phone Frame Relay Connection Cell mobile station Air Interface
PSTN
SH
CE
CDMA Frequency Frame Offset Long Code (reverse)
CircuitSwitched Connection
SH-DLCI
CE-DLCI
path
Capacity Budget (PPCU) Delay Budget (Skew Group)
Antenna Face (paf)
Pilot PN Offset Code Channel (forward)
21 September 2004
This picture shows a CDMA call that has already been set up. We're skipping over the details of how the call is set up in order to describe what is in a call once it is set up. This is basically the resources from the point of view of the RCS that are involved in a CDMA call. This would be a simplex call meaning that you haven't done any handoffs. It is a mobile talking to one cell site, one antenna, the simplest form of CDMA call. Starting at the mobile, the CDMA call has an air interface link established between the mobile and an antenna at a cell site. There's a lot of details and it can take 3 days to talk about how that air interface works. We'll just cover the air interface from the RCS resource management point of view. There are parameters of a traffic channel that you have to tell the mobile about in order to setup a call. One of the parameters of a traffic channel is the Pilot PN Offset which means a lot of things, but from the resource point of view it is just a number that identifies one particular antenna at a particular cell site. It's just a number between 0 and 511. When we set up a call we have to tell the mobile in various ways what Pilot PN Offset number it should be communicating with. There's another piece of information called the Code Channel which is also known as the Walsh function or Walsh Code. In order to have a number of mobiles communicating with one cell site at the same time on a particular antenna face, each mobile, each conversation, has to use a different Walsh code. The RCS is responsible for administering the set of Walsh Codes and assigning them individually to each call that shows up on a particular antenna face. Those two pieces of information together define the forward air interface. Forward is the signal that is traveling from the cell site to the mobile. Those pieces of information tell the mobile how to listen to the cell site. In the reverse direction, there's a value referred to as the long code. It's a long pseudo-random number. Each mobile uses a unique value for long codes so we can demodulate each mobile's reverse signal uniquely. The long code is based on the mobile's serial number. When encryption is being used, the long code is generated by the ECP so it's a secret piece of data that only the mobile and the ECP know about. The RCS doesn't have to manage that long code value since each mobile ends up using an unique code on its own.
9/21/2004 11:00 AM
Basic CDMA Call (Simplex) (notes cont.)
21 September 2004
One other piece of information being managed is CDMA frequency. A given cell site, a given antenna, can be using multiple frequencies at the same time. On one frequency you can handle 30 or more mobiles per sector. If you have more traffic than that, you can add more frequencies, up to 11, and handle more mobiles. For an individual call, we have to choose a particular frequency. The RCS keeps track of all the frequencies equipped on each antenna face and assigns calls to different frequencies. You'll also hear the word carrier used. Carrier and frequency means pretty much the same thing. One carrier is equal to one CDMA frequency. Finally, theres the Frame Offset. This tells the mobile that its data frames should be shifted in time relative to system time. We try to put different mobiles at different frame offsets, in order to smooth out delays on the packet pipes, which Ill mention in more detail later. That covers the air interface resources. One RCS is managing the resources within a cell, the actual physical hardware. In order to setup a CDMA call, the RCS has to allocate the set of resources within the cell. The main resource is the Channel Element (CE.) It's equivalent to what a radio does in analog. One Channel Element is a circuit that processes one call. It handles modulation and demodulation and everything to do with per frame 20 millisecond stuff. Every cluster has a full set of CEs. In the physical architecture, every cell has a number of clusters, CCCs. Each CCC has a number of CCUs. A CCU corresponds to a circuit board The original CCU only had 2 Channel Elements per board. Now we have as many as 128 Channel Elements per board. Once the RCS call processing allocates a Channel Element, it has to assign the air interface. It also has to get the channel element connected to the actual antenna. Every cell site can have up to 6 antenna faces. If you're looking at RCS code, you'll see Antenna faces referred to as Physical Antenna Face or PAF, with an f. These are usually referred to by Greek letters like alpha, beta, gamma. A given Channel Element typically has the ability to connect to any one of three different antenna faces. A normal Series II cell will be configured as an interconnected configuration which means all the CEs in a given group can connect to three antenna faces, alpha, beta, gamma.
9/21/2004 11:00 AM
Basic CDMA Call (Simplex) (notes cont.)
21 September 2004
10
The way that connection works is there is a physical path. This refers to the way the backplane is configured. There is a path for the signals to go from the CE to any of three different radios that are connected to each antenna face. The RCS call processing doesn't really worry about all the hardware between the CE and the antenna. We just abstract that to a value of 0, 1, or 2 to indicate three possible path values. In the oneBTS, we now have up to 66 possible path values. One thing that's confusing is we talk about path and paf and you have to listen carefully to hear what someone is saying when they talk about path or paf. The RCS manages both of those. At the other end, the RCS is responsible for getting that Channel Element connected to the 5E in order to make a connection to the land-line network. Stuff that's at the 5ESS or DCS, the RCS isn't involved in. ECP and 5ESS work together to manage these resources. The basic unit that's involved at the 5E is called the speech handler. For every individual CDMA call there has to be one speech handler involved. Speech handler is basically one circuit or part of the circuit board that handles all the encoding and decoding of CDMA voice call or could be data calls, converts from CDMA air interface format for data to the telephone network 64 kbps type for voice. The speech handler appears to the 5ESS as a voice trunk, at least for voice calls. The 5ESS and the ECP work together to connect a speech handler to an outgoing trunk, or looparound trunks or outgoing trunks. Basic 5E call processing handles this trunk connection depending on what's going on with the call. The cell site doesn't need to know anything about that. When a speech handler is identified for a particular call, though, the 5E tells the ECP what the address of that speech handler is. The ECP tells that address to the RCS. The address of a speech handler, at least what we're interested in is called a DLCI which stands for Data Link Connection Identifier. From our point of view it's basically just a 4 to 8 byte number. Throughout a network, every individual speech handler has a unique DLCI. The Channel Elements also have unique DLCIs. What happens when a CDMA call gets set up, the RCS is told what the speech handler DLCI is and the RCS has to tell the Channel Element how to connect to that speech handler. We actually tell the Channel Element what the speech handler DLCI is and the CE and the speech handler talk to each other to establish a connection between themselves, exchange their own address back and forth and establish a connection. Once this entire set of resources is established, then the CDMA call has everything it needs to have data or voice flowing in both directions. RCS also manages the capacity of each Packet Pipe, in terms of Packet Pipe Capacity Units (PPCU). In addition to total PP capacity, the delay for each call must be minimized. This is managed by skew groups, which shifts the start time of each calls packet transmissions by a different amount. Skew groups are created by using frame offsets on the air interface.
9/21/2004 11:00 AM
Call Setup
MS
Origination CR_ORIG MGORIG_C RC_TCACT MGTCSETUP_C CR_TCACTCONF RC_TCASN SH Assignment Channel Assignment RC_SHASGN Traffic Channel Established CE-SH Protocol Established MGSHASGN_C SH Request
Paging CCC
Traffic CCC
RCS
ECPC
DCS
CR_VCCONF MGTCCONF_C
RC_PARLS
Talking!
21 September 2004
11
This diagram shows the messages that pass back and forth between the various elements. I glossed over a lot of the details of what happens in the CCC and the mobile and what happens at the ECP. I've focussed on what the RCS is doing in this scenario, where it allocates various resources, etc. Everything in call processing is message based. There is a naming convention that helps you understand what the code is doing. Messages between CCC and RCS are prefixed with either RC or CR where the order of the letters indicates the direction of the message. Messages that start with CR are message from CCC to an RCS. Messages that start with RC are messages from an RCS to a CCC. For historical reasons, we didn't use the same naming convention on ECP-RCS messages. In that case everything starts with MG in both directions. In order to keep things separate in CDMA from AMPS and TDMA, all the messages end with underscore C. As you're browsing through code and see an unfamiliar message at least you know where it fits in the architecture. Call origination starts with someone pressing the send button on their mobile. A termination--a land to mobile call--starts with paging the mobile but from that point on it's the same as an origination. So this scenario covers both originations and terminations. A mobile will send an origination page response to a cell and a paging CCC will receive and decode that message. It will forward that message up to an RCS as a CR_ORIG or CR Page Response (CR_PGRES). That message contains a lot of information about the mobile: the mobile phone number or MIN, serial number and dialed digits for origination and lots of other stuff. The CCC adds a little information to that--mainly the path on which it receives the message and from that the RCS can tell which antenna face the mobile is currently located on.
9/21/2004 11:00 AM
Call Setup (notes continued)
21 September 2004
12
When the RCS receives the CR_ORIG it has enough information to start allocating cell and air interface resources. First thing we do is send a message up to the ECP that says this mobile originates a call with these dialed digits. ECP call processing goes off and starts doing things related to that call. Meanwhile the RCS gets things started as well. It allocates all the resources. RCS tries to find a Channel Element on a CDMA frequency, allocates a code channel sets up a code channel, channel element and path to a given antenna face. Provided we can allocate all the resources, we send a traffic channel activation message to the CCC that owns that channel element. Sometimes the paging CCC and the traffic CCC could be the same physical CCC, but it's not always the case. Hence they are shown separately in the diagram. We can have the paging channel CCC receiving the paging message and then we could end up assigning the call to a different carrier, different frequency so that the traffic CCC is separate. The RCS has to do some interworking between the paging CCC and the traffic CCC. At this point a lot of things start happening in parallel in a call setup. The ECP goes off and starts doing things. The traffic CCC goes off and starts activating things. At certain stages they send messages to the RCS. The ECP sends a setup message that tells us whether it's O.K. for this mobile to be making a call or whether we should send a reorder tone or something. If they dial an invalid number they'll get a tone and we won't set up the call. Meanwhile the CCC is activating a channel element, getting it connected to an antenna face. Once it's done with that it sends back an activation confirmation message. These things can happen in either order. We can get the CCC message first or the ECP message first. So there's a lot of extra complication in the RCS call setup code to handle things happening in different order.
9/21/2004 11:00 AM
Call Setup (notes continued)
21 September 2004
13
At the same time, the ECP sends this back to us, it's also going off to the 5ESS DCS to allocate a speech handler. This is all happening in parallel. 5E is activating a speech handler and sending back the DLCI information to the ECP which then relays it back to the RCS. Meanwhile once the channel element has been set up even before we get the speech handler assignment we go ahead and assign the mobile to the traffic channel. So we send this traffic channel assignment message to the paging CCC which sends channel assignment to the mobile. This is the message that tells the mobile to switch from the paging channel to the traffic channel. The reason we don't wait until everything else it set up is because it's very important to get the mobile on the traffic channel as soon as possible. Studies in the field show that the longer it takes to get the mobile on the traffic channel the greater the chance of losing the call before it gets all the way set up. It's a big issue with the customer as far as how many calls they lose. Eventually we get the speech handler assignment from the 5E via the ECP. At that point we can tell the channel element via the CCC that it should connect to the speech handler. This message contains the DLCI information, tells the channel element to establish a connection. At this point, two things are still going on at the same time. Traffic channel establishment between the CE and the mobile and speech handler protocol establishment is happening between the CE and speech handler. Those two processes are going on in parallel at the CE. When they're both completed, CCC sends to the RCS a voice channel confirmation message, Now the call is up in a stable state. At that point we inform the ECP, and tell the paging CCC that it no longer has to do anything with the mobile and the call is up in the talking state
9/21/2004 11:00 AM
RCS Call Processing Software Architecture

OSDS Processes
CDPC Priority 5
WCA Priority 4
CCP Priority 4
Call Registers
CPA Priority 4
Power Control Dynamic Data
TCA
Resource Data Structures
ccphook Priority 1
MRA, etc. Priority 3
Equipage Data Structures
CCP Audits Priority 1
TR
TE
OSDS
TMdwnlink
DD Macros
HEH Macros
21 September 2004
14
We'll talk about the software architecture of RCS call processing. The RCS itself is running OSDS. If you've worked in 5E or ECP call processing, you're familiar with the operating environment we run in. It's just basic OSDS. Flexent is also running OSDS. The only difference is it is running OSDS inside an UNIX process. It's a fancier environment but as far as call processing code goes, it's really running under OSDS. CDMA call processing has five OSDS processes. The main process where most of the work is done is called CCP which stands for CDMA call processing. This one big system process manages all of the calls at the same time. Every call has an individual register containing its call information. The CCP has a set of call registers, one for each call. There is a library-type module called TCA, traffic channel administration, that manages all the physical and logical resources associated with CDMA. TCA is a set of functions and a big set of data structures that keeps track of the antenna faces, frequencies, channel elements, CCCs, all the status of all the equipment in the cell, plus it keeps track of the code channels, the logical resources on the air interface. The TCA module also interfaces with OA&M. OA&M is another process called MRA which stands for Maintenance Request Administrator. MRA is where things are removed from service, restored to service. Channel Elements, CCCs, and Packet Pipes will get removed or restored and MRA will tell TCA about them. TCA will update its data structures. When CCP wants to set up resources for a call it will make a request to TCA to allocate resources from the set of active resources that are available. CCP along with TCA is the core of call processing. In addition, CDMA call processing has another OSDS process called CPA that is responsible for managing paging and access channel activities. These are things where you don't have an actual call going on, where you're trying to locate a mobile, sending out a page message. Or a mobile registers and you just have to relay the message up to the ECP. CPA doesn't have any internal data structures. It doesn't keep track of much it just relays the messages back and forth. It runs at the same priority at CCP but has additional self-regulation so that if CCP is real busy with a lot of active calls, CCP will get more time to run than CPA. It will discard some paging messages in favor of keeping up the calls that are already active. Walsh code administration, or WCA, manages the division of walsh codes between the RCS for basic calls, and the CCCs for packet data supplemental channels. It works with TCA to move walsh codes back and forth between RCS and CCCs as demand varies. The ccphook process provides debugging capabilities in RCS call processing. This includes the ability to dump
9/21/2004 11:00 AM
RCS CP Software Architecture (notes cont.)
21 September 2004
15
There's another process called Dynamic Power Control. It is technically part of call processing, but we treat it as a separate area. It's responsible for managing the actual power levels forward and reverse. It makes sure we don't go into power overload. Where we're trying to overdrive the amplifiers transmitting or we have too much interference from too many mobiles in the reverse direction. Although it lives under the call processing subsystem, it's not call processing per se. What it does is the subject of another talk. CDMA call processing has audits which run under the audit subsystem under low priority, a back-ground priority. These are responsible for verifying the integrity of the data between OA&M, TCA and CCP. They make sure we don't lose track of any resources or things don't get corrupted. At the bottom of the graphic, I've listed some of the other subsystems that Call Processing relies on. This probably isn't a complete list. But if you're looking at code, you'll see some of these. TR is translations. This is the cell configuration data that comes down from recent change in the ECP. TE is Traffic Engineering which is also known as Service Measurements. Call processing pegs service measurement counts, how many calls are attempted, how many calls are successful, how many handoffs are attempted, that sort of thing. It all goes through the TE subsystem. We depend on OSDS for sending and receiving messages and running the process. There's one function called TMdwnlink(). It's one function that is used is to send messages to a CCC. We rely on the TM subsystem for that purpose to send messages to a CCC. For some reason in the reverse direction, for getting messages from CCC, it comes from OSDS through the OSWGETMSG() primitive. There are also macros that MRA makes available called DDA macros. We use that to obtain status of CCCs and CEs and that kind of thing. HEH stands for Hardware Error Handler. When call processing detects an error like we can't activate a channel element, we have to report it to the HEH subsystem so they can take corrective action.
9/21/2004 11:00 AM
Inside the CCP OSDS Process

CCP OSDS Process
Incoming Messages (from CCCs, RCSs, ECPC) Message Router (CCPu_rtmain) PRIHO (CCPh_priho_trg, CCPh_priho_main) Priho Filter Superstate Routing Call Registers (CRCR)
SETUP (CCPs_setupmain)
STBLCALL (CCPb_stblcall_main)
SECHO (CCPh_secho_trig CCPh_secho_main)
NEWHO (CCPh_newho_trig CCPh_newho_main)
RELS (CCPr_rlscall, CCPr_rlsmain) Library Modules TCA HOEVAL MSGUTIL NLMGR
Resource Data Structures
Neighbor List Data Structures
21 September 2004
16
This graphic represents the internals of the CCP process. It's the most interesting one where most of the work takes place. CDMA call processing is broken down into submodules. Each of those submodules corresponds either to a library-type interface or to a state in our overall call processing state machine. The blue boxes represent the various states that a call can be in from a call register point of view. While we're setting up a call, the SETUP module is responsible for all the actions that take place in that setup scenario. Once a call is set up, it transitions to the stable state module which is responsible for handling the stable call. The call doesn't do much except for handoffs in that state. When a call is finished, it goes to the release module which is responsible for cleaning up everything, sending off all the messages to clean up all the resources and put everything back in the idle state. The rest of these have to do with handoff. There are 3 different handoff related modules. PRIHO is Primary Cell Handoff. SECHO is secondary cell handoff. NEWHO is only involved in CDMA to CDMA hard handoffs, so it's kind of separate. The reason PRIHO is in a different color is because a primary handoff can happen in parallel with other activities. We can start doing a handoff while we're in the middle of setting up a call. PRIHO is implemented more as a filter than as a separate state. The way we made that work was that all messages that come into CCP from whereever go through the message routing function. It first passes the message to the PRIHO module. If there is a handoff that is taking place, PRIHO will process the message. If it's not a handoff related message, PRIHO may pass the message back to the message router which then passes it to whatever state function is responsible for the call. If it's a setup or a stable, it will pass it to either one of these. That way we can be in the middle of doing call setup, initiate a handoff, and then finish the call setup without having the code be unnecessarily complicated trying to deal with both of those at the same time. Try to keep them logically separate.
9/21/2004 11:00 AM
CCP OSDS Process (notes cont.)
21 September 2004
17
SECHO - Secondary Soft handoff module is completely responsible for soft secondary legs. So when a leg of the call is secondary it is in the SECHO state and all the messages are handled by SECHO. If a primary transfer takes place, what happens is a transition from the SECHO state to the stable call state or possibly the setup state if it's still under setup. NEWHO is a lot like a call setup. A hard handoff is a lot like setting up a new call so what you see if a call starts off in NEWHO state after receiving a hard handoff and then transitions to the stable call state. All the different states in different modules can eventually transfer control to the release module if you get a mobile release, or land release or some kind of call shutdown in the middle. Even if you're dropping one leg, everything is cleaned up by the release module. This graphic shows some other pieces of call processing that are more like library modules. We already talked about TCA. There's a module called handoff evaluation whose sole purpose is to evaluate handoff trigger messages and determine what type of handoff should be done. It appears as a kind of library function. Message utilities contain functions for sending and receiving messages. Technically that includes this message router function. It also includes a function to send messages to a CCC, to another RCS, or to the ECP. Finally, there's the neighbor list manager which manages copies of neighbor lists that are received from other cells. The neighbor list manager gets more and more complicated as time goes by and more features gets created.
9/21/2004 11:00 AM
TCAs Algorithm
Given: desired sector, channel characteristics, carrier constraints, etc. ! Select best carrier
" "
If no available carrier, reject Select Walsh Code for selected carrier If no PP available, try next best carrier Select skew group within the selected Packet Pipe If no CE available, try next best Packet Pipe for selected carrier
Select best Packet Pipe for the selected carrier

" "
Select best CE for the selected Packet Pipe and Carrier

"
21 September 2004
18
Best carrier is based on the Forward RF load values, provided by DPC. There are many adjustments made to the forward load, based on various customer-tunable preferences for example: the accessed carrier can be given a preference, border carriers can be given a preference, 2G calls can be made to prefer 2G-only carriers, etc. Note that for a soft handoff, there is only one choice for carrier. Best Packet Pipe is based on packet pipe load. Best CE has to do with how shared resources are allocated on the CSM in the CCU, especially for Packet Data calls. The TCA Algorithm is iterative if no packet pipe capacity is left for the best carrier, it can go to the next best carrier. It keeps trying until either something is found, or no carriers are left.
9/21/2004 11:00 AM
TCAs Data Model

Sector 0 Sector 1 Sector 2 Sector 3 Sector 4 Sector 5 Sector 6
Sector 1 Carrier 1 DPC status Sector 1 Carrier 2 Walsh Code Set Sector 1 Carrier 3 CE CE CE CE
2G-only CE List
CCC y CCC z
CCC List
CCC x
Note: the CCC belongs to a different SectorCarriers CCC List for each of
its paths
Path 0 Sector 1 Carrier n PP y1 Path 1 Path 2 PP y2 Path 3 CCU b CSM 0 CSM 1 CE CE CE CCU a
PP yn CCU c Path 65
Note: each path object links to a different sector-carrier
CSM Pathmap
1 1 1 1 1 1 1
CE
21 September 2004
19
In order to allocate resources to calls efficiently and to keep track of everything available vs. in-use, TCA keeps internal data structures which model the actual resources. Each Sector (PAF) is an object, containing a list of carriers that are available on that sector. For a sector-carrier, there is a walsh code set and a list of CCCs serving the sector-carrier. TCA also utilizes the DPC data for each sector carrier. Each CCC may appear in many different lists for different sector-carriers. The CCC object links back to each sector-carrier that it supports through a Path structure. The CCC also contains a list of available Packet Pipes. The Packet Pipe object keeps track of the capacity available and in use, as well as skew group usage. The CCC also contains a list of CCUs. Each CCU object contains a list of its CSMs. The CSM object contains a list of CEs on that CSM. It also contains a pathmap which indicates the specific subset of paths supported by that CSM. Each CSM in the CCC will support only a subset of the paths supported by the CCC itself. The 2G-only CE list is handled separately at the CCC level, since CSM management is not needed with 2G.
9/21/2004 11:00 AM
Handoff Management
!
Various types of Handoff in CDMA:

" " " " "
Softer Handoff Soft Handoff Semisoft Handoff Hard Handoff (CDMA-to-CDMA) CDMA-to-Analog Handoff
21 September 2004
20
If that was all there was to it, it wouldn't be that complicated in the RCS. Things get more complicated when it comes to soft handoffs. In CDMA, a mobile can do soft handoff, meaning that multiple antenna faces and multiple cell sites can be involved in a call at the same time. To improve coverage when the mobile is between two cells the signal from one cell or the other might not be sufficient to fully serve the call and you end up setting up two or more legs (up to six) to serve the call at the same time. That improves the voice quality and reduces the power requirements to maintain a CDMA call, which increases total capacity. It also makes it more complex to manage the calls. That's where a lot of the RCS call processing is involved in managing these handoffs. You may have heard about the various types of handoffs. There are: softer soft Semi-soft hard Analog
9/21/2004 11:00 AM
Softer Handoff
1
3
21 September 2004
21
With a three sector cell, you have a directional antenna facing three different directions. If you have a mobile that happens to be sitting on the border between two antenna faces such that their signals overlap to some degree, you need both antennas involved in the call. In this case, neither signal that the mobile sees from either of the two antenna faces is stronger than the other. The mobile needs to be able to receive signals from both of those antenna faces and combine the data it receives from both legs together to always ensure that it's getting good data. Likewise in the other direction, we need to have both those antennas turned on, listening to the mobile, so we're assured that at any given moment, we're going to get good data from the mobile.
9/21/2004 11:00 AM
Softer Handoff Resources

path 1 paf 1
Pilot 1 Code Channel 1 5E-DCS Cell
SH
CE
Long Code
mobile station
SH-DLCI
CE-DLCI
Pilot 2 Code Channel 2
path 2
paf 2
Same CDMA Frequency and Frame Offset is used on both paths
21 September 2004
22
Within one cell site, one Channel Element has the ability to connect to three different antenna faces. In a softer handoff, we use that capability to connect the one Channel Element that's involved in the call to two different antenna faces at the same time. All the resources that are involved here are the same as in the simplex call, except when it comes to the air interface resources. In the forward direction, we have two of everything. There's a Pilot and Code Channel for one antenna face and a different Pilot and Code Channel for the other antenna face. Likewise with hardware physical resources at the cell, the CE has to be told to use these parameters on one path on one antenna face and use these parameters on a second path to a second antenna face. It's still just one Channel Element. The way the Channel Element deals with this is that every 20 milliseconds when it sends a frame out, it sends the same exact frame over both antenna faces. It's just modulated with a different Code Channel and Pilot. The mobile receives either one or both of those frames. If either is in error, it discards it and takes whatever one is good. If both are good, it combines them or uses the first one that gets there. So at any given moment, the mobile is always getting at least one good frame. The same thing happens in the reverse direction. The Channel Element tries to receive frames of data down both of those paths from the mobile. Usually it's going to get one or the other, sometimes it gets both. But most of the time it gets at least one of them. It only sends one frame to the speech handler. It gets two frames, combines them into one and sends one frame to the speech handler.
9/21/2004 11:00 AM
Soft Handoff
1
3
21 September 2004
23
Now consider the case of the mobile that's right between two different cells, two physically different cells. Again, you have pretty much the same situation in that the mobile's not getting a better signal from one or the other. It's getting about the same signal strength from both cells. Again, we need to be able to have both antennas involved in the call. But because they're different cells, we can't do a softer handoff, we have to go to a soft handoff.
9/21/2004 11:00 AM
Soft Handoff Resources

path 1 SH-DLCI Logical Link 1 CE-DLCI 1 paf 1
Cell 1
5E-DCS
SH
CE
Long Code
mobile station
SH-DLCI Logical Link 2
Cell 2
CE
Same CDMA Frequency and Frame Offset is used on both paths
CE-DLCI 2
path 2
paf 2
21 September 2004
24
Soft handoff, from the mobile's point of view, is identical to a softer handoff. The mobile sees two different Pilots and two different code channels and has to listen to both of those at the same time and combine the frame, same way it did with softer. From the mobile's point of view, there's no difference between softer and soft. However, at the cell and the 5E end, everything is completely different because the Channel Element in one cell cannot connect directly to the antenna face in another cell. So now what happens in soft handoff is we have to set up a channel element in the second cell, connect it to the antenna that's involved in the call, and connect it back to a speech handler. In soft handoff, the speech handler does what a Channel Element was doing in softer. Every 20 milliseconds it's getting frames on these two different paths and it has to do the combining to figure out the best one and decode that one before converting it to voice to go out on the voice network. And likewise for sending data or voice to the mobile, the speech handler sends everything down both paths at the same time. From a Channel Element point of view, each one of these behaves pretty much like in a simplex call. There's one path and one physical antenna face to the CE and each one connects to a DLCI at the speech handler. The only difference is that these are now two different DLCIs. Every speech handler has a whole set of addresses available and each separate Channel Element that gets connected to a soft handoff has to address a different DLCI at the speech handler. The RCS has to manage which Channel Element is using which DLCI. The other thing you notice here, is these are in two different cells so we have RCS to RCS messaging in setting up this soft handoff. One RCS is the primary which is in control of the call, the second RCS is called the secondary. The Secondary leg just acts as a relay, and does whatever the primary tells it to do.
9/21/2004 11:00 AM
Soft/Softer Combinations
Each CE supports 3 paths, but only 2 can be used at one time for softer handoffs
Cell 1
Each SH supports 7 logical links
CE
5E-DCS
Cell 2
SH
CE
mobile station
Cell 3
Mobile can follow up to 6 forward channels at once
CE CE
21 September 2004
25
Soft and softer can exist in many combinations. One call can have up to six legs within a single call. Those six legs can be any combination of soft or softer legs. The example here is softer at cell one, just plain soft at cell two and a softer at cell three and another soft leg at cell three. Total number of legs adds up to six. Some are softer pairs. Some are just single legs. All the soft and softer legs are together at the speech handler that still does the combination of frames that are received. The total limit on resources is dependent on the speech handler which has 7 DLCI values reserved for each call which we also refer to as logical links. They all map to the same physical address, the speech handler itself deals with each DLCI almost as if it was a separate port. They call it a logical link. The RCS manages those 7 DLCIs based on logical link values. The mobile also has the capability of following up to six channels at the same time. If you look at the IS95 standards, you'll see that all the messages have room for up to six legs. That's why we have six way soft handoff, not seven or eight way. From the field data, most of the time, three or four legs are plenty of connections for most calls, in most places. But there are a few places where you need six legs. A very small percentage needs six legs, but we still have to support it. Even though the CE has physically the capability to connect to more than two antenna face, for softer handoff, we only ever use two at a time. So you have to allocate a second CE even within the same cell to handle three legs at the same cell. So it's a combination of soft and softer even within the same cell.
9/21/2004 11:00 AM
Inter MSC Soft Handoffs
5E-DCS 1 Cell 1
SH
CE
ATM Network
Cell 2
CE
mobile station
5E-DCS 2 Cell 3
CE CE
21 September 2004
26
From the RCS point of view, an inter-MSC soft handoff is fairly easy to do. It is just a soft handoff as long as the Channel Elements have a path to connect to the speech handler that is running the call. All they have to do is tell that Channel Element how to connect to that speech handler using the ATM network between two different 5ESSs. A Channel Element sends a message to a particular DLCI. If it turns out that DLCI is in a different 5ESS from the one that's connected directly to the cell, the 5ESS routes the ATM frames directly across to the switch where the speech handler is. There were a lot of complications in ECP call processing to handle this case. But the RCS code was fairly straight-forward. There is not much inter-MSC specific code in RCS call processing. Basically, across MSCs all the same combinations apply. Just some of the cells happen to be in different MSCs. The ECPC provides the router-like functionality for RCS-to-RCS messaging, including the inter-MSC case. Any RCS can send messages to any other RCS in the same MSC or in neighboring MSCs.
9/21/2004 11:00 AM
RCS-to-RCS Message Routing
MSC 1
SS7
SS7 Envelope Msg To: RCS 3 in MSC 2
MSC 2
Msg To: RCS 3 in MSC 2
Msg From: RCS 1 in MSC 1
RCS 1
RCS 2
RCS 3
21 September 2004
27
The MSCs take care of routing inter-MSC RCS-to-RCS messages. RCS doesnt actually know the details. We just have to put the right addressing information into the message header and trailer. This is a little tricky due to some legacy issues. MSC actually encapsulates the RCS-RCS message in an SS7 envelope and routes it via SS7. Theres no reason this couldnt change some day in the future to use IP for example.
9/21/2004 11:00 AM
Soft-type handoff actions

!
Add a Leg
" " "
Softer Leg at primary Soft Leg at secondary Softer Leg at secondary Softer Leg at primary Soft Leg at secondary Softer Leg at secondary Primary Transfer 11 combinations of add/drop
Drop a Leg
" " " "
Soft Swap
"
21 September 2004
28
One thing that is interesting about CDMA compared to Analog is that in Analog and TDMA a handoff is a transient state. You do a handoff and you have a stable call before the handoff and after the handoff. But in CDMA a soft handoff is a stable state. You don't talk about doing a handoff so much as adding a leg and dropping a leg from a call. When you have a soft handoff, one leg of that call is the primary. It's the one that controls the call. All the other legs are secondary legs. There are seven different actions that can take place as part of handoff processing with adding and dropping legs. We can add a leg to a call. We can add it as: a softer leg at a primary, a soft leg at a secondary or softer at a secondary. You can drop a leg when signal strength falls below a threshold. We get rid of one of the legs on the call, or drop the leg. Again it can be a softer leg at the primary, a soft leg at a secondary or a softer leg at a secondary. And in those cases we are just dropping a leg. But one of the things that can happen is a Primary transfer. The leg that is controlling the call itself has to drop off because its own signal strength has fallen below a threshold. In that case we have to transfer that primary control to a different cell. That's the primary transfer which is the most complicated scenario we have to deal with. There's another type of action called soft swap in which we drop one leg and add another leg at the same time, all as part of the same scenario. That also turns out to be extremely complicated because there are 11 different combinations that must be dealt with. Three different types of adding a leg and four different types of dropping a leg. It adds up to twelve, but one of them cannot happen, so there ends up being 11 soft swaps.
9/21/2004 11:00 AM
Add Soft Handoff Leg

MS Primary CCC
Pilot Strength Measurement Message
Primary RCS
2ndary CCC
2ndary RCS
SH
CR_HOTRIG RR_HOREQ RC_HO_SOFT
Handoff Direction
CC_HODIR Additional Traffic Channel Added
CE-SH Protocol Established CR_HOACK
Ack RC_HODIR_SOFT Handoff Complete Neighbor List Update Ack CR_HOCMPLT MGHOINFO_C
MGHOINFOACK_C ECPC
RR_HOACK
21 September 2004
29
Soft handoff add and drop. I'm not going to try and cover all the soft swap scenarios. For the most part the soft swap just combines an add scenario and an drop scenario together and does them without any intermediate steps. I skipped over adding a softer leg, that's a simple scenario. Adding a soft leg at a different cell involves communication between two different RCSs. All soft handoffs start with a pilot strength measurement message from the mobile. The mobile is continuously measuring the signal strength that is seen not only from the antenna faces that are currently part of the call but also from some of the neighboring cells. Every few hundred milliseconds it goes out and takes measurement of those neighbor cells. Every once in a while it will detect a signal strength above a certain threshold and it will report that to the cell in a pilot strength measurement message. The primary CCC in the call gets that message and sends it as a CR_HOTRIG message to the primary RCS. HOTRIG comes from handoff trigger. At this point the primary RCS evaluates the signal strength information that it got in the handoff trigger and may decide to do a number of things. One of things it may decide to do is a soft handoff with another cell. To do a soft handoff, the RCS sends a Handoff request message to the RCS that controls the antenna face that we want to hand off to. The handoff request message logically is a RCS to RCS message. In reality, when there's no direct connection between RCSs at different cells, the message really travels up to the ECP. The ECP acts as a message router and routes that message. That works even when the cells are in different MSCs. The system knows how to route that message over intersystem data links, SS7 links, or X.25 links, to another MSC that then routes it to the target. For the most part it looks like RCS to RCS message.
9/21/2004 11:00 AM
Add Soft Handoff Leg (notes cont.)
21 September 2004
30
The RCS that receives this message attempts to allocate resources. Assuming that it can allocate resources it picks the CCC and sends RC_HO_SOFT message which serves to activate a channel element, get it connected to the speech handler and also make a connection back to the primary CCC to coordinate the handoff. So this one RC_HO_SOFT message is really doing all in one message, what in the call setup scenario, we had three different messages doing. It can do it all at once because some things already exist. The speech handler already exists at this point. So we already know the DLCI. We already know the mobile is out there so everything can be combined into this one message. The CCC goes off and establishes the link to the speech handler. Once it establishes that link, there's a message from secondary CCC to primary CCC to tell it that the handoff can be performed. Our naming convention is that CCC to CCC messages start with CC. Unfortunately, you cannot tell what direction it is going. This message is shown going from CCC to CCC. In reality that message follows the voice path. It goes from the CCC to the speech handler and the speech handler sends it on to the primary CCC. There's a run-time link established between two CCCs that are involved in a soft handoff. That goes through the speech handler. So this handoff direction from CCC to CCC results in telling the mobile, a handoff direction message over the air, to tune in to the antenna face on the new cell. At this point, the mobile has established a soft handoff between the two antenna faces or more if there are more. Meanwhile the CCC acknowledges back to its RCS that it is connected to the call. There's another RCS to RCS message because there's a lot of information that the primary RCS needs to know about the secondary leg of the call. There wasn't enough room for it to fit in the CCC to CCC message so there's a separate message from RCS to RCS.
9/21/2004 11:00 AM
Add Soft Handoff Leg (notes cont.)
21 September 2004
31
What happens at this point is a little bit of coordination between RCS and the CCC. The mobile completes the handoff. We update some information at the mobile as far as the list of neighboring pilots that it's supposed to measure. Meanwhile we also inform the ECP that a handoff took place. The ECP has to know what cells are involved in a handoff at all times. Even though it's not involved in doing the handoff, it has to keep track of where the call is at. If this was an inter-MSC soft handoff, there would be some additional activities between two ECPs to coordinate between themselves the identity of this call. But from the RCS perspective, we don't see that so it isn't shown here.
9/21/2004 11:00 AM
Drop Soft Handoff Leg

Quick Drop
MS Primary CCC
Pilot Strength Measurement Message Handoff Direction Ack Handoff Complete CC_HO_RMV CC_HOACK CR_HOCMPLT MGHOINFO_C
MGHOINFOACK_C ECPC
Primary RCS
2ndary CCC
2ndary RCS
SH
CR_HOTRIG RC_HODIR_RMV
Logical Link Disconnect CR_HORMV
Neighbor List Update Ack
21 September 2004
32
The case of dropping a leg from a soft handoff. You may see this called quick-drop in the code because originally in CDMA 1.0 and 2.0, we had a different version of removing a leg from soft handoff and it was too slow so we replaced it with this scenario. You may see code talking about slow drop and quick drop. The slow drop isn't used anymore. You only have quick drop that is used. It starts off the same way, the mobile sends a pilot strength measurement message but this time it's detected that one of the current legs on the call has fallen below a threshold that is too weak to be of any use to the call. Again, this comes up to the RCS as a CR_HOTRIG message. The RCS has to figure out that it needs to drop a leg from soft handoff. This message tells the CCC to drop a leg from a call. It identifies which leg to drop. The CCC tells the mobile to stop using the leg. Once we get an acknowledgement from the mobile that it has stopped using that leg, then the CCC directs the secondary CCC to disconnect from a call. At this point, the secondary leg acknowledges that fact and disconnects from the speech handler, it drops its connections, and lets the speech handler reuse that logical link for the next handoff. CCC also tells the RCS that it's been removed from a call. At this point, the RCS releases all the resources it had allocated: Channel Element, Code Channels and that stuff. It puts them back in the idle state. It's released. Meanwhile, back at the primary, the handoff completes. We inform the ECP that a leg was dropped from a handoff.
9/21/2004 11:00 AM
Primary Transfer
MS Old Primary CCC
Pilot Strength Measurement Message Handoff Direction Ack Handoff Complete
Old Primary RCS
New Primary CCC
New Primary RCS
SH
CR_HOTRIG RC_HODIR_XFER
CC_XFER CC_XFERACK Logical Link Disconnect CR_HOCMPLT Other 2ndary RCSs RR_HOINFO MGHOINFO_C RR_HOINFOACK
CR_HOXFER
ECPC
Neighbor List Update In Traffic System Parameters
RC_XFERACK
MGHOINFOACK_C
21 September 2004
33
The most complex scenario is primary transfer. When one cell drops off of a call completely that it was the primary for, all control for the call has to be transferred to a different RCS, different CCC. It starts off the same way, handoff trigger except this time the RCS identifies that the call that it controls itself must be dropped. It initiates a primary transfer with this handoff direction transfer message. At the beginning this looks just like removing a soft leg from a handoff. We tell the mobile to stop using that leg of the call. But then there's coordination between the old primary CCC and the new primary CCC. This is more complicated that it looks. There's a transfer message and a transfer acknowledgement message that transfers this control. It turns out there are lots of little windows of things that can happen while you're in the middle of doing this transfer. For example, if the mobile released the call at this point, before you completed the transfer, it's unclear as to which RCS is responsible for actually cleaning things up. There's a lot of coordination to close this window, possible extra messages going back and forth to complete the transfer and then convey this information that happens during this window. Assuming we transfer successfully, the old primary CCC disconnects from the speech handler and tells the RCS it is done. RCS releases resources, everything is done at the old RCS. Meanwhile the new RCS gets this message from a CCC that a transfer has taken place. At this point, this RCS becomes primary. It switches roles from secondary to primary at that moment. We complete the scenario back to the CCC by telling it we acknowledge the transfer. The CCC takes care of updating some information at the mobile including the neighbor list and system parameters. Meanwhile the RCS takes care of informing the ECP and informing any secondary RCSs that may be involved in the call that it is now the new primary. If your call was in 3, 4, 5 or 6 way soft handoff, at the time the transfer takes place, you may have other secondaries out there. They need to know who the primary RCS is on the call. With a soft swap, all these things can be combined. You can have primary transfer scenario combined with adding a soft leg. What happens in that case you see one handoff trigger message and you'd see the soft add scenario take place and then you'd see only a single handoff direction to the mobile to tell the mobile to add and drop at the same time and then it continues on with the transfer scenario.
9/21/2004 11:00 AM
Primary Rules
!
Primary Leg remains primary until it is dropped

" "
Primary does not mean strongest Primary does not mean reference
21 September 2004
34
The basic rule of thumb in order to keep things relatively simple is that one leg of a call is always primary. Once it's primary it remains primary until it drops off. Primary transfer only happens when the primary legs drops off. A lot of people tend to think that primary should be the one that is strongest. It might have been weaker, but it was there first, so it is the primary.
9/21/2004 11:00 AM
Pilot Sets
! !
Active Set Set of pilots or antennas the mobile is currently using for the call Neighbor Set Set of neighboring pilots that weve told the mobile to measure signal strength on Candidate Set neighboring pilots strong enough to be added to the active set Cell changes active set and neighbor set. The mobile manages neighbor set and candidate set.
19
17
18 15 13
1
3 M
14
20
21
22 4
12
10
6
11 9 7 5
Active Set: 1, 2, 6 Neighbor Set: 4, 5, 7, 9, 10, 14, 15, 18 14 becomes a candidate as mobile moves Northeast.
21 September 2004
35
The handoff direction message actually updates the active set. The active set is the set of pilots or the set of antennas that the mobile is currently using for the call. So adding a leg and dropping a leg is really modifying the active set. The neighbor set is the set of neighboring cells that we told the mobile to make measurements on. When we update the neighbor list after a handoff, we're sending a new list to the mobile. We don't influence the candidate set directly. What happens is the mobile measures the signal strengths from its neighbor list and anything that's above the T_ADD threshold automatically moves into the candidate set. And they report it in a pilot strength measurement message. The cell changes the active set and neighbor set and then the mobile manages neighbor set candidates.
9/21/2004 11:00 AM
Walsh Code Administration

!
Walsh Code Usage

"
Walsh Code Size (in bits) determines its capacity (data rate):
#
Smaller Code == Larger Capacity
" "
64-bit and 128-bit Walsh Codes for Fundamental Channels (FCH) (e.g. voice calls) 4, 8, 16, 32-bit Walsh Codes for Supplemental Channels (SCH) (16x, 8x, 4x, 2x)
#
managed in blocks at the 16-bit level
"
2n bit
walsh code can be split into two 2n+1 bit walsh codes
SCH setup requires low latency

" "
No time for CCC->RCS->CCC messages at SCH setup time Walsh codes for SCH must be preallocated to CCCs
21 September 2004
36
The basic air interface channel is CDMA, also called the Fundamental Channel, provides a raw data rate of 9600 bits per second. With 3G1x High Speed Packet Data, bursts of higher data rates can be provided to a user through the use of a Supplemental Channel or SCH. Higher data rates are possible on the SCH by using different sized walsh codes. The smaller a walsh code is, the more capacity it can handle, because the traffic data is spread over fewer chips (time). This is a complex topic which I cant get into the details of. A single walsh code of a given size can be split into two walsh codes of the next size. There is only so much total capacity on a CDMA carrier, so the use of different walsh code sizes is a way to divide that capacity into different sized chunks. Latency is critical with SCHs, because any time spent waiting to set up a channel is perceived as a reduction in bandwidth for the user, as well as a reduction in total throughput for the cell. The higher the maximum data rate, the worse the effect of channel setup latency. So the architecture goal for 3g1x was that the CCC should be able to activate a SCH without having to get any response from the RCS. The way to achieve this was for the RCS to pre-allocate a portion of the walsh code space to the CCC for SCHs. Optimal utilization requires that this portion be continuously adjusted to adapt to the demand. The WCA process handles this allocation of walsh code space for SCHs.
9/21/2004 11:00 AM
Walsh Code Administration

! !
RCS manages division of walsh code space between FCH usage and SCH usage - WCA TCA: overall walsh code family management
"
provides interfaces and triggers for WCA Grants blocks of walsh codes to the WAD-CCC when extras are available Revokes blocks of walsh codes from the WAD-CCC when reserves for FCH run low Chooses the WAD-CCC when multiple 3G CCCs exist for sector/carrier (S2 and oneBTS only)
Walsh-code Administration System Process

" " "
! !
audits between RCS and WAD-CCCs in each sector/carrier CCCs manage codes for SCHs
"
WAD-CCC allocates SCH walsh codes to other CCCs via inter-CCC messaging
21 September 2004
37
When there are plenty of extra walsh codes available, WCA will grant blocks of codes to the CCC. When TCA starts running low on walsh codes for FCHs, it triggers WCA to revoke some blocks of walsh codes from the CCC. In Series II and in OneBTS, multiple CCCs may serve the same sector-carrier. In order for the SCH walsh codes to be managed efficiently, one of those CCCs must be chosen as the Walsh Administrator or WAD-CCC for that sector carrier. The CCCs then communicate directly with each other via inter-CCC (IC) messaging within the subcell or assemblage. WCA is responsible for choosing and maintaining the WAD-CCC assignment for each sector-carrier. A given CCC may be the WAD for a number of different sector-carriers at the same time.
9/21/2004 11:00 AM
WCA Sector-Carrier View

RCS
Walsh Code Master FCH Walsh Code Allocation WADC Selection
WC Grants/Revokes
IC
CCC
Designated WADC For a sector-carrier
IC
CCC
CCC
SCH WC Allocation requests, releases
A single CCC may be the WADC for many paths
21 September 2004
38
9/21/2004 11:00 AM
Hard-type handoffs
! ! !
Semisoft CDMA-CDMA Hard Handoff CDMA-Analog Handoff
21 September 2004
39
We won't be going into too much detail on the non-soft handoffs, but we'll cover what these other types of handoffs mean. These are: Semi-soft CDMA-CDMA Hard Handoff CDMA-Analog Handoff
9/21/2004 11:00 AM
SemiSoft Handoff Resources

7. Deactivate old Traffic Channel Resources Old Primary
5E-DCS
SH
CE
4. Direct mobile to tune to new traffic channel
X
4a. Mobile Retunes
mobile station
Click!
5. Receive Handoff Complete from Mobile on new channel (via Speech Handler Bounce) 2. Connect to SH New Primary 3. Begin transmitting on new forward Traffic Channel and listen for mobile
CE
6. Transfer Primary to New Cell 1. Activate New CE
21 September 2004
40
We'll start with SemiSoft. One thing I didn't mention with soft handoff, to do a soft handoff all the legs of the call have to be on the same frequency. When a mobile detects the signal from a neighboring cell site, we try to set up a soft handoff. There's an assumption that the neighboring cell can allocate channel elements that serve the same frequency that the call is currently on. That's not necessarily always going to be true. That neighboring cell may not have any channel elements available in that frequency. They may all be used or may not be any in existence at all. In which case the call has to be transitioned to a different frequency. In order to get the call from one frequency to another, it's more of a hard handoff. We can't do the smooth handoff transition, we have to tell the mobile to switch from frequency one to frequency two. We can do this with a semisoft handoff. A new cell that is trying to be added to a call as a soft handoff, may decide that it can't do the soft handoff, so it will activate a new Channel Element on a different frequency in preparation for doing a semi-soft handoff. It still connects to a speech handler just like a soft handoff does and begins transmitting on its antenna face and its frequency. The difference here is because it's on a different frequency, the mobile can't hear the signal that's been transmitted by the new cell. There are some messages that take place between the new cell and the old cell. Once the old cell finds out that a semi-soft handoff is taking place, it tells the mobile to tune to the new channel. Compared to a a soft handoff where we'd tell the mobile to just add the new leg to the call, in a semi-soft we tell the mobile to switch channels. The mobile stops transmitting on the old frequency and tunes in to the new frequency. There's a short period of time where no voice is going through at all. If you're a mobile user going through a semi-soft handoff, you may hear a small click. It should be a shorter click than the one you hear on an Analog handoff, but there's still a click. The mobile retunes, it acquires the signal from the new cell and the new cell acquires the signal from the mobile, but the old cell is still in control of the call. Handoff completion message comes in through the new cell, through the speech handler and back to the old primary. Once it's gotten that confirmation, it performs a primary transfer scenario. The old primary initiates the primary transfer and then it deactivates it's resources. It disconnects from the speech handler, and deactivates the traffic channel, releases all the resources. Meanwhile the new cell on the new frequency becomes the primary for the call. The call continues on the new frequency. The key point about a semi-soft handoff is it can change frequency, but the speech handler always remains the same.
9/21/2004 11:00 AM
CMPIFHO SemiSoft Handoff

Old Secondary
CE
5E-DCS
X X X X
mobile station
X X
Old Primary
SH
CE
Mobile Tunes to both new pilots simultaneously
New Primary
CE
New Primary sets up new secondaries in a soft handoff before the Semisoft takes place
New Secondary
CE
21 September 2004
41
The previous slide illustrated the simplest case of a semisoft handoff, when the mobile is handed off from one single cell on the old frequency to one single cell on the new frequency. But in general, a semisoft handoff can occur while a mobile is in a soft handoff situation. In this case, the mobile can be handed off from multiple cells on the old frequency to multiple cells on the new frequency. This is referred to as the "CDMA Multiple Pilot Inter-Frequency Handoff", or CMPIFHO. Performing a semisoft handoff with multiple legs decreases the chance of failure, especially in cases where the position of the mobile relative to the target cells is not well known. The scenario is the same as the basic semisoft handoff, except that the new primary cell, in addition to activating its own channel element, also sets up one or more new secondary cells in a soft handoff configuration. Once the primary and new secondary cells have all been activated, then the old primary cell instructs the mobile to tune to the new frequency on all of the new cells, primary and secondary. A primary transfer takes place, and then the old primary deactivates itself and all of the old secondary legs.
9/21/2004 11:00 AM
Hard Handoff Resources

8. Deactivate old Traffic Channel Resources After Guard Time
Old Primary
5E-DCS
X SH
CE
6. Direct mobile to tune to new traffic channel
X
6a. Mobile Retunes
mobile station
Click!
1. Connect IST Trunk to call at DCS 7. Receive reverse Traffic from Mobile on new channel - Become Primary
3. Activate new SH
5E-DCS
New Primary
SH CE
4. Connect to SH 2. Activate New CE
5. Begin transmitting on new forward Traffic Channel and listen for mobile
21 September 2004
42
CDMA Hard handoff is much the same situation except that in this case the new cell you want to add to the call doesn't have a path back to the speech handler. Usually this is because you're in two different MSCs that don't have the ATM network between their DCSs or between their 5ESSs. We support this hard handoff also between different vendors. You can have a Motorola system doing a handoff to an Autoplex system or vice versa using a CDMA to CDMA hard handoff. This graphic shows two Autoplex systems doing CDMA to CDMA hard handoff. We don't know the details of how other vendor's equipment work internally. In a hard handoff, the other assumption is there is no real communication path between the two RCSs. In order to coordinate the hard handoff, the ECP is fully involved. ECP call processing has more to do with a hard handoff than it does with a soft or semi-soft. Steps that take place. The ECPs work with each other to establish a trunk connection between the two switches. This is an IST or Inter-System Trunk. That trunk is connected to the existing call. The new cell, if it's a Lucent cell, activates the channel element and at same time the ECP activates the speech handler. The channel element and the speech handler establish a connection. Once that's all activated successfully, we begin transmitting on the new channel, waiting for the mobile to show up on the channel. Once that's all done, a message goes back from ECP to ECP and the old cell sends a handoff direction to the mobile to tune to the new channel. At this point, from the mobile's point of view, it's similar to a semi-soft. It retunes from the old channel to the new channel, and if you're a user, you may hear a click. It should sound the same as a semi-soft, you shouldn't hear too much difference. The old cell waits a little while to ensure the mobile successfully handed off. We wait a second or two. Unfortunately, we don't have any good confirmation method so we just wait a couple of seconds, then we start deactivating everything. If the mobile doesn't successfully hand off, too bad, you lose the call. There's not much we can do about it at that point. Assuming the mobile does tune to the new channel, the new cell will acquire that signal from the mobile, and basically assume the primary cell role. Now you have a stable call at the new cell at the new switch and everything at the old cell is discontinued. What will finally happen is the ECP will disconnect the speech handler from the trunk connection on the call. And you'll have a call that comes in from the network across the IST trunks to a speech handler at another MSC.
9/21/2004 11:00 AM
CMPIFHO Hard Handoff

Old Secondary
CE
5E-DCS
X X X X
mobile station
X X
Old Primary
X SH
CE
Mobile Tunes to both new pilots simultaneously
New Primary
5E-DCS
CE
SH
New Secondary New Primary sets up new secondaries in a soft handoff before the HHO takes place
CE
21 September 2004
43
Just like with the semisoft handoff, the CDMA-to-CDMA hard handoff can involve multiple pilots. Again, this is referred to as the CMPIFHO hard handoff. The scenario is essentially the same as the simple hard handoff case, except that the new primary cell also sets up one or more new secondary cells in a soft handoff. The handoff direction message which is sent from the new ECP to the old ECP instructs the mobile to tune in to all of the new legs on the target channel.
9/21/2004 11:00 AM
CDMA-to-Analog Handoff
8. Deactivate old Traffic Channel Resources After Guard Time
Old Primary
5E-DCS
X SH
CE
5. Direct mobile to tune to Analog channel
X
6. Mobile Retunes
mobile station
1. Connect IST Trunk to call at DCS
7. Receive reverse Signal from Mobile
Click Hiss Buzz Crackle
2. Connect Analog Cell Site Trunk to IST
DCS
Analog Cell
4. Begin transmitting on Analog Channel and listen for mobile
RCU
3. Activate Analog Radio
21 September 2004
44
Support CDMA to Analog handoff. For the most part this is just like a CDMA to CDMA hard handoff except that the target cell is Analog. In addition to changing frequency, the mobile has to switch from CDMA mode to Analog mode. Some of the details are different. What happens at the Analog cell is completely different. The details of what happens at the Analog side, CDMA call processing doesn't worry about. On the old cell, the CDMA cell, things are pretty much the same, CDMA to CDMA, except the handoff direction message we send to the mobile has to contain Analog channel parameters instead of CDMA channel parameters. Once we tell the mobile to retune, it retunes. We wait a few seconds, and then we tear down the resources. We stop transmitting. We disconnect the speech handler and the ECP disconnects the speech handler from the trunk connection.
9/21/2004 11:00 AM
Colocated Partner Cells

!
Two Cell Sites with a common Antenna Location.

" "
MSC ECPC
Each has a subset of the carriers Usually used as capacity expansion for Series II Cells
RCSs periodically exchange loading information via RCS-RCS messages Call Setups can be forwarded from the accessed cell to the serving cell (via RR messages).
CellSite
RCS to RCS Messages
C7-C10
CellSite
C1-C6
21 September 2004
45
The RCS is logically part of the Base Station. Physically, this is not necessarily true. In the Flexent architecture, the RCS is physically located in the MSC, controlling remotely located base station equipment. RCS stands for Radio Cluster Server. For call processing, the Flexent RCS has the same role as the RCC in the old Series II cell site in fact, the Call Processing code is common. These days, we prefer to use the term RCS to cover both RCS and RCC. In a lot of the documents and code, youll see the term RCC used to mean both RCS and RCC.
9/21/2004 11:00 AM
IP Backhaul
Frame Relay
Zone Trunk SH Trunk 5E-DCS land phone Packet Pipe Cell mobile station Air Interface
PSTN
SH
FRPH
CE
SH-DLCI
Capacity Budget (PPCU) Delay Budget (Skew Group) CE-DLCI
IP Backhaul
Zone Trunk SH Trunk 5E-DCS land phone
MLG
Capacity Budget (kbps) Delay Budget (Skew Group)
Cell
PSTN
SH
BHS
IP Network
CE
mobile station
SH-DLCI
BHS IP Address MLG IP Address

CE-DLCI
21 September 2004
46
Just a brief introduction to IP Backhaul, which is currently under development. Recall that when we set up a call, we have a connection between the CE at the cell and the SH at the DCS which carries the traffic. This connection would be going over a Frame Relay Packet Pipe. A packet pipe is a hardwired connection between the cell and an FRPH (Frame Relay Packet Handler) at the DCS. I didnt mention the FRPH before, because it is hardwired to a packet pipe, so from the cells point of view, we dont know about it. The hard wiring is a burden for service providers to maintain, plus the limited size of each packet pipe limits efficiency. The number of calls supported per T1 facility is less than everybody would like. IP backhaul addresses those shortcomings. T1 facilities can be grouped into Multi-Link Groups, or MLGs. The MLGs for a cell connect to a router in a private IP network. At the DCSs side of the network, the hardwired FRPH is replaced by a Back Haul Server or BHS. The BHSs and the MLGs are assigned IP addresses. Connections are established by software, hence the need to maintain hardwiring is eliminated. But this does mean that the RCS and the cell now must know about BHSs and how to connect to them, whereas with FRPHs we didnt have to do anything. The MLG is similar to a big packet pipe we still have to manage its capacity and delay budget (via skew groups). The algorithms are somewhat different in detail. Also, an MLG can be shared by multiple CCCs, which complicates the TCA model somewhat. Note that we still have DLCIs at the SH and at the CE. Essentially we are maintaining the old frame relay addressing protocol, it is just carried over the IP connections. This allows for compatibility for soft handoffs between new IP cells and old frame relay cells in the same network.
9/21/2004 11:00 AM
Additional Topics
! ! ! ! ! ! ! ! ! ! !
AHO/CAMSHO/APHO Mobile-assisted Interfrequency Handoffs Distance Based Handoff Triggers Mobile-Return on Hard Handoff Failure SMS SHAPCAR Neighbor List Caching Packet Core vs. 5E-DCS IOS A3/A7 Load Balancing Algorithms (intra-band, inter-band) Fast Call Setup and Immediate Call Setup
Lucent Technologies, Inc. -PROPRIETARY47
21 September 2004
A number of additional topics of interest could be addressed if there were time and interest.
9/21/2004 11:00 AM
References
! ! ! !
SRD-1205, CDMA Base Station Call Processing Requirements (DOORS) ARD-0196, CDMA Cell Site Cal Processing Software Architecture, (docsable) RCS CDMA Call Processing Software Architecture, (apxlib d31845) CDMA Air Interface Standards:
" " "
Current: IS-2000A Past: IS-95A, J-STD-008, IS-95B, IS-2000 Future: IS-2000C, IS-2000D
21 September 2004
48

Call Processing

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Call Processing

Caricato da

Copyright:

Formati disponibili

9/21/2004 11:00 AM

CDMA Call Processing

Steve Meier skmeier@lucent.com

CCCs CCCs CCCs RF Components

Lucent Technologies, Inc. -PROPRIETARY-

LAPD Signaling Links

Lucent Technologies, Inc. -PROPRIETARY-

Series 2 vs. Flexent

Flexent CDMA ModCell 1/2/3 Architecture

CCC = CRC BBA = CBR RCC = RCS Subcell = Module

Lucent Technologies, Inc. -PROPRIETARY-

Modcell 1/2/3 vs. OneBTS (Modcell 4.0)

CDMA OneBTS Architecture

With MCR: 6 sectors x 11 Carrier

Lucent Technologies, Inc. -PROPRIETARY-

The RCS Call Processing Mission

CDMA Call Processing in the RCS is:

Air-Interface and Cell Resources

Intra-Cell and Inter-Cell coordination

Lucent Technologies, Inc. -PROPRIETARY-

The RCS Call Processing Mission

CDMA Call Processing in the RCS is not:

Lucent Technologies, Inc. -PROPRIETARY-

Basic CDMA Call (Simplex)

CDMA Frequency Frame Offset Long Code (reverse)

Capacity Budget (PPCU) Delay Budget (Skew Group)

Antenna Face (paf)

Pilot PN Offset Code Channel (forward)

Lucent Technologies, Inc. -PROPRIETARY-

Basic CDMA Call (Simplex) (notes cont.)

Lucent Technologies, Inc. -PROPRIETARY-

Basic CDMA Call (Simplex) (notes cont.)

Lucent Technologies, Inc. -PROPRIETARY-

Lucent Technologies, Inc. -PROPRIETARY-

Call Setup (notes continued)

Lucent Technologies, Inc. -PROPRIETARY-

Call Setup (notes continued)

Lucent Technologies, Inc. -PROPRIETARY-

RCS Call Processing Software Architecture

Power Control Dynamic Data

Resource Data Structures

MRA, etc. Priority 3

Equipage Data Structures

CCP Audits Priority 1

Lucent Technologies, Inc. -PROPRIETARY-

RCS CP Software Architecture (notes cont.)

Lucent Technologies, Inc. -PROPRIETARY-

Inside the CCP OSDS Process

SECHO (CCPh_secho_trig CCPh_secho_main)

NEWHO (CCPh_newho_trig CCPh_newho_main)

RELS (CCPr_rlscall, CCPr_rlsmain) Library Modules TCA HOEVAL MSGUTIL NLMGR

Resource Data Structures

Neighbor List Data Structures

Lucent Technologies, Inc. -PROPRIETARY-

CCP OSDS Process (notes cont.)

Lucent Technologies, Inc. -PROPRIETARY-

Select best Packet Pipe for the selected carrier

Select best CE for the selected Packet Pipe and Carrier

Lucent Technologies, Inc. -PROPRIETARY-

TCAs Data Model

Note: each path object links to a different sector-carrier

Lucent Technologies, Inc. -PROPRIETARY-

Various types of Handoff in CDMA:

Lucent Technologies, Inc. -PROPRIETARY-