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

Nova Gestão de Trafego

Embed Size (px)

Citation preview

Page 1: Nova Gestão de Trafego

2G Traffic Management

Traffic steering between layers

Luanda, 24 de Junho de 2013

Page 2: Nova Gestão de Trafego

2G Traffic Management Traffic steering between layers

1

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

1.1 Objetivo ......................................................................................................................................... 3

1.2 Estratégia 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 Físicos ..................................................................................................................................... 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 Alocação dos CODE SCHEMES ...................................................................................................... 18

8.2 Parametrização Rádio .................................................................................................................. 19

9 Trial .................................................................................................................................................... 21

9.1 Objetivo ....................................................................................................................................... 21

9.2 Cenário do Trial ........................................................................................................................... 21

9.2.1 Elementos Afetados .............................................................................................................. 21

9.3 Cronograma do Trial .................................................................................................................... 21

9.4 Parametrização ............................................................................................................................ 21

9.5 Resultados e Análise .................................................................................................................... 24

9.5.1 CSSR ...................................................................................................................................... 24

9.5.2 TCONG .................................................................................................................................. 24

Page 3: Nova Gestão de Trafego

2G Traffic Management Traffic steering between layers

2

9.5.4 CDR ....................................................................................................................................... 25

9.5.5 SDR ....................................................................................................................................... 25

9.5.6 Tráfego ................................................................................................................................. 26

9.5.7 Distribuição do Tráfego GSM/DCS ......................................................................................... 26

9.5.8 Distribuição HR/FR ................................................................................................................ 27

9.5.9 Handover .............................................................................................................................. 27

9.6 Conclusão .................................................................................................................................... 28

Page 4: Nova Gestão de Trafego

2G Traffic Management Traffic steering between layers

3

1 Introdução

1.1 Objetivo

A nova gestão do tráfego visa permitir que os móveis em casos extremos acesse a rede via o sistema DCS.

1.2 Estratégia 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 células GSM;

iii. Os sistemas GSM e DCS devem ser diferenciados por prioridade, Layers:

1 GSM Cobertura/Acesso/Indoor;

2 DCS Capacidade;

iv. Células 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 proporção de 30/70, ou seja, as chamadas iniciam-se em HR somente após a célula chegar a 70% de ocupação e enquanto estiver acima desse valor;

vii. Mobilidade entre o GSM e o DCS:

1 Inter-Layer HO; (��� → ���)

i. Layer DCS prioritário em relação ao GSM;

ii. Trigger do HO leva em consideração a carga da célula servidora.

2 PBGT HO; ( ��� ↔ ���, ��� ↔ ���)

3 EDGE HO; (��� ↔ ���, ��� ↔ ��� e ��� ↔ ���)

i. Handover baseado no nível de sinal da célula servidora;

ii. HO ocorre nas bordas de cobertura da célula.

4 Load HO; (���/��� ↔ ���/���)

i. Handover com o intuito de liberar recursos no DCS, quando este estiver congestionado.

ii. Esse HO não será usado na gestão por defeito, porém mantive ele no documento para efeito de conhecimento.

Page 5: Nova Gestão de Trafego

2G Traffic Management Traffic steering between layers

4

2 IDLE MODE BEHAVIOR

2.1 MS em Dual Mode

i. INTERRATCELLRESELEN = YES; Ativa a reseleção 2G3G; ii. Send2QuterFlag = YES; iii. QI = 7; MS sempre faz a medição das células 3G em Idle Mode; iv. QP = 7; MS sempre faz a medição das células 3G em Packet Mode; v. QSEARCHC = 15; MS nunca faz as medições das células 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). Nível mínimo para fazer a reseleção para o 3G;

��������� > ���_� + �������

������� �0⁄ ≥ ������� − �������������

��������� ≥ ����������

*RLA_C é nível de sinal médio recebido da célula servidora (GSM).

Essas condições devem ser satisfeitas durante um período de 5s para que a reselecção seja feita para o 3G.

2.2 MS em 2G

Critério de Seleção:

i. Prioridade de seleção a. Definido através dos parâmetros CBQ e CBA: b. Priorizar as células GSM em detrimento das DCS:

i. GSM CBQ = CBA = NO; ii. DCS CBQ = CBA = YES.

Sistema CBQ CBA Seleção Reseleção

GSM NO NO Normal Normal

DCS YES YES Baixa Normal

Page 6: Nova Gestão de Trafego

2G Traffic Management Traffic steering between layers

5

ii. Critério do PATHLOSS

��1 = ����� − �����_������_��� − ���((��_�����_���_��� − �),0)

�1 = ����� − �����_������_���

a. RXLEV_ACCESS_MIN = RXMIN i. GSM RXMIN = 4, equivale a -106dBm ii. DCS RXMIN = 8, equivale a -102dBm

O RXMIN é um dos parâmetros otimizáveis, através deste será possível reduzir a área de cobertura do DCS, reduzindo o LOAD e evitando o TCONG. Esse parâmetro deverá ser alterado em conjunto com outros parâmetros utilizados nos processos de HO.

Critério de Reseleção:

��2 = �1 − ���, (�� = 31)

�2 = �1 + ���, (�� ≠ 31)

A reseleção 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.

Page 7: Nova Gestão de Trafego

2G Traffic Management Traffic steering between layers

6

3 Direct Retry O DR deverá estar ativo tanto no GSM quanto no DCS, para evitar bloqueio de chamadas em situações onde a célula servidora esteja congestionada (sem canais TCH disponíveis).

DIRECTRYEN = YES

O DR pode ser implementado de duas formas distintas:

1. ASSLOADJUDGEEN = OFF DR é realizado quando a célula servidora estiver com o LOAD acima dos 100%;

2. ASSLOADJUDGEEN = YES DR é realizado quando a célula servidora tiver um LOAD superior ao CDRTTRYFBDTHRES.

A seleção da célula target é feita de acordo com os seguintes critérios:

Carga da target ≤ DTLOADTHRED;

����������� ≥ MINPWRLEVDIRTRY.

Para evitar problemas do DR ser executado para uma célula que esteja sobrecarregada e/ou não possui uma boa qualidade de sinal, a carga da target deve ser inferior a 85% e o nível mínimo 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 avançar com a outra implementação do DR.

Implementação do DR, em todas as células GSM e DCS:

a. DIRECTRYEN = YES; b. ASSLOADJUDGEEN = OFF; c. DTLOADTHRED = 85; d. MINPWRLEVDIRTRY = 20.

Page 8: Nova Gestão de Trafego

2G Traffic Management Traffic steering between layers

7

4 Half Rate

De acordo com as recomendações da Unitel a proporção entre o tráfego HalfRate e o FullRate não deve ser superior à 30%.

Por defeito a prioridade na alocação de canais é: AMR/FR, Enhanced FR, FR, AMR/HR e HR. Essa prioridade visa proporcionar uma melhor qualidade de serviço aos usuários, visto que, o AMR/FR, EFR e FR possuem uma melhor proteção a interferência em relação ao AMR/HR e HR.

O princípio de funcionamento do algoritmo de alocação é: quando a taxa de ocupação dos canais é elevada, i.e., o setor está sobrecarregado, um canal TCH/HR é preferencialmente alocado, caso contrário o TCH/FR tem prioridade. A alocação 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 são: AMRTCHHPRIORLOAD e TCHBUSYTHRES, respectivamente. E a fórmula usada para calcular a taxa de ocupação dos canais é conforme segue:

�����çã� = �ú���� �� ������ �� �������� + �ú���� �� ������ �� �������� 2⁄

�ú���� �� ������ �� ������í���� + �ú���� �� ������ �� ������í���� 2⁄∗ 100%

O número de canais disponíveis é referente ao número de canais ocupados e aos livres. Inclusive os canais configurados como PDTCHs dinâmicos que não estejam sendo usados pelo GPRS/EDGE são incluídos no cálculo.

Para que a razão entre TCH/FR e TCH/HR seja mantida nos 30%, é preciso definir os parâmetros AMRTCHHPRIORLOAD e TCHBUSYTHRES, ambos em 70%. Desta forma a alocação dos canais em HR só irão começar quando 70% dos canais estiverem ocupados.

Parametrização do HalfRate implementada:

1. GSM/DCS

o TCHBUSYTHRES = 70;

o AMRTCHHPRIORLOAD = 70.

Fica a dica: Como a gestão de tráfego faz uso do InterLayer HO (ver tópico sobre Handover),

para enviar o tráfego do GSM para o DCS, quando a ocupação no GSM estiver acima dos 40%, o tráfego

no GSM será em sua maioria em FR. Caso o DCS apresente congestões de canais TCHs, uma das formas

de se resolver é altera os thresholds de alocação de canais HR no GSM.

Ao se alterar esses thresholds para valores inferiores a 40% o GSM irá começar a processar

tráfego em HR antes de Interlayer HO começar a migrar o tráfego para o DCS, com o aumento do

tráfego no GSM será visível uma redução de tráfego no DCS, reduzindo assim o congestionamento.

Page 9: Nova Gestão de Trafego

2G Traffic Management Traffic steering between layers

8

5 HANDOVER O Algoritmo de Handover utilizado é o “Handover Algorithm I” (HOCTRLSWITCH = HOALGORITHM1). Segundo este algoritmo os HOs existentes e suas prioridades são conforme figura abaixo:

Figure 1 - Tipos de Handover

Desconsiderando os handovers de emergência, visto que estes sempre serão utilizados para

evitar quedas de chamadas no limite da cobertura/qualidade do sinal. Os handovers que serão implementados na nova gestão para proporcionar um balanceamento do tráfego bem como uma melhor mobilidade são:

i. INTER-LAYER HO; ii. PBGT HO; iii. EDGE HO; iv. LOAD HO - Não será implementado de imediato.

Por defeito o SDCCH HO estará desabilitado:

SIGCHANHOEN = OFF;

Page 10: Nova Gestão de Trafego

2G Traffic Management Traffic steering between layers

9

5.1 INTER-LAYER HO Definição dos Layers (quanto maior o Layer menor a prioridade):

GSM LAYER = 3;

DCS LAYER = 2;

Indoor LAYER = 1. Se achar necessário.

Ativação do INTER-LAYER HO LEVHOEN = YES.

Condições para ser executado o INTER-LAYER HO (Trigger):

1. LAYER da servidora < LAYER da Target 2. LOAD da servidora > LAYHOLOADTH 3. ����������� ≥ ������� + ������������� − 64

(Condição P/N): Todas essas condições devem ser observadas LEVSTAT (p) segundos dentro de LEVLAST (n) segundos.

Através do LAYHOLOADTH é possível manter o tráfego no GSM até este atingir um certo nível

de carga, situação semelhante ao HCSOUT disponível no HCS na Ericsson. Como na Huawei não existe um parâmetro semelhante ao HCSIN na Ericsson, onde é possível limitar o HO por HCS devido à carga na Target, é recomendado definir um valor para o LAYHOLOADTH a fim de evitar que todo o tráfego passe para o DCS e gere problemas de congestão, TCONG.

LAYHOLOADTH = 40.

Com relação à seleção da célula target, está deve possuir um nível de sinal superior ao HOTHRES + INTELEVHOHYST – 64, onde:

HOTHRES é nível de sinal mínimo para que a célula 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 parâmetro é definido como sendo um inteiro entre 0 e 127, o fator -64 é introduzido na fórmula para transforma o INTELEVHOHYST é dB. Semelhante ao LAYERHYST do HCS da Ericsson.

Page 11: Nova Gestão de Trafego

2G Traffic Management Traffic steering between layers

10

Para manter o padrão com a rede Ericsson, esses parâmetros serão assim definidos:

HOTHRES = -95;

INTERLEVHOHYST = 70. (Equivale a 6dB = 70 - 64).

Resumo para implantação:

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 ��� ↔ ��� e o ��� ↔���. O PBGT HO será utilizado para proporcionar um maior grau de mobilidade aos usuários em movimento, visto que, para disparar o HO é preciso, de forma simplificada, apenas que a diferença entre os níveis de sinal da célula servidora e da célula target seja superior a margem definida para o PBGT HO.

Ativação do PBGT HO PBGTHOEN = YES.

Trigger do HO:

����������� − ������� − ������������ > ���������� − 64

(Condição P/N): A condição acima deve ser observada PBGTLAST (p) segundos dentro de PBGTLSTAT (n) segundos.

O ������� está associado ao POWER CONTROL e é definido como sendo a diferença entre a

potência máxima de transmissão e a potência atual de transmissão na célula servidora.

O PBGTMARGIN por defeito está configurado em 4dB:

PBGTMARGIN = 68. (68 - 64 = 4dB)

Esse parâmetro será um dos parâmetros otimizáveis na nova gestão, visto que, através dele é possível aumentar e/ou reduzir a cobertura das células intra-layers, facilitando e/ou dificultando o HO entre células. Isto permitirá fazer um balanceamento de tráfego entre células vizinhas, reduzindo, provavelmente, a congestão em uma delas.

Resumo para implantação:

PBGTHOEN = YES;

PBGTMARGIN = 68;

Page 12: Nova Gestão de Trafego

2G Traffic Management Traffic steering between layers

11

5.3 EDGE HO O EDGE HO também é baseado no nível de sinal, bastante semelhante ao PBGT HO. A diferença básica entre os dois está no fato de que, ao contrário do PBGT HO, onde o trigger é a diferença entre os níveis de sinal. O EDGE HO tem como trigger um limiar para o nível de sinal da célula servidora, podendo ser tanto o nível no DL quanto no UL e/ou o “power budget” entre o a servidora e a target,

��_������������ < �������������

��_������������ < �����������

Ou

����������� > ������������ + ������������� − 64

(Condição P/N): As condições acima devem ser observadas EDGELAST1 (p) segundos dentro de EDGESTAT1 (n) segundos.

Após o rank das células target a célula selecionada para receber o HO deve ter uma prioridade (critério M – desnecessário de momento a sua explicação) maior que a célula servidora, obedecendo o critério P/N, ou seja, durante EDGEADJSTATTIME segundos a célula target deve aparecer EDGEADJLASTTIME vezes com prioridade superior a célula servidora.

O EDGE HO é bastante interessante, pois ele para além de incluir uma espécie de PBGT HO, ele também se assemelha a um HO de emergência por nível, ao despoletar o HO, quando o nível da célula target está fora do limite definido como aceitável, DLEDGETHRES/ULEDGETHRES.

Como critério para a gestão do tráfego 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 célula 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 célula 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 faça 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 diferença 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 otimização: Sempre que for preciso reduzir a área de cobertura de uma célula DCS para evitar o TCONG, para além 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 célula terá a mesma área de cobertura tanto em IDLE quanto em DEDICADO. Atenção ao fato de que o HOTHRES do INTERLAYER HO também 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, vocês devem ter isso em mente).

Page 13: Nova Gestão de Trafego

2G Traffic Management Traffic steering between layers

12

Resumo para implantação:

FRINGEHOEN = YES;

DLEDGETHRES = 8;

ULEDGETHRES = 4;

INTERCELLHYST = 70;

5.4 LOAD HO (* Essa solução ainda precisa ser testada melhor e apesar de ser discutida abaixo, ela por defeito não será implementada)

Como o INTER-LAYER HO não possui nenhum parâmetro similar ao HCSIN da Ericsson, não tem como se controlar o LOAD nas células DCS via o INTER-LAYER HO. Desta forma o LOAD HO terá como função 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 célula servidora está sobrecarregada, LOAD > TRIGTHRES, a BSC irá definir uma área de cobertura, definida pelos níveis (DLEDGETHRES, DLEDGETHRES + LOADHOSTEP) e todos os MS inseridos dentro desta área poderão sofrer um HO para as células vizinhas.

Após um certo período, definido por LOADHOPERIOD, caso a célula servidora continue congestionada, uma nova região será definida, (DLEDGETHRES, DLEDGETHRES + 2*LOADHOSTEP). Este processo se repete de criar novas áreas de cobertura continua até que a célula servidora fique descongestionada, LOAD <= TRIGTHRES.

Enquanto isso as novas regiões serão definidas conforme a seguinte fórmula, (DLEDGETHRES, DLEDGETHRES + x*LOADSTEP). Entretanto, quando o DLEDGETHRES + x*LOADSTEP for igual ou superior ao LOADOFFSET não será criada nenhuma nova região, porém o LOAD HO continuará a ser executado na região atual até que a carga da célula seja igual ou inferior ao TRIGTHRES.

Como o LOAD HO pode despoletar uma quantidade muito grande de handover em simultâneo, existe um critério de segurança para evitar que o processamento da BSC entre em overflow. Isto significa dizer que, o LOAD HO só será executado se a utilização da CPU for inferior a um determinado valor:

CPU USAGE ≤ SYSFLOWLEV

A outra condição para o trigger do LOAD HO é que a célula servidora esteja sobrecarregada:

Load da célula servidora ≥ TRIGTHRES;

Já a seleção da célula target é baseada nas seguintes condições:

����������� ≥ ������� + �������������� − 64 ;

Load da target ≤ LoadAccThres;

Explicado o conceito do LOAD HO, passemos para a sua implementação.

Apesar do LOAD ser usado para descongestionar o DCS, este também pode estar ativo no GSM, de forma a tentar descongestionar o GSM também, assim temos:

LOADHOEN = YES; Tanto para o GSM quanto para o DCS;

Page 14: Nova Gestão de Trafego

2G Traffic Management Traffic steering between layers

13

GSM o TRIGTHRES = 70; Ou seja, quando a célula estiver com 70% de ocupação ativa-se o LOAD

HO. Esse parâmetro deve ser maior que o LAYHOLOADTH do INTER-LAYER de forma a evitar HO’s desnecessários entre o GSM, antes do MS ser enviado ao DCS.

o LoadAccThres = 60; Células GSM só irão 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 otimização.

DCS o TRIGTHRES = 70; Por defeito mantemos ambos os valores em 70%, porém para o caso do

DCS esse parâmetro poderá ser otimizável caso necessário; o LoadAccThres = 60; Células DCS só irão 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 otimização.

SYSFLOWLEV = 10; Este é o valor por defeito e significa que o LOAD HO será executado mesmo quando a utilização da CPU esteja igual a 100%;

LOADHOSTEP = 5;

LOADHOPERIOD = 10;

LOADOFFSET = 25 (equivale a -85dBm). Otimização: Essa parte fica em aberto, pois primeiro é preciso fazer testes mais detalhados no LOAD HO, antes de decidir quais parâmetros podem ser alterados e quais deveram manter sempre fixo.

Resumo para implantação:

LOADHOEN = YES; Tanto para o GSM quanto para o DCS;

TRIGTHRES = 70;

LoadAccThres = 60;

SYSFLOWLEV = 10;

LOADHOSTEP = 5;

LOADHOPERIOD = 10;

LOADOFFSET = 25.

Page 15: Nova Gestão de Trafego

2G Traffic Management Traffic steering between layers

14

6 Canais Físicos

Com a nova gestão do tráfego não será preciso, a priori, alterar quaisquer configurações a nível de canais físicos, ou seja, os sites continuarão a ter as seguintes configurações:

1. GSM a. 4 SDCCH; b. 2 PDTCH.

2. DCS a. 1 SDCCH; b. 0 PDTCH.

Assim que a nova gestão for implementada, é preciso testar a parte de PACKET no DCS e redefinir a quantidade de canais de PDTCHs.

Com relação aos canais de SDCCH, é de responsabilidade de cada um, validar se a célula apresenta SCONG e tomar ações para reduzi-lo, incluindo mais canais de SDCCH. Como a prioridade de seleção e reseleção são as células GSM, não é preciso definir mais do que um canal de SDCCH no DCS, a menos que se faça necessário.

Page 16: Nova Gestão de Trafego

2G Traffic Management Traffic steering between layers

15

7 Abis O intuito deste tópico é de caráter informativo e para ilustrar a feature do FlexAbis (adquirida

pela Unitel), para mais detalhes é preciso ler a documentação própria da Huawei sobre transmissão.

7.1 FixAbis

Neste tipo de configuração 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 não são mapeados na Abis, pois toda a sinalização é enviada através do canal de RSL (Radio Signaling Link).

Figure 2 - Mapeamento FixAbis

Cada TRX possui um RSL associado e devido a multiplexação estatística 4:1, pode-se multiplexar 4 RSL’s em um único TS de 64Kbps na Abis. O OML é mapeado em um único TS de 64Kbps no Abis também devido a multiplexação selecionada ser a estatística.

O problema do FixAbis é a deficiência na gestão dos recursos da abis (TimeSlots), pois como o mapeamento é fixo, mesmo que o TS não esteja sendo utilizado por um canal TCH (Voz), o TS na Abis fica ocupado e não pode ser usado para o GPRS/EDGE.

7.1.1 IDLE TimeSlot (GPRS/EDGE)

Tanto no FixAbis, quanto no FlexAbis, é possível definirmos TimeSlots(TS) extras para os dados. Esses TS são conhecidos como os IDLE_TS(16kbps).

Qual o impacto de adicionarmos esses IDLE_TS principalmente no FixAbis?

O gráfico Abaixo mostra os throughputs máximo por PDTCH atingidos pelos serviços de dados em GPRS/EDGE. Se levar em consideração que o móvel pode alocar mais de um PDTCH por conexão, o throughput final vai ser multiplicado pela quantidade de TS usados na conexão. Supondo que o móvel estabeleça uma conexão de dados e que utilize 3 PDTCHs no downlink com o code scheme MCS-9 (EDGE), sua taxa final será de:

3 ����� � 59.2���� = ���. �����

Page 17: Nova Gestão de Trafego

2G Traffic Management Traffic steering between layers

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 (aérea) permitir taxas de 177kbps, a Abis iria limitar o serviço em 48Kbps. Com a definição dos IDLE_TS (TSCOUNT), a Abis pode usar esses TS em conjunto com os mapeados para os PDTCHs e com isso ter banda disponível para prover uma maior taxa ao GPRS/EDGE, não sendo mais um limitante.

7.2 FlexAbis

Com a ativação da feature de FlexAbis, o único mapeamento fixo que existe entre os canais físicos do TRX e a Abis são os canais de PDTCH. Além disso o OML e os RSLs ainda são mantidos prefixados na Abis. Com a ativação da feature um novo canal de sinalização também é adicionado, o ESL (Extended Signaling Link), cujo mapeamento é feito no mesmo TS do OML na Abis, ou seja, o ESL e o OML são multiplexados na Abis.

Todos os demais TS da Abis são adicionados a uma pool de recursos que a BSC de forma dinâmica aloca para os serviços 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

Page 18: Nova Gestão de Trafego

2G Traffic Management Traffic steering between layers

17

No FlexAbis os TS da Abis são divididos em sub-TS de 8Kbps e o mapeamento entre os TS do TRX e os Sub-TS na Abis seguem o seguinte princípio.

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 transmissão em TDM devem ter a seguinte configuração:

FLEXABISMODE = FLEX_ABIS – Ativação do FlexAbis;

MPMODE = 4:1 – Tipo de multiplexação dos RSLs;

TSCOUNT = 0 – Número mínimo de subTS na ABIS dedicados para PS (IDLE_TS).

Como a Abis será configurada como Flex não há a necessidade de se configurar TS extras para o GPRS/EDGE, visto que os TS da Abis serão alocados de forma dinâmica e caso haja disponibilidade de recursos na Abis, novos TS serão alocados para o GPRS/EDGE para prover maior throughput ao usuário.

7.2.1 Load Control

Com a ativação do FlexAbis é possível 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 disponível na Abis seja inferior ao valor deste parâmetro a BSC vai iniciar as ações para descongestionar a ABIS. Por defeito o TDMCONGTH está definido em 15%;

b. AÇÕES: i. PSDOWN – Reduz o throughput dos móveis em GPRS/EDGE; ii. CSPH – As novas chamadas de voz terão preferência por canais HR;

iii. CSFHHO – BSC inicia HO de TCH FR para TCH HR para reduzir a ocupação 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 não é recomendado fazer intracell HO está ação não deve ser definida.

Para ativar as ações basta definir a sequência 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 serviço 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.

Page 19: Nova Gestão de Trafego

2G Traffic Management Traffic steering between layers

18

8 GPRS/EDGE

8.1 Alocação dos CODE SCHEMES

A alocação dos Code Schemes pode ser feita de duas formas distintas:

1. Alocação Fixa;

2. Alocação Dinâmica.

Na alocação fixa é definido um CODE SCHEME único para o UPLINK e outro para o DOWNLINK e todas as conexões GPRS/EDGE irão fazer uso desta codificação. Esse cenário não é razoável, pois dependendo da qualidade do sinal (PATHLOSS/INTERFERENCE/SIGNAL STRENGHT), a codificação utilizada pode não ser a ideal e o serviço de PS não funcionará corretamente. Para resolver isto, pode-se configurar um Coding Scheme mais baixo (CS-1 ou CS-2). Entretanto, desta forma, estaria limitando o serviço PS a taxas muito baixas e o serviço também não funcionaria de forma eficiente.

Na alocação dinâmica, a BSC, de acordo com a qualidade do sinal e a taxa de retransmissão do TBF, irá determinar qual é o melhor Code Scheme a ser utilizado no momento. Para isto, é preciso definir os parâmetros, UPFIXCS, DNFIXCS, UPFIXMCS e DNFIXMCS como UNFIXED.

Quanto pior a qualidade do sinal na interface aérea, maior o número de retransmissões do TBF, principalmente ao se utilizar CODE SCHEMES maiores, pois possuem menos bits de paridade em sua composição e com isso são mais susceptíveis a interferência.

Por isso que para que o serviço de GPRS/EDGE seja adequado, é preciso ajustar os code schemes de forma dinâmica e de acordo com a qualidade do sinal, evitando assim retransmissões desnecessárias e proporcionando uma melhor experiência ao usuário final.

Na alocação dinâmica é preciso definir o CODE SCHEME inicial, ou seja, o CODE SCHEME que todos os usuários irão usar para iniciar o serviço. Para evitar problemas de acessibilidade e como, a priori, não se sabe a qualidade do sinal sem antes iniciar a sessão de dados, o CODE SCHEME inicial não 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 usuário.

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 retransmissão do TBF(UL ou DL) for menor ao UPTHDUPGRADE1 ou DNTHDUPGRADE1 a BSC seleciona o CS-2;

Se o CODE SCHEME atual for o CS-2 e a taxa de retransmissão do TBF(UL ou DL) for menor ao 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;

Page 20: Nova Gestão de Trafego

2G Traffic Management Traffic steering between layers

19

Se o CODE SCHEME atual for o CS-3 e a taxa de retransmissão do TBF(UL ou DL) for menor ao UPTHDUPGRADE3 ou DNTHDUPGRADE3 a BSC seleciona o CS-4; E se a taxa for maior que UPTHDUPGRADE2 ou DNTHDUPGRADE2 a BSC faz o downgrade para o CS-2;

Se o CODE SCHEME atual for o CS-4 e a taxa de retransmissão do TBF(UL ou DL) for maior ao UPTHDUPGRADE3 ou DNTHDUPGRADE3 a BSC faz o downgrade para o CS-3;

Para o EDGE a alocação dinâmica pode ser feita utilizando dois métodos de controle de

qualidade do link:

Link Adaptation – LA

Incremental Redundancy – IR

O método utilizado na rede é o IR, pois, pois o LA funciona melhor quando se tem uma qualidade do sinal bastante razoável. O parâmetro que define o tipo de Link Quality Control é o LQCMODE.

LQCMODE = IR.

No EDGE a definição de se fazer um upgrade/downgrade do Code Scheme é feita através dos BEP (Bit Error Probability) Measurement Reports, que podem ser gerados pela BTS ou pelo MS. A periodicidade de envio é definida pelo parâmetro BEPPERIOD.

BEPPERIOD = 5.

Existe também dois contadores que são utilizados para fazer o downgrade do CODE SCHEME, tanto para o GPRS quanto para o EDGE, são eles: N3101 e N3105. Esses contadores basicamente contam a quantidade de retransmissões do TBF no Uplink e no Downlink, respectivamente. E quando esses valores ultrapassam o limite, é feito um abnormal release do TBF e o móvel é forçado a alocar um CODE SCHEME inferior ao atual.

N3101 = 20;

N3105 = 10.

8.2 Parametrização Rádio

Para além das parametrizações acima também foi definido um grupo de parâmetros para tentar melhorar a qualidade dos serviços de dados no 2G, esses parâmetros serão explicados abaixo.

1. MAXPDCHRATE – Define a quantidade máxima de TS na interface áerea que pode ser utilizado para PS:

�º �� ����� = ������������ � (�º ��� + ������ �����)

Por defeito esse parâmetro deveria ser configurado em 100%, i.e., todos os TS dos TRXs poderiam ser utilizados para o serviço de GPRS/EDGE. Entretanto devido a alguns problemas experimentados (bloqueio de chamadas) com essa configuração, 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.

Page 21: Nova Gestão de Trafego

2G Traffic Management Traffic steering between layers

20

2. UPDYNCHNTRANLEV – Define o número de usuários multiplexados em um único TS no Uplink. É usado como trigger para iniciar as conversões de TS TCH para PDTCH;

i. Quanto menor esse valor mais rápido a célula inicia a realocação dos usuários em novos TS de PDTCH UL, isso implica a conversão de TS TCH para PDTCH;

3. DWNDYNCHNTRANLEV – Define o número de usuários multiplexados em um único TS no Downlink. É usado como trigger para iniciar as conversões de TSL TCH para PDTCH;

i. Quanto menor esse valor mais rápido a célula inicia a realocação dos usuários em novos TS de PDTCH DL, isso implica a conversão de TS TCH para PDTCH;

4. CHIDLHIGHTHR – Threshold usado para despoletar as conversões de PDTCHs dinâmicos.

i. Quando o CHIDLHIGHTHR está definido em 100%, sempre que o número máximo de usuários multiplexados em um único TS atinge um dos limites definidos por UPDYNCHNTRANLEV e DWNDYNCHNTRANLEV, a BSC inicia as conversões de PDTCHs dinâmicos;

5. PDCHUPLEV – Define o número de TBFs permitidos em um único TS no Uplink.

i. Para permitir as conversões dos PDTCHs dinâmicos, este parâmetro deve ser superior ao UPDYNCHNTRANLEV;

6. DWNPDCHLEV – Define o número de TBFs permitidos em um único TS no Downlink.

i. Para permitir as conversões dos PDTCHs dinâmicos, este parâmetro deve ser superior ao DWNDYNCHNTRANLEV;

7. DYNCHNPREEMPTLEV – Define o tipo de preemption dos PDTCHs dinâmicos.

8. DYNCHNTRANRESLEV – Número de canais TCH/FR reservados para voz.

9. DEFAULTDYNPDCHPRETRANNUM – Define um número de TS que são criados por defeito como PDTCHs dinâmicos.

i. Esses canais quando em IDLE podem ser convertidos em TCH/F;

10. RESERVEDDYNPDCHPRETRANNUM – Define o número de canais PDTCHs dinâmicos reservados(DEFAULTDYNPDCHPRETRANNUM) que não podem sofrer o preemption.

11. FORBIDEDGU – Define se um canal EDGE DL e um GPRS UL podem ou não compartilhar um mesmo canal físico no TRX.

A parametrização que foi definida para a rede 2G da Huawei é conforme tabela abaixo:

Parâmetro Recomendado Parâmetro 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.

Page 22: Nova Gestão de Trafego

2G Traffic Management Traffic steering between layers

21

9 Trial

9.1 Objetivo

Validar a nova gestão do tráfego para a rede 2G da Unitel nas províncias com equipamentos Huawei.

9.2 Cenário 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 mês de Junho de 2013.

9.4 Parametrização A parametrização da nova gestão do tráfego 2G e que utilizada para realizar o Trial está toda

definida abaixo. A Parametrização está distribuída em 5 partes: Mobilidade 2G3G, Idle Mode Behavior, Direct Retry, Half Rate e Handover.

Além dos valores recomendados para a nova gestão a tabela abaixo incluir o MoClass do parâmetro para facilitar a sua implementação nas outras províncias.

Page 23: Nova Gestão de Trafego

2G Traffic Management Traffic steering between layers

22

Função Parametro Valor

Recomendado MML

Mo

bilid

ade 2

G3

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

Idle M

od

e Beh

avior

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

Direct R

etry

DIRECTRYEN YES SET GCELLBASICPARA

ASSLOADJUDGEEN OFF SET GCELLCCBASIC

DTLOADTHRED 85

MINPWRLEVDIRTRY 20 SET GCELLHOCTRL H

alf

Rate

TCHBUSYTHRES 70 SET GCELLCHMGAD

AMRTCHHPRIORLOAD 70

Page 24: Nova Gestão de Trafego

2G Traffic Management Traffic steering between layers

23

Função Parametro Valor

Recomendado MML

Han

do

ver

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

Page 25: Nova Gestão de Trafego

2G Traffic Management Traffic steering between layers

24

9.5 Resultados e Análise Abaixo estão os principais KPIs da rede. Os KPIs estão apresentados em duplicidade, pois o

primeiro gráfico leva em conta apenas os sites Dualband (GSM e DCS) e o segundo todos os sites envolvidos no Trial.

9.5.1 CSSR

Não houve impacto negativo no CSSR dos sites envolvidos no Trial.

9.5.2 TCONG

Não houve incremento no TCONG dos sites envolvidos no Trial.

Page 26: Nova Gestão de Trafego

2G Traffic Management Traffic steering between layers

25

9.5.3 SCONG

Não houve incremento no SCONG dos sites envolvidos no Trial.

9.5.4 CDR

Não houve incremento no CDR dos sites envolvidos no Trial.

9.5.5 SDR

Não houve incremento no SDR dos sites envolvidos no Trial.

Page 27: Nova Gestão de Trafego

2G Traffic Management Traffic steering between layers

26

9.5.6 Tráfego

Com a nova gestão houve uma melhor distribuição do tráfego entre o GSM e o DCS.

9.5.7 Distribuição do Tráfego GSM/DCS

Com a nova gestão houve uma melhor distribuição do tráfego entre o GSM e o DCS.

Page 28: Nova Gestão de Trafego

2G Traffic Management Traffic steering between layers

27

9.5.8 Distribuição HR/FR

Devido a melhor distribuição do tráfego entre o GSM e o DCS, foi possível reduzir o tráfego em HR nos sites GSM de 50% para 20% aproximadamente.

9.5.9 Handover

Não houve impacto negativo nos handovers dos sites envolvidos no Trial.

Page 29: Nova Gestão de Trafego

2G Traffic Management Traffic steering between layers

28

9.6 Conclusão Os resultados acima mostram que a nova gestão do tráfego 2G cumpre com os objetivos

propostos de se ter uma rede 2G que permita acessos em ambas as tecnologias, GSM e DCS. Além disto o tráfego total está de acordo com o pressuposto, 40% do tráfego no GSM e 60% no DCS. Está estratégia visa permitir que o GSM tenha capacidade para prover acessos onde o DCS não consegue cobrir (ambientes Indoor).

Outro ponto é com relação ao tráfego HR, onde é possível ver que com a gestão proposta e a correção de alguns parâmetros, o tráfego em HR foi reduzido para valores inferiores a 20% no GSM.

Como nenhum dos principais KPIs sofreu degradações aparente e a gestão se mostrou funcionar de acordo com os pré-requisitos a recomendação é de alargar a parametrização para as demais províncias e sites da rede 2G da Unitel, cujo equipamento utilizado é o da Huawei.