Add eNB TR-069 Support

enodebd Overview

The enodebd service is responsible for any TR-069 management of eNodeB devices. As such, you’ll only need to modify enodebd to add support for a new eNB.

At a high level, enodebd brings up a server, the tr069_server, and when the tr069_server receives an HTTP request, it translates the contained SOAP message into the corresponding model representing the message, eg. Inform, GetParameterRequest, etc. It takes the message, and passes it on to the StateMachineManager.

The StateMachineManager, as the name implies, manages different state machines. One state machine is used for each eNB that the Magma AGW is managing. Using the IP of the HTTP request, the StateMachineManager routes the request to the correct state machine (also called ‘Handler’).

Each EnodebAcsStateMachine contains a representation of the configuration that we believe the eNB has. It also contains the configuration that we desire to set on it. These are labeled as the ‘device configuration’ and ‘desired configuration’. Each state machine will attempt to configure its corresponding eNB to the desired configuration.

Configuration through TR-069 is done in the ‘Provisioning Session’. The state machine has a state for each step of the provisioning session, each with its own logic for how to process the incoming TR-069 message, and how to construct the TR-069 response. Most of these states are in enodebd/state_machines/enb_acs_states.py, since the provisioning session happens nearly the same way for most devices. There are differences though, and so there is a different state machine for each supported eNB device model, which can be found under enodebd/devices.

Adding an eNB

To add TR-069 support, the TR-069 data model is needed for the device, as well as the hardware model, and software version. A new state machine should be created under enodebd/devices.

For the data model, the same parameter will have different paths for different devices, and may even have its value formatted differently. For these formatting differences, the ‘transform’ functions should be added to transform the parameter value from the formatting that the eNB uses, to the common formatting that Magma enodebd understands, and vice-versa.

For constructing the desired-configuration of the eNB, there will be differences between devices. Attach a EnodebConfigurationPostProcessor to the eNB state machine, and add any logic for modifying the desired-configuration beyond the defaults that enodebd already does.

The provisioning session can occur a little different for each eNB. The state map attached to each state machine lets you customize the state machine for differences between devices. Some devices require rebooting for parameter changes to take effect, for example. You can add/remove behavior through this map, and also add custom states.

An example pull request for adding an eNB

Testing

Make sure that the eNB is configured to reach out to baiomc.cloudapp.net:48080, so that Magma’s DNS hijacking works, and routes TR-069 messages through iptables to enodebd’s TR-069 server. Debugging can most easily be done with tcpdump, and then viewing the SOAP messages through Wireshark.

Magma's dnsd service configures dnsmasq for DNS hijacking. See: dnsd.yml. You can modify dnsd.yml and restart the service for further configuration.