From the Book:
“Clean code that works” is Ron Jeffries’ pithy phrase. The goal is clean code that works, and for a whole bunch of reasons:
Clean code that works is a predictable way to develop. You know when you are finished, without having to worry about a long bug trail.Clean code that works gives you a chance to learn all the lessons that the code has to teach you. If you only ever slap together the first thing you think of, you never have time to think of a second, better, thing. Clean code that works improves the lives of users of our software.Clean code that works lets your teammates count on you, and you on them.Writing clean code that works feels good.But how do you get to clean code that works? Many forces drive you away from clean code, and even code that works. Without taking too much counsel of our fears, here’s what we do—drive development with automated tests, a style of development called “Test-Driven Development” (TDD for short). 
In Test-Driven Development, you:
Write new code only if you first have a failing automated test.Eliminate duplication.

Two simple rules, but they generate complex individual and group behavior. Some of the technical implications are:You must design organically, with running code providing feedback between decisionsYou must write your own tests, since you can’t wait twenty times a day for someone else to write a testYour development environment must provide rapid response to small changesYour designs must consist of many highly cohesive, loosely coupled components, just to make testing easy

The two rules imply an order to the tasks ofprogramming:
1. Red—write a little test that doesn’t work, perhaps doesn’t even compile at first
2. Green—make the test work quickly, committing whatever sins necessary in the process
3. Refactor—eliminate all the duplication created in just getting the test to work


Red/green/refactor. The TDD’s mantra.

Assuming for the moment that such a style is possible, it might be possible to dramatically reduce the defect density of code and make the subject of work crystal clear to all involved. If so, writing only code demanded by failing tests also has social implications:
If the defect density can be reduced enough, QA can shift from reactive to pro-active workIf the number of nasty surprises can be reduced enough, project managers can estimate accurately enough to involve real customers in daily developmentIf the topics of technical conversations can be made clear enough, programmers can work in minute-by-minute collaboration instead of daily or weekly collaborationAgain, if the defect density can be reduced enough, we can have shippable software with new functionality every day, leading to new business relationships with customers


So, the concept is simple, but what’s my motivation? Why would a programmer take on the additional work of writing automated tests? Why would a programmer work in tiny little steps when their mind is capable of great soaring swoops of design? Courage.
Courage
Test-driven development is a way of managing fear during programming. I don’t mean fear in a bad way, pow widdle prwogwammew needs a pacifiew, but fear in the legitimate, this-is-a-hard-problem-and-I-can’t-see-the-end-from-the-beginning sense. If pain is nature’s way of saying “Stop!”, fear is nature’s way of saying “Be careful.” Being careful is good, but fear has a host of other effects:
Makes you tentativeMakes you want to communicate lessMakes you shy from feedbackMakes you grumpy

None of these effects are helpful when programming, especially when programming something hard. So, how can you face a difficult situation and:
Instead of being tentative, begin learning concretely as quickly as possible.Instead of clamming up, communicate more clearly.Instead of avoiding feedback, search out helpful, concrete feedback.(You’ll have to work on grumpiness on your own.) 

Imagine programming as turning a crank to pull a bucket of water from a well. When the bucket is small, a free-spinning crank is fine. When the bucket is big and full of water, you’re going to get tired before the bucket is all the way up. You need a ratchet mechanism to enable you to rest between bouts of cranking. The heavier the bucket, the closer the teeth need to be on the ratchet.

The tests in test-driven development are the teeth of the ratchet. Once you get one test working, you know it is working, now and forever. You are one step closer to having everything working than you were when the test was broken. Now get the next one working, and the next, and the next. By analogy, the tougher the programming problem, the less ground should be covered by each test.

Readers of Extreme Programming Explained will notice a difference in tone between XP and TDD. TDD isn’t an absolute like Extreme Programming. XP says, “Here are things you must be able to do to be prepared to evolve further.” TDD is a little fuzzier. TDD is an awareness of the gap between decision and feedback during programming, and techniques to control that gap. “What if I do a paper design for a week, then test-drive the code? Is that TDD?” Sure, it’s TDD. You were aware of the gap between decision and feedback and you controlled the gap deliberately.

That said, most people who learn TDD find their programming practice changed for good. “Test Infected” is the phrase Erich Gamma coined to describe this shift. You might find yourself writing more tests earlier, and working in smaller steps than you ever dreamed would be sensible. On the other hand, some programmers learn TDD and go back to their earlier practices, reserving TDD for special occasions when ordinary programming isn’t making progress.

There are certainly programming tasks that can’t be driven solely by tests (or at least, not yet). Security software and concurrency, for example, are two topics where TDD is not sufficient to mechanically demonstrate that the goals of the software have been met. Security relies on essentially defect-free code, true, but also on human judgement about the methods used to secure the software. Subtle concurrency problems can’t be reliably duplicated by running the code.

Once you are finished reading this book, you should be ready to:
Start simplyWrite automated testsRefactor to add design decisions one at a time

This book is organized into three sections.
An example of writing typical model code using TDD. The example is one I got from Ward Cunningham years ago, and have used many times since, multi-currency arithmetic. In it you will learn to write tests before code and grow a design organically.An example of testing more complicated logic, including reflection and exceptions, by developing a framework for automated testing. This example also serves to introduce you to the xUnit architecture that is at the heart of many programmer-oriented testing tools. In the second example you will learn to work in even smaller steps than in the first example, including the kind of self-referential hooha beloved of computer scientists.Patterns for TDD. Included are patterns for the deciding what tests to write, how to write tests using xUnit, and a greatest hits selection of the design patterns and refactorings used in the examples.

I wrote the examples imagining a pair programming session. If you like looking at the map before wandering around, you may want to go straight to the patterns in Section 3 and use the examples as illustrations. If you prefer just wandering around and then looking at the map to see where you’ve been, try reading the examples through and refering to the patterns when you want more detail about a technique, then using the patterns as a reference.

Several reviewers have commented they got the most out of the examples when they started up a programming environment and entered the code and ran the tests as they read.

A note about the examples. Both examples, multi-currency calculation and a testing framework, appear simple. There are (and I have seen) complicated, ugly, messy ways of solving the same problems. I could have chosen one of those complicated, ugly, messy solutions to give the book an air of “reality.” However, my goal, and I hope your goal, is to write clean code that works. Before teeing off on the examples as being too simple, spend 15 seconds imagining a programming world in which all code was this clear and direct, where there were no complicated solutions, only apparently complicated problems begging for careful thought. TDD is a practice that can help you lead yourself to exactly that careful thought.

Test Driven Development: By Example

Despite the evolution of cellular networks, spectrum scarcity and the lack of intelligent and autonomous capabilities remain a cause for concern. These problems have resulted in low network capacity, high signaling overhead, inefficient data forwarding, and low scalability, which are expected to persist as the stumbling blocks to deploy, support and scale next-generation applications, including smart city and virtual reality. Fifth-generation (5G) cellular networking, along with its salient operational characteristics—including the cognitive and cooperative capabilities, network virtualization, and traffic offload—can address these limitations to cater to future scenarios characterized by highly heterogeneous, ultra-dense, and highly variable environments. Cognitive radio (CR) and cognition cycle (CC) are key enabling technologies for 5G. CR enables nodes to explore and use underutilized licensed channels; while CC has been embedded in CR nodes to learn new knowledge and adapt to network dynamics. CR and CC have brought advantages to a cognition-inspired 5G cellular network, including addressing the spectrum scarcity problem, promoting interoperation among heterogeneous entities, and providing intelligence and autonomous capabilities to support 5G core operations, such as smart beamforming. In this paper, we present the attributes of 5G and existing state of the art focusing on how CR and CC have been adopted in 5G to provide spectral efficiency, energy efficiency, improved quality of service and experience, and cost efficiency. This main contribution of this paper is to complement recent work by focusing on the networking aspect of CR and CC applied to 5G due to the urgent need to investigate, as well as to further enhance, CR and CC as core mechanisms to support 5G. This paper is aspired to establish a foundation and to spark new research interest in this topic. Open research opportunities and platform implementation are also presented to stimulate new research initiatives in this exciting area.

Cognition-Inspired 5G Cellular Networks: A Review and the Road Ahead

This paper demonstrates the use of Universal Software Radio Peripheral (USRP), together with Raspberry Pi3 B+ (RP3) as the brain (or the decision making engine), to develop a distributed wireless network in which nodes can communicate with other nodes independently and make decision autonomously. In other words, each USRP node (i.e., sensor) is embedded with separate processing units (i.e., RP3), which has not been investigated in the literature, so that each node can make independent decisions in a distributed manner. The proposed testbed in this paper is compared with the traditional distributed testbed, which has been widely used in the literature. In the traditional distributed testbed, there is a single processing unit (i.e., a personal computer) that makes decisions in a centralized manner, and each node (i.e., USRP) is connected to the processing unit via a switch. The single processing unit exchanges control messages with nodes via the switch, while the nodes exchange data packets among themselves using a wireless medium in a distributed manner. The main disadvantage of the traditional testbed is that, despite the network being distributed in nature, decisions are made in a centralized manner. Hence, the response delay of the control message exchange is always neglected. The use of such testbed is mainly due to the limited hardware and monetary cost to acquire a separate processing unit for each node. The experiment in our testbed has shown the increase of end-to-end delay and decrease of packet delivery ratio due to software and hardware delays. The observed multihop transmission is performed using device-to-device (D2D) communication, which has been enabled in 5G. Therefore, nodes can either communicate with other nodes via: (a) a direct communication with the base station at the macrocell, which helps to improve network performance; or (b) D2D that improve spectrum efficiency, whereby traffic is offloaded from macrocell to small cells. Our testbed is the first of its kind in this scale, and it uses RP3 as the distributed decision-making engine incorporated into the USRP/GNU radio platform. This work provides an insight to the development of a 5G network.

/pdf/a-distributed-testbed-for-5g-scenarios-an-experimental-study-43xf15r22v.pdf

A Distributed Testbed for 5G Scenarios: An Experimental Study

The Interference Rejection Combining (IRC) receiver can significantly boost the network throughput in scenarios characterized by dense uncoordinated deployment of small cells, as targeted by future 5th generation (5G) radio access technology. This paper presents an experimental study on the potential benefit of IRC receiver in real deployment scenarios. The study is carried out using a software defined radio (SDR) testbed network with four cells, each featuring one Access Point (AP) and one User Equipment (UE) with two antennas. The testbed network was placed in an indoor office and open hall scenarios, respectively. In each scenario, the cells were arranged to characterize the propagation in different spatial configurations. Using the obtained propagation data, we analysed the cases of closed and open subscriber group for the respective scenarios, to compare the achievable throughput with IRC and Maximum Ratio Combining (MRC) receivers. Different frequency reuse schemes were also considered. The throughput results confirm the effectiveness of the IRC receiver in improving the network throughput with respect to the MRC receiver, under the assumption of single stream (rank 1) transmission. Results show average gains up to around 40% and outage gains up to 70% over the MRC receiver. The combination of the IRC receiver and frequency reuse achieves a favourable trade-off between the network throughput and fairness. Overall, due to the direct propagation, the open hall open subscriber group scenario is benefiting the most from the ability of the IRC receiver to cancel a strong dominant interferer.

Experimental evaluation of interference rejection combining for 5G small cells

Notwithstanding the value of Long Term Evolution (LTE) towards an improved user experience in next-generation networks, its associated high complexity is known to place computational and time burdens on testing tasks involving real-world platforms. Simulation is currently the tool most widely used to tackle this issue. LENA, for instance, is an open source simulator based on ns-3 that allows the design, evaluation, and validation of LTE networks. Despite of modeling the main LTE elements and interfaces, one limitation of LENA is that it docs not support the use of external traffic entities in conjunction with the simulation. In this paper, we describe how the ns-3 LENA LTE framework can be customized for use in an emulation-based test environment that allows a wider variety of real-world applications to be run over the simulated links. To validate our emulation results, we use as benchmark a testbed that differs from the aforementioned test environment in that the ns-3 server running the simulated network is replaced with a network made up of real-world platforms. Initial validation results, based on limited tests using an industry-standard VoIP test tool and iperf throughput tool, demonstrate that ns-3 LTE models can deliver voice quality and latency as good as an experimental testbed using actual LTE equipment over a range of signal-to-noise ratios. Similar conclusions arc also drawn for throughput, thus confirming the suitability of our emulation approach as a viable means to predict performance in real LTE networks. The good agreement of our experimental results is possible not only because the same functionality is implemented in both experiments but due to the use of the same traffic generation tools in the simulated and real-world LTE networks not -- possible in standard LENA simulation.

/pdf/performance-comparison-of-a-custom-emulation-based-test-28iplz6bdw.pdf

Performance comparison of a custom emulation-based test environment against a real-world LTE testbed

Network synchronization is a fundamental enabler of interference mitigation techniques that are required in ultradense deployment of small cells as targeted by upcoming 5th Generation (5G) wireless system. In this paper, we experimentally evaluate the possibility of acheiving in a distributed manner (i.e. without any external high precision reference clocks) a tight time alignment in a network of small cells. We are considering a software defined radio (SDR) network of 8 nodes, where each node adopts the Universal Software Radio Peripheral N200 (USRP N200) radio boards by Ettus Research, and the ASGARD software platform. Experimental results demonstrate the possibility of synchronizing the timing of the multiple nodes with a few μs precision, despite of the occurrencies of beacon losses.

Distributed Synchronization of a testbed network with USRP N200 radio boards

Research on intelligent and reconfigurable wireless systems is in continuous evolution. Nevertheless, in order to fix some keystones, more and more researchers are entering the idea of research-oriented test beds. Unfortunately, it is very difficult for a wide number of research groups to start with their own set up, since the potential costs and efforts could not pay back in term of expected research results. Software Defined Radio solutions offer an easy way to communication researchers for the development of customized research test beds. While several hardware products are commercially available, the software is most of the times open source and ready to use for third party users. Even though the software solution developers claim complete easiness in the development of custom applications, in reality there are a number of practical hardware and software issues that research groups need to face, before they are up and running in generating results. With this chapter we would like to provide a tutorial guide, based on direct experience, on how to enter in the world of test bed-based research, providing both insight on the issues encountered in every day development, and practical solutions. Finally, an overview on common research-oriented software products for SDR development, namely GNU Radio, Iris, and ASGARD, will be provided, including how to practically start the software development of simple applications. Finally, best practices and examples of all the software platforms will be provided, giving inspiration to researchers on how to possibly build their own customized systems.

Designing a CR Test bed: Practical Issues

The characteristics of the deployment scenario are fundamental elements in the performance evaluation of wireless networks inter-cell interference coordination (ICIC) schemes. The statistical validation of such concepts is typically achieved by means of system-level simulation campaigns where regular reference scenarios and stochastic channel models are employed. It is an important next step to verify that the trends observed in the reference scenarios compare equally well in more practical deployments. For such comparison, it is required to evaluate an extensive set of link conditions, reflecting the many possible configurations that can be experienced in a practical scenario. In this paper we adopt an experimental procedure, using a software defined radio testbed, for acquiring almost 1000 different radio link conditions between the nodes of a relevant wireless indoor network scenario. The acquired measurements, were used as input to a system level simulator in order to evaluate the performance of a local area decentralized ICIC scheme. The obtained performance results highlight the contribution of the selected scheme and provide a new insight for the validation of the related simulation-based studies, previously published in literature.

/pdf/validation-of-an-inter-cell-interference-coordination-46hqihg9dz.pdf

Validation of an Inter-Cell Interference Coordination Solution in Real-World Deployment Conditions

User Equipments (UEs) which support simultaneous activity from Multiple Active Subscriber Identities (Multi-SIM) has gained popularity within the last years. Such UEs are forced to discard data on one of the SIMs when both try to access the Radio Frequency (RF) interface simultaneously, creating gaps in the data transfer. The discarded data due to Multi-SIM gaps, along with channel errors, significantly increase the probability of high latency data subframes. High latency increases the probability of data subframes being discarded. In this paper we present an algorithm with which it is possible to decrease the probability of discarded data subframes due to high latency. The algorithm takes advantage of the fact that the connections of each SIMs are unaligned and therefore gaps will only cover some timeslots partially. In such a case, it is possible to recover data using existing error correction coding, if the amount of corrupted bits corresponds to the error correction capability of the code. We investigate the performance of the algorithm using a link level simulator in respect to KPIs; overall throughput, decrease in subframe loss probability, and block error rate. The algorithm is tested in three different radio conditions as they comprise different restrictions to the algorithm. We show how the algorithm significantly decreases the subframe loss probability due to Multi-SIM, without significant impact on the overall throughput.

CQI Reporting Strategy for Multi-SIM UEs

The number of User Equipments (UEs) with multiple active subscriber identities (Multi-SIM) will increase throughout the coming years. The requirement in such UEs for each of the Subscriber Identity Modules (SIMs) to have parallel network access, invoke access conflicts on baseband/RF level. These conflicts ends up in one or more of the inserted SIMs being denied access for brief period of time, usually on the scale of tenths of milliseconds repeated every half to two minutes. These Multi-SIM conflicts are analysed using a combination of link level, and frame based simulation. The simulation clarifies the impact of Global System for Mobile (GSM)-like idle mode operations conflicting with an active Long Term Evolution (LTE) connection. The presented results show the effect Multi-SIM has on Radio Link Control (RLC) Unacknowledged Mode (UM) Service Data Unit (SDU) drop rate, and Acknowledge Mode (AM) SDU arrival time. It is shown that the impact of Multi-SIM on the drop rate and arrival time of the SDUs is based not only on the amount of conflicts between the SIMs, but also on the time alignment between the basestations retransmission timing strategy and the placement of the conflicts in time. The results may prove as base for discussions on some requirements to the basestations network configuration and performance.

Jakob L. Buthler

Papers

Distributed Synchronization of a testbed network with USRP N200 radio boards

Designing a CR Test bed: Practical Issues

Validation of an Inter-Cell Interference Coordination Solution in Real-World Deployment Conditions

CQI Reporting Strategy for Multi-SIM UEs

RLC SDU Loss and Arrival Delay in Multi-SIM UEs