Expert Opinion

Blog Post: IP Mobility Management

Ahmad — Mon, 18 Feb 2013 20:56:00 GMT

It all started as a basic idea of allowing a host with its statically configured IP address to be reachable at the same IP address when moving to a new point of attachment. Thus, there was RFC2002 for IP Mobility. At the time there was no concern of the different applications running on the laptop or the host as there was not many applications anyway or if there were, they all shared similar requirements for quality of services.

With the realization of the very limited number of IPv4 addressing, there was the notion of allowing the host to be reachable at different point of attachment while being dynamically allocated the same IPv4 address. The dice started rolling with many different features for Mobile IPv4 and Mobile IPv6. Despite all the enhancements and changes to allow multiple care-of addresses [RFC-5648], Mobile Router Support [RFC-5177], Hierarchical Mobile IPv6 [RFC-5380], Network-Based Mobility in v6 and v4 flavors [RFC5213, RFC-5563], etc., there always was one fundamental aspect that never changed. The mobility aspect was always controlled via the network layer without interference from the application layer [Remember: All applications were treated as the same from the network layer point of view]. Thus, all applications running on the same host use the same reachability, i.e., the same IP address and consequently the same IP anchor, e.g., home agent.

As everything around us started to move to all-IP based networking including time-sensitive applications, restricting the IP mobility management to the network layer without the knowledge of the specific needs of the different applications which are using the underlined transport pipe becomes problematic.

In other words, if a host or a mobile device has a VoIP application, a Video Conferencing application, an http session, and email running at the same time, then anchoring all of these applications traffics at a single node in the network (e.g., home agent) becomes overkill. It would probably work without noticeable problem with the http and email sessions but may cause some unacceptable delay which may cause a reduced level of Quality of Experience (QoE) by the end user. In addition, the http and email session may not require an IP address that is mobile across different access network points of attachment. In other words, most probably no noticeable degradation in the QoE will occur if such applications traffic is always anchored at the access gateway with the possibility of having a different IP address allocated whenever the point of attachment is changed, for example. That for sure can NOT be afforded for a time-sensitive application like VoIP or Video Conferencing.

This introduced the whole idea of how to provide IP Mobility at the network layer while taking on consideration the type of application that is using this transport pipe. In other words, how to make sure that the transport pipe being established satisfies the mobility requirement of the application that is using it. Thus, the concept of Distributed Mobility Management which more accurately was later defined within IETF as Dynamic Mobility Management or DMM. To be followed.

Blog Post: The World Phone – Multi-Band LTE UE (User Equipment), An Elusive Goal is becoming Possible?

Tony — Thu, 14 Feb 2013 16:56:00 GMT

Just when the cellular communication proliferated around the globe, people have dreamed for the World phone that travelers could use the same phone wherever you go around the world.

The fragmentation of technology (3GPP versus 3GPP2, or EDGE/UMTS versus CDMA) has made the goal of World phone elusive. Adding salt to the wound, the un-harmonized frequency bands around the different countries has made the World phone dream from elusive to illusive.

Until recently, we have reason to believe that 3GPP and 3GPP2 fragmentation has finally converged to LTE in either TD (Time-Division) or FD (Frequency-Division) versions! LTE will be the choice for most, if not for all, corners of the World. There is definitely hope that the holy grail for the World Phone is becoming possible.

I have posted more in-depth details on the LTE UE categories and the breed of BB (Base Band) chipset battle field on my previous communications:

http://lteuniversity.com/get_trained/expert_opinion1/b/twong/archive/2013/01/08/dynamic-of-the-lte-ue-user-equipments-base-band-bb-modem-market-from-the-list-of-tender-awardees-of-the-world-s-largest-wireless-operator-china-mobile.aspx

http://lteuniversity.com/get_trained/expert_opinion1/b/twong/archive/2012/05/30/landscape-of-the-lte-base-band-chip-set-and-cat-5-ue-commercial-availability.aspx

Per the LTE specification, all LTE UE will support FDD, TDD, H-FDD in all of the 6 possible bandwidths (1.4, 3, 5, 10, 15, and 20 all in MHz) of deployment, the remaining issue is the World phone has to work across multiple frequency bands. Table 1 summarizes a partial list of frequency bands of interest. They are, or will be, used for LTE deployment among the major geographical regions and/or major operators. I welcome your comment if my information is outdated and/or inaccurate.

Table 1. Global Frequency Band for 4G / LTE Deployment

Now, we know the frequency bands being used in the different continents. It is indeed a challenge to design a World phone with the RFFE (Radio Frequency Front End including the antenna, tuner, PA etc.) to work across all the frequency bands. It requires having a wide-band receiver, or a concatenation of multiple narrow band receivers to cover the “wide band”. Achieving a wide-band receiver which work across multiple bands has proven to be more difficult than it sounds. Thus, it is not pragmatic to design a RFFE to work across all bands.

Paradoxically, it does not require having a “wide-band” RFFE to cover all bands to make it the World phone! Will the device also require to be multi-modes (LTE, and other air interface otherwise) to become the perfect companion of the world traveler? Which RFFE supplier(s) will have the best solution to win the socket(s)? Table 2 summarizes a partial list of the major players in the transceiver battle field in alphabetical order. What are the SWOT (Strength, Weakness, Opportunity, and Threat) among the players? Whoever wins the transceiver battle field will likely capitalize substantial business opportunity both for the WORLD phone and the LOCAL phone.

Table 2. A Partial List of the Major Suppliers for UE Transceiver and PA Subsystems

For the trained eyes, we could strategically pick a subset of all the frequency bands to make the UE a World phone depending on the roaming agreement. Many of the smart phones OEMs and wireless operators are now charting the product and requirement roadmaps to realize this elusive goal for the “flagship” device as the perfect companion of the hi-end (hi-value) business travelers.

Let see if you can identify the least number of frequency bands and/or modes in order to make the UE a WORLD PHONE? This is a mind game balancing the vitality, performance, industrial design, and cost. I welcome your comment to exchange further perspectives…

Blog Post: SCTP Streaming in E-UTRAN

Ahmad — Wed, 06 Feb 2013 21:51:00 GMT

As per LTE EPS architecture, SCTP is used as the transport protocol for S1 and X2 control interfaces, i.e., S1-MME and X2-Control, where S1AP and X2AP are being used, respectively. The details of SCTP usage over these two interfaces is captured in TS36.412. (S1AP, X2AP SCTP ports: 36412 & 36422, respectively)

According to TS36.412, there is a single SCTP association between the eNB and the MME and between any pair of eNBs whenever X2 is available. In addition, the specification mandates that a single stream be used for Non UE-Associated signaling, e.g. this stream is used for all eNB-MME signaling for carrying configuration parameters, load balancing information, etc., and one or more streams for UE-Associated signaling. One last mandate is that all “single UE signaling” shall be carried over the same stream. Moreover, the specification reference RFC4960 for the details of SCTP.

As per RFC4960, the two SCTP end points agree on the number of outbound and inbound streams during the initiation of the SCTP association using two 16-bits fields in the SCTP INIT and INIT ACK chunks, i.e., maximum number of outbound/inbound stream is 65,535.

Since one of the most fundamental advantages of SCTP over TCP is avoiding the head-of-line blocking by the use of multiple streams, the number of outbound and inbound streams become an important factor for each SCTP association. In other words, the eNB could theoretically have up to 65k+ streams but the more streams the SCTP association end-point has the higher the overhead for managing those streams.

If we would like to have a theoretical example of an SCTP association in E-UTRAN, e.g., over S1-MME from the eNB location, it would be normal to expect something as follows (see figure below):

One outbound stream for Non UE-Associated signaling, e.g., stream 0.
If we assume the expected head-of-line blocking not to be more than 5% if a single stream is blocked, then we would like to have about 20 streams; e.g., outbound Stream 1 to Stream 20.
The Inbound streams are based on the MME configuration but for sure as per the standard there will be a single Non UE-Associated signaling stream. The number of the inbound streams and their labels (i.e., numbers) can be totally different than those of the outbound. e.g., stream 10 to stream 30.
Each stream will have its own Stream Sequence Number (16-bits) to track ordered delivery of different chunks over this stream.

Although, each chunk carries a sequence number that reflects the chunk sequence within its own stream, it also carries a Transmission Sequence Number (TSN, 32-bits) that reflects the chunk sequence with respect to all chunks that are transmitted over the SCTP association. One last observation, since DATA chunks is used to carry S1AP signaling, it is expected that each SCTP packet to have a single UE S1AP signaling message; thus a single DATA chunk per SCTP packet.

Blog: Ahmad

Wed, 06 Feb 2013 21:47:00 GMT

Blog Post: Is RSRQ Underdefined in Standards (Part 1)?

Charlie — Mon, 28 Jan 2013 16:59:00 GMT

As the principal Standards Development Organization (SDO) responsible for developing LTE Specifications, 3GPP is tasked with providing a framework within which Infrastructure vendors and Device vendors can reliably build products built to said specifications, that should successfully interoperate with each other. However there is always the dilemma that must be dealt with by any Standards Body, which is to say, “how deeply and completely must specifications be written?” In my past experience at Infrastructure vendors, in working with R&D teams and Standards people within R&D, there was always a belief that Standards should not be overly defined so as to leave room for vendor differentiation. Thus there is a balancing act that must take place – the specifications should be written tightly enough to enable interoperability, but not so tightly as to preclude vendors from building in their own functionalities and enhancements to add value above and beyond simply, “building to the Standard.”

In light of this, the topic of this blog (to be delivered in two parts) is to discuss the possibility that an important metric may be under-defined in 3GPP. There seems to be significant anecdotal evidence coming from the LTE industry that there is an issue with device vendors measuring and reporting a metric called Reference Signal Received Quality (RSRQ) in a standard fashion. It may be that the interpretation of the definition of RSRQ in 3GPP is leading to significantly different implementations by Device vendors such that the use of RSRQ as a mobility trigger is being called into question, at least at this relatively early stage of LTE development.

Let’s examine the definition of the metric. Per 3GPP TSG RAN; EUTRA; TS36.214 Physical Layer – Measurements, the following definition in blue is given:

Reference Signal Received Quality (RSRQ) is defined as the ratio N×RSRP/(E-UTRA carrier RSSI), where N is the number of RB’s of the E-UTRA carrier RSSI measurement bandwidth. The measurements in the numerator and denominator shall be made over the same set of resource blocks.

E-UTRA Carrier Received Signal Strength Indicator (RSSI), comprises the linear average of the total received power (in [W]) observed only in OFDM symbols containing reference symbols for antenna port 0, in the measurement bandwidth, over N number of resource blocks by the UE from all sources, including co-channel serving and non-serving cells, adjacent channel interference, thermal noise etc.

The reference point for the RSRQ shall be the antenna connector of the UE.

If receiver diversity is in use by the UE, the reported value shall not be lower than the corresponding RSRQ of any of the individual diversity branches.

At first glance the definition seems to make sense. In multiplying RSRP by the number of N Resource Blocks in the measurement bandwidth (NxRSRP/E-UTRA carrier RSSI), the definition is striving to make an apples to apples comparison of RSRP in the numerator versus the contribution of RSRP to the RSSI in the denominator. Typically, RSSI is the measurement of all energy seen by a receiver in a given measurement bandwidth and includes thermal noise, additional self-induced noise as represented by the receiver noise figure, and all desired as well as undesired signals. The reference signals of the serving cell would certainly qualify as desired signals thus they would also contribute to the denominator. RSRP in itself is an average measurement of the signal strength of individual Reference Signals over a measurement (Channel) bandwidth while RSSI is a cumulative measurement over the total channel bandwidth. Multiplying RSRP by N Resource blocks would seem to be making the numerator a cumulative quantity over the total channel bandwidth thus lending itself to a logical comparison to the cumulative quantity expressed by RSSI in the denominator. Before going further, we should discuss the definition of RSRP itself.

Reference Signal Received Power (RSRP) in itself is an average measurement of the signal strength of Reference Signals only and the definition is given in TS36.214 as well, per the below text in blue.

Reference signal received power (RSRP), is defined as the linear average over the power contributions (in [W]) of the resource elements that carry cell-specific reference signals within the considered measurement frequency bandwidth.

For RSRP determination the cell-specific reference signals R0 according TS 36.211 [3] shall be used. If the UE can reliably detect that R1 is available it may use R1 in addition to R0 to determine RSRP.

The reference point for the RSRP shall be the antenna connector of the UE.

If receiver diversity is in use by the UE, the reported value shall not be lower than the corresponding RSRP of any of the individual diversity branches.

Let’s go through some quick examples of how RSRP should be measured based on some assumptions for a single transmit antenna at the eNodeB and a single receive antenna at the UE. Let’s assume that the operating parameters are:

FDD Operation, 10 MHz wide carrier bandwidth (50 Resource Blocks), Transmit Power settings of the downlink Reference Signals = +20 dBm, Path Loss between eNode B transmit antennas and UE receive antennas = 100 dB

In LTE on the downlink, we set an equal Energy per Resource Element (EPRE) for the different resource elements, with the reference signals being set to an absolute value of transmit power, and all other resource elements carrying other channels and signals set to an offset value versus the reference signal setting. Assuming flat fading for the channel, and not taking into account antennas gains and coaxial feeder/jumper losses, in our example the RSRP would be simply:

+20 dBm – 100 dB = -80 dBm

For our 10 MHz wide carrier, there would be 50 resource blocks with 2 reference signals per symbol (always in symbols 0 and 4 in each Resource Block for two antenna operations in the downlink). If each reference signal is transmitted at +20 dBm (equal to 100 milliwatts in linear terms), the total power consumed in the eNode B power amplifier by the reference signals is 100 Reference Signals x 100 mW/RS = 10 Watts (+40 dBm) for a single transmit branch. However since RSRP is the received signal strength averaged over all the reference signals in the measurement bandwidth of 10 MHz, we use +20 dBm in our example calculation and we assume a path loss of 100 dB applied against each of the reference signals. What’s interesting to note here is that if we were to calculate a cumulative RSRP at the UE receiver it is logical to think that the cumulative RSRP would be:

+40 dBm – 100 dB = -60 dBm

In reality, for a non-flat fading scenario, the UE would take into account the fading characteristics of the channel and this would result in the equivalent of a frequency-dependent path loss over the channel bandwidth, and the measured RSRP would then differ somewhat from our example, but again, we are assuming flat fading for simplicity.

Given that this blog will extend into multiple parts, before concluding we can draw the first interesting observation. In looking at the cumulative RSRP versus the average RSRP of the example, we see there is a difference of 20 dB based on the fact that the cumulative RSRP is measuring the total contributions of 100 reference signals over one symbol time in 50 resource blocks versus an average number. So why does the definition use N RB’s X RSRP in the numerator instead of N Reference Signals X RSRP? We notice in the definition of RSRQ that there is a definition for how RSSI is measured as well, which itself is an averaged measure. Stay tuned for Part 2 of this blog as we go deeper into our interpretation.

Blog Post: Types of UE Feedback: The Measurement Report

Bill — Tue, 22 Jan 2013 22:52:00 GMT

As UEs have become smarter and the air interface more complex, the need for more detailed communication between the UE and the network has increased dramatically. The UE has become the eyes and the ears of the radio access network. Its main goal is to find the best cell and maximize performance with that cell.

To help the UE accomplish this, the eNodeB gathers several pieces of information from the UE and then adjusts its’ downlink transmissions accordingly. The UE tells the network what cells it can see and how strong it can see them, its current channel conditions, the current state of its’ memory buffer, which antennas should be transmitting in the downlink, how many different transmission streams can be supported simultaneously, acknowledgements when data is received successfully, and any other information that the network wants to know.

This is the first in a series of blogs on these different types of UE feedback. This blog will focus on the measurement report. The measurement report is the mechanism used by the UE to tell the network whatever results have been requested. Typically, these are measurements of the surrounding cells. They can also include requested measurements of block error rate, transmit power and other UE-based parameters. The UE learns the requested information using a measurement configuration.

When a UE is in RRC-CONNECTED mode, this measurement configuration is provided to the UE by means of dedicated signaling; typically using the RRCConnectionReconfiguration message.

The measurement configuration provided to the UE includes the following parameters:

Measurement Objects: the objects on which the UE shall perform the measurements; i.e. frequencies and cells. In other words: who should the UE measure? These include intra- and inter- frequency neighbors, IRAT UMTS neighbors, IRAT GSM neighbors and IRAT CDMA2000 HRPD and 1xRTT neighbors.
Reporting Configurations: the criteria used by the UE to trigger the transmission of a measurement report and the quantities that the UE includes in the report. In other words: when should the UE send a report? This trigger can either be periodical or event-based.
Measurement Identities: an identifier that links one measurement object with one reporting configuration. In other words: the UE needs to keep track of the objects to be measured and their specific triggers. The measurement identity is used as a reference number in the measurement report.
Quantity configurations: the measurement quantities and associated filtering used for all event evaluation and related reporting per Radio Access Technology.
Measurement gaps: periods of time that the UE may use to perform measurements while in connected mode.

The UE maintains a single measurement object list, a single reporting configuration list and a single measurement identities list. Any measurement object can be linked to any reporting configuration of the same RAT type.

As mentioned earlier, a report can be event-triggered or periodical. An event-based measurement report will be transmitted when the criteria for any of the following events have been met:

A1: Serving Cell becomes better than a defined threshold

A2: Serving Cell becomes worse than a defined threshold

A3: Neighbor cell becomes some offset better than the primary cell

A4: Neighbor cell becomes better than a defined threshold

A5: Primary cell becomes worse than a defined threshold and a neighbor becomes better than a second threshold

A6: Neighbor cell becomes some offset better than the serving cell

B1: Inter-RAT neighbor becomes better a defined threshold

B2: Primary cell becomes worse than a defined threshold and inter-RAT neighbor becomes better than a second threshold

Periodical measurement reports are sent based on the reporting configuration. For instance, it could be configured that the UE report its’ transmit power every 2 seconds or its’ transport channel block error rate every second. This is operator-specific.

We have discussed the vehicle used by the UE to tell the network what it can see as well as other operator-configured parameters. Another piece of information that the network needs to be successful is some indication of the channel conditions at the UE. This will help the network adapt its downlink transmission to match the UE’s capability at that time. These channel quality indicators or CQI’s will be the subject of the next blog in this series.

Source: LTE; Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification (3GPP TS 36.331 version 10.5.0 Release 10)

Blog: Bill

Bill — Tue, 22 Jan 2013 22:47:00 GMT

Blog Post: LTE Link Budget and Uplink Throughput

Michael — Mon, 21 Jan 2013 21:10:00 GMT

When considering the LTE link budget, we focus a great deal on the uplink shared data channel (PUSCH) since it is often found to be our limiting link. Since the mobile’s transmit power and the environmental margins are generally established and out of our control, we look to several other factors that can combine to impact our PUSCH link budget including: mobile speed, modulation and coding, minimum uplink data rate, etc. If we assume that we are designing for some average mobile speed (e.g., mobile, but slow moving), then we must look to our requirements for the minimum uplink data rate to help us determine our link budget.

We know that the minimum allocation to a UE is 1 Resource Block (RB) over a subframe. Assuming QPSK with 1/3 rate encoding (to know our SNR requirement from TS 36.104), we can quickly calculate a throughput of about 96 Kbps (or 67 Kbps at cell edge where we expect 70% reliability). So, now we need to decide if an uplink throughput of 67 Kbps is sufficient for our applications and user experience requirements. This might be fine for texing or updating email, but would definitely become a problem for users trying to do uplink live streaming video.

A possible solution is for a higher minimum uplink throughput is to increase the number of RBs a mobile at cell edge can use from one to two; thereby, giving us about 130 Kbps uplink throughput for the cell-edge user. This change will impact the noise bandwidth which the receiver must overcome (part of receiver sensitivity) by 3 dB, reducing our Maximum Allowable Path Loss (MAPL) for the PUSCH.

In the end, it is important when designing for LTE to clearly define the minimum uplink throughput requirement at cell edge as this will directly impact our MAPL. So, if you plan to use features like uplink live streaming, include this in the planning and design phase of the network otherwise there will be some users who are unable to benefit from these services.

Blog Post: How fast can my LTE smartphone go?

Ray — Wed, 16 Jan 2013 16:59:00 GMT

You just received one of those new fangled 4G LTE phones during the end of year sales!

You just picked up a brand new, unrefurbished “rPhone 999” from your local RayTel Wireless store….”Raytel Wireless, where rPhone is better than your phone!” . It’s the latest, greatest ultra-fast high speed LTE wireless device in your hands. It has the high def screen and ultra-super-color display for watching those action movies that you like. And the color of the phone is a hot red color!

Decisions, decisions. What movie to download first? That can wait. The first decision is which of your friends do you call first to brag about your new super high speed device.

Hmmmm?

But wait a minute…..Just how fast does your device really go? Is it really faster than your friend Herman’s phone. He always gets the latest technology. And he can’t sleep unless he checks his smartphone speed on one of those speed testing web sites every night, so he knows what’s fast.

So just how fast can your device download videos? Let’s figure it out.

Your device is probably an LTE Category 3 device. LTE release 8 devices have a defined “UE category” that specifies uplink and downlink physical layer performance for each category value. These are defined in the 3GPP specification “3GPP TS 36.306 Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment (UE) radio access capabilities (Release 8)”. According to the table below, your new rPhone category 3 UE has a maximum downlink data throughput of 102 Mbps! That has to be better than anything Herman has.

Table 1. Maximum possible LTE airlink physical layer speeds for Release 8 devices (values based on information from 3GPP TS 36.306)

But wait, Herman keeps telling you about multiple antennas and MIMO and how it makes his device work so much faster. Let’s do some homework before we make that call to Herman.

In Table 2 below, I have listed the maximum possible speeds based on different antenna techniques. You’re in luck, the rPhone category 3 device can still achieve up to 102 Mbps IF 2x2 MIMO is used. Also notice that 299 Mbps is only possible for a category 5 UE if 4x4 MIMO is used. But Raytel Wireless uses 2x2 MIMO like most operators today, so 102 Mbps is still possible!

Those maximum speeds have some built-in assumptions. Assumption #1: They assume the usage of multiple antennas, or more specifically multiple transmission layers reusing the same subcarriers on each antenna. Each transmission layer carries different data so you can increase your physical layer throughput by using more antennas with separate transmission layers. But you can only get MIMO if DL channel conditions are good (a high SINR value, probably something greater than 12 dB). Notice that your maximum possible for a category 3 UE drops to 75 Mbps ( and probably something even slower) if you happen to have poor channel conditions or are a long distance from the transmitting antenna and there are probably obstructions between you and the cell tower antenna.

Assumption #2: must have great channel quality with zero redundancy bits and zero transmission errors. (Not likely for all of these 3 to happen in real life systems.)

Let’s call Herman.

Table 2. Maximum possible DL Physical layer speeds based on DL transmission techniques (maximum 20 MHz bandwidth)

But wait….Herman also told you about channel bandwidth. MIMO is great but your phone’s speed is also limited by your operator’s available channel bandwidth. RayTel Wireless has both 5 MHz and 10 MHz channels depending on which city you are in. Looking at the tables below, your new rPhone category 3 device can achieve a maximum possible physical layer DL speed of 39.6 Mbps or 79.2 Mbps in 5 and 10 MHz channels, respectively. What happened to my 102 Mbps!?!?!?! I’m using 2x2 MIMO!

Table 3. Maximum possible DL Physical layer speeds in 5 MHz channel

Table 4. Maximum possible DL Physical layer speeds in 10 MHz channel

Assumption #3: maximum possible speeds are also based on large channel bandwidths. Depending on the device, it can’t attain its maximum possible speed unless the channel bandwidth is large.

Based on the table below, you can see the category 3 UE won’t reach its maximum capability until it has at least a 15 MHz channel.

Table 5. Maximum possible DL Physical layer speeds in 15 MHz channel

The limiting factor here is if the channel bandwidth is not available, there just aren’t enough physical airlink resources (Physical Resource Blocks (PRBs)) available to get the highest possible speed.

Here’s the formula I used to make a quick calculation of maximum possible physical layer DL throughput:

Assumptions:

1. network is using normal Cyclic Prefix

2. network has 2 TX antennas

3. DL channel conditions are so good that no redundancy bits are needed (coding rate = 1) and no retransmissions since there are no errors

4. due to the great channel conditions, the network uses 64-QAM modulation (6 information bits per data modulation symbol)

5. Only 2 OFDM symbols are used for the Physical Downlink Control Channel (PDCCH).

Formula: (# of PRBs) x (# of available data modulation symbols per PRB pair) x (6 bits per mod symbol) x (# of transmission layers)

Then multiply by 1000/1000000 to get a Mbps value.

Example for 10 MHz channel: 50 x 132 x 6 x 2 x 1000/1000000 = 79.2 Mbps

So even if the category 3 UE can attain DL data speeds of up to 102 Mbps, the 10 MHz network can only transmit at the maximum possible speed of 79.2 Mbps.

You can do a similar calculation for the UL speeds (see table below). Just use only one transmission layer since the UL only supports one TX antenna, use 16-QAM modulation for category 1-4 devices, and don’t allocate all of the UL PRBs because probably at least 4 of them will be allocated for Physical Uplink Control Channel (PUCCH). Number of available data modulation symbols per PRB pair will be 144 in the uplink.

Table 6. Maximum possible UL Physical layer speeds in 5 & 10 MHz channels

Obviously, you can see the maximum possible speeds are attainable if

1. you are the only user in the LTE cell

2. have great channel conditions

3. and the maximum bandwidth is available

So if you have to do a nightly “speed check” of your LTE 4G smartphone like my friend Herman does, don’t despair if the numbers don’t reach the maximum speeds we talked about. Those tools only count the application layer speed so they don’t take into account the overhead of LTE airlink protocol layers.

If you are looking for other high-tech toys that you desire , don’t forget the RayTel Wireless rPhone 999, now on sale for only $9.99 and hope that you always get high channel quality.

Ray

Blog Post: Dynamic of the LTE UE (User Equipments) Base Band (BB) modem Market from the list of tender awardees of the World’s largest wireless operator – China Mobile

Tony — Tue, 08 Jan 2013 19:14:00 GMT

Since I posted my blog back in May on the Landscape of the LTE Base Band Chip Set and Cat.5 UE Commercial Availability (http://lteuniversity.com/get_trained/expert_opinion1/b/twong/archive/2012/05/30/landscape-of-the-lte-base-band-chip-set-and-cat-5-ue-commercial-availability.aspx), there has been some new development.

Let us first look at the landscape of the China wireless market in the table below with the most recently published wireless subscriber’s statistics for October 2012.

Although CM (China Mobile) enjoys a ~65% of overall subscribers market share, it could only grasp ~37% of the 3G subscribers population. CM is the one and only operator using the TD-SCDMA technology in the world, The TD-SCDMA technology policy has painfully handicapped CM from offering enough ionic handsets [including the iPhone, and the Blackberry (other than the BB-9788)] to attract the mass of prospective 3G subscribers. Thus, they are working diligently to transition to 4G hoping to get to a more healthy ecosystem.

In early December 2012, it was announced that there were 30 different UE models awarded in response to the latest China Mobile TD-LTE UE tender. By model count, 12 of them (40%) use the Qualcomm BB modem and 18 of them (60%) use BB from other BB suppliers.

The 40% from Qualcomm is a no-brainer. In fact, it is alarming to see Qualcomm was only on 40% (by model count) of the TD-LTE UE. More enlighteningly, let us focus on the 60% and look into the market dynamic in the LTE BB modem. Aside from Qualcomm, there were 9 TD-LTE chip-makers awarded in the tender for 18 UE models:

Sequans – (http://www.sequans.com). France-based. It is in 4 of the 18 winning terminals;
HiSilicon – (http://www.hisilicon.com/about/about.html). China-based subsidiary of Huawei. It is in 3 of the 18 winning terminals;
ZTE Microelectronics Technology – China-based subsidiary of ZTE (0763.HK);
Leadcore Technology – (http://www.leadcoretech.com/about.htm). China-based subsidiary of the Datang Group. Datang was one of the early pillars in TD-SCDMA technology;
Spreadtrum – (http://www.spreadtrum.com) China-based (Nasdaq: SPRD);
MediaTek – (http://www.mediatek.com/en/About/index.php). Taiwan-based fab-less semiconductor company (2454.TW) focusing on the 3GPP2 (2G/3G) solutions;
Lightsurfing – (http://www.lightsurfing.com/pages/aboutUs.html). Shanghai (China)–based IT company;
Altair – (http://www.altair-semi.com). Israel-based);
Marvell – (http://www.marvell.com). US-based (Nasdaq: MRVL). Marvell has R&D center in Shanghai (China) focusing on TD-SCDMA and TD-LTE;

Qualcomm has historically enjoyed the “first-mover” advantage in all new wireless technologies. They are always ahead of the competitions by a substantial TTM (Time-To-Market) benefits. Samsung now uses in-house LTE BB modem for smart phones being sold outside of NA. Samsung represents a significant market share in the smart phone space. Broadcom has also made announcement that they has joined this battle (http://www.reuters.com/article/2012/12/06/us-broadcom-analystday-idUSBRE8B518V20121206). Cat.4 UE (yet from another BB supplier) are also being qualified in the operators’ labs

As part of the bid specifications, China Mobile requires the UEs to support TDD, FDD, TD-SCDMA, WCDMA, and GSM/GPRS/EDGE. Apart from Qualcomm, none of the above BB suppliers is in any of the commercial LTE UEs from any of the wireless NA carriers as of yet. One can extrapolate that in the near future, a subset of the BB OEMs will make their ways into the LTE UE. Additionally, per the 3GPP Rel.8 requirements, all LTE UEs shall support TDD, FDD, and Hybrid-FDD modes. If some of the above BB suppliers validate their chipset and build up their scales, they will slowly and surely earn the trust from the less vertically-integrated handset OEMs (Nokia, RIMM, HTC, Sony-Ericsson, and others). Equally important, it will eventually turn the tide of many of the NA wireless carriers’ perception of the alternative LTE BB modem OEMs.

Since my last blog, Cat.4 BB test-UEs are being tested in the operators’ labs. It is conceivable that Cat.4-capble UEs (either smart phones or more likely data cards) will be commercially available in 2013. Arguably, between the BB modem and the apps-processor sockets, they are the thrones of the BoM (Bill of Material) of the UE simply because they represent the highest cost (values).

With the pack of the “followers” restlessly chasing the LTE BB socket in the wireless handset market which is growing at an ACGR of 20+%, let us think about what Qualcomm will need to do to stay ahead of the curve in 2013 and beyond. Equally intriguing, what are the technical and business strategies that the “followers” must adapt to in order to un-throne Qualcomm for one of the most-sought after “sockets” of the LTE UE BoM?

Blog Post: Hallway Conversations and Link Budgets

Michael — Thu, 20 Dec 2012 15:06:00 GMT

Many times when discussing link budget to someone new to the topic, a simple analogy helps. Consider you and I are having a hallway conversation and you start to walk away, at some point as you’re walking down this long hallway you will no longer be able to hear me. This is the maximum separation between transmitter and receiver, or in cellular parlance the Maximum Allowable Path Loss (MAPL). Extending our example, it is clear that if I speak louder you will be able to hear me from further away. Along the same line, how well you hear will be a factor as well. If it is my 83 year old father, with poor hearing – his receiver sensitivity is not as good as mine. I joke however that he has tower-mounted amplifiers (hearing aids) to improve his overall receiver noise figure. Finally, to end the analogy, if there are several people milling about in the hallway, then the maximum separation is reduced again by the environment. So, in this simple analogy we have the three components of our link budget transmitter power, environmental margins, and receiver sensitivity.

Blog Post: The Master Information Block in LTE vs. UMTS and Much Ado About Nothing

Charlie — Tue, 18 Dec 2012 22:44:00 GMT

One of the wonderful things about the evolution from 3G UMTS to 4G LTE was that, while there was a true revolutionary upgrade of the Air Interface Technology, and introduction of new Radio Access Network and Packet Core networks as well, many of the technical concepts and much of the Terminology that we were introduced in UMTS/HSPA/HSPA+ remained the same in LTE. We were introduced to the concept of the Master Information Block (MIB) in UMTS and this concept has carried over to LTE as well. The MIB contains broadcasted System Information that must be read by UE’s attempting to access the UTRAN as well as the EUTRAN, although there are some slight differences.

In UMTS, the MIB is broadcasted by the Node B via the Primary Common Control Physical Channel (PCCPCH) and includes vital system information such as the PLMN ID, PLMN List (optionally), supported PLMN types, and very importantly the scheduling information for the other System Information Blocks that must be read by the UMTS UE in order for it to perform the basic operations regarding System Acquisition, Random Access Procedure, Cell Reselection, etc. In this sense the MIB truly is the “Master” Information Block of all the System Information Blocks that exist in UMTS, in that the UE must be able to read the MIB, otherwise it cannot read any of the other SIB’s.

In LTE, the MIB is broadcasted by the eNodeB on the Physical Broadcast Channel (PBCH) which occupies the center 6 Resource Blocks of the downlink channel bandwidth, specifically the first four symbols of slot 1, subframe 0 of every radio frame. LTE UE’s will need to read the MIB to acquire the channel bandwidth information (5/10/20 MHz wide channels, for example), the eNodeB transmit antenna scheme, the Physical Hybrid ARQ Indication Channel (PHICH) configuration, and the System Frame Number. At Award Solutions, we typically describe the periodicity of transmission of the MIB as “new” transmissions occurring every 40 milliseconds with retransmissions every 10 milliseconds. My curiousity led me to try to understand why we used the term “new transmission” versus “retransmissions”. Are the channel bandwidth, eNodeB transmit antenna scheme, or PHICH configuration changing dynamically from new transmission to retransmission? Hardly - what is changing is the System Frame Number (SFN).

The System Frame Number is broadcast in the MIB and is used as a timing reference between the eNodeB and the UE for operations such as SIB scheduling and Paging. The SFN is a 10 bit Binary Coded Decimal number which runs from 0 to 1023 when expressed in Decimal terms. Let’s looks at a new transmission versus three retransmissions in both BCD and Decimal formats and let’s assume that our timer is incremented at 0.

New Transmission: 0000000000 = 0

1^st Retransmission 10 ms later: 0000000001 = 1

2^nd Retransmission 10 ms later: 0000000010 = 2

3^rd Retransmission 10 ms later: 0000000011 = 3

New Transmission 10 ms later, 40 ms after previous new transmission: 0000000100 = 4

A quick examination shows that within the timespan of a new transmission and three retransmissions, only the last two bits are incrementing within the SFN, and upon another new transmission a bit in the first eight most significant bits increments. It turns out that only the first eight most significant bits of the SFN are broadcasted in the MIB, and that the value of the two least significant bits is hardcoded versus the specific retransmission. Why would 3GPP standards choose not to implement the broadcasting of all 10 bits of the SFN? As usual standards is always looking for ways to lighten signaling overhead and not broadcasting the two least significant bits yields a 20% savings on the SFN overhead.

In summary, the MIB in LTE does not seem to be as much the “Master” Information Block in LTE as it was in UMTS, as the SIB scheduling for the various possible SIBs is now contained in SIB 1! And as for the mystery of the“New” transmissions of the LTE MIB, for me it was much ado about nothing……

Blog: Charlie

Charlie — Tue, 18 Dec 2012 22:40:00 GMT

Blog Post: SCTP Multi-homing

Gary — Tue, 18 Dec 2012 20:05:00 GMT

Introduction

The Stream Control Transmission Protocol (SCTP) is a transport layer protocol, similar in nature to the traditional Transmission Control Protocol (TCP). They both provide a number of useful features, including congestion control, error detection and retransmission. SCTP, however, offers some capabilities that TCP does not. It allows the application to send data as independent streams. SCTP also makes better use of the redundancy benefits of having multiple network interfaces. This article explores this redundancy support in detail.

High Availability Requirements

Mission critical systems recognize that their components inevitably fail and plan accordingly. Any individual component that would disrupt service when it dies is known as a single point of failure. Effective contingency plans eliminate (within practical capabilities) single points of failure. Consider the connectivity between a hypothetical Cell Site and Mobile Switching Office (MSO) illustrated in Figure 1. It’s been decked out with redundant routers at both the cell site and the switching office. It also has two independent links between the sites – Ethernet and SONET. Each of the nodes has two network interfaces (IP addresses shown). It appears to have eliminated all single points of failure; communications between the eNodeB and MME cannot be disrupted by the failure of any single component. Looks can be deceiving, however.

Figure 1 Cell site with redundant connectivity to the Mobile Switching Office

Where TCP Comes Up Short

The concept of a TCP connection is fundamental to the operation of the protocol. The connection embodies all of the state information needed by the congestion control, sequential delivery and error recovery algorithms. TCP connections are identified by the IP address and TCP port number of the source and destination nodes. Figure 2 illustrates three TCP connections between the eNodeB and the MME. TCP connection [192.0.2.125:14457, 198.51.100.65:34851] uses one network interface on each device. TCP connections [192.0.2.10:36412, 198.51.100.39:36412] and [192.0.2.10:24500, 198.51.100.39:18479] use the other network interface.

Figure 2 Examples of TCP connections between eNodeB and MME

The problem with TCP stems from its strict association of IP address with the TCP connection. Figure 3 illustrates what happens when one of the network interfaces on the MME fails. TCP connections associated with that port’s IP address will time out. TCP cannot redirect data from the failed port to the remaining active port. Communication between the eNodeB and MME has been affected, even though an alternate path between the two nodes exists.

Figure 3 Effect of a port failure on TCP connection

Now, it is possible for us to do something about this. We could write the application such that it reopens the failed TCP connection using the new address. We could devise a scheme in which the IP address of the failed port gets mapped to the in-service port. However, the central issue with TCP remains: TCP cannot, by itself, effectively use redundant network interfaces.

SCTP to the rescue

Before an application sends data using SCTP, it must first set up an association between the source and destination nodes. The SCTP association is analogous to the TCP connection. One significant difference, however, is that the two nodes may exchange a list of acceptable IP addresses when they establish the association. SCTP monitors the reachability of the destination IP address it is using to send data. If the address becomes unreachable, for any reason, SCTP selects one of the association’s alternate addresses. Figure 4 illustrates the fact that all three SCTP associations remain up, despite an MME network interface failure.

Figure 4 SCTP Associations

Conclusion

SCTP’s multi-homing feature assigns multiple IP addresses to a single association. SCTP automatically detects when an IP address is unreachable and starts sending data to one of the association’s other IP addresses. SCTP improves the overall availability of mission critical systems like the LTE network. The LTE standards documents suggest using SCTP on a number of its signaling interfaces, as shown in Figure 5.

Figure 5 SCTP in the LTE-EPC network

Blog Post: The VOLTE “Conversation” Between IMS and LTE

Bob — Mon, 17 Dec 2012 20:03:00 GMT

“Voice over Long Term Evolution” (VoLTE) is emerging as the preferred solution for the need to support real time voice traffic in the new world of all IP networks. LTE is designed to support massive volumes of traffic. Voice traffic is very low bandwidth. So why is VoLTE critical to the evolution toward an all-IP networking environment? The answer is this, until the service providers can support real time voice services (and meet voice QoS requirements) in the same packet switched domain as the high volume, best-efforts data, they will be burdened with the huge capital and operating expenses of two separate networks. For most carriers, VoLTE is the solution to this dilemma.

VoLTE is based on two separately introduces 3GPP standards; IP Multimedia Subsystems (IMS), first introduced in 3GPP UMTS Release 5, and Long Term Evolution (LTE) first introduced in the 3GPP UMTS Release 8. It should be noted that 3GPP2 (the CDMA folks) offered a solution called Multi-Media Domain (MMD) to compete with IMS. There was also 3GPP2 Revision C proposal a 4G proposal for CDMA. Most CDMA service providers have opted to move to IMS for their future network service solution, and to reject Rev C in favor of the 3GPP defined LTE. Therefore future 3GPP2 standards are merging into 3GPP standards. That said the description below applies equally to the historical UMTS-based providers and the historical CDMA2000-based providers.

IMS and LTE are defined independently. Therefore IMS does not depend on the existence of LTE nor does LTE rely upon IMS. VoLTE however is a process designed to couple IMS and LTE to create an environment capable of supporting voice traffic in a shared packet data network. We can view IMS is the “Boss” in the sense that it is IMS that recognized the need for special network conditions required to support voice traffic. LTE may then be considered the “employee” responsible for carrying out the Boss’s instructions. For VoLTE, IMS directs LTE to establish the desired QoS environment, then commence with the voice call. IMS also notifies LTE when the call has completed, and directs LTE to tear down the special voice environment.

Let’s take a quick look at how this works. The process starts with a wireless subscriber (“sub”) expressing the desire to the LTE network to make a Voice over IP (VoIP) call. LTE knows this means that it must make a connection with IMS. In preparation, LTE identifies a PDN Gateway (P-GW) that offers a connection to the IMS network and establishes a Default EPS bearer from the subscriber to the selected P-GW.

The language spoken by IMS is “Session Initiation Protocol” (SIP). The default EPS bearer is established with a QoS Class Indicator (QCI) value of 5 (the QCI value required for SIP signaling). It should be noted up front that this EPS bearer will not support the QoS required for voice traffic, so we can expect to need an additional EPS bearer.

Like the IMS network, the subscriber also speaks SIP. Therefore the subscriber registers with the IMS network then commences to make a VoIP request. Before we get too far ahead of ourselves let’s introduce a couple of the key players in the IMS network. The Serving Call Session Control Function (S-CSCF) is the node with which the subscriber registers for IMS service. The S-CSCF will authenticate the subscriber, then it assumes the responsibility of connecting the subscriber with the called party once a VoIP request is made. We can consider the Proxy Call Session Control Function (P-CSCF) as the “administrative assistant” of the S-CSCF. All IMS related requests made by the subscriber must be first received by the P-CSCF before being forwarded to the S-CSCF. The P-CSCF will open the SIP request and perform any necessary administrative tasks before sending the request on to the S-CSCF.

Now that we know the players let’s examine how they interact. We will assume that the subscriber is now authenticated both by the LTE network and the IMS network. A default EPS bearer has been established between the subscriber and the appropriate P-GW, and the subscriber is ready to request the establishment of a VoIP session.

The subscriber begins by sending a SIP “Invite” message toward the S-CSCF. Contained in the SIP message is a Session Description Protocol (SDP), that carries the QoS requirement. Note that this SIP message is carried through the LTE network, but the LTE network is unaware of the content of the message (nor the need for special QoS treatment). The first contact point in IMS is the P-CSCF. The P-CSCF opens the SIP message and extracts the QoS requirement. The SIP message is sent on to the S-CSCF, while QoS requirements are sent through the Rx interface (using the Diameter protocol) to the Policy and Charging Rules Function (PCRF). The PCRF creates actionable charging and QoS rules and forwards these across the Gx interface to the Policy and Charging Enforcement (PCEF) that lives with the P-GW in the LTE network. This is the first time that LTE is aware that it must support voice traffic.

The P-GW now takes charge forwarding a request to establish a separate “dedicated bearer” (with a QCI value of 1) toward the subscriber. The subscriber is the only one in the LTE network that communicates both in the LTE language and in SIP (the IMS language). After the subscriber acknowledges that LTE can support the new dedicated bearer in LTE, the subscriber sends a SIP “UPDATE” message to the IMS network. This is a signal for IMS to complete the setup process and establish the call. It should be noted that, though the VoIP call will flow through the LTE network to the P-GW, voice packets will not transit through the IMS network elements.

IMS only comes back into action when the VoIP call is completed. Termination of the call is reflected in another SIP message called the “BYE” message, which passes through the S-CSCF and the P-CSCF. The P-CSCF detects the fact that the call had ended and triggers actions to collect IMS billing records. The P-CSCF then notifies the PCRF of call termination which in turn tells the PCEF to close out the LTE billing, and tells the P-GW to tear down the dedicated EPS bearer which had been established solely for the purpose of supporting the VoIP call.

At this point the VoLTE call and all associated signaling and billing actions are through.

Blog Post: Are Voice Packets Retransmitted in LTE?

Hooman — Mon, 17 Dec 2012 19:12:00 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

Blog Post: TTI Bundling and VoIP Performance in LTE - Part I

Hooman — Mon, 17 Dec 2012 18:35:00 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

Blog Post: The Beauty of LTE AMBER....Part 2 (Where it is used)

Ray — Mon, 10 Dec 2012 15:49:00 GMT

Last time we talked about the 3 AMBR values: Subscribed UE-AMBR, Subscribed APN-AMBR and Used UE-AMBR.

Where and how are they used?

The two subscribed values are stored in the LTE user’s subscriber profile in the Home Subscriber Server (HSS). The LTE user has one Subscribed UE-AMBR value and has one Subscribed APN-AMBR for each APN that they can connect to. Each of the AMBR values has a separate value for uplink and downlink. For simplicity of the discussion here, we won’t distinguish between uplink and downlink since the concepts are the same.

These values will be provided to the Mobility Management Entity (MME) when the LTE smartphone attaches to the LTE network. The MME will use these values when it creates the traffic bearers to carry the LTE user’s IP data packets.

When a LTE user connects to an APN, the APN-AMBR value will be provided to both the LTE user’s smartphone and the P-GW. The calculated Used UE-AMBR value will be generated at the MME whenever the LTE user connects to a new APN or disconnects from an APN. The Used UE-AMBR value will be provided to the eNB that the UE is currently connected to.

Here is a picture illustrating the Subscribed AMBR values for Chris and two of the APNs that he is subscribed to. All of the subscribed AMBR values are in Chris’ subscription profile stored at the HSS. All of Chris’ services are non-guaranteed bit rate services. In this case, Chris is sleeping and his smartphone is powered off.

Figure 1. Chris’ smartphone not attached to the LTE network

After Chris wakes up, he powers on his smartphone, it attaches to the LTE network and all of the subscribed AMBR values are provided to the MME. (See figure below) The smartphone also connects automatically to the NETRAY^SM APN so Chris can surf the Internet. When this connection occurs, the MME sends the NETRAY^SM Subscribed APN-AMBR value to both the P-GW and the smartphone. It also calculates the Used UE-AMBR value and provides that to the eNB.

Figure 2. Chris’ smartphone attaches to LTE network and connects to Internet service

The eNB will use the Used UE-AMBR value to limit the maximum data rate in both the UL and DL directions for all of Chris’ non-guaranteed bit rate services on the airlink. In this case, his Internet service is a non-guaranteed bit rate service.

The P-GW will use the NETRAY^SM Subscribed APN-AMBR value to limit the IP data traffic to a maximum rate of 18 Mbps in and out of the LTE network for Chris’ connection to the NETRAY^SM PDN. The smartphone will use the APN-AMBR value to allocate UL airlink resources at the appropriate amount to each APN connection. In this case, Chris has only one APN connection so all UL data traffic resources will be assigned to the NETRAY^SM APN traffic path.

Chris decides to stay home and watch a video using his LTE service. (See figure below) He selects Video service on his smartphone and the smartphone will initiate a connection to the STREAMRAY^SM APN to access video services. The MME will send the STREAMRAY^SM Subscribed APN-AMBR value to both the P-GW and the smartphone, and send an updated Used UE-AMBR value to the eNB.

Figure 3. Chris’ smartphone connects to Video service and still has Internet service connection

The eNB will use the updated Used UE-AMBR value to limit the maximum data rate in both the UL and DL directions for all of Chris’ non-guaranteed bit rate services on the airlink. In this case, the maximum combined data rate for both the Internet and Video connections will be limited to a maximum rate of 44 Mbps in both directions.

The P-GW will use the STREAMRAY^SM Subscribed APN-AMBR value to limit the video IP data packets to a maximum rate of 30 Mbps in and out of the LTE network for Chris’ connection to the STREAMRAY^SM PDN. The smartphone will use both the STREAMRAY^SM Subscribed APN-AMBR value and the NETRAY^SM Subscribed APN-AMBR value to allocate UL airlink resources (allocated by the eNB) at the appropriate amount to each APN connection. Other QoS parameters (not discussed in this blog article) are also used to make this allocation using a standards-defined algorithm.

Thus ends our story about LTE AMBRs and Chris’ day off at home watching videos.

Ray

Blog Post: The Beauty of LTE AMBER....Part 1 (AMBR defined)

Ray — Thu, 06 Dec 2012 17:22:00 GMT

Amber...that pretty glowing golden gemstone used for decoration and jewelry and also in some cases has medicinal uses. It also has the magical capabilities of preserving 30 million year-old dinosaur DNA in the innards of a 30 million year-old mosquito so we can enjoy live dinosaurs in movies like Jurassic Park. (I wonder what happened to those dinosaurs after they finished making that movie?)

What does this have to do with LTE? Well, amber isn’t really a gemstone, it is a fossilized tree resin. That means it takes a long time (like 10s of millions of years in time) for it to become amber. That amount of time sounds like Long Term Evolution to me!

Back to LTE AMBER...this AMBER doesn’t take as long to explain and define so no evolution required. So we can remove the “e” (for evolution), and it is just AMBR or more commonly known as Aggregate Maximum Bit Rate.

As LTE becomes more popular and the number of LTE users increase, there has to be some way to control the bandwidth allowed to individual users. That’s where AMBR comes in. The majority of LTE services right now are still “best effort”, a lot faster best effort than 3G but still best effort. AMBR defines the maximum possible bit rate allowed for a particular LTE user for all of their best effort (or non-guaranteed bit rate) services so they can’t hog all the available bandwidth from the other LTE users. AMBR values are not used for any services that are guaranteed bit rate services.

There are 3 AMBR values used in LTE:

Subscribed UE-AMBR

This is the maximum possible bit rate configured by the LTE operator for a particular LTE user for all of their best effort services. The key word here is “possible”. This is the maximum possible if bandwidth is available and also dependent on what and how many services the user is using. It is a configured value by the LTE operator and does not change. (unless the user changes their services or stops paying their wireless bill!)

Subscribed APN-AMBR

This is the maximum possible bit rate configured by the LTE operator for a particular LTE user for all of their best effort services on one particular Packet Data Network (as defined by the APN). Again, the key word here is “possible”. This is the maximum possible if bandwidth is available. This value should never be larger than Subscribed UE-AMBR value. An LTE user will have one Subscribed APN-AMBR value for each APN that they subscribe to for services.

And the third AMBR of interest is Used UE-AMBR.

Used UE-AMBR is the calculated UE-AMBR value that will be used to define the current working value for UE-AMBR for the active LTE user. In other words, this is the actual UE-AMBR value in effect for an active LTE user based on how many PDN connections (or APNs) they are actually using. It is calculated by summing together the Subscribed APN-AMBR values for all of the active PDN connections of the LTE user. The total value cannot exceed the Subscribed UE-AMBR value. This value is recalculated each time the LTE user starts another service (connects to another APN) or disconnects from a service (the UE actually disconnects from the PDN; the LTE user closing an internet web browser window does not disconnect a connection to an APN).

All of the AMBR values each have separate uplink and downlink values that can be different to reflect the different bandwidth needs in both directions.

Let’s look at an example:

Chris is lucky enough to have his LTE service provided by RTWI*. Chris has a Subscribed UE-AMBR value of 44 Mbps. He subscribes to Internet service (APN NETRAY^SM with Subscribed APN-AMBR = 18 Mbps), Streaming Video service (APN STREAMRAY^SM with APN-AMBR=30 Mbps) and Weather reporting service (APN STORMRAY^SM with Subscribed APN-AMBR = 1 Mbps). All of these services are non-guaranteed bit rate services.

Early in the morning, Chris logs in to his NETRAY^SM Internet service to check on his favorite blog site LTEUniversity.com. His smartphone makes a connection to the NETRAY^SM packet data network. His smartphone is connected to only one APN.

Chris’ Used UE-AMBR = 18 Mbps (Subscribed APN-AMBR for APN NETRAY^SM)

Chris looks outside and sees storm clouds and wants to check the weather. He logs in to his STORMRAY^SM service to check the weather, so his smartphone makes a connection to the STORMRAY^SM packet data network. Now that Chris has connected to a second APN, his Used UE-AMBR value will be recalculated.

Chris’ new calculated Used UE-AMBR = 19 Mbps.

18 Mbps (Subscribed APN-AMBR for APN NETRAY^SM) + 1 Mbps (Subscribed APN-AMBR for APN STORMRAY^SM).

Chris lives in Texas. The weather reporting service indicates that a tornado is imminent. He is scared to drive in to work. So he stays home to watch a video. He logs in to his STREAMRAY^SM video service to watch videos all day long at home. In this case, his smartphone makes a connection to the STREAMRAY^SM APN.

His smartphone now has 3 APN connections. His new calculated Used UE-AMBR value is now the sum of the Subscribed APN-AMBR values for all of the 3 APN connections.

18 Mbps (Subscribed APN-AMBR for APN NETRAY^SM) + 1 Mbps (Subscribed APN-AMBR for APN STORMRAY^SM) + 30 Mbps (Subscribed APN-AMBR for APN STREAMRAY^SM) = 49 Mbps. But the Used UE-AMBR cannot be greater than his Subscribed UE-AMBR. So Chris’ new calculated Used UE-AMBR value is 44 Mbps (equal to his Subscribed UE-AMBR value) when connected to all 3 APNs that Chris is subscribed to.

Since Chris is taking a break, we’ll take a break also and return in a later blog with the conclusion of this discussion when we will explain where these values are used in the LTE network.

Ray

*RayTel Wireless Inc.

For information on all of RayTel’s service plans and state-of-the-art smartphones, send cash (preferably large bills) and I’ll respond with information about RayTel’s possible high speed data services.

Blog Post: VoLTE Characteristics: A Brief Overview

Nishith — Thu, 27 Sep 2012 18:05:00 GMT

Voice over LTE (VoLTE) is expected to become the mainstream solution for providing voice services in commercial LTE networks in the coming years. VoLTE integrates voice over IP (VoIP), LTE radio network (i.e., E-UTRAN), LTE core network (i.e., EPC), and the IMS (IP Multimedia Subsystem) to support voice services. Let’s summarize the main characteristics of VoLTE from the perspectives of IMS capabilities, media codecs, LTE radio and core capabilities, and IP functionalities [1].

IMS plays an essential role in VoLTE. The UE performs SIP (Session Initiation Protocol) registration with the IMS network. IMS-AKA (IMS- Authentication and Key Agreement) procedures are followed for authentication. Integrity protection, whereby integrity of SIP signaling messages is ensured, is mandatory. The use of ISIM (IP Multimedia Services Identity Module) or USIM (UMTS Subscriber Identity Module) is required during the IMS authentication. Alphanumeric or MS ISDN based identities can be used for the consumer. SIP signaling messages are ASCII text messages and could thus be quite large. Hence, signaling compression is mandatory to reduce the bandwidth requirements, especially for over-the-air transmission. A variety of supplementary services such as communication forwarding and communication hold are supported.

As far as speech codecs are concerned, the basic Adaptive Multi Rate (AMR) speech codec with all the eight modes is mandatory; the popular data rate for good speech quality is 12.2 kbps. VoLTE optionally supports the AMR wideband codec with nine modes, where the data rate of 12.65 kbps (often called the anchor bit rate) is expected to be popular. The Real-time Transport Protocol/ Audio Video Profile (RTP/AVP) must be supported. Furthermore, RTP over UDP is used to transport AMR speech. While Real-time Transport Control Protocol (RTCP) is turned off during the active speech, it is temporarily enabled for link aliveness when the media are on hold.

LTE radio and core networks need to use optimal configurations for VoIP calls. For example, to make the over-the-air transmission of VoIP packets efficient, the IP-related overhead is reduced using Robust Header Compression (RoHC) at the eNodeB and the UE. A default EPS bearer with QCI (QoS Class Identifier)=5 toward the IMS Access Point Name (APN) is established to carry SIP signaling. This default EPS bearer requires an Acknowledged Mode Data Radio Bearer (DRB) between the eNodeB and the UE. A dedicated EPS bearer with QCI=1 is required to carry the VoIP traffic. Such dedicated EPS bearer requires an Unacknowledged Mode DRB. The network initiates the dedicated EPS bearer setup. The UE battery life is improved through the use of DRX (Discontinuous Reception), where the UE receives (and transmits) information intermittently and saves the battery power and the processing power between the subframes carrying the UE’s VoIP frames.

VoLTE supports both IPv4 and IPv6, with IPv6 expected to be quite popular. The UE conveys its preference for IPv4v6 (i.e., dual-stack IPv4 and IPv6) while connecting to the IMS APN. When the operator’s network supports IMS-based E911 calls, Release 9-compliant UE and the network are utilized.

MetroPCS is offering VoLTE to its subscribers. VoLTE is expected to be deployed by AT&T and Verizon in 2013.

References

[1] GSMA, “IMS Profile for Voice and SMS,” Version 3.0, PRD IR.92, December 22, 2010, http://www.gsma.com/newsroom/wp-content/uploads/2012/06/IR9230.pdf.