4.1 Admission Control ................................................................................................................................... 10 4.1.1 Admission Policy ............................................................................................................................................ 10 4.1.2 Resources to be monitored .............................................................................................................................. 11
4.1.2.1 RF Power .......................................................................................................................................... 11 4.1.2.2 Code Tree Consumption ................................................................................................................... 11 4.1.2.3 UL and DL Channel Elements .......................................................................................................... 11 4.1.2.4 Iub bandwidth ................................................................................................................................... 11
4.3 After Admission ....................................................................................................................................... 12 4.3.1 Failure after Admission: Transport failures .................................................................................................... 12
7.5 Radio Access Bearer (RAB) Setup and Reconfiguration ..................................................................... 24
1 INTRODUCTION
This specific document focuses on ACCESSIBILITY and its specifics within HUAWEI infrastructure (RAN10).
Target users for this document are all personnel requiring a detailed description of this process (Accessibility Optimization), as well as configuration managers who require details to control the functions and optimize parameter settings. It is assumed that users of this document have a working knowledge of 3G telecommunications and are familiar with WCDMA.
2 ACCESSIBILITY
Accessibility is the ability of a service to be obtained within specific tolerances and other given conditions, when requested by the user. In other words, the ability of a user to obtain the requested service from the system. Target is to get a 100% Accessibility, i.e., all users always get the service they request. Poor Accessibility is typically due to
- some sort of congestion
- hardware/software fault (Check ALARMS, Cells Downtime, tickets in REMEDY…)
- misconfiguration (AUDIT the settings in RNC)
- other reasons (for instance, it is also possible that there is some external source of interference (such as a microwave link on the same frequency) affecting the accessibility)
Accessibility is to be monitored independently for the different RAB types (e.g. Speech, CS Video, PS Interactive R99, PS Interactive HSDPA, etc.) as in certain situations only one of the RAB types will be affected.
2.1 Idle Mode
Accessibility issues may occur related to the UE idle mode behavior. The UE in Idle mode performs next 5 main tasks [please refer to ANNEX I for a brief review]:
- PLMN selection and reselection
- Reading system information (MIB, SIB)
- Cell selection and reselection
- Location area (LA) and routing area (RA) registration/update
- Paging procedure Settings should guarantee that the UE in idle mode is always in the best conditions to access the network (i.e., to initiate a Mobile Originated call, MO) and be reached by the network (i.e., to receive a Mobile Terminated call, MT).
2.2 Call Establishment Process Each step in the Call Establishment process should be monitored in order to clearly identify where the accessibility issue is located. (for a more complete review of the Call Establishment Process, please refer to ANNEX II.)
3 ACCESSIBILITY KPIs (Key Performance Indicators)
Below the main metrics used for Accessibility Monitoring of a 3G WCDMA/UMTS Network, and their implementation with Huawei counters.
3.1 High Level KPIs
3.1.1 Call Setup Success Rate - CSSR (%)
This is the first “overall” metric we are considering to monitor Accessibility as a whole. This KPI is typically calculated by considering just 2 steps in Call Establishment: RRC Connection Setup and RAB Establishment. They are assumed to be independent processes, and therefore CSSR is hence calculated as product of the Success Rates of each of these 2 phases (described later in section 3.2):
where (RAB) = CS.Conv, CS.Str Low value (e.g. <95%) indicates problems to establish a CS call between UEs and CS domain CORE. Similar formulas can be used for each specific RAB CSSR, i.e., Voice_CSSR (%) or CS64 CSSR (%).
3.1.1.2 PS CSSR (%)
(For PS connection requests, both R99 PS and HS) PS_CSSR = 100*sum((RRC.SuccConnEstab.OrgStrCall +RRC.SuccConnEstab.OrgItrCall+RRC.SuccConnEstab.OrgBkgCall+ RRC.SuccConnEstab.TmStrCall+RRC.SuccConnEstab.TmItrCall+RRC.SuccConnEstab.TmBkgCall)/(sum (RRC.AttConnEstab.OrgStrCall+RRC.AttConnEstab.OrgInterCall+RRC.AttConnEstab.OrgBkgCall+ RRC.AttConnEstab.TmStrCall+RRC.AttConnEstab.TmInterCall+RRC.AttConnEstab.TmBkgCall)) * (sum(VS.RAB.SuccEstab[RAB])/sum(VS.RAB.AttEstab[RAB]) where (RAB) = Conv, Str, Inter, Bkg Low value (e.g. <95%) indicates problems to establish a PS call between UEs and PS domain CORE. Similar formulas can be used for each specific RAB CSSR, i.e., PS Conversational CSSR (%), PS Streaming CSSR (%),
PS Interactive CSSR (%) or PS Background CSSR (%).
3.1.2 Overall Service Accessibility - OSAC (%)
Since there are many different services defined in UMTS and each one can have a different accessibility at any time, an overall service accessibility can be defined to obtain an overall measure of network accessibility averaged over all services. This metric can be used in case one single measurement is to be applied to sort out the worst overall inaccessible cells. The OSAC criterion will be based on a weighted averaging of the accessibility for the CS and PS services supported by the cell. The weighting factors will be chosen to be the demand for the service given by the number of RAB Establish attempt for that service. OSAC = 100 * [(CS CSSR * CS RAB Assignment Request) + (PS CSSR * PS RAB Assignment Request)] /
Sum(# CS & PS RAB Assignment Request) where: CS/PS CSSR = Call Setup Success Rate, as described in the previous section.
Low value (e.g. <95%) indicates problems to establish a generic radio connection between UEs and RNC starting from idle mode state.
3.2.1.1 RRC Connection Success Rate CS (%)
(For CS connection requests) Low value (e.g. <95%) indicates problems to establish a radio connection between UEs and RNC starting from idle mode state in particular affecting CS services (speech and video calls). 3.2.1.2 RRC Connection Success Rate PS (%)
(For PS connection requests)
Low value (e.g. <95%) indicates problems to establish a radio connection between UEs and RNC starting from idle mode state in particular affecting PS services. 3.2.2 Iu Signalling Establishment Success Rate (%)
(For all connection requests) Low value (e.g. <95%) indicates problems to establish the Iu part of the Control Plane between the RNC and CORE. (Note these counters are only available at RNC level). Notes:
Counters VS.IU.SCCP.Rx.Con.Req and VS.IU.SCCP.Rx.Con.Succ need to be included in the formula above if we want to consider the success of Iu Signaling Establishments for Paging Type 1 to Idle UEs
Successful Establishments of Iu Interface are not available per domain (CS, PS) however counters VS.IU.SIG.AttConnEstabCS and VS.IU.SIG.AttConnEstabPS could be used to estimate their contribution at RNC level.
Where (RAB) = CS.Conv, CS.Str, PS.Conv, PS.Str, PS.Inter, PS.Bkg Note that PS RAB counters do not differentiate between R99 traffic and HSPA traffic. Low value (e.g. <95%) indicates problems to establish a RAB after the RAB assignment coming from the CORE network. 3.2.4 HSDPA Establishment Success Rate (%)
Low value (e.g. < 95%) indicates problems to establish an HSDPA connection. 3.2.5 HSUPA Establishment Success Rate (%)
Low value (e.g. < 95%) indicates problems to establish an HSDPA connection. 3.2.6 Sending Paging Failure Rate (%)
High value (e.g. >2%) indicates problems to send paging through the radio network due to overload.
Implemented through the GRADE OF SERVICE (GoS): Probability of a call in a circuit group being blocked or delayed for more than a specified interval, expressed as a common fraction or decimal fraction. 3.2.7.1 GoS CS (%)
Where (RAB) = CS.Conv, CS.Str
High value (e.g. >2%) indicates problems to establish a Voice call mainly related to Admission Control, i.e., due to some kind of capacity shortage (DL TX Power, CE, OVSF codes,…). Note that the RRC connection blocking term cannot be specified in Huawei for CS or PS RRC connections. Therefore, this term evaluates the global GoS for the RRC connection Setup (CS and PS all together plus signaling ). To avoid any distortion in the metric due to this fact, a simple possibility is just to remove this term from the formula above.
3.2.7.2 GoS PS (%)
Where (RAB) = PS.Conv, PS.Str, PS.Inter, PS.Bkg High value (e.g. >2%) indicates problems to establish a PS call mainly related to Admission Control, i.e., due to some kind of capacity shortage (DL TX Power, CE, OVSF codes,…). In fact, VS.RAB.FailEstPS.Unsp is the Number of PS RABs unsuccessfully established because of insufficient capability of UTRAN (cause value: Requested Traffic Class not Available, Requested Maximum Bit Rate not Available, Requested Maximum Bit Rate for DL not Available, Requested Maximum Bit Rate for UL not Available, Requested Guaranteed Bit Rate not Available, Requested Guaranteed Bit Rate for DL not Available, Requested Guaranteed Bit Rate for UL not Available, or Requested Transfer Delay not Achievable). Another contribution that could be added to the RAB term is VS.RAB.FailEstPS.NResAvail: Number of PS RABs unsuccessfully established because of lack of system resources, for instance, a shortage of memory (cause value: No Resource Available)
Note that the RRC connection blocking term cannot be specified in Huawei for CS or PS RRC connections. Therefore, this term evaluates the global GoS for the RRC phase of the Call Establishment (CS and PS all together). To avoid any distortion in the metric due to this fact, a simple possibility is just to remove this term from the formula above.
If one (or more) of the main KPIs present performance below operator’s acceptable triggers we should carry an analysis to find out the root cause. To do so, we move towards an in-depth analysis based in more detailed and specific raw counters (Low Level KPIs).
In the case of Huawei infra, this analysis for Accessibility issues will explore in 3 different directions:
Note: A 4
th line of investigation has been added at the end of the section to cover those Accessibility issues not
detected by counters. 4.1 Admission Control
The purpose of the Admission Control is to limit the traffic that is admitted in order to ensure that all traffic that is admitted meets the requirements on the quality of the service. 4.1.1 Admission Policy
When new resources are needed for a radio connection, the RN Admission Control function receives a request for admission. The request specifies the estimated amount of system resources that the radio connection needs. UE Access Control consists of the Call Admission Control (CAC) and the Intelligent Access Control (IAC). The access control procedure for improving the access success rate is called Intelligent Access Control (IAC). The IAC procedure includes DRD, rate negotiation, queuing and preemption. The following figure describes a typical procedure for service access control. It shows the relationship between the IAC algorithms and CAC algorithms. For further details, please refer to Huawei documentation [See References].
4.1.2 Resources to be monitored
4.1.2.1 RF Power (Lack of DL Power)
- VS.RRC.Rej.Power.Cong
- VS.RAB.FailEstCs.Power.Cong
- VS.RAB.FailEstPs.Power.Cong)
Note: Huawei calls Power Resource to both DL Power and UL Interference 4.1.2.2 Code Tree Consumption (Lack of OVSF Codes)
- VS.RRC.Rej.Code.Cong
- VS.RAB.FailEstCs.Code.Cong
- VS.RAB.FailEstPs.Code.Cong 4.1.2.3 UL and DL Channel Elements (lack of Channel Elements)
- VS.RRC.Rej.DL.CE.Cong
- VS.RAB.FailEstPs.DLCE.Cong
- VS.RRC.Rej.UL.CE.Cong
- VS.RAB.FailEstPs.ULCE.Cong 4.1.2.4 Iub bandwidth (lack of BW)
- VS.RRC.Rej.DLIUBBandCong
- VS.RAB.FailEstab.CS.DLIUBBand.Cong
- VS.RAB.FailEstab.PS.DLIUBBand.Cong
- VS.RRC.Rej.ULIUBBandCong
- VS.RAB.FailEstab.CS.ULIUBBand.Cong
- VS.RAB.FailEstab.PS.ULIUBBand.Cong
4.2 SPM Load
The Service Processing Module (SPM) is the basic service processing unit of the RNC. An SPM consists of two SPUa (Signaling Processing Unit) boards (active/standby) and two DPUb (Data Processing Unit) boards. One SPM supports 100
NodeBs and 300 cells. Among other functions the SPU Board processes high-layer signaling of the Uu/Iu/Iur/Iub interfaces, such as the RRC
signaling of the Uu interface. In case a poor RRC Success Rate (consider UE NoReply events as a possible signature) is detected and Admission Control can not explain such a degradation of the RRC Accessibility, then check these counters: VS.SPU.CPULOAD.MAX Maximum CPU Usage of SPU VS.SPU.CPULOAD.MEAN Mean CPU Usage of SPU VS.SPU.CPULOAD.OVER Percentage of SPU CPU Usage over Alarm Threshold Unbalancing load between SPMs may cause RRC connection issues.
4.3 After Admission
Number of Radio Resource Control (RRC) or Radio Access Bearer (RAB) establishment requests failed after being admitted by admission control. Follows a list of causes for failures after admission:
a) Transport failures
TN failure reasons
AAL2 setup failure (due to congestion or miss configuration)
b) Core Transport Network Congestion 4.3.1 Failure after Admission: Transport failures
4.3.1.1 Low RRC Success Rate
In case a poor RRC Success Rate is detected and Admission Blocks rejections can not explain such a degradation of the RRC Accessibility, then check these 2 counters: VS.RRC.Rej.RL.Fail
Number of RRC CONNECTION REJECT messages from the RNC to UEs in a cell due to RL setup failure(except RL setup failure because of CE congestion)
VS.RRC.Rej.AAL2.Fail Number of RRC CONNECTION REJECT messages from the RNC to UEs in a cell due to AAL2 setup failure
4.3.1.2 Low RAB Success Rate
Similar analysis can be done for RABs Blocked due to transport network failures including:
CS:
PS:
4.3.2 Failure after Admission: Core Transport Network Congestion
Accessibility issues are observed on all sites at the RNC without major issues with Iub congestion (especially at peak hour): Congestion will be observed at Iu-CS (RNC<-->MSC) or Iu-PS (RNC<-->SGSN) links.
Possible indicators: Degradation of KPIs Iu(CS/PS) Signalling Establishment Success Rate (%) would be expected in this case.
Possible solutions: This issue will require support from the Operation and Maintenance department (OMC) in order to determine the reasons for that high utilization over Iu-CS and Iu-PS links.
If a site shows none of the previously described issues, then it is likely to be a more complicated problem to solve; often relating to a software/hardware fault, or perhaps an external source of interference in the area. Check for neighboring sites: Remember that neighboring sites having AAL2 congestion can cause other cells to have high number of failures after admission (due to soft handover) Check that software revisions are up to date at the Node B Check for unexpected figures in counters VS.RAB.FailEstPS.RNL Number of PS RABs unsuccessfully established because of radio network layer failures. This counter is sum of the following 4 ones:
VS.RAB.FailEstPS.Unsp Number of PS RABs unsuccessfully established because of insufficient capability of UTRAN (cause value: Requested Traffic Class not Available, Requested Maximum Bit Rate not Available, Requested Maximum Bit Rate for DL not Available, Requested Maximum Bit Rate for UL not Available, Requested Guaranteed Bit Rate not Available, Requested Guaranteed Bit Rate for DL not Available, Requested Guaranteed Bit Rate for UL not Available, or Requested Transfer Delay not Achievable)
VS.RAB.FailEstPS.Par Number of PS RABs unsuccessfully established because of parameter failures (cause value: Invalid RAB Parameters Value, Invalid RAB Parameters Combination, Condition Violation for SDU Parameters, Condition Violation for Traffic Handling Priority, or Condition Violation for Guaranteed Bit Rate)
VS.RAB.FailEstPS.Relo Number of PS RABs unsuccessfully established due to relocation (cause value: Relocation Triggered)
VS.RAB.FailEstPS.RIPFail Number of PS RABs unsuccessfully established because of radio interface failure (cause value: Failure in the Radio Interface Procedure)
4.4 Accessibility issues not detected by counters Some kinds of RRC failures could not be detected by counters or other traces. This typically happens when the RRC Connection Request messages from the UE cannot reach the RNC. In this case the accessibility KPIs are not able to reveal the problem, but it could be reported by
- user’s complaints
- drive test activities
- variations of the expected traffic level
Typical causes are: 4.4.1 HW Problems in the RBS
- Antenna system failures
- BBU boards failures
- Cell unavailability Most of the related problems should raise an alarm.
4.4.2 UL Interference
Strong UL Interference could also be the cause of some Accessibility issues not clearly detected by counters described so far. It can be monitored by checking: VS.MeanRTWP: Mean RTWP of a cell > -95 dBm, consistently. VS.MaxRTWP: Maximum RTWP of a cell > -90 dBm, consistently. 4.4.3 RACH misconfiguration
Check RACH parameters to look for a wrong setting: AICHPowerOffset PowerRampStep PowerOffsetPpm PreambleRetransMax Mmax Constantvalue MaxAllowedUlTxPower 4.4.4 Cell/NodeB Unavailability
Check Cell/NodeB unavailability through the following counter: VS.Cell.UnavailTime.OM VS.NodeB.UnavailTime.OM 4.4.5 Lack of system resources
VS.RAB.FailEstPS.NResAvail Number of PS RABs unsuccessfully established because of lack of system resources, for instance, a shortage of memory (cause value: No Resource Available)
5 REFERENCES [1] WCDMA (UMTS) Deployment Handbook. Planning and Optimization Aspects. Christophe Chevallier, Christopher Brunner, Andrea Garavaglia, Kevin P. Murray, Kenneth R. Baker (All of QUALCOMM Incorporated California, USA). Ed. John Wiley & Sons. 2006 [2] Radio Network Planning and Optimisation for UMTS. Jaana Laiho and Achim Wacker [Both of Nokia Networks, Nokia Group, Finland] & Tomas Novosad [Nokia Networks, Nokia Group, USA]. Ed. John Wiley & Sons. 2006 [3] WCDMA Radio Access Network Optimization. LZT 123 8297 R1C. Ericsson 2006.
[4] HED 5.5. NodeB Documentation (V100R010_06)
[5] RAN6.1 Feature Description [6] RAN10.0 Network Optimization Parameter Reference-20080329-A-1.0 [7] NodeB WCDMA V100R010C01B051 Performance Counter Reference [8] Function List and Description of Huawei UMTS RAN10[1].0 V1.7(20080827)
6 ANNEX I: UE Idle Mode Procedures PLMN selection is the first step in the registration process that allows a UE to initiate or receive services from an operator. The UE normally operates on its Home PLMN. However, a Visited PLMN (VPLMN) may be selected if the UE loses coverage. A UE successfully registers on a PLMN if it finds a suitable cell to camp on within the selected PLMN. The UE will
then obtain a location or routing registration acknowledgement in the area of the cell on which it is camped. The UE displays to the user that this PLMN is registered. When a UE does not find a suitable cell in the selected PLMN, it tries to camp on any other acceptable cell within an
allowed PLMN. When there is a suitable cell available normal services can be obtained in the cell. If there is an acceptable cell available only emergency calls are available, and if in automatic mode, new PLMN selection.
6.1 PLMN Selection and Reselection
PLMN selection is a NAS function, but the AS provides the list of available PLMNs from which the selection is made. AS reports all successfully read PLMN identities to the NAS, in 2 groups:
Those that meet the high quality criterion:
RSCP CPICH >= -95 dBm, for FDD cells RSCP CPICH >= -84 dBm, for TDD cells RSSI CPICH >= -85 dBm, for GSM cells
Those that do not. These ones together with their measured CPICH RSCP value, so they can be ranked.
The standard allows for the optimization of this measuring and reporting process through the use of stored information in the UE regarding carrier frequencies and other cell parameters as scrambling codes. Once a suitable list of available PLMNs is compiled, it is up to the NAS to select a PLMN for registration. This may be done automatically or manually. IN automatic mode the available PLMNs are listed in priority order and the highest priority PLMN is selected. In manual mode a list of the available PLMNs is presented to the user in priority order, but the user may select any PLMN from the list. Prioritization for both modes is as follows: 1. Home PLMN (HPLMN) 2. PLMNs in the “User Controlled PLMN Selector with Access Technology” data field in the SIM in priority order. 3. PLMNs in the “Operator Controlled PLMN Selector with Access Technology” data field in the SIM in priority order. 4. Other PLMNs that meet the high-quality criterion in random order. 5. Other PLMNs that do not meet the high-quality criterion in order of decreasing signal quality.
Once a PLMN is selected this is indicated to the AS along with the selected radio access technology.
6.2 Reading System Information
The System Information Block (SIB) messages are sent on BCCH logical channel, which can be mapped:
- to the BCH for UEs in idle mode, Cell_PCH and URA_PCH
- or the FACH transport channel for UEs in Cell_FACH. To inform the UE if a change in System information has occurred, the MIB also delivers a value tag for each SIB.
To inform UEs in idle mode, Cell_PCH and URA_PCH of a change in the system information, paging (“Paging type 1”) is used to deliver the IE “BCCH modification info” to notify the new value tag for the MIB. WCDMA RAN can also inform of the change in the system information with a System Information Change Indication message on the FACH transport channel.
6.3 Cell Selection and Reselection
6.3.1 Cell Selection
Next figures summarize the process.
6.3.2 Cell Reselection
Next figure summarizes the process.
6.3.3 Location/Routing Area Update
LA and RA updating is necessary to inform the CN of the current LA or RA of the UE, so that the network can send a paging message to the UE. There are three types of LA and RA registration updates:
- International Mobile Subscriber Identity (IMSI) attach or detach
- Normal LA and RA updating
- Periodic LA and RA updating (T3212, T3312) A border RBS can handle less traffic than an RBS placed inside the LA, due to the increased signalling load. Therefore, it is recommended that he LA/RA borders should be placed in areas with low traffic. If the LAs/RAs are small, there will be more LAUs/RAUs in the system and a high number of border RBSs. On the other hand, if the LAs/RAs are large the number of paging messages will increase. If the same LAI/RAI is used for the GSM and WCDMA networks, the consequence is heavy paging load in 3G arising from the GSM subscribers.
RRC MODES and STATES
LA/RA UPDATE vs. CELL UPDATE vs. URA UPDATE
6.3.4 Paging Procedure
Paging Type 1 (to UE in idle mode or dormant state: Cell_PCH/URA_PCH)
- UE terminating service request for PS or CS services (CN initiated).
- UTRAN initiated broadcast to inform UEs when SI is modified.
- Channel switch from state URA_PCH to CELL_FACH (UTRAN initiated) Two different physical channels are used in order to exchange proper information between the WCDMA RAN and the UE: the PICH and the S-CCPCH (carries the PCH). There is a fixed timing relation between a PICH frame and the associated S-CCPCH frame. Discontinuous Reception (DRX): The UE listens to the PICH only at certain predefined times, reducing power consumption. The paging record varies in length depending on whether it includes the UE identity in terms of IMSI, TMSI, or P-TMSI. A PCH frame can carry one “Paging Type 1” message of 10 ms and may contain between 3-5 paging records, depending on whether the paging uses IMSI or TMSI/P-TMSI.
Paging Type 2 (to UE in Cell_DCH or Cell_FACH)
- UE terminating service request for PS or CS services (CN initiated). When a connection exists between the WCDMA RAN and the UE, the SRNC determines that a RRC connection has already been established by this UE and the RRC message "Paging type 2" is used to carry paging information. Since it is sent on a dedicated control channel, this message is intended only for one particular UE. For paging, the capacities of the FACH and the RACH are assumed to be enough, but there is a risk of congestion in the PCH due to heavy paging load. Therefore, the probability of congestion in the PCH must be calculated in order to dimension the LA/RA.
7 ANNEX II: Call Establishment Procedure
7.1 Voice Call Establishment
7.2 PS Data Call Establishment
7.3 Radio Resource Control (RRC)
RRC is the overall controller of the Access Stratum, responsible for configuring all other layers in the Access Stratum and providing the control and signalling interface to the NAS layer.
- Broadcast of System Information
- RRC Connection Management
- Radio Bearer Management
- RRC Mobility Functions
- Paging and Notification Functions
- Routing of Higher Layer Messages
- Control of Ciphering and Integrity Protection
- Measurement Control and Reporting
- Power Control Functions
RRC manages radio resources, including allocation, deallocation, and configuration of Logical, Transport, and Physical Channels, measurement reporting, security procedures, and overall management of the Access Stratum.
7.3.1 RRC connection Request & Setup
The RRC Connection Setup establishes SRBs (Signalling Radio Bearers) to carry dedicated signalling. This phase of the call establishment is identical for CS and PS calls (both MO and MT) and it is always composed by next three messages:
1. RRC Connection Request (RACH, in UL) 2. RRC Connection Setup (FACH, in DL) 3. RRC Connection Setup Complete (DCH, in UL)
It is important to note that this signalling is also needed when the UE performs Periodic Registration/ LAU/RAU/Detach as part of the Mobility Management. In these cases, the purpose of the RRC connection setup is not to establish a call (CS or PS), and therefore, there will not be RAB setup phase. The RRC connection request contains the UE identity, optional cell measurement results, and the establishment cause. For speech AMR service, this cause is recorded as either “Originating Conversational Call” or “Terminating Conversational Call”. For PS service, this cause is recorded as “Originating/Terminating Interactive/Background Call”. Successfully establishing the RRC connection is the most challenging part of call setup. This can be attributed to two factors: the admission control implementation and the size of the RRC Connection Setup message. The latter is the main challenge. During admission control implementation, an RRC connection reject is sent if no resources are available for allocation, or if the call should be redirected to a different system or carrier. After successful resource allocation, the RRC Connection Setup message–which contains SRB information including the mapping details of dedicated logical, transport, and physical channels–is sent on the Forward Access Channel (FACH) (over [Downlink Secondary Common Control Physical Channel] [DL SCCPCH]). This RRC Connection Setup message contains a significant amount of information, and it spans multiple frames while not yet operating in closed loop power-controlled condition. This makes it difficult for the UE to receive the message, especially if the SCCPCH power allocation is not set to accommodate low geometry. After the RRC Connection Setup message is received, the UE can set up the low data rate DCH according to the RRC Connection Setup message. First, only the PDCCH containing Transmit Power Control (TPC) and Pilot bits are sent to allow the inner loop power control to converge. Afterwards, the RRC Connection Setup Complete message is used to acknowledge the setup message and send UE-capability information to the network. At this point, the UE should have transitioned from Idle state to CELL DCH state. At this time, the connection is power-controlled and may support handover, depending on the Universal Terrestrial Radio Access Network (UTRAN) implementation. Both features improve the reliability of the connection.
7.4 Core Network Negotiation
The low data rate DCH facilitates upper layer signaling with the NAS layer, which performs all authentication and security procedures along with additional processes in the CN to establish the end-to-end connection. To initiate the connection request to the upper layers, MO calls use the Connection Management (CM) Service Request and MT calls use the paging response. In the CM Service Request message, the CM Service Type field indicates “Mobile originating call establishment” as the cause for a MO AMR call. The Paging Response message does not need to carry service information because the NAS layer already knows what service is being set up for the MT call. To perform two-way authentication, the UE checks the Authentication Token (AUTN) nd the network checks the Signed Authentication Response (SRES), which is calculated from the RAND number from the network. Depending on the supported security capabilities, ciphering and integrity protection are switched on to enable encryption of user data and signaling messages. For MO calls, the UE sends main parameters such as bearer capabilities and dialed digits to the network using the Call Control (CC) Setup message. For MT calls, the network uses the Setup message to send the same, or similar, information to the UE. The next step is similar; MO calls use Call Proceeding messages (UTRAN to UE), while MT calls use Call Confirmed messages (UE to UTRAN) as a Layer 3 acknowledgment.
7.5 Radio Access Bearer (RAB) Setup and Reconfiguration After the CN negotiation, the UE can establish the DCH(s) for the requested service. Existing DCHs also may be reconfigured to meet the requirements, depending on the current configuration. Before sending the RB Setup message, call admission control must be checked and resource allocation performed for every resource involved in a call. For AMR voice, the UE typically sets up three dedicated logical/transport channels mapped onto one CCTrCh. Information in the RB Setup message is similar to the RRC Connection Setup:
NAS Layer 2. Radio Bearer/logical/transport channel mapping
Layer 2. Channel coding, Radio Link Control (RLC) parameters, TTI, BLER targets, Transport Format Combination Set (TFCS)
Layer 1. Spreading Factor (SF), OVSF code, Scrambling Code, frame offset, power control parameters At this point, the radio link is completely established; however, the end-to-end connection is not yet fully established:
The Alerting message is sent from the network to the UE for MO calls, or from the UE to the network for MT calls.
The directions for Connect and Connect ACKnowledge (ACK) are reversed, depending on the call type.
The Connect message is sent by the UTRAN for MO calls, but by the UE for MT calls. The RB Setup message can also be used as a reconfiguration message because the existing SRBs are, from this point forward, multiplexed with RAB onto a single physical dedicated channel.
