Você está na página 1de 23

Inteligência de borda em movimento: migração de serviço de inferência de DNN

dinâmico com reconhecimento de mobilidade com tempo de inatividade na


computação de borda móvel

Resumo—Edge intelligence (EI) torna-se uma tendência para empurrar as fronteiras do


aprendizado profundo para a borda da rede, para que os aplicativos de redes neurais
profundas (DNNs) possam ser bem aproveitados em dispositivos móveis com recursos
limitados com os benefícios da computação de borda. Devido à alta mobilidade do
usuário entre servidores de borda dispersos em muitos cenários, como internet de
aplicativos veiculares, a migração dinâmica de serviços é desejada para manter uma
qualidade de serviço (QoS) confiável e eficiente. No entanto, o inevitável tempo de
inatividade de serviço incorrido pela migração de serviço degradaria amplamente o
desempenho em tempo real dos serviços de inferência de DNN sensíveis a atrasos.
Felizmente, com base nas características dos serviços DNN baseados em contêiner, a
seleção de ponto de saída e o recurso de compartilhamento de camada da técnica de
contêiner podem aliviar essa degradação de desempenho. Assim, consideramos um
gerenciamento centrado no usuário para migração de serviço de inferência DNN e
seleção de ponto de saída, visando maximizar a utilidade geral do usuário (por
exemplo, precisão de inferência do modelo DNN) com vários tempos de inatividade do
serviço. Primeiro, aproveitamos a programação dinâmica para propor uma migração
offline ideal e algoritmo de estratégia de seleção de ponto de saída (OMEPS) quando
informações futuras completas sobre comportamentos do usuário estiverem
disponíveis. Atendendo a um domínio de aplicação mais prático sem informações
futuras completas, incorporamos o algoritmo OMEPS em uma estrutura de controle
preditivo de modelo (MPC) e, em seguida, construímos uma migração de serviço com
reconhecimento de mobilidade e um algoritmo de seleção de ponto de saída DNN
(MOMEPS), que melhora a longa utilidade de serviço de curto prazo dentro de
informações futuras preditivas limitadas. No entanto, as sobrecargas de computação
pesadas do algoritmo MOMEPS impõem cargas aos dispositivos móveis, portanto,
defendemos ainda um algoritmo econômico, chamado smart-MOMEPS, que introduz
um julgamento de migração inteligente baseado em redes neurais para controlar a
implementação do algoritmo (MOMEPS). estimando sabiamente se o serviço DNN deve
ser migrado ou não. Resultados extensivos de simulação orientada por rastreamento
demonstram o desempenho superior do nosso algoritmo smart-MOMEPS para
alcançar melhorias significativas de utilidade geral com baixas despesas gerais de
computação em comparação com outros algoritmos online.

I. INTRODUÇÃO

Com o desenvolvimento explosivo de dispositivos da Internet dos Coisas (IOT),


um número crescente de redes neurais profundas (DNNS) -Drives IOT aplicativos,
incluindo reconhecimento facial, condução autônoma e realidade aumentada estão
surgindo. Geralmente, essas aplicações exigem recursos de computação massivos para
garantir baixa latência e alta precisão de inferência, que muitas vezes são indisponíveis
devido à capacidade de computação e energia restritas de dispositivos móveis. Por
exemplo, aplicativos analíticos de vídeo em tempo real exigem processamento de
dezenas de quadros por segundo por modelos DNN intensivos em computação (por
exemplo, YOLO, Rescnet), inadequados para dispositivos móveis de recursos e recursos
[1]. Para resolver este desafio, a computação móvel (MEC) é proposta para impulsionar
esses serviços a partir dos dispositivos IOT locais para as arestas de rede, que são
servidores de proximidade com dispositivos móveis (por exemplo, em estações base
ou hotpots WiFi). Os dispositivos móveis podem colaborar com bordas de rede para
obter uma maior qualidade de serviço e uma baixa latência via descarregamento de
tarefas [2].
No entanto, manter um desempenho de serviço confiável e eficiente de
aplicativos DNN na borda da rede não é trivial devido à mobilidade dos usuários. Para
reduzir a latência da rede, os serviços DNN são geralmente implantados em um
servidor de borda próximo, onde os usuários podem acessar seus serviços por meio de
comunicações sem fio para uma estação base local (BS), como hotspots WiFi. Quando
um usuário se afasta do escopo de serviço do servidor de borda próximo, a conexão
mudará para um novo BS para acesso remoto ao serviço, e a QoS inevitavelmente
degradará devido ao maior atraso de transmissão causado pelo aumento da distância
da rede. Embora métodos como a réplica de serviço [3] possam aliviar a degradação do
desempenho do serviço causada pela mobilidade do usuário por meio de serviços de
backup em diferentes servidores de borda, isso traz problemas como privacidade do
usuário e redundância de armazenamento. Portanto, focamos em outra abordagem
amplamente adotada, migração de serviço dinâmica [4]–[7], para resolver esse
problema.
Projetar um esquema de migração de serviço dinâmico adequado enfrenta
alguns desafios. Especificamente, a migração frequente do serviço causaria um
extenso tempo de inatividade do serviço [8] e, portanto, é inaceitável para serviços
DNN sensíveis à latência, especialmente na internet de aplicativos veiculares onde os
usuários têm alta mobilidade. Além disso, permitir cegamente que o serviço
acompanhe a mobilidade do usuário (como loops de pingue-pongue, ou seja, o usuário
vai e volta entre duas coberturas de BSs) incorre em migrações desnecessárias e
pesados overheads. Portanto, é fundamental migrar dinamicamente um serviço DNN
de forma moderada para acompanhar a mobilidade do usuário.
O trabalho existente na migração de serviços de borda considerou o contêiner
como uma maneira promissora de prestação de serviços [9]–[12]. Comparado à
máquina virtual (VM) tradicional, o contêiner é uma técnica de virtualização mais leve
e ocupa menos espaço de armazenamento do que as VMs. No entanto, como os
aplicativos DNN geralmente são construídos em estruturas de aprendizado de
máquina, como TensorFlow e PyTorch, os tamanhos de imagem de contêiner desses
aplicativos podem chegar a centenas ou milhares de megabytes. O tempo de
inatividade do serviço causado pela migração vem principalmente da busca da imagem
do registro remoto, que é relativamente longo para aplicativos sensíveis à latência.
Portanto, a migração frequente levaria a uma sobrecarga de tráfego significativa e uma
experiência de usuário terrível. Em nosso trabalho, aproveitamos o recurso de
compartilhamento de camada do contêiner para reduzir o tempo de inatividade do
serviço. A imagem de contêiner empacota os arquivos necessários, como ferramentas
de tempo de execução, bibliotecas do sistema e arquivos de dados em diferentes
camadas independentes, que podem ser compartilhadas por diferentes imagens [13].
Por exemplo, o tamanho oficial da imagem do contêiner do TensorFlow no dockerhub
é de 400 MB [14] e custará 80 segundos para migrar em uma rede de longa distância
(WAN) de 5 Mbps. Quando um serviço DNN baseado em TensorFlow é migrado para
um nó de borda em que a imagem do TensorFlow já existe, o serviço pode
compartilhar essa imagem de base no nó de borda de destino sem baixar a imagem de
serviço completa. Nesse caso, apenas uma parte dos dados do serviço, como arquivos
dependentes do estado, dados privados do usuário ou parâmetros de modelo
personalizados, precisam ser migrados e, portanto, o tempo de inatividade do serviço
pode ser reduzido significativamente.
Neste trabalho, focamos no problema de migração de serviço dinâmico em um
cenário MEC distribuído e variante no tempo para otimizar a utilidade do usuário de
longo prazo, por exemplo, a precisão da inferência do modelo DNN. Assumimos que
uma solicitação trará utilidade total se for concluída antes do prazo. Caso contrário, a
utilidade será zero. Como mencionado acima, a migração frequente causará inúmeras
interrupções de serviço e, durante a migração, todas as solicitações perderão o prazo e
não trarão utilidade. Como o aumento da distância da rede é a principal causa da
migração, para reduzir a frequência de migração, introduzimos um mecanismo de
saída antecipada [15] para adquirir menor latência de inferência para neutralizar o
aumento do atraso de transmissão. Para combater a interrupção do serviço,
poderíamos executar o serviço DNN em um dispositivo móvel com um ponto de saída
adequado durante a migração. No entanto, sair da inferência em uma camada DNN
inicial resulta em perda de precisão. À medida que a distância da rede continua a
aumentar, os benefícios da saída antecipada diminuirão gradualmente, pois a
inferência precisa sair no ponto de saída anterior.
Conforme ilustrado na Fig. 1, um veículo móvel percorre três regiões, cada uma
contendo uma BS dotada de um servidor de borda. Para melhor QoS, o veículo precisa
decidir constantemente se migrar o serviço ou escolher pontos de saída antecipados
durante a condução. Quando o veículo está indo e voltando entre as regiões 2 e 3, é
mais sensato sair da inferência DNN mais cedo do que manter o serviço seguindo a
mobilidade do veículo considerando o tempo de inatividade do serviço. Além da
trajetória do usuário, a frequência de requisições de serviço é outro fator importante
nas decisões de migração. O veículo gerará uma maior frequência de solicitações de
serviço na região 2 devido às condições mais complicadas da estrada. Nesse caso, a
migração antecipada do serviço para o BS2 pode gerar maior utilidade. Portanto,
informações futuras das atividades do usuário podem nos ajudar a tomar uma decisão
melhor sobre a migração do serviço e a seleção do ponto de saída. Felizmente, uma
variedade de estudos tem sido sobre a previsão do comportamento do usuário, que
pode ser utilizada para prever informações futuras para a tomada de decisões.
Neste artigo, consideramos um sistema com intervalos de tempo e formulamos
o problema de otimização de longo prazo. Propomos um algoritmo online baseado em
Model Predictive Control (MPC) [16] estrutura para fazer a migração de serviço DNN
adaptável e decisões de seleção de ponto de saída. Em seguida, desenvolvemos uma
abordagem de julgamento de migração baseada em Redes Neurais para fazer uma
política eficiente para maior utilidade do usuário e menor sobrecarga de computação.
As principais contribuições deste artigo estão listadas a seguir:
1) Propomos uma estrutura geral de migração de serviço dinâmico com
reconhecimento de mobilidade e seleção de ponto de saída do modelo DNN no
cenário MEC. Essa estrutura permite um serviço DNN eficiente que maximiza a
utilidade do usuário a longo prazo.
2) Formulamos um problema de maximização da utilidade do usuário de longo
prazo considerando o tempo de inatividade no MEC. Resolvemos o problema em um
ambiente offline onde as informações das atividades do usuário são conhecidas,
através de um algoritmo de programação dinâmica em tempo polinomial. Em uma
configuração online em que as informações são desconhecidas, aproveitamos uma
estrutura MPC para construir uma migração de serviço proativa online e um algoritmo
de seleção de ponto de saída DNN chamado MOMEPS para resolver esse problema de
utilidade de longo prazo. Além disso, para lidar com a pesada sobrecarga de
computação do MPC, desenvolvemos uma abordagem de julgamento de migração
inteligente baseada em Rede Neural chamada smart-MOMEPS, que navega
eficientemente no trade-off de desempenho e sobrecarga de computação.
3) Conduzimos experimentos extensivos para avaliar nosso algoritmo online
com base em rastreamentos de dados do mundo real. Demonstramos a eficácia de
nossa abordagem por meio de comparações com algoritmos de benchmark. Os
resultados da simulação orientada por rastreamento mostram que nossa abordagem
pode melhorar significativamente a utilidade geral e reduzir a sobrecarga de
computação.
O restante deste trabalho está organizado da seguinte forma. A Seção II analisa
brevemente os trabalhos relacionados à migração de serviços. Na seção III,
descrevemos o modelo do sistema e a formulação do problema. Na seção IV,
propomos uma migração de serviço offline ideal e algoritmo de seleção de ponto de
saída para maximizar a utilidade geral do usuário. Explicamos o algoritmo online
baseado em MPC e, além disso, propomos um algoritmo mais leve na Seção V. Na
Seção VI, avaliamos nosso algoritmo online para demonstrar a eficácia. Por fim,
concluímos este artigo na Seção VII.

II. TRABALHO RELATADO

Com o rápido desenvolvimento do MEC, que permite baixo atraso de


transmissão e velocidade de resposta rápida, desafios significativos estão surgindo
gradativamente. As características inerentes aos serviços do MEC que estão
distribuídos em diferentes regiões geográficas e a mobilidade dos usuários trazem
dificuldades dominantes. Assim, a solução de migração de serviços de borda, que pode
ajudar a manter a QoS em um ambiente MEC dinâmico, tornou-se um dos tópicos de
pesquisa significativos.
Migração de serviços sem previsão de futuro: Muita literatura tem focado na
migração de serviços no MEC para lidar com o principal desafio da dinâmica do
usuário. Um ramo de tais trabalhos acomoda mobilidades arbitrárias de usuários sem
previsão. Zhao et ai. abordou a estratégia de migração de máquinas virtuais com base
na tomada de decisão de múltiplos atributos, visando minimizar um custo abrangente,
dada a situação atual da rede e a localização do usuário [17]. Em [18], Ouyang et al.
pesquisou um mecanismo de posicionamento de serviço adaptativo no MEC e o
formulou como um problema contextual de aprendizado de bandidos multi-armados
para otimizar a latência percebida do usuário e o custo de migração do serviço. Além
disso, muitos estudos utilizaram métodos baseados em processos de decisão de
Markov (MDP) para resolver o posicionamento dinâmico de serviços sob a suposição
de que a mobilidade do usuário segue ou pode ser aproximada por um modelo de
mobilidade em cadeia de Markov. Especificamente, [19] trabalhou no balanceamento
de um trade-off entre custo e qualidade de migração, modelando o procedimento de
migração de serviço usando MDP. Em [20], a política ótima de migração de serviços de
borda formulada como MDP provou ser uma política de limite quando a mobilidade do
usuário segue um modo de mobilidade de passeio aleatório assimétrico
unidimensional (1-D).
Migração de Serviço com Previsão de Futuro: Assim, a previsão de atividades
do usuário no cenário de migração de serviço também é amplamente estudada para
melhorar a QoS do usuário. Ma et ai. incorporou o método de otimização Lyapunov em
duas escalas de tempo e a previsão de mobilidade limitada do usuário para encontrar
as decisões ideais de colocação de serviço [21]. Zhang et ai. em [22] superou os
desafios de um problema subjacente de posicionamento do módulo de renderização
dinâmica, aproveitando o controle preditivo do modelo (MPC) para lidar com a
previsão da trajetória do usuário na borda. Ambos [23] e [24] tiraram vantagens do
MPC para trabalhar o posicionamento dinâmico de funções de rede virtual (VNF) e
alcançaram um escalonamento eficiente de recursos. No entanto, o downtime do
serviço, que é generalizado na borda e tem grande influência nas políticas de
migração, não foi considerado nesses trabalhos. Neste artigo, levamos em
consideração o tempo de inatividade do serviço e propomos um algoritmo baseado em
MPC, que integra o julgamento de migração baseado em NN para mitigar o alto custo
de computação do MPC.
Migração de serviço baseada em contêiner: Além disso, a migração de serviço
baseada em contêiner é considerada especificamente em nosso trabalho, que é mais
leve e economiza espaço de armazenamento em comparação com a VM tradicional.
Para reduzir a sobrecarga de migração, [11] projetou um sistema eficiente de migração
ao vivo que garante a integridade dos componentes, aproveitando a estrutura em
camadas do contêiner. Em [9], os autores propuseram uma arquitetura de plataforma
de computação de borda que suporta a migração perfeita de contêineres do docker de
serviços de descarregamento, ao mesmo tempo em que mantém o usuário móvel em
movimento com seu servidor de borda mais próximo. [12] apresentou o Voyager, um
serviço de migração de contêiner ao vivo just-in-time que combina migração de estado
de memória de serviço com migração de sistema de arquivos local para minimizar o
tempo de inatividade do serviço. No entanto, esses trabalhos se concentram
principalmente em aproveitar os recursos do contêiner para reduzir o tempo de
inatividade do serviço. Enquanto nosso trabalho incorpora o impacto de vários tempos
de inatividade de serviço devido ao recurso de compartilhamento de camada do
contêiner na migração e melhora a utilidade do usuário a longo prazo, otimizando as
decisões de migração.
Migração do serviço de inferência DNN: como o DNN tem sido amplamente
aplicado para aplicativos inteligentes na borda, o tempo de inatividade contínuo do
serviço se torna extremamente inacessível para serviços de inferência DNN sensíveis à
latência. Para descobrir a dificuldade acima, [25] desenvolveu um algoritmo de
descarregamento de partição DNN incluído na mobilidade para se adaptar ao
movimento do usuário. Wang et ai. adotou a saída de inferência DNN em camadas
anteriores durante a interrupção do serviço para encurtar o atraso de inferência,
sacrificando um nível aceitável de precisão [26]. Diferente de [25] e [26], resolvemos a
interrupção do serviço de inferência de DNN de forma colaborativa via mecanismo de
saída antecipada e migração dinâmica de serviço para manter a QoS do usuário.

III. MODELO DO SISTEMA E FORMULAÇÃO DO PROBLEMA

Nesta seção, apresentamos o modelo do sistema e a formulação do problema


para migração de serviço DNN com tempo de inatividade e seleção de ponto de saída
em computação de borda móvel.

A. Visão geral da migração dinâmica para serviço DNN

A Fig. 1 ilustra um cenário típico de inteligência de borda, ou seja, detecção de


objeto de um dispositivo assistida por borda para análise de streaming de vídeo. Mais
explicitamente, um veículo inteligente viajando em uma cidade urbana usa o serviço
DNN para processar as informações do entorno coletadas por sua câmera. Com base
nas tecnologias de virtualização existentes, o perfil de serviço e o ambiente para o
modelo DNN de várias saídas (por exemplo, AlexNet) podem ser executados em um
contêiner dedicado. Assim, o fluxo de vídeo em tempo real pode ser processado
colaborativamente no veículo local e no servidor de borda próximo por meio de
descarregamento de tarefas [1]. Para garantir uma QoS confiável para um veículo em
movimento, a migração dinâmica do serviço DNN e a seleção do ponto de saída são
adotadas para acomodar a alta dinâmica dentro do tempo de conclusão necessário.
Com a arquitetura assistida por borda apresentada, consideramos um conjunto
de estações base (BSs): = 1, ..., B , cada uma equipada com um servidor de borda para
fornecer serviço DNN ao usuário. E o usuário acessa o serviço pela estação base mais
próxima. Em consonância com o trabalho recente [27] sobre computação de borda,
adotamos um modelo de intervalo de tempo discreto para caracterizar
completamente a dinâmica do sistema (por exemplo, mobilidade do usuário e
frequência de solicitação). Cada intervalo de tempo = 0, ..., T corresponde à escala de
tempo em que as decisões de migração de serviço e seleção de ponto de saída são
atualizadas. Para facilitar a exposição, a Tabela I resume as notações introduzidas.
B. Migração de serviço dinâmico

Devido ao comportamento incerto do usuário, como mobilidade do usuário e


frequência de requisições, o usuário precisa migrar dinamicamente o serviço entre
essas BSs para adquirir maior QoS. Aqui usamos xi(t) 0, 1 para indicar a tomada de
decisão para migração de serviço no intervalo de tempo t. xi(t) = 1 (i ) indica que o
usuário decide descarregar a computação para a i-ésima BS em t. Observe que o
usuário só pode descarregar para uma BS em cada intervalo de tempo. Assim, tal
restrição de tomada de decisão de migração de serviço pode ser expressa como:

Considerando a natureza sensível ao atraso dos serviços DNN, capturamos


grande tempo de inatividade do serviço, que é causado pela busca da imagem do
contêiner do registro de imagem remoto (durante o procedimento de migração), ao
otimizar o desempenho do serviço de longo prazo. Uma vez que o usuário determina
uma migração, o serviço DNN só pode ser executado localmente no dispositivo do
usuário e as sucessivas decisões de migração devem ser consistentes com a original até
que todo o procedimento de migração termine. Devido às diferentes camadas de
contêiner implantadas em servidores de borda, diferentes quantidades de dados
devem ser baixadas do registro de imagem central para buscar as camadas de
contêiner necessárias no BS de destino, o que leva a vários tempos de inatividade do
serviço com base na decisão de migração atual. A esse respeito, denotamos o custo de
tempo para buscar a imagem do contêiner em BS i por si e usamos λ(t) para denotar o
tempo de inatividade do serviço no tempo t. Então, as restrições de execução do
serviço DNN devem ser satisfeitas como
onde 1{·} é a função indicadora. A restrição (3) indica o tempo de inatividade
atual do serviço para migrar o serviço para BS i quando x (t) > x (t − 1) (ou seja, x (t) = 1
e x (t − 1) = 0). A restrição (4) denota a execução local durante o procedimento de
migração, ou seja, o usuário não pode tomar decisão de migração de t + 1 para t + λ(t)
1 após decidir migrar para BS i no tempo t, onde o serviço está sendo migrado de t
para t + λ(t) 1.
Para descrever claramente o estado atual do usuário, usamos S(t) para indicar
se o usuário está migrando ou descarregando. S(t) = 1 representa o usuário está
transferindo a computação para BS em t. Assim, S(t) = 0 quando o usuário está
migrando seu serviço (executando requisições localmente). Obviamente, há apenas
um estado para um usuário em um determinado intervalo de tempo. As expressões
estão listadas abaixo:

C. Seleção do Ponto de Saída Antecipada de DNN

Para melhorar o desempenho do serviço durante o procedimento de


descarregamento de tarefas, incorporamos a seleção inicial de pontos do modelo DNN
para acomodar o comportamento dinâmico do usuário e o ambiente de borda. Sem
perda de generalidade, consideramos o modelo DNN com um conjunto de pontos de
saída antecipados, denotados como = (1, ..., M ). A seleção do ponto de saída afetaria
diretamente o desempenho do serviço (ou seja, atraso e precisão). Por exemplo, uma
saída anterior da inferência DNN causa menos atraso de computação com menor
precisão [28]. Portanto, o usuário pode optar por sair da inferência de DNN
antecipadamente no BS para evitar a degradação do desempenho devido ao tempo de
inatividade do serviço. Seja yj(t) denotando se j é o ponto de saída antecipado
selecionado em t. yj(t) = 1 significa que o modelo DNN sairá da inferência no j-ésimo
ponto de saída em t. Assim como a migração de serviço, o usuário só pode tomar a
decisão de seleção do ponto de saída durante o descarregamento. Além disso, apenas
um ponto de saída pode ser selecionado em cada intervalo de tempo. Temos assim as
seguintes restrições:
D. Latência de solicitação do usuário

Assumimos que uma solicitação trará o utilitário completo do usuário se for


concluída antes do prazo. Caso contrário, o utilitário do usuário será zero. Portanto,
para maximizar a utilidade geral do usuário, a latência de cada solicitação deve atender
ao seu prazo [26]. Definimos Tmax como o atraso máximo tolerado de cada solicitação.
A latência de solicitação do usuário difere no estado de descarregamento e no estado
de migração.
Latência de descarregamento: Quando o usuário descarrega sua solicitação
para um servidor de borda, o atraso de solicitação lf (t) é determinado em conjunto
pelo atraso de inferência de DNN e pelo atraso de comunicação. Definimos o atraso
para que o servidor de borda execute a inferência de modelo no j-ésimo ponto de
saída inicial como df . lc(t) denota o atraso de comunicação em t. Aparentemente, lc(t)
inclui o atraso para transmitir a solicitação do dispositivo do usuário para a BS à qual o
usuário está conectado no tempo t, e o atraso de encaminhamento que depende
principalmente da distância de salto ao longo do caminho de comunicação mais curto
entre essas BSs. As restrições de lf(t) podem ser expressas como:

Latência de migração: Durante a migração, a inferência de DNN será


processada no dispositivo local com um ponto de saída inicial fixo γ E M. Portanto, a
latência de solicitação do usuário le(t) é determinada principalmente pelo atraso de
computação. Definimos o atraso de inferência DNN durante a execução no dispositivo
local como de , e suas restrições são mostradas a seguir:

E. Formulação do Problema

Após introduzir as variáveis de decisão do usuário e a latência da requisição,


estamos prontos para apresentar o problema de maximização da utilidade do usuário
em um determinado horizonte de tempo. Aqui definimos a utilidade como a precisão
de inferência do modelo DNN. O utilitário de usuário acumulado contém o utilitário de
migração e descarregamento. Definimos que a utilidade no j-ésimo ponto de saída
antecipada é uj. A taxa de solicitação do usuário no tempo t é rt. Quando a solicitação
está sendo descarregada, a utilidade do usuário Uo(t) no tempo t é a soma da utilidade
de todas as solicitações naquele momento, que pode ser expressa como:
Durante a migração, definimos o utilitário em um ponto de saída fixo γ é uγ, e o
utilitário do usuário de migração Um(t) no tempo t pode ser expresso como:

Formulamos um problema de maximização da utilidade acumulada do usuário


em um determinado horizonte de tempo finito T como segue:

Resolver o problema em (11) tem os dois desafios a seguir. Em primeiro lugar,


como o objetivo é a utilidade acumulativa em um horizonte de tempo, é difícil obter as
informações futuras completas (por exemplo, trajetória do usuário e frequência de
requisições). Em segundo lugar, as decisões do usuário são acopladas em diferentes
intervalos de tempo. Ou seja, a decisão no slot atual afetaria as decisões no futuro.
Para resolver esses desafios, começamos com um caso ideal em que informações
futuras estão disponíveis e desenvolvemos uma solução off-line ideal. Isso ajuda a
fornecer alguns insights para resolver o problema. Em seguida, focamos no caso
desafiador sem informações futuras. Aproveitamos métodos avançados de
aprendizado de máquina para prever informações limitadas e criar um algoritmo
online.

4. SOLUÇÃO DE ALGORITMO DE MIGRAÇÃO DE SERVIÇO OTIMIZADO OFFLINE E


SELEÇÃO DE PONTO DE SAÍDA

Nesta seção, apresentamos a solução ótima offline do problema de migração


de serviço e seleção de ponto de saída DNN por meio de programação dinâmica,
quando as informações futuras completas das atividades do usuário são consideradas
exatamente conhecidas.
Primeiro, mostramos que este problema ótimo offline possui a propriedade de
subestrutura ótima. Definimos (i, q, n) como o estado do usuário, em que i representa
o tempo, q representa a BS que hospeda o serviço do usuário e n representa o ponto
de saída do modelo DNN selecionado. Assim, (i−, q−, n−) é o estado anterior de (i, q, n).
Definimos p e m como a decisão de migração do usuário e a seleção do ponto de saída,
respectivamente. Seja C((i, q), p, m) representar todos os intervalos de tempo para
completar p e m. Pode ser expresso como

Aqui, p = q indica que o usuário decide selecionar novamente o ponto de saída


do modelo no estado atual e custa um intervalo de tempo para concluir. Quando o
usuário opta por migrar o serviço (p q), o tempo de execução da decisão é o downtime
do serviço (sp), e a porção além de T é descartada.
Seja U ((i, q, n), p, m) representar a soma das utilidades durante a conclusão da
decisão pe m. Observe que a inferência DNN será processada no dispositivo local com
um ponto de saída antecipado fixo γ durante o tempo de inatividade do serviço (p q). f
(i, q, n) representa a utilidade acumulada no estado (i, q, n). Então, dadas (i, q, n) e as
decisões do usuário p e m, o estado é transitado para (i+, q+, n+), onde

Uma vez que o problema pode ser considerado como a equação de Bellman,
uma abordagem de programação dinâmica pode ser adotada para derivar uma solução
ótima offline de nosso problema de migração de serviço e seleção de ponto de saída
DNN. Para facilitar a exposição, transformamos o problema de ótimo off-line em um
problema de caminho mais longo construindo um grafo acíclico direcionado (DAG).
Conforme mostrado na Fig. 2, construímos um gráfico G = (V, E) para
representar todas as decisões possíveis de migração de serviço e seleção de ponto de
saída DNN dentro de T intervalos de tempo. Cada vértice apresenta o estado (i, q, n)
que o usuário pode alcançar. Uma vez que a informação futura (trajetória do usuário e
frequência de solicitação) é conhecida, o ponto de saída n pode ser determinado
quando i e q são dados em cada estado. Observe que o vértice de origem S representa
o estado inicial (definimos como (0, 1, n)). Cada estado (exceto o estado inicial) é
transitado do estado anterior executando a decisão correspondente. O vértice de
destino E é um vértice auxiliar para garantir que um único caminho mais longo possa
ser encontrado. Cada peso de aresta no DAG entre dois estados representa a soma dos
utilitários de solicitação das decisões de execução, e as arestas que se conectam a E
têm peso zero. Vale a pena notar que, suponha que a decisão do usuário possa ser
concluída antes de T , podemos traçar uma aresta direcionada entre dois estados. No
entanto, se a decisão for concluída em um momento além de T , por exemplo, quando
um usuário no estado B1 em T4 executa a decisão de transferir para o estado B2.
Desenhamos uma aresta direcionada de B1 em T4 para o vértice auxiliar amarelo
correspondente B2. Assim, o peso da borda representa a soma das utilidades que o
usuário pode obter de T4 até o final. O peso da aresta que liga cada vértice de tempo T
aos vértices auxiliares amarelos é zero. Concluímos agora a construção do DAG.
Podemos derivar a estratégia ótima do usuário encontrando o caminho mais
longo de S a E. Especificamente, dadas todas as informações das atividades do usuário
em T intervalos de tempo, o peso de todas as arestas pode ser calculado. E o peso total
de um caminho do vértice de origem S ao vértice de destino E pode, portanto,
apresentar toda a utilidade ao longo do horizonte de tempo. Conseqüentemente, a
migração de serviço ideal e a estratégia de seleção do ponto de saída do modelo DNN
podem ser encontradas tomando o caminho mais longo de S para E. Conforme
mostrado na Fig. 2, damos o caminho mais longo para T = 5 com 3 BSs. Cada vértice
vermelho representa o estado do usuário no intervalo de tempo correspondente, e o
vértice apontado pela borda preta sólida é o estado do usuário após a decisão.
Obviamente, como esse problema de caminho mais longo possui uma propriedade de
subestrutura ótima, ele pode ser resolvido pela abordagem clássica de programação
dinâmica. O Algoritmo 1 mostra o pseudocódigo do nosso algoritmo de otimização que
utiliza programação dinâmica com memoização para descobrir as estratégias ótimas de
cada intervalo de tempo para um determinado horizonte de tempo finito. No
algoritmo, podemos obter o caminho mais longo (ou seja, a migração de serviço ótima
e a estratégia de seleção do ponto de saída do modelo DNN) para cada estado
resolvendo a equação de Bellman (ou seja, linha 6). Então podemos escolher o
caminho que contém o estado com a maior utilidade acumulada em T como o caminho
mais longo (ou seja, a linha 15), que é a solução ótima para o problema. Para pesquisar
o caminho mais longo, o algoritmo precisa enumerar no máximo B2 estados possíveis
em cada intervalo de tempo. Assim, para os intervalos de tempo T, a complexidade de
tempo do Algoritmo 1 é O(B2T).
V. MIGRAÇÃO DE SERVIÇO ONLINE E ALGORITMO DE SELEÇÃO DE PONTO DE SAÍDA

Até agora apresentamos a solução do problema em (11) no cenário de


informações futuras completas como linha de base. Na prática, é um desafio obter
informações completas. Isso motiva um algoritmo on-line ideal sem informações
completas. Para este fim, nesta seção, combinamos algumas técnicas populares de
aprendizado de máquina (por exemplo, LSTM) para prever informações futuras (por
exemplo, rastreamentos de mobilidade) para melhorar o desempenho do serviço a
longo prazo com tomada de decisão informada. No entanto, a previsão frequente
incorreria em grandes custos de execução (por exemplo, latência de previsão), que não
são acessíveis para o equipamento do usuário com recursos limitados. Para equilibrar
bem o trade-off desempenho-custo, propomos um algoritmo adaptativo proativo,
chamado smart-MOMEPS, para otimizar conjuntamente a migração de serviço e o
ponto de saída antecipado de serviços DNN, que integra migração online baseada em
MPC e estratégia de seleção de ponto de saída (MOMEPS) e julgamento de migração
baseado em NN para obter utilidades médias mais altas a custos baixos.

A. Migração online baseada em MPC e estratégia de seleção de ponto de saída

Uma grande variedade de técnicas de aprendizado de máquina (por exemplo,


[29]– [32]) foi estudada para estimar bem o comportamento do usuário, aproveitando
as informações de dados coletados. Entre eles, a memória de longo prazo (LSTM) [33]
é considerada particularmente eficiente para previsão de séries temporais (atividades
do usuário em nosso problema) devido à sua capacidade de manter uma memória de
entradas anteriores [34]. Além disso, em comparação com outros métodos de
aprendizado de máquina, como DNN, o LSTM possui uma estrutura de rede mais
simples e menos sobrecarga de computação, tornando-o mais adequado para
dispositivos móveis com recursos limitados. Portanto, em nosso trabalho, exploramos
o LSTM para prever informações futuras, incluindo a trajetória do usuário e a demanda
de solicitações. Ao incorporar esses resultados preditivos para auxiliar na otimização
de decisões, podemos nos livrar de extensas migrações desnecessárias causadas pela
mobilidade incerta do usuário (por exemplo, loops de pingue-pongue).
A migração online baseada em MPC e a estratégia de seleção de ponto de saída
funcionam da seguinte forma. Conforme ilustrado na Fig. 3, no início de cada slot, o
dispositivo usaria seu mecanismo de previsão para estimar as informações futuras de
rastreamento de mobilidade e demandas de solicitação dentro de W slots de tempo
antes da tomada de decisão. Aqui, W é na verdade o tamanho da janela de previsão.
Sequencialmente, com base nos resultados preditivos, o dispositivo pode derivar
decisões ideais de migração de serviço e seleção de ponto de saída antecipada durante
a janela de previsão por meio do algoritmo OMEPS.
O mecanismo de previsão no ambiente online dificilmente pode fornecer uma
previsão perfeita. Além disso, à medida que o tamanho da janela W aumenta, o erro
de previsão se acumula, o que eventualmente leva a uma degradação severa do
desempenho. Para aumentar a robustez das decisões informadas, adotamos uma
abordagem padrão baseada em MPC para execução de decisões, ou seja, apenas a
primeira decisão seria implementada em cada janela de previsão. Desta forma, o
impacto negativo dos erros preditivos acumulados pode ser consideravelmente
aliviado, uma vez que as possíveis decisões terríveis na janela de predição
(especialmente os últimos intervalos de tempo) são rejeitadas.
Resumimos a migração online baseada em MPC e a estratégia de seleção de
ponto de saída no Algoritmo 2. Na linha 7, o usuário precisa executar o algoritmo
OMEPS para obter as decisões de migração de serviço e seleção de ponto de saída
antecipada. Assim, para os slots de tempo T, a complexidade de tempo do Algoritmo 2
é O(B2WT).
B. MOMEPS Inteligentes

No entanto, a migração online baseada em MPC e a estratégia de seleção de


ponto de saída (MOMEPS) trazem não apenas melhorias substanciais no desempenho
do serviço, mas também altos custos de operação. Mais explicitamente, a tomada de
decisão de um slot depende de toda uma otimização sobre a janela de previsão, que
contém o custo de execução (ou seja, latência) do mecanismo de previsão e do
algoritmo OMEPS. Tais custos computacionais em MO-MEPS aumentam amplamente a
carga de dispositivos móveis com recursos limitados para otimização de decisões. Para
equilibrar bem o trade-off desempenho-custo no tempo de execução, defendemos um
algoritmo adaptativo proativo, Smart-MOMEPS, para permitir uma otimização de
decisão mais moderada em tempo real.
Projetamos o algoritmo Smart-MOMEPS com base na observação dos
resultados da execução do MOMEPS. Intuitivamente, o MOMEPS evitaria migrações
frequentes de serviço para reduzir a degradação do utilitário do usuário devido ao
extenso tempo de inatividade do serviço. Nesse sentido, aplicamos o algoritmo
MOMEPS em todo o processo para demonstrar a proporção de migração de serviço e
offloading de borda (ou seja, sem migração) na otimização de políticas de longo prazo.
Conforme mostrado na Fig. 4, as decisões de descarregamento desempenham uma
posição dominante (ou seja, 81,82%) para reduzir o tempo de inatividade do serviço,
de modo que os serviços DNN possam ser processados o maior número possível no
servidor de borda rico em recursos. Inspirado por essas observações vitais, uma ideia
central em nosso algoritmo adaptativo proativo é projetar uma abordagem leve para
ajudar o usuário a determinar rapidamente se uma migração de serviço DNN é
necessária ou não. Conforme ilustrado na Fig. 5, uma vez determinada a migração do
serviço DNN no slot atual, a política preditiva baseada em MPC seria adotada para
derivar uma decisão de migração eficiente. Caso contrário, o dispositivo pode
descarregar sua tarefa com uma seleção de ponto de saída ideal para obter alto
desempenho de serviço. Claramente, os tempos de execução da política preditiva
baseada em MPC serão significativamente reduzidos, levando a menores overheads
computacionais.
Inspirado em [35], adotamos um modelo leve de Redes Neurais (NN) para
determinar dinamicamente se migrar ou não o serviço DNN com base no estado atual
do usuário, devido à sua poderosa capacidade de apresentação. Particularmente, o
dispositivo pode coletar rastros de amostra suficientes antecipadamente e treinar o
modelo NN offline e, em seguida, executar apenas a inferência do modelo leve
online1. Para caracterizar bem o mapeamento subjacente do modelo NN,
consideramos dois itens-chave observados pelo dispositivo no intervalo de tempo
atual, ou seja, a frequência de solicitações e a distância de salto entre o serviço e o
usuário como entrada para o modelo NN. As razões por trás disso são as seguintes: por
um lado, um longo atraso de transmissão com grandes distâncias de salto estimularia a
migração do serviço DNN, visando utilitários mais altos em intervalos de tempo
sucessivos; Por outro lado, a demanda de requisições é um indicador essencial do
desempenho do serviço. Particularmente, a alta frequência de solicitações do usuário
(por exemplo, o número de quadros de vídeo na detecção objetiva) implica em altos
custos potenciais para a migração do serviço DNN, uma vez que o modelo DNN deve
ser inferido no dispositivo local durante o procedimento de migração. Finalmente,
resumimos este algoritmo Smart-MOMEPS no Algoritmo 3.
VI. AVALIAÇÃO

Nesta seção, realizamos simulação orientada a traços para avaliar o


desempenho de nosso algoritmo proposto e demonstrar sua eficácia em comparação
com esquemas de referência.

A. Configuração da Simulação

Neste experimento, tomamos o AlexNet [36] como o serviço DNN e


empregamos o framework BranchyNet para treinar este modelo AlexNet com cinco
pontos de saída. Testamos o atraso e a precisão da inferência em cada ponto de saída,
usando um PC desktop (CPU Intel i7-6700 e 8 GB de memória). O resultado é mostrado
na Tabela II. Para mobilidade do usuário, utilizamos o simulador ONE [37] para gerar
traços de movimento do usuário. O ONE simula o cenário em que dispositivos móveis
se movem pelas estradas e ruas de uma cidade urbana. Escolhemos os dados de
movimento dos carros, e a velocidade de cada carro é de 10km/h a 50km/h. Para
simplificar, dividimos toda a área em 169 partes quadradas, sendo que cada parte
possui uma estação base que pode prestar serviço ao usuário e ocupa 200m 200m de
área. Em nossa simulação, adotamos um modelo discreto com intervalos de tempo
para caracterizar a dinâmica do sistema. Definimos o intervalo de um intervalo de
tempo para 20 segundos, e a conexão sem fio e a dinâmica do sistema permanecem
inalteradas durante cada intervalo de tempo. Para trajetória do usuário e previsão de
frequência de solicitação, utilizamos LSTM para obter os resultados.

B. Esquemas de referência

Comparamos nossos algoritmos propostos com a solução ótima offline acima


mencionada e os 5 benchmarks a seguir.
1) Sempre Migração (AM): o usuário sempre migra o serviço para a estação
base onde está localizado atualmente.
2) Lazy Migration (LM): o serviço não será migrado até que a distância entre a
estação base onde está hospedado e o usuário ultrapasse o limite. Uma vez que a
migração é acionada, a imagem do serviço é migrada para a estação base onde o
usuário está atualmente localizado.
3) Predictive Lazy Migration (PLM): um algoritmo de predição baseado em Lazy
Migration proposto em [38]. Ele aproveita a previsão one-shot para melhorar o
algoritmo LM.
4) Lazy MPC (L-MPC): este algoritmo é proposto para reduzir o overhead
computacional do MPC. A ideia básica do L-MPC é que usamos o MPC somente quando
a condição de migração no LM é atendida.
5) Controle de Horizonte Fixo (FHC): diferentemente do algoritmo padrão
baseado em MPC, o FHC executa todas as decisões dentro de uma janela de previsão
em vez de apenas o primeiro passo dessas decisões [39].

C. Comparações de desempenho do algoritmo

Primeiro avaliamos nossos algoritmos propostos e cinco benchmarks. A janela


de previsão de algoritmos baseados em MPC é definida para 5 slots de tempo.
Definimos uma métrica de eficiência como a razão entre a utilidade geral do usuário
obtida por esses algoritmos e a utilidade obtida pelo algoritmo ótimo offline. Os
resultados numéricos são mostrados na Fig. 6, nossos algoritmos propostos são
estáveis em diferentes intervalos de tempo e sempre alcançam efeitos mais notáveis
em comparação com benchmarks. A eficiência do Smart-MOMEPS é de 96%, quase o
mesmo do MOMEPS (97%). Esse resultado demonstra que nossa abordagem de
julgamento de migração inteligente proposta pode efetivamente ajudar o usuário a
determinar se a migração é necessária com base no estado atual do usuário.
Além disso, podemos observar que o algoritmo FHC tem o pior desempenho,
com apenas 58% do ótimo offline. Isso ocorre porque as decisões nos últimos
intervalos de tempo dentro da janela de previsão se desviam muito das decisões
ótimas devido ao acúmulo de erros de previsão, o que pode reduzir severamente a
eficiência do algoritmo. Comparado ao FHC, o Smart-MOMEPS tem 1,6 vezes a
eficiência e melhor robustez. Exceto para FHC, algoritmos que alavancam informações
futuras funcionam melhor do que aqueles que não o fazem. A razão é que
consideramos o tempo de inatividade do serviço neste trabalho. Se o serviço seguir
cegamente a trajetória do usuário (AM e LM), o serviço não poderá ser migrado para
um BS adequado na maioria dos casos devido à mobilidade do usuário. Por outro lado,
informações futuras podem ajudar o usuário a migrar o serviço da maneira mais
adequada possível. Comparado ao LM, o PLM pode ajudar o usuário a evitar migrações
desnecessárias usando as informações do próximo slot. No entanto, quando o serviço
precisa ser migrado, o PLM não pode orientar o usuário para onde migrar o serviço,
pois o tempo de inatividade contém vários intervalos de tempo. Consequentemente, o
Smart-MOMEPS pode ser mais eficaz que o PLM.

D. Custo de Execução de Algoritmos

Também avaliamos a redução da sobrecarga computacional causada pelo


Smart-MOMEPS em diferentes intervalos de tempo. Definimos a sobrecarga
computacional desses algoritmos como os tempos de execução de previsão e OMEPS.
De acordo com o resultado da Fig. 7, o Smart-MOMEPS pode cumprir uma taxa média
de redução de sobrecarga de computação 3,1 vezes mais do que o MOMEPS. Embora a
sobrecarga de computação do Smart-MOMEPS seja maior que a do Lazy-MPC, ainda
vale a pena considerar a melhor eficiência do algoritmo. Para verificar ainda mais o
desempenho do nosso algoritmo em dispositivos com recursos limitados, avaliamos a
adequação do nosso algoritmo em dispositivos móveis medindo a latência de execução
em diferentes dispositivos. Os resultados são mostrados na tabela 3. Comparado ao
intervalo de um intervalo de tempo (20s), nosso algoritmo é leve o suficiente para
ajudar o usuário a tomar decisões de migração rapidamente.
E. Impacto do Erro de Previsão e Tamanho da Janela de Previsão

Além disso, investigamos o impacto do erro de previsão e até que ponto olhar
para o futuro na eficiência do algoritmo. Usamos dois métodos de previsão para obter
as informações futuras. Um deles é a memória de longo prazo (LSTM) e o outro é o
modelo de média móvel integrado autorregressivo (ARIMA) [40]. A precisão de
previsão desses dois métodos é de 93,3% e 82,5%, respectivamente. Intuitivamente,
quanto mais precisas forem as previsões do modelo MPC, melhor será o desempenho
do algoritmo, e os dados experimentais confirmam essa intuição. Conforme mostrado
na Fig. 8, a eficiência do algoritmo baseado em LSTM é 5,3% maior do que o algoritmo
baseado em ARIMA em média.

Quanto à influência de diferentes tamanhos de janela de previsão W , a Fig. 8


mostra que a eficiência do algoritmo melhorará com o aumento de W no início. Isso
ocorre devido à existência de tempo de inatividade do serviço. Quando o tempo de
inatividade do serviço para migração para uma estação base for maior que o tamanho
da janela de previsão, o algoritmo não selecionará essa estação base como destino da
migração. Além disso, o efeito de migração de longo prazo não é considerado quando
W é pequeno, o que também fará com que a solução tenha um desempenho inferior.
Portanto, quando o tamanho da janela de previsão for menor que o tempo de
inatividade máximo do serviço, o desempenho do algoritmo melhorará com o
aumento do tamanho da janela de previsão. No entanto, esta melhoria não dura para
sempre. A Fig. 8 mostra que os desempenhos desses algoritmos começam a declinar
quando W é maior que 6. Isso pode ser explicado pelo fato de que quando não há
erros na previsão futura, W pode ser definido o maior possível para obter o melhor
desempenho de longo prazo. No entanto, não podemos prever o futuro perfeitamente
na prática. Quanto mais à frente olhamos para o futuro, menos precisa se torna a
previsão. Portanto, quando o tamanho da janela de previsão continua a aumentar, o
desempenho do algoritmo diminuirá gradualmente.
F. Impacto de Diferentes Pontos de Saída do Modelo DNN

Para avaliar como o número de pontos de saída antecipados do modelo DNN


influencia o desempenho do algoritmo, empregamos um modelo AlexNet como um
serviço DNN e medimos o desempenho de nossos algoritmos com 2 a 5 pontos de
saída. Para mostrar concisamente a diferença de desempenho, caracterizamos o
desempenho de cada algoritmo como sua razão para o ótimo offline com 5 pontos de
saída.
Os resultados da eficiência do algoritmo e dos tempos de migração são
mostrados na Fig. 9. À medida que o número de pontos de saída aumenta, a eficiência
do algoritmo melhora e menos migrações de serviço serão executadas. Esse resultado
demonstra que os pontos de saída do modelo desempenham um papel positivo na
migração do serviço DNN. Assumindo que não há ponto de saída em um modelo DNN,
quando o atraso percebido pelo usuário exceder o atraso máximo tolerado do serviço,
o usuário só poderá migrar o serviço, pois o utilitário será zero se perder o prazo.
Durante o tempo de inatividade do serviço causado pela migração, as solicitações de
serviço serão processadas localmente com pouca utilidade. Em vez disso, o ponto de
saída fornece ao usuário uma alternativa à migração. O usuário pode optar por sair da
inferência de DNN mais cedo para reduzir o atraso de computação, o que pode aliviar
o atraso de transmissão aumentado causado pelo movimento do usuário. Isso requer
muito pouco sacrifício de utilitários em comparação com a migração. Em poucas
palavras, mais pontos de saída levam a mais utilidade do usuário e menos migrações.

G. Impacto da Densidade da Estação Base

Finalmente, mostramos o impacto de diferentes densidades de estações base e


observamos as mudanças de nossos algoritmos. Vale ressaltar que a gama de serviços
fornecidos por cada estação base é constante em nossa configuração, e controlamos a
densidade das estações base alterando suas propriedades (uma apenas encaminhe
solicitações do usuário, enquanto a outra é capaz de encaminhar e executar
solicitações de). Para simplificar, caracterizamos a eficiência de cada algoritmo sob
diferentes densidades de BS como sua razão para o ótimo offline quando a densidade
de BS é 12,57. A Fig. 10 mostra que existe um crescimento na eficiência dos algoritmos
à medida que a densidade de BS aumenta de 4,16 para 12,57. Isso ocorre porque mais
estações base trazem mais opções de migração quando o usuário migra serviços.
Também é mais fácil para o usuário migrar serviços para uma estação base mais
próxima para obter maior utilidade. Para resumir, quanto mais densas forem as
estações base, melhor será o desempenho de nossos algoritmos.

VII. CONCLUSÃO

Neste artigo, investigamos um problema de migração de serviço DNN centrado


no usuário e seleção de ponto de saída com vários tempos de inatividade de serviço no
ambiente de computação de borda móvel. Aproveitamos o recurso de seleção de
ponto de saída e compartilhamento de camada da técnica de contêiner para aliviar a
degradação do desempenho causada pelo inevitável tempo de inatividade do serviço.
Para maximizar a utilidade do usuário a longo prazo, primeiro propomos um algoritmo
de estratégia de migração otimizada e seleção de ponto de saída (OMEPS) offline,
aproveitando a programação dinâmica quando informações futuras completas
estiverem disponíveis. Para lidar com o comportamento incerto do usuário,
incorporamos uma estrutura de controle preditivo de modelo ao algoritmo OMEPS. Em
seguida, construa uma migração de serviço proativa e um algoritmo de seleção de
ponto de saída DNN (MOMEPS). Para lidar com as pesadas sobrecargas de computação
do MOMEPS, propomos um algoritmo econômico, o smart-MOMEPS, que introduz um
julgamento de migração inteligente baseado em rede neural para navegar no trade-off
de desempenho e sobrecarga de computação. Por fim, realizamos extensos
experimentos orientados a rastreamento para avaliar nosso algoritmo online. Também
exploramos o desempenho de nossos algoritmos em uma variedade de configurações
do sistema e fornecemos análises correspondentes.

Você também pode gostar