= 5G/NextG =
Team: Jeff Acevedo | Stanislav Ceman | Ryan Lin | Sreeram Mandava | Aleksa Samardzija | Nikhil Sampath | Sanskar Shah | Steve Shin | Xoua Thao

Advisors: Ivan Seskar | N.K. Shankaranarayanan
== Project Objectives 
The ultimate goal of the project is to develop an open-source implementation of a 5G system. Specific tasks included implementing an end-to-end session of the system from user equipment to the internet, and developing network control and management applications. All work was done in the context of Open RAN (O-RAN), which seeks to create a more disaggregated and flexible architecture of the traditional radio access network (RAN). A diagram displaying the basic O-RAN architecture is shown below.
[[Image(5G_NextG Week 9.png, 500px)]]

A central aspect of the project was developing applications (rApps) and framework services in the Service Management and Orchestration (SMO) framework. The three rApps developed by the team were the Security rApp, Resilience rApp, and !Frequency/Spectrum management rApp. Functions of the framework services included topology maintenance, topology visualization, alarm generation, and spectrum sensing. A block diagram and sequence diagram detailing the layout and dataflow of the SMO framework are shown below. All communication between the different functions are through the ORBIT amqp server using the RabbitMQ message-brokering software.
[[Image(AMQP Diagram (3).png, 500px)]]
[[Image(SystemSequenceDiagram_v3.png, 1000px)]]
=== Topology Scenario
To understand and convey the use of the applications and framework services, the group developed a realistic situation in which the work would apply. Say there is a straight-line road running east-west. An example of such a road is shown below, at latitude 38.892 (Washington D.C.).
[[Image(TopologyStoryImage.png, 1000)]]

UEs, such as cell phones, and RUs could be distributed along the road. There is an assumption that UEs can only connect to a particular RU when the distance is within a certain threshold. The ultimate purpose of the applications is to maintain constant connectivity for a dynamic or static UE along this road. If a UE is connected to multiple paths, connectivity can still be maintained as a UE moves along the road. If one connected RU becomes out of range, the UE will connect to another in-range RU. The existence of multiple paths also ensures connectivity if one path becomes compromised. The compromised path will be shut down and the data will be transmitted through one of the alternative paths connected to that UE. Additionally, the transmission of data can be optimized among the paths. As detailed below, all of these functions are handled by the SMO. 


=== Weekly Slides
Week 1: https://docs.google.com/presentation/d/12tB8qu7PKzh8Vf91PTPGVp_zUQDTg3FHjTDCSrbz3OU/edit?usp=sharing

Week 2:
https://docs.google.com/presentation/d/1BG-Ic3cOMBmDDZqHKv0XwhQrPxmHiZBA1T47vDEJ4ic/edit?usp=sharing

Week 3: 
https://docs.google.com/presentation/d/1ki9sL52asnUo6WTF8jv6MEudg8ONSFogNYiSJHvBZ4U/edit?usp=sharing

Week 4: 
https://docs.google.com/presentation/d/1G3B79Km7aUUF_xqcfx2OCIzeoE0pBuLZj6MlBGVAii8/edit?usp=sharing

Week 5:
https://docs.google.com/presentation/d/1OS8VFtsQ5ILXReiLvHyejSO0vgwyX_5eUyWc2-GP_84/edit?usp=sharing

Week 6:
https://docs.google.com/presentation/d/1rORzg2HuLZ9SxoOVcGMePYcQY3u_tkATb7bNcjwagXI/edit?usp=sharing

Week 7:
https://docs.google.com/presentation/d/1GB9vG1cwhJmrmIPBrwt6um108A3Dv3bwhitFh3CY5f8/edit?usp=sharing

Week 8:
https://docs.google.com/presentation/d/1edx007kB5G_o_x5JgZPQ-HRJM-ZRZyGK-N0pWfACPFA/edit?usp=sharing

Week 9:
https://docs.google.com/presentation/d/1c6ID0c8H2XI0_f_ypQehksXWcXTJUp20SNDlI2dtnMU/edit?usp=sharing
== Radio System Implementation ==
=== Amarisoft
=== !OpenAirInterface
== SMO Framework Services and Applications
=== Topology Service
The topology service maintains updated network topology information. In this model, the topology service receives a json file describing the full topology of the system. The topology service then publishes the topology initialization to the amqp server, and subsequently, the rApps receive initialize their topology information. When a change in topology occurs (due to a security issue), the change goes through the topology service. When the rApps need to update their topology, the process the update from the topology service.

The topology service also has topology visualization capabilities. The group experimented with visualization methods including the Python NetworkX library and the !JavaScript D3 library. 

=== Security rApp
The Security rApp provides closed-loop control in the SMO. This means that the network would be automatically configured based on changes. The rApp receives security alarms from the RAN network, simulated by an alarm generator. The application then assesses the severity of the alarm, and generates a corresponding response command. The command may be to disable a compromised node, and all of its children nodes as well. The configuration change is sent to a controller for execution. The command would also be forwarded to the topology service, which would update the topology information for the rApps to read.

=== Resilience rApp
One method of increasing the resilience and efficiency of a RAN system is to have a single UE device connected to two RAN networks. Using the two networks, the data transmission can be optimized for speed, efficiency, and security. Additionally, if one of the networks were to be compromised, connectivity can be maintained through the other network. All nodes are tagged with attributes including cost and security. A drawing of the system is shown below. Upon updating based on changes in topology, the resilience rApp outputs a different distribution of data among the existing paths to a UE. 
=== Spectrum Management rApp
The spectrum is a limited resource, thus it is essential to manage the topology across the available frequency channels. 
Using Spectrum Sensing allows for monitoring the frequency channel occupancy. Multiple methods are available for such action, one of them being energy detection. This method includes measuring the energy of the whole spectrum , and comparing every value of the spectrum with a threshold value. If the value is above threshold, we can estimate the channel as occupied.The algorithm was developed through GNURadio, while the measurements were completed by Universal Software Radio Peripheral ( USRP). 


[[Image(output_plot.jpg, 300)]]

Through the rApp, the RUs are distributed according to the available channels. This is done by continuously rearranging the .json topology file, and sending the updated version (delta) through a message queueing protocol (AMQP). These data can further be read and utilized for other rApps.