Método​

Presencial

Duração​

9:00 - 10:00

Supervisores presentes​

• Rafael Teixeira ✔️
• Rafael Direito ✔️

Membros presentes​

• Rodrigo Abreu ✔️
• Eduardo Lopes ✔️
• João Neto ❌
• Hugo Ribeiro ✔️
• Jorge Domingues ✔️

Assuntos discutidos​

• Data Processor
• Dataset
• Estado da implementação
• Diagrama de fluxo de dados
• Apresentação checkpoint 1

Resumo​

Data Processor​

Não mandar as features que o modelo não vai usar.

Se mandarmos os ips vai fazer bias ao modelo. 3 opções:

• eliminar tudo o que não preciso (melhor no nosso caso)
• método para preencher os dados
• definir como não possivel (pior no nosso caso)

Guardar dados em tabela ou csv no data warehouse?

Orientador Rafel Teixeira: "Para o modelo é melhor os dados tabelados, então devemos guardar tabelados."

O modelo nunca aceita strings, o modelo aceita números.

Não preocupar com isso para já, há ferramentas que transformam automaticamente.

Dataset​

Conseguimos tirar daqui o que é preciso:

• descrição dos features
• como obteram os dados
• etc

paper associado: https://link.springer.com/article/10.1007/s11036-021-01843-0

usar o outro csv para dados raw.

usar este para ver os dados pré-processados: https://espace.library.uq.edu.au/view/UQ:ffbb0c1

Implementação​

• ler pcaps em vez de csv
• alterar data producer, receiver, etc
• pcaps devem ser convertidos em algo para pôr no kafka

Diagrama de sequência​

• colocar kafka no meio e não separar em tópicos.
• colocar nrf (service registry). Prof. Aguiar falou disso.
• colocar tudo em inglês.

Apresentação checkpoint 1​

• diagrama de fluxo dos dados deve ser o primeiro a ser apresentado.
• mostrar a arquitetura do mvp e o que já foi feito.
• Adicionar divisão de trabalho (coisas do github project)

Notas​

• Fazer a apresentação ASAP.
• Importante fazer o refactoring para os pcaps rapido, para implementar o resto das features.

Ficheiros relacionados​

• Logs avaliados

• Diagrama do fluxo de dados

Método​

Presencial

Duração​

10:00 - 11:00

Supervisores presentes​

• Rafael Teixeira ✔️
• Rafael Direito ✔️
• Rui Aguiar ✔️

Membros presentes​

• Rodrigo Abreu ✔️
• Eduardo Lopes ✔️
• João Neto ✔️
• Hugo Ribeiro ✔️
• Jorge Domingues ✔️

Assuntos discutidos​

• Primeiros passos da implementação
• Data Producer

Resumo​

• Usámos o poetry para dar build ao projeto e fazer a gestão das dependências.
• Orientador Rafael Teixeira explicou-nos como integrar os kubernetes para deployment do projeto, mas não é muito importante. Usar containers docker por agora.
• Apresentação do producer -> tem erros, principalmente o facto de tentar pôr os dados numa classe python desde o início, o que não é correto. O dataset tem muitos outliers.
• Tratar dos outliers apenas no Data Processor
• Meter Data Producer e *Data Receiver a comunicar com o kafka por agora. Mais tarde, usar as APIs.
• Meter o Data Producer a enviar dados periodicamente para o respetivo tópico, para o receiver conseguir obtê-los.
• Influx DB já está dockerized.
• Vamos precisar de um componente na arquitetura que indique aos clientes as possiveis métricas que podem consumir. Metadados
• Esse componente pode não ser implememntado, mas tem de estar atualizado.
• Establecer dentro dos possiveis a API para desponibilizar as nossas insishts com o 3gpp.
• Orientador Rafel Direito recomendou um diagrama de sequência para mostrar o fluxo de mensagens entre os componentes.
• Apresentação ter sido corrido mal não é assim tão relevante -> focar no produto final e ter boa documentação.

Notas​

• Sanitizing dos dados com erros.
• Focar nos dados. ML é um bonus.
• Prometer pouco e entregar muito. -> Rafael Teixeira
• Diagrama de Sequência ASAP

Ficheiros relacionados​

Método​

Presencial

Duração​

10:00 - 11:00

Supervisores presentes​

• Rafael Teixeira ✔️
• Rafael Direito ✔️

Membros presentes​

• Rodrigo Abreu ✔️
• Eduardo Lopes ✔️
• João Neto (remoto)✔️
• Hugo Ribeiro ✔️
• Jorge Domingues ✔️

Assuntos discutidos​

• Apresentação do powerpoint da MS2.

Resumo​

Análise dos orientadores ao Powerpoint:

Contexto e estado da arte:

• Estado da arte da NWDAF. Precisamos de ML porque é o estado da arte da implementação.
• 5G precisa de ML, Solução NWDAF (SoA) e depois dizer o que vamos fazer.
• Distanciar da NWDAF.
• SoA tirar umas conclusões da cada paper.

Casos de Uso:

• Exportar o diagrama com svg.
• Mudar o cenario -> slide dá ideia que o cenario é ataques a robos. Tirar o svg do robô.

Requirements:

• Pequenos ajustes em alguns.
• Redução de alguns, para ficarem apenas os principais.

Non-functional:

• Meter os requisistos com medidas a serio, eram pouco objetivas.

Arquitetura:

• meter em svg também.
• meter a seta bidirecional no metrics.
• Chronograph em vez do grafana.
• Dashboard interface subscribe. (seta nos 2 sentidos).
• Meter middleware entre o kafka e as BDs.

Mockups

Slide 1.

• meter metricas mais corretas.
• current anomaly rate -> average anomaly probability.
• meter uplink e downlink.

Slide 2.

• jitter -> time series.
• tirar heatmaps.

Slide 3.

• Cuidados com os ips.
• Meter tudo TCP.

Notas​

• Fazer os ajustes necessários ao powerpoint.
• Atualizar o microsite com as coisas da MS2.
• Preparar a apresentação da MS2.
• Atenção à gestão do tempo. (Temos muitos slides).

Ficheiros relacionados​

• Arquitetura antes das alterações:

• Arquitetura depois das alterações (Versão MS2):

Método​

Presencial

Duração​

9:00 - 10:00

Supervisores presentes​

• Rafael Teixeira ✔️
• Rafael Direito ✔️

Membros presentes​

• Rodrigo Abreu ✔️
• Eduardo Lopes ✔️
• João Neto ✔️
• Hugo Ribeiro ✔️
• Jorge Domingues (remoto) ✔️

Assuntos discutidos​

• Considerações sobre a integração com o core 5G.
• Atores e cenários.
• Arquitetura
• Use Cases
• Mockups da monitoring interface.
• Apresentação do SCRUM Board.

Resumo​

Sobre a integração com o core 5G:

• É importante descobrir as interfaces e depois encontrar API.
• Focar no pipeline.
• Importante identificar que interfaces teria de ter para a comunicação entre os componentes e depois qual deveriamos implementar.

Em relação aos casos de uso, apresentámos os levantados e um exemplo de um diagrams (segue em anexo):

Feedback dos tutores:

• retirar alguns (está muito exaustivo).
• Pôr só 2 atores. Network/service provider e client para simplificar.
• Conectar os que se relacionam com o client a ele.
• No relatório apresentar todos os casos de uso, mas só implementar alguns. Os que serão implementados já darão trabalho suficiente.
• Focar no caso de uso "anomaly detection".

Alguma informação do tutor Rafael Teixeira sobre o ML Ops pipeline:

• Tutor Rafael Teixeira vai fornecer um dataset para identificar-mos as métricas a usar no modelo.
• Dados raw são por exemplo, os recolhidos pelo wireshark a correr na rede.
• Ips, pedidos de conexão, etc. Traduzir isto para métricas.
• Output é suposto ser um csv. Este deve ser já processado e raw.
• Precisamos de um data warehouse para provenance.

Foi apresentado uma ideia da arquitetura aos orientadores (segue em anexo).

Feedback dos tutores:

• Organizar melhor o diagrama. Exemplo da arquitetura openslice como guia (segue em anexo).
• Temos de ter API no ML Model.
• Meter o monitoring system e o ML Model à direita.
• Manter a time series DB, é útil para o segundo caso de uso que será implementado.
• Como fazer a gestão do treino? -> Ter data warehouse para guardar dados processados.

Mockups da Monitoring Interface?

Feedback dos tutores:

• Levar uns exemplos da interface de monitoring, embora o projeto não esteja muito virado para estes moldes.
• Justificar a falta de mockups. Especificar que o projeto é virado para o backend e o único dashboard que temos é o grafana.

Foi-nos apresentado também um bom sistema de previsão de QoS e Assurance -> Facebook Prophet.

• Apresentação do SCRUM Board do projeto para os tutores conseguirem acompanhar o progresso.

Notas​

• Daqui em diante fazer a parte correspondente à apresentação na documentação, antes da apresentação.
• Anotar as dúvidas nos pdfs do 3GPP para ser analisado pelo tutor Rafael Direito.
• Data lake: dados raw. Data warehouse: dados processados.
• Tentar ter esta milestone concluída sexta para os tutores avaliarem e termos tempo de corrigir coisas atempadamente.

Ficheiros relacionados​

• Ideia de Diagrama de Casos apresentada

• Ideia de Arquitetura apresentada

• Arquitetura Openslice

Método​

Presencial

Duração​

11:00 - 12:00

Supervisores presentes​

• Rafael Teixeira ✔️
• Rafael Direito ✔️

Membros presentes​

• Rodrigo Abreu ✔️
• Eduardo Lopes ✔️
• João Neto ✔️
• Hugo Ribeiro ✔️
• Jorge Domingues ✔️

Assuntos discutidos​

• Análise da Apresentação 1
• Calendário
• Microsite

Resumo​

• Os orientadores aconselharam-nos a explorar mais o contexto, dividindo a parte de Network e ML Ops em 2.
• Recomendaram-nos a explorar mais os related works, evidenciando o conteúdo de cada paper.
• Recomendaram-nos a ter menos texto nos slides para não sobrecarregar o leitor da apresentação.
• Alguns esclarecimentos sobre o conceito do projeto, por exemplo da implementação de um NWDAF é um objetivo ilusório e focar-nos mais na implementação do ML Ops pipeline.
• Afastar aspetos como reliability do projeto, pois é uma coisa dificil de mensurar.
• Aconselharam-nos a fazer uma calendário mais de acordo com a metodologia agile, visando a implementação de um gantt chart. O nosso anterior estava muito waterfall.
• Breve discussão sobre o enquadramento de personas e cenários no nosso projeto. (Exemplo de personas: MNO e CSP).
• Remover coisas a mais do microsite. Vestígios do tutorial principalmente.
• Atualizar o microsite com os deliverables desta fase, quando concluídos

Notas​

• Tentar apresentar a nova versão do calendário ASAP aos orientadores ainda hoje para obter feedback.
• Atualizar e não esquecer de dar deployment ao microsite atualizado.

Método​

Presencial

Duração​

9:00 - 10:30

Supervisores presentes​

• Rafael Teixeira ✔️
• Rafael Direito
• Rui Aguiar ✔️

Membros presentes​

• Rodrigo Abreu ✔️
• Eduardo Lopes ✔️
• João Neto ✔️
• Hugo Ribeiro ✔️
• Jorge Domingues ✔️

Assuntos discutidos​

• Dúvidas relacionadas com a implementação
• Arquitetura
• ML
• Tecnologias
• Contextualização das telecomunicações
• Microsite

Resumo​

Considerações acerca do projeto com o orientador Rafael Teixeira​

Dados​

• Uma base de dados time series seria o mais adequado para o problema.
• Os dados terão de ser guardados antes de serem processados e, dependendo do pipeline, mais versões precisarão ser armazenadas.
• Os dados servirão para análise (não relacionado com ML): médias, medianas, máximos, mínimos, desvio padrão, etc.
• Trabalhar desde cedo com data streams, usando um dataset com timestamp para simular data stream.

Data Lake​

• Devemos usar um host local.

ML​

• Evitar que o modelo veja dados do futuro (apenas usá-los para teste) para não enviesar os resultados.
• Fazer pre-processed training.
• Não focar na complexidade do modelo no início.

Tecnologias​

• TensorFlow ou Scikit-Learn podem ser úteis para ML.
• Kafka poderá ser a ferramenta mais adequada para a implementação do publish/subscribe do streaming de dados.
• Precisamos de ferramentas para monitoring.
• Grafana poderá ser útil para analisar os dados.

Considerações acerca do projeto com o orientador Rui Aguiar​

Contextualização​

• Apresentação do panorama das telecomunicações e 5G, especialmente em Portugal (exemplos da Meo, Vodafone, etc).
• Importância do software ser robusto, pois falhas podem impactar milhões de pessoas.

Arquitetura 5G​

• Importante cumprir os standards, embora não seja possível cobrir todos com a API.
• Fundamental a abstração de cada componente.
• Desenvolver o software de forma modular, permitindo a substituição de partes da arquitetura para futuras melhorias.

Apresentação do microsite ao orientador Rafael Teixeira​

Notas​

• O primeiro passo é data engineering.
• Devemos usar o que já está feito sempre que possível (não reinventar a roda).
• Existem ferramentas de Auto ML.
• A complexidade do ML não deve ser a prioridade; focar no restante das implementações primeiro.
• A complexidade do modelo dependerá do tempo disponível no final.
• No momento, focar na arquitetura e deixar detalhes da implementação para depois.