Tuesday 21 December 2010

An Intellectual Property Rights Primer

Page 5-8 is a very good starting point to understand the IPR issues surrounding LTE.
The Essentials of Intellectual Property - Sep 2010
View more documents from Zahid Ghadialy.
An accompanying video and download information is available on Ericsson's website here.

Monday 20 December 2010

HSPA and LTE carrier aggregation

Last week there were press releases about the Long Term HSPA Evolution. The only thing that got reported mostly is the 650Mbps peak rates. There are other interesting features in Release-11 that is covered in Nokia Siemens Networks presentation. Here is one of them:

The idea of aggregating multiple carriers to increase performance is included in both LTE and HSPA. A logical step to fully leverage existing HSPA deployments and future LTE deployments is to aggregate the capacity of both systems and tie them together into a single mobile system. The concept is illustrated in Figure 3.

The aggregation of LTE and HSPA systems enables the peak data rates of the two systems to be added together. It also allows for optimal dynamic load balancing between the two radios. A small number of active LTE and HSPA aggregation-capable devices is sufficient to exploit this load balancing gain, since the network can schedule these devices to carry more data on the radio that has lower instantaneous loading and less data on the radio with the higher load at any given moment.

Carrier aggregation is expected to have no impact on the core network.


Sunday 19 December 2010

Multicarrier and multiband HSPA aggregation

From NSN Whitepaper on HSPA Evolution:

HSPA Release 10 with 4-carrier HSDPA provides a peak downlink data rate of 168 Mbps using 2x2 MIMO (Multiple Input Multiple Output) over the 20 MHz bandwidth. This matches the LTE Release 8 data rates obtained using comparable antenna and bandwidth configurations. A natural next step for the HSPA Release 10 downlink is to further extend the supportable bandwidths to 40 MHz with 8-carrier HSDPA, doubling the Release 10 peak rate to 336 Mbps.

8-carrier HSDPA coupled with 4x4 MIMO doubles the peak rate again to reach 672 Mbps, see Figure 1. The evolution of HSPA beyond Release 10 will push the peak data rates to rival those provided by LTE Advanced.


In addition to increased peak rates, the aggregation of a larger number of carriers improves spectrum utilization and system capacity owing to inherent load balancing between carriers. Additional capacity gains from trunking and frequency domain scheduling will also be seen.

Typical spectrum allocations do not provide 40 MHz of contiguous spectrum. To overcome spectrum fragmentation, HSDPA carrier aggregation allows carriers from more than one frequency band to be combined. 3GPP Release 9 already makes it possible to achieve 10 MHz allocation by combining two 5 MHz carriers from different frequency bands, such as one carrier on 2100 MHz and another on 900 MHz.


The 4-carrier HSDPA of Release 10 extends this further, allowing the aggregation of up to four carriers from two separate frequency bands. Long Term HSPA Evolution allows eight carriers. Typical cases of HSDPA multiband aggregation are shown in Figure 2.

Thursday 16 December 2010

Packet Flow in 2.5G, 3G, 3.5G and 4G




The 'LTE Signaling' is a very interesting book just being released that is a must have for people who are involved in design, development and testing. A book that explains the basic concepts from beginning till advanced concepts and explains how different components and interfaces fit together.

Though I havent yet read this book, I have read the earlier one titled UMTS Signaling, from the same authors that is an excellent reference for understanding Signalling in UMTS. I have no doubt that this book will be the same high quality.

The Excerpt on Wiley's website provides complete chapter 1 which is quite detailed and the Packet flow pictures and details below is extracted from this book.
The first stage of the General Packet Radio Service (GPRS), that is often referred to as the 2.5G network, was deployed in live networks starting after the year 2000. It was basically a system that offered a model of how radio resources (in this case, GSM time slots) that had not been used by Circuit Switched (CS) voice calls could be used for data transmission and, hence, profitability of the network could be enhanced. At the beginning there was no pre-emption for PS (Packet Switched) services, which meant that the packet data needed to wait to be transmitted until CS calls had been finished.

In contrast to the GSM CS calls that had a Dedicated Traffic Channel (DTCH) assigned on the radio interface, the PS data had no access to dedicated radio resources and PS signaling, and the payload was transmitted in unidirectional Temporary Block Flows (TBFs) as shown in Figure 1.2.

In Release 99, when a PDP (Packet Data Protocol) context is activated the UE is ordered by the RNC (Radio Network Controller) to enter the Radio Resource Control (RRC) CELL_DCH state. Dedicated resources are assigned by the Serving Radio Network Controller (SRNC): these are the dedicated physical channels established on the radio interface. Those channels are used for transmission of both IP payload and RRC signaling – see Figure 1.7. RRC signaling includes the exchange of Non-Access Stratum (NAS) messages between the UE and SGSN.

The spreading factor of the radio bearer (as the combination of several physical transport resources on the Air and Iub interfaces is called) depends on the expected UL/DL IP throughput. The expected data transfer rate can be found in the RANAP (Radio Access Network Application Part) part of the Radio Access Bearer (RAB) assignment request message that is used to establish the Iu bearer, a GPRS Tunneling Protocol (GTP) tunnel for transmission of a IP payload on the IuPS interface between SRNC and SGSN. While the spreading factor controls the bandwidth of the radio connection, a sophisticated power control algorithm guarantees the necessary quality of the radio transmission. For instance, this power control ensures that the number of retransmitted frames does not exceed a certain critical threshold.

Activation of PDP context results also in the establishment of another GTP tunnel on the Gn interface between SGSN and GGSN. In contrast to IuPS, where tunnel management is a task of RANAP, on the Gn interface – as in (E)GPRS – the GPRS Tunneling Protocol – Control (GTP-C) is responsible for context (or tunnel) activation, modification, and deletion.

However, in Release 99 the maximum possible bit rate is still limited to 384 kbps for a single connection and, more dramatically, the number of users per cell that can be served by this highest possible bit rate is very limited (only four simultaneous 384 kbps connections per cell are possible on the DL due to the shortness of DL spreading codes).

To increase the maximum possible bit rate per cell as well as for the individual user, HSPA was defined in Releases 5 and 6 of 3GPP.

In High-Speed Downlink Packet Access (HSDPA) the High-Speed Downlink Shared Channel (HSDSCH) which bundles several High-Speed Physical Downlink Shared Channels (HS-PDSCHs) is used by several UEs simultaneously – that is why it is called a shared channel.

A single UE using HSDPA works in the RRC CELL_DCH state. For DL payload transport the HSDSCH is used, that is, mapped onto the HS-PDSCH. The UL IP payload is still transferred using a dedicated physical data channel (and appropriate Iub transport bearer); in addition, the RRC signaling is exchanged between the UE and RNC using the dedicated channels – see Figure 1.8.

All these channels have to be set up and (re)configured during the call. In all these cases both parties of the radio connection, cell and UE, have to be informed about the required changes. While communication between NodeB (cell) and CRNC (Controlling Radio NetworkController) uses NBAP (Node B Application Part), the connection between the UE and SRNC (physically the same RNC unit, but different protocol entity) uses the RRC protocol.

The big advantage of using a shared channel is higher efficiency in the usage of available radio resources. There is no limitation due to the availability of codes and the individual data rate assigned to a UE can be adjusted quicker to the real needs. The only limitation is the availability of processing resources (represented by channel card elements) and buffer memory in the base station.

From the user plane QoS perspective the two major targets of LTE are:
• a further increase in the available bandwidth and maximum data rate per cell as well as for the individual subscriber;
• reducing the delays and interruptions in user data transfer to a minimum.

These are the reasons why LTE has an always-on concept in which the radio bearer is set up immediately when a subscriber is attached to the network. And all radio resources provided to subscribers by the E-UTRAN are shared resources, as shown in Figure 1.9. Here it is illustrated that the IP payload as well as RRC and NAS signaling are transmitted on the radio interfaces using unidirectional shared channels, the UL-SCH and the Downlink Shared Channel (DL-SCH). The payload part of this radio connection is called the radio bearer. The radio bearer is the bidirectional point-to-point connection for the user plane between the UE and eNodeB (eNB). The RAB is the user plane connection between the UE and the Serving Gateway (S-GW) and the S5 bearer is the user plane connection between the S-GW and public data network gateway (PDN-GW).

The end-to-end connection between the UE and PDN-GW, that is, the gateway to the IP world outside the operator’s network, is called a PDN connection in the E-UTRAN standard documents and a session in the core network standards. Regardless, the main characteristic of this PDN connection is that the IP payload is transparently tunneled through the core and the radio access network.

To control the tunnels and radio resources a set of control plane connections runs in parallel with the payload transport. On the radio interface RRC and NAS signaling messages are transmitted using the same shared channels and the same RLC transport layer that is used to transport the IP payload.

RRC signaling terminates in the eNB (different from 3G UTRAN where RRC was transparently routed by NodeB to the RNC). The NAS signaling information is – as in 3G UTRAN – simply forwarded to the Mobility Management Entity (MME) and/or UE by the eNB.

You can read in detail about all these things and much more from the Wiley's website here.

Tuesday 14 December 2010

What are Heterogeneous Networks (HetNets)?

HetNets are hot. I hear about them in various contexts. Its difficult to find exactly what they are and how they will work though. There is a HetNets special issue in IEEE Communications Magazine coming out next year but that's far away.

I found an interesting summary on HetNets in Motorola Ezine that is reproduced below:


“The bigger the cell site, the less capacity per person you have,” said Peter Jarich, research director with market intelligence firm Current Analysis. “If you shrink coverage to a couple of blocks, you are having that capacity shared with a fewer number of people, resulting in higher capacity and faster data speeds.”

This is a topic the international standards body, the Third Generation Partnership Project (3GPP), has been focusing on to make small cells part of the overall cellular network architecture.

“What we’re seeing is a natural progression of how the industry is going to be addressing some of these capacity concerns,” said Joe Pedziwiatr, network systems architect with Motorola. “There is a need to address the next step of capacity and coverage by introducing and embracing the concepts of small cells and even looking at further advances such as better use of the spectrum itself.”

As such, discussion regarding this small-cell concept has emerged into what is called heterogeneous networks, or Het-Net, for short. The idea is to have a macro wireless network cooperating with intelligent pico cells deployed by operators to work together within the macro network and significantly improve coverage and augment overall network capacity. Small cells can also be leveraged to improve coverage and deliver capacity inside buildings. Indoor coverage has long been the bane of mobile operators. Some mobile operators are already leveraging this concept, augmenting their cellular service offering with WiFi access to their subscriber base in order to address the in-building coverage and capacity challenges facing today’s cellular solutions.

Pedziwiatr said this Het-Net structure goes far beyond what is envisioned for femtocells or standard pico cells for that matter. Introducing a pico cell into the macro network will address but just one aspect of network congestion, namely air interface congestion. The backhaul transport network may become the next bottleneck. Finally, if all this traffic hits the core network, the congestion will just have shifted from the edge to the core.

“This requires a system focus across all aspects of planning and engineering,” Pedziwiatr said. “We’re trying to say it goes beyond that of a femto. If someone shows up at an operator and presents a pico cell, that is just one percent of what would be needed to provide true capacity relief for the macro network.”

Femtocells, otherwise known as miniature take-home base stations, are obtained by end users and plugged into a home or office broadband connection to boost network signals inside buildings. A handful of 3G operators worldwide are selling femtocells as a network coverage play. For the LTE market, the Femtocell Forum is working to convince operators of the value of a femtocell when it comes to better signal penetration inside buildings and delivering high-bandwidth services without loading the mobile network. This is possible, because the backhaul traffic runs over the fixed line connection. However, this femtocell proposition largely relies on end user uptake of them—not necessarily where operators need them, unless they install femtocells themselves or give end users incentives to acquire them.

As with any new concept, there are challenges to overcome before Het-Nets can become reality. Het-Nets must come to market with a total cost of ownership that is competitive for an operator to realize the benefit of providing better capacity, higher data speeds, and most of all, a better end-user experience said Chevli.

“The level of total cost of ownership has to be reduced. That is where the challenge is for vendors to ensure that any new solution revalidates every existing tenet of cellular topology and evolve it to the new paradigm being proposed,” Chevli said. “You can’t increase the number of end nodes by 25X and expect to operate or manage this new network with legacy O&M paradigms and a legacy backhaul approach.”

One of the issues is dealing with interference and Het-Net network traffic policies. “How do you manage all of these small cell networks within the macrocell network?” asked Jarich. “Right now if you have a bunch of femtocells inside a house, there is this concept that the walls stop the macrocell signals from getting in and out. You get a separation between the two. Go outdoors with small cells underlying bigger cells and you get a lot more interference and hand-off issues because devices will switch back and forth based on where the stronger signal is.”

Pedziwiatr said for a Het-Net to work, it would require a change in node management, whereby an operator isn’t burdened with managing big clusters of small cells on an individual basis. “We see elements of SON (self organizing networks), self discovery and auto optimization that will have to be key ingredients in these networks. Otherwise operators can’t manage them and the business case will be a lot less attractive,” he said.

Fortunately, the industry has already been working with and implementing concepts of SON in LTE network solutions. In the femtocell arena also, vendors have been incorporating some elements and concepts of SON so that installing them is a plug-and-play action that automatically configures the device and avoids interference. But even then, Het-Nets will require further SON enhancement to deal with new use cases, such as overlay (macro deployment) to underlay (pico deployments) mobility optimization.

When it comes to LTE, SON features are built into the standard, and are designed to offer the dual benefit of reducing operating costs while optimizing performance. SONs will do this by automating many of the manual processes used when deploying a network to reduce costs and help operators commercialize their new services faster. SON will also automate many routine, repetitive tasks involved in day-to-day network operations and management such as neighbor list discovery and management.

Other key sticking points are deployment and backhaul costs. If operators are to deploy many small cells in a given area, deploying them and backhauling their traffic should not become monumental tasks.

Chevli and Pedziwiatr envision Het-Nets being deployed initially in hot zone areas – where data traffic is the highest – using street-level plug-and-play nodes that can be easily installed by people with little technical know-how.

“Today, macro site selection, engineering, propagation analysis, rollout and optimization are long and expensive processes, which must change so that installers keep inventories of these units in their trucks, making rollout simple installations and power-ups,” said Pedziwiatr. “These will be maintained at a minimum with quick optimization.”

The notion of backhauling traffic coming from a large cluster of Het-Net nodes could also stymie Het-Nets altogether. Chevli said that in order to keep costs down, Het-Net backhaul needs to be a mix of cost-effective wireless or wired backhaul technology to aggregate traffic from what likely will be nodes sitting on lamp posts, walls, in-building and other similar structures. The goal then is to find a backhaul point of presence to aggregate the traffic and then put that traffic on an open transport network in the area.

Backhaul cost reductions may also be a matter of finding ways to reduce the amount of backhaul forwarded to the core network, Pedziwiatr said. These types of solutions are already being developed in the 3G world to cope with the massive data traffic that is beginning to crush networks. For traffic such as Internet traffic, which doesn’t need to travel through an operator’s core network, offloading that traffic as close to the source as possible would further drive down the cost of operation through the reduction of backhaul and capacity needs of the core network.

In the end, with operators incorporating smaller cells as an underlay to their macro network layer rather than relying on data offloading techniques such as femtocells and WiFi that largely depend on the actions of subscribers and impacted by the surrounding cell operating in the same unlicensed frequency, Het-Nets in licensed spectrum will soon become the keystone in attacking the ever-present congestion issue that widely plagues big cities and this is only likely to get worse over time.

Image Source: Dr. Daichi Imamura, Panasonic presentation.

Monday 13 December 2010

Refresher: LTE RLC Layer Protocol

6LoWPAN: Low power Wireless Personal Area Networks

From Wikipedia: 6lowpan is an acronym of IPv6 over Low power Wireless Personal Area Networks, or (as the "personal" qualification is no longer relevant), IPv6 over LoW Power wireless Area Networks. 6lowpan is the name of a working group in the internet area of the IETF. The 6lowpan group has defined encapsulation and header compression mechanisms that allow IPv6 packets to be sent to and received from over IEEE 802.15.4 based networks. IPv4 and IPv6 are the work horses for data delivery for local-area networks, metropolitan area networks, and wide-area networks such as the Internet.

There is a book from Wiley entitled "6LoWPAN: The Wireless Embedded Internet", which has a good definition and explanation of 6LoWPAN that I am using below. Wiley has excerpt from the book that details the complete introductory chapter.

As the Internet of routers, servers and personal computers has been maturing, another Internet revolution has been going on – The Internet of Things (see pic below). The vision behind the Internet of Things is that embedded devices, also called smart objects, are universally becoming IP enabled, and an integral part of the Internet. Examples of embedded devices and systems using IP today range from mobile phones, personal health devices and home automation, to industrial automation, smart metering and environmental monitoring systems. The scale of the Internet of Things is already estimated to be immense, with the potential of trillions of devices becoming IP-enabled. The impact of the Internet of Things will be significant, with the promise of better environmental monitoring, energy savings, smart grids, more efficient factories, better logistics, better healthcare and smart homes.


The Internet of Things can be understood as a layer of digital information that covers the physical world. Objects and places become part of the Internet of Things in two ways: First, data and information can be associated with a particular location, using geo-coordinates or a street address. Second with sensors and RFID tags or transmitters installed in these objects allowing then to be accessed via Internet protocols.

Remember, Ericsson has already predicted 50 Billion connected devices by 2050. See here.

The Institute of Electrical and Electronics Engineers (IEEE) released the 802.15.4 lowpower wireless personal area network (WPAN) standard in 2003, which was a major milestone, providing the first global low-power radio standard. Soon after, the ZigBee Alliance developed a solution for ad hoc control networks over IEEE 802.15.4, and has produced a lot of publicity about the applications of wireless embedded technology. ZigBee and proprietary networking solutions that are vertically bound to a link-layer and application profiles only solve a small portion of the applications for wireless embedded networking. They also have problems with scalability, evolvability and Internet integration.

The IEEE 802.15.4 standard released in 2003 was the biggest factor leading to 6LoWPAN standardization. For the first time a global, widely supported standard for lowpower wireless embedded communications was available [IEEE802.15.4]. The popularity of this new standard gave the Internet community the needed encouragement to standardize an IP adaptation for such wireless embedded links.

The ideal use of 6LoWPAN is in applications where:
• embedded devices need to communicate with Internet-based services,
• low-power heterogeneous networks need to be tied together,
• the network needs to be open, reusable and evolvable for new uses and services, and
• scalability is needed across large network infrastructures with mobility.

Connecting the Internet to the physical world enables a wide range of interesting applications where 6LoWPAN technology may be applicable, for example:
• home and building automation
• healthcare automation and logistics
• personal health and fitness
• improved energy efficiency
• industrial automation
• smart metering and smart grid infrastructures
• real-time environmental monitoring and forecasting
• better security systems and less harmful defense systems
• more flexible RFID infrastructures and uses
• asset management and logistics
• vehicular automation

One interesting example application of 6LoWPAN is in facility management, which is the management of large facilities using a combination of building automation, asset management and other embedded systems. This quickly growing field can benefit from 6LoWPAN, is feasible with today’s technology, and has real business demand.

You can read more from the book on Wiley's website here.

More information on purchasing and reviews on Amazon's website below:



Sunday 12 December 2010

The silent heroes of the wireless world

Often you will hear about some famous people from certain organisations who speak at conferences and meetings but there are often in the background many people who labour to ensure that reports, documents, presentations and technology are completed without problems.

Last Friday, I met up with some old colleagues who are these silent movers and shakers in our mobile industry. Often behind multiple monitors and pile of documents, these people work on the cutting edge future technologies. It was nice to know that they do read and refer to my blog from time to time and find it useful.

I should also like to mention the people who often mail me to thank me for the blog and the 3g4g website. I do quite often bump into people who know me for my work but dont know me personally. Sometimes they do get a bit surprised because my HQ (humour quotient) is very high. I have a jokelist active since 1999 and even though I dont get enough time to post jokes I do make it a point to keep it alive.

I am fortunate enough to learn a lot from such people, as knowledge is limitless and there is always something everyone can contribute as they may know it much better than others.

So please feel free to say hello to me when you come across me in any conference, presentation, party or even interviews. Its always good to know people.

Thursday 9 December 2010

Minimization of Drive Tests (MDT) in 3GPP Release-10

Another one that came from the SON conference.

At present, the network optimisation after it is operational is generally done by drive testing. In this an equipment (test mobile) that collects measurements and location information collects all the required information while the equipment is being driven in a car on the roads and this information is used offline to analyse the coverage in different locations and based on that the parameters, power, antenna locations, antenna tilts, etc. are optimised. After the changes to any of the optimisation paramaters, drive test has to be undertaken again to make sure that the impact of these changes are positive.

One more thing that has to be taken account of is that the drive tests have to be carried out at di9ffert times to be able to predeict the behaviour at different loads.

Using drive tests for network optimization purposes is costly and causes also additional CO2 emissions, so it is desirable to develop automated solutions, including involving UEs in the field, in 3GPP to reduce the operator costs for network deployment and operation. The studies done as part of the study item phase [1] have shown that it is beneficial to collect UE measurements to enable a more efficient network optimisation and it is feasible to use control plane solutions to acquire the information from devices. This information, together with information available in the radio access network can be used for Coverage Optimization purposes.

It should be remembered that drive tests form a big part of the Network opex and Deutsche Telekom for example expects a 40% cost saving with SON (and MDT is a part of that)

Goal of MDT in 3GPP Rel.10
– Automatic UE measurements collection and data logging used to replace the manual drive testing that the operators have to perform in their networks
– Evaluation of network performance per physical location
– For both HSPA & LTE


There are two different types of MDT:

Immediate MDT: MDT functionality involving measurement performance by UE in CONNECTED state and reporting of the measurements to eNB/RNC available at the time of reporting condition.

Logged MDT: MDT functionality involving measurement performance by UE in IDLE state at points in time when configured conditions are satisfied, its storage in measurement log for reporting to eNB/RNC at a later point in time.

The solutions for MDT shall be able to work independently from SON support in the network. Relation between measurements/solution for MDT and UE side SON functions shall be established in a way that re-use of functions is achieved where possible.

• Use cases
– 3GPP R10: Coverage optimization : Prio1
– For 3GPP > R10 :Capacity optimization, Mobility optimization, Parameterization of common channels, QoS verification, no specific measurements
- In Release-11 MDT Enhancements and evaluation of other MDT use cases, such as ”Parameterization of common control channels” and Positioning enhancements will be explored.

• MDT and SON
– MDT is about UE measurement collection for off-line processing No automatic mechanism is defined MDT
– SON is aiming at instantaneous/automated reaction on short to middle term network issues

It should be noted that MDT is a wide area and some of the boundaries between MDT and SON are a bit fuzzy. One of the other ways for SON is to enable detected cell measurements in the handset. This will give the indication about the cells that are not in the monitored set but the UE is able to see.

The RRC (control plane) measurements for LTE are not advanced enough and there are no measurements for UE position. On the other hand for UMTS/HSPA the UE positioning measurements could be used to report the exact location at the point of measurements. There are some discussions for enhancing the LTE measurements to include the longitude, latitude, altitude, velocity and even direction (too ambitious?).

Finally it should be pointed out that UE based reporting based on the User Plane Measurements (typically done by the operator installing a small application on the handset) can be performed by the operator in case a user is reporting poor coverage or failure in an area. Since these are proprietary applications, the operator can collect variety of information including but not limited to, position information, crrent cell and neighbour cell power levels, etc.

With all the control plane measurements and user plane measurements, the battery life could be severely affected and it has to be made sure that these are done very seldomly or with users permission.

Some of the things mentioned above may not be exactly true and if you know better please feel free to correct me.

[1] 3GPP TR 36.805 - Study on Minimization of drive-tests in Next Generation Networks

[2] 3GPP TS 37.320 - Universal Terrestrial Radio Access (UTRA) and Evolved Universal Terrestrial Radio Access (E-UTRA); Radio measurement collection for Minimization of Drive Tests (MDT); Overall description; Stage 2 (Release 10)

Wednesday 8 December 2010

SON for reducing Opex in Legacy Networks

Presented by Stéphane Téral, Principal Analyst, Mobile and FMC Infrastructure, Infonetics Research in the 1st Self-Organizing Networks Conference, 30th Nov and 1st Dec. 2010 at the Waldorf Hilton.

Tuesday 7 December 2010

SON framework in 3GPP

From a Presentation by Cinzia Sartori from Nokia Siemens Networks (NSN) in the Self-Organising Networks Conference in London, Nov. 2010

Release 8 functionality
• Self-configuration procedures

Release 9 enhancements
• Self-optimization procedures
• Energy Saving Intra-RAT

Release 10 objectives
• Extend Self-optimization procedures , including inter-RAT
• Minimization of Drive Test (MDT)
• Energy Saving extension, including Multi-RAT (Study Item)
• 3G-ANR
• SON Conflict Resolution

SON features for R11 (Probably - Under Discussion)
• Minimization of Drive Tests (MDT) enhancements
• Mobility Robustness Optimization for MultiRAT
• SON for LTE-A features defined in Rel.10
•• Hetrogeneous Networks aka. HetNet?
•• SON for Relays
•• SON for Carrier Aggregation

Sunday 5 December 2010

Inter-Operability Testing (IOT) Process Flow

I have been asked couple of times about the IOT process, how it works, etc. The above picture is from a Huawei Presentation in "The 3GPP release 8 IMS Implementation, Deployment & Testing workshop".

You can read more about 3G/4G testing from my old article here.

Saturday 4 December 2010

Role of ENUM in NGN Interconnect

I have blogged about ENUM here and here and its been quite a while. In these last couple of years ENUM has evolved a bit and now GSMA has its own Number translation service called Pathfinder.

The following is a presentation by GSMA in the recently concluded The 3GPP release 8 IMS Implementation, Deployment & Testing workshop.

Friday 3 December 2010

Presentation: IMS for 3G Voice Services and Migration Strategies

Very interesting presentation from NTT DoCoMo in the IMS workshop I blogged about yesterday. It shows their strategy to move from legacy core network to an All IP Network (AIPN).


Thursday 2 December 2010

The 3GPP release 8 IMS Implementation, Deployment & Testing workshop

The 3GPP release 8 IMS Implementation, Deployment & Testing workshop took place in Sophia Antipolis on 24-25 November 2010.

The event was attended by 70 delegates actively participating to the discussions.
Presenting companies included: Tel : A1 Telekom Austria, Alcatel Lucent, Codenomicon, Conformiq, Eircom, Elvior, ETSI, France Telecom, GSMA, Huawei, Huawei, Mobitel, NTT DoCoMo, SFR, Telecom Italia, TestingTech, TU Berlin, Wind, Wipro, ZTE.

Here are the highlights from the ETSI document:

Goals and Outcome for this workshop

Share exprience from IMS implementation
Highlight areas for further specifications, for
Standards and Testing
Learn of issues and possible resolutions

Comments from The IMS Network Testing Group

Develop IMS core network test specifications based upon 3GPP, for:
• Interoperability
• conformance
• network integration
Hold interoperability events (IMS Plugtests)
Coordinate with other organisations such as OMA, MSF, GSMA

Implementations

• Beyond small islands, second wave to replace unscalable, unmaintenable early VoIP systems
• Implementation options - Hybrid CS-GW for transition from CS to LTE, which already has 2 million subscribers on IMS/CS-GW/RNC
• Auto provisioning - to simplify complexity
• IMS functions must be implemented in the core – not in any access network, such as LTE, and can be used for non-Voice as well


Implementing RCS (Rich Communication Suite)

• RCS trial feedback - Good feedback from 400 trial users on RCS but difficult to configure SBC
• RCS implementations should include aggregation with SNS (Social Network Services)– eg contact list from Facebook
• Most appreciated feature of RCS is: - cross-operator interworking and compatibility with ordinary phones, not just smartphones


Specific Issues and Resolutions

• FAX – Delay and Jitter issues - FTTH will solve long delays etc
• Emergency and Lawful Intercept with IMS -There are standards and developed solutions available but Currently still falls back to CS /TDM
• Data Provisioning speed is important, to achieve no service interruption.
• 3GPP II-NNI: Inter-IMS Network to Network Interface - Two levels: Solx (service with control function) and Coix (connection – a pipe for media).
• “PathFinder” Global ENUM – like DNS for phone number; It is a solution to number portability and can optimise routing


About Services

• Most issues are Beyond IMS - integrating OSS/BSS, existing systems, inter-vendors interfaces
• IMS and IN - Pity the Standards did not bring IN and IMS close together; Need iFC enhancements, like in IN; Need to support combining services
• OTT and SNS dominate growth - occupies the minds of commercial people, GSMA-like services have slowed down
• Service layer (Wipro) – Telcos want one SDP to serve all - include IMS and non-IMS services, human and non-humans on NAB, context based, and charge only what is ‘consumed’


Testing Methods, Tools and Test Beds

• Integrate Conformance checking with interoperability testing
• Automation of interoperability trace checking – it can reduce costs by more than 50 % compared to manual validation
• Independent Test Bed- available EPC playground for prototyping applications
• Protocol message customisation tool - allows changing the message and customise the flow
• Security testing tool - testing by ‘fuzzing’, 100% TTCN free – everything is already build in
• IMS is a multi vendor environment - Testing and validation must be an integral part of the deployment process


Memorable Quotes

“IMS is a Journey, not a destination” (ALU)
“SDP is almost anything” (Matjas Bericic, Mobitel)
“Voice as an app versus Voice as a Service” is a challenge (Manuel Vexler, Huawei)
“IMS is not a box, it is a network” (Matjas Bericic, Mobitel)
“global ENUM is DNS for phone numbers” (Adrian Dodd, GSMA)
“Kill with one SIP” (Ari Takanen, Codenomicon)
“ IOP is the red thread running through the entire ETSI standards development process “ (Milan Zoric, ETSI)

All documents from this workshop is available at: http://docbox.etsi.org/Workshop/2010/201011_IMSWORKSHOP/

Wednesday 1 December 2010