FACH Trial Result v0.1

8/11/2019 FACH Trial Result v0.1

http://slidepdf.com/reader/full/fach-trial-result-v01 1/16

FACH Trial with Huawei RAN11



Objective

1. To enable FACH in Huawei RAN11

2. FACH will be testing in both configuration

a) All HS Configuration: F1 and F2 both carry R99 and HS

b) CS/HS Configuration: F1 for R99 ; F2 dedicated for HS

3. Evaluate effectiveness of FACH in optimization Node-B

resources



Huawei Algorithm for DCH FACH

• Down-switch from Cell_DCH to Cell_FACH in Huawei RAN is based on Buffer onand govern by a Timer

64Byte

5s

Time-to-trigger

1s

DCH to FACH

Transition Time

Pending-Time-after-trigger

5s

Trigger Event

4b

DCH to FACH

Transition

When the user buffer is less than 64Byte, it will

trigger an Event-4b. For a duration of 5s, if the

buffer is still below 64Byte

=Down-switch from DCH to FACH



FACH to Idle Channel Switching in Huawei

CELL_DCHCELL_FACH

IDLE

RRC conn ect ion

FACH to Idle

timer is 20s20s

1025byte

FACH to DCH when

there is more than

1024byte in the

buffer



Dual-HS Configuration (Signaling Flow)

R99 / HS

R99 / HS

F2

F1

DCH

FACH

IDLE

Radio Bearer Reconfiguration (FACH triggered)

1

2RB Reconfig Complete

3

4

RRC Release (After 20s)

DCH

FACH

IDLE

RB Reconfiguration (FACH triggered)

1

2 RB Reconfig Complete

3

4

UE transit from

FACH to DCH

using RB

Reconfiguration

RRC Release (After 20s)

UE transit from

FACH to DCHusing RB

Reconfiguration



Trial Result: CSSR

PS CSSR Success Rate

0.00%

20.00%

40.00%

60.00%

80.00%

100.00%

120.00%

5 4 t h A p r i l

6 t h A p r i l

1 2 t h A p r i l

1 3 t h A p r i l

PS CSSR Normal

CS CSSR Normal

CS CSSR Success Rate

0

20

40

60

80

100

120

5 4

t h A p r i l

6

t h A p r i l

1 2

t h A p r i l

1 3

t h A p r i l



Trial Result: PS Drop

PS Drop Call Rate

0.00%

1.00%

2.00%

3.00%

4.00%

5.00%

6.00%

7.00%

5 4 t h A p r i l

6 t h A p r i l

1 2 t h A p r i l

1 3 t h A p r i l

1. PS Drop Call Rate degraded. Notice higher peak drop during night during busy hour

2. Huawei still investigating why PS drop increased when FACH is enabled for HS. Nevertheless higher drop

rate is expected as FACH is paired with RACH on the uplink. Since both channels are not power controlled,

some degradation is expected

3. PS drop also occur in FACH state. Predominantly user has low data activity in FACH state, this drop does

not severely impact customer experience

4. Do note, PS drop refers to RF drop , not a PDP drop. Subscriber connection still active but will lead totemporarily discontinuity of data transfer until the radio bearer is re-established.



Trial Result: FACH and DCH ChannelSwitching Success Rate

1. Channel switching success is healthy. Close to 100%

2. If FACH is enabled, this KPI must be monitored to ensure channel switching does take place between FACH

and DCH

Channel Switching Success Rate

0%

20%

40%

60%

80%

100%

120%

1 2 t h A p r i l

1 3 t h A p r i l



Trial Result: FACH To Optimize RadioResource (HSDPA) 1 of 2

No of Active HS Users

0

2000

4000

6000

8000

10000

12000

0 0 : 0 0

0 1 : 0 0

0 2 : 0 0

0 3 : 0 0

0 4 : 0 0

0 5 : 0 0

0 6 : 0 0

0 7 : 0 0

0 8 : 0 0

0 9 : 0 0

1 0 : 0 0

1 1 : 0 0

1 2 : 0 0

1 3 : 0 0

1 4 : 0 0

1 5 : 0 0

1 6 : 0 0

1 7 : 0 0

1 8 : 0 0

1 9 : 0 0

2 0 : 0 0

2 1 : 0 0

2 2 : 0 0

2 3 : 0 0

5th April (No FACH) 6th April (No FACH)

12th April (FACH) 13th April (FACH)

HS users reduced

by 3K by enablingFACH (26%

reduction)

1. FACH can better optimize radio resources

particularly scheduler resource. During peak

hour, number of concurrent HSDPA in the

scheduler has reduced by around ~3K

2. By enabling FACH, user with low dataactivity will switch to FACH state giving way

to users who require scheduler resource

3. Overall no improvement in HSDPA User

Throughput

*Huawei per cell can support 64 concurrent HSDPA users

HSDPA User Throughput

0

20000

40000

60000

80000

100000

120000

140000

160000

0 0 : 0 0

0 1 : 0 0

0 2 : 0 0

0 3 : 0 0

0 4 : 0 0

0 5 : 0 0

0 6 : 0 0

0 7 : 0 0

0 8 : 0 0

0 9 : 0 0

1 0 : 0 0

1 1 : 0 0

1 2 : 0 0

1 3 : 0 0

1 4 : 0 0

1 5 : 0 0

1 6 : 0 0

1 7 : 0 0

1 8 : 0 0

1 9 : 0 0

2 0 : 0 0

2 1 : 0 0

2 2 : 0 0

2 3 : 0 0

K

b p s


12th Apri l (FACH) 13th Apri l (FACH)



Cell Distribution of HSDPA Users (Max of the day)

0

100

200

300

400

500

600

700

5 10 15 20 25 30 35 40 45 50 55 60 65

Number of HSDPA Users

N u m b e r o f C e l l

Count w/o FACH

Count w FACH


1. By having FACH, we can avoid scheduler congestion by optimization radio resource

2. From the trial , cell with high number of HSDPA users reduced. Help to resolve HSDPA scheduler

congestion

Cell with extreme high

number of concurrent

HSDPA users



No of Active HSUPA Users

0

1000

2000

3000

4000

5000

6000

7000

0 0 : 0 0

0 1 : 0 0

0 2 : 0 0

0 3 : 0 0

0 4 : 0 0

0 5 : 0 0

0 6 : 0 0

0 7 : 0 0

0 8 : 0 0

0 9 : 0 0

1 0 : 0 0

1 1 : 0 0

1 2 : 0 0

1 3 : 0 0

1 4 : 0 0

1 5 : 0 0

1 6 : 0 0

1 7 : 0 0

1 8 : 0 0

1 9 : 0 0

2 0 : 0 0

2 1 : 0 0

2 2 : 0 0

2 3 : 0 0

U s e r


12th April (FACH) 13th April (FACH)

Trial Result: FACH To Optimize RadioResource (HSUPA) 1 of 2

HSUPA users

reduced by 1.4K

by enabling FACH

(24% reduction)

1. Currently in Huawei RAN , Maxis only allows

10 concurrent HSUPA user per cell

2. With such low number of supported users,

FACH is critical to ensure HSUPA resourceis given to user requiring high bandwidth by

avoiding low activity user hogging HSUPA

resource

HSUPA User Throughput

25

30

35

40

45

50

55

60

65

70

0 0 : 0 0

0 1 : 0 0

0 2 : 0 0

0 3 : 0 0

0 4 : 0 0

0 5 : 0 0

0 6 : 0 0

0 7 : 0 0

0 8 : 0 0

0 9 : 0 0

1 0 : 0 0

1 1 : 0 0

1 2 : 0 0

1 3 : 0 0

1 4 : 0 0

1 5 : 0 0

1 6 : 0 0

1 7 : 0 0

1 8 : 0 0

1 9 : 0 0

2 0 : 0 0

2 1 : 0 0

2 2 : 0 0

2 3 : 0 0

K b p s

12t h Apri l (FAC H) 13 th Ap ri l (FACH)

5th Apri l (No FACH) 6th Apr il (No FACH)



Cell Distribution of HSUPA Users (Max of the day)

0

50

100

150

200

250

300

350

400

450

500

2 4 6 8 10

Number of HSUPA Users

N u m b e r o f C e l l

Count w/o FACH

Count w FACH


1. Each cell only support maximum 10 concurrent HSUPA users

2. Without FACH, close to 400 cells already loaded with maximum 10 concurrent HSUPA users

3. With FACH, number of cells with maximum 10 concurrent users has drop from 400 to around 150 cells

4. With FACH, this will help HSUPA capable cell to optimize their resources by mowing low activity user to

FACH and allow genuine HSUPA user to have a slot in the scheduler

Cell hitting

HSUPA limit of

10 concurrent

users



FACH Trial Summary for All HSConfiguration

1. All KPIs are healthy except PS drop call rate

2. Higher PS drop call rate is expected as FACH has no power control and on the uplink is paired with a

RACH channel which is a common channel on the uplink and again no power control

3. By enabling FACH, cell can better optimize the scheduler resource particular HSUPA resource as

number of supported HSUPA users are limited by noise rise. Typically each cell can only support

maximum 10 HSUPA users.

4. With FACH, low activity user will be pushed to FACH.

5. Channel switching between FACH and DCH is healthy , almost 100% success rate.

Recommendation

1. FACH is relevant and should be enabled to optimize radio resources due to proliferation of smart phones

which exhibit an always-on behavior but not necessarily downloading heavy data all the time.

2. Need to optimize FACH transmit power to ensure FACH transmission power could cover the entire cell

area since it has no power control capability. We also need optimize inactivity timer and fine tune channel

switching parameter



F1-CS and F2-HS Configuration: FACH Not workingProperly

HS

F2

F1

DCH

Radio Bearer Reconfiguration

FACH triggered

1

3

4

FACH

IDLE

Cell Update

6

RB Reconfig Complete

5

RRC Release RAN dueto state mismatch

Cell ReservedCell Reserved, cannot camp on

Cell:F2, UE reselect to Cell:F1

2

RNC is expecting RB reconfiguration

completed from UE via Cell: F2

Timer expired, RNC did not receive

RB Reconfiguration completed via

Cell:F2. RNC assume UE remains in DCH

state.

RNC pegged PS drop : UL Unsynchronized

RNC received cell update from UE

via F1 and realized state mismatch as RNC

presume the UE still in DCH state

RNC releases the UE due to state

mismatch

1a

2a

R99 / HS

3a

5a



Trace from RNC

Source: Huawei



FACH Trial Summary for F1-R99; F2-HSConfiguration

1. Maxis cannot enable FACH in such configuration

2. This will lead to High PS drop and uses are force to Idle state when FACH is triggered

3. Huawei is proposing not to cell-reserved F2 and uses Qoffset to maintain our F1-R99;

F2-HS configuration. This is not been tested yet in Maxis.

Documents

FACH Trial Result v0.1