AWS for Industries
Private 4G/5G and video analytics for industrial sites with AWS Snowball Edge
Industry vertical customers demand secure and reliable wireless networks that can be trusted with mission-critical tasks. As digital transformation and IoT become business imperatives, 4G and 5G private networks are a must to connect everything from robots, security, and safety to virtual reality applications.
In this blog, we will discuss how customers can implement industrial safety solutions by combining private 4G/5G networks and machine learning video analytics at the edge. AWS Snowball Edge provides rugged edge infrastructure and software for this solution, deployed as close as necessary to where data is created in order to deliver intelligent, real-time responsiveness.
Overview
Intrusion detection, Personal Protective Equipment (PPE) compliance, and occupancy monitoring are some common problems faced by industrial customers. Athonet and Megh Computing, AWS Technology Partners, combines private 4G/5G networks and machine learning video analytics to help industrial customers solve these problems. A combination of 4G/5G Quality of Service (QoS) and Snowball Edge deployed at the industrial site provides low latency and near real-time responsiveness for the video analytics solution.
The benefit of providing a combined Athonet 4G/5G core with the MEGH application on a Snowball Edge appliance means that the solution is quick to deploy, portable, and easy to set up with a preset configuration template so that customer demands for video surveillance over a cellular network can be swiftly deployed. Additionally, multiple additional communication services can be provided over the same cellular network, such as voice communication, IoT sensors, communication of point-of-sale devices, and so on.
This blog post describes how to deploy industrial safety solutions in five steps. The following figure (Figure 1) is a diagram showing the five steps.
Figure 1 – Private 4G/5G and video analytics for industrial sites with AWS Snowball Edge
The spectrum used for private mobile networks can commonly be divided into into three categories:
CBRS-type approaches
The Citizens Broadband Radio Service (CBRS) approach in the United States in the 3.5 GHz band aims to support three tiers using dynamic sharing. The top tier is made up of the incumbents (for example, radars, satellite companies, and wireless ISPs) who have the most protection.
The secondary tier includes Priority Access License (PAL) holders, who will pay to buy rights to use a portion of the available spectrum where it is not in use by the top tier.
The third tier comprises General Authorized Access (GAA) and is available to anyone but will have the fewest protections.
Portions of the spectrum are reserved for GAA and PAL tiers in areas where the incumbent is not using the spectrum. PAL and GAA users can access each other’s reserved portion of the spectrum where it is not registered as being used in the SAS database. For this solution spectrum band, a connection to a SAS provider will be required.
Licensed Shared Access
Incumbent license holders can sublicense spectrum to other users in a controlled way. The traditional model was developed in Europe for the 2.3 GHz band. It has two tiers, including the incumbent and secondary users (for example, mobile operators) who are permitted to use the spectrum in areas when it is available. More advanced models are being developed.
Concurrent Shared Access (for example, club licensing)
Unlike the approaches above, this only allows one class of user but allows them to share spectrum with each other in a coordinated way. This allows sharing between mobile operators to improve data speeds and spectrum efficiency. Policy makers increasingly see spectrum sharing as a means of opening up additional spectrum for 4G and 5G mobile services. Their decisions regarding bands and frameworks for sharing directly impact the potential of the resulting mobile services, which in turn will determine the level of investment that mobile operators are willing to make.
Step 1: Prepare Amazon Machine Image (AMI)
Both Athonet and Megh Computing provide premade AMIs ready for deployment on Amazon EC2.
The Athonet 4G/5G Core Network does not require SSH access as the setup is readily configurable via the built-in graphical user interface.
In order to deploy and use the Megh AMIs on the Snowball Edge, the image must be configured with an SSH login key to create a new “prebaked” AMI.
Configure AMI with SSH login key
- Launch an EC2 instance using a premade AMI from Megh Computing.
- Make sure to save the SSH private key (.pem) that is generated when creating the instance. This will be the SSH login key for later when deployed to the Snowball Edge.
- For Megh’s AMI, this may be a good time to make configuration changes to the VAS-100 software, such as changing out the trial license key with one purchased specifically for this Snowball Edge deployment. Although, this configuration can also be deferred until after the software is running on the Snowball Edge.
Reference: Adding an AMI from AWS Marketplace
Save configured AMI
After the software has been configured on the EC2 instance, stop the instance through the AWS Management Console and then save a new image from the instance:
Tip: Name the image to indicate that it’s “ready for Snowball” to differentiate it from normal AMIs.
Optional: Export to VM image for sideloading
If a Snowball Edge has already been ordered or delivered and the customer wants to load a new version of Athonet’s or Megh’s software, then they can do so through a VM image sideloading process using AWS OpsHub.
Follow the referenced AWS guide below to export the new AMI to a VM image in an S3 bucket:
- Make sure to complete the Prerequisites before following the export instructions!
- When starting the export task, set the disk image format to “RAW.”
Reference: Exporting a VM directly from an AMI
Once the image export is complete, it can be downloaded from S3 and saved to the computer that is running AWS OpsHub. Skip to Step 4 for instructions on how to sideload the raw VM image onto the Snowball Edge device using AWS OpsHub.
Step 2: Order AWS Snowball Edge
From the AWS Management Console, navigate to the AWS Snow Family console and select Create Job.
See the AWS Snow Family documentation for instructions on how to create a Snowball Edge job. For job type, select the option Import into Amazon S3 and choose device type Snowball Edge Compute Optimized.
Select the S3 bucket where the data will be imported to. There is an option to create an S3 bucket if one does not already exist (create an Amazon S3 bucket). In the section for Compute using EC2 instances, select the AMIs for Athonet and Megh that were previously created.
In the next step, accept the defaults for the KMS key and the service-linked role. This gives the AWS Snowball Edge read/write access to resources in your account. AWS Snowball Edge uses this role to import your data into Amazon S3.
Finally, select your SNS notification option (you can create a new SNS topic if you do not already have one) and create the job.
The Snowball Edge will be prepared and shipped to you. When the Snowball Edge is received, it will be in a locked state. To unlock it, you will need an unlock code and the manifest file, both of which are obtained through the AWS Snow Family dashboard.
Using the AWS Snow Family dashboard, select the job that was created. Scroll down towards to bottom to the Credentials section. Here you will find the unlock code and manifest file. Copy the unlock code and download the manifest file and store it in a safe place on your machine. You will need both the unlock code and the manifest file to unlock the device in the field to begin using the Snowball Edge.
Step 3 : Initial Setup
Once Snowball has been received, it can be taken to a remote location, and the configuration stage can start. Following are the steps on how to set up the Snowball Edge device. Here are the prerequisites:
- A Snowball Edge configured using the preceding instructions
- A router that supports 1 GbE or 10 GbE. This is required to create a local area network that will allow a laptop to connect to the Snowball. In this demonstration, a standard home router with at least one available port is used.
- A cable to connect the Snowball to the router
- A laptop, to interact with the Snowball over the LAN, using AWS OpsHub and SSH
- A 4G/5G radio access point
- Manifest file and unlock code
The Snowball Edge can be configured using AWS OpsHub or CLI. For setting up the Athonet 4G/5G core, use the CLI for passing username for hostname generation to the application.
The instructions for the initial setup are as follows:
- Open the left side panel and connect the power to the power outlet and ethernet or optical to the router.
- Connect the 4G/5G access point to the router.
- Connect the camera to the 4G/5G modem.
Figure 2– an AWS Snowball edge
- Power up the Snowball Edge, and it will obtain a DHCP IP address from the router.
- Open the right side panel and change the IP address to static. This address will be the address to access the Snowball.
Figure 3 – AWS snowball edge touch screeen
The following steps will unlock the Snowball and prepare it for turning up the applications.
- Log into your laptop and make sure that you can access the Snowball by issuing a ping command.
- connecting to the Snowball:
# snowballedge configure –profile snowball
Configuration will stored at xxx/snowball-edge.config
Snowball Edge Manifest Path:xxx_manifest.bin
Unlock Code: xxx
Default Endpoint: https://172.17.4.166
- unlocking the Snowball:
# snowballedge unlock-device --profile snowball
The Snowball Edge unlock status is: UnlockSnowballResult(status=UNLOCKING)
- verify that the Snowball is unlocked:
# snowballedge describe-device --profile snowball
"DeviceId" : "xxx",
"UnlockStatus" : {
"State" : "UNLOCKED"
},
"ActiveNetworkInterface" : {
"IpAddress" : "172.17.4.166"
},
--lines removed –
Step 4 : Launch the Athonet 4G/5G core instance
The next step is to launch the Athonet 4G/5G core instance
- Create a virtual network interface that will be attached to the Athonet 4G/5G core:
# snowballEdge create-virtual-network-interface --ip-address-assignment DHCP --physical-network-interface-id s.ni-84ca5aab36289c0d4 –-profile snowball
{
"VirtualNetworkInterface" : {
"VirtualNetworkInterfaceArn" : "arn:aws:snowball-device:::interface/ s.ni-84ca5aab36289c0d4",
"PhysicalNetworkInterfaceId" : " s.ni-84ca5aab36289c0d4",
"IpAddressAssignment" : "DHCP",
--lines removed --
- Get the AMI on the Snowball
# aws ec2 describe-images --endpoint http://172.17.4.166:8008 --profile snowball
"State": "AVAILABLE",
"Description": "Image for building EC2 compute instance",
"ImageId": "s.ami-8e275321926f0830e"
- Launch the Athonet 4G/5G Core EC2 instance
# aws ec2 run-instances --image-id s.ami-8e275321926f0830e --endpoint http://172.17.4.166:8008 --instance-type sbe-c.8xlarge --profile martin --user-data file://user-data.json
{
"Instances": [
{
"SourceDestCheck": false,
"InstanceId": " s.ami-8e275321926f0830e",
"EnaSupport": false,
--lines removed --
Where the user-data.json is the hostname provided to the Athonet 4G/5G Core system and later used for licensing of the system, the format of the user-data.json file is as follows, and the hostname can be obtained from xyz.
{ "hostname": "000z000000y0" }
- Associate the previously defined virtual-interface addresses:
aws ec2 associate-address --public-ip 172.17.4.172 --instance-id s.i-849b50eb6fa003f56 --endpoint http://172.17.4.166:8008 --profile snowball
- The Athonet 4G/5G UI is now available via the virtual interface address:
Figure 4 – Athonet login page
Step 5: Video Analytics Dashboard
Megh VAS 100 is a complete, end-to-end video analytics solution that offers high performance and low latency. The software includes an easy-to-use web-based dashboard for visualizing the valuable insights and analytics that the Megh platform extracts from the supplied video input.
Create new instance
Using AWS OpsHub, navigate to the Compute page and select the orange Launch Instance button in the bottom right corner.
Figure 5 -AWS opshub , creation of a new instance
Choose the AMI that was preloaded on the Snowball Edge, or the AMI that was sideloaded during Step 4. Pick the sbe-c.8xlarge instance type for best performance and utilization of the Snowball Edge , we need to take into consideration that in case Both the Athonet 5g core and Megh application are running on the same Snowball edge , we need to make sure that we are allocating sufficient resources also for the core itself . Choose the Create public IP address option if this is the first time using the Snowball Edge and there are no existing IP addresses created on the device, otherwise choose Use existing IP address and select the desired one.
Figure 6-launch instance page
After launching the instance, AWS OpsHub will display the new instance in the Instances list, and a public IP address will be assigned to the instance. This IP address is “public” from the perspective of the Snowball Edge; it is not a public IP address on the internet.
Figure 7 – instances list
Log in to instance
Use an SSH-enabled computer on the same network as the Snowball Edge to connect to the running Megh instance using the SSH login key that was created when the AMI was configured in Step 1. The login username on the Megh AMI is “ubuntu.” Make sure to connect to the public IP address of the instance, not the device IP address.
Figure 8 – login to snowball edge via SSH
Start Megh application
Navigate into the directory named “VAS100” and run the start.sh script:
Figure 9 – runtime of the start.sh script
Open a web browser to view the dashboard
Navigate to the public IP address of the Megh application using a web browser to view the login page of the dashboard. The browser will report the page as “Not secure” because the dashboard is being served over normal HTTP (port 80). However, this is not an issue if the network itself is secured and trusted.
Figure 10 – Megh application login page
If this is the first time running the Megh application, the customer must register to create a user on the platform. This registration information is all stored locally on the Snowball Edge.
Figure 11 – Megh application registration page
After logging in, the customer can view the selection of use cases available and which ones have active channels running.
Figure 12 – Megh Application use cases page
Physical Distancing use-case example:
Figure 13 – Physical distancing use case
Intrusion Detection use-case example:
Figure 14– Intrusion Detection use case
Configure Megh application with live cameras
The Megh application includes canned sample videos out of the box for demonstration purposes. The input video sources can be changed to use live IP cameras by making changes to a JSON configuration file. Follow the release notes for how to make these changes.
Conclusion
In this AWS blog post we showcased what can be achieved with AWS snowball edge leveraging the AWS partner ecosystem , using Athonet 4G/5G core and Megh VAS for real time analytics.
One AWS customer who have recently launched a proof of concept for 5G private networks ,is Telenor Thailand(DTAC) who is addressing use-cases, such as personal protective equipment (PPE) Compliance, Intrusion Detection, People Occupancy and Physical Distancing , by using the AWS snowball in points of entry like airports as an example.
You can visit the following websites for additional information :
Athonet BubbleCloud on the AWS marketplace
Megh VAS-100 on the AWS marketplace
Related resource:
Reliable wireless networks