Implementing mechanisms to improve the performance of LTE-WLAN Aggregation

IMPLEMENTING MECHANISMS TO IMPROVE THE PERFORMANCE OF LTE-WLAN AGGREGATION A Master’s Thesis Submitted to the Faculty of the Escola T` ecnica Superior d’Enginyeria de Telecomunicaci´ o de Barcelona Universitat Polit` ecnica de Catalunya by Mag´ı Coscollola Coletes In partial fulfilment of the requirements for the degree of MASTER IN TELECOMMUNICATIONS ENGINEERING Advisors: Klaus Moessner (University of Surrey) and Oriol Sallent Roig (UPC) Barcelona, September 2017 Title of the thesis: Implementing mechanisms to improve the performance of LTEWLAN Aggregation Author: Mag´ ı Coscollola Coletes Advisors: Klaus Moessner, Oriol Sallent Roig Abstract: As the release of 5G gets closer, different technologies appear aiming to make a difference in this next generation of mobile communications. A proposed way to achieve more capacity for end-users in 5G is aggregating Long Term Evolution (LTE) and Wireless Local Area Network (WLAN), and allowing users to connect to both at the same time. There are different technologies that aggregate LTE and WLAN, but in this project we focus only on one: LTE-WLAN Aggregation (LWA). In this thesis we study how offloading WLAN beacons to LTE can improve its performance due to the higher efficiency that LTE brings. This offloading allows to remove overhead from WiFi and UEs using LWA can achieve higher capacities. This investigation has been performed using OpenAirInterface, a software tool used to simulate and emulate LTE networks. 1 Acknowledgements I would like to thank both my thesis supervisors, Klaus Moessner and Oriol Sallent, for their help and support during the development of the project. I would also like to thank the people I met at University of Surrey, especially Marcin Filo, Atm Shafiul Alam and Faouzi Bouali for their advice and help during my stay at the 5GIC. 2 Revision history and approval record Revision Date Purpose 0 15/05/2017 Document creation 1 05/07/2017 Document revision 2 14/08/2017 Document revision 3 21/08/2017 Document revision Written by: Reviewed and approved by: Date 01/09/2017 Date 04/09/2017 Name Mag´ ı Coscollola Coletes Name Oriol Sallent Roig Position Project author Position Project supervisor 3 Contents Abstract 1 Acknowledgements 2 Revision history and approval record 3 Table of contents 5 List of figures 6 List of tables 7 List of code listings 8 1 Introduction 9 1.1 Objectives...................................... 10 1.2 Thesisoutline.................................... 11 1.3 Workplan...................................... 11 2 State of the art 13 2.1 LTE ......................................... 13 2.1.1 System Information Blocks in LTE . . . . . . . . . . . . . . . . . . . . 13 2.1.2 UE attachment and DRB assignment in LTE . . . . . . . . . . . . . . . 16 2.2 IEEE802.11 .................................... 19 2.2.1 CSMA/CA.................................. 21 2.2.2 Beaconframes............................... 21 2.3 LTE-WLANAggregation.............................. 22 2.3.1 LWAArchitecture.............................. 23 2.3.2 LWA Configuration message . . . . . . . . . . . . . . . . . . . . . . . 26 2.3.3 Discussion ................................. 26 2.4 OpenAirInterface.................................. 26 2.5 ns-3 ......................................... 28 2.6 Discussion ..................................... 28 3 Project development 29 3.1 Installation of OAI and bug corrections . . . . . . . . . . . . . . . . . . . . . . 29 3.1.1 MSCtranslator............................... 29 3.2 AddingSIBX.................................... 32 3.2.1 SIBXcontents............................... 32 3.2.2 Creating SIB X using ASN.1 . . . . . . . . . . . . . . . . . . . . . . . 32 3.2.3 SendingSIBX ............................... 34 3.2.4 ReceivingSIBX .............................. 35 3.3 Notifying the UEs about SIB X . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.3.1 Deciding how to notify . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.3.2 Creating new RRC Connection Reconfiguration message . . . . . . . 37 3.4 Implementing LWA Configuration message . . . . . . . . . . . . . . . . . . . 40 3.4.1 eNBside .................................. 40 4 3.4.2 UEside................................... 41 3.5 Selectingthescenario............................... 41 3.6 Theoretical calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.7 ns-3simulations .................................. 45 4 Results 47 4.1 IEEE 802.11 ns-3 simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.2 LTE with OpenAirInterface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 5 Budget 50 6 Conclusions and future development 51 Bibliography 53 Appendices 55 A Installation of OAI 55 A.1 Systemrequirements ............................... 55 A.1.1 Installation of a Linux Image in VMWare . . . . . . . . . . . . . . . . . 55 A.2 Downloadofthefiles................................ 56 A.3 Installation of the required Linux kernels . . . . . . . . . . . . . . . . . . . . . 57 A.3.1 Linux Kernel 3.19 Low Latency . . . . . . . . . . . . . . . . . . . . . . 57 A.3.2 LinuxKernel4.7 .............................. 58 A.4 Installation of Openair5G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 A.5 Installation of OpenairCN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 A.5.1 Installation of LAMP (Linux, Apache, MySQL and PHP . . . . . . . . . 61 A.5.2 InstallationofHSS............................. 65 A.5.3 InstallationofMME............................. 66 A.5.4 Installation of SPGW . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 A.6 FirstrunofOpenairCN............................... 69 A.6.1 RunningMME ............................... 70 A.6.2 RunningSPGW .............................. 70 A.7 FirstrunofOpenair5G............................... 71 A.7.1 Runningoaisim............................... 71 B MSC Translator 73 C Beacon contents 75 D LWA Configuration message contents 80 Glossary 81 5 List of Figures 1.1 Gantt diagram of the work plan. (1) . . . . . . . . . . . . . . . . . . . . . . . . 12 1.2 Gantt diagram of the work plan. (2) . . . . . . . . . . . . . . . . . . . . . . . . 12 2.1 Summary of Initial Attach procedures [10]. . . . . . . . . . . . . . . . . . . . . 17 2.2 Procedure for EPS Session Establishment (1) [10]. . . . . . . . . . . . . . . . 18 2.3 Procedure for EPS Session Establishment (2) [10]. . . . . . . . . . . . . . . . 19 2.4 LWA network architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.5 LWA user plane architecture. [20] . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.6 OpenAirInterface structure showing the interfaces that connect each module. 27 2.7 OpenAirInterface LTE software stack [4]. . . . . . . . . . . . . . . . . . . . . . 27 3.1 Example of oaisim MSCoutput........................... 30 3.2 Example of translated MSC output (compatible with Mscgen).......... 31 3.3 Example of MSC generated by Mscgen...................... 31 3.4 Example of a hexagonal BSS layout [14]. . . . . . . . . . . . . . . . . . . . . 43 3.5 Example of a hexagonal BSS layout with reuse 3. . . . . . . . . . . . . . . . . 43 3.6 IEEE 802.11n management frame structure [15]. . . . . . . . . . . . . . . . . 44 4.1 Results of the simulation with 85 APs and 1 STA. . . . . . . . . . . . . . . . . 48 4.2 Results of the simulation with 85 APs and 85 STAs. . . . . . . . . . . . . . . . 49 A.1 Synaptic Package Manager screenshot. . . . . . . . . . . . . . . . . . . . . . 57 A.2 Organisation diagram of OpenairCN . . . . . . . . . . . . . . . . . . . . . . . 60 A.3 Apache2defaultpage ............................... 61 A.4 Example of info.php................................. 63 A.5 Example of phpMyAdmin log in page. . . . . . . . . . . . . . . . . . . . . . . 64 A.6 mmeidentity table. ................................. 69 A.7 Example of terminal when running HSS. . . . . . . . . . . . . . . . . . . . . . 70 A.8 Example MME terminal output when the Access Network is running. . . . . . 72 6 List of Tables 3.1 ContentsofSIBX. ................................. 32 5.1 Cost of software and hardware components. . . . . . . . . . . . . . . . . . . 50 7 (broadcasted to all User Equipments (UEs)) that comes from superior layers -Non Access Stratum (NAS). This information is applicable when the UE is on ”idle” mode. SIBs are transmitted by means of the Radio Resource Control (RRC) protocol, which is the one in charge of controlling the behaviour of the UEs when it is on ”connected” mode and sends paging messages and broadcasts SIBs to the UEs that are on ”idle” mode [2]. This system is formed by the different kinds of SIB listed below [1] [2]: •Master Information Block (MIB). Transmitted every 40 ms using the Physical Broadcast Channel (PBCH) and appears on the subframe number 0. It transmits fundamental parameters of the network to allow the initial access of the UEs, e.g. used channels, number of transmitting antennas on the Evolved Node B (eNB) side, the frame number, etc. •SIB Type 1. Transmitted every 80 ms using the Physical Downlink Shared Channel (PDSCH) and appears in the subframe number 5. This SIB transmits information related to the access to the cell and resource assignment information, e.g. Public Land Mobile Network (PLMN) identity, location area, cell identity, scheduling of the other SIBs, etc. •SIB Type 2. Broadcasted with a periodicity of 160 ms and used to inform the UEs about the configuration of the common and shared channels, random access parameters, bandwidth, uplink (UL) power control parameters, etc. •SIB Type 3. Transmitted with a periodicity of 320 ms and used to inform the UEs about common parameters related to the cell reselection mechanisms. •SIB Type 4. Transmitted every 320 ms and used to inform the UEs about parameters related to the configuration of the neighbouring cells that use the same sub-carriers (intra-frequency cell reselection information). This information is useful for future handover measurements. •SIB Type 5. Has a periodicity of 640 ms. It is also used to inform the UEs about neighbouring cells, but in this case it informs about the neighbours that use different sub-carriers (inter-frequency cell reselection information). Again, this information is used so the UEs can perform measurements to support handover procedures. •SIB Type 6. Transmitted every 640 ms and used to give support to the mechanisms that perform cell reselection to UMTS Terrestrial Radio Access Network (UTRAN) cells. •SIB Type 7. Transmitted every 640 ms and used to give support to the mechanisms that perform cell reselection to GSM EDGE Radio Access Network (GERAN) cells. •SIB Type 8. Broadcasted with a periodicity of 640 ms and used to give support to the mechanisms that perform cell reselection to CDMA2000 cells. •SIB Type 9. Has a periodicity of 640 ms and contains the eNB identifier, which has a maximum size of 48 B. It allows the UEs to manually select the eNB they want to connect to. •SIB Type 10. Contains Earthquake and Tsunami Warning System (ETWS) notifications. 14 •SIB Type 11. Contains complementary ETWS notifications. •SIB Type 12. Contains Commercial Mobile Alert System (CMAS) notifications. •SIB Type 13. Contains the information required to acquire the MBMS control information associated with one or more Multicast-Broadcast Single Frequency Network (MBSFN) areas. •SIB Type 14. Contains the Extended Access Barring (EAB) parameters. •SIB Type 15. Contains the MBMS Service Area Identifier (SAI) of the current and/or neighbouring carrier frequencies. •SIB Type 16. Contains information related to GPS time and Coordinated Universal Time (UTC). The UE may use these parameters to obtain the UTC, the GPS and the local time. •SIB Type 17. Contains information relevant for traffic steering between Evolved UTRAN (E-UTRAN) and WLAN. •SIB Type 18. Indicates that E-UTRAN supports the sidelink UE information procedure and may contain resource configuration information related to sidelink communication. •SIB Type 19. Indicates that E-UTRAN supports the sidelink UE information procedure and may contain resource configuration information related to sidelink discovery. •SIB Type 20. Contains the information required to acquire the control information associated transmission of MBMS using Single Cell Point To Multipoint (SC-PTM). •SIB Type 21. Contains Vehicle-To-Everything (V2X) sidelink communication configuration. In LTE, only MIB, SIB1 and SIB2 provide the minimum required information in order to allow UEs to connect to the network, so it is mandatory that they are transmitted in any cell [19]. The different SIBs are mapped to the SI messages, which are transmitted using Physical Resource Blocks (PRBs) of the PDSCH. SIB1 is always mapped to SI1 and SIB2 is also always mapped to SI2. The remaining SIBs can be multiplexed between themselves if they have the same periodicity. As an example, SIB3, SIB4 and SIB5 could be multiplexed to only one SI with a periodicity of 320 ms. 2.1.1.1. Notification of changes in SIBs Even though SIBs’ information is quite static, it may suffer changes over time because the configuration of the eNB or the neighbouring eNBs has changed. For example, if a new SIB is started to broadcast the SIB mapping field in SIB1 will change, so it will be necessary to notify the existing UEs that are connected to the eNB that there has been a modification in a SIB. These changes need to be notified to the UEs of the network so they can update their knowledge about the cell. If the UEs are not notified about a change, they will automatically update their SIB information after 3h of obtaining it, as they will consider the old information invalid. 15 There are a couple of mechanisms in order to notify of this information update: the systemInfoValueTag in SIB1 and the systemInfoModification field in the paging messages. systemInfoValueTag is a field in SIB1 that tells if changes have been done in other SIBs. Every time a change is made this tag is increased by one. UEs may use this tag to verify if the previously stored SI messages are still valid, e.g. when returning from out of coverage. This tag, however, may not be always updated. E-UTRAN may not update it after changing some system information (e.g. ETWS information), regularly changing parameters like time information or EAB parameters [3]. Paging messages are used to inform UEs in RRC IDLE and RRC CONNECTED mode about a system information change. If the UE receives a paging message including the systemInfoModification it knows that the system information will change at the next modification period boundary. This message is used to tell UEs that there are going to be changes in the SI, but it does not provide further details, so the UE does not know which system information will change. Modification periods are defined by the scheduling of system information, and SI may be transmitted several times with the same content within a modification period. The boundaries of modification periods are defined by System Frame Number (SFN) values for which SFN mod m= 0, where mis the number of radio frames comprising the modification period. The modification period is transmitted by SIB2 using the fields modificationPeriodCoeff and defaultPagingCycle. The length of a modification period corresponds to modificationPeriodCoeff times defaultPagingCycle frames. 2.1.2. UE attachment and DRB assignment in LTE It is necessary to explain this procedure because it was used as a trigger in OAI for sending a message that told the UEs to listen to our newly created SIB -SIBXor not. We are going to look into the case where a UE is turned on and attempts to attach to a network for the first time after subscribing to the LTE network, but, in order to simplify, we are only going to focus on the last part of this procedure (step 5 in Figure 2.1), where the Dedicated Radio Bearer (DRB) assignment is performed. In the first step of the Initial Attach procedure the Mobility Management Entity (MME) obtains an International Mobile Subscriber Identity (IMSI) from the UE. The UE attempts to initially attach to the network by sending an Attach Request message containing its IMSI, so the MME obtains it from this message. After collecting the UE’s IMSI and security capability information, from the Attach Request message received from the UE, the MME performs the authentication and NAS security setup procedures (2 and 3 in Figure 2.1). The authentication procedure consists of two steps: authentication vector acquisition, where the MME requires authentication vectors from the Home Subscriber Server (HSS) for the UE, and mutual authentication, during which the MME and the UE are mutually authenticated. 16 Figure 2.1: Summary of Initial Attach procedures [10]. Once the UE and MME are mutually authenticated, the procedure for establishing NAS security begins. The MME initiates the NAS security setup procedure so that NAS messages can be securely exchanged between itself and the UE. Once the procedures for authentication and NAS security setup are completed, the MME has to register the subscriber in the network and find out what service are available for them. Here, the MME notifies the HSS that the subscriber is registered in the network and located in its Tracking Areas (TAs) and then downloads information about the subscriber from the HSS. This is done through the location update procedure (Step 4 in Figure 2.1). After that, the MME establishes an Evolved Packet System (EPS) session and a default EPS bearer for the user based on the subscription information. By doing so, the MME allocates the resources for providing each user with a Quality of Service (QoS) satisfying what they are subscribed to. We can see this detailed procedure in Figures 2.2 and 2.3. As we can see in Figure 2.2, the MME first selects an EPS Bearer ID (a number between 5 and 15) in order to establish a default EPS bearer for the newly attached user. After that, the MME selects the PDN Gateway (P-GW) based on the subscription information received from the HSS. Next, a ”create Evolved Packet Core (EPC) session request” is sent by the MME and it is established once the MME has received a ”create EPC session response”. With this response, the P-GW informs the MME that the resources had been approved and allocated to the user and also the QoS information applied to the established EPS sessions and default EPS bearer. Once this procedure is finished with the creation of the UL S1 GTP-U tunnel, the MME returns an ”Attach Accept” message to the UE as a response to the ”Attach Request” it had sent before (seen in Figure 2.3), so at this point the UE is attached to the network. At this point the MME creates the Access Stratum (AS) security base key, KeN B , which the 17 Figure 2.2: Procedure for EPS Session Establishment (1) [10]. AS security base key and is included in the ”Initial Context Setup Request” message that is sent afterwards to the eNB so that it can establish a S1 bearer with the Serving Gateway (S-GW) and a DRB with the UE. Next, the AS security is set up. The eNB generates AS security keys from KeN B received from the MME and selects the ciphering and integrity algorithms for RRC messages and user traffic between itself and the UE. The eNB also helps the UE to generate AS security keys by informing it about the chosen AS security algorithms through a ”Security Mode Command” message. When the AS keys are completely generated and ready to work the UE indicates it to the eNB sending a ”Security Mode Complete” message. As the AS security setup is now completed, RRC messages over the radio link are now sent as encrypted and integrityprotected, and user traffic is delivered as encrypted. Now, the DRB establishment can begin. The DRB establishment begins with a ”RRC Connection Reconfiguration” message from the eNB to the UE. The RRC connection was already established when the UE sent the ”Attach Request” message. However, it must be reconfigured now that the UE needs to configure parameters according to the resources allocated by the network as a result of permission to access it. The RRC layer of the UE allocates radio resources based on the configuration parameters gathered from the ”RRC Connection Reconfiguration” message and it replies with a ”RRC Connection Reconfiguration Complete” message. Now the DRB is established and the UE and the eNB stay in EMM-Registered state and now 18 Figure 2.3: Procedure for EPS Session Establishment (2) [10]. the remaining step is establishing the S1 bearer between the eNB and the S-GW. 2.2. IEEE 802.11 IEEE 802.11 standard, mainly known as Wi-Fi, became the de facto standard for wireless connectivity for computers and other devices several years ago. WLANs were, at first, only used by computers and laptops, but now they are also massively used by smartphones and other ”smart” devices. There are several standards under IEEE 802.11, each with a different letter suffix. These standards cover everything from the wireless standards themselves to standards for security aspects or QoS and some of them are listed below [16]: •802.11a defines a wireless network bearer operating in the 5 GHz Industrial, Scientific and Medical (ISM) band with a data rate up to 54 Mbps. •802.11b defines a wireless network bearer operating in the 2.4 GHz ISM band with data rates up to 11 Mbps. 19 •802.11e provides Media Access Control (MAC) enhancements for the prioritisation of traffic classes through the modification of MAC parameters [7]. •802.11f standardises the handover procedures. •802.11g defines a wireless network bearer operating in the 2.4 GHz ISM band with data rates up to 54 Mbps. •802.11h includes spectrum and transmit power management extensions to solve interference problems in the 5 GHz ISM band [7]. •802.11i contains security enhancements such as new encryption methods [7]. •802.11j defines interworking. •802.11k allows Radio Resource Measurements (RRMs) of WLANs in order to facilitate their management and maintenance [7]. •802.11n defines a wireless network bearer operating in the 2.4 and 5 GHz ISM bands with data rates up to 600 Mbps. •802.11r presents the definition of authentication and association messages in order to complete fast and secure handoffs between Basic Service Sets (BSSs) [7]. •802.11s provides mesh networking by describing the mechanisms to form self-configuring multi-hop networks for broadcast, multicast and unicast data delivery [7]. •802.11ac defines a wireless network bearer operating below 6 GHz to provide data rates of at least 1 Gbps for multi-station operation and 500 Mbps on a single link. •802.11ad defines a wireless network bearer providing very high throughput at frequencies up to 60 GHz. •802.11af standardises Wi-Fi in TV spectrum white spaces. •802.11ah standardises Wi-Fi using unlicensed spectrum below 1 GHz to provide long range communications and support for the Internet of Everything. •802.11ax has the aim of become a new amendment to the Wi-Fi standard which increases the transmission rates and improves efficiency of channel usage in case of dense deployment [14]. All the 802.11 Wi-Fi standards operate within the ISM frequency bands. The operation in these unlicensed bands helped this technology to become widespread, but it also presents drawbacks related to the need of being a ”good neighbour” with other devices and technologies that may use the same band at the same time. IEEE 802.11 organises its communications in three frame types: •Data frames carry data from station to station. •Control frames are used alongside with data frames to deliver data in a reliable way. •Management frames are used to join and leave wireless networks and move associations from access point to access point. Beacons are a type of management frames. IEEE 802.11 can use two multiple access mechanisms: Carrier Sense Multiple Access / Collision Avoidance (CSMA/CA), also called Distributed Coordination Function (DCF), and 20 a priority-based access, also called Point Coordinated Function (PCF). The first one makes sure that the channel is free before starting the transmission, while the second one implements a polling mechanism where the access point acts as the coordinator. In practice, CSMA/CA is the mostly used as it does not require centralised coordination. 2.2.1. CSMA/CA This multiple access mechanism is based on listening to the channel and making sure it is free before starting a transmission. When someone wants to transmit, it first has to listen to the channel. If the channel is free during DCF Interframe Space (DIFS) time it transmits, if the channel is busy it waits until the transmission ends, waits DIFS time and after that it enters in random backoff. If the medium keeps free during the backoff it transmits, if not, the timer is stopped until the channel has been free for a DIFS time. In this way stations that have been waiting for more time should finish the backoff before the ones that started waiting later. When the timer expires (again if the channel has been free during the wait), it transmits. Even though this system tries to avoid collisions, they may still happen as the transmitter may not be able to detect another device that is transmitting to the same receiver (hidden terminal problem). In order to ensure that the transmission has been successful, the receiver needs to send an acknowledgement message. If the acknowledgement is not received, the collisioned frame will have to be retransmitted. Before retransmitting, the sender will enter in an exponential random backoff, which starts with a small window that keeps doubling its size when more collisions happen (from a size of 32 to a maximum size of 1024) [7]. 2.2.1.1. RTS/CTS Request To Send (RTS) and Clear To Send (CTS) messages may be optionally used in order to reduce the problem of the hidden terminal in a CSMA/CA system because the Access Point (AP) allows only one station (STA) to transmit at a time. When a STA wants to transmit it sends a RTS with a time of channel reservation. When the AP receives it, it sends a CTS with the same period of reservation. This last message is received by all the stations that are connected to the AP, so all stations know that the channel will be busy during the solicited time, even if they do not detect activity in the channel. In this way collisions can only happen in RTS packets, and as they are shorter than data packets they are also less likely to collide. 2.2.2. Beacon frames Beacon frames are a type of management frame that are being periodically broadcasted by the AP in order to announce the presence of the WLAN and transmit useful information for enabling STAs to establish and maintain communication with them. A complete list with all the possible fields of a beacon frame can be found in Appendix C. Beacon size can vary a lot from one AP to another, but we can consider 300 B as a common size. 21 Another function of beacons is providing synchronisation to the network. Each station manages its own clock but it must be updated periodically in order to avoid synchronisation mismatches. This is done with the beacon, even though beacon intervals might be slightly irregular because the beacon also needs to follow CSMA/CA. Beacon messages have a timestamp field that STAs read in order to update their local clocks to this time, so all the STAs associated to an AP will have the same local clock value. Beacons are also used to tell STAs in power save mode that they have packets to be received. These stations only wake up every time the beacon is being transmitted in order to check if there is traffic waiting for them. APs normally broadcast beacons every 102.4 ms, which is 100 Time Units (TU) (1 TU is 1024 μs), and at the lowest data rate available. The beacon interval can be modified to a different number of TU in most of the commercial APs. Increasing it would lead to less overhead so STAs see more throughput. However, it delays association processes as stations scanning for networks could easily miss a beacon while they are scanning other channels. On the other hand, reducing the beacon interval increases the overhead, so STAs connected to the network would now see less throughput but it makes the process of association faster. Additionally, it also makes that STAs in power saving mode will have a higher consumption as they will have to wake up and listen to the beacon more frequently. The beacon interval is typically not changed from the default value in the WLAN network installation phase. As a short beacon interval is good for the association but gives a lower throughput, and the opposite for a long beacon interval, this setting will be only good in certain moments and traffic conditions. That is why adaptive beacon interval algorithms have been invented [21]. These algorithms use short beacon intervals when the network has a low amount of connected STAs, so the new ones can detect it fast, and it increases the beacon interval as more users connect to it, so it can increase its throughput. 2.3. LTE-WLAN Aggregation LWA is a feature of the Release-13 from the 3rd Generation Partnership Program (3GPP) which allows a mobile device to be configured by the network so that it utilises its LTE and Wi-Fi links simultaneously. Unlike other LTE-WLAN interworking methods, LWA has the capability of splitting a single IP flow at a sub-level granularity (i.e. Packet Data Convergence Protocol (PDCP)). This capability allows all applications to use both LTE and WLAN links simultaneously without any application-level enhancements, thus providing significant performance gains [20]. With LWA, the UEs will automatically use operator deployed WLAN without user intervention. If a user wishes to use a non-LWA enabled network, they may connect to the desired network even while a LWA session is ongoing if their UE is capable to connect simultaneously to two WLANs. For cases when the UE does not have this capability, it will disassociate from the LWA-enabled AP and connect to the user selected WLAN while any existing sessions continue, uninterrupted, over the LTE bearer. The benefits of LWA include, thanks to the extra capacity provided by the WLAN, an increase in the whole system capacity, the ability to increase the number of users who can be served without making major upgrades to the LTE network, just deploying a LWA-enabled 22 WLAN where needed; and the simplification of WLAN operation within the cellular network. Legacy LTE-WLAN interworking technologies implied that the operator had to deploy and maintain two separate networks, one for licensed spectrum and other for unlicensed spectrum. LWA, instead, allows the operator to integrate WLAN at the Radio Access Network (RAN) level so it can eliminate costly WLAN specific Core Network (CN) nodes. In this way, it can reduce CN signalling and making WLAN deployment easier and cheaper to maintain. It also allows the operator to deploy WLAN with a sufficient level of network control to ensure efficient network resources usage of both LTE and WLAN [20]. In order to quantise the performance gains, in [20] some simulations have been performed with a scenario using LWA with 20 MHz WLAN and 20 MHz LTE channels, using IEEE 802.11n capabilities and non full buffer File Transfer Protocol (FTP) traffic model 3. The result of these simulations was compared to a LWIP scenario, where there is integration but bearers are not split between LTE and WLAN [6]. The results of these simulations show that LWA performance gains for non-collocated deployments (see subsection 2.3.1) are between 20-30% in average user throughput and between 30-50% for collocated deployments. As we can see, LWA offers an important increase of the throughput while keeping a simple architecture. It offers a good option for small cell deployment using unlicensed bands and WLAN equipment, which will result cheaper than using LTE base stations. LWA can also be deployed in places where the Wi-Fi network already exists (i.e. shopping centres), so it can be controlled by eNBs and, in this way, manage the traffic over LTE, WLAN or both depending of the characteristics of each connection and improve the users’ quality of experience. 2.3.1. LWA Architecture LWA follows the Dual Connectivity architecture in LTE [12], which allows the UEs to connect to multiple base stations at the same time. Where, as stated previously, the APs are connected to a WLAN Termination (WT)/Access Controller (AC) device, which is connected to the eNBs via the Xw interface as we can see in Figure 2.4. On the user plane, LTE and WLAN are aggregated at the PDCP level. In downlink (DL), the eNB may schedule PDCP Protocol Data Units (PDUs) of the same bearer to be delivered to the UE either via LTE or WLAN. The eNBs can receive radio information about both links that allow them to perform a more efficient scheduling. We can see a diagram of the splitting in Figure 2.5. As WLAN MAC layer has to remain unchanged, 3GPP defined a new protocol: LWA Adaptation Protocol (LWAAP). This new protocol is transparent to WLAN. A new EtherType1 had to also be created in order to allow UEs to differentiate between LWA and non-LWA packets. When it receives the packets, the UE’s PDCP layer performs re-ordering and in this way it allows packet-by-packet scheduling on both LTE and WLAN links. 1It is a field of 2 B in an Ethernet frame that is used to indicate which protocol is encapsulated in the payload of that frame. 23 Figure 3.1: Example of oaisim MSC output. 3.1) was not in a format that could be read by Mscgen (see Figure 3.2), so we had to write a translator in Python in order to make it compatible (the code can be found in Appendix B. The result after processing the translated input with Mscgen can be seen in Figure 3.3. 30 Figure 3.2: Example of translated MSC output (compatible with Mscgen). Figure 3.3: Example of MSC generated by Mscgen. 31 3.2. Adding SIB X In this section we are going to present the changes that have been done in OAI’s code in order to add this new SIB, send it and receive it properly. A large number of lines of code have been added, deleted or modified, but we are only going to show the main changes here. 3.2.1. SIB X contents When creating SIB X we had to set some fields to it in order to send and receive some data. As it was only for testing, we set very simple fields that can be seen in table 3.1. SystemInformationBlockTypeX sibX Group1 group1 INTEGER (0..63) test1 Pair pair BOOLEAN booleanA BOOLEAN boolean B Table 3.1: Contents of SIB X. The italic words tell the type of every element and the bold ones its name. 3.2.2. Creating SIB X using ASN.1 Abstract Syntax Notation One (ASN.1) is an international standard for representing data types and structures. It was created to face one of the fundamental problems confronting users communicating with different systems, which is the efficient transfer of data in such a way that the received data is the same that has been transmitted [11]. ASN.1 is the method of specifying abstract objects in Open Systems Interconnection (OSI), which governs the interconnection of computers from the physical layer up to the application layer and it has to support many different implementations of the services at each layer. In this way, ASN.1 is a notation that due to this abstract nature can be understood and implemented by the programming languages that are used to program the different functions in each layer [13]. OAI uses ASN.1 in order to automatically generate a big number of .c and .h files that are used by the simulator. These files include type declarations and the necessary functions to use them. Most of these automatically created files include types related to messages used by the system, for instance SIBs or RRC messages. In order to create the new SIB with the contents of table 3.1, we had to add several pieces of code in the ASN.1 file that can be found in: openair2/RRC/LITE/MESSAGES/asn1c/ASN1 files/EUTRA-RRC-Definitions-a20.asn. This ASN.1 file is used by the compiler in order to generate all the necessary C files for the SIBs, among other messages. The code after the changes is shown in code listing 3.1. 32 1SystemInformation−r8−IEs : : = SEQUENCE { sib−TypeAndInfo SEQUENCE ( SIZE ( 1 . . maxSIB ) ) OF CHOICE { 3sib2 SystemInformationBlockType2 , sib3 SystemInformationBlockType3 , 5sib4 SystemInformationBlockType4 , sib5 SystemInformationBlockType5 , 7sib6 SystemInformationBlockType6 , sib7 SystemInformationBlockType7 , 9sib8 SystemInformationBlockType8 , sib9 SystemInformationBlockType9 , 11 sib10 SystemInformationBlockType10 , sib11 SystemInformationBlockType11 , 13 sibX SystemInformationBlockTypeX , . . . , 15 sib12−v920 SystemInformationBlockType12−r9 , sib13−v920 SystemInformationBlockType13−r9 17 }, nonC r i t i ca l Ex te n si on SystemInformation−v8a0−IEs OPTIONAL 19 } 21 . . . 23 SystemInformationBlockTypeX : : = SEQUENCE { −− MCC: Define what i s SIBX group1 Group1 25 } 27 Group1 : : = SEQUENCE { −− MCC: Define Group1 f o r SIBX tes t1 INTEGER( 0 . . 6 3 ) , 29 p a i r Pai r } 31 Pair : : = SEQUENCE { −− MCC: Define Pair f o r Group1 33 booleanA BOOLEAN, booleanB BOOLEAN 35 } 37 . . . 39 SIB−Type : : = ENUMERATED { sibType3 , sibType4 , sibType5 , sibType6 , 41 sibType7 , sibType8 , sibType9 , sibType10 , sibType11 , sibType12−v920 , sibType13−v920 , sibTypeX , 43 spare4 , spare3 , spare2 , spare1 , . ..} −− MCC: changed ” spare5 ” by ” sibTypeX” Code Listing 3.1: ASN.1 code for adding SIB X. After the edit in code listing 3.1, when we built OAI we had a problem with the SHA-1 hash of SystemInformation-r8-IEs.h because it did not match the number that the building script was expecting. We had to modify the file called fix asn1 (located in cmake targets/tools) and comment the line where it checked the SHA-1 checksum, in function apply patches(). After the first build we were able to uncomment the previously commented line and modify the array in the beginning of the same file that contained the value of the old hash of SystemInformation-r8-IEs.h. We changed it for the number we obtained calculating its new hash so now when checking the hash it will contemplate the last changes we made on the ASN.1 file that generates SystemInformation-r8-IEs.h. 33 3.2.3. Sending SIB X It was necessary to implement mechanisms in the eNB side in order to send SIB X. We first had to create the function that initialises the values of the new SIB, do SIBX(), in asn1 msg.c and asn1 msg.h (which can be found in openair2/RRC/LITE/MESSAGES/). We can see a summary of this function in code listing 3.2. u i n t 8 t do SIBX ( u i n t 8 t Mod id , / / MCC: Added f o r i n i t i a l i s i n g SIBX 2int CC id , LTE DL FRAME PARMS ∗frame parms , 4u i n t 8 t ∗b uffer , BCCH DL SCH Message t ∗bcch message , 6SystemInformationBlockTypeX t ∗∗sibX 8/ / . . . 10 / /MCC: Memory a l l o c a t i o n sibX part = CALLOC(1 , sizeof(struct SystemInformation r8 IEs sib TypeAndInfo Member) ) ; 12 memset ( sibX part , 0 , sizeof (struct SystemInformation r8 IEs sib TypeAndInfo Member) ) ; 14 / /MCC: Setting message as SIB X sib X p ar t −>present = SystemInformation r8 IEs sib TypeAndInfo Member PR sibX ; 16 ∗sibX = &sib X par t −>choice . sibX ; 18 / / MCC: Se t t i n g SIB X f i e l d s : 20 (∗sibX )−>group1 . test 1 = 47; 22 (∗sibX )−>group1 . p a i r . booleanA = TRUE; (∗sibX )−>group1 . p a i r . booleanB = FALSE; 24 / / . . . 26 / / MCC: S e t t i n g BCCH message as SIB 28 bcch message−>message . present = BCCH DL SCH MessageType PR c1 ; bcch message−>message . choice . c1 . present = BCCH DL SCH MessageType c1 PR systemInformation ; 30 bcch message−>message . choice . c1 . choice . systemInformation . c r i t i c a l E x t e n s i o n s . present = SystemInformation criticalExtensions PR systemInformation r8 ; 32 bcch message−>message . choice . c1 . choice . systemInformation . c r i t i c a l E x t e n s i o n s . choice . systemInformation r8 . sib TypeAndInfo . l i s t . count =0; 34 / / . . . 36 / / MCC: Sending message t o b u f f e r 38 enc r v a l = u per enco de to buff er (&asn DEF BCCH DL SCH Message , (void∗)bcch message , 40 buff er , 900) ; 42 Ass ertFa tal ( enc r v a l . encoded >0 , ”ASN1 message encoding f a i l e d (%s , %l u ) ! \n ” , e nc r val . f a i l e d t y p e −>name, enc r v a l . encoded ) ; 44 / / . . . 46 return ( ( e nc r va l . encoded+7) / 8 ) ; 34 48 } Code Listing 3.2: Summarised code of function do SIBX(). After this we also needed to edit the function init SI() in openair2/RRC/LITE/rrc enb.c in order to do the initialisation of the new SIB. In code listing 3.3 we can see that we call do SIBX() there. s t a t i c void i n i t S I ( const p r o t o c o l c t x t t ∗const ctxt pP , const i n t CC id ) { 2uint8 t SIwindowsize = 1; u i n t 1 6 t SIperiod = 8; 4 / / . . . 6 / / MCC: A l l o c a t i n g memory f o r SIB X . 8eN B r r c i ns t [ ctxt pP−>module id ] . c a r r i e r [ CC id ] . SIBX = ( u i n t 8 t ∗) malloc16 (64) ; 10 i f ( e N B r r c i ns t [ ctxt pP−>module id ] . c a r r i e r [ CC id ] . SIBX ){/ / MCC: I f SIBX e x i s t s ( t he re i s memory a l lo ca t e d f o r i t ) eN B r r c i ns t [ ctxt pP−>module id ] . c a r r i e r [ CC id ] . sizeof SIBX = do SIBX ( 12 ctxt pP−>module id , CC id , 14 mac xface−>lte frame parms , eN B r r c i ns t [ ctxt pP−>module id ] . c a r r i e r [ CC id ] . SIBX , 16 &eN B r r c i nst [ ctxt pP−>module id ] . c a r r i e r [ CC id ] . systemInformation , &eN B r r c i nst [ ctxt pP−>module id ] . c a r r i e r [ CC id ] . sibX 18 / / . . . ) ; 20 / / . . . } 22 } / / . . . 24 } Code Listing 3.3: Summarised code of function init SI(). We also had to edit the function mac rrc data req() in openair2/RRC/LITE/L2 interface.c, which is the piece of code in charge of broadcasting the SIBs, in order to get SIB X sent periodically. We can see in code listing 3.4 that we are sending SIB X every 16 frames starting in frame 3. This field can be changed depending on the periodicity we want. / / . . . 2else i f ( ( frameP%16) == 3) { / /MCC: Here we send SIB X 4memcpy(& buffer pP [ 0 ] , eN B r r c i nst [ Mod idP ] . c a r r i e r [ CC id ] . SIBX , 6eN B r r c i nst [ Mod idP ] . c a r r i e r [ CC id ] . sizeof SIBX ) ; / / . . . Code Listing 3.4: Piece of code extracted from mac rrc data req(). 3.2.4. Receiving SIB X After we are sending the new SIB successfully, we need to go to the UE side in order to make the UEs able to receive and understand it. 35 We had to create a function called dump SIBX(), which is in charge of printing the contents of SIB X, We had to edit the function decode SI() in openair2/RRC/LITE/rrc UE.c in order to add a case for the new SIB, as it can be seen in code listing 3.5. 1s t a t i c i n t decode SI ( const p r o t o c o l c t x t t ∗const ctxt pP , const u i n t 8 t eNB index ) { 3/ / . . . case SystemInformation r8 IEs sib TypeAndInfo Member PR sibX : 5i f ( U E r r c i n s t [ ct xt p P−>module id ] . l is t en To S IB Xf l ag == 1) { i f ( ( U E r r c i n s t [ ctxt pP −>module id ] . I n f o [ eNB index ] . SIS tatu s &2048) == 0) {/ /MCC: SISstatus i s used as an ar ray of 32 f l a g s 7/ / U E r r c i n s t [ ct xt p P−>module id ] . I n f o [ eNB index ] . S ISta tus |=2048; / / new sib =1; 9/ /MCC: These two l i n e s are commented to keep l i s t e n i n g to SIB X 11 / /MCC: We save the contents of SIB X memcpy( U E r r c i n s t [ c tx t pP −>module id ] . sibX [ eNB index ] , &typeandinfo −>choice . sibX ,sizeof(SystemInformationBlockTypeX t ) ) ; 13 dump sibX ( U E r r c i n s t [ c txt p P−>module id ] . sibX [ eNB index ] ) ; 15 } } 17 break ; / / . . . 19 } Code Listing 3.5: Part of function decode SI() where we handle the reception of SIB X. As we can see in code listing 3.5, we commented two lines in order to keep receiving SIB X every time it is sent. The reason for keeping them is that all the other SIBs work in a slightly different way and they are ignored once they have been listened for the first time until the UEs have to listen to them again because they have been told to do so or it has been 3 hours since the last time they received it (see section 2.1.1.1). 3.3. Notifying the UEs about SIB X OAI with the changes that we have done so far presents a scenario where eNBs are always transmitting SIB X and UEs are always listening to it. Taking into account that this SIB will not always be sent and that the network may decide to activate LWA only for certain users, we thought that we needed a way to notify these users about the existence of LWA and also inform them that SIB X would be available (because we could have LWA without implementing SIB X). 3.3.1. Deciding how to notify SIB 1 has a field called systemInfoValueTag that tells if any SIB has changed. Our problem was that the UEs do not listen to SIB 1 with enough frequency for this case. Another way to inform UEs about a system information change is to send a Paging message to them including the systemInfoModification field. In this way, UEs know that there are 36 going to be changes in the system information . We could not implement this method because paging messages were not implemented in OAI yet. The first alternative regarding the way to notify UEs about SIB X was sending a RRC Connection Reconfiguration message to every UE to tell them to start listening to SIB X. In order to do so we had to create a new kind of RRC Connection Reconfiguration message. This can be found in section 3.3.2. The second idea was implementing the LWA Configuration message from Release 14, and adding a field to it that would inform the UE about the availability of SIB X. The methodology we followed in this case is explained in section 3.4. This message can be implemented from scratch in OAI even though OAI does not support LWA. In this case we are going to send the message after a certain trigger event in the same way we send the new RRC Connection Reconfiguration message, so LWA will not be implemented in OAI but this message will be sent anyway. 3.3.2. Creating new RRC Connection Reconfiguration message To create this new message we had to edit EUTRA-RRC-Definitions-a20.asn as when we created SIB X. This new message will send a boolean and an integer telling if SIB X is available and its period. We can see its contents in code listing 3.6. 1DL−DCCH−MessageType : : = CHOICE { c1 CHOICE { 3csfbParametersResponseCDMA2000 CSFBParametersResponseCDMA2000 , dl I n form a t ionTr a n sfer DLInformationTransfer , 5handoverFromEUTRAPreparationRequest HandoverFromEUTRAPreparationRequest , mobilityFromEUTRACommand MobilityFromEUTRACommand , 7rrcConnectionReconfiguration RRCConnectionReconfiguration , listenRRCConnectionReconfiguration RRCConnectionReconfiguration , 9−− MCC: Added to be able to receive i t rrcConnectionRelease RRCConnectionRelease , 11 securityModeCommand SecurityModeCommand , ueCapabilityEnquiry UECapabilityEnquiry , 13 counterCheck CounterCheck , ueInformationRequest−r9 UEInformationRequest−r9 , 15 loggedMeasurementConfiguration−r10 LoggedMeasurementConfiguration−r10 , rnReconfiguration−r10 RNReconfiguration−r10 , 17 spare4 NULL, spare3 NULL, spare2 NULL, spare1 NULL 19 }, messageClassExtension SEQUENCE {} 21 } 23 . . . 25 RRCConnectionReconfiguration ::= SEQUENCE { rrc−TransactionIdentifier RRC−TransactionIdentifier , 27 criticalExtensions CHOICE{ c1 CHOICE{ 29 rrcConnectionReconfiguration−r8 RRCConnectionReconfiguration−r8−IEs , listenToSIBX ListenToSIBX ,−− MCC: Here we had ” spare7 NULL” before 31 spare6 NULL, spare5 NULL, spare4 NULL, spare3 NULL, spare2 NULL, spare1 NULL 33 }, c r i t i c a l E x t e n s i o n s F u t u r e SEQUENCE {} 37 35 } } 37 ListenToSIBX : : = SEQUENCE { −−MCC: Defined type f o r RRCConnectionReconfiguration 39 l i s t e n BOOLEAN, period INTEGER( 0 . . 1 6 ) −− MCC: We can make i t bigger i f we need 41 } Code Listing 3.6: ASN.1 code for adding the new RRC Connection Reconfiguration message. As we can see in 3.6, we called this new message listenRRCConnectionReconfiguration. After creating it, we needed to find some event that triggered it. We realised that a good moment to send it would be after the DRB assignment seen in subsection 2.1.2. To do so, we added the piece of code that can be seen in code listing 3.7 at the end of the function that processes RRCConnectionReconfigurationComplete messages in the eNB side. We did it this way because this message is sent for the first time after the eNB sends the RRCConnectionReconfigurationRequest message during the DRB establishment. In order to avoid sending this message every time we receive a RRCConnectionReconfigurationComplete, we set up a flag (per user) that gets set to 1 after the message is sent for the first time. This flag is called listenToSIBXsent and it can be seen in code listing 3.7. void rrc eNB process RRCConnectionReconfigurationComplete ( 2const p r o t o c o l c t x t t ∗const ctxt pP , rrc eNB ue context t∗ue context pP , 4const u i n t 8 t xid ) 6{ / / . . . 8i f ( ue context pP−>list enToSI BXsent == 0) {/ /MCC: Flag / /MCC: We send the listenRRCConnectionReconf here . 10 rrc eNB generate listenRRCConnectionReconfiguration ( ctxt pP , ue context pP , 1 , 4) ; 12 ue context pP−>listenToSIBXsent = 1; } 14 } Code Listing 3.7: Fragment where listenRRCConnectionReconfiguration message is sent. As we had to do with SIB X, we also had to create new functions in order to set up the message in a proper way. These functions are: •rrc eNB generate listenRRCConnectionReconfiguration(), which can be seen in code listing 3.8, in opeiair2/RRC/LITE/rrc eNB.c. •do listenRRCConnectionReconfiguration() in opeiair2/RRC/LITE/MESSAGES/asn1 msg.c. void rrc eNB generate listenRRCConnectionReconfiguration ( 2const p r o t o c o l c t x t t ∗const ctxt pP , rrc eNB ue context t∗const ue context pP , 4int l i s t e n , int listenPeriod 6) { 8u i n t 8 t size ; u i n t 8 t b u f f e r [ 1 0 0 ] ; 10 38 DL DCCH Message t dl dcch msg ; 12 RRCConnectionReconfiguration t ∗rrcConnectionReconfiguration ; 14 memset(& dl dcch msg , 0 , sizeof( DL DCCH Message t ) ) ; 16 / / MCC: The i n i t i a l i s a t i o n of the message i s done here . size = do listenRRCConnectionReconfiguration ( ctxt pP , dl dcch msg , & rr cC onn ect ion Rec onf ig ura tio n , l i s t e n , l i s ten Pe ri od , &b u f f e r ) ; 18 / / . . . 20 rrc data req( / / MCC: The message i s sent here . 22 ctxt pP , DCCH, 24 rrc eNB mui ++ , SDU CONFIRM NO, 26 size , buff er , 28 PDCP TRANSMISSION MODE CONTROL) ; 30 } Code Listing 3.8: Summary of the function that generates the listenRRCConnectionReconfiguration message. We also had to edit the UE side in order to understand the new message and act in consequence. We created a flag that the UE will set to 1 whenever it receives the message telling it to start listening to SIB X. In this way all UEs ignore SIB X until they are told to listen to it. This flag was called listenToSIBXflag and we can see how we set it to the value that is carried by the listenRRCConnectionReconfiguration message in code listing 3.9. We can also see how it is taken into account at the moment of receiving SIB X in code listing 3.5. void rrc ue decode dcch(const p r o t o c o l c t x t t ∗const ctxt pP , const r b i d t Srb id , const u i n t 8 t ∗const Buffer , const u i n t 8 t eNB indexP ) 2{ / / . . . 4case DL DCCH MessageType c1 PR listenRRCConnectionReconfiguration : 6/ /MCC: We set the ” l i s t e n ” f l a g here . U E r r c i n s t [ ctxt pP −>module id ] . l istenT oSIBXf lag = dl dcch msg−>message . choice . c1 . choice . listenRRCConnectionReconfiguration . criticalExtensions .choice . c1 . choice . listenToSIBX . l i s t e n ; 8 / /MCC: Reply with a RRCConnectionReconfigurationComplete 10 rrc ue generate RRCConnectionReconfigurationComplete( ctxt pP , 12 target eNB index , dl dcch msg−>message . choice . c1 . choice . rrcConnectionReconfiguration . r r c T r a n s a c t i o n I d e n t i f i e r ) ; 14 break ; / / . . . 16 } Code Listing 3.9: Part of function rrc ue decode dcch() where we handle the reception of a listenRRCConnectionReconfiguration. 39 The first simulation used a scenario with 7 cells and frequency reuse 1, this was mainly to practice with ns-3 as it was the first time we used it. Following simulations increased the number of APs in the scenario up to 85, as, using a transmitted power of 17 dBm, hexagonal cells and a distance between APs of 10 m, was the maximum number of APs that the central AP would hear. In order to calculate that, we used the formula of the path loss model from 3.5. To see it from a spacial point of view, 85 APs in this setup make 5 rings of hexagonal cells without the 6 ”corner cells” from the largest ring. We simulated scenarios with 85 cells and 1 STA, so we could see the number of beacons that this station would see in each case. After, we increased the number of users up to 1 per cell in order to see the impact of the beacons in networks with higher density. As we were using full buffer transmissions, 1 user would use the AP in an equivalent way as several users connected to it but with less traffic. In order to calculate the throughput, we transmitted this full buffer data in DL direction. The first simulations were made using IEEE 802.11n standard at 5 GHz, but we changed it to 802.11ac with 160 MHz of bandwidth, so we could have a higher throughput. Another change that we introduced was in ”Remote Station Manager”, which controls the whole operation of APs including the Modulation and Coding Scheme (MCS) and so controlling the data rate. First, we used a constant rate Wi-Fi manager, but we changed it for the Minstrel High Throughput (HT) Wi-Fi manager, which implements the Minstrel HT Rate Control Algorithm [22], which adapts the MCS, channel width, number of streams, and short guard interval (enabled or disabled). We collected the throughput from these simulations in order to compare the results when using different beacon sizes and intervals. Most of these simulations were performed by the servers in the 5GIC as they would require several hours to be completed even with a powerful machine. All the simulation programs were written in C++ and the results can be seen in chapter 4. 46 4. Results In this chapter we are going to expose the results obtained during the development of the project. As the project has two different parts, the one related to OAI and the one related to ns-3, we have divided this chapter in two sections. The first one will be ns-3 because even though we worked first with OAI, the simulations of LTE were done after the ns-3 simulations of Wi-Fi. 4.1. IEEE 802.11 ns-3 simulations As we have seen in section 3.7, several simulations were performed with ns-3. The first one implemented 7 APs with only one STA. This STA was connected to the central AP and full-buffer DL traffic was implemented. In this scenario, the default case (300 B1of beacon size and 100 TU of beacon interval) makes beacons use the channel a 2.56 % of the time. If we reduced the beacon size to 100 B, this percentage was reduced to a 0.84 %, and, if we increased the beacon interval (keeping the size of 100 B) to 300 TU, it was reduced to a 0.30 % of the time. If we kept increasing the beacon interval to 500 TU, this would get to a 0.18 %. In this case, the STA saw a very high throughput in both cases, around 45 Mbps. However, there was a gain of a 2.6 % between the best and the worst cases, 100 B of beacon size with a beacon interval of 500 TU and 300 B of beacon size with a beacon interval of 100 TU respectively. The next case made our scenario much bigger by using the maximum number of cells, 85, calculated in section 3.7, but having reuse 3. In this case, we calculated graphically that the number of interfering cells would be 30 instead of the 84 we would have with reuse 1. The results in this case went from a 8.48 % of the time when using 300 B beacons sent every 100 TU to 0.75 % when using 100 B beacons sent every 500 TU. The throughput gain, again we have only one STA receiving a full-buffer stream, would be of a 8.8 % when comparing the best case to the worst one. In this case, the gain would be between 3 and 4 Mbps. The next scenario was the same but with reuse 1, meaning that there are 84 neighbours interfering our cell. In this case, the channel time used by beacons is a 15.61 % of the time when having a beacon size of 300 B and a beacon interval of 100 TU. When having a beacon size of 100 B and a beacon interval of 500 TU, the time used by beacons decreases to a 1.66 %. The throughput gain is a 19 % between the best and the worst case, gaining around 7 Mbps. If we change to IEEE 802.11ac we can observe a very similar behaviour. In this case, using 802.11ac with 160 MHz of channel bandwidth, and keeping the same topology as before, we got that in the worst case (300 B of beacon size and 100 TU of beacon interval) the time the channel is used by beacons is a 17.6 %, while when using a beacon size2of 110 B sent 1The size takes into account the header and the FCS. 2110 B was the smallest beacon size we could use. 47 Figure 4.1: Results of the simulation with 85 APs and 1 STA. every 500 TU we got a 3.0 %. From the throughput point of view, we get an improvement of a 34 % from the worst to the best case, in absolute numbers, this gain supposes almost 70 Mbps. We can see these results in Figure 4.1. After that, we made much denser simulations where the number of beacons was very large and much more difficult to count, as it had to be done manually due to the characteristics of the simulations. In these cases, we compared the performance taking into account only the average throughput. In addition, we can assume that the number of beacons will not vary from what we got in the scenario with only one STA, as they have to be transmitted periodically in all cases. In these new simulations we used the Minstrel HT Wi-Fi Manager in IEEE 802.11ac. We used 85 STAs, one in a random position within each cell. Each STA was receiving a fullbuffer bit stream from its AP. This scenario with a lot of traffic, and thus collisions, made the throughput become very small for everyone. In this case with 85 APs and 85 STAs, the worst overall average throughput, calculated averaging the sum of the throughput that each STA saw over the 100 simulations we did, was 50.7 Mbps for the scenario where the beacon size was 300 B and the beacon interval, 100 TU. The best case was when having a beacon size of 110 B and a beacon interval of 500 TU, resulting in an average total throughput of 64.0 Mbps. This supposes an increase of a 26.2 %, however, the results show a very low throughput caused by the huge amount of interference generated by the 85 DL connections between the APs and the STAs. We can see these results in figure 4.2. We did a last simulation reducing the amount of STAs to 40, each one receiving a full-buffer data stream from its AP. In this case we went from 61.5 Mbps of average total throughput when having beacons of 300 B and an interval of 100 TU to 75.9 Mbps when having beacons of 110 B and an interval of 400 TU. This supposes a gain of a 23.4 %. 48 Figure 4.2: Results of the simulation with 85 APs and 85 STAs. 4.2. LTE with OpenAirInterface After the simulations with ns-3, we tried to simulate a LTE cell in order to see the impact that adding a new SIB would have on the throughput that the cell would see. As OAI is still under development and has some non-fixed issues, when simulating the cell we got the exact same throughput when the eNB transmitted a SIB X of a size of 200 B and when it did not transmit it. In addition, different random number seeds generated the same output as well. The throughput that the cell saw was several hundreds of kbps. As this result is not normal at all, because it should be of around 75 Mbps, we investigated the cause of it. This low throughput was caused by an authentication problem that did not let the UE connect to the eNB, and the number we got was probably based on the amount of control traffic that had been exchanged between the UE and the eNB. This bug was impossible to solve because we ran out of time. However, we can assume that broadcasting a SIB over LTE is more efficient than broadcasting a beacon over Wi-Fi thanks to the much larger amount of control that LTE has over the channel compared to WLAN. This difference is mainly caused by the use of licensed spectrum by ”traditional” LTE, this makes that all those resources are going to be used only by this technology, so eNBs’ can schedule the use of the channel in order to use it in the most efficient way and they do not have to be aware of interferences and being ”good neighbours” as WLANs have. These tests will be able to be completed once this authentication problem is solved. We were able to test that the new SIB was broadcasted and received correctly by the UEs. The configuration messages we also created in Chapter 3 were also sent correctly and understood by the receiver UEs. These facts mean that the only barrier that exists between us and a correct simulation when SIB X is deployed is the same that would exist when trying to simulate the system without any changes: this authentication problem when the UE tries to connect to the eNB. Hopefully, this issue will be solved soon by the developers of OAI. 49 5. Budget During the development of the project, the only equipment that was needed was a computer complying with the minimum requirements of OAI. We can see the total cost of the hardware and software used in the table below: Desktop computer 1200 e OAI License 0 e ns-3 License 0 e Texmaker License 0 e Total 1200 e Table 5.1: Cost of software and hardware components. As we can see, all the software used for this project is open source. In addition to that, we need to take into account the amount of hours worked: 30 h/week ·24 weeks = 864 h 864 h ·15 e/h = 12960 e This makes the total cost of the project of: 1200 e+ 12960 e=14160 e 50 6. Conclusions and future development We have seen that beacons have a real impact on the throughput that WLANs can give, and it becomes more important when the density of APs increases. These results show that offloading beacon information from IEEE 802.11 to LTE would have a noticeable impact on WiFi performance by reducing the amount of time the channel is being occupied by beacon transmissions, and thus increasing the amount of time the channel is available for sending data. However, we have not been able to test the impact of the addition of another SIB on LTE. Even though we can assume that what we gain by reducing the beacon size and increasing the beacon interval is more that what we lose adding a new SIB, it should be tested in each scenario to see if it is worth it. As an example, we saw that when having only 7 APs it gave us a very small gain compared to when we had 85. So, in order to decide if this technique should be implemented, many different scenarios should be tested so we can see in which ones it provides a sensible gain and in which ones it does not. Another issue that should be tested is the loss of synchronisation when increasing the beacon interval. As beacons are used for providing synchronisation to the STAs, we should take into account how long these devices can hold the synchronisation with the AP, because the more we increase the interval, the less time the channel is occupied by beacons. However, as we could see very clearly in Figure 4.1, the extra gain becomes less important the more we increase the beacon interval. Having seen that, a beacon interval between 300 and 500 TU would probably be the best option. Another way to reduce the overhead generated by beacons that could be investigated would be sending a ”big beacon” with all the information we wanted to offload every several seconds alongside the ”small” beacons sent every hundreds of milliseconds. In this way we would not need any LTE network for offloading the beacon information and it could work for all WLANs with just an update on their software. Opposite to this approach, we would find another interesting one which would send very small beacons, only containing timing information and the identifier of the AP in order to keep synchronisation, and sending all the other data over LTE. This would make the impact of the beacons much smaller on Wi-Fi, but it would also mean that legacy devices would not be able to connect to that WLAN. Talking about legacy devices, an issue that should be taken into account by operators when deploying LWA is whether they allow everyone to connect to their WLANs or only their clients. In the first case they should provide backwards compatibility so tablets and laptops without LTE can connect to the network. On the other hand, in the second case this compatibility with non-LTE devices would not be necessary and then there would be no problem in reducing the amount of information carried by the beacons, as all the devices connected to the WLAN would have been first connected to the LTE network and they can receive beacon information from there. Regarding the future development of this topic, and alongside what we have written before in this chapter, OAI should be improved and corrected in order to make it able to test the impact of introducing a new SIB. OAI is presented as a very powerful tool, but at the moment 51 it is not suitable for investigation as it is incomplete. It still needs a lot of work and so far it is not a good option because users will need a lot of time for configuring it, finding what features work and which ones do not work, and, if it supports their needs, modifying it in order to perform simulations. The feeling that OAI gave when using it was that it only worked in several particular cases that had been tested by the developers. OAI, however, will be a very powerful tool when it is completed, and it will be very useful in research, but so far it is better for investigators that want to perform simulations to use ns-3, as it is more complete than OAI, with less errors and with a large community behind and a large amount of documentation available online. This makes ns-3 a good candidate for testing the impact of a new SIB in LTE. This would be a long task as the people doing it will have first to understand how ns-3 works internally and how to add this new message in a reliable way, as we did with OAI, but in this case it would bring back some results and the impact of adding a new SIB would get measured. In the case of using ns-3, a whole LWA system simulating together LTE and WLAN could be simulated, but it would require several weeks (or even months) of work. To conclude, LWA is a very powerful technology that will enable more capacity to the UEs, which will be needed in the next years. LWA works perfectly with the idea of having less users per base station so their capacity is larger, and it does it in a very easy way that does not require a lot of changes in the hardware, so it is easy to introduce. 5G will support LWA and it will also introduce other mechanisms and technologies to reach higher throughputs in order to handle the users’ demand and also make them increase their consumption. Operators, however, will develop only the features that are profitable. So, even though LTEWLAN aggregation seems a very good option, at this moment it is difficult to say whether users will be able to experience it or not. 52 Bibliography [1] 3GPP TS 36.331. Evolved Universal Terrestrial Radio Access (E-UTRA): Radio Resource Control (RRC) Protocol Specification (Release 14). Technical Specification. Apr. 2017. [2] R. Agust´ ı et al. LTE: Nuevas Tendencias en Comunicaciones M´ oviles. Ed. by Fundaci´ on Vodafone Espa˜ na. 2010. [3] S. Ahmadi. LTE-Advanced. A Practical Systems Approach to Understanding the 3GPP LTE Releases 10 and 11 Radio Access Technologies. Elsevier, 2014. [4] OpenAirInterface Software Alliance. OpenAirInterface (OAI): Towards Open Cellular Ecosystem. English. Website. URL:http://www.openairinterface.org/?page_id= 864 (visited on 08/16/2017). [5] OpenAirInterface Software Alliance. Third OAI General Workshop. Status and Objectives for 2017-2018. Presentation. BUPT, Beijing, China. Apr. 2017. [6] R. Burbidge. LTE-WLAN Aggregation (LWA) and LTE WLAN Radio Level Integration with IPsec Tunnel (LWIP). Presentation at IEEE meeting. Macao. Mar. 2016. [7] J. Casademont. Communication Networks. Wireless Local Area Networks. Course slides. 2014. [8] R. Ferr´ us. Advanced Mobile Communications. Chapter 1 - Introduction. Course slides. 2015. [9] IEEE 802.11ax Task Group. TGax Simulation Scenarios. doc.: IEEE 802.11-14/0980r16. Nov. 2015. [10] NMC Consulting Group. EMM Procedure 1. Initial Attach. Part 2. Call flow of Initial Attach. Netmanias Technical Document. Jan. 2014. [11] Objective Systems Inc. ASN.1. ASN.1 Tutorial. English. Website. URL:https://www. obj-sys.com/asn1tutorial/asn1only.html (visited on 06/27/2017). [12] S. C. Jha et al. “Dual Connectivity in LTE Small Cell Networks”. In: Globecom 2014 Workshop - Heterogeneous and Small Cell Networks (2014). [13] B. Kaliski. A Layman’s Guide to a Subset of ASN.1, BER, and DER. English. Technical Note. RSA Laboratories, June 1991. URL:http://luca.ntop.org/Teaching/ Appunti/asn1.html (visited on 06/27/2017). [14] E. Khorov, A. Kiryanov, and A. Lyakhov. “IEEE 802.11ax: How to Build High Efficiecny WLANs”. In: 2015 International Conference on Engineering and Telecommunication (2015). [15] R. Nayanajith. CWAP – 802.11 Mgmt Frame Types. English. Website. Sept. 2014. URL:https://mrncciew.com/2014/09/29/cwap80211mgmtframetypes/ (visited on 08/22/2017). [16] I. Poole. IEEE 802.11 Wi-Fi Standards. English. Website. URL:http://www.radioelectronics.com/info/wireless/wi-fi/ieee-802-11-standards-tutorial.php (visited on 08/7/2017). [17] ns-3 project. ns-3 Tutorial. Release ns-3.26. Mar. 2017. [18] ns-3 project. What is ns-3. English. Website. URL:https://www.nsnam.org/overview/ what-is-ns-3/ (visited on 08/16/2017). [19] ShareTechnote. LTE Basic Procedure. SIB Scheduling. English. Website. URL:http: //www.sharetechnote.com/html/BasicProcedure_LTE_SIB_Scheduling.html (visited on 08/5/2017). 53 [20] S Sirotkin. LTE-WLAN Aggregation (LWA): Benefits and Deployment Considerations. White Paper. Intel Corporation. 2016. [21] A. V¨ ais¨ anen, P. Orava, and H. Haverinen. Adaptive Beacon Interval in WLAN. US Patent 7333460 B2. Feb. 2008. [22] Linux Wireless. en:developers:documentation:mac80211:ratecontrol:minstrel. English. Website. Jan. 2016. URL:https://wireless.wiki.kernel.org/en/developers/ documentation/mac80211/ratecontrol/minstrel (visited on 08/30/2017). 54 Appendices A. Installation of OAI A.1. System requirements •Processor: Generation 3/4/5/6 Intel Core i5,i7; Generation 2/3/4 Intel Xeon; Intel Atom Rangely, E38xx, x5-z8300 •OS: Ubuntu 14.04 64-bit •Kernel: Linux kernel version ¿= v.4.7 for Core Network (OpenAirCN) and v.3.19 lowlatency for Access Network (OpenAir5G). •CPU frequency scaling disabled for emulation. •If we want to simulate the whole system in one machinne: –16 GB RAM –8x Processor –VMware Player installed To see the full requirements visit: https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/OpenAirSystemRequirements and https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/OpenAirKernelMainSetup IMPORTANT: In order to run eNB and EPC+HSS in the same machine, one of the two parts (RAN or EPC) needs to be running on a virtual machine (we used VMware) while the other one is running on the physical machine. This manual will be for configuring the whole system in the same physical machine, with the RAN running on the virtual machine. A.1.1. Installation of a Linux Image in VMWare First, we need to download the 14.04 image from: http://releases.ubuntu.com/14.04/, clicking on “64-bit PC (AMD64) desktop image”. Second, we need to install VMware Player. We can download it from the following website: https://my.vmware.com/en/web/vmware/free#desktop end user computing/ vmware workstation player/12 0. The downloaded file will have a similar name as the following one (or even the same): “Vmware-Player-12.5.5-5234757.x86 64.bundle”. Now, we need to run the following command on a terminal: sudo sh /Download location/Vmware-Player-12.5.5-5234757.x86 64.bundle We need to follow the installer’s prompts until the installation ends successfully. 55 A.5.1.3. Installation of PHP We can install PHP and some helper packages by running: sudo apt-get install php5 libapache2-mod-php5 php5-mcrypt This should install PHP without any problems. After, we need to change the configuration of Apache to modify the way it serves files when a directory is requested. To do this we need to open the “dir.conf” file with root privileges: sudo nano /etc/apache2/mods-enabled/dir.conf It will look like this: 1<IfModule mod dir . c> Dire ctoryI ndex index . html index . c g i index . p l index . php index . xhtml index . htm 3</IfModule> Code Listing A.1: Original dir.conf file. And we need to modify it by moving “index.php” to the first position like the following: 1<IfModule mod dir . c> Dire ctoryI ndex index . php index . html index . cgi index . pl index . xhtml index . htm 3</IfModule> Code Listing A.2: Modified dir.conf file. After this, we need to restart the Apache web server in order to apply our changes: sudo service apache2 restart In order to test that our system is configured properly for PHP, we can create a very basic PHP script. We will call it “info.php” and it must be saved at /var/www/html/. We can create the file at the location by typing: sudo nano /var/www/html/info.php This will open an empty file. We will fill and save the file with the following text, which is valid PHP code: 1<?php phpinfo () ; 3?> Code Listing A.3: Code that we need to write in info.php. Now we can test if our web server can correctly display content generated by a PHP script. To do it, we just have to visit the following webpage: http://your server IP address/info.php (in our case http://127.0.0.1/info.php). If we can see something similar to Figure A.4 it means that our PHP is working as expected. 62 Figure A.4: Example of info.php. After this test we should remove the file because it could give information about our server to unauthorised users. We just need to remove the “info.php” file that we created before: sudo rm /var/www/html/info.php A.5.1.4. Installation of phpMyAdmin It is a tool that will allow us to manage our database through a web interface. To install the files in our system we need to run the following: sudo apt-get install phpmyadmin It will ask us a few questions during the installation: •For the server selection, choose apache2. To select it press SPACE when the cursor is on it and ENTER afterwards. •Select “yes” when asked if you want to use dbconfig-common to set up the database. •It will ask for the database administrator’s password. •It will ask for a password for the phpMyAdmin application itself. After this, the only thing we need to do is explicitly enable the php5-mcrypt extension and restart the server by typing: sudo php5enmod mcrypt sudo service apache2 restart We can now access the web interface by visiting the next web page: http://your server IP address/phpmyadmin (in our case http://127.0.0.1/phpmyadmin). It should look like Figure A.5. We can now log into the interface using “root” username and the MySQL admin password that we set up during the installation. 63 Figure A.5: Example of phpMyAdmin log in page. 64 A.5.2. Installation of HSS First we need to run the following command in order to install the packages required for a proper functioning of HSS: cd "openairCN dir"/ source oaienv # This command is IMPORTANT cd SCRIPTS/ ./build hss -i When asking to install freeDiameter we should say “yes” as it is not installed. We also need to set a FQDN (Fully Qualified Domain Name) for the HSS. An easy way to do that is to fill the /etc/hosts file: sudo nano /etc/hosts And then add the HSS in this way: 112 7. 0. 0. 1 l o c a l h o s t 127.0.1.1 ubuntu . openair4G . eur ubuntu 3127.0.33.1 hss . openair4G . eur hss Code Listing A.4: Edited /etc/hosts. After this we need to configure the HSS. First we need to copy the HSS configuration file template to /usr/local/etc/oai/ using the following commands: sudo mkdir -p /usr/local/etc/oai/freeDiameter sudo cp ../ETC/hss.conf /usr/local/etc/oai Now we can customise the copied hss.conf file (in /usr/local/etc/oai/ ), which will look like this: 1HSS : { 3## MySQL mandatory options MYSQL server = ” 1 2 7 . 0 . 0 . 1 ” ; # HSS S6a bind address 5MYSQL user = ” r o ot ” ; # Database serv er l o g i n MYSQL pass = ”1234admin ” ; # Database server password set during the i n s t a l l a t i o n 7MYSQL db = ” oai db ” ; # Your database name ## HSS options 9OPERATOR key = ”1006020f0a478bf6b699f15c062e42b3 ” ; # OP key matching your database RANDOM = ” true ” ; # True random or only pseudo random ( f o r sub scri ber vector generation ) 11 ## Freediameter options FD conf = ” / usr / l o c a l / etc / oai / freeDiameter / hss fd . conf ” ; 13 }; Code Listing A.5: Modified hss.conf. For the MYSQL server field, we wrote our own local address as the database is located in the same host. After this, we need to copy two more files: 65 sudo cp "openairCN dir"/ETC/acl.conf "openairCN dir"/ETC/hss fd.conf /usr/local/etc/oai/freeDiameter It should not be necessary to customise these files, but you need to make sure that we can find the following two lines in hss fd.conf: 1I d e n t i t y = ” hss . openair4G . eur ” Realm = ” openair4G . eur ” Code Listing A.6: Lines that need to be found in hss fd.conf. After this we need to generate the certificates for the HSS: cd "openairCN dir"/SCRIPTS/ ./check hss s6a certificate /usr/local/etc/oai/freeDiameter hss.openair4G.eur After this we can build HSS in two different ways: an executable that can run in a terminal or a daemon that would run in the background. ./build hss --clean --debug # For the executable ./build hss --clean --debug --daemon # For the daemon A.5.3. Installation of MME To install the MME we need to run the following command (we are still in “openairCN dir”/SCRIPTS/ ): ./build mme -i # It will install the required software in our host When asking whether to install asn1c rev 1516 and liblfds7.1.0 it is necessary to say yes in order to be able to build MME afterwards. After that, we need to copy the configuration files as we did when installing the HSS: sudo mkdir -p /usr/local/etc/oai/freeDiameter # If we haven’t done it before sudo cp "openairCN dir"/ETC/mme.conf /usr/local/etc/oai Now we need to customise the copied configuration file. We only modified the following part: NETWORK INTERFACES : 2{ # MME binded i n t e r f a c e f o r S1−C or S1−MME communication (S1AP) , can be ethernet i n t erf a c e , v i r t u a l ethernet i n terf a ce , we don ’ t advise w i reless interfaces 4MME INTERFACE NAME FOR S1 MME = ” vmnet8 ” ; # YOUR NETWORK CONFIG HERE MME IPV4 ADDRESS FOR S1 MME = ” 1 7 2 . 1 6 . 5 3 . 1 / 2 4 ” ; 6MME INTERFACE NAME FOR S1 MME = ” vmnet8 ” ; # YOUR NETWORK CONFIG HERE MME IPV4 ADDRESS FOR S1 MME = ” 1 7 2 . 1 6 . 5 3 . 1 / 2 4 ” ; 8MME INTERFACE NAME FOR S1 MME = ” vmnet8 ” ; # YOUR NETWORK CONFIG HERE MME IPV4 ADDRESS FOR S1 MME = ” 1 7 2 . 1 6 . 5 3 . 1 / 2 4 ” ; 10 MME INTERFACE NAME FOR S1 MME = ” vmnet8 ” ; # YOUR NETWORK CONFIG HERE MME IPV4 ADDRESS FOR S1 MME = ” 1 7 2 . 1 6 . 5 3 . 1 / 2 4 ” ; 12 # MME binded i n t e r f a c e f o r S11 communication (GTPV2−C) MME INTERFACE NAME FOR S11 MME = ” l o ” ; # YOUR NETWORK CONFIG HERE 14 MME IPV4 ADDRESS FOR S11 MME = ” 1 2 7 . 0 . 1 1 . 1 / 8 ” ; MME PORT FOR S11 MME = 2123; 16 }; 66 . . . 18 S−GW\LIST\SELECTION = ( {ID =” tac−lb01 . tac−hb00 . tac . epc . mnc093 . mcc208 .3 gppnetwork . org ” ; 20 SGW IPV4 ADDRESS FOR S11= ” 1 2 7 . 0 . 1 1 . 2 / 8 ” ; }, . . . # ALL THE IPS ARE SET TO THE SAME VALUE 22 {ID =” tac−l b 0 f . tac−hb00 . tac . epc . mnc093 . mcc208.3 gppnetwork . org ” ; SGW IPV4 ADDRESS FOR S11= ” 1 2 7 . 0 . 1 1 . 2 / 8 ” ; } 24 ) ; ” Code Listing A.7: Example of modified mme.conf. In the NETWORK INTERFACES field, we need to set the IP that the MME will have for the S1-C and S11 interfaces. In the case of the S1-C, we put the IP address of the machine when using vmnet8 interface (the one connecting the physical machine with the virtual one); for S11, we put an address inside the range of addresses for the lo interface (local loop). In the S-GW LIST SELECTION we set all the addresses to 127.0.11.2, another address in the range of addresses for the lo interface, which will be the address that the S-GW will have (so we will have to write it again when configuring spgw.conf). After, we need to copy another file: sudo cp "openairCN dir"/ETC/mme fd.conf /usr/local/etc/oai/freeDiameter Then we need to customise the copied “mme fd.conf”. We need to make sure that these three lines are correct: I d e n t i t y = ” ubuntu . openair4G . eur ” ; 2Realm = ” openair4G . eur ” ; ConnectPeer= ” hss . openair4G . eur ” {ConnectTo = ” 1 2 7 . 0 . 3 3 . 1 ” ; No SCTP ; No IPv6 ; Prefer TCP ; No TLS ; p o r t = 3868; realm = ” openair4G . eur ” ; }; Code Listing A.8: Lines that need to be checked in mme fd.conf. We need to put the hostname and address that we set for the HSS host in /etc/hosts. After that, we can build the MME as an executable or as a daemon following the next commands: ./build mme --clean # For the executable ./build mme --clean --daemon # For the daemon This command will compile oai mme (for the executable) or oai mmed (for the daemon). After, we need to generate the certificate for the MME: ./check mme s6a certificate /usr/local/etc/oai/freeDiameter/ ubuntu.openair4G.eur A.5.4. Installation of SPGW To install the required software we need to run the following command (in “openairCN dir”/SCRIPTS/): ./build spgw -i When asking to ask libgtpnl say “yes”. After this, we need to copy the configuration files: 67 sudo mkdir -p /usr/local/etc/oai # If we haven’t done it before sudo cp "openairCN dir"/ETC/spgw.conf /usr/local/etc/oai Then, we need to customise the copied configuration files like the following: 1S−GW : { 3NETWORK INTERFACES : { 5# S−GW binded i n t e r f a c e f o r S11 communication (GTPV2−C) , i f none selected the ITTI message i n t e r f a c e i s used SGW INTERFACE NAME FOR S11 = ” l o ” ; # YOUR NETWORK CONFIG HERE 7SGW IPV4 ADDRESS FOR S11 = ” 1 2 7 . 0 . 1 1 . 2 / 8 ” ; # YOUR NETWORK CONFIG HERE 9# S−GW binded i n t e r f a c e f o r S1−U communication (GTPV1−U) can be ethernet i n ter fa ce , v i r t u a l e th erne t i nt er fa ce , we don ’ t advise w irele ss i n t e r f a c e s SGW INTERFACE NAME FOR S1U S12 S4 UP = ” vmnet8 ” ; # YOUR NETWORK CONFIG HERE , USE ” lo ” i f S−GW run on eNB host 11 SGW IPV4 ADDRESS FOR S1U S12 S4 UP = ”17 2 . 1 6.53.1/2 4 ” ; # YOUR NETWORK CONFIG HERE SGW IPV4 PORT FOR S1U S12 S4 UP = 2152; # PREFER NOT CHANGE UNLESS YOU KNOW WHAT YOU ARE DOING 13 # S−GW binded i n t e r f a c e f o r S5 or S8 communication , not implemented , so leave i t to none SGW INTERFACE NAME FOR S5 S8 UP = ” none ” ; # DO NOT CHANGE (NOT IMPLEMENTED) 15 SGW IPV4 ADDRESS FOR S5 S8 UP = ” 0 . 0 . 0 . 0 / 2 4 ” ; # DO NOT CHANGE (NOT IMPLEMENTED) }; 17 . . . } 19 P−GW = { 21 NETWORK INTERFACES : { 23 # P−GW binded i n t e r f a c e f o r S5 or S8 communication , not implemented , so leave i t to none PGW INTERFACE NAME FOR S5 S8 = ” none ” ; # DO NOT CHANGE (NOT IMPLEMENTED YET ) 25 # P−GW binded i n t e rf a c e f o r SGI ( egress / ingress i n t e r n e t t r a f f i c ) PGW INTERFACE NAME FOR SGI = ” eth0 ” ; # STRING, YOUR NETWORK CONFIG HERE 27 PGW MASQUERADE SGI = ” yes ” ; # STRING, {” yes ” , ” no ” }. YOUR NETWORK CONFIG HERE, w i l l do NAT f o r you i f you put ” yes ” . UE TCP MSS CLAMPING = ” no ” ; # STRING, {” yes ” , ” no ” }. 29 }; . . . 31 # DNS address communicated to UEs DEFAULT DNS IPV4 ADDRESS = ” 1 31.227.100.5 ” ; # YOUR NETWORK CONFIG HERE 33 DEFAULT DNS SEC IPV4 ADDRESS = ” 1 31.227.130.5” ; # YOUR NETWORK CONFIG HERE . . . 35 } Code Listing A.9: Modified spgw.conf. For the S11 interface, we set that the address of the S-GW will be the same we told the MME before (127.0.11.2) and lo as the interface. Then, for the S1-U interface we set again vmnet8 and the IP address of the machine for this interface, as we did for S1-C in MME. As our machine gets the connection to Internet through eh0, we set that for the SGI interface 68 name. We got an error when running if PGW MASQUERADE SGI was set to “no”, so we set it to “yes”. We can check the default DNS address with the following command: nm-tool | grep DNS After that, we can build the SPGW as an executable or as a daemon following the next commands: ./build spgw --clean # For the executable ./build spgw --clean --daemon # For the daemon A.6. First run of OpenairCN A.6.0.1. Running HSS Always run HSS first. The first time we run it we need to generate the database using the following command: ./run hss -i "openairCN dir"/SRC/OAI HSS/db/oai db.sql After generating the database, we need to add the host where we have the MME in mmeidentity table (in our case, “ubuntu.openair4G.eur”). We can see this table in Figure A.6. We can know the hostname of the machine where MME is installed on with the following command: hostname -f For the following runs, we only need to use: ./run hss After running HSS, we should see the terminal like in Figure A.7. After that, we can run MME. Figure A.6: mmeidentity table. 69 Figure A.7: Example of terminal when running HSS. A.6.1. Running MME To run MME we need to use the following command: ./run mme If the connection between the MME and HSS is successful we will see STATE OPEN in the HSS terminal. In case of getting STATE ZOMBIE or some other state that is not STATE OPEN we need to check if our host is registered to the database and if the addresses and interfaces in the configuration files match each other. A.6.2. Running SPGW We can run SPGW using the next command: ./run spgw When SPGW is running, so the whole Core Network is running, we can connect eNBs to it using the Openair5G software. 70 A.7. First run of Openair5G A.7.0.1. Editing configuration file Before running oaisim we need to edit the configuration file in order to make it connect to the Evolved Packet Core. The file can be modified in the following way: gedit "openair5G dir"/targets/PROJECTS/GENERIC-LTE-EPC/CONF/ enb.band7.generic.oaisim.local mme.conf And then it should look like the following: 1/ / Tracking area code , 0x0000 and 0 x f f f e are reserved values tracking area code = ”1”; 3mobile country code = ”2 0 8 ”; mobile network code = ” 9 3 ” ; 5. . . / / / / / / / / / / MME parameters : 7mme ip address = ( {ipv4 = ”172.16.53.1”; ipv 6 = ” 1 9 2 : 1 6 8 : 3 0 : : 1 7 ” ; 9Active = ” yes ” ; preference = ” ipv4 ” ; 11 } ) ; 13 NETWORK INTERFACES : { 15 ENB INTERFACE NAME FOR S1 MME = ” eth0 ” ; ENB IPV4 ADDRESS FOR S1 MME = ”172.16 . 5 3 . 1 29/24”; 17 ENB INTERFACE NAME FOR S1U = ” eth0 ” ; ENB IPV4 ADDRESS FOR S1U = ”172.16.53.12 9 / 2 4 ” ; 19 ENB PORT FOR S1U = 2153; # Spec 2152 }; Code Listing A.10: Example of enb.band7.generic.oaisim.local mme.conf. It is very important that the tracking area code,mobile country code and mobile network code match the ones in the EPC configuration. If not, the system will not work. Afterwards, we need to set the IP address of the MME in the mme ip address section and set the interfaces and the IP address that oaisim will have in order to use S1-C and S1U. A.7.1. Running oaisim When the configuration file is properly set, we can run oaisim in the following way: ./run enb ue virt s1 -c "openair5G dir"/targets/PROJECTS/GENERIC-LTE -EPC/CONF/enb.band7.generic.oaisim.local mme.conf We can check if the eNB connects to the MME if we can see the following outputs on the terminal where MME is running. 71 78 79 D. LWA Configuration message contents 1−− ASN1START 3LWA−Configurarion−r13 : : = = CHOICE { release NULL, 5setup SEQUENCE { lwa−Config−r13 LWA−Config−r13 7} } 9 LWA−Confgi−r13 ::== SEQUENCE { 11 lwa−M ob ilityConfi g −r13 WLAN−M obilityCon fi g −r13 OPTIONAL, −− Need ON lwa−WT−Counter−r13 INTEGER (0..655 3 5) OPTIONAL, −− Need ON 13 } Code Listing D.1: LWA-Configuration message contents. LWA-Configuration field descriptions: •lwa-MobilityConfig: Indicates the parameters used by WLAN mobility. •lwa-WT-Counter: Indicates the parameter used by UE for WLAN authentication. 80 Glossary 3GPP 3rd Generation Partnership Program. 22, 23, 26, 28 5GIC 5G Innovation Centre. 10, 46 AC Access Controller. 23, 25 AP Access Point. 21–23, 25, 26, 41, 42, 45–48, 51 AS Access Stratum. 17, 18 ASN.1 Abstract Syntax Notation One. 32, 33, 40 BSS Basic Service Set. 20, 41, 42, 44 CDMA Code Division Multiple Access. 14 CMAS Commercial Mobile Alert System. 15 CN Core Network. 23 CSMA/CA Carrier Sense Multiple Access / Collision Avoidance. 20–22, 26, 41, 44, 45 CTS Clear To Send. 21 DCF Distributed Coordination Function. 20, 21, 81 DIFS DCF Interframe Space. 21, 44, 45 DL downlink. 23, 46–48 DRB Dedicated Radio Bearer. 16, 18, 38 E-UTRAN Evolved UTRAN. 15, 16, 26, 27 EAB Extended Access Barring. 15, 16 EDGE Enhanced Data rates for GSM Evolution. 14, 81 EMM EPS Mobility Management. 18 eNB Evolved Node B. 14, 15, 18, 19, 23, 25–28, 34, 36, 38, 40, 49 EPC Evolved Packet Core. 17, 26, 27 EPS Evolved Packet System. 17, 81 ETWS Earthquake and Tsunami Warning System. 14–16 FCS Frame Check Sequence. 44, 47 FTP File Transfer Protocol. 23 GERAN GSM EDGE Radio Access Network. 14 81 GSM Universal Mobile Telecommunications System. 14, 81 HSPA High-Speed Packet Access. 13 HSS Home Subscriber Server. 16, 17, 27 HT High Throughput. 46, 48 IEEE Institute of Electrical and Electronics Engineers. 10, 11, 13, 19, 20, 23, 26, 28, 29, 44, 46–48, 51 IMSI International Mobile Subscriber Identity. 16 IP Internet Protocol. 13, 22, 28, 82, 84 IPsec IP security. 10, 82 ISM Industrial, Scientific and Medical. 19, 20 ITU International Telecommunication Union. 13 LTE Long Term Evolution. 10, 11, 13, 15, 16, 22, 23, 26, 28, 47, 49, 51, 52, 82 LTE-A LTE Advanced. 13 LWA LTE-WLAN Aggregation. 10, 13, 22, 23, 25, 26, 28, 36, 37, 40, 51, 52, 82 LWAAP LWA Adaptation Protocol. 23 LWIP LTE WLAN integration with IPsec tunnel. 10, 23 MAC Media Access Control. 20, 23 MBMS Multimedia Broadcast Multicast Service. 13, 15 MBSFN Multicast-Broadcast Single Frequency Network. 15 MCS Modulation and Coding Scheme. 46 MIB Master Information Block. 14, 15 MIMO Multiple In Multiple Out. 9, 13 MME Mobility Management Entity. 16–18, 27 MSC Message Sequence Chart. 29, 73 NAS Non Access Stratum. 14, 16, 17 OAI OpenAirInterface. 10, 11, 16, 26–29, 32, 33, 36, 37, 41, 47, 49–52 OFDMA Orthogonal Frequency Division Multiple Access. 13 OPEX Operating Expenses. 9 OSA OpenAirInterface Software Alliance. 26 OSI Open Systems Interconnection. 32 82 P-GW PDN Gateway. 17, 27 PBCH Physical Broadcast Channel. 14 PCF Point Coordinated Function. 21 PDCCH Physical Downlink Control Channel. 29 PDCP Packet Data Convergence Protocol. 22, 23 PDN Public Data Network. 17, 83 PDSCH Physical Downlink Shared Channel. 14, 15 PDU Protocol Data Unit. 23 PLMN Public Land Mobile Network. 14 PRB Physical Resource Block. 15 QoS Quality of Service. 17, 19 RAN Radio Access Network. 23 RRC Radio Resource Control. 14, 18, 26, 32, 37, 40 RRM Radio Resource Measurement. 20 RTS Request To Send. 21 S-GW Serving Gateway. 18, 19, 27 SAI Service Area Identifier. 15 SC-PTM Single Cell Point To Multipoint. 15 SDR Software-defined Radio. 27 SFN System Frame Number. 16 SI System Information. 13, 15, 16 SIB System Information Block. 10, 11, 13–16, 26–29, 32, 34–40, 49, 51, 52 SSID Service Set Identifier. 44 STA station. 21, 22, 41, 42, 45–48, 51 TA Tracking Area. 17 TU Time Units. 22, 44, 45, 47, 48, 51 UE User Equipment. 14–18, 22, 23, 25–28, 35–37, 39, 41, 49, 52, 80 UL uplink. 14, 17 UMTS Universal Mobile Telecommunications System. 13, 14, 84 UTC Coordinated Universal Time. 15 83 UTRAN UMTS Terrestrial Radio Access Network. 14, 15, 81 V2X Vehicle-To-Everything. 15 VoIP Voice over IP. 13 WiMAX Worldwide Interoperability for Microwave Access. 28 WLAN Wireless Local Area Network. 10, 15, 19–23, 25, 26, 28, 42, 49, 51, 52, 80, 84 WT WLAN Termination. 23, 25 84