Hooman

Are Voice Packets Retransmitted in LTE?

Hooman — Mon, 17 Dec 2012 19:12:12 GMT

Once Voice Over IP (VoIP) is deployed in LTE, the provided Quality of Service (QoS) is going to be a very important factor for the success of VoLTE (Voice Over LTE). For voice services in general, the MOS (Mean Opinion Score) is the metric chosen to evaluate the subjective voice quality in the network. There is a direct relationship between the MOS score, the QoS related parameters, such as latency, and the number of voice carrying frames which are in error at the receiver end (Frame Error Rate). Typically, Frame Error Rates larger than 2% result in unacceptable voice quality and dramatically reduced MOS scores.

In wireless network the problem of dealing with erroneous transmissions in the adverse radio environment is dealt with using two basic approaches, i.e. the Forward Error Correction (FEC) and Backward Error Correction (BEC) strategies. The FEC uses redundant bits and error correcting algorithms for dealing with the problem. The idea is to protect the payload by adding redundant information that allows the receiver to reconstruct any damage that may have occurred to the payload during the transmission.

In the second strategy, known as Backward Error Correction and also known as ARQ, the errors are handled by retransmission of the erroneous packet after the receiver indicates (or lack of such an indication from the receiver after a time period!) that the packet was not received correctly. The transmitting entity will then retransmit the packet again.

There is nothing in principle that prohibits the strategies described in the above to be used in combination. In wireless, they are almost always are used together. The hybrid use of the BEC and FEC is usually referred to as HARQ. These principles have been used from the very early days of packet radio services for example in EGPRS and are used in LTE as well. With the ever increasing bit rates in the wireless networks, it has become increasingly important to reduce the accumulated latency in the HARQ and that has pushed the HARQ process to the lower layers in the protocol stack, i.e. Layer 1 and Layer 2. Indeed the modern use of the word HARQ in the 3GPP standards refers to this aspect as well, and has become synonymous with the use of BEC and FEC at the PHY and MAC layers, (with interesting additional possibilities regarding the retransmitted packets.) The round trip delay for a HARQ process is in about 8ms in LTE.

For voice packets the retransmissions cannot continue for too many rounds, since the accumulated latency becomes difficult to deal with. (Jitter and playback buffers can handle this problem only to a limit). Given that the HARQ delay is in the order of 10 ms and a voice packet usually carries 20ms worth of speech, the maximum number of retransmissions is about 2. Higher number of retransmissions may be possible with more advanced jitter and playback buffers, but not beyond one or two extra tries. Here is the crux of the matter: In LTE, HARQ operates with an acceptable error rate of up to 10% for each individual transmission over the air. The accumulated error approaches zero only because of the retransmissions and forward error correction that is used in the HARQ process. In modern implementation of HARQ, the first erroneous packet can be used to help in decoding the retransmitted packet as well! This is known as incremental redundancy. It is also important to note that in LTE one “Block” is sufficient for carrying 20ms worth of encoded speech frame.

A simplified explanation of why this level of error is tolerable, is that 10% error rate is something of a sweet spot in HARQ operations. If we strive to make HARQ operate with too little error rate, then the packets require more redundancy (or we need to spend more radio resources such as power!) On the other hand, if we go beyond 10% error rate, the throughput is impacted adversely by too many retransmissions. It is no coincidence that the 10% error rate is stipulated in the 3GPP standards as the operating point for HARQ. Fortunately, thanks to the immutable laws of probability, it takes only a few quick retransmissions at the HARQ to push down the error rate to very acceptable levels.

Now we understand why VoIP packets have to be retransmitted by the HARQ process. Recall that in the beginning we determined that an acceptable voice quality needs to have 98-99% of packets received with no error (after decoder magic has been applied). However, at the same time HARQ operates happily with error rates of 10% for each individual transmission. The conclusion is that HARQ must retransmit VoIP packets or we will be left with 10% frame error rate and a very bad voice quality!

When HARQ fails, the next safety net in LTE protocol stack is the Radio Link Control (RLC) protocol which primarily relies on the ARQ process. RLC operates in 3 modes; The Transparent (TM) mode, the Unacknowledged (UM) mode and the Acknowledged (AM) modes. Unlike 3G UMTS, voice packets in LTE are transmitted in the UM which means that they get some overhead in the form of an RLC header, (mainly for reordering out of sequence packets), but will not be retransmitted from this layer. In LTE, we expect less than 1% of retransmissions to be handled by ARQ at the RLC layer.

The final retransmission mechanism could potentially reside in the application layer and is usually handled by the TCP protocol. Since VoIP will rely on the nimbler UDP protocol and not the sophisticated TCP, no retransmissions are expected from the application layer.

In summary the answer to our question is this: YES, NO , NO from bottom up! YES at the Physical Layer, NO at the RLC layer (but VoIP packets will have RLC headers!) and NO at the Application Layer.

/Hooman

TTI Bundling and VoIP Performance in LTE - Part I

Hooman — Mon, 17 Dec 2012 18:35:48 GMT

One of the benefits of LTE is its superlative performance in the amount of payload that can be delivered in a short period of time. This is a convoluted way to say: “fantastic throughput”. Yours truly has been testing this fact, countless times by running a speed test app every night before I go to sleep! (59Mbps in DL is the maximum I have seen. I would reveal my carrier’s name if it were not for fear of the repercussions …. ;-)

The minimum allocation in LTE, spans 180KHz and 1ms in the frequency and time domains respectively (this is exactly one resource block in frequency and two resource blocks in time). This resource should be sufficient to carry a VoIP packet using coded narrow band AMR ( @ 12.2 kbps = 244 bits in 20ms). Since a VoIP packet carries 20ms worth of speech and our transmission time interval (TTI) is only 1ms, a UE that is engaged in continuous voice is only active for 5% of the time!

The efficiency of LTE can be exploited to increase the voice capacity of the cell by time-multiplexing many more users that could be scheduled in the intervening time before the first batch of users have to be scheduled again. Disregarding many realistic and important constraints, and perfect RF conditions, the theoretical capacity of voice calls per cell can be estimated as the number of users that can be scheduled in a TTI multiplied by 20. In 20MHz band there are 100 Resource Blocks and presumably one user can be scheduled per resource block in a TTI (this is far from the truth due to PDCCH limitations), then the theoretical peak capacity of LTE is around 2000 calls per cell! Even with a 50% efficiency, 1000 calls per cell is impressive.

There is another way to use the 5% activity factor in LTE that is about improving the Uplink coverage at the cost of reduced capacity. This technique is known in the 3GPP specs as TTI Bundling. In TTI bundling, the 20ms worth of speech packet is repeated in consecutive frames. Up to four TTIs can be used to send copies of the same VoIP packet over the air. But why does the uplink coverage improve when copies of a voice packet are bundled together?

To understand the impact of TTI bundling for uplink coverage, we need to remind ourselves of the uplink link budget in LTE. In fact we only need to consider how much the eNodeB sensitivity is improved when TTI bundling is used. TTI-Bundling allows for efficient decoding since it implies a four-fold redundancy in transmission without any need for retransmissions! This should decrease the required signal to noise ratio at the cell edge, without appreciable increase in latency. According to RAN1#54 report R1-081856, there is a 4dB gain in uplink coverage in when 4 TTIs are bundled together (an extra twist to this result is that it is calculated for 2 RBs which is what is needed for Wide-Band AMR transmissions).

TTI Bundling is activated in the network using Layer 3 signaling. One way to implement the activation or deactivation of TTI bundling is to consider the UE power head room. This is a strong indicator of how much the UE is struggling to close the uplink and be heard by the eNodeB at the appropriate Signal to Noise Ratio. So a simple implementation for TTI bundling algorithm could depend on thresholds for the UEs available power at any given moment in time.

In part two of this blog, I will look at the effects of delay and retransmission in TTI bundling.

/Hooman

The HetNet - Pico-cells Make a Comeback

Hooman — Sat, 22 May 2010 01:05:00 GMT

How many RATs (Radio Access Technologies) can you name? Lets see, there is GSM with 4 billion subscribers and then there is W-CDMA with its released flavors and evolutionary cousin LTE of course, a few still clinch on to their efficient 1xEVDO and its peculiar flavors, then we have the IEEE family from 802.11s and the newly launched mobile versions of those, i.e. WiM... (forbidden word in my blogs) , there are Satellite based RATs, and a few RATs facing the skies mainly aimed at commercial airliners, .... to name a few!

First, we can wonder what is going to play the bagpiper tune to which all these heterogeneous RATs will dance to in unison, (assuming there is a need for such a dance!)

One important unifying scheme that has been discussed extensively here and elsewhere is the IP Multimedia Subsystem (IMS), playing the role of a (super) glue. No matter what type of RAT is available or offered by the service provider(s), the mobile station can get to the service plane by choosing the right RAT for making the service plane connections. In the most generic scenarios, little or no Radio Resource Management is involved across these RATs and the choice of the "best" available network is a mobile device responsibility. Nevertheless, Inter-RAT handover decisions are usually made across RATs belonging to the same domain of standards or after extensive harmonization between different standardization bodies.

Most recently the term HetNet (Heterogeneous networks) is now being applied in a different sense to one RAT as a novel way to increase (data) capacity and coverage within that RAT. But in what sense can a single RAT network be heterogeneous?

A uni-RAT hetnet is a mobile wireless network where cooperating "smart" pico-cells work together within the larger Macro-cell coverage, to dramatically improve performance. The step can be seen as one that falls between the femto-cell evolution and the existing ubiquitous Macro-cell structure. To me, the core of this idea is close to the hierarchical cell-structures that have been used in the GSM networks in the past, with a new twist of increased coordination and intelligence among the pico-cells.

Many vendors such as Samsung, Ericsson, NSN, Huawei and others are very busy filing patents in this arena and see great opportunities in the US market. It is a well known fact that the North American landscape has a void in pico-cell deployments compared to European/Japanese networks. The HetNet concept is seen by these and others as a keystone in attacking the conspicuous congestion issues that are widely experienced in big cities.

An interesting and open question is about the future role of the femto-cells in the shadow of the coming HetNet pico-cells. It may turn out that the femto-cell will be pushed to a secondary niche application such as the indoor coverage problem.

The HetNet initiative is at an embryonic stage as far as the standards are concerned. Most likely the 3GPP R10 (LTE) will be the place where we will see the first standardization attempts being made. Although most of the HetNet functions are network-centric, many actors believe that the success of the HetNet will depend on standardization for allowing multi-vendor solutions. Otherwise the HetNet might face the same fate as many other good ideas that were never deployed!

/Hooman Razani

LTE Myth Busters

Hooman — Mon, 23 Nov 2009 22:23:00 GMT

Since the website face-lift a year ago, 3GPP is actively involved in more than just producing Technical Specs and Reports. I regularly read the 3GPP News column and the latest one from Nov. 4^th has the conspicuous title "Dispelling LTE Myths" . I wonder if these so called Myths are the product of competing technology campaigns or the result of self-inflicted "accidents" such as CS Fallback (CSFB) and Single Radio Voice Call Continuity (SRVCC). Well, with UMB in ruins and mobile WiMAX shrinking in size to the footprint of a loaded UMTS cell (ouch!), there is little to fear from the competition nowadays...

The article dispels four "common myths" in LTE. (1) No Voice, (2) No SMS, (3) IMS isn't ready and (4) No E911 calls. My aim in here is to enhance the descriptions with references to the 3GPP documents and add a few neutral and hopefully insightful comments.

Myth 1: No Voice in LTE. It is true that the carriers have been reluctant in throwing out their CS core and jumping on IMS as the universal all-IP service platform. For this and other reasons, LTE has full IMS solution arrives. CS-Fallback is one such solution. In CSFB the call is handed over to 2G/3G at the beginning of the call. This involves signaling between an upgraded 2G/3G MSC and the MME. IMS standards have become more VoIP friendly without compromising the emergency call requirements. Finally, one-way handover from IMS to legacy 2G/3G is supported via SRVCC. This can be done during an ongoing call. The following is a quick reference to 3GPP specs for further reading.

(For a guide about how to find your way around the 3GPP site, take a look at my earlier post)

a. CS-Fallback TS 23.272 Rel8

b. Enhanced VoIP in IMS R7 TS 23.228 and TS 24.229 Rel7

c. IMS to 2G/3G handover for voice TS 23.216 (SRVCC) Rel8

Myth 2: No SMS in LTE. SMS is supported in a couple of ways in LTE. In one approach, the SMS is carried on the user plane over IP (unlike 2G/3G for example). This is SMS over IMS and was standardized in 3GPP in Release 7. The other approach keeps SMS on the control plane and uses the new SGs interface between the MMEs and at least one MSC that is upgraded with the required protocol. Even supplementary services (SS) can be supported in either way.

d. SMS over IP TS 23.204, TS 24.341 and TR 23.804 Rel7

e. SMS over SGs TS 23.272, TS 29.118 and TS 24.301 Rel8

Myth 3: IMS is not here! IMHO this is not much of a myth, but a sad state of affairs. IMS specs have been around for a looong time and certain operators on both sides of the pond have very ambitious deployment programs. However IMS has still some convincing to do as a reliable voice anchor (and other CS based services) in mobile environments. The Rich Communication Suite initiative (RCS) may be the final push needed to get over the hurdle.

f. IMS: IMS is covered over a large number of specifications. A good reference is TS 21.202 from which you can jump to all other IMS related specs

g. RCS: Rich Communication Suite is not a 3GPP feature. RCS is more like a service package that will use the 'always-on' paradigm of IMS based services and provide feature rich services to end-users and will make mobile applications easier to develop and deliver for the providers - How about getting your SMS on the TV screen in the hotel room....The RCS initiative is now under GSMA (www.gsmworld.com).

Myth 4: No Emergency calls in LTE. This is a genuine problem in Rel8 LTE. In fact emergency call handling has been pushed to Release 9 in the specifications. UE positioning techniques in LTE are not fully defined yet and until Rel9 is in place, carriers will have to redirect E911 calls to 2G/3G. It is interesting to speculate on how this deficiency will impact the provision of VoIP in LTE. Today, many carriers redirect emergency calls in 3G to legacy 2G where they do support (sometimes proprietary) positioning techniques which satisfy the stringent regulatory requirements. Early LTE deployments will have to deal with the same problem. Meanwhile carriers with UMTS who are on the LTE path are facing a difficult choice (if any) about support of full emergency-class positioning infrastructure in their 3G networks.

h. Location Services in LTE TS 23.271, TS 44.031, TS36.455

i. UE Positioning in E-UTRAN TS 36.305

/Hooman

The Mysterious Case of LTE Band 13

Hooman — Sat, 25 Jul 2009 01:17:00 GMT

The auction of the UHF band (700MHz) last year caused quite a stir in the industry. The "Open Access" can was opened, Google flexed muscles during the bidding process, and the analogue TV finally got the last nail in the coffin. Long after the dust had settled, I had an "Oersted-moment" during one of my Wireless Technology classes about block C of this band which is known as E-UTRA Band 13 in the 3GPP specifications. This block is assigned for LTE operations by Verizon Wireless in their upcoming LTE deployment.

Now, the "Oersted-Moment"; The Dane H.C. Oersted is the guy who discovered that electric currents can create magnetic fields. Just moments before starting a public lecture in April 1820, he noticed the current in a wire can deflect the needle in a compass that was lying around. He changed the subject of the lecture on the fly and started to explain (correctly) the phenomena he had just observed to the oblivious public who were witness to the birth of Electromagnetism!

Well, I'm afraid my "discovery" is not going to make it in any history book nor is it going to start a new science. But it was in a classroom, after I had opened Technical Specification 36.101 for handset radio transmission and reception that I suddenly noticed for the first time something odd about Band 13. The table is in below, and you can try to spot it before you go on reading....

E-UTRA Band

Uplink (UL)
eNode B receive
UE transmit

Downlink (DL)
eNode B transmit
UE receive

Duplex Mode

F_{UL_low} - F_{UL_high}

F_{DL_low} - F_{DL_high}

1920 MHz

1980 MHz

2110 MHz

2170 MHz

FDD

1850 MHz

1910 MHz

1930 MHz

1990 MHz

FDD

1710 MHz

1785 MHz

1805 MHz

1880 MHz

FDD

1710 MHz

1755 MHz

2110 MHz

2155 MHz

FDD

824 MHz

849 MHz

869 MHz

894MHz

FDD

830 MHz

840 MHz

875 MHz

885 MHz

FDD

2500 MHz

2570 MHz

2620 MHz

2690 MHz

FDD

880 MHz

915 MHz

925 MHz

960 MHz

FDD

1749.9 MHz

1784.9 MHz

1844.9 MHz

1879.9 MHz

FDD

1710 MHz

1770 MHz

2110 MHz

2170 MHz

FDD

1427.9 MHz

1452.9 MHz

1475.9 MHz

1500.9 MHz

FDD

698 MHz

716 MHz

728 MHz

746 MHz

FDD

777 MHz

787 MHz

746 MHz

756 MHz

FDD

788 MHz

798 MHz

758 MHz

768 MHz

FDD

...

704 MHz

716 MHz

734 MHz

746 MHz

FDD

...

1900 MHz

1920 MHz

1900 MHz

1920 MHz

TDD

2010 MHz

2025 MHz

2010 MHz

2025 MHz

TDD

1850 MHz

1910 MHz

1850 MHz

1910 MHz

TDD

1930 MHz

1990 MHz

1930 MHz

1990 MHz

TDD

1910 MHz

1930 MHz

1910 MHz

1930 MHz

TDD

2570 MHz

2620 MHz

2570 MHz

2620 MHz

TDD

1880 MHz

1920 MHz

1880 MHz

1920 MHz

TDD

2300 MHz

2400 MHz

2300 MHz

2400 MHz

TDD

"And as you can see..." I said to the class without hesitation, Band 13 has the uplink and downlink reversed! In contrast to all other FDD bands in the table (and many other bandplans elsewhere), in this band, the higher frequency is allocated to the mobile device and the lower frequency to the base station. The normal practice of FDD paired band allocation has to do with attenuation properties of the carrier frequency and the availability of the power. The mobile side has usually been allocated the "easier" lower-frequency portion of the band which experiences smaller amount of attenuation and therefore requires less power for closing the uplink. A reversal of this allocation strategy in band 13 is a sure sign that some other problem is lurking in the background, namely interference in the form of spurious emissions.

The 700MHz band is divided into four paired blocks, A, B, C and D (an unpaired E Block is also available). The A and B blocks are guard bands. The C blocks (LTE Band 13) in this upper 700MHz band were the main object of last year's auction. 12MHz in the middle of this spectrum belongs to the Public Safety.

A - C - D - B - [Public Safety] - A - C - D - B

A look at the structure of the auctioned UHF band shows that upper portion of Band 13 is closer to the public safety band. In order to reduce the effects of interference to the public safety band and other bands due to intermodulation effects of this carrier, the higher more "difficult" frequency has been allocated to the lower powered handset. On the other hand we can expect a slight enhancement in indoor coverage for band 13, due to further lowering of the downlink frequency .The question to ask is if this maneuver is enough to suppress the spurious emissions caused by the handsets to nearby bands. Further details after initial deployment will shed light on the mysterious case of band 13.

/Hooman

LTE Device Requirements for Verizon Wireless

Hooman — Tue, 16 Jun 2009 03:04:00 GMT

Not long ago, Verizon Wireless (VzW) released their initial LTE device requirements intended for 3GPP band 13 (700MHz). The document which is in the public domain is full of interesting information about the shape of things to come on the LTE front. By reading it, one can get a decent idea about the first LTE devices that will be commercially available. Here is a brief summary.

Perhaps the most conspicuous fact is the absence of voice services in the Services description. VzW will be providing packet data service initially. This was expected and is quite in line with previous technology enhancements such as HSPA and DO. These devices were launched as PC-cards initially and later USB modules, before the technology was integrated with the traditional handset form, supporting voice.

The SIM card is supported from the outset, but more interesting is the requirement for the IMS-based SIM or ISIM. This is an obvious reflection of VzW's interest in IMS as the platform for IP-based service convergence. As an example, SMS will be supported over IMS.

On the technology side, we note the explicit disregard for TDD operation, which would not be suitable for the 10 MHz paired band operation in band 13 in any case. The device category is given as 1, 2 or 3. This will ultimately dictate the device's data rate performance. A peek in the specification for category 3 (TS 36.306) puts the peak rate at about 102Mbps. Yes, this may be "ain't gonna see it" type of data rate, however keep in mind that the same "ain't gonna see it" rate for the fastest HSDPA device is 13.9Mbps. If you were like me when I was a kid, then you know that comparing these numbers is just like peeking at the car dashboards in an auto-show to see which one has a higher max speed printed on the speedometer. The car with the highest reading, had all my respect!

Multiple antennas are supported and the VzW requirement is in line with the specifications. Category 2 and 3 devices must support multiple antenna operations in MIMO mode, not just receive diversity. Only one transmitting antenna is required (and at least two receiving) at the device in Release 8, however it should be possible to switch the transmitter output between a primary and secondary antenna as required.

On the IP side, the device is required to support simultaneous IPv4 and IPv6 sessions. Up to 3 IP addresses should be supported and connectivity to multiple PDN-Gateways is a requirement. IP-mobility is handled by GTP or PMIPv6 and this does not have any impact on the device which can attach to the network using Simple IPv6

With LTE, VzW will forever put behind their well known limitations regarding international roaming. The LTE device is required to support at least 70 network entries. However, a packet-only device is a notorious generator of exorbitant international data roaming charges! It will be interesting to see how Vzw and their international partners deal with the pricing points for data roaming in the near future.

The game continues, and the ball is about to pass the net and drop on AT&T's court.

/Hooman

The Basic Unit of Time in LTE

Hooman — Thu, 26 Mar 2009 21:20:00 GMT

If you browse through the E-UTRA 3GPP specifications for LTE air interface (series 36.21x), sooner or later you will come across the ubiquitous parameter Ts. This nameless parameter is the most basic unit of time in the LTE air interface and pretty much everything in the LTE frame structure is based on multiples of this basic time unit, capital “T”, sub small “s”. Ts is defined exactly as:

Ts = 1/(15000 x 2048) seconds,

a little more than 32 nano-seconds.

As our first example, a radio frame in LTE is exactly 307200 x Ts which in turn is precisely 10ms. Since a radio frame is exactly 20 time slots (in FDD), a time-slot in LTE becomes 15360 x Ts. The radio frame is divided into twenty 0.5ms time-slots which normally carry 7 symbols.

For another example consider the cyclic prefix (Cp), OFDM’s prominent solution for Inter Symbol Interference (ISI). In LTE two cyclic prefixes are defined for normal operation (15kHz subcarrier spacing), long and short which can be used in different radio environments depending on the expected multipath delays. These two Cyclic Prefixes are exact multiples of Ts in time;

Cp (short) = 144 x Ts and Cp (long) = 512 x Ts

(Here is an interesting timing detail. If you do the math with these Cp durations and a symbol time of 1/15 kHz and seven symbols per time-slot, i.e. [7 x [144 x Ts + 1/15000]] you will find a discrepancy with the time-slot period of 0.5ms! The “missing” time is due to the fact that the first symbol of each time-slot has a slightly longer Cp of 160 x Ts)

But is there any deeper significance to the value of this Ts parameter and its definition. Well to begin with, Ts can be considered the sampling time for an OFDM signal in LTE where an FFT size of 2048 is used. In other words the OFDM time-domain symbol duration is in units of 2048 x Ts ( = 1/15kHz).

Another significance of Ts is the fact that it is an exact multiple of the UMTS and 1xEV-DO chip rates! The chip rate in UMTS is 3.84 Mcps and for 1x-based technologies 1.2288 Mcps. Expressed in units of Ts, the chip periods are:

8 x Ts for UMTS and 25 x Ts for 1xEV-DO.

These relationships are important in reducing chipset complexity when the same chipset for LTE has to support also UMTS and 1xEV-DO technologies simultaneously.
The basic unit of time in LTE will make the same clock do the trick for all.

/Hooman

LTE: Long Term Employment

Hooman — Thu, 19 Feb 2009 15:39:00 GMT

Long Term Employment for whom?

We sometimes joke about what LTE really stands for. Among the many possibilities that the letters L, T and E offer, the phrase Long Term Employment has been brought up more than once. I sometimes wonder who is going to enjoy this long term employment really? The way I see it, unlike its counterpart in the Nature, this long term Evolution seems to be heading in the wrong direction. It is going to put us all out of work!

Consider one of the most ambitious features in LTE, namely the Self-Optimizing and Self-Configuring Network or SON for short. This is the idea in a nutshell: The radio network manager flips a switch on her desk and the entire access network comes to life. Evolved-NodeBs start warming up, they will then begin to look for their neighbors over the X2 interfaces and initiate the handshaking with the EPC over S1. They configure themselves and each other with network parameters, software downloads and soon start broadcasting on PBCH. Some of the towers are actually on wheels (as in COWs: cells on wheels) and start moving around autonomously to adjust for the clutter and changing environment. Moments later the handsets are communicating with the network, beams are formed, multiple antennas are electrically tilted, power amplifiers are adjusted, and millions of subscribers unbeknownst to them, become sources of input data to a self-optimizing network that now has a life of its own.
Meanwhile the two RF engineers downstairs are engaged in a game of tennis on wii and the field technician is on page 512 of 'War and Peace'. SON of LTE has arrived! What am I going to do next? I can almost hear the shrill voice in my head “Get your own LTE network and stop whining”.

Ok, I admit to a slight element of exaggeration in my scenario, but be forewarned that SON has passed the dream stage and is part of stage2 3GPP specifications now! So we need to understand what the real motivation behind SON is. I have identified 3 main driving factors for the development of SON. (Send your comments about more that I’m sure have been overlooked.)

1. OpEx: As a wise man (down my corridor) says, the real LTE killer-app is the reduced cost of operations (OpEx) for the carriers. Obviously a self do-it-all network is an important step in giving more weight to this wisdom. SON can become a central feature of LTE and an interesting differentiator for vendors who are early adopters of the ambitious program.

2. HeNB: How about Home-eNodeBs, aka femto-cells? I refuse to fly back all the way to Sweden to configure my mom’s LTE femto-cell. A femto-cell that you just picked up at the local Best Buy should be plug-and-play, period. Therefore, there is little doubt that SON will play an important role in this arena. It may be true that the scope and complexity of a femto-cell will not match that of a full blown eNodeB in the field and many femto-cells may come with a lot of preconfigured parameters, but the HeNB must sooner or later get an IP-address, authenticate the network and be authenticated and is likely to download certain software/firmware before it does you any good.

3. Plectics: Finally, I can also see a case for the grand Self-Optimization part of SON. Ever heard of complex networks and emergent phenomena? If not then try this experiment at home. Plant five termites in your garden and watch what happens. Not much I bet. Next, try 5000 termites and watch the magic show. A super-organism will emerge with an intricate network of functions and behavior that would soon want to devour your entire house. (For a less expensive insight to network complexity and emergent behavior, I recommend M. Gell-Mann’s “The Quark and the Jaguar” or just google the odd word “Plectics” if you have not already done so).

It is no secret. Telecom engineers have known that a network can be larger than the sum of its parts, somewhat akin to a termite colony. Grant that a wireless network is orders of magnitude simpler than a termite colony, but it still has thousands of components that must inter-operate flawlessly. Wireless networks are notorious for becoming unstable under certain conditions, such as shifts in traffic patterns. Pin-pointing a solution can be a difficult task. You change a parameter here, and something else happens over there. You change another parameter there and nothing happens. With literally hundreds of network parameters to play with, it is easy to feel frustrated as you note that the performance indicators are not where they need to be. In my experience with operators and their attempts at optimization, the rule of thumb is to follow ‘common practice’. Do what was done in the past and and don’t touch anything if you are not sure of the outcome! There is little or no room for experimenting here. Moreover, a speedy response to localized problems in the network requires a very good understanding of how the network performance metrics are influenced by the relevant parameters at any given time. You need intelligence and adaptive behavior in a network to deal with these issues and the RF engineers have been kindly providing most of that so far.

SON has the potential to bring a radical change to the way we approach problems in the radio network. It combines a fast response time, with the intelligence of self-optimizing algorithms to predict, avoid and solve radio network problems instantaneously.

My exaggerated scenario in above is not going to be realized any time soon, (self-moving COWs was a joke, seriously :-) but I have no doubt that the self-optimizing feature of LTE networks will provide a crucial advantage as a tool for tackling the complex problems of RF performance. Yes, we still need RF engineers to be in charge for forseeable future.

In the sequel, we will take a closer look at the SON features of self configuration and optimization and explore the role of the UE as described in the standards.

Later,

/Hooman

Finding my way around the new 3GPP site and LTE specs

Hooman — Mon, 29 Dec 2008 17:55:00 GMT

For years I have used my own routine to find and access 3GPP specifications online. After typing in 3gpp.org, a click on the specifications link would bring up a page with the most descriptive link on the entire site: “GO HERE”, it used to say, using a bold oversized font. A click on this link would bring you to the venerable table of specifications and from there it was a breeze.

No one in the industry has escaped noticing 3GPP’s new look- they have gone green! Not in envy of any IEEE standard we hope, but as a sign of new things to come. The old light pink background has turned white (no noise related pun intended) with bright green as the main ornament.

But, where is my “GO HERE” link? After a few minutes of frustrating search I find that the most straight forward way of getting to the specs table is to move the cursor over the <Specifications> tab and then choose the cryptic <Specifications Numbering> label. Voila! I have my table.

For LTE a couple of entries on this table are noteworthy.

A click on the 36 series link will bring up all the important E-UTRAN specifications. Among the 36 series, the best spec to download and read for your beginning LTE studies must be the TS 36.300 E-UTRAN Overall Description, Stage2. It gives the bird’s eye view of the entire subject (click on version numbers to start the downloading). Unfortunately this general spec may not always up to date with the other more detailed specifications. A few discrepancies in use of terminology and other details may linger in 36.300, but by and large it is the place to go to for an overview of LTE. Do not be fooled by the term E-UTRAN in the title. This spec does a decent job of treating some of the basic aspects of the LTE Core Network, better known as Evolved Packet Core (EPC), as well. The role of the Mobility Management Entity (MME) and the Serving Gateway (S-GW) is listed, alongside a good description of the security functions which involve the EPC. I find the general discussion of QoS and the EPC bearer also quite useful.

Using the 36.300 as spring board, you will find your way to a long list of list of references for further LTE studies. Most of these are concerned with the E-UTRAN or the EPC portion of the LTE architecture. Below is a summary.

E-UTRAN and Air Interface related topics are in the 36.2xx series where the xx can be 11 (Physical Channels and Modulation), 12 (Multiplexing and Channel coding), 13 (Physical Layer Procedures) and 14 (Physical Layer measurements).

For EPC related and Interworking topics there are two important specs TS23.401 and its companion TS23.402. TS23.401 is a comprehensive description of EPC architecture, functions, protocols, and procedures. If you want to know how LTE will interact with UMTS and GSM/GPRS networks, this is the place to go. TS23.402 on the other hand tackles the challenge of inter-operability with the 1xEV-DO and other non-3GPP networks. There are a number of “auxiliary” specs that support these two. An important one among these is the TS25.304 which describes the mobile’s behavior in idle mode. When opening these non-36 series specs you should make sure that you pick Rel-8 versions. In future blogs I will elaborate about the contents of these specs.

3GPP still adheres to the MS Word format for the specifications. If you have anything political against using MS, 3GPP give you the option of downloading the specs in PDF format. Just click on the last column on a specs page, where you see ETSI (European Telecommunications Standards Institute). This link will take you to ETSI’s webpage from where you can get a PDF version of your favorite LTE specification.

Happy reading.

Hooman