Skip to main content

5G Hotspot Requirements

info

This document is the Hardware Audit procedure for 5G/CBRS Hotspots which have a FreedomFi whitelabel.

Certification Process​

Certification will require two steps, both performed by the Manufacturing Compliance Committee ("MCC").

  1. Functional Certification.
  2. System Certification.

Audit Process​

  • Indoor and Outdoor Hotspots arriving together will be audited together.
  • Indoor and Outdoor Hotspots arriving more than 2 weeks apart will be audited separately.
  • Re-audit (such as change in model) required only if any of the following:
    • CPU changes.
    • RAM decreases.
    • Storage decreases.
    • Change in radio.
    • Change in security element.
    • Change in any parameter that requires regulatory recertification.

Functional Certification​

Section 1: Hardware Unboxing and Review​

  • Provide directions for how to change Orc8r to FreedomFi's Orc8r or give Foundation ssh access.
  • Record date of audit.
  • Record Model name and serial number.
  • Link to vendor provided documentation.
  • Link to HIP-19 proposal on Github.
  • Link to Vendor website.
  • List expected certifications (for CBRS, only FCC is relevant).
  • Check antenna connector, must be reverse SMA.
  • Unbox hardware and list what has been received (number received, Indoor/Outdoor).
  • Record block diagram of system including the secure boot hardware:
    • The diagrams should include all the hardware involved in the boot process and the security boundaries of each component.
    • Hardware items to illustrate include (but are not limited to):
      • Cryptographic hardware accelerator
      • Secure storage for private/secret and public keys
      • Secure RAM
      • Boot ROM
      • Untrusted external RAM
      • Untrusted external non-volatile storage (eMMC, SATA, etc)
      • Communication busses
    • The diagram must also show the security boundaries of your design. Group each component and bus by the boundary it resides in.
    • Image of PCB with secure security element clearly outlined

Section 2: Hardware Specifications​

  • Does the hardware meet the specifications.
  • Is the hardware the same in the HIP-19 application and on the manufacturer's website as what was sent for the audit?
  • Auditor may run one or more of the following to check hardware:
    • Inspect CPU: cat /proc/cpuinfo
    • Check memory: free --mega
    • Check storage: lsblk

Section 3: Verify Secure Element Configuration​

Purpose of this section is to verify that the key is secure

  • Check firmware version is up to date: sudo docker exec helium_miner_1 miner versions
    • NOTE: In FreedomFi’s firmware, it is necessary to keep the miner image running when attempting to rungateway_mfr. This is because the miner image has a helper daemon that gateway_mfr needs to contact in order to “talk” to the TPM.
  • Query the Miner for its working keys/ verify that private and public are the same: sudo docker exec helium_miner_1 miner print_keys
  • Download the Miner from Helium's repo
  • Query the TPM for its keys: docker exec helium_miner_1 /gateway_mfr --device "tpm://tpm/HS/SRK/MinerKey" test to verify keys match.

Section 4: RF Verification​

  • Verify Manufacturue has RF Verification.
  • Check US915 configuration file.

System Certification​

Section 5: UE Connection To Network​

Telecom Acronym

User Equipment ("UE") refers to any device capable of connecting to the Internet, such as a phone, tablet or computer.

  • Connect a UE Device to the CBRS network and perform activity such as downloading photos, sending emails, and chat using Discord while using the 5G network.
    • Does the UE connect to the network and able to use it?
  • Verify that the UE is connected to the correct network by matching the IMSI and IP address: mobility_cli.py get_subscriber_table
    • Is the UE connected to the expected network?
  • Verify that the UE is connected to the correct radio by matching the EARFCN and CI:sudo cat /var/opt/magma/configs/gateway.mconfig
    • Check the "enodebd" section for "cellId" and "earfcndl" numbers and compare them to the numbers in Carrier Lab Dashboard (app for iOS) and/or About Phone in Android.
    • Is the UE connected to the expected radio and do the EARFCN and CI match?
  • Verify attach-detach with service request for single UE, can a single UE attach and detach from the network?
    • Using wireshark: ssh support@IP_ADDDRESS sudo tcpdump -i enodebr0 -U -s0 -w - 'not tcp port 22' | /Applications/Wireshark.app/Contents/MacOS/Wireshark -k -i - filter on sctp and put the UE in airplane mode, toggle and look for detach request
    • Is the UE able to leave and rejoin the network

Section 6: Federation Gateway (FeG) and Magma connection​

  • Verify that traffic is flowing through Magma rather than locally by sniffing traffic between radio and AGW where GTP traffic is encapsulated.
    • Are source and destination IP showing 2-way traffic? Is there GTP traffic present?
  • Verify that traffic is flowing through the Foundation hosted Federation Gateway by looking at messages that show that the UE's SIM card is getting checked by the Foundation's HSS.
    • Is the public IP of the Foundation hosted FeG present? Is the UE SIM card pointing at the Foundation HSS?

Section 7: UDP/ TCP traffic​

  • Verify attach to network with uplink UDP data and then detach from network to show traffic flowing inside of the GTP tunnel.
    • Traffic flows from the UE to Google's DNS using UDP.
    • Use Wireshark while browsing internet and filter on udp.dstport == 53.
    • Is traffic present in the GTP tunnel in 8.8.8.8.?
  • Verify attach to network with uplink TCP data and then detach from network to show traffic flowing inside of the GTP tunnel.
    • Traffic flows from the UE to Google's DNS using TCP.
    • Use Wireshark while browsing internet and filter on TCP.
    • Is traffic present in the GTP tunnel?

Section 8: UE Failure​

  • Verify attach/ detach for two UEs
    • Put 2 UEs into airplane mode and reconnect to internet in and out of airplane mode.
    • Use Wireshark and filter on sctp.
    • Is attach/ detach messaging present?
  • Verify radio link failure for single or many UEs.
    • Toggle airplane mode on UE, then leave it attached to the network (not in airplane mode) and place it in a Faraday cage.
    • This may be verified by using Wireshark and look for GUTI cleared/ IMEI cleared.
    • This may also be verified by looking at the subscriber data with the timestamp before and after mobility_cli.py get_subscriber_table;date
    • Does UE detach from network in simulated failure mode?