Summary

Developed internally at Telstra, Neuron is a new Network Observability Platform consolidating a number of existing tools used for Network Performance Monitoring and Optimisation, primarily in the RAN space but also encompassing the Converged Core and parts of the Transport Network.

Neuron will provide innovative new features to facilitate greater flexibility, speed and quality of insights generated by network engineers, enabling them to more effectively maintain the health and quality of our network for customers.

Neuron is developed using the MERN stack, MongoDB as our non-relational database, ExpressJS and NodeJS for our RESTful API’s and backend, along with React and Redux for our frontend and state management. The application is hosted on AWS and utilises a suite of services documented below.

AWS Architecture Overview

Application Services and Features

Catalog

The Catalog feature is the replacement for Dingbat, and its development is critical to Bilby's initiative to move towards big data, migrating Oracle to Hadoop. Catalog supports and enables the continued visualisation of Bilby data after the transformation. Dingbat would no longer be able to be used as a presentation layer after the migration, leaving Network Engineers blind to faults and unable to identify where they are occurring in the network.

Blueprints

The Blueprints feature enables Network Engineers to develop network checks and reports on the fly, enabling customized queries, charting and data collection. Blueprints enables innovation and collaboration by allowing engineers to save, favourite and share blueprints to other users of the application.

This tool automates fault finding and raising of alarms for issues in the network introduced by integrations of network elements and new technologies. A good example is the Post Integration Checklist which gave engineers observability of the 5G network through performance checks, identifying network issues during integration of cell sites in real time.

There are three types of Blueprints:

• Checklist:

  Enabling users to create a suite of checks to run against different parts of the network on an ad-hoc basis and raise alarms through its integration with the Dingo fault ticketing system.

• Tabular:

  A smart report with features for heat mapping, interactive commenting, and linked split screen reports.

• Scheduled:

  Scheduled blueprints facilitates triggering and raising alarms to SON. It is a data processing and scheduling mechanism that produces reports and alerts for the purpose of fault detection, analysing data during special events with custom aggregation.

Explore

The Explore feature is a chart editor for Catalog, leveraging Sigma to enable the automatic generation of underlining SQL queries for charts. It enables consistency and accuracy of reporting by utilizing a centralized KPI manager for network observability, removing user reporting errors caused by manual entry of unmaintained or stale metrics.

Explore is an ad-hoc analytical tool enabling users to create their own charts, having full control of the targets, metrics, granularity and aggregation. This tool also enables collaboration through the ability to save these charts to Catalog and share them with other users.

Microservices

Neuron is developed using the MERN stack, MongoDB as our non-relational database, ExpressJS and NodeJS for our RESTful API’s and backend, along with React and Redux for our frontend and state management.

The team has taken the Microservices architecture approach to developing Neuron. Microservices are distributed and loosely coupled, so code changes to a particular service won’t break the entire application. The benefit of using microservices is that developers are able to rapidly build new components to meet changing business needs, each service can be built and deployed independently making CI/CD seamless.

Looking at our application architecture design, all of our services are containerized using Docker and communicate between each other through secure RESTful API calls, and each service has a defined function.

Amazon Web Services

This is a high-level architectural overview of the Amazon Web Services used by Neuron to enable resiliency, auto healing, redundancy and autoscaling for our application.

The Application Load balancer manages traffic across our ECS Cluster which is a logical grouping of tasks or services. These services enable autoscaling, auto healing, redundancy and resiliency by spreading the application across 3 EC2 instances in different Availability Zones, allowing the application to continue running if one of the services or data centres go down.

Our data is hosted on the non-relational database service Amazon DocumentDB for MongoDB compatibility used in our technology stack.

Neurons services are containerized by Docker, the images are built and deployed to the Elastic Container Register, managing our images and deploying them to the Elastic Container Service which is our container orchestrator.

Service logs are piped to CloudWatch, then processed and analysed by Kinesis in real-time, then forwarded into Bambi Splunk for dashboarding.

Neuron’s AWS infrastructure deployment is automated using Terraform for Infrastructure as Code. The combination of these services makes our application reliable, performant at scale, secure and optimized for cost.

Security

Application security and secure code is always top of mind for the Neuron team, always following and implementing best practices.

Secure single sign-on authentication is achieved with integration to SecureAuth, returning a SAML response after successful authentication allowing us to validate the users AGS groups against our application. We use AGS for group & role management to enable authorization to the application, allowing us to sign JSON Web Tokens and set Secure Cookies, controlling user access across the application and API’s.

Our repositories code and docker images are scanned for vulnerabilities, by integrating Jetpack Security as a Service with Source Clear into our Bamboo plans.

Neuron’s backend services secure API routes with authentication and role authorization middleware.

Vulnerable HTTP headers and our HTTP traffic are hardened by implementing SSL, better Cross-Origin Resource Sharing policies and best practices from leading security vendors, mitigating and minimizing attack vectors, protecting us from attacks such as Cross Site Scripting and Request Forgery.

Application dependencies are regularly scanned for security vulnerabilities using Node Package Managers audit feature, and dependencies are kept up to date, applying fixes for identified vulnerabilities within packages.

Application Preview

Catalog

Blueprints

Explore

Sigma