# BNS: A Framework for Wireless Body Area Network Realistic Simulations
## 3 Proposed BNS Framework
### Mac Layer  
The BNS framework MAC Layer implementation extends the draft version available in Castalia to meet the requirements of the frame format of the IEEE 802.15.6 standard published in 2012. In the BNS framework MAC Layer, we added features such as: storing the list of neighboring nodes and some metrics of communication between neighbors; the possibility of encapsulating frames and using nodes as relay; prioritization of traffic when using Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) medium access method; and the adjustment of allocation times, channel assessment and other temporal parameters to follow those recommended by IEEE 802.15.6 NB-PHY. The changes in the frame header fields were as follows:  
Figure 2: Goswami channel class implemented in the BNS framework. The character ”*” refers to pointer-type variable. * Changing the structure of source and destination fields. The draft version of the standard did not provide the possibility of communication between network nodes, and was restricted to the node/hub communication. Therefore, in the implementation provided in the simulator there were only two markers, one for the address of the hub (_Hub ID_) and one for the address of the _Node ID_ node, which were used to identify the hub and node in the communication indiscriminately whether source or destination. To enable the communication between different nodes, those two fields were replaced by the three used in the standard header: _Recipient ID_, _Sender ID_ and _BAN ID_. In this way, it is possible to identify the message source and destination in a BAN, and permits node/node communication. * Inclusion of the _BAN Security/Relay_ field. The _BAN Security/Relay_ field is a flag that, if used by the hub, defines whether the BAN accepts only secure connections or also accepts insecure ones, features that are not implemented in the simulator. However, when used by network nodes, the field is interpreted as a relay flag, marking an extended topology frame. Within the scope of this work, other implementations were made that allow the use of the field as relay flag. * Inclusion of other fields. For the header to have the size and all fields specified in the standard, the fields _Last Frame/Access Mode/B2_ and _Non-final Fragment/Cancel/Scale/ Inactive_ were also inserted, but without the implementation of its functionalities. To enable the use of the relay functionality, in addition to the _BAN Security/Relay_ field, the framework subtypes _Relay Request_, _Relay Accept_ and _Relay Refuse_ were also implemented, and methods for encapsulating and decapsulating frames. Thus, it is possible to investigate the use of the extended topology in future work. To enable the monitoring of neighboring nodes, a class structure was created to store their information. The created classes are represented in the diagram of Figure 3.  
With this new class structure, it is possible to store information about neighboring nodes, such as their address, whether they can be used as relay, if the node is a hub and  
Figure 3: Class diagram for the IEEE 802.15.6 MAC module implemented in the BNS framework. in addition to two vectors of _size_ store the instant of the last contacts and the RSSI of the received frames. In addition to this node information, a neighborhood structure makes it possible to verify this stored information through a map that uses the address as a key and for the functions of relay an attribute called _selector_, which makes it possible to use different criteria for selecting a relay node, which can be done by a neighbor with a better RSSI or with the most recent contact. In addition to those modifications, the random-access priority level was implemented and available in the BNS framework. The IEEE 802.1p classes of services are used, and each class has a contention window interval, defined by the IEEE 802.15.6 standard.