Nova Gestão de Trafego

2G Traffic
Management
Traffic steering between layers
Luanda, 24 de Junho de 2013
2G Traffic Management

1

Contedo
1 Introduo ........................................................................................................................................... 3
1.1 Objetivo ......................................................................................................................................... 3
1.2 Estratgia Geral ............................................................................................................................. 3
2 IDLE MODE BEHAVIOR ......................................................................................................................... 4
2.1 MS em Dual Mode ......................................................................................................................... 4
2.2 MS em 2G ...................................................................................................................................... 4
3 Direct Retry .......................................................................................................................................... 6
4 Half Rate .............................................................................................................................................. 7
5 HANDOVER .......................................................................................................................................... 8
5.1 INTER-LAYER HO ............................................................................................................................ 9
5.2 PBGT HO (PowerBudget) .............................................................................................................. 10
5.3 EDGE HO ...................................................................................................................................... 11
5.4 LOAD HO...................................................................................................................................... 12
6 Canais Fsicos ..................................................................................................................................... 14
7 Abis .................................................................................................................................................... 15
7.1 FixAbis ......................................................................................................................................... 15
7.1.1 IDLE TimeSlot (GPRS/EDGE) ................................................................................................... 15
7.2 FlexAbis ....................................................................................................................................... 16
7.2.1 Load Control ......................................................................................................................... 17
7.2 Abis over IP .................................................................................................................................. 17
8 GPRS/EDGE ........................................................................................................................................ 18
8.1 Alocao dos CODE SCHEMES ...................................................................................................... 18
8.2 Parametrizao Rdio .................................................................................................................. 19
9 Trial .................................................................................................................................................... 21
9.1 Objetivo ....................................................................................................................................... 21
9.2 Cenrio do Trial ........................................................................................................................... 21
9.2.1 Elementos Afetados .............................................................................................................. 21
9.3 Cronograma do Trial .................................................................................................................... 21
9.4 Parametrizao ............................................................................................................................ 21
9.5 Resultados e Anlise .................................................................................................................... 24
9.5.1 CSSR ...................................................................................................................................... 24
9.5.2 TCONG .................................................................................................................................. 24

2

9.5.4 CDR ....................................................................................................................................... 25
9.5.5 SDR ....................................................................................................................................... 25
9.5.6 Trfego ................................................................................................................................. 26
9.5.7 Distribuio do Trfego GSM/DCS ......................................................................................... 26
9.5.8 Distribuio HR/FR ................................................................................................................ 27
9.5.9 Handover .............................................................................................................................. 27
9.6 Concluso .................................................................................................................................... 28


3

1 Introduo

1.1 Objetivo
A nova gesto do trfego visa permitir que os mveis em casos extremos acesse a rede via o
sistema DCS.

1.2 Estratgia Geral

i. Dual Mode MS deve ficar sempre no 3G;
1 Melhorar o USER EXPERIENCE nos dados;
ii. Quando em 2G e em Idle Mode, o MS deve acampar, preferencialmente, em clulas GSM;
iii. Os sistemas GSM e DCS devem ser diferenciados por prioridade, Layers:
1 GSM Cobertura/Acesso/Indoor;
2 DCS Capacidade;
iv. Clulas DCS devem estar desbloqueadas para o acesso;
v. DR deve est ativo em ambos sistemas, GSM e DCS.
vi. HR deve ser usado em uma proporo de 30/70, ou seja, as chamadas iniciam-se em HR
somente aps a clula chegar a 70% de ocupao e enquanto estiver acima desse valor;
vii. Mobilidade entre o GSM e o DCS:
1 Inter-Layer HO; (0SH CS)
i. Layer DCS prioritrio em relao ao GSM;
ii. Trigger do HO leva em considerao a carga da clula servidora.
2 PBGT HO; ( 0SH 0SH, CS CS)
3 EDGE HO; (0SH 0SH, 0SH CS e CS CS)
i. Handover baseado no nvel de sinal da clula servidora;
ii. HO ocorre nas bordas de cobertura da clula.
4 Load HO; (0SHCS 0SHCS)
i. Handover com o intuito de liberar recursos no DCS, quando este estiver
congestionado.
ii. Esse HO no ser usado na gesto por defeito, porm mantive ele no
documento para efeito de conhecimento.

4

2 IDLE MODE BEHAVIOR

2.1 MS em Dual Mode

i. INTERRATCELLRESELEN = YES; Ativa a reseleo 2G3G;
ii. Send2QuterFlag = YES;
iii. QI = 7; MS sempre faz a medio das clulas 3G em Idle Mode;
iv. QP = 7; MS sempre faz a medio das clulas 3G em Packet Mode;
v. QSEARCHC = 15; MS nunca faz as medies das clulas 3G em Dedicated Mode;
vi. QCI = Use_Qsearch_I; MS em dedicated mode utiliza o QCI enquanto no receber o valor do
QSEARCHC no SACCH.
vii. FDDQMIN = 7; (Equivale a -12dB)
viii. FDDQOFF = 0;
ix. FDDQMINOFFSET = 0;
x. FDDRSCPMIN = 6; (Equivale a -102dBm). Nvel mnimo para fazer a reseleo para o 3G;
_
CPICE
RSCP
> RIA_C + FDDQOFF
CPICE
E
C
N
u
FDDQMIN FDDQMINOFFSFT
CPICE
RSCP
FDDRSCPMIN

*RLA_C nvel de sinal mdio recebido da clula servidora (GSM).
Essas condies devem ser satisfeitas durante um perodo de 5s para que a reseleco seja feita
para o 3G.

2.2 MS em 2G
Critrio de Seleo:
i. Prioridade de seleo
a. Definido atravs dos parmetros CBQ e CBA:
b. Priorizar as clulas GSM em detrimento das DCS:
i. GSM CBQ = CBA = NO;
ii. DCS CBQ = CBA = YES.

Sistema CBQ CBA Seleo Reseleo
GSM NO NO Normal Normal
DCS YES YES Baixa Normal

5

ii. Critrio do PATHLOSS
_
C1 = RXIEI RXIEI _ACCESS_HIN HAX((HS_IXPwR_HAX_CCE P),u)
C1 = RXIEI RXIEI _ACCESS_HIN
a. RXLEV_ACCESS_MIN = RXMIN
i. GSM RXMIN = 4, equivale a -106dBm
ii. DCS RXMIN = 8, equivale a -102dBm

O RXMIN um dos parmetros otimizveis, atravs deste ser possvel reduzir a rea de cobertura do
DCS, reduzindo o LOAD e evitando o TCONG. Esse parmetro dever ser alterado em conjunto com
outros parmetros utilizados nos processos de HO.

Critrio de Reseleo:

_
C2 = C1 CR0, (PI = S1)
C2 = C1 +CR0, (PI S1)

A reseleo para o DCS deve ser penalizada:
GSM:
o CRO = 0;
o PT = 0;
o PI = YES.
DCS:
o CRO = 63; Equivale a 126dB;
o PT = 31;
o PI = YES.


6

3 Direct Retry

O DR dever estar ativo tanto no GSM quanto no DCS, para evitar bloqueio de chamadas em
situaes onde a clula servidora esteja congestionada (sem canais TCH disponveis).
DIRECTRYEN = YES
O DR pode ser implementado de duas formas distintas:
1. ASSLOADJUDGEEN = OFF DR realizado quando a clula servidora estiver com o
LOAD acima dos 100%;
2. ASSLOADJUDGEEN = YES DR realizado quando a clula servidora tiver um LOAD
superior ao CDRTTRYFBDTHRES.
A seleo da clula target feita de acordo com os seguintes critrios:
Carga da target DTLOADTHRED;
RXIEI
tugct
MINPWRLEVDIRTRY.
Para evitar problemas do DR ser executado para uma clula que esteja sobrecarregada e/ou no
possui uma boa qualidade de sinal, a carga da target deve ser inferior a 85% e o nvel mnimo de sinal
superior a -90dBm.
Para efeito de simplicidade, o DR que a ser implementado o do item 1. acima. Em caso de
problemas podemos avanar com a outra implementao do DR.
Implementao do DR, em todas as clulas GSM e DCS:
a. DIRECTRYEN = YES;
b. ASSLOADJUDGEEN = OFF;
c. DTLOADTHRED = 85;
d. MINPWRLEVDIRTRY = 20.


7

4 Half Rate

De acordo com as recomendaes da Unitel a proporo entre o trfego HalfRate e o FullRate
no deve ser superior 30%.
Por defeito a prioridade na alocao de canais : AMR/FR, Enhanced FR, FR, AMR/HR e HR. Essa
prioridade visa proporcionar uma melhor qualidade de servio aos usurios, visto que, o AMR/FR, EFR e
FR possuem uma melhor proteo a interferncia em relao ao AMR/HR e HR.
O princpio de funcionamento do algoritmo de alocao : quando a taxa de ocupao dos
canais elevada, i.e., o setor est sobrecarregado, um canal TCH/HR preferencialmente alocado, caso
contrrio o TCH/FR tem prioridade. A alocao dos canais em HR proporcionam um aumento na
capacidade da rede.
Os thresholds para que a BSC comece a alocar canais em AMR/HR ou HR em um determinado
setor so: AMRTCHHPRIORLOAD e TCHBUSYTHRES, respectivamente. E a frmula usada para calcular a
taxa de ocupao dos canais conforme segue:
0cupoo =
Nmcro Jc conois FR ocupoJos + Nmcro Jc conois ER ocupoJos 2
Nmcro Jc conois FR Jisponi:cis + Nmcro Jc conois ER Jisponi:cis 2
1uu%
O nmero de canais disponveis referente ao nmero de canais ocupados e aos livres. Inclusive
os canais configurados como PDTCHs dinmicos que no estejam sendo usados pelo GPRS/EDGE so
includos no clculo.
Para que a razo entre TCH/FR e TCH/HR seja mantida nos 30%, preciso definir os parmetros
AMRTCHHPRIORLOAD e TCHBUSYTHRES, ambos em 70%. Desta forma a alocao dos canais em HR s
iro comear quando 70% dos canais estiverem ocupados.
Parametrizao do HalfRate implementada:
1. GSM/DCS
o TCHBUSYTHRES = 70;
o AMRTCHHPRIORLOAD = 70.
Fica a dica: Como a gesto de trfego faz uso do InterLayer HO (ver tpico sobre Handover),
para enviar o trfego do GSM para o DCS, quando a ocupao no GSM estiver acima dos 40%, o trfego
no GSM ser em sua maioria em FR. Caso o DCS apresente congestes de canais TCHs, uma das formas
de se resolver altera os thresholds de alocao de canais HR no GSM.
Ao se alterar esses thresholds para valores inferiores a 40% o GSM ir comear a processar
trfego em HR antes de Interlayer HO comear a migrar o trfego para o DCS, com o aumento do
trfego no GSM ser visvel uma reduo de trfego no DCS, reduzindo assim o congestionamento.


8

5 HANDOVER

O Algoritmo de Handover utilizado o Handover Algorithm I (HOCTRLSWITCH =
HOALGORITHM1). Segundo este algoritmo os HOs existentes e suas prioridades so conforme figura
abaixo:

Figure 1 - Tipos de Handover

Desconsiderando os handovers de emergncia, visto que estes sempre sero utilizados para
evitar quedas de chamadas no limite da cobertura/qualidade do sinal. Os handovers que sero
implementados na nova gesto para proporcionar um balanceamento do trfego bem como uma
melhor mobilidade so:
i. INTER-LAYER HO;
ii. PBGT HO;
iii. EDGE HO;
iv. LOAD HO - No ser implementado de imediato.
Por defeito o SDCCH HO estar desabilitado:
SIGCHANHOEN = OFF;

9

5.1 INTER-LAYER HO

Definio dos Layers (quanto maior o Layer menor a prioridade):
GSM LAYER = 3;
DCS LAYER = 2;
Indoor LAYER = 1. Se achar necessrio.

Ativao do INTER-LAYER HO LEVHOEN = YES.
Condies para ser executado o INTER-LAYER HO (Trigger):
1. LAYER da servidora < LAYER da Target
2. LOAD da servidora > LAYHOLOADTH
3. RXIEI
1ugct
HOTHRFS +INTFLFFHOHYST 64

(Condio P/N): Todas essas condies devem ser observadas LEVSTAT (p) segundos dentro de
LEVLAST (n) segundos.

Atravs do LAYHOLOADTH possvel manter o trfego no GSM at este atingir um certo nvel
de carga, situao semelhante ao HCSOUT disponvel no HCS na Ericsson. Como na Huawei no existe
um parmetro semelhante ao HCSIN na Ericsson, onde possvel limitar o HO por HCS devido carga na
Target, recomendado definir um valor para o LAYHOLOADTH a fim de evitar que todo o trfego passe
para o DCS e gere problemas de congesto, TCONG.
LAYHOLOADTH = 40.
Com relao seleo da clula target, est deve possuir um nvel de sinal superior ao HOTHRES
+ INTELEVHOHYST 64, onde:
HOTHRES nvel de sinal mnimo para que a clula target seja considerada como uma candidata
ao HO. Semelhante ao LAYERTHR do HCS da Ericsson.
INTELEVHOHYST a histerese definida para se evitar o efeito de ping-pong no INTER-LAYER HO.
Como esse parmetro definido como sendo um inteiro entre 0 e 127, o fator -64 introduzido
na frmula para transforma o INTELEVHOHYST dB. Semelhante ao LAYERHYST do HCS da
Ericsson.


10

Para manter o padro com a rede Ericsson, esses parmetros sero assim definidos:
HOTHRES = -95;
INTERLEVHOHYST = 70. (Equivale a 6dB = 70 - 64).
Resumo para implantao:
GSM LAYER = 3;
DCS LAYER = 2;
INDOOR LAYER = 1;
LAYHOLOADTH
o GSM = 40;
o DCS = 100;
HOTHRES = 15 (Equivale -95dBm = -110 + 15);
INTELEVHOHYST = 70.

5.2 PBGT HO (PowerBudget)

O PBGT HO um HO intra layer, ou seja, este s ser realizado entre o 0SH 0SH e o CS
CS. O PBGT HO ser utilizado para proporcionar um maior grau de mobilidade aos usurios em
movimento, visto que, para disparar o HO preciso, de forma simplificada, apenas que a diferena entre
os nveis de sinal da clula servidora e da clula target seja superior a margem definida para o PBGT HO.
Ativao do PBGT HO PBGTHOEN = YES.
Trigger do HO:
RXIEI
tugct
PwR
IPP
RXIEI
scng
> PB6TMAR6IN 64

(Condio P/N): A condio acima deve ser observada PBGTLAST (p) segundos dentro de
PBGTLSTAT (n) segundos.

O PwR
IPP
est associado ao POWER CONTROL e definido como sendo a diferena entre a
potncia mxima de transmisso e a potncia atual de transmisso na clula servidora.
O PBGTMARGIN por defeito est configurado em 4dB:
PBGTMARGIN = 68. (68 - 64 = 4dB)
Esse parmetro ser um dos parmetros otimizveis na nova gesto, visto que, atravs dele
possvel aumentar e/ou reduzir a cobertura das clulas intra-layers, facilitando e/ou dificultando o HO
entre clulas. Isto permitir fazer um balanceamento de trfego entre clulas vizinhas, reduzindo,
provavelmente, a congesto em uma delas.
PBGTHOEN = YES;
PBGTMARGIN = 68;


11

5.3 EDGE HO

O EDGE HO tambm baseado no nvel de sinal, bastante semelhante ao PBGT HO. A diferena
bsica entre os dois est no fato de que, ao contrrio do PBGT HO, onde o trigger a diferena entre os
nveis de sinal. O EDGE HO tem como trigger um limiar para o nvel de sinal da clula servidora, podendo
ser tanto o nvel no DL quanto no UL e/ou o power budget entre o a servidora e a target,
_
I_RXIEI
scng
< DLFD6FTHRFS
ou
uI_RXIEI
scng
< ULFD6FTHRFS

Ou
RXIEI
tugct
> RXIEI
scng
+INTFRCFLLHYST 64

(Condio P/N): As condies acima devem ser observadas EDGELAST1 (p)
segundos dentro de EDGESTAT1 (n) segundos.

Aps o rank das clulas target a clula selecionada para receber o HO deve ter uma prioridade
(critrio M desnecessrio de momento a sua explicao) maior que a clula servidora, obedecendo o
critrio P/N, ou seja, durante EDGEADJSTATTIME segundos a clula target deve aparecer
EDGEADJLASTTIME vezes com prioridade superior a clula servidora.
O EDGE HO bastante interessante, pois ele para alm de incluir uma espcie de PBGT HO, ele
tambm se assemelha a um HO de emergncia por nvel, ao despoletar o HO, quando o nvel da clula
target est fora do limite definido como aceitvel, DLEDGETHRES/ULEDGETHRES.
Como critrio para a gesto do trfego e de forma a diferenciar os HOs, pode-se definir o
INTERCELLHYST para ser superior ao PBGTMARGIN do PBGT HO, desta forma o EDGE HO
provavelmente s ir ocorrer nos limites de cobertura da clula servidora.
INTERCELLHYST = 70. Significa dizer que a histerese ser de 6dB (70 - 64), 2dB a mais que o
PBGTMARGIN.
Para manter uma certa simetria entre os limites de cobertura da clula em modo IDLE e
DEDICATED, o DLEDGETHRES dever ser igual ao RXMIN e menor que o HOTHRES do INTER-LAYER HO.
Isto poder evitar que o MS faa o HO do DCS para o GSM por EDGE HO e logo em seguida volte para o
DCS por INTER-LAYER. J o ULEDGETHRES deve compensar a diferena entre o PATHLOSS do DL e UL,
que normalmente fica em torno de 6-10dB. Definindo est margem em 4dB, tem-se que:
DLEDGETHRES = 8; (Equivale a -102dBm = -110 + 08);
ULEDGETHRES = 4. (Equivale a -106dBm = -110 + 4).
Fica a dica de otimizao: Sempre que for preciso reduzir a rea de cobertura de uma clula DCS
para evitar o TCONG, para alm de se aumentar o valor do RXMIN (acesso) preciso replicar esse valor
no DLEDGETHRES* e ULEDGETHRES (neste caso compensar os 4dB que foram colocados de margem).
Isso garantir que a clula ter a mesma rea de cobertura tanto em IDLE quanto em DEDICADO.
Ateno ao fato de que o HOTHRES do INTERLAYER HO tambm dever ser alterado para evitar o ping
pong entre o DCS e o GSM conforme explicado acima. (*Ao se alterar o DLEDGETHRES se altera o
funcionamento do LOAD HO, vocs devem ter isso em mente).


12

FRINGEHOEN = YES;
DLEDGETHRES = 8;
ULEDGETHRES = 4;
INTERCELLHYST = 70;

5.4 LOAD HO

(* Essa soluo ainda precisa ser testada melhor e apesar de ser discutida abaixo, ela por defeito no
ser implementada)
Como o INTER-LAYER HO no possui nenhum parmetro similar ao HCSIN da Ericsson, no tem
como se controlar o LOAD nas clulas DCS via o INTER-LAYER HO. Desta forma o LOAD HO ter como
funo principal descongestionar os sites DCS para evitar falhas de HO entre o GSM e o DCS por INTER-
LAYER.
O LOAD HO funciona de seguinte forma, ao se detectar que a clula servidora est
sobrecarregada, LOAD > TRIGTHRES, a BSC ir definir uma rea de cobertura, definida pelos nveis
(DLEDGETHRES, DLEDGETHRES + LOADHOSTEP) e todos os MS inseridos dentro desta rea podero
sofrer um HO para as clulas vizinhas.
Aps um certo perodo, definido por LOADHOPERIOD, caso a clula servidora continue
congestionada, uma nova regio ser definida, (DLEDGETHRES, DLEDGETHRES + 2*LOADHOSTEP). Este
processo se repete de criar novas reas de cobertura continua at que a clula servidora fique
descongestionada, LOAD <= TRIGTHRES.
Enquanto isso as novas regies sero definidas conforme a seguinte frmula, (DLEDGETHRES,
DLEDGETHRES + x*LOADSTEP). Entretanto, quando o DLEDGETHRES + x*LOADSTEP for igual ou
superior ao LOADOFFSET no ser criada nenhuma nova regio, porm o LOAD HO continuar a ser
executado na regio atual at que a carga da clula seja igual ou inferior ao TRIGTHRES.
Como o LOAD HO pode despoletar uma quantidade muito grande de handover em simultneo,
existe um critrio de segurana para evitar que o processamento da BSC entre em overflow. Isto
significa dizer que, o LOAD HO s ser executado se a utilizao da CPU for inferior a um determinado
valor:
CPU USAGE SYSFLOWLEV
A outra condio para o trigger do LOAD HO que a clula servidora esteja sobrecarregada:
Load da clula servidora TRIGTHRES;
J a seleo da clula target baseada nas seguintes condies:
RXIEI
tugct
HOTHRFS + INTFRLFFHOHYST 64;
Load da target LoadAccThres;
Explicado o conceito do LOAD HO, passemos para a sua implementao.
Apesar do LOAD ser usado para descongestionar o DCS, este tambm pode estar ativo no GSM,
de forma a tentar descongestionar o GSM tambm, assim temos:
LOADHOEN = YES; Tanto para o GSM quanto para o DCS;

13

GSM
o TRIGTHRES = 70; Ou seja, quando a clula estiver com 70% de ocupao ativa-se o LOAD
HO. Esse parmetro deve ser maior que o LAYHOLOADTH do INTER-LAYER de forma a evitar
HOs desnecessrios entre o GSM, antes do MS ser enviado ao DCS.
o LoadAccThres = 60; Clulas GSM s iro aceitar HO por Load se suas respectivas cargas
forem inferiores a 60%. Deve ser inferior ao TRIGTHRES para evitar o ping-pong. Valor
poder sofrer otimizao.
DCS
o TRIGTHRES = 70; Por defeito mantemos ambos os valores em 70%, porm para o caso do
DCS esse parmetro poder ser otimizvel caso necessrio;
o LoadAccThres = 60; Clulas DCS s iro aceitar HO por Load se suas respectivas cargas forem
inferiores a 60%. Deve ser inferior ao TRIGTHRES para evitar o ping-pong. Valor poder
sofrer otimizao.
SYSFLOWLEV = 10; Este o valor por defeito e significa que o LOAD HO ser executado mesmo
quando a utilizao da CPU esteja igual a 100%;
LOADHOSTEP = 5;
LOADHOPERIOD = 10;
LOADOFFSET = 25 (equivale a -85dBm).

Otimizao: Essa parte fica em aberto, pois primeiro preciso fazer testes mais detalhados no LOAD
HO, antes de decidir quais parmetros podem ser alterados e quais deveram manter sempre fixo.


LOADHOEN = YES; Tanto para o GSM quanto para o DCS;
TRIGTHRES = 70;
LoadAccThres = 60;
SYSFLOWLEV = 10;
LOADHOSTEP = 5;
LOADHOPERIOD = 10;
LOADOFFSET = 25.


14

6 Canais Fsicos

Com a nova gesto do trfego no ser preciso, a priori, alterar quaisquer configuraes a nvel
de canais fsicos, ou seja, os sites continuaro a ter as seguintes configuraes:
1. GSM
a. 4 SDCCH;
b. 2 PDTCH.
2. DCS
a. 1 SDCCH;
b. 0 PDTCH.
Assim que a nova gesto for implementada, preciso testar a parte de PACKET no DCS e
redefinir a quantidade de canais de PDTCHs.
Com relao aos canais de SDCCH, de responsabilidade de cada um, validar se a clula
apresenta SCONG e tomar aes para reduzi-lo, incluindo mais canais de SDCCH. Como a prioridade de
seleo e reseleo so as clulas GSM, no preciso definir mais do que um canal de SDCCH no DCS, a
menos que se faa necessrio.


15

7 Abis

O intuito deste tpico de carter informativo e para ilustrar a feature do FlexAbis (adquirida
pela Unitel), para mais detalhes preciso ler a documentao prpria da Huawei sobre transmisso.

7.1 FixAbis
Neste tipo de configurao existe um mapeamento fixo entre os canais PDTCH/TCH dos TRXs e
os TimeSlots na Abis, conforme figura abaixo. Os canais de BCCH e SDCCH no so mapeados na Abis,
pois toda a sinalizao enviada atravs do canal de RSL (Radio Signaling Link).

Figure 2 - Mapeamento FixAbis
Cada TRX possui um RSL associado e devido a multiplexao estatstica 4:1, pode-se multiplexar
4 RSLs em um nico TS de 64Kbps na Abis. O OML mapeado em um nico TS de 64Kbps no Abis
tambm devido a multiplexao selecionada ser a estatstica.
O problema do FixAbis a deficincia na gesto dos recursos da abis (TimeSlots), pois como o
mapeamento fixo, mesmo que o TS no esteja sendo utilizado por um canal TCH (Voz), o TS na Abis
fica ocupado e no pode ser usado para o GPRS/EDGE.

7.1.1 IDLE TimeSlot (GPRS/EDGE)

Tanto no FixAbis, quanto no FlexAbis, possvel definirmos TimeSlots(TS) extras para os dados.
Esses TS so conhecidos como os IDLE_TS(16kbps).
Qual o impacto de adicionarmos esses IDLE_TS principalmente no FixAbis?
O grfico Abaixo mostra os throughputs mximo por PDTCH atingidos pelos servios de dados
em GPRS/EDGE. Se levar em considerao que o mvel pode alocar mais de um PDTCH por conexo, o
throughput final vai ser multiplicado pela quantidade de TS usados na conexo. Supondo que o mvel
estabelea uma conexo de dados e que utilize 3 PDTCHs no downlink com o code scheme MCS-9
(EDGE), sua taxa final ser de:
S PICE x S9.2Kbps = 177. Kbps

16

Figure 3 - Throughput GPRS/EDGE
Como no FixAbis s existe um TS de 16Kbps mapeado para cada PDTCH, a Abis iria limitar o
throughput final em 3 x 16Kbps = 48Kbps. Neste caso apesar da interface Um (area) permitir taxas de
177kbps, a Abis iria limitar o servio em 48Kbps. Com a definio dos IDLE_TS (TSCOUNT), a Abis pode
usar esses TS em conjunto com os mapeados para os PDTCHs e com isso ter banda disponvel para
prover uma maior taxa ao GPRS/EDGE, no sendo mais um limitante.

7.2 FlexAbis
Com a ativao da feature de FlexAbis, o nico mapeamento fixo que existe entre os canais
fsicos do TRX e a Abis so os canais de PDTCH. Alm disso o OML e os RSLs ainda so mantidos
prefixados na Abis. Com a ativao da feature um novo canal de sinalizao tambm adicionado, o ESL
(Extended Signaling Link), cujo mapeamento feito no mesmo TS do OML na Abis, ou seja, o ESL e o
OML so multiplexados na Abis.
Todos os demais TS da Abis so adicionados a uma pool de recursos que a BSC de forma
dinmica aloca para os servios solicitados (Voz ou dados). Abaixo est um exemplo de um
mapeamento para o FlexAbis de um site com 3 Setores, 4 TRX por setor e 2 PDTCH fixos por setor.

Figure 4 - FlexAbis

17

No FlexAbis os TS da Abis so divididos em sub-TS de 8Kbps e o mapeamento entre os TS do TRX
e os Sub-TS na Abis seguem o seguinte princpio.
1 TCH HR 1 subTS na Abis (8Kbps);
1 TCH FR 2 subTS na Abis (16Kbps);
1 PDTCH vai depender do code scheme selecionado (taxa).
Como a feature do FlexAbis foi adquirida pela Unitel todos os sites com transmisso em TDM
devem ter a seguinte configurao:
FLEXABISMODE = FLEX_ABIS Ativao do FlexAbis;
MPMODE = 4:1 Tipo de multiplexao dos RSLs;
TSCOUNT = 0 Nmero mnimo de subTS na ABIS dedicados para PS (IDLE_TS).
Como a Abis ser configurada como Flex no h a necessidade de se configurar TS extras para o
GPRS/EDGE, visto que os TS da Abis sero alocados de forma dinmica e caso haja disponibilidade de
recursos na Abis, novos TS sero alocados para o GPRS/EDGE para prover maior throughput ao usurio.

7.2.1 Load Control
Com a ativao do FlexAbis possvel fazer controle de carga na interface Abis. Para isso basta
definir os procedimentos que se quer executar quando a Abis estiver congestionada:
a. TDMCONGTH Threshold que define o congestionamento na Abis. Caso a largura de
banda disponvel na Abis seja inferior ao valor deste parmetro a BSC vai iniciar as aes
para descongestionar a ABIS. Por defeito o TDMCONGTH est definido em 15%;
b. AES:
i. PSDOWN Reduz o throughput dos mveis em GPRS/EDGE;
ii. CSPH As novas chamadas de voz tero preferncia por canais HR;
iii. CSFHHO BSC inicia HO de TCH FR para TCH HR para reduzir a ocupao dos TS
na POOL;
iv. AMRC Limita os codecs do AMR para as taxas mais baxas.
Para o CSFHHO funcionar preciso ativar o INTRACELL HO, e com em uma rede com frequency
hopping ativado no recomendado fazer intracell HO est ao no deve ser definida.
Para ativar as aes basta definir a sequncia que a BSC ir seguir, a priori, a ideia primeiro
reduzir a taxa dos dados para s assim ativar o HR, pois Voz tem prioridade e o HR tem impacto na
qualidade do servio de voz:
1. LDRFST = PSDOWN;
2. LDRSND = CSPH;
3. LDRTRD = AMRC;
4. LDRFOUH = CLOSED.

7.2 Abis over IP

Para o Abis over IP favor verificar o documento criado exclusivamente para o projeto do Abis
over IP.


18

8 GPRS/EDGE

8.1 Alocao dos CODE SCHEMES
A alocao dos Code Schemes pode ser feita de duas formas distintas:
1. Alocao Fixa;
2. Alocao Dinmica.
Na alocao fixa definido um CODE SCHEME nico para o UPLINK e outro para o DOWNLINK e
todas as conexes GPRS/EDGE iro fazer uso desta codificao. Esse cenrio no razovel, pois
dependendo da qualidade do sinal (PATHLOSS/INTERFERENCE/SIGNAL STRENGHT), a codificao
utilizada pode no ser a ideal e o servio de PS no funcionar corretamente. Para resolver isto, pode-se
configurar um Coding Scheme mais baixo (CS-1 ou CS-2). Entretanto, desta forma, estaria limitando o
servio PS a taxas muito baixas e o servio tambm no funcionaria de forma eficiente.
Na alocao dinmica, a BSC, de acordo com a qualidade do sinal e a taxa de retransmisso do
TBF, ir determinar qual o melhor Code Scheme a ser utilizado no momento. Para isto, preciso
definir os parmetros, UPFIXCS, DNFIXCS, UPFIXMCS e DNFIXMCS como UNFIXED.
Quanto pior a qualidade do sinal na interface area, maior o nmero de retransmisses do TBF,
principalmente ao se utilizar CODE SCHEMES maiores, pois possuem menos bits de paridade em sua
composio e com isso so mais susceptveis a interferncia.
Por isso que para que o servio de GPRS/EDGE seja adequado, preciso ajustar os code schemes
de forma dinmica e de acordo com a qualidade do sinal, evitando assim retransmisses desnecessrias
e proporcionando uma melhor experincia ao usurio final.
Na alocao dinmica preciso definir o CODE SCHEME inicial, ou seja, o CODE SCHEME que
todos os usurios iro usar para iniciar o servio. Para evitar problemas de acessibilidade e como, a
priori, no se sabe a qualidade do sinal sem antes iniciar a sesso de dados, o CODE SCHEME inicial no
pode ser muito elevado. No caso da rede da Unitel o que se fez foi definir os CODE SCHEMES iniciais
como sendo os code schemes mais baixos e caso a qualidade do sinal seja boa a BSC altera o CODE
SCHEME utilizado fornecendo maior largura de banda ao usurio.
UPDEFAULTCS = CS-1; - Code Scheme inicial para o Uplink no GPRS;
DNDEFAULTCS = CS-2; - Code Scheme inicial para o Downlink no GPRS;
UPDEFAULTMCS = MCS-2; - Code Scheme inicial para o Uplink no EDGE;
DNDEFAULTMCS = MCS-6; - Code Scheme inicial para o Downlink no EDGE.

Para fazer o ajuste dos CODE SCHEMES no GPRS definido 3 Thresholds para o Uplink e 3 para o
Downlink.
Se o CODE SCHEME atual for o CS-1 e a taxa de retransmisso do TBF(UL ou DL) for menor ao
UPTHDUPGRADE1 ou DNTHDUPGRADE1 a BSC seleciona o CS-2;
UPTHDUPGRADE2 ou DNTHDUPGRADE2 a BSC seleciona o CS-3; E se a taxa for maior que
UPTHDUPGRADE1 ou DNTHDUPGRADE1 a BSC faz o downgrade para o CS-1;

19

UPTHDUPGRADE3 ou DNTHDUPGRADE3 a BSC seleciona o CS-4; E se a taxa for maior que
Se o CODE SCHEME atual for o CS-4 e a taxa de retransmisso do TBF(UL ou DL) for maior ao

Para o EDGE a alocao dinmica pode ser feita utilizando dois mtodos de controle de
qualidade do link:
Link Adaptation LA
Incremental Redundancy IR

O mtodo utilizado na rede o IR, pois, pois o LA funciona melhor quando se tem uma
qualidade do sinal bastante razovel. O parmetro que define o tipo de Link Quality Control o
LQCMODE.
LQCMODE = IR.
No EDGE a definio de se fazer um upgrade/downgrade do Code Scheme feita atravs dos
BEP (Bit Error Probability) Measurement Reports, que podem ser gerados pela BTS ou pelo MS. A
periodicidade de envio definida pelo parmetro BEPPERIOD.
BEPPERIOD = 5.
Existe tambm dois contadores que so utilizados para fazer o downgrade do CODE SCHEME,
tanto para o GPRS quanto para o EDGE, so eles: N3101 e N3105. Esses contadores basicamente contam
a quantidade de retransmisses do TBF no Uplink e no Downlink, respectivamente. E quando esses
valores ultrapassam o limite, feito um abnormal release do TBF e o mvel forado a alocar um CODE
SCHEME inferior ao atual.
N3101 = 20;
N3105 = 10.

8.2 Parametrizao Rdio

Para alm das parametrizaes acima tambm foi definido um grupo de parmetros para tentar
melhorar a qualidade dos servios de dados no 2G, esses parmetros sero explicados abaixo.
1. MAXPDCHRATE Define a quantidade mxima de TS na interface erea que pode ser
utilizado para PS:
N Jc PICE = HAXPICERAIE x (N ICE + Stotic PICE)
Por defeito esse parmetro deveria ser configurado em 100%, i.e., todos os TS dos TRXs
poderiam ser utilizados para o servio de GPRS/EDGE. Entretanto devido a alguns problemas
experimentados (bloqueio de chamadas) com essa configurao, o valor foi redefinido para 50%.
Esse problema foi reportado a Huawei que informou que com o upgrade para a release GBSS14
esse problema ser solucionado.

20

2. UPDYNCHNTRANLEV Define o nmero de usurios multiplexados em um nico TS no
Uplink. usado como trigger para iniciar as converses de TS TCH para PDTCH;
i. Quanto menor esse valor mais rpido a clula inicia a realocao dos usurios
em novos TS de PDTCH UL, isso implica a converso de TS TCH para PDTCH;
3. DWNDYNCHNTRANLEV Define o nmero de usurios multiplexados em um nico TS
no Downlink. usado como trigger para iniciar as converses de TSL TCH para PDTCH;
i. Quanto menor esse valor mais rpido a clula inicia a realocao dos usurios
em novos TS de PDTCH DL, isso implica a converso de TS TCH para PDTCH;
4. CHIDLHIGHTHR Threshold usado para despoletar as converses de PDTCHs dinmicos.
i. Quando o CHIDLHIGHTHR est definido em 100%, sempre que o nmero
mximo de usurios multiplexados em um nico TS atinge um dos limites
definidos por UPDYNCHNTRANLEV e DWNDYNCHNTRANLEV, a BSC inicia as
converses de PDTCHs dinmicos;
5. PDCHUPLEV Define o nmero de TBFs permitidos em um nico TS no Uplink.
i. Para permitir as converses dos PDTCHs dinmicos, este parmetro deve ser
superior ao UPDYNCHNTRANLEV;
6. DWNPDCHLEV Define o nmero de TBFs permitidos em um nico TS no Downlink.
i. Para permitir as converses dos PDTCHs dinmicos, este parmetro deve ser
superior ao DWNDYNCHNTRANLEV;
7. DYNCHNPREEMPTLEV Define o tipo de preemption dos PDTCHs dinmicos.
8. DYNCHNTRANRESLEV Nmero de canais TCH/FR reservados para voz.
9. DEFAULTDYNPDCHPRETRANNUM Define um nmero de TS que so criados por
defeito como PDTCHs dinmicos.
i. Esses canais quando em IDLE podem ser convertidos em TCH/F;
10. RESERVEDDYNPDCHPRETRANNUM Define o nmero de canais PDTCHs dinmicos
reservados(DEFAULTDYNPDCHPRETRANNUM) que no podem sofrer o preemption.
11. FORBIDEDGU Define se um canal EDGE DL e um GPRS UL podem ou no compartilhar
um mesmo canal fsico no TRX.
A parametrizao que foi definida para a rede 2G da Huawei conforme tabela abaixo:
Parmetro Recomendado Parmetro Recomendado
MAXPDCHRATE* 50 DYNCHNPREEMPTLEV LEVEL0
UPDYNCHNTRANLEV 15 DYNCHNTRANRESLEV 0
DWNDYNCHNTRANLEV 15 DEFAULTDYNPDCHPRETRANNUM 0
CHIDLHIGHTHR 100 RESERVEDDYNPDCHPRETRANNUM 0
PDCHUPLEV 70 FORBIDEDGU OPEN
DWNPDCHLEV 80
* Valor alterado para 50% devido ao problema reportado acima.


21

9 Trial

9.1 Objetivo
Validar a nova gesto do trfego para a rede 2G da Unitel nas provncias com equipamentos
Huawei.

9.2 Cenrio do Trial
O Trial foi realizado na cidade de Malanje, por ser uma cidade relativamente grande com uma
grande densidade de sites GSM e DCS co-localizados.

9.2.1 Elementos Afetados
BSC
BML1H
SITES
CACULAMA LUMBO MALANGECTR QUISSANGA
CAMP_AVIAC LUMBO_DCS MALANGECTR_DCS QUISSANGA_DCS
CANAMBUA LUMBO_SUL MAXINDE RITONDO
CANAMBUA_DCS LUMBO_SUL_DCS MAXINDE_DCS RITONDO_DCS
CARREIRA_TIRO MALANGE_HOSPITAL NDA_CABUIL SUINGUE
CARREIRA_TIRO_DCS MALANGE_HOSPITAL_DCS PAVIL_ML_T VILA_MATILDE
GICA_ML MALANGE_OE QUESSUA VILA_MATILDE_DCS
KEMBA

9.3 Cronograma do Trial
O Trial foi realizado entre os dias 19 e 23 do ms de Junho de 2013.

9.4 Parametrizao
A parametrizao da nova gesto do trfego 2G e que utilizada para realizar o Trial est toda
definida abaixo. A Parametrizao est distribuda em 5 partes: Mobilidade 2G3G, Idle Mode Behavior,
Direct Retry, Half Rate e Handover.
Alm dos valores recomendados para a nova gesto a tabela abaixo incluir o MoClass do
parmetro para facilitar a sua implementao nas outras provncias.


22

Funo Parametro
Valor
Recomendado
MML
M
o
b
i
l
i
d
a
d
e

2
G
3
G

MSCVER R99_or_above
SET
GCELLCCUTRANSYS
QI 7
QCI Use_Qsearch_I
FDDQOFF 0
FDDRSCPMIN 6
FDDREP RSCP
FDDQMIN 7
FDDQMINOFFSET 0
QP 7
SEARCH3G YES
QSEARCHC 15
INTERRATCELLRESELEN YES SET GCELLHOBASIC
Send2QuterFlag YES SET BSCBASIC
I
d
l
e

M
o
d
e

B
e
h
a
v
i
o
r

CBQ - GSM|DCS NO|YES
SET GCELLIDLEBASIC
CBA - GSM|DCS NO|YES
PI YES
CRO - GSM|DCS 0|63
PT - GSM|DCS 0|31 SET GCELLIDLEAD
RXMIN - GSM|DCS 4|8 SET GCELLBASICPARA
D
i
r
e
c
t

R
e
t
r
y

DIRECTRYEN YES SET GCELLBASICPARA
ASSLOADJUDGEEN OFF
SET GCELLCCBASIC
DTLOADTHRED 85
MINPWRLEVDIRTRY 20
SET GCELLHOCTRL
H
a
l
f

R
a
t
e

TCHBUSYTHRES 70
SET GCELLCHMGAD
AMRTCHHPRIORLOAD 70


23

Funo Parametro
Valor
Recomendado
MML
H
a
n
d
o
v
e
r

HOCTRLSWITCH HOALGORITHM1
SET GCELLHOBASIC
SET GCELLHOEMG
SET GCELLHOFITPEN
SIGCHANHOEN NO
SET GCELLHOBASIC
INTRACELLHOEN NO
INTRACELLFHHOEN NO
QCKMVHOEN NO
RXQCKFALLHOEN NO
INTERFHOEN NO
QUICKHOEN NO
LOADHOEN NO
BQHOEN YES
TAHOEN YES
LEVHOEN YES
PBGTHOEN YES
FRINGEHOEN YES
QUICKPBGTHOEN YES
NOAMRFULLTOHALFHOALLOW NO
INTERRATOUTBSCHOEN NO
INTERRATINBSCHOEN YES
HOTHRES 15
DLEDGETHRES 8
ULEDGETHRES 4
LAYER - GSM|DCS 3|2 SET GCELLBASICPARA
LAYHOLOADTH - GSM|DCS 40|100
SET GCELLHOAD
TRIGTHRES 70
LoadAccThres 60
SYSFLOWLEV 10
LOADHOSTEP 5
LOADHOPERIOD 10
LOADOFFSET 25
INTERCELLHYST 70
MOD G2GNCELL INTELEVHOHYST 70
PBGTMARGIN 68


24

9.5 Resultados e Anlise
Abaixo esto os principais KPIs da rede. Os KPIs esto apresentados em duplicidade, pois o
primeiro grfico leva em conta apenas os sites Dualband (GSM e DCS) e o segundo todos os sites
envolvidos no Trial.

9.5.1 CSSR

No houve impacto negativo no CSSR dos sites envolvidos no Trial.
9.5.2 TCONG

No houve incremento no TCONG dos sites envolvidos no Trial.


25

9.5.3 SCONG

No houve incremento no SCONG dos sites envolvidos no Trial.
9.5.4 CDR

No houve incremento no CDR dos sites envolvidos no Trial.
9.5.5 SDR

No houve incremento no SDR dos sites envolvidos no Trial.

26

9.5.6 Trfego

Com a nova gesto houve uma melhor distribuio do trfego entre o GSM e o DCS.
9.5.7 Distribuio do Trfego GSM/DCS

Com a nova gesto houve uma melhor distribuio do trfego entre o GSM e o DCS.

27

9.5.8 Distribuio HR/FR

Devido a melhor distribuio do trfego entre o GSM e o DCS, foi possvel reduzir o trfego em
HR nos sites GSM de 50% para 20% aproximadamente.
9.5.9 Handover

No houve impacto negativo nos handovers dos sites envolvidos no Trial.

28

9.6 Concluso
Os resultados acima mostram que a nova gesto do trfego 2G cumpre com os objetivos
propostos de se ter uma rede 2G que permita acessos em ambas as tecnologias, GSM e DCS. Alm disto
o trfego total est de acordo com o pressuposto, 40% do trfego no GSM e 60% no DCS. Est estratgia
visa permitir que o GSM tenha capacidade para prover acessos onde o DCS no consegue cobrir
(ambientes Indoor).
Outro ponto com relao ao trfego HR, onde possvel ver que com a gesto proposta e a
correo de alguns parmetros, o trfego em HR foi reduzido para valores inferiores a 20% no GSM.
Como nenhum dos principais KPIs sofreu degradaes aparente e a gesto se mostrou funcionar
de acordo com os pr-requisitos a recomendao de alargar a parametrizao para as demais
provncias e sites da rede 2G da Unitel, cujo equipamento utilizado o da Huawei.

Nova Gestão de Trafego

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Nova Gestão de Trafego

Enviado por

Direitos autorais:

Formatos disponíveis

2G Traffic

Você também pode gostar