Introduction

During the last few years, wireless data traffic has skyrocketed, driven mainly by a large penetration of smart phones and devices. In 2013, an exabyte of data traveled across the global mobile network monthly [1]. By 2020, data traffic served by such networks is expected to increase by up to a factor of 100, including traffic generated by the widespread adoption of device–device (D2D) and the Internet of Things (IoT) connected via machine–machine (M2M) communications. It is widely recognized that this general trend toward more explosive growth may accelerate even further in future, and how to meet such a demand has been one of the most active and rapidly growing areas in the wireless communication community in the past decade in terms of both academic and industrial research and development [2].

Facing the unprecedented challenge, the wireless communication community has considered many candidate solutions. A significant portion of these are focused on increasing the communication resources, e.g., deploying more network nodes, which leads to densification of existing networks, utilizing wider bandwidth, increasing antenna numbers, and employing additional resources to offload. Among them, the dense network approach stands out for its high scalability of providing magnitudes of capacity increase. Extensive research has been devoted to dense networks (see e.g., [3–8] and references therein).

Indeed, commercial wireless networks are already becoming denser and dense-network deployment will be a critical factor (together with other solutions) to meet the ever-increasing traffic demand. The trends for traffic and network-density growth over a 20-year span are illustrated in Figure 5.1.

In Figure 5.1, the network densities for the years 2000 to 2015 were estimated from 3GPP publications (e.g., [3, 9], etc.), whereas the network density for year 2020 is a projection based on historic data and recent trends. In more detail, around year 2000, sparse 3G network deployments of macro base stations covered wide areas with typical cell radii of several kilometers. Starting from around 2005, the network density increased to about 10 to 20 nodes/km2 and cell radii shrunk to between one kilometer and several hundreds of meters, according to the study in 3GPP LTE Rel-8/9; however, macro eNBs (evolved NodeB, also known as base stations, BS, BTS, etc.) were still the main focus.

FLOW-TABLE ANALYSIS

Recall from Section 14.1 that an asynchronous sequential circuit is formed when a feedback path is placed around combinational logic, as shown in Figure 26.1(a). To analyze such circuits, we break the feedback path as shown in Figure 26.1(b) and write the equations for the next-state variables as a function of the current-state variables and the inputs. We can then reason about the dynamics of the circuit by exploring what happens when the current-state variables are updated (in arbitrary order if multiple bits change) with their new values.

INTERFACE TIMING

Interface timing is a convention for sequencing the transfer of data. To transfer a datum from a source module S to a destination module D, we need to know when the datum is valid (i.e., when the source module S has produced the datum and placed it on its interface pins) and when D is ready to receive the datum (i.e., when D samples the datum from its interface pins). We have already seen examples of interface timing in the interfaces between the modules of factored state machines in Chapter 17. In the remainder of this section, we look at interface timing in more depth.

Always valid timing

As the name implies, an always valid signal (Figure 22.1), is always valid. An interface with only always valid signals does not require any sequencing signals.

It is important to distinguish an always valid signal from a periodically valid signal (Section 22.1.2) with a period of one clock cycle. An always valid signal represents a value that can be dropped or duplicated. A temperature sensor that constantly outputs an eight-bit digital value representing the current temperature is an example of such a signal. We could pass this signal to a module operating at twice the clock rate (duplicating temperature signals) or a module operating at half the clock rate (dropping temperature values), and the output of the module still represents the current temperature (with perhaps a slight lag).

The state interfaces in the Pong game of Figure 21.2 are another example of always valid interfaces. The mode, ballPos, leftPadY, rightPadY, and score signals are all examples of always valid signals. Each of these signals always represents the current value of a state variable.

PROPAGATION AND CONTAMINATION DELAY

In a synchronous system, logic signals advance from the stable state at the end of one clock cycle to a new stable state at the end of the next clock cycle. Between these two stable states, they may go through an arbitrary number of transitions.

In analyzing timing of a logic block we are concerned with two times. First, we would like to know for how long the output retains its initial stable value (from the last clock cycle) after an input first changes (in the new clock cycle).We refer to this time as the contamination delay of the block – the time it takes for the old stable value to become contaminated by an input transition. Note that this first change in the output value does not in general leave the output in its new stable state. The second time we would like to know is how long it takes the output to reach its new stable state after the input has stopped changing. We refer to this time as the propagation delay of the block – the time it takes for the stable value of the input to propagate to a stable value at the output.

BASIC PIPELINING

Suppose you have a factory that assembles toy cars. Assembling each car takes four steps. In step 1 the body is shaped from a block of wood. In step 2 the body is painted. In step 3 the wheels are attached. Finally, in step 4, the car is placed in a box. Suppose each of the four steps takes 5 minutes. With one employee, your factory can assemble one toy car every 20 minutes. With four employees your factory can assemble one car every 5 minutes in one of two ways. You could have each employee perform all four steps – producing a toy car every 20 minutes. Alternatively, you could arrange your employees in an assembly line with each employee performing one step and passing partially completed cars down to the next employee.

In a digital system, a pipeline is like an assembly line. We take an overall task (like building a toy car) and break it into subtasks (each of the four steps).We then have a separate unit, called a pipeline stage (like each employee along the assembly line), performing each task. The stages are tied together in a linear manner so that the output of each unit is the input of the next unit – like the employees along the assembly line passing their output (partially assembled cars) to the next employee down the line.

This book uses VHDL syntax features from the most recent standard, VHDL-2008, that enable greater designer productivity and are supported by the FPGA CAD tools typically used in introductory courses on digital design. Many CAD tools by default still assume an earlier version of VHDL even though they have support for VHDL-2008. Hence, you should consult your CAD tool's documentation to learn how to enable support for VHDL-2008 before trying the examples in this book.

To keep descriptions brief yet precise Extended Backus-Naur Form (EBNF) is employed in this appendix. Non-terminals are surrounded by angle brackets (“<” and “>”) and definitions of non-terminals are denoted by the symbol “::=”. A list of choices is separated by a pipe symbol (“|”) and the interpretation is that only one of the items should appear. Zero or more repetitions of a construct are indicated by surrounding the construct with curly braces (“{” and “}”). An optional construct (i.e., zero or one instances) is indicated by surrounding it with square brackets (“[” and “]”). The EBNF descriptions in this appendix are simplified versions of those found in the VHDL language standard [55]. The simplified EBNF descriptions here correspond to the VHDL syntax subset commonly used for synthesis.

The use of hardware description languages (HDLs) for hardware design differs from the use of programming languages for software development. Software is implemented by converting a program written in a programming language into computer instructions that then appear to execute one at a time.

SIMPLE MICROCODED FSM

Figure 18.1 shows a block diagram of a simple microcoded FSM. A memory array holds the next-state and output functions. Each word of the array holds the next state and output for a particular combination of input and current state. The array is addressed by the concatenation of the current state and the inputs. A pair of registers holds the current state and current output.

In practice, the memory could be realized as a RAM or EEPROM allowing software to reprogram the microcode. Alternatively, the memory could be a ROM. With a ROM, a new mask set is required to reprogram the microcode. However, this is still advantageous because changing the program of the ROM does not otherwise alter the layout of the chip. Some ROM designs even allow the program to be changed by altering only a single metal-level mask – reducing the cost of the change. Some designs take a hybrid approach, putting most of the microcode into ROM (to reduce cost) but keeping a small portion of microcode in RAM. A method is provided to redirect an arbitrary state sequence into the RAM portion of the microcode to allow any state to be patched using the RAM.

Introduction

In cellular networks, handover refers to the mechanism by which the set of radio links between an active mode mobile device and base station cells is modified. Mobility in the idle mode (when the mobile has no data bearers established and is not transmitting or receiving user plane traffic), termed cell selection/reselection, typically ensures that the UE selects the strongest available cell in preparation for an outgoing or incoming call/data session. Handover reliability is a key performance indicator (KPI) since it directly impacts the perceived quality of experience (QoE) of the end user. In contrast, cell reselection is less important since no bearers are established and suboptimal performance is apparent only on call establishment and as a signaling cost to the network operator. For this reason, the remainder of this chapter focuses on handover.

In GSM and LTE the mobile supports only a single radio link such that the handover swaps this link from one cell (the serving cell) to another (the target cell). In WCDMA, however, multiple links (on the same frequency) may be established (known as “soft handover”). Handovers can be classified as:

• intra-RAT, meaning within the same radio access technology (RAT), for example, LTE to LTE

1. • intra-frequency (serving and target cells are on the same frequency)

2. • inter-frequency (serving and target cells are not on the same frequency)

• inter-RAT

1. • between cells of different RATs.

Handover may be triggered for a number of reasons:

1. • to maintain the connectivity of the mobile and support data transfer (often called a “coverage handover”)

2. • to balance the loading of cells with overlapping coverage or to handover a mobile between overlapping cells to ensure data rates demanded by an ongoing service are met (often called a “vertical handover”).

Vertical handovers target stationary mobiles, implying that the radio conditions of links to serving and target cells are relatively stable. More challenging are coverage handovers that result from the motion of the mobile, leaving the coverage of the serving cell and entering that of the target cell. Since indoor users are usually stationary, the focus of coverage handovers is on outdoor users, on foot or in vehicles.

When you first start to program your emphasis is usually on correctness, that is, getting your programs to run and return accurate and error-free results - and rightly so. There is little point in trying to speed up a program that returns incorrect answers! You develop your programs, prototyping with simple inputs so that you can see at a glance how things are progressing. At some point in the development process you start to increase the size or complexity of the inputs to your program and, if all goes well, the program scales well. But commonly, there are bottlenecks at various stages of the computation that slow things down; or there may be a large increase in the amount of memory needed to represent or store an expression or result. Some of these situations may be unavoidable, but often you can find optimizations that improve the efficiency and running time of your programs. This chapter introduces some of the optimization principles to think about both during the development process and after your programs are complete and you are satisfied that they produce the desired output.

How, you might ask, does one quantify efficiency? There are two measures we will focus on - timing and memory footprint. The importance of these two measures is highly subjective. Squeezing another tenth of a second out of a computation that is only going to be run once or twice does not make a lot of sense. However, if that computation is part of a loop that is going to be evaluated thousands of times, little things really start to add up. You will be the best judge of where to focus your efforts.

SWITCH LOGIC

In digital systems we use binary variables to represent information and switches controlled by these variables to process information. Figure 4.1 shows a simple switch circuit. When binary variable a is false (0), Figure 4.1(a), the switch is open and the light is off. When a is true (1), the switch is closed, current flows in the circuit, and the light is on (Figure 4.1(b)).

THE DESIGN PROCESS

As in other fields of engineering, the digital design process begins with a specification. The design then proceeds through phases of concept development, feasibility, partitioning, and detailed design. Most texts, like this one, deal with only the last two steps of this process. To put the design and analysis techniques we will learn into perspective, we will briefly examine the other steps here. Figure 2.1 gives an overview of the design process.

After you have developed several programs for some related tasks, you will find it convenient to group them together and make them available as a cohesive whole. Packages are designed to make it easy to distribute your programs to others, but they also provide a framework for you to write programs that integrate with Mathematicaseamlessly.

A package is simply a text file containing Mathematicacode. Typically you put related functions in a package. So there might be a computational geometry package or a random walks package that includes functions in support of those tasks. The package framework includes a name-localizing construct, analogous to Module, but for entire files of definitions. The idea is to allow you, the programmer, to define a collection of functions for export.These exported functions are what the users of your package will work with and are often referred to as publicfunctions. Other functions, those that are not for export,are auxiliary, or privatefunctions, and are not intended to be accessible to users. The package framework, and contexts specifically, provide a convenient way to declare some functions public and others private. In this chapter we will describe this framework and show how to write, install, and use the packages developed with it.

Working with packages

Loading and using packages

Upon starting a Mathematicasession, the built-in functions are immediately available for you to use. There are, however, many more functions that you can access that reside in files supplied with Mathematica.The definitions in those files are placed in special structures called packages.Indeed, these files themselves are often called “packages” instead of “files.”

Mathematicapackages have been written for many different domains. They are provided with each version of Mathematicaand are referred to as the Standard Extra Packages. Their documentation is available in the Documentation Center (under the Help menu) and they provide a good set of examples for learning about package creation and usage.

The idea of representing an idealized version of an object with something called a pattern is central to mathematics and computer science. For the purposes of search, patterns provide a template with which to compare expressions. They can be used to filter data by selecting only those parts that match the pattern. Because of the wide applicability of patterns, many modern programming languages have extensive pattern-matching capabilities that enable them to identify objects that meet some criteria in order to classify, select, or transform those objects through the use of rules.

Pattern matching in Mathematica is done through a powerful yet flexible pattern language. Used in rules to transform expressions from one form to another, they can be applied to broad classes of expressions or they can be limited to very narrowly-defined objects through the use of conditional and structured pattern matching. Pattern matching is the key to identifying which rules should be applied to expressions that you wish to transform.

If you have used regular expressions in languages such as Perl or Ruby, or via libraries in Java, Python, or C++, then you are already familiar with pattern matching on strings (discussed further in Chapter 7). Mathematica's pattern language generalizes this to arbitrary objects and expressions. Although the syntax may be new to you, with practice it becomes natural, providing a direct connection between the statement of a problem and its expression in a program. This chapter starts with an introduction to patterns and pattern matching and then proceeds to a discussion of transformation rules in which patterns are used to identify the parts of an expression that are to be transformed. The chapter concludes with several concrete examples that make use of pattern matching and transformation rules to show their application to some common programming tasks.

Lists are the key data structure used in Mathematica to group objects together. They share some features with arrays in other languages such as C and Java, but they are more general and can be used to represent a wide range of objects: vectors, matrices, tensors, iterator and parameter specifications, and much more.

Because lists are so fundamental, an extensive set of built-in functions is available to manipulate them in a variety of ways. In this chapter, we start by looking at the structure and syntax of lists before moving on to constructing, measuring, and testing lists. We then introduce some of the built-in functionality used to manipulate lists such as sorting and partitioning. Finally, we will discuss associations, a feature first introduced in Mathematica 10. Associations provide a framework for efficient representation and lookup of large data structures such as associative arrays (for example, a large database of article and book references or a music library).

Many of the things you might wish to do with a list or association can be accomplished using built-in functions and the programming concepts in this book. And most of these operations extend to arbitrary expressions in a fairly natural way, as we will see in later chapters. As such, it is important to have a solid understanding of these functions before going further, since a key to efficient programming in Mathematica is to use the built-in functions whenever possible to manipulate lists and associations as well as general expressions.

Creating and displaying lists

List structure and syntax

The standard input form of a list is a sequence of elements separated by commas and enclosed in curly braces:

{e1, e2, …, en}

Internally, lists are stored in the functional form using the List function with an arbitrary number of arguments.

Mobile device data rates are increasing at effectively Moore's law [1] due to the fact that mobile devices are all integrated in silicon and thus are taking advantage of the reduction in geometry and increase in functionality and the number of transistors per die. The current cellular approach of using large outdoor base station towers to provide mobile broadband via wireless communications, however, does not scale efficiently to cope with the forecast 13-fold increase expected by 2017 [2]. Thus a need for a new approach is required. As we will discuss in this chapter, small cell deployments have the potential to provide a scalable solution to this demand where they are beginning to change the network topology into a so-called heterogeneous network (HetNet) containing a mix of different cell sizes and cell power levels, as shown in Figure 8.1. This will lead to a mix of macro cells, micro cells, pico cells, and femto cells. This deployment is not as uniform as outdoor macro cells with different cell sizes and a much more irregular deployment results.

As we will show in this chapter, small cell network (SCN) deployments provide, for the first time, a low-cost efficient scalable architecture to meet the expected demand. This technology was initially deployed in large scale when femto cells (residential small cells) were first deployed by a number of leading wireless operators (including Vodafone and AT&T). The solution was enabled by two key developments, namely:

1. • low-cost chip-sets (a so-called “system-on-chip”), which included the entire signal processing and most of the radio software stack, and

2. • high-speed internet access (greater than Mbps) was available, thus providing the so-called “backhaul” (the connectivity into the network) for these access points.

These developments mean that with volume the effective capital costs of small cells are negligible compared to the cost of deployment and operating costs.

Small cell deployments have a range of topologies and configurations that will depend on the location and the demand requirements. For example, downtown city areas will consist of a combination of small cells where they will exist:

1. on outdoor light poles to serve “hotspot” traffic needs around cafes and other places where users congregate

2. in city buildings to serve enterprise customers with high demands on throughput and reliability

3. in apartments or residential homes to serve private users' needs.