UMTS CE Consumption - Uplink and Downlink

Uplink CE consumption is more than that of downlink. The reason is that CEs are not utilized  by HSDPA being a shared channel. HSUPA and R99, on the other hand, consume dedicated CS resources for their respective sessions.

UMTS - Analysis for Second Carrier Expansion

Second Carrier expansion can be proposed if there is low user throughput due to high number of users. One way of finding Node B/Cells that requires such an expansion is presented below. Extract the cell hourly level performance statistics of last 10 days and check for below criteria:

• RoT (Rise Over Thermal) >= 6dB and Cell DCH users >= 16
• HS User Throughout is less than 500 kbps and Average HSDPA users are larger than 16
• Non HSDPA TCP Utilization avg >=55% or max>=90%  and Cell DCH users >=16 

If these conditions are fulfilled by cells in at least 10 hours, the cell should be recommended for second carrier expansion. 

Note that second carrier expansion will not increase the peak user throughput, but the average user throughput is enhanced and so is the user QoS. The peak throughput is 21 Mbps for UMTS, however with Dual Carrier technology, the theoretical throughput limit is increased to as high as 42 Mbps.

UMTS Inter Vendor Hard Handover Issue Analysis

Hard handover could be an issue if two or more vendors are involved. Following steps can be taken to identify and kill the problem:

1. Neighbor configuration verification (LAC/RAC)
1. Definitions in both source and target RNC
2. Core network (MSC) definitions
2. Parameters check related to Hard Handver
1. Switch (Some vendors have Hard Handover Switch)
2. Threshold settings (could be too tight to initiate Handover)

A solved case scenario:

Ericsson to ZTE hard handovers were not taking place (there were no attempts at all). 

• Neighbors were correctly defined at both RNCs
• Core definitions were verified as well
• RNC trace analysis showed relocation failure message from MSC to RNC with eRANAP cause as "misc_unspecified_failure"

Source RNC Trace log

Core/MSC trace showed that relocation_request was being forwarded by the MSC to target RNC when relocation_required message is sent by source RNC. However, when target RNC did not respond with relocation_request_ack, the MSC sent the relocation_preparation_failure with "unspecified failure". This showed that target RNC (Ericsson) had some functional issue. On further investigation, it was found that Ericsson RNC had a switch parameter for hard handover which was disabled. Enabling it rectified the problem and hard handovers began to take place.

GSM - Low Paging Sucess Rate Issue

Paging discards can be a source low PSR or users complaining about getting "user not responding" messages as they call party B in GSM. The steps that can be taken to reduce or eliminate discards are as follows:

1- LAC Splitting
2- Cell paging capacity
      - can be increased of worst offenders
      - Shifting of SD/PD timeslots to non-BCCH TRXs
3- Audit of Periodic Location Update BSC Timer Value (t3212)
      - Can be set to 6 hours
      - This timer value at the MSC should be greater than the BSC value
4- Activation of Precise Paging Feature
      - Paging is done only on cells where there is high probability of finding subscribers according to the location record saved in the BSC

BS PA MFRMS - PSR Alcatel-Lucent

Improvement in PSR (Paging Success Rate) can be achieved by tuning of BS_PA_MFRMS and reducing Paging discards. Paging discards are mostly due to congestion in the BSC, on the Abis link and/or on the PCH (Paging Channel) ie Air interface.

Parameter:

• BS_PA_MFRMS

Target Cells: Cells with higher number of paging discards

Theory: 

• This parameter defines the the number of 51 multiframes between two consecutive occurrences of Paging group (a number of pagings)
• Higher value means less number of pagings will be transmitted in a given interval thereby conserving lesser power of the MS
• Reducing this parameter increases number of pagings per paging group (for a given value of MSC paging timer T3113) and therefore probability of no paging response decreases

Mobile Originating Call Flow

Here is the detailed Mobile Originating Call Flow divided into 4 functional modules depicting the network nodes for easy comprehension:

Sector Swap (Cross-sector) Issue

Sector-Swap Issue means that sector of a site is serving the area in a direction different to its azimuth. For instance, sector 1 is serving the area of sector 2 and sector 2 is serving the area of sector 1. This is known as complete Sector Swap. Another type is Partial Swap in which the logical area of say sector 1 is served partially by sector 2 and partially by sector 1 itself.

This problem arises due to jumbled cables at the BTS which could be caused due to human mistake during site maintenance activities. Issue can be diagonosed through Drive Test results as well as observing the number of Handover requests in Handover statistics of the site.



The issue can cause increase in CDR, RxQual degradation, increased DL interference,

Resolution can be done by closely following the cables from the antenna to the respective TRX of each sector of the BTS and correcting the cross-connections.