QoD - Quality on Demand

Prefácio

O Desafio da Rede

A proliferação de dispositivos conectados transformou nossas residências em ecossistemas digitais complexos. De Smart TVs e computadores a uma vasta gama de aparelhos de Internet das Coisas (IoT) — como assistentes de voz, câmeras de segurança e eletrodomésticos inteligentes — a quantidade de tráfego em redes domésticas cresceu exponencialmente. O grande desafio é que, em uma rede tradicional, todo esse tráfego é tratado de forma genérica, sob um modelo de "melhor esforço". Isso cria um verdadeiro "congestionamento digital", onde uma aplicação crítica e sensível ao tempo, como uma videoconferência de trabalho ou uma partida de jogo online, precisa competir pelos mesmos recursos que uma atualização de software em segundo plano ou o upload de um vídeo de uma câmera de segurança. O resultado é a degradação da experiência justamente quando mais precisamos de uma conexão estável e com baixa latência. Diante desse cenário, torna-se imprescindível que novas tecnologias superem essa abordagem de "tamanho único". É preciso criar mecanismos inteligentes que permitam priorizar o tráfego de pacotes de internet de forma dinâmica, garantindo que as aplicações mais importantes recebam o tratamento preferencial que necessitam, precisamente quando necessitam. É exatamente nesse ponto que a API Quality on Demand (QoD) se apresenta como uma solução inovadora.

A Abordagem Tradicional: Modelo Melhor Esforço

A API Quality on Demand trabalha justamente nesse tópico, buscando criar mecanismos para que um determinado dispositivo em uma casa tenha maior prioridade de pacotes de dados. Para explicarmos esse conceito temos que primeiramente entender como a operadora de internet distribui esse pacotes de dados. Tradicionalmente, uma operadora gerencia sua rede de forma genérica. Isso significa que ela opera sob um modelo conhecido como "melhor esforço" (Best-Effort). Nesse modelo, a rede tenta entregar todos os pacotes de dados da melhor maneira possível, mas sem fazer distinção entre eles. Imagine uma grande avenida com tráfego intenso: carros de passeio, ônibus, caminhões de carga e ambulâncias, todos dividindo as mesmas pistas e enfrentando o mesmo congestionamento. Na abordagem tradicional, o pacote de dados de um jogo online (que precisa de agilidade, como uma ambulância) é tratado com a mesma prioridade que o pacote de um e-mail ou de uma atualização de software em segundo plano (que não são urgentes, como um caminhão de carga). O resultado é que, em momentos de muito tráfego na rede, todos os serviços podem sofrer com lentidão e instabilidade, pois não há um mecanismo para priorizar as aplicações que são mais sensíveis à latência.

QoD: Uma Solução

A API Quality on Demand (QoD) muda esse cenário ao introduzir um mecanismo de priorização de tráfego dinâmico e programático. Em vez de tratar todos os pacotes igualmente, a operadora pode dar tratamento preferencial aos pacotes de uma aplicação específica que solicitou essa prioridade. O processo funciona em algumas etapas:

• A Requisição via API: Uma aplicação autorizada (como um app de videoconferência ou um jogo) envia uma solicitação para a API QoD da operadora. Essa solicitação informa para qual usuário/dispositivo a melhoria é necessária e qual o nível de qualidade desejado, geralmente através de um perfil como LOW_LATENCY (baixa latência) ou HIGH_BANDWIDTH (alta largura de banda).
• Identificação e Marcação dos Pacotes: Uma vez que a operadora aprova a solicitação, seus sistemas de rede passam a identificar todos os pacotes de dados que vêm daquela aplicação e daquele usuário. Esses pacotes são, então, "marcados" internamente com uma prioridade mais alta.
• Tratamento Prioritário na Fila do Roteador: Quando os pacotes chegam a um equipamento de rede, como um roteador ou uma antena 5G, há uma fila de pacotes esperando para serem processados e enviados. Os pacotes que foram marcados com alta prioridade não vão para o fim da fila comum. Em vez disso, eles são colocados em uma "fila expressa" e são atendidos primeiro, passando na frente dos outros pacotes de menor prioridade.
• Encerramento da Sessão: A sessão de QoD tem uma duração definida na requisição inicial. Quando esse tempo acaba ou a aplicação informa que não precisa mais da prioridade, a operadora remove as regras de tratamento especial, e os pacotes daquele usuário voltam a ser tratados de forma genérica, como todos os outros.

Em resumo, a QoD permite que uma aplicação "avise" a rede que seu tráfego é importante, garantindo que ele não fique preso no congestionamento e chegue ao seu destino com a estabilidade e a velocidade necessárias.

Tecnicidades da API

A interação de uma aplicação com a API Quality on Demand não se resume a uma única chamada, mas sim a um ciclo de vida completo que garante o uso eficiente e seguro dos recursos da rede. Esse ciclo é composto por quatro etapas fundamentais.

Autenticação e Autorização

Antes de qualquer solicitação de qualidade de rede, a aplicação precisa provar sua identidade e obter autorização da operadora. Esse processo de segurança garante que apenas aplicações legítimas e autorizadas possam solicitar alterações na rede. Os métodos mais comuns para isso são o uso de Chaves de API (API Keys) ou, preferencialmente, o protocolo de autorização OAuth 2.0, que permite um acesso delegado e seguro sem expor as credenciais do usuário.

Criação da Sessão (A Requisição POST)

Uma vez autenticada, a aplicação pode solicitar o início de uma sessão de qualidade de rede. Isso é feito através de uma requisição POST para o endpoint da API. No corpo (body) dessa requisição, a aplicação envia os parâmetros essenciais que definem a sessão:

• Identificador do Usuário/Dispositivo (Device): Informa para qual conexão a melhoria deve ser aplicada (ex: número de telefone ou endereço IP).

<syntaxhighlight lang="json">

 "device": { 
     "phoneNumber": "+123456789",
     "networkAccessIdentifier": "123456789@domain.com",
     "ipv4Address": { 
        "publicAddress": "203.0.113.0",
        "publicPort": 59765
     },
     "ipv6Address": "2001:db8:85a3:8d3:1319:8a2e:370:7344"
 }

</syntaxhighlight>

• Perfil de Qualidade (QoS Profile): Especifica o tipo de melhoria necessária, como LOW_LATENCY_HIGH_BANDWIDTH (ideal para videoconferências) ou GAMING.

<syntaxhighlight lang="json">

 "qosProfile": "voice"

</syntaxhighlight>

• Duração da Sessão: Define por quanto tempo a sessão de qualidade ficará ativa, em segundos.

<syntaxhighlight lang="json">

 "duration": 3600

</syntaxhighlight>

• URL de Notificação (Webhook): Um endereço fornecido pela aplicação para receber atualizações assíncronas sobre o status da sessão, como "sessão ativada" ou "sessão expirada".

<syntaxhighlight lang="json">

 "sink": "https://endpoint.example.com/sink", 
 "sinkCredential": {    
     "credentialType": "PLAIN" 
 },

</syntaxhighlight>
Se a requisição for bem-sucedida, a API retorna uma resposta indicando que a sessão foi aceita e fornece um ID de Sessão (session_id), que será usado como referência nas etapas seguintes.
<syntaxhighlight lang="json">

 "sessionId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",  
 "duration": 3600,  
 "startedAt": "2024-06-01T12:00:00Z",
 "expiresAt": "2024-06-01T13:00:00Z",
 "qosStatus": "REQUESTED",
 "statusInfo": "DURATION_EXPIRED"

</syntaxhighlight>

Monitoramento e Gerenciamento (A Requisição GET)

Com a sessão ativa, a aplicação pode usar o session_id para fazer uma requisição GET e consultar o status atual da qualidade de rede. Além disso, caso uma URL de notificação tenha sido informada, a operadora pode enviar ativamente mensagens sobre eventos importantes, como a expiração iminente da sessão, sem que a aplicação precise perguntar.

<syntaxhighlight lang="json">

 "duration": 3600,
 "device": {
   "ipv4Address": {
     "publicAddress": "203.0.113.0",
     "publicPort": 59765
   }
 },
 "applicationServer": {
   "ipv4Address": "198.51.100.0/24"
 },
 "qosProfile": "QOS_L",
 "sink": "https://application-server.com/notifications",
 "sessionId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
 "startedAt": "2024-06-01T12:00:00Z",
 "expiresAt": "2024-06-01T13:00:00Z",
 "qosStatus": "AVAILABLE"

} </syntaxhighlight>

Encerramento da Sessão (A Requisição DELETE)

É fundamental que a aplicação encerre a sessão QoD assim que ela não for mais necessária, a fim de liberar os recursos da rede para outros usos. Isso é feito de forma explícita através de uma requisição DELETE, utilizando o session_id da sessão que se deseja finalizar.

Arquitetura da API QoD (Padrão CAMARA)

Para garantir que os desenvolvedores possam criar aplicações que funcionem de maneira consistente entre diferentes operadoras, o projeto CAMARA lidera a padronização da API QoD. A arquitetura dessa API padronizada é composta por três componentes principais que trabalham em conjunto:

• Quality-on-Demand: Este é o componente central da API, responsável pelo gerenciamento dinâmico das sessões de QoS. É através dele que as aplicações podem criar, consultar e deletar as sessões de qualidade sob demanda.
• QoS-profiles: Este componente funciona como um mecanismo de descoberta. Ele possui uma API própria que permite à aplicação consultar quais perfis de qualidade (como latência estável, throughput priorizado, etc.) estão disponíveis na rede da operadora naquele momento.
• QoD-provisioning: Oferece uma capacidade mais avançada de provisionamento persistente. Com esta API, é possível configurar uma qualidade de serviço que seja aplicada automaticamente sempre que um dispositivo específico se conectar à rede, sem a necessidade de uma nova requisição a cada vez.