Accesibility 3G
Accesibility 3G
Accesibility 3G
• RRC establishment
• Initial DT
• Authentication
• Security mode
• RAB assignment
RRC Establishment Counter and KPI
RRC Establishment
- RRC connection request
- Establishment request for different Causes
- Establishment request for different channels
VS.RRC.SuccConnEstab.CCH
VS.RRC.SuccConnEstab.DCH
RRC Establishment Counter (RNC)
RRC connection setup complete (RNC)
VS.RRC.SuccConnEstab.First.RNC
VS.RRC.SuccConnEstab.Second.RNC
VS.RRC.SuccConnEstab.Third.RNC
RRC Establishment Counter (RNC)
RRC connection setup failure (RNC)
VS.RRC.FailConEst.RNC
This measurement item provides the number of failed RRC connection setups. The value of
VS.RRC.FailConEst.RNC is equal to or greater than that of VS.RRC.FailConEst.Cng.RNC
When the RNC receives an RRC CONNECTION REQUEST message from the UEs and if the RRC
connection setup fails, the measurement of this item is triggered
RRC Establishment Counter (RNC)
RRC connection setup failure (RNC)
VS.RRC.FailConEst.Cng.RNC
- This measurement item provides the number of RRC CONNECTION REJECT messages that the
RNC sends to the UE in response to the RRC CONNECTION REQUEST message from the UE due
to network congestion
- The measurement is triggered at point A as shown in following figure. When the RNC sends the
UE an RRC CONNECTION REJECT message with the cause of "congestion", the measurement of
this item is triggered
RRC Establishment Counter (Cell)
RRC connection setup failure (Cell)
VS.RRC.FailConnEstab (Cell)
VS.RRC.Rej.ULIUBBand.Cong Number of RRC Connection Rejects for Cell (UL Iub Bandwidth Congestion)
VS.RRC.Rej.ULPower.Cong Number of RRC Connection Rejects for Cell (UL Power Congestion)
VS.RRC.Rej.DLPower.Cong Number of RRC Connection Rejects for Cell (DL Power Congestion)
VS.RRC.Rej.DLIUBBand.Cong Number of RRC Connection Rejects for Cell (DL Iub Bandwidth Congestion)
VS.RRC.Rej.ULCE.Cong Number of RRC Connection Rejects for Cell (UL CE Resource Congestion)
VS.RRC.Rej.DLCE.Cong Number of RRC Connection Rejects for Cell (DL CE Resource Congestion)
VS.RRC.Rej.Code.Cong Number of RRC Connection Rejects for Cell (Code Resource Congestion)
FLUJOGRAMA RAB ASSIGNMENT
CALL ADMISION CONTROL
Call Admission Control (CAC) is used to determine whether the system
resources in a cell are sufficient to accept a resource request.
If the system resources are sufficient, the resource request is accepted;
otherwise, the resource request is rejected
Resources:
When RSVDBIT11 under the RsvdPara1 parameter in the ADD UCELLALGOSWITCH command is
set to 1, the RNC implements code resource-based admission based on the cause carried in the
RRC connection setup request:
- If the cause is "Emergency Call" or "Detach", code resource-based admission succeeds if the
remaining code resources are sufficient.
- For any other cause, the RNC must ensure that the remaining codes (the remaining minimum SF
of the current cell) do not exceed the reserved minimum spreading factor (SF) for an RRC
connection upon admitting an RRC connection setup request. The reserved minimum SF is
specified by RSVDBIT12 under the RsvdPara1 parameter in the ADD UCELLALGOSWITCH
command.
a. If RSVDBIT12 under the RsvdPara1 parameter is set to 0, the reserved minimum SF is SF128.
b. If RSVDBIT12 under the RsvdPara1 parameter is set to 1, the reserved minimum SF is SF32.
CAC Based on Code Resources
2. Handover Service Requests
For handover service requests, code resource-based admission succeeds if the remaining code
resources are sufficient for the service to be admitted.
When RSVDBIT11 under the RsvdPara1 parameter in the ADD UCELLALGOSWITCH command is
set to 1, code resource-based admission succeeds if the remaining code resources are sufficient for
the service to be admitted.
CAC Based on Power Resources
Power-based admission is used for RRC connection setup requests and radio access
bearer (RAB) admission. The power-based admission algorithm is enabled or disabled
by the NBMUlCacAlgoSelSwitch/NBMDlCacAlgoSelSwitch parameter.
CAC Based on Power Resources
Algorithm 1 (ALGORITHM_FIRST): admission control based on the expected load
increase caused by a new service
Depending on the current cell power load, the RNC determines whether the cell load
will exceed the threshold upon admitting the new service. If the cell load exceeds the
threshold, the RNC rejects the access request. Otherwise, the RNC admits the service.
If there is a rate downsizing request, the RNC accepts it directly. For a rate upsizing
request, both uplink and downlink admission control are required.
CAC Based on Power Resources
Strict Admission Control
If an RRC connection setup request comes from emergency calls or detachments, the
RRC connection is set up directly.
The RNC determines the admission threshold using the following formulas:
Admission threshold for RRC of real-time services = Admission threshold offset for
RRC of real-time services + UlNonCtrlThdForAMR (for the uplink) or
DlConvAMRThd (for the downlink)
Admission threshold for RRC of other services = Admission threshold offset for
RRC of other services + UlOlcTrigThd (for the uplink) or DlOlcTrigThd (for the
downlink)
CAC Based on Power Resources
The offsets in these three formulas vary with the settings of RSVDBIT8, RSVDBIT9,
and RSVDBIT10 under the RsvdPara1 parameter
CAC Based on Power Resources
Algorithm 1: UL/DL Power
Uplink
UL threshold of Conv AMR service
UL threshold of Conv non_AMR service
UL threshold of other services
UL handover access threshold Recommendation:
UL total power threshold
Algorithm 2: ENU
One uplink CE needs to be consumed by an uplink 12.2 kbit/s voice service (SF = 64)
plus 3.4 kbit/s signaling traffic.
One downlink CE needs to be consumed by a downlink 12.2 kbit/s voice service (SF =
128) plus 3.4 kbit/s signaling traffic.
CAC Based on NodeB Credit Resources
The relationship between NodeB credit resources and CEs is as
follows:
In the uplink, the quantity of NodeB credit resources is twice that
of CEs.
In the downlink, the quantity of NodeB credit resources equals
that of CEs.
CAC Based on the Number of HSPA Users
CAC for HSDPA Users
HSDPA admission control is based on the number of HSDPA users.
When a new HSDPA service attempts to access the network, the algorithm admits
the service if the following conditions are met:
The number of HSDPA users in the cell does not exceed the maximum value
specified by the MaxHsdpaUserNum parameter.
The number of HSDPA users in the cell does not exceed the licensed number of
users.
The number of HSDPA users in NodeB does not exceed the maximum value
specified by the NodeBHsdpaMaxUserNum parameter.
Otherwise, the HSDPA service performs Directed Retry Decision (DRD) to access one
of the cells that support blind handovers. If none of these cells can be accessed, the
HSDPA service is degraded to an R99 service and then attempts to access a cell.
CAC Based on the Number of HSPA Users
CAC for HSUPA Users
HSUPA admission control is based on the number of HSUPA users.
When a new HSUPA service attempts to access the network, the algorithm admits
the service if the following conditions are met:
The number of HSUPA users in the cell does not exceed the maximum value
specified by the MaxHsupaUserNum parameter.
The number of HSDPA users in the cell does not exceed the licensed number of
users.
The number of HSUPA users in NodeB does not exceed the maximum value
specified by the NodeBHsupaMaxUserNum parameter.
Otherwise, the HSUPA service performs Directed Retry Decision (DRD) to access one
of the cells that support blind handovers. If none of these cells can be accessed, the
HSUPA service is degraded to an R99 service and then attempts to access a cell.
Power Resources – Common Channels