State Transition

Resultados do Trial
 State Transition
Resultados do Trial

Conteúdo
1. Introdução ........................................................................................................................................................ 3

1.1 Descrição .......................................................................................................................................... 3

1.2 Objetivos ........................................................................................................................................... 6

2. Procedimentos para ativação ..................................................................................................................... 7

2.1 Pré-requesitos ................................................................................................................................ 7

2.2 Ativação ............................................................................................................................................. 7

2.3 Cronograma de atividade ............................................................................................................ 8

2.4 Elementos de rede afetados ....................................................................................................... 8

2.5 Configuração recomendada ....................................................................................................... 8

3. Monitoramento ............................................................................................................................................... 9

4. Resultados ...................................................................................................................................................... 10

5. Conclusão ........................................................................................................................................................ 30

5.1 Próximos passos .......................................................................................................................... 30

1
 State Transition
Resultados do Trial

Lista de Figuras
Figure 1 – State transition scheme ............................................................................................................... 4
Figure 2 – D2F parameters ............................................................................................................................ 4
Figure 3 – F2P parameters ............................................................................................................................ 5
Figure 4 – F2D parameters ............................................................................................................................ 5
Figure 5 – Access stratum stack .................................................................................................................... 6
Figure 6 – Parametrization state transition .................................................................................................. 8
Figure 7 – RRC accessibility - CS .................................................................................................................. 10
Figure 8 – RAB accessibility - CS .................................................................................................................. 10
Figure 9 – RRC accessibility - PS .................................................................................................................. 11
Figure 10 – RAB accessibility - PS ................................................................................................................ 11
Figure 11 – RRC attempts - PS................................................................................................................... 172
Figure 12 – RAB attempts - PS .................................................................................................................... 12
Figure 13 – RRC attempts - CS..................................................................................................................... 13
Figure 14 – RAB attempts - PS .................................................................................................................... 13
Figure 15 – NBAP usage reduction.............................................................................................................. 14
Figure 16 – XPU load ................................................................................................................................... 14
Figure 17 – RRC connected users ................................................................................................................ 15
Figure 18 – CS user number ........................................................................................................................ 15
Figure 19 – HSPA user number ................................................................................................................... 16
Figure 20 – R99 user number ...................................................................................................................... 16
Figure 21 – Downlink credit usage .............................................................................................................. 17
Figure 22 – Uplink credit usage................................................................................................................... 17
Figure 23 – RRC radio link rejections .......................................................................................................... 18
Figure 24 – RRC no reply rejections ............................................................................................................ 18
Figure 25 – RAB PS failure ........................................................................................................................... 19
Figure 26 – RAB CS failure ........................................................................................................................... 19
Figure 27 – UTRAN paging ........................................................................................................................ 280
Figure 28 – RANAP paging........................................................................................................................... 20
Figure 29 – RRU power usage ..................................................................................................................... 21
Figure 30 – Uplink load ............................................................................................................................... 21
Figure 31 – Cellupdates causes ................................................................................................................... 22
Figure 32 – CS drop ..................................................................................................................................... 22
Figure 33 – PS drop ..................................................................................................................................... 23
Figure 34 – RAB normal release - inactivity ................................................................................................ 23
Figure 35 – RAB normal release .................................................................................................................. 24
Figure 36 – RAB abnormal release – PCH/CCH ........................................................................................... 24
Figure 37 – RAB abnormal release – Reset ................................................................................................. 25
Figure 38 – RAB abnormal release – UuNoReply and UlSync ..................................................................... 25
Figure 39 – Transition: HSDSCH-DCH .......................................................................................................... 26
Figure 40 – Transition: EDCH-DCH .............................................................................................................. 26
Figure 41 – Transition: HSDSCH-FACH ........................................................................................................ 27
Figure 42 – Transition: EDCH-FACH ............................................................................................................ 27
Figure 43 – Transition: FACH-PCH ............................................................................................................... 28
Figure 44 – FACH congestion - DTCH .......................................................................................................... 28
Figure 45 – FACH congestion - CCCH and DCCH ......................................................................................... 29

2
 State Transition
Resultados do Trial

1. Introdução
Diferente dos sistemas de segunda e quarta geração onde temos puramente dois estados: idle e
connected mode, no sistema UMTS da 3G temos mais subdivisões para o estado connected mode
(CELL_DCH, CELL_FACH, CELL_PCH e URA_PCH). O uso destes estados maximiza a capacidade do sistema
permitindo uma melhor experiência do usuário já que os recursos da rede são finitos.

Cada vez mais a demanda do trafego de dados é crescente em função do aumento da penetração
de smartphones e suas aplicações. Além dos estados CELL_DCH/FACH que estão ativos atualmente na
rede é necessário a ativação do estado CELL_PCH. Com a ativação desse estado permitimos que os
terminais que suportem CELL_PCH, não tenha toda conexão liberada depois um certo tempo de
inatividade (enviado a Idle mode) e após alguns segundos volte a solicitar novamente a conexão
(aplicações em background).

1.1 Descrição
Em CELL_DCH os usuários podem ativar chamada de voz, serviços HSPA e PS R99, mobilidade
realizada através de handovers e métodos de controle de potência de acordo o serviço. Já no estado
CELL_FACH o móvel só pode executar dados PS R99, mobilidade controlada através reseleção e sem
controle de potência (fixa em relação ao CPICH).

Em CELL_PCH e URA_PCH o móvel não pode transferir dados, ou seja, tem o mesmo
comportamento de Idle mode. A principal diferença entre esses estados Idle e CELL/URA_PCH é a conexão
RRC que é mantida, exigindo menos processos, recursos e delay para voltar aos estados de transferência
de dados/voz.

A distinção entre CELL_PCH e URA_PCH é como a RNC conhece a localização do terminal, no caso
de CELL_PCH a RNC sabe aonde está localizado a nível de célula e em URA_PCH o usuário é localizado a
nível de URA (entidade criada apenas na RNC que abrange um conjunto de células). Apesar que o
comportamento em CELL/URA_PCH obedece às características de idle mode, após uma reseleção os UEs
têm que informar a RNC através do procedimento de cellupdates que está se movendo entre células
(CELL_PCH) ou entre URA (URA_PCH).

Para o controle das transições na Huawei temos quatro parâmetros importantes:

 Event 4x threshold: Define o valor do threshold dos eventos 4a e 4b.
 Timer-to-trigger: Disparado após a quantidade de dados no buffer atingir os thresholds
dos eventos da família 4x.
 Pending timer: Disparado após termino do Timer-to-trigger, evita o envio da quantidade
excessiva de measurement report (4a/b).
 Transition timer: Disparado após o termino do Timer-to-trigger, uma vez que Transition
timer é expirado a transição é executada.

3
 State Transition
Resultados do Trial

No esquema abaixo podemos verificar a o funcionamento básicos dos parâmetros mencionados

acima:

Figure 1 – State transition scheme

Como uma segunda forma de confirmação podemos definir que dentro do período “Transition
Timer” temos que receber uma certa quantidade de eventos (4b) para que seja confirmado a transição
de estado através da formula a seguir:

*Transition threshold = Transition time/ (Time to trigger + Pending time after trigger) x Coefficient
*Válido apenas para transições D2F e F2P
*Resultado deve ser arredondado para um número inteiro para baixo
*Coefficient: STATETRANSTRAFFREDUNDCOEF

Transição CELL_DCH -> CELL_FACH:

Service Type D2F Transition Timer (s) Event 4B Threshold (bytes) Time to Trigger Event 4B (ms) Pending Time After Event 4B Trigger (ms)
BE service on the DCH BeD2FStateTransTimer D2F2PTvmThd D2FTvmTimeToTrig D2FTvmPTAT
BE service on the HS-DSCH BeH2FStateTransTimer BeH2FTvmThd BeH2FTvmTimeToTrig BeH2FTvmPTAT
BE service on the E-DCH BeE2FStateTransTimer E2FThrouThd E2FThrouTimeToTrig E2FThrouPTAT x E2FThrouMeasPeriod
PS real-time service RtDH2FStateTransTimer RtDH2FTvmThd RtDH2FTvmTimeToTrig RtDH2FTvmPTAT
Figure 2 – D2F parameters

Para que o processo de transição D2F comece, o buffer (UE e RNC) de dados deve estar abaixo do
xx2FPTvmThd, nesse momento iniciará o timer xx2FTvmTimeToTrig quando esse timer espirar o report
4b será disparado e ao mesmo iniciaremos dois timers: Pending timer e transition timer.

Enquanto o pending timer não expirar, os demais reports 4b não poderão ser enviados., logo esse
mecanismo evita excessivos envios de eventos 4b. Quando o Timer-To-Trigger expirar o Transition timer
é iniciado durante essa transição nenhum evento 4a poderá ser reportado, caso contrário a transição será
cancelada.

Dependendo ainda dos valores escolhidos de TTT, pending e transition timer poderá ser
necessário que durante o transition timer a RNC precise receber o número de reports indicado pela
formula do “Transition threshold”. Isso serve como mais um mecanismo de proteção para evitar variações

4
 State Transition
Resultados do Trial

de dados no buffer, geralmente essa quantidade de reports são definidos quando se tem uma transição
muita rápida (< 3s).

Para os usuários em R99 temos uma particularidade caso a feature DCCC esteja ativa e DcccStg
configurado como RATE_UP_AND_DOWN_ON_DCH, que é o caso da rede da Unitel. Para esses usuários
só pode ser realizado a transição de estado caso o throughput do usuário for menor ou igual a
DlDcccRateThd e UlDcccRateThd.

Transição CELL_FACH -> CELL_PCH:

Service Type F2P Transition Timer Event 4B Threshold Time to Trigger Event 4B Pending Time After Event 4B Trigger
BE service BeF2PStateTransTimer D2F2PTvmThd F2PTvmTimeToTrig F2PTvmPTAT
Figure 3 – F2P parameters

O processo de transição F2P segue a mesma sequência do D2P.

Transição CELL_FACH -> CELL_DCH:

Service Type Event 4A Threshold Event 4A Time to Trigger

BE service on the DCH BeF2DTvmThd
BE service on the HS-DSCH BeF2HTvmThd
BE service on the E-DCH BeF2ETvmThd
PS real-time service RtF2DHTvmThd
Figure 4 – F2D parameters
BeF2DTvmTimeToTrig
BeF2HTvmTimeToTrig
BeF2ETvmTimeToTrig
RtF2DHTvmTimeToTrig

O processo de transição F2D, segue o mesmo processo das transições anteriores com a diferença
que não existe transition timer e pending timer. Ou seja, uma vez que o buffer alcança o valor do evento
4a, o Timer-To-Trigger é iniciado e quando o mesmo expira a transição é executada.

Transição CELL_PCH -> CELL_FACH:

Para sair do estado CELL_PCH o terminal deve enviar apenas uma das mensagens pré-
determinadas pelo 3GPP, por exemplo:
 Uplink Data Transmission
 Cell Reselection
 Paging Response

Timer de inatividade:

Uma vez que a RNC detecta que o terminal não está transferindo nenhuma informação a RNC
enviaria o pedido de desconexão para o CN e com isso o CN iniciará o release da conexão do terminal.

A RNC realiza esse monitoramento de atividade na camada PDCP e a partir do momento que a
RNC verifica que não existe dados sendo transferidos pelo usuário nessa camada o timer T1 é iniciado.
Quando o timer T1 é expirado a RNC envia pedido de release para o CN, nesse momento inicia-se o timer
T2 e a RNC aguarda a confirmação do CN para o pedido de release.

Uma vez recebida a mensagem de confirmação a RNC fará o release de toda a conexão do móvel
e o mesmo irá para idle mode. Caso a RNC não receba essa confirmação dento do timer T2, será enviada

5
 State Transition
Resultados do Trial

pela RNC uma mensagem de connection release para a camada de RRC que fará com que o UE entre no
estado de idle mode.

O timer T1 pode ser iniciado em qualquer um dos estados (CELL_DCH, CELL_FACH, CELL_PCH,
URA_PCH). Em paralelo a esse processo pode ocorrer também os timers do state transition (timer-to-
trigger, transition timer, pending timer) e o processo com menor duração de tempo que será executado.

Figure 5 – Access stratum stack

1.2 Objetivos
O objetivo principal é a ativação do estado CELL_PCH que serão usados pelos terminais depois um
certo tempo de inatividade com zero dados no buffer. Além da ativação o segundo objetivo é manter o
usuário em CELL_PCH o máximo de tempo enquanto o mesmo não tiver dados e informações para receber
ou enviar.

Com essa ativação a tendência é que tenhamos mais recursos disponíveis na rede e melhor
percepção de sempre conectado (Always-on) para o usuário. A redução da utilização dos recursos vai
desde a nível de célula (CE, potência, códigos, licença de usuários), NodeB (NBAP, número de usuários
suportados em HSPA, IuB) até RNC (Carga das placas de processamento).

6
 State Transition
Resultados do Trial

2. Procedimentos para ativação

2.1 Pré-requisitos
 Hardware
Nenhum

 Licença
WRFD-01061111 HSDPA State Transition
WRFD-010611 HSDPA Enhanced Package feature

 Dependência de features
WRFD-010610 HSDPA Introduction Package
WRFD-010612 HSUPA Introduction Package

2.2 Ativação
1. Ativação do State Transition - HSPA:
a. SET UCORRMALGOSWITCH: DraSwitch=DRA_HSDPA_STATE_TRANS_SWITCH-
1&DRA_HSUPA_STATE_TRANS_SWITCH-1;

2. Ativação do State Transition – R99:

a. SET UCORRMALGOSWITCH: DraSwitch=DRA_PS_BE_STATE_TRANS_SWITCH-
1&DRA_PS_NON_BE_STATE_TRANS_SWITCH-1;

3. Ativação da transição CELL_FACH para CELL_PCH:

a. SET UUESTATETRANSTIMER: BeF2PStateTransTimer=5;
b. SET UUESTATETRANS:F2PTVMPTAT=D1000;

4. Ajuste do volume de threshold para transição F2D e F2H:

a. SET UUESTATETRANS:BEF2DTVMTHD=D512,BEF2HTVMTHD=D512;

5. Ajuste do timer do T1:

a. SET UPSINACTTIMER: PsInactTmrForInt=1800, PsInactTmrForBac=1800;

7
 State Transition
Resultados do Trial

2.3 Cronograma de atividade

 Ativação: 29/06/2015
 Período de análise: 29/06/2015 até 06/07/2015
 OT02339/2015

2.4 Elementos de rede afetados

O trial foi realizado na RNC de Huila, RHL1H, e por se tratar de parâmetros de RNC, todos os
elementos (NodeBs) conectados neste RNC foram afetados.

2.5 Configuração recomendada

MO Parameter From To
UUESTATETRANSTIMER BEF2PSTATETRANSTIMER 65535 5
UUESTATETRANS F2PTVMPTAT D16000 D1000
UUESTATETRANS BEF2DTVMTHD D1024 D512
UUESTATETRANS BEF2HTVMTHD D1024 D512
UPSINACTTIMER PsInactTmrForInt 10 1800
UPSINACTTIMER PsInactTmrForBac 10 1800
Figure 6 – Parametrization – State Transition

8
 State Transition
Resultados do Trial

3. Monitoramento
Os indicadores que foram analisados e monitorados foram:

1. Acessibilidade
a. RRC SR  CS e PS;
b. RAB SR  CS e PS.
2. Retenção
a. CDR  CS e PS.
3. Recursos
a. Usuários em HSPA;
b. Consumo de códigos;
c. Consumo de CEs;
d. Carga do RNC;
e. Carga dos NodeBs (CNBAP);
f. Carga no Uplink – RTWP;
g. Congestionamento no FACH.
4. State Transitions
a. Usuários em CELL_DCH, CELL_FACH e CELL_PCH;
b. D2F, F2D, F2P, P2F;
c. H2F, F2H, E2F, F2E
5. Paging
a. Volume de paging

9
 State Transition
Resultados do Trial

4. Resultados

Melhora de 0.3pp na acessibilidade RRC - CS.

Figure 7 – RRC accessibility – CS

Leve tendência de melhora na acessibilidade CS - RAB.

Figure 8 – RAB accessibility - CS

Melhora de 2.5pp aproximadamente na acessibilidade RRC - PS.

10
 State Transition
Resultados do Trial

Figure 9 – RRC accessibility - PS

Melhora de 1pp na acessibilidade RRC - PS.

Figure 10 – RAB accessibility - PS

11
 State Transition
Resultados do Trial

Redução de aproximadamente de 40% nas tentativas de RRC. Quando o terminal está em

CELL_PCH, o mesmo mantém a conexão RRC e evitando uma nova conexão. Já quando o usuário é enviado
para idle toda a conexão é liberada, necessitando que esse terminal solicite outra vez a conexão RRC.

Figure 11 – RRC attempts – OS

Redução de aproximadamente 46% das tentativas de RAB, conforme esperado.

Figure 12 – RAB attempts - PS

12
 State Transition
Resultados do Trial

Tentativas de conexão CS mantiveram a mesma tendência de antes – UEs com conexão ativa de
voz não se movem entre os estados conectados.

Figure 13 – RRC attempts – CS

Tentativas de RAB CS mantem a mesma tendência das conexões RRCs – UEs com conexão ativa
de voz não se movem entre os estados conectados.

Figure 14 – RAB attempts - CS

13
 State Transition
Resultados do Trial

Como a estratégia é mover a quantidade máxima de usuários possíveis do estado Idle para
CELL_PCH, com isso evitamos um fluxo intenso de sinalização entre os estados: idle e conectado. Como
resultado obtemos uma redução do uso de recursos de NBAP em até 34%.

Figure 15 – NBAP usage reduction

Após a ativação do estado CELL_PCH podemos verificar um aumento do número de usuários nesse
estado, pois os usuários em CELL_FACH com atividade zero podem ser enviados a CELL_PCH ao invés de
Idle. Como esperado tivemos também um aumento do número dos usuários em CELL_FACH, já que toda
vez que um terminal necessita receber ou transmitir dados em CELL_PCH esse UE deve voltar ao estado
CELL_FACH para executar essa operação. Para evitar um congestionamento no canal FACH os thresholds
de volume foram reduzidos de 1024 para 512 bytes.
Redução de aproximadamente 2pp na carga das placas XPU, já que mais usuários em CELL_PCH
implica e menos conexões de RRC e RAB desnecessárias.

Figure 16 – XPU load

14
 State Transition
Resultados do Trial

Também tivemos redução do número de usuários em CELL_DCH já que o tempo total de transição
(CELL_DCH CELL_FACH) estava igual ao timer de release da conexão RRC.

Figure 17 – RRC connected users

Como esperado nenhuma redução no número de usuários CS, já que esses usuários não
impactados diretamente pela ativação do novo estado – CELL_PCH. Uma vez que usuários CS não trocam
de estado (CELL_DCH), enquanto o serviço de voz estiver ativo.

Figure 18 – CS user number

15
 State Transition
Resultados do Trial

Como foi mencionado anteriormente tivemos uma redução do número de usuários em CELL_DCH,
mais especificamente usuários em HSDPA já que o tempo total de transição (CELL_DCH CELL_FACH)
estava igual ao timer de release da conexão RRC.

Figure 19 – HSPA user number

Mesma tendência da quantidade de usuários R99 PS, já que nessa primeira mudança não foi
alterado os thresholds de inatividade para canal DCH.

Figure 20 – R99 user number

16
 State Transition
Resultados do Trial

Como a redução dos usuários em CELL_DCH não foi acentuada, a redução do consumo de Credits
(Channel elements RNC) teve uma redução de aproximadamente 1.5%.

Figure 21 – Downlink credit usage

Figure 22 – Uplink credit usage

As falhas de rádio link na fase de RRC, estão ligadas diretamente a recursos de NodeB.
Principalmente recursos das placas de banda base – NBAP e quantidade de usuários em HSPA. Como os

17
 State Transition
Resultados do Trial

recursos de NBAP foram reduzidos em até 34%, temos como resultado uma menor quantidade de
rejeições devido à falta desses recursos.

Figure 23 – RRC radio link rejections

Diminuição das falhas de RRC no reply, devido a menor quantidade de tentativas na fase de RRC.

Figure 24 – RRC no reply rejections

18
 State Transition
Resultados do Trial

Redução das rejeições devido a RNL (Radio network layer), que estão interligados aos
congestionamentos devido à falta de recursos nas células. Isso ocorre devido à redução de sinalização de
RRC/RAB, pois os usuários são mantidos em CELL_PCH e necessitando de menos recursos e um menor
tempo para regressar ao estado CELL_DCH/FACH.

Figure 25 – RAB PS failure

Não houve uma clara melhoria no congestionamento para o domínio CS.

Figure 26 - RAB CS failure

Aumento do número de Paging type 1 controlado pela UTRAN, devido ao aumento do número de
usuários em CELL_PCH. Existe um aumento de também de Paging type 2 devido a maior quantidade de

19
 State Transition
Resultados do Trial

usuários em CELL_FACH. Para o CN essa alteração de paging é a mesma, pois usuários em CELL/URA_PCH
e Idle ouvem o mesmo tipo de paging que é Type 1.

Figure 27 – UTRAN paging

Redução do número de PS paging para usuários em Idle Mode, já que os usuários foram movidos
para CELL_PCH.

Figure 28 – RANAP paging

20
 State Transition
Resultados do Trial

Como a redução da quantidade de usuários em CELL_DCH foi bem discreta, não houve alteração
no consumo de potência da RRU.

Figure 29 – RRU power usage

Sem alterações no comportamento na carga de uplink.

Figure 30 – Uplink load

Uma vez em CELL_PCH caso o móvel realize uma reseleção ou tenha dados para serem enviados
o mesmo deve avisar a RNC sobre essa reseleção e por essa razão temos um aumento das causas

21
 State Transition
Resultados do Trial

mencionadas. O excesso de cellupdates (Reselection) poderia impactar na carga do uplink e analisando o

gráfico anterior não se nota nenhuma alteração do comportamento desse indicador.

Figure 31 – Cellupdates cause

Sem alterações na tendência de CS – Drop.

Figure 32 – CS drop

22
 State Transition
Resultados do Trial

Leve aumento da taxa de PS – Drop. Como veremos adiante essa tendência de aumento de drop
é causado devido à redução acentuada das causas normais por inatividade. Esse tipo de release está
relacionado ao timer T1.
Anteriormente o usuário com 10s de inatividade já tinha o release da conexão para idle mode e
com a mudança o usuário necessita de 30 minutos para ter toda a conexão liberada para idle mode. Mas
de alcançar o tempo de 30 minutos a RNC moverá o usuário entre os estados de connected mode.

Figure 33 – PS drop

Uma vez que o timer RRC Release é maior que o tempo de transição (CELL_DCH  CELL_FACH),
é esperado que não tenhamos mais nenhum release de RAB por inatividade.

Figure 34 – RAB normal release - inactivity

23
 State Transition
Resultados do Trial

Normal releases reduzidos em 34% devido aos usuários se manterem em modo conectado
(CELL_PCH) e não serem enviados para Idle – Sem impacto para usuário.

Figure 35 – RAB normal release

Aumento do número de abnormal release inerentes ao estado CELL_FACH/PCH, devido a maior

utilização desses canais.

Figure 36 – RAB abnormal release – PCH/CCH

Aumento do número de abnormal release devido a SRB e TRB reset. Esse tipo de drop geralmente
ocorre durante transição de CELL_FACH  CELL_DCH ou durante o uso do canal FACH/DCH/HSDSCH. O

24
 State Transition
Resultados do Trial

reset da conexão é disparado a quando uma das entidades RNC/UE retransmite a quantidade máxima de
vezes permitido e quando o tempo total dessas retransmissões é expirado.
Esse tipo de falhas também é bastante comum em ambientes com baixa qualidade de rádio. Junto
com a implementação do call reestablishment, será realizado a otimização dos parâmetros de RLC que
irão ajudar nas falhas de SRB/TRB reset.

Figure 37 – RAB abnormal release - Reset

Aumento do número de abnormal releases por UuNoReply e UlSync. Apesar dessas falhas estarem
intimamente ligadas com ambientes com baixa qualidade de rádio, é possível realizar uma otimização
desses casos através do call reestablishment.

Figure 38 – RAB abnormal release – UuNoReply and ULSync

Diminuição do downgrade de serviço entre HSDSCH-DCH, devido a menor quantidade de

rejeições devido à falta de recursos.

25
 State Transition
Resultados do Trial

Figure 39 – Transition: HSDSCH-DCH

Figure 40 – Transition: ECH-DCH

Aumento das transições de FACH para HSDSCH, pois o threshold de volume para essa transição
foi reduzido de 1024 para 512 bytes para evitar congestionamento no canal FACH.

26
 State Transition
Resultados do Trial

Figure 41 – Transition: HSDSCH-FACH

Aumento das transições de FACH para HSDSCH, pois o threshold de volume para essa transição
foi reduzido de 1024 para 512 bytes para evitar congestionamento no canal FACH.

Figure 42 – Transition: EDCH-FACH

Início das transições entre os estados CELL_PCH e CELL_FACH.

27
 State Transition
Resultados do Trial

Figure 43 – Transition: FACH-PCH

Aumento esperado do congestionamento do canal de dados de FACH (DTCH). Conforme a

programação de atividades apresentado anteriormente, já programado a expansão do canal de FACH.

Figure 44 – FACH congestion - DTCH

Já para o canal de sinalização de FACH (CCCH e DTCH) não temos uma piora de congestionamento
como vimos no canal lógico DTCH. Mas com a atividade de expansão já programada esse comportamento
será ser resolvido.

28
 State Transition
Resultados do Trial

Figure 45 – FACH congestion – CCCH and DCCH

29
 State Transition
Resultados do Trial

5. Conclusão
Com a ativação do estado CELL_PCH foi possível reduzir o consumo de recursos importantes e
indispensáveis para rede, como utilização de NBAP, carga de RNC, e etc. Além do mais a redução
acentuada de sinalização se traduz em maior capacidade do sistema já que esses recursos poderão ser
utilizados para serviços de dados e voz.
Essa mesma estratégia será aplicada nas outras RNCs, devido ao ganho obtido durante o trial e
também devido ao grande potêncial de ganho que poderá ser obtido com as próximas otimizações e
implementações.

5.1. Próximos passos

Após a ativação do estado CELL_PCH temos como as seguintes atividades abaixo que estão
interligadas intimamente:

1. Expansão do canal (largura de banda) e número de usuários em FACH

a. Possibilitar o aumento de usuário de usuários permitidos
b. Aumentar a capacidade do canal, evitando congestionamento nos canais lógicos.

2. Otimização do State Transition (Timer-To-Trigger, pending timer, Event Threshold)

a. Melhorar a alocação de recursos
b. Aumentar capacidade do sistema

3. Ativação Fast Dormancy R8

a. Reduzir sinalização causada por smartphones
b. Aumentar eficiência de recursos disponíveis nas RNCs e NodeBs.

30