Modelos Desenvolvidos

Foi necess ´ario criar dois modelos para a implementac¸ ˜ao de JT no simulador LTE Downlink System Level Simulator v1.7 r1119 [IWR10]. Esses modelos ser ˜ao descritos nesta secc¸ ˜ao, assim como alterac¸ ˜oes de outra ordem no simulador. UEs que n ˜ao usem JT ser ˜ao referidos como UEs normais.

3.2.1 Uso de Joint Transmission

O primeiro modelo desenvolvido foi implementado no bloco “Criac¸ ˜ao da Rede”, Secc¸ ˜ao 3.1. Tem como finalidade decidir quais os UEs que usar ˜ao JT e encontrar para estes o(s) melhor(es) sector(es) para o fazerem. Podem ser ligados a 2 ou a 3 sectores, conforme o tipo de cooperac¸ ˜ao escolhido. Quanto `a formac¸ ˜ao de clusters de cooperac¸ ˜ao, foram 4 as definidas:

• todos os eNBs cooperam entre si, a rede ´e um ´unico cluster ; • definidos clusters de 2 eNBs;

• definidos clusters de 3 eNBs;

• apenas existe cooperac¸ ˜ao no pr ´oprio eNB, intra-eNB.

No caso de serem definidos clusters de tamanho 2 ou 3, estes s ˜ao definidos para uma dada rede e caso esta rede se altere, torna-se necess ´ario redefini-los. N ˜ao existe cooperac¸ ˜ao entre clusters diferentes. Os clusters usados nesta tese podem ser visualizados no Anexo B.

Tal como no simulador sem alterac¸ ˜oes, os UEs s ˜ao inicialmente ligados ao sector que apresentar menor valor de macroscopic pathloss. Como j ´a foi referido o mapa de macroscopic pathloss para cada sector ´e obtido atrav ´es da soma do pathloss, do ganho da antena e do desvanecimento lento. O primeiro sector ao qual os UEs se ligam ser ´a referido como sector principal. Os outros ser ˜ao os sectores secund ´arios.

De seguida ´e preciso definir quais as condic¸ ˜oes que permitam decidir se um dado UE usar ´a JT ou n ˜ao. Para isso foram criadas 3 vari ´aveis: relac¸ ˜ao entre o raio a partir do qual ´e considerado orla e o raio do eNB, valor de macroscopic pathloss m ´aximo para o sector principal que justifique a procura de outro sector, e diferenc¸a m ´axima entre o valor de macroscopic pathloss do sector principal para os secund ´arios. A primeira e a segunda vari ´avel s ˜ao aplicadas na condic¸ ˜ao 1 e condic¸ ˜ao 2 respetivamente:

Rmin[%]·^DeNB[m] 2 ^< q d2 x [m]+ d2 y [m] (3.4) onde:

• R_min: relac¸ ˜ao entre o raio a partir do qual ´e considerado orla e o raio do eNB; • D_eNB: dist ˆancia entre eNBs;

• d_x: componente x da dist ˆancia do UE ao eNB; • d_y: componente y da dist ˆancia do UE ao eNB.

PL_pri[dB]>PL_{max [dB]} (3.5) onde:

• PL_pri: valor de macroscopic pathloss para o sector principal;

• PL_max: valor de macroscopic pathloss m ´aximo para o sector principal que justifique a procura de outro sector.

A condic¸ ˜ao 1 far ´a com que UEs que se encontrem suficientemente longe do sector principal, e con-sequentemente a uma dist ˆancia semelhante dum sector secund ´ario, usem JT. A condic¸ ˜ao 2 garante que UEs que n ˜ao consigam um bom macroscopic pathloss devido ao diagrama de radiac¸ ˜ao e efeito sombra do sector procurem tamb ´em um sector secund ´ario. Outra vantagem da condic¸ ˜ao 2 ´e a invaria-bilidade quando se alteram valores de (3.1), ou mesmo quando se altera o modelo usado para c ´alculo de pathloss ou efeito sombra. Cada UE que cumpra pelo menos uma das condic¸ ˜oes referidas dever ´a ir

`a procura dum segundo e, dependendo dos par ˆametros de entrada, dum terceiro sector.

Depois de encontrado o segundo sector com menor macroscopic pathloss, ou seja, o primeiro sector secund ´ario, ´e necess ´ario que este cumpra a condic¸ ˜ao 3 antes que a ligac¸ ˜ao do UE ao sector seja feita:

PLsec[dB]<PLpri[dB]+ ∆PLmax [dB] (3.6)

onde:

• PL_sec: valor de macroscopic pathloss para o sector secund ´ario; • PL_pri: valor de macroscopic pathloss para o sector principal;

• ∆PL_max: diferenc¸a m ´axima entre o valor de macroscopic pathloss do sector principal para os secund ´arios.

Desta forma ´e garantido que um UE n ˜ao se liga a um sector secund ´ario se este n ˜ao apresentar um macroscopic pathloss semelhante, ou pelo menos n ˜ao muito superior ao do sector principal. Caso a ligac¸ ˜ao seja ent ˜ao feita para o segundo sector, o UE procura um terceiro sector. Tamb ´em o macroscopic pathloss para o terceiro sector tem de respeitar a condic¸ ˜ao 3. ´E poss´ıvel limitar a cooperac¸ ˜ao a dois sectores por UE no ficheiro de entrada, independentemente do tipo de cooperac¸ ˜ao escolhido.

No bloco “C ´alculo do SINR/CQI pelos UEs”, descrito na Secc¸ ˜ao 3.1, foi necess ´ario fazer alterac¸ ˜oes para suportar o uso de JT. Agora os UEs calculam tamb ´em para os sectores secund ´arios os seguin-tes valores: pathloss, ganho da antena, perdas de penetrac¸ ˜ao e desvanecimento lento e r ´apido. As pot ˆencias dos v ´arios sectores s ˜ao depois somadas na recec¸ ˜ao para o c ´alculo correto dos CQIs por parte dos UEs. Nesta tese o atraso no feedback entre os UEs e os eNBs ´e igual a 0 TTI, ou seja, os eNBs usam sempre os CQIs/RIs/PMIs ideais para o estado das ligac¸ ˜oes, tanto dos sectores principais como secund ´arios. N ˜ao ´e tirado partido do facto de haver mais antenas na emiss ˜ao por se usar JT, como por exemplo ganho de diversidade.

Na apresentac¸ ˜ao dos resultados foi criada uma func¸ ˜ao que calcula o n ´umero de UEs a usar JT (tanto ligados a 2 como a 3 sectores), o n ´umero de UEs restantes da orla sem usar JT, e o n ´umero de UEs do centro. ´E tamb ´em calculado o d ´ebito m ´edio para todos estes grupos de UEs. Todos estes valores s ˜ao impressos no ecr ˜a e guardados no ficheiro de resultados. Um UE pertence `a orla se cumprir a condic¸ ˜ao 1, (3.4).

3.2.2 Agendamento dos Recursos R ´adio

O agendamento de RBs que era feito at ´e ent ˜ao pelo simulador de forma individual passou a ser feito em conjunto entre sectores. Agora o pretendido ´e que, em cada TTI, UEs a usar JT tenham dispon´ıveis os mesmos RBs em todos os sectores aos quais est ˜ao ligados. Estas alterac¸ ˜oes foram feitas no bloco em que os eNBs recebem o feedback dos UEs e fazem o preenchimento da resource block grid (RBG). A RBG consiste num vetor de RBs onde o tamanho depende da largura de banda dispon´ıvel no sistema. Cada setor tem a sua RBG, logo por eNB existem 3 RBGs. Inicialmente cada sector agenda os recursos de forma individual e em concord ˆancia com o scheduler escolhido no ficheiro de entrada, tal como seria feito pelo simulador sem alterac¸ ˜oes. Depois ´e ent ˜ao aplicado um dos dois modelos criados nesta tese: Scheduler 1 ou Scheduler 2. O modelo a usar ´e especificado no ficheiro de entrada. O Scheduler 1 ´e executado para todos os UEs na RDI a usar JT, enquanto o Scheduler 2 ´e executado para todos os sectores na RDI.

O Scheduler 1 est ´a representado no diagrama de blocos da Figura 3.3.

S ˜ao primeiro calculadas as posic¸ ˜oes em que o UE a ser alterado se encontra nas RBGs. De recordar que nesta fase j ´a foi feito o agendamento dos recursos e as RBGs j ´a se encontram preenchidas. As posic¸ ˜oes s ˜ao obtidas segundo a forma dum vetor, e cada UE ter ´a um vetor para cada sector ao qual est ´a ligado. Cada posic¸ ˜ao do vetor indica um RB que o UE disp ˜oe no corrente TTI no correspondente sector. Neste momento existem ent ˜ao 2, ou 3 vetores para cada UE com muito provavelmente valores diferentes e tamanhos diferentes. Os vetores terem tamanhos diferentes acontece porque cada sector pode ter um n ´umero de UEs diferentes devido aos UEs a usar JT. O pretendido ´e que tenham os

Obter posic¸ ˜oes RBG Alterar RB ´ Ultimo RB? Limpar RBs isolados Sim N ˜ao

Figura 3.3: Diagrama de blocos do Scheduler 1, executado para todos os UEs da RDI.

mesmos valores e o mesmo tamanho. ´E feito um ciclo em que a cada iterac¸ ˜ao ´e tratada uma posic¸ ˜ao dos 2/3 vetores. Um dos valores do vetor ´e tido como o de refer ˆencia `a vez, e ´e tentado trocar os UEs que ocupam esse RB nos outros sectores. A troca ´e feita se:

• o RB n ˜ao esteja alocado a nenhum UE (traduz-se num 0 na RBG); • o UE ao qual pertenc¸a o RB n ˜ao esteja a usar JT;

• o identificador (ID) do UE seja superior ao ID do pr ´oprio UE.

Os UEs que n ˜ao usem JT podem ser alterados na RBG pelo facto de n ˜ao haver qualquer tipo de sin-cronismo entre sectores. Pelo contr ´ario alterar UEs a usar JT na RBG pode ser feito apenas se o ID for superior ao ID do pr ´oprio UE, o que significa que o Scheduler 1 ainda n ˜ao foi executado para este UE e portanto ainda n ˜ao existe sincronismo. Cada UE tem um ID ´unico em toda a rede.

Est ˜ao dispon´ıveis tantos valores de refer ˆencia quantos sectores aos quais um UE est ´a ligado por iterac¸ ˜ao. Se depois de tomadas as 2 ou 3 posic¸ ˜oes de refer ˆencias ainda n ˜ao tiver sido poss´ıvel co-ordenar os setores, s ˜ao alterados todos eles. Varre-se a RBG de todos os setores at ´e ser encontrado um RB comum em que seja poss´ıvel colocar o UE.

Caso um ou dois sectores tenham mais RBs alocados ao UE que os outros ou outro sector, estes RBs a mais s ˜ao alocados a UEs normais. Desta forma ´e garantido que os UEs s ˜ao servidos apenas quando h ´a coordenac¸ ˜ao entre todos os sectores aos quais est ˜ao ligados. Para encontrar UEs que n ˜ao usem JT

´e percorrida uma lista que cada sector tem com os UEs que este serve.

Caso o scheduler usado pelo simulador antes de ser executado o Scheduler 1 tenha em conta o des-vanecimento r ´apido em cada RB, e em particular neste caso em que o atraso no feedback ´e igual a 0, esta troca de RBs seria pouco eficiente. No entanto este n ˜ao ´e o caso j ´a que nenhum dos schedulers

implementados no simulador tem isso em conta.

O Scheduler 2 aloca uma percentagem da RBG destinada ao uso de JT. Esta percentagem ´e especifi-cada no ficheiro de entrada e ´e igual para todos os sectores. Na Figura 3.4 encontra-se o diagrama de blocos referente ao Scheduler 2. Cada bloco do diagrama ´e executado primeiro para todos os sectores, e s ´o depois se passa para o bloco seguinte. O primeiro bloco ´e executado para todos os sectores da rede enquanto os restantes apenas para sectores na RDI.

Desalocar parte das RBGs

Alocar uma vez UEs a usar JT

Preencher RBGs com UEs a usar JT

Finalizar RBGs com UEs normais

Figura 3.4: Diagrama de blocos do Scheduler 2, executado para todos os sectores.

Tal como no Scheduler 1, s ´o ´e alocado um determinado RB a um UE a usar JT se este for servido por todos os sectores aos quais est ´a ligado. Tamb ´em este modelo ´e aplicado depois de preenchida a RBG uma primeira vez. Comec¸am por ser retirados todos os UEs que usam JT da RBG, o que equivale a colocar um 0 em todos os RBs ocupados por estes. De seguida s ˜ao eliminados todos os UEs da percentagem da grelha que est ´a dedicada ao uso de JT. Da parte da RBG dedicada a UEs normais s ˜ao retirados os UEs que usam JT, e s ˜ao preenchidos esses RBs com UEs normais com recurso a um vetor de prioridades em que o UE na primeira posic¸ ˜ao ´e o que menos RBs tem na RBG. ´E usado o algoritmo de ordenac¸ ˜ao bubble sort [Moo14] para conseguir este vetor de prioridades. Depois de executado este bloco para todos os sectores, ´e passado ao pr ´oximo. As RBGs neste momento est ˜ao vazias at ´e ao

´ultimo RB alocado para JT e preenchidas por UEs normais nos restantes RBs.

No segundo bloco, cada sector aloca um RB para cada UE a usar JT que tenha o pr ´oprio sector como principal. Esta alocac¸ ˜ao s ´o ´e poss´ıvel se o RB estiver ainda livre tamb ´em nos sectores secund ´arios. Desta forma tenta-se garantir que haja pelo menos um RB para cada UE a usar JT. Isto pode n ˜ao acon-tecer se a percentagem da grelha alocada for menor que o n ´umero de UEs a usar JT num dado sector, ou se por motivos de sincronismo n ˜ao for poss´ıvel fazer a coordenac¸ ˜ao entre sectores para um dado UE. Os primeiros sectores ter ˜ao mais facilidade ao alocar visto disporem de mais RBs livres, tanto na sua RBG como na dos outros sectores. Caso esta parte da RBG fosse toda preenchida neste bloco, em muitos sectores quando chegasse a vez de preencher a sua parte j ´a seriam muito poucos os RBs dispon´ıveis e ent ˜ao haveriam muitos UEs sem um ´unico RB.

RB e s ˜ao tentados preencher os RBs ainda livres. ´E tamb ´em aqui usado o algoritmo bubble sort para criar um vetor de prioridades para UEs a usar JT. Pode ocorrer o caso em que mesmo usando este vetor de prioridades o UE a ser alocado seja sempre o mesmo por impossibilidade de sincronismo dos UEs com prioridade sobre este. Por este motivo foi criada a condic¸ ˜ao:

NRB> N_RB/RBG NUEs

+ Cd (3.7)

onde:

• N_RB: n ´umero de RBs do UE;

• N_RB/RBG: n ´umero total de RBs em cada RBG; • N_UEs: n ´umero de UEs ligados ao sector; • C_d: constante de desigualdade.

Se um UE tiver demasiados RBs na RBG, este ´e retirado do vetor de prioridades e fica portanto sem a possibilidade de lhe serem alocados mais RBs. O valor da constante de desigualdade ´e par ˆametro de entrada no simulador. Se esta constante tiver um valor negativo os UEs normais ser ˜ao favorecidos em termos de n ´umero de RBs alocados. Se pelo contr ´ario tiver um valor positivo os UEs a usar JT ser ˜ao os favorecidos.

Caso no terceiro bloco n ˜ao seja poss´ıvel preencher algum RB por motivos de sincronismo entre secto-res e em particular devido `a condic¸ ˜ao referida, estes RBs s ˜ao preenchidos no ´ultimo bloco. S ˜ao usados apenas UEs normais e ´e feito um vetor de prioridades de forma semelhante aos blocos anteriores. Todos os UEs na rede procuram sectores secund ´arios desde que cumpram uma das condic¸ ˜oes referi-das na Secc¸ ˜ao 3.2.1. Se apenas UEs ativos usassem JT as simulac¸ ˜oes seriam otimistas pelo que os eNBs da RDI usariam RBs de eNBs fora da RDI, sem que eles pr ´oprios “perdessem” RBs. Assim os eNBs da RDI usariam 100 % dos seus RBs mais RBs de eNBs fora da RDI. Os d ´ebitos s ˜ao calculados apenas para UEs ativos. Um UE est ´a ativo se o seu eNB principal pertencer `a RDI. Desta forma os RBs de eNBs da RDI n ˜ao usados por pertencerem a UEs desativos s ˜ao compensados pelos RBs de eNBs fora da RDI que se encontrem alocados a UEs ativos.