Método​

Presencial

Duração​

10:00 - 11:00

Supervisores presentes​

• Rafael Teixeira ✔️
• Rafael Direito ✔️

Membros presentes​

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

Assuntos discutidos​

• APIs 5G
• Componente de Machine Learning

Resumo​

APIs 5G​

• No data relay, temos de comunicar com o NRF para ir buscar um URL para saber onde fazer post dos dados (exposição default da NWDAF)
• Temos de nos registar no NRF
• Inicialmente fazer isto de forma automatica ao dar up à pipeline
• Ver NEF para ir buscar os dados
• Na resposta chega ter o IP e a port da NF instance
• Ser compliant é passar em testes unitários e de integração.
• Escolher o que nós queremos do payload e usar

ML​

• Ter um modelo, dar deployment e avaliá-lo.
• Escolher features, escolher modelo e submeter modelo.
• Usar diretamente o csv para termos logo muitos dados.
• Primeiro testes unitários, depois testes de integração.

Balancear dados de treino.​

• SMOTE

• Gerar dados artificiais negativos para balancear ou cortam positivos.

• Alterar a pipeline para mandar dados mais rapidamente.

• Teste com o groundtruth é no ML Training.

• Para validar o eval é só no modelo em deployment.

• .corr_metrics no pandas -> indica a relação das features entre si.

• correlação 0 entre features é mau -> não conseguimos retirar relação.

• em princípio não precisaremos de mais do que aqueles modelos classificativos (Random Forest, XGBoosting, NN).

Model Testing Report:​

• PRECISION: Quantidade de instâncias positivas que de facto são positivas.
• São muito usados na saúde porque não geram tantos falsos positivos
• F1: Medida que vamos considerar (balanceada).
• O que se usa hoje em dia é MCC -> Mas vamos usar F1 Score.
• Não vamos usar accuracy -> extremamente biased principalmente no nosso caso.
• Mudar de classificativo para binário para simplificar. Ver só se é ataque ou não ataque.
• Quando conseguirmos ter o binário em condições -> Passar para classificativo.
• weighted avg -> avg de acordo com as classes.
• macro avg -> desconsidera qualquer peso.

Notas​

• Próxima reunião: 30/04 14:00h

Ficheiros Relacionados​

Exemplo de um relatório de testes dos modelos.

2025-04-22 00:13:51,510 - INFO - Model training complete.
2025-04-22 00:20:06,972 - INFO - Starting the ML pipeline...
2025-04-22 00:20:06,972 - INFO - Fetching new training data from ClickHouse...
2025-04-22 00:20:07,024 - INFO - Fetched 8210 rows and 46 columns
2025-04-22 00:20:07,024 - INFO - Preprocessing data...
2025-04-22 00:20:07,030 - INFO - Attack labels encoded: [' Fuzzers ', ' Reconnaissance ', 'Benign', 'DoS', 'Exploits', 'Generic']
2025-04-22 00:20:07,031 - INFO - Rows with Label = 1: 39
2025-04-22 00:20:07,031 - INFO - Final dataset shape after preprocessing: (8210, 43)
2025-04-22 00:20:07,031 - INFO - Training and comparing classifiers...
2025-04-22 00:20:07,034 - INFO - Training Random Forest...
2025-04-22 00:20:07,299 - INFO - 
--- Classification Report: Random Forest ---
2025-04-22 00:20:07,303 - INFO - 
              precision    recall  f1-score   support

           1       0.00      0.00      0.00         1
           2       1.00      1.00      1.00      1636
           4       1.00      0.20      0.33         5

    accuracy                           1.00      1642
   macro avg       0.67      0.40      0.44      1642
weighted avg       1.00      1.00      1.00      1642

2025-04-22 00:20:07,303 - INFO - Training Gradient Boosting...
2025-04-22 00:20:14,447 - INFO - 
--- Classification Report: Gradient Boosting ---
2025-04-22 00:20:14,451 - INFO - 
              precision    recall  f1-score   support

           0       0.00      0.00      0.00         0
           1       0.00      0.00      0.00         1
           2       1.00      1.00      1.00      1636
           4       1.00      0.40      0.57         5

    accuracy                           1.00      1642
   macro avg       0.50      0.35      0.39      1642
weighted avg       1.00      1.00      1.00      1642

2025-04-22 00:20:14,451 - INFO - Training MLP (Neural Network)...
2025-04-22 00:20:14,639 - INFO - 
--- Classification Report: MLP (Neural Network) ---
2025-04-22 00:20:14,644 - INFO - 
              precision    recall  f1-score   support

           1       0.00      0.00      0.00         1
           2       1.00      1.00      1.00      1636
           4       0.00      0.00      0.00         5

    accuracy                           1.00      1642
   macro avg       0.33      0.33      0.33      1642
weighted avg       0.99      1.00      0.99      1642

2025-04-22 00:20:14,645 - INFO - Model training complete.

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​

• Chronograf
• ML
• 5G INtegration
• Novos horários de reuniões

Resumo​

• duvidas no chronograph
• conexão entre o chronograf e um influx
• Pipline sem ML a funcionar e depois focar no resto
• Malta da integração com o 5g se não estiverem a fazer nada, podem começar.

ML​

• O ML vai ter de conseguir pedir dados por API ao Data Processor.

• Ir buscar o dataset

• Ver modelos para aplicar.

• Quando eles fizerem as previsões.

• Transformar num pickle.

• Sempre que o modelo estiver pronto, mandar para o inference.

• Divisão de features

5G Integration

• Ver as APIs da release 18.

Planeamento das proximas reuniões durante a Pácoa e Semana Académica.

22/04 10h 28/04 ???

Notas​

• Acabar a pipeline o mais rápido possível, para conseguir passar à parte de ML.

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​

• Apresentação MS3
• Groundtruth
• Estado da implementação
• Próximos passos

Resumo​

Powerpoint​

• Alterar última linha do SoA. -> Apontar a lacuna e o que nós vamos melhorar.
• Arquitetura -> alterar a ligação do chronograph ao service register.
• Alterar diagramando deployment -> Adicionar as novas coisas.
• Alterar foto do pacote JSON -> Dividir em 2 para ficar readable e dar highlight a partes importantes.
• Future work -> Falta falar de ML.
• Demo -> mostrar interface, logs, containers e código.
• Mostrar calendário atualizado (de forma dinâmica).

Geral​

• No processor fazer chunking.
• Documentar tópicos do kafka.

Groundtruth​

• Match do timestamp com o timestamp do pacote.
• Usar timestamp e ports para verificar o que estava a acontecer.
• Fazer subset dos ataques.
• Timestamps: start time é o inicio da flow e last time o fim. (uma flow inclui vários pacotes)
• Carregar o CSV do groundtruth em memória.
• Se der valores diferentes, não preocupar porque pode ter havido mudanças no código do nProbe.

ML​

• O modelo só treina quando tem dados suficientes.
• Acumula dados num buffer e depois usa para treino.

Data Processor​

• Meter o pré-processamento das queries da BD do lado do Processor.

Notas​

• Acabar o powerpoint ASAP.
• Atualizar Microsite com as coisas da MS3.

Ficheiros relacionados​

• Arquitetura do MVP

• Arquitetura Final

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​

• Dúvidas e problemas na implementação.

Resumo​

• Nos dados, apresentar só se é ataque ou não é ataque -> tem mais accuracy.
• Com base no csv gerado por eles conseguimos tirar os identificadores.
• NUSW_NB15 groundtruth, com base neste conseguimos identificar qualquer um deles.
• Conseguimos saber quanto cada ataque aconteceu.
• Mesmo ip/porto de ataque: pode atacar ou não atacar, ou atacar de forma diferente. Ver os timestamps do ataque.
• Filtrar por src ip e filtrar com o timestamp. Se não acontecer nada é não ataque.
• Tudo o que estivar naquele csv é ataque. O que não estiver não é ataque.
• Espetar este csv na bd e fazer queries à bd. Ou usar frameworks do python.
• Treinar modelos é dados históricos.
• Não temos groundtruth no live data.
• Conjunto de dados históricos pré-carregados na bd.
• O edu concluiu coisas da implementação.
• nprobe funciona em batch.
• Se ele funciona por conexão temos de ter a certeza que todas as comunicações já comunicaram.
• Tem que se analisar o nprobe.
• Os dados raw são mandados para a timeseries. Num dado momento o processor vais buscar à timeseries quando for preciso processar.
• Usar o scapy.
• A conversão dos dados (bytes dos pacotes) faz-se no Data Receiver. -> diminui o numero de conversões.
• Meter em pcap no processor, se tiver de ser.
• Quanto menos conversões melhor.
• Ver o tamanho das batches que nós temos.
• Normalização faz-se quando tivermos de carregar para o dataset de treino.
• E vai depender de como estivermos a dividir o dataset.
• Dependendo do algoritmo do modelo, usaremos diferentes tipos de normalização.
• InfluxDB está indexado ao tempo e aproveitaremos para fazer queries com base nisto.
• Data drift obriga o retraining e redployment e do modelo.
• Dados de treino têm sempre ground truth, exceto se for unsupervised learning.

Depois do mvp:​

• Implementar os standards.
• Service register não vai ser implementado, a menos que terminemos cedo.

Notas​

• Focar em ter um produto funcional no MVP.
• Demo conta muito -> Ter um dashboard com métricas relevantes.
• Estamos atrasados, acelerar nesta iteração.

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.