Criação de EPS-Bearers com requerimentos de QoS

A Figura 4.6 descreve o procedimento para a criação de EPS-Bearers específicos considerando um UE 4G (um procedimento similar pode ser definido utilizando uma tecnologia de acesso 5G). Como será mostrado, para este procedimento não é requerido realizar mudanças nas terminais mó- veis 4G, porém, o procedimento de criação de EPS-Bearer com QoS proposto requer significativas mudanças sé é comparado com o procedimento utilizado hoje na arquitetura PCC (Policy Control and Charging ). A seguir é descrito o procedimento proposto.

1. Inicialmente, o tráfego com requerimentos de QoS é encaminhado simultaneamente utilizando o OF-Bearer por default, e é enviado à tabela de detecção de tráfego, que encaminha o tráfego para o SDD. Logo, o SDD processa os pacotes é para determinar as caraterísticas e necessidades do serviço. Esta informação é enviada para o PCRF (ou para um novo elemento com essa funcionalidade), o que debe definir as políticas a serem aplicadas.

2. Se é requerida informação adicional, o PCRF pode solicitar esta informação a outro elemento móvel. Como exemplo, pode ser realizada uma solicitação de informação de crédito disponível ao OCS (Online Charging System) o que determinará o tempo ou quantidade de tráfego que pode ser transmitida para esse serviço.

Flow Table

OCS

UE

1. O Tráfego com QoS é detetado e enviado por duas linhas de processamento, ao SDD e pela OF-Bearer por default

3. Definição de política 2. Informação de crédito

5. Classificação do tráfego utilizando UL-TFT PCRF eNodeB 0. Default radio bearer 4. Radio bearer with QoS 0. Default OF-Bearer 0. or 4. OF-bearer with QoS

Rede de Backhaul Móvil

PDN

5. Mensagem para criar um radio Bearer com QoS

Flow Table

5. Clasificação do tráfego utilizando entradas de fluxo para serviço especificas S1-MME

Controlador

Orquestador Móvil

MME

6. Mensagem Flow-add para criar EPS-Bearer com QoS

E-UTRAN Uu

4. Se não existe um OF-Bearer com QoS apropriado, um será criado

SDD

Figura 4.6: Procedimento para a criação de EPS-Bearer com QoS.

3. Com a informação da característica do tráfego, do perfil de usuário, de o credito disponível, o PCRF define a política a ser aplicada (as características que deve ter o EPS-Bearer a ser criado). Finalmente, á politica é comunicada ao MME e ao Controlador.

4. Se já existe um OF-Bearer com as características de QoS apropriadas para esse tráfego, este será utilizado. Por outro lado, se ainda não existe um OF-Bearer com essas caraterísticas, o Controlador criará um novo OF-Bearer que cumpra com os requerimentos de QoS. Para isso, o Controlador define o rótulo MPLS externo apropriado e cria as entradas de fluxo em cada um dos switches OpenFlow envolvidos no caminho com QoS fim a fim.

5. A seguir são indicados os passos para a criação de Radio Brearer com QoS:

(a) O MME envia uma mensagem de solicitação 3GPP padrão do tipo bearer setup request (utilizando a interface padrão S1-MEE) ao OF-NB indicando a necessidade de criação de um Radio Bearer apropriado.

(b) O OF-NB envia o correspondente RRC (Radio Resource Control ) connection reconfi- guration ao UE (procedimento padrão utilizando a interface E-UTRAN-Uu) indicando que deve ser criado um Radio Bearer com QoS. Esta mensagem tem a informação de requerimentos de QoS associada e tem os filtros TFT (Traffic Flow Template) a ser aplicados no UE. Estes filtros incorporam as regras para classificar o tráfego no sentido uplink e para encaminhar ele por um novo Radio Bearer com QoS.

(c) O UE responde ao OF-NB com uma mensagem padrão RRC connection reconfiguration complete.

(d) O OF-NB responde ao MME como uma mensagem padrão bearer setup response, com- pletando a etapa de criação do Radio Bearer. No final de este passo o tráfego continua sendo encaminhado utilizando o OF-Bearer por default.

6. Como é descrito a seguir, o Radio Bearer com QoS e o OF-Bearer com QoS são ligados para criar um EPS-Bearer com QoS..

(a) O Controlador define a entrada de fluxo necessária no sentido downlink (a configurar no OF-NB) para ligar o tráfego que vem desde o OF=Bearer com QoS com o Radio Bearer com QoS agora criado. Neste passo fica definido o rótulo MPLS interno, o que identifica o UE/Radio Bearer.

(b) O Controlador define a entrada de fluxo no sentido downlink que deve ser aplicado no OF-GW para encaminhar o tráfego do serviço com QoS através do OF-Bearer com QoS (com destino o UE). As entradas de fluxo são similares às entradas de fluxo para o serviço específicas presentes no OF-NB (ver Figura 4.4). Adicionalmente os critérios de coincidência são baseados nas características do serviço e o endereço IP destino do UE, e a entrada de fluxo colocada no OF-GW deve adicionar os dois rótulos MPLS apropriados. Em este passo, o tráfego no sentido downlik pode já ser encaminhado utilizando o novo EPS-Bearer com QoS.

(c) Se não foram previamente configuradas, o Controlador cria as entradas de fluxo es- pecíficas (no OF-GW) para encaminhar o tráfego para o serviço com QoS no sentido uplink.

(d) Finalmente, como pode ser observado nas Figuras 4.4 e 4.6, o Controlador cria as entradas de fluxo para o serviço específicas no OF-NB, de forma de ligar o tráfego que usa o Radio Bearer com QoS com o OF-Bearer com QoS. Esta entrada de fluxo tem seu critério de coincidência baseado nas caraterísticas do serviço e do endereço IP origem. Em este passo o tráfego nos sentidos uplink e downlink já podem ser encaminhados, devido a que o EPS-Bearer com QoS fica estabelecido nas duas direções.

As entradas de fluxo são criadas com uma prioridade OpenFlow adequada, a qual determina a ordem em que elas são processadas. Particularmente, as entradas de fluxo para serviços específicas sempre têm maior prioridade que as entradas de fluxo por default para o UE. Por tanto, se uma entrada de fluxo para o serviço específica existe, o tráfego será processado utilizando esta entrada (ver Figura 4.6).

É importante notar que os OF-GW são switches OpenFlow padrão situados na borda da rede móvel ou conectados aos servidores de aplicação. A posição na rede onde eles são colocados faz que eles sejam apropriados para terminação de OF-Bearer por default, e em vários casos para a terminação de OF-Bearers com QoS. Os OF-Bearers com QoS podem ser criados diretamente entre qualquer par de switches OpenFlow, sendo um exemplo de este conceito o que mostra um OF-Bearer criado diretamente entre dois OF-NB (representado na Figura 5.10).

4.3.5 Considerações adicionais

Devido a que o tráfego pode ser encaminhado diretamente entre dois OF-NB sem requerer o passo por um OF-GW, os contadores de tráfego e de tempo de duração de fluxos devem ser movimentados à borda da rede de acesso móvel. Particularmente para isto podem ser utilizados os contadores das entradas de fluxo para serviço específicas e os contadores das entradas de fluxo por default para os EU ver Figura 4.4. Se durante a criação de um EPS-Bearer com QoS, a consulta a uma base de dados (como a OCS) informa que o EPS-Bearer tem que ser criado com x minutos de crédito, a entrada de fluxo para o serviço específica deve ser criada com um idle-timeout de x minutos indicados. Por outra parte, se o credito é relacionado a uma quantidade de tráfego, a entrada de fluxo para o serviço especifica deve ser examinada periódicamente até que o contador de tráfego de esse fluxo atinga o limite estabelecido.

Durante a operação normal, o tráfego sem requerimentos de QoS é encaminhado utilizando o caminho por default previamente configurado, e o Controlador só interatúa se o tráfico tem reque- rimentos de QoS ou no processo de attachment, o que reduz o número das mensagens OpenFlow que o Controlador deve processar (diminuindo a carga no Controlador).

Adicionalmente, como a arquitetura proposta sempre encaminha os pacotes imediatamente uti- lizando o OF-Bearer por default, esta arquitetura tem menos impacto durante tempos de resposta elevados do Controlador, dado que o tráfego continua sendo encaminhado utilizando o OF-Bearer por default. Este comportamento incrementa a roubustez da solução se esta é comparada com implementações que utilizam SDN de forma tradicional nas que os pacotes pertencentes ao novo fluxo com QoS devem aguardar a resposta do Controlador para ser encaminhados.

É importante notar que a lógica de detecção de tráfego proposta está composta por dois estagios principais, um implementado de forma distribuída nos OF-NB utilizando a tabela de deteção de tráfego, e o segundo estagio implementado nos SDD utilizando software dedicado para personalizar as caraterísticas de QoS que devem ser detetadas. O primeiro estagio é limitado pelas combinação de critérios de coincidência possíveis por o OpenFlow, e a segundo é programável e ilimitado (portanto a proposta combinada permite critérios de detecção ilimitados). Como um exemplo prático, pode ser considerado un caso onde debe ser identificado um conteúdo especifico de camada de aplicação quando os pacotes são encaminhados a um servidor de aplicaçao específico. Em este caso, a tabela de detecção de tráfego no OF-NB é responsável por encontrar coincidência quando o pacote é encaminhado ao servidor de aplicação a uma porta TCP/UDP específica, e é responsavel por encaminhar esse tráfego detectado a um SDD apropriado. Uma vez que o pacote é recebido no SDD, este realiza uma inspeção no nível de aplicação aprofundada para encontrar os requerimentos. Por outra parte, para reduzir o processamento nos elementos SDD, estos podem ser implemen- tados de forma distribuída dentro do domínio da rede móvel. De esta forma, os OF-NB podem ser divididos em grupos onde cada grupo é atendido por um SDD que dependerá da locação geográfica. Outra alternativa é criar SDDs específicos para analisar diferentes tipos de tráfego. Em este último caso são os OF-NB os responsáveis pela classificação do tráfego com requerimentos de QoS e seu encaminhamento ao SDD correspondente.

Finalmente, para incrementar a robustez da solução, as funções do Controlador podem ser divididas e colocadas em três Controladores diferentes trabalhando juntos de forma complementaria [91]. Uma possível separação é utilizar um Controlador para a configuração proactiva dos fluxo, sendo este responsável pela criação dos OF-Bearer por default, pelas tabelas de deteção de tráfego, e pelas regras de encaminhamento gerais. Um segundo Controlador pode ser responsável pelo processo de attachment, sendo o encarregado de criar o EPS-Bearer por default e pela ligação de um UE com a tabela de detecção de tráfego correspondente. Finalmente, um terceiro Controlador pode ser responsável pela criação de EPS-Bearers com QoS específicos.