Case study of SKT deployment using the C-RAN architecture

Recently I came across this whitepaper by iGR, where they have done a case study on the SKT deployment using C-RAN. The main point can be summarised from the whitepaper as follows:

This approach created several advantages for SK Telecom – or for any operator that might implement a similar solution – including the:

• Maximum re-use of existing fiber infrastructure to reduce the need for new fiber runs which ultimately reduced the time to market and capital costs.
• Ability to quickly add more ONTs to the fiber rings so as to support additional RAN capacity when needed.
• Support of multiple small cells on a single fiber strand. This is critical to reducing costs and having the flexibility to scale.
• Reduction of operating expenses.
• Increased reliability due to the use of fiber rings with redundancy.
• Support for both licensed and unlicensed RAN solutions, including WiFi. Thus, the fronthaul architecture could support LTE and WiFi RANs on the same system.

As a result of its implementation, SK Telecom rolled out a new LTE network in 12 months rather than 24 and reduced operating expenses in the first year by approximately five percent. By 2014, SK Telecom expects an additional 50 percent OpEx savings due to the new architecture.

Anyway, the paper is embedded below for your perusal and is available to download from the iGR website here.

Fronthaul: The New Paradigm for Enabling the Het-Net from Zahid Ghadialy

Telecom API's: The why and what

It felt like with the focus on LTE/4G and Small Cells and everything else in the mobile industry, the API's vanished in the background...or so it seemed. Telco API's are alive and kicking and there is a renewed focus on them.

This is from an AT&T press release not so long back:

AT&T*, already the leading carrier deploying network Application Programming Interfaces (APIs) to developers,1 today announced it has launched an enterprise-focused API program that allows enterprise customers, wholesale collaborators and solution providers to innovate using AT&T network APIs.

Led by industry thought leader Laura Merling, VP of Ecosystem Development and Platform Solutions, AT&T is pursuing a telecommunications industry API opportunity expected to grow to $157 billion in global revenues by 2018.2

APIs are software interfaces that provide access to data and core functions within AT&T’s network. By opening up its APIs to customers, AT&T believes it can help them meet three key challenges: do more without spending more; harness technology to gain competitive advantage; and support their ability to create and deploy applications that can be used on almost any device around the world.

...

Some examples of how enterprises can use AT&T APIs include:

• Content formatting: Using APIs, video content from a company’s video library stored in the cloud can be easily optimized in near real-time for users to watch on almost any device and network.
• Communications services: To bring more efficiency and productivity to business operations, businesses can use APIs to automate voice and video calls, integrating speech and video services into applications.

Sometime back, Martin Geddes (MG) posted his discussion on this topic with Alan Quayle (AQ) here:

I interviewed Alan earlier this week, and here is our joint “state of the telecom API nation” report.

MG: My early telecom API project crashed and burned, and past industry initiatives like ParlayX never took off. What has changed since the early 2000s that is triggering new and rapid growth?

AQ: Both the technology and the market have evolved. Large new developer communities have been created by Apple and Google, delivering value through those ecosystems. The need for such ecosystems and partnerships in telecoms is now driven by business demand, not technology supply, and thus is no longer seen as unusual or controversial.

Ten years ago there were developers, but the developer platforms were not as sophisticated. The technology was complex to consume, so you had to be a hardcore developer to use what was on offer. Today we have a mass developer market of people with Web development skills, and an Independent Software Vendor (ISV) market able to consume telecoms capabilities using their existing skills base.

The whole ICT industry – including ancillary services like consulting and equipment – is around a $5tn annual market. Yet it notably lacks a large-scale profitable developer ecosystem for networked service delivery. Why has it failed? Historically there have been too many silos, and too much friction to engage with them. What we are now seeing are companies like Apidaze, Bandwidth, OpenCloud, Plivo, Telestax, Tropo, and Twilio eliminating both of these. Lots of money is being spent on marketing to developers, creating a new business opportunity that telcos and broader ecosystem can take advantage of.

Notably this ecosystem is about more than just APIs. There's also the whole free and open source software arena too. Tools like FreeSWITCH, OpenCloud, Mobicents and WebRTC are becoming core to service innovation. Platforms like Tropo’s Ameche open up new opportunities for value-added voice services. We will be looking at the whole development stack at the Summit in Bangkok.

Who are the key consumers of telecoms APIs and what for?

Telecoms APIs are generally used by enterprises that are embedding communications into their core processes. The term “Communications Enabled Business Processes” was used in the past, but the name never took off, even if the concept did. As such, there is a quiet enterprise communications revolution going on. (See my recent articlefor more information.)

Lots of businesses are doing cool stuff, often to sell to other enterprises. These projects and platforms may not get much press individually, but collectively they add up to a significant market.

For example, Turkcell are a leader in this area of enterprise API delivery. However, they don’t talk about APIs, because it’s about the end user and the value from a better customer experience. They focus on promoting their enterprise services, all of which are (crucially) backed by sales team with technical support. Example services include FreeURL, where customers surf on your pages for free; customer device model and mobile number to support efficient and effective interaction regardless of end user device type; a “find the nearest store” capability to drive sales; and click to call services to capture leads.

That these telecoms services use APIs is about as interesting as them using electricity. The business value and innovation is in the enhanced customer experiences they enable.

Who makes money from producing telecoms APIs and how?

Everyone can! Telcos, intermediaries who work with the developers, enterprises and systems integrators. To make progress, however, telcos have to accept they can't do everything for themselves. For instance, you have to know what developers want – and that means Web scripting, not REST APIs. We will for the foreseeable future need middlemen who translate the value of telecoms APIs into a consumable form.

The greatest value is in customer interaction APIs. The need to communicate with suppliers and customers is fundamental to the human condition, we have been doing it for millennia, and will not stop any time soon. There are long-established markets like bulk SMS and automated calling, and these are ripe for new growth with new capabilities to interact and transact with customers.

What are the most promising areas for future growth?

The growth is around value-added services, notably around the current voice cash cow. It’s time for telcos to remember their heritage: you're the phone company. The distracting “digital lifestyle” stuff only makes money for the content companies. There are too many adjacent businesses being built where the telco doesn't have enough competence, and are competing against low-end competition (e.g. cheap webcams vs managed CCTV or home monitoring services).

Lots of consultants are selling future billion-dollar markets that don't exist. Telcos need to stick to the basic nuts and bolts of communications services, and do them better.

What are the key challenges facing this space?

The key challenge is that this game is that it requires an ecosystem, and telcos are islands. That doesn't mean they should copy Apple and Android, but instead they need to focus on segments where they have credible value and an advantage. A $5tn industry should be able to do this.

What it requires is a whole offering, including sales, business development and support. API-enablement is just a piece of technology, and this cannot be led from a network or IT function; it’s a line of business. The improvement and value to the customers has to come first, and getting the mindset right is hard. We have proof points that you can make money, thanks to companies like Telestax, Tropo and Twilio, if you build a whole supply chain.

Finally, Alan Quayle has posted his independent review of Telecom API's which is embedded below:

Do you have an opinion on Telecom API's? Feel free to add it in the comments.

Multi-stream aggregation (MSA): Key technology for future networks

In our recent 5G presentation here, we outlined multi-technology carrier aggregation as one of the technologies for the future networks. Some of the discussions that I had on this topic later on highlighted the following:

1. This is generally referred to as Multi-stream aggregation (MSA)
2. We will see this much sooner than 5G, probably from LTE-A Rel-13 onwards 

Huawei have a few documents on this topic. One such document is embedded below and aanother more technical document is available on slideshare here.

MSA: A key technology for the evolution of future wireless networks from Zahid Ghadialy

Push to talk (PTT) via eMBMS

I was talking about push to share back in 2007 here. Now, in a recent presentation (embedded below) from ALU, eMBMS has been suggested as a a solution for PTT like services in case of Public safety case. Not sure if or when we will see this but I hope that its sooner rather than later. Anyway, the presentation is embedded below. Feel free to add your comments:

eMBMS for Public Safety from Zahid Ghadialy

#5G: Your Questions Answered

This is our view on what 5G is, please feel free to add your comments here or if you want a much wider audience to discuss your comments, please add them to the Cisco Communities here.

5G: Your Questions Answered from Cisco Service Provider Mobility

LTE for Utilities and Smart Grids

This has been an area of interest for the last couple of years. Discussions have been centred around, "Is LTE fit for IoT?", "Which technology for IoT", "Is it economical to use LTE for M2M?", "Would small cells be useful for M2M?", etc.

Ericsson has recently published a whitepaper titled "LTE for utilities - supporting smart grids". One of the table that caught my eye is as follows:

LTE would be ideally suited for some of the "Performance class" requirements where the transfer time requirements is less than 100ms. Again, it can always be debated if in many cases WiFi will meet the requirements so should WiFi be used instead of LTE, etc. I will let you form your own conclusions and if you are very passionate and have an opinion, feel free to leave comment.

The whitepaper is embedded below:

Related posts:

• Introduction to M2M and its developments in LTE
• From M2M Communications to IoT
• M2M Standardization and its Role for Emerging Smart Cities
• Everything you ever wanted to know about M2M

LTE TDD - universal solution for unpaired spectrum?

TDD deployments are gathering pace. An earlier GSA report I posted here, highlighted the many devices that are TD-LTE ready.

The main thing that is being emphasised is that from the standards point of view, not much additional efforts are required for a TDD device as compared to an FDD device. Of course in practice the physical layer would be different and that could be a challenge in itself.

Qualcomm published a presentation on this topic that is embedded below. Available to download from here.

Throughput Comparison for different wireless technologies

Merged various slides from the recent 4G Americas presentation to get a complete picture of data throughput speeds for various technologies.

VoLTE Bearers

While going through Anritsu whitepaper on VoLTE, I found this picture that explains the concepts of bearers in a VoLTE call well. From the whitepaper:

All networks and mobile devices are required to utilize a common access point name (APN) for VoLTE, namely, “IMS”. Unlike many legacy networks, LTE networks employ the “always-on” conception of packet connectivity: Devices have PDN connectivity virtually from the moment they perform their initial attach to the core network. During the initial attach procedure, some devices choose to name the access point through which they prefer to connect. However, mobile devices are not permitted to name the VoLTE APN during initial attach, i.e., to utilize the IMS as their main PDN, but rather to establish a connection with the IMS AP separately. Thus, VoLTE devices must support multiple simultaneous default EPS bearers.

Note that because the VoLTE APN is universal, mobile devices will always connect through the visited PLMN’s IMS PDN-GW. This architecture also implies the non-optionality of the P-CSCF:

As stated, VoLTE sessions employ two or three DRBs. This, in turn, implies the use of one default EPS bearer plus one or two dedicated EPS bearers. The default EPS bearer is always used for SIP signaling and exactly one dedicated EPS bearer is used for voice packets (regardless of the number of active voice media streams.) XCAP signaling may be transported on its own dedicated EPS bearer – for a total of three active EPS bearers – or it may be multiplexed with the SIP signaling on the default EPS bearer, in which case only two EPS bearers are utilized.

My understanding is that initially when the UE is switched on, a default bearer with QCI 9 (see old posts on QoS/QCI here) is established that would be used for all the signalling. Later on, another default bearer with QCI 5 is established with the IMS CN. When a VoLTE call is being setup, a dedicated bearer with QCI 1 is setup for the voice call. As the article says, another dedicated bearer may be needed for XCAP signalling. If a Video call on top of VoLTE is being used than an additional dedicated bearer with QCI 2 will be setup. Note that the voice pat will still be carried by dedicated bearer with QCI 1.

Do you disagree or have more insight, please feel free to add the comment at the end of the post.

The whitepaper is embedded below and is available to download from slideshare.

Related posts:

• Voice-Over-LTE (VoLTE) Signalling
• Voice over LTE – a step towards future telephony (Ericsson Whitepaper)
• SPS and TTI Bundling Example
• On LTE Roaming ...
• LTE QCI and End-to-end bearer QoS in EPC

New Mobile related terms added in Oxford dictionary

The Oxford dictionary has just added some new words in its dictionary. Here is a summary of the words related to mobiles.

BYOD: n.: abbreviation of 'bring your own device': the practice of allowing the employees of an organisation to use their own computers, smartphones, or other devices for work purposes. Wikipedia also calls it bring your own technology (BYOT), bring your own phone (BYOP), and bring your own PC (BYOPC).

digital detox, n.: a period of time during which a person refrains from using electronic devices such as smartphones or computers, regarded as an opportunity to reduce stress or focus on social interaction in the physical world.

Another term called "Nomophobia" which has unfortunately not yet entered the dictionary refers to as the fear of being out of mobile phone contact. The term, an abbreviation for "no-mobile-phone phobia". According to a recent survey some 54% of Brits have experienced this. If someone is getting affected by Nomophobia, its time they undergo a 'digital detox' to sort their life out.

emoji, n: a small digital image or icon used to express an idea or emotion in electronic communication.

Everyone using OTT applications would know them well. They are very useful in communicating emotions. I generally think this as one of the drawbacks of SMS that we cant use emoji's. On the other hand OTT apps can be making money by providing extended emoji's for a premium but I havent seen anyone do this yet.

FOMO, n.: fear of missing out: anxiety that an exciting or interesting event may currently be happening elsewhere, often aroused by posts seen on a social media website

'FOMO' is big and I personally know people who suffer from this. In the good old days this was known as jealousy where one would be jealous that someone was going on more holidays, have a bigger house/car, etc. In this connected world where we can get Facebook updates and notifications on the phones and tablets the digital term is FOMO. A slide from Mary Meeker's presentation that I put here shows that a typical user checks their phone 150 times every day and social media is not very far from the top.

internet of things, n.: a proposed development of the Internet in which everyday objects have network connectivity, allowing them to send and receive data.

This 'Internet of Things' or 'IoT' has been covered in the blog more than enough times.

phablet, n.: a smartphone having a screen which is intermediate in size between that of a typical smartphone and a tablet computer.

Earlier this year I put a post here that talked all about feature phones, smartphones, phablets, etc. Other terms like Tabphones and Phonetabs didn't make it.

selfie, n. (informal): a photograph that one has taken of oneself, typically one taken with a smartphone or webcam and uploaded to a social media website.

Here is a selfie of me using my phone today to end this post :-)

Centralized SON

I was going through the presentation by SKT that I blogged about here and came across this slide above. SKT is clearly promoting the benefits of their C-SON (centralized SON) here.

The old 4G Americas whitepaper (here) explained the differences between the three approaches; Centralized (C-SON), Distributed (D-SON) and Hybrid (H-SON). An extract from that paper here:

In a centralized architecture, SON algorithms for one or more use cases reside on the Element Management System (EMS) or a separate SON server that manages the eNB's. The output of the SON algorithms namely, the values of specific parameters, are then passed to the eNB's either on a periodic basis or when needed. A centralized approach allows for more manageable implementation of the SON algorithms. It allows for use case interactions between SON algorithms to be considered before modifying SON parameters. However, active updates to the use case parameters are delayed since KPIs and UE measurement information must be forwarded to a centralized location for processing. Filtered and condensed information are passed from the eNB to the centralized SON server to preserve the scalability of the solution in terms of the volume of information transported. Less information is available at the SON server compared to that which would be available at the eNB. Higher latency due to the time taken to collect UE information restricts the applicability of a purely centralized SON architecture to those algorithms that require slower response time. Furthermore, since the centralized SON server presents a single point of failure, an outage in the centralized server or backhaul could result in stale and outdated parameters being used at the eNB due to likely less frequent updates of SON parameters at the eNB compared to that is possible in a distributed solution.

In a distributed approach, SON algorithms reside within the eNB’s, thus allowing autonomous decision making at the eNB's based on UE measurements received on the eNB's and additional information from other eNB's being received via the X2 interface. A distributed architecture allows for ease of deployment in multi-vendor networks and optimization on faster time scales. Optimization could be done for different times of the day. However, due to the inability to ensure standard and identical implementation of algorithms in a multi-vendor network, careful monitoring of KPIs is needed to minimize potential network instabilities and ensure overall optimal operation.

In practical deployments, these architecture alternatives are not mutually exclusive and could coexist for different purposes, as is realized in a hybrid SON approach. In a hybrid approach, part of a given SON optimization algorithm are executed in the NMS while another part of the same SON algorithm could be executed in the eNB. For example, the values of the initial parameters could be done in a centralized server and updates and refinement to those parameters in response to the actual UE measurements could be done on the eNB's. Each implementation has its own advantages and disadvantages. The choice of centralized, distributed or hybrid architecture needs to be decided on a use-case by use case basis depending on the information availability, processing and speed of response requirements of that use case. In the case of a hybrid or centralized solution, a practical deployment would require specific partnership between the infrastructure vendor, the operator and possibly a third party tool company. Operators can choose the most suitable approach depending upon the current infrastructure deployment.

Finally, Celcite CMO recently recently gave an interview on this topic on Thinksmallcell here. An extract below:

SON software tunes and optimises mobile network performance by setting configuration parameters in cellsites (both large and small), such as the maximum RF power levels, neighbour lists and frequency allocation. In some cases, even the antenna tilt angles are updated to adjust the coverage of individual cells.

Centralised SON (C-SON) software co-ordinates all the small and macrocells, across multiple radio technologies and multiple vendors in a geographic region - autonomously updating parameters via closed loop algorithms. Changes can be as frequent as every 15 minutes– this is partly limited by the bottlenecks of how rapidly measurement data is reported by RAN equipment and also the capacity to handle large numbers of parameter changes. Different RAN vendor equipment is driven from the same SON software. A variety of data feeds from the live network are continuously monitored and used to update system performance, allowing it to adapt automatically to changes throughout the day including outages, population movement and changes in services being used.

Distributed SON (D-SON) software is autonomous within each small cell (or macrocell) determining for itself the RF power level, neighbour lists etc. based on signals it can detect itself (RF sniffing) or by communicating directly with other small cells.

LTE has many SON features already designed in from the outset, with the X.2 interface specifically used to co-ordinate between small and macrocell layers whereas 3G lacks SON standards and requires proprietary solutions.

C-SON software is available from a relatively small number of mostly independent software vendors, while D-SON is built-in to each small cell or macro node provided by the vendor. Both C-SON and D-SON will be needed if network operators are to roll out substantial numbers of small cells quickly and efficiently, especially when more tightly integrated into the network with residential femtocells.

Celcite is one of the handful of C-SON software solution vendors. Founded some 10 years ago, it has grown organically by 35% annually to 450 employees. With major customers in both North and South America, the company is expanding from 3G UMTS SON technology and is actively running trials with LTE C-SON.

Quite a few companies are claiming to be in the SON space, but Celcite would argue that there are perhaps only half a dozen with the capabilities for credible C-SON solutions today. Few companies can point to live deployments. As with most software systems, 90% of the issues arise when something goes wrong and it's those "corner cases" which take time to learn about and deal with from real-world deployment experience.

A major concern is termed "Runaway SON" where the system goes out of control and causes tremendous negative impact on the network. It's important to understand when to trigger SON command and when not to. This ability to orchestrate and issue configuration commands is critical for a safe, secure and effective solution.

Let me know your opinions via comments below.

How Cyber-Attacks Can Impact M2M Infrastructure

An Interesting presentation from Deutsche Telekom in the Network Security Conference which highlights some of the issues faced by the M2M infrastructure. With 500 Billion devices being predicted, security will have to be stepped up for the M2M infrastructures to work as expected. Complete presentation embedded below:

How Cyber-Attacks Can Impact M2M from Zahid Ghadialy

eIMTA: Enhanced Interference Mitigation & Traffic Adaptation

eIMTA is one of the features being discussed in 3GPP Rel-12. The pictures above and below provide the details.

As can be seen, at the moment all the eNodeB's associated with a network has to transmit the same UL/DL pattern throughout out the system. With eIMTA, each eNodeB can decide the UL/DL pattern itself depending on the load.

The main challenge would be interference management while using this scheme.

See also, this slideshare presentation for details:

White Paper: Dynamic TDD for LTE-a (eIMTA) and 5G from Eiko Seidel

Stress Testing of LTE devices

Another interesting presentation from R&S LTE Summit 2013 embedded below:

Stressing a LTE device with Typical User Behaviors from Zahid Ghadialy

C-RAN Architecture and Challenges

I have blogged about Cloud RAN or C-RAN in the Metrocells blog here and am looking forward to more discussions on this topic in the SON conference later this year.


I came across this interesting presentation from Orange in the LTE World Summit this year where the authors have detailed the C-RAN architecture and also discussing the fronthaul challenges faced by C-RAN. The presentation is embedded as follows. Please feel free to add your comments with your opinions.

C-RAN architecture and fronthaul challenges from Zahid Ghadialy

2 Factor and 3 Factor Authentication (2FA / 3FA)

Found an interesting slide showing 2 Factor Authentication in picture from a presentation in LTE World Summit

You can also read more about this and Multi-factor Authentication (MFA) on Wikipedia here.

M2M, Cellular and Small Cells

I have written a post on this topic in the Cisco Service Provide Mobility blog here. The article is embedded as follows:

Feel free to add any comments you may have on the blog post here.

Mobile Relay Nodes (MRN) in Rel-12

Interesting article in IEEE Comms Magazine (embedded below) about the Moving Relay Node (MRN). 3GPP has done a study on a similar topic available in 3GPP TR 36.836. To make the case for the MRN they provide a reference scenario of high speed train

The TGV Eurostar in Europe is 393 m long, moves at speed reaching 300 km/h. The Shinkansen in Japan has similar characteristics, with 480 m long, 300 km/h of commercial speed. The high speed train in China is 432 m long moving at speed reaching 350 km/h.

Due to fast moving and well shield carriage, the network in high speed train scenario faces severe Doppler frequency shift and high penetration loss, reduced handover success rate and increased power consumption of UEs.

To improve the coverage of the train deployment, access devices can be mounted on the high speed train, providing a wireless backhaul connection via the eNBs along the railway by outer antenna e.g. installed on top of the train, and wireless connectivity to the UEs inside carriages by inner antenna installed inside.

MRN is a good solution but when it has to operate alongside with many other technologies can pose challenges. The IEEE article summarises it as follows:

Furthermore, new challenges regarding interference management arise due to the use of MRNs. As the distance between an MRN and the vehicular UE served by it is very short, the MRN and the vehicular UE can communicate with each other using very low power. In addition, the VPL can further help to dampen the signal of the MRN access link that propagates out from the vehicle. Thus, compared to direct transmission, the use of MRNs generates less interference from the access link, for both downlink and uplink, to UE outside the vehicles. This is appreciated in a densely deployed urban scenario where link availabilities are usually dependent on interference rather than coverage. For the backhaul link, however, the problem becomes complicated, as interference is expected both between different MRN backhaul links, and between MRN backhaul links and macro UE. The use of predictor antennas can improve CSI accuracy to enable the use of advanced interference avoidance and cancellation schemes for the backhaul links. Nevertheless, whether enhancements on the current intercell interference coordination (ICIC) framework in LTE are needed to support the use of MRNs still requires further investigation.

I have been thinking of possible use of 8x8 MIMO, this can be one possible scenario where the network may use 8x8 or even 4x4. Anyway, the complete article is embedded below:

Making LTE fit for the IoT

Another presentation from the #FWIC2013. This presentation by Vodafone covers some of the areas where the LTE standards are being tweaked for making M2M work with them without issues.

Another area is the access barring that I have blogged about before here. This will become important when we have loads of devices trying to access the network at the same time.

The presentation is embedded below and you can also listen to the audio here.

Making LTE fit for the IoT - Vodafone from Zahid Ghadialy

Big Data and Vulnerability of Cellular Systems

I am sure most of you are aware of Big Data, if not watch this video on my old post here. Moray Rumney from Agilent recently gave a talk in #FWIC on how Big Data techniques can be used to exploit the vulnerabilities in a cellular system. Though the talk focussed on GSM and 3G, it is always a good intro. The presentation embedded below:

Collecting Big Data in an Increasingly Complex Mobile World from Zahid Ghadialy

You can also listen to the audio of his presentation here.

New RRC message in Rel-11: In-device coexistence indication

I have blogged about about IDC here and here. If the eNB is interested in knowing if the device is having an interference issue it can ask the UE to send this message in the RRC Conn Reconfiguration message. The UE would send the message if it has interference issues.

Inter-frequency handover is a good solution in case the UE is experiencing interference.

From the Rel-11 whitepaper posted last week here:

To assist the base station in selecting an appropriate solution, all necessary/available assistance information for both time and frequency domain solutions is sent together in the IDC indication. The IDC assistance information contains the list of carrier frequencies suffering from on-going interference and the direction of the interference. Additionally it may also contain time domain patterns or parameters to enable appropriate DRX configuration for time domain solutions on the serving LTE carrier frequency.

Note that the network is in the control of whether or not to activate this interference avoidance mechanism. The InDeviceCoexIndication message from the UE may only be sent if a measurement object for this frequency has been established. This is the case, when the RRCConnectionReconfiguration message from the eNB contains the information element idc-Config. The existence of this message declares that an InDeviceCoexIndication message may be sent. The IDC message indicates which frequencies of which technologies are interfered and gives assistance to possible time domain solutions. These comprise DRX assistance information and a list of IDC subframes, which indicate which HARQ processes E-UTRAN is requested to abstain from using. This information describes only proposals, it is completely up to the network to do the decisions.

Connectivity in 'Connected Vehicles'

An interesting presentation from the Future of Wireless International conference about the evolution and options for connected cars and other vehicles

Connected Vehicle - Accenture from Zahid Ghadialy

3GPP Rel.11 Technology Introduction whitepaper

Another excellent summary whitepaper by R&S, embedded below:

LTE- Advanced (3GPP Rel.11) Technology Introduction from Zahid Ghadialy

Nice way of showing HetNets, by Cisco #LTEWS

This is from a presentation by Akram Awad of Cisco in the LTE World Summit 2013 in Amsterdam. I really like the way HetNets are explained

Our World Without Mobile :-)

Decision Tree of Transmission Modes (TM) for LTE

4G Americas have recently published whitepaper titled "MIMO and Smart Antennas for Mobile Broadband Systems" (available here). The above picture and the following is from that whitepaper:

Figure 3 above shows the taxonomy of antenna configurations supported in Release-10 of the LTE standard (as described in 3GPP Technical Specification TS 36.211, 36.300). The LTE standard supports 1, 2, 4 or 8 base station transmit antennas and 2, 4 or 8 receive antennas in the User Equipment (UE), designated as: 1x2, 1x4, 1x8, 2x2, 2x4, 2x8, 4x2, 4x4, 4x8, and 8x2, 8x4, and 8x8 MIMO, where the first digit is the number of antennas per sector in the transmitter and the second number is the number of antennas in the receiver. The cases where the base station transmits from a single antenna or a single dedicated beam are shown in the left of the figure. The most commonly used MIMO Transmission Mode (TM4) is in the lower right corner, Closed Loop Spatial Multiplexing (CLSM), when multiple streams can be transmitted in a channel with rank 2 or more.

Beyond the single antenna or beamforming array cases diagrammed above, the LTE standard supports Multiple Input Multiple Output (MIMO) antenna configurations as shown on the right of Figure 3. This includes Single User (SU-MIMO) protocols using either open loop or closed loop modes as well as transmit diversity and Multi-User MIMO (MU-MIMO). In the closed loop MIMO mode, the terminals provide channel feedback to the eNodeB with Channel Quality Information (CQI), Rank Indications (RI) and Precoder Matrix Indications (PMI). These mechanisms enable channel state information at the transmitter which improves the peak data rates, and is the most commonly used scheme in current deployments. However, this scheme provides the best performance only when the channel information is accurate and when there is a rich multi-path environment. Thus, closed loop MIMO is most appropriate in low mobility environments such as with fixed terminals or at pedestrian speeds.

In the case of high vehicular speeds, Open Loop MIMO may be used, but because the channel state information is not timely, the PMI is not considered reliable and is typically not used. In TDD networks, the channel is reciprocal and thus the DL channel can be more accurately known based on the uplink transmissions from the terminal (the forward link’s multipath channel signature is the same as the reverse link’s – both paths use the same frequency block). Thus, MIMO improves TDD networks under wider channel conditions than in FDD networks.

One may visualize spatial multiplexing MIMO operation as subtracting the strongest received stream from the total received signal so that the next strongest signal can be decoded and then the next strongest, somewhat like a multi-user detection scheme. However, to solve these simultaneous equations for multiple unknowns, the MIMO algorithms must have relatively large Signal to Interference plus Noise ratios (SINR), say 15 dB or better. With many users active in a base station’s coverage area, and multiple base stations contributing interference to adjacent cells, the SINR is often in the realm of a few dB. This is particularly true for frequency reuse 1 systems, where only users very close to the cell site experience SINRs high enough to benefit from spatial multiplexing SU-MIMO. Consequently, SU-MIMO works to serve the single user (or few users) very well, and is primarily used to increase the peak data rates rather than the median data rate in a network operating at full capacity.

Angle of Arrival (AoA) beamforming schemes form beams which work well when the base station is clearly above the clutter and when the angular spread of the arrival is small, corresponding to users that are well localized in the field of view of the sector; in rural areas, for example. To form a beam, one uses co-polarized antenna elements spaced rather closely together, typically lamda/2, while the spatial diversity required of MIMO requires either cross-polarized antenna columns or columns that are relatively far apart. Path diversity will couple more when the antennas columns are farther apart, often about 10 wavelengths (1.5m or 5’ at 2 GHz). That is why most 2G and 3G tower sites have two receive antennas located at far ends of the sector’s platform, as seen in the photo to the right. The signals to be transmitted are multiplied by complex-valued precoding weights from standardized codebooks to form the antenna patterns with their beam-like main lobes and their nulls that can be directed toward sources of interference. The beamforming can be created, for example, by the UE PMI feedback pointing out the preferred precoder (fixed beam) to use when operating in the closed loop MIMO mode TM4.

For more details, see the whitepaper available here.

Related posts:

• LTE-A: Downlink Transmission Mode 9 (TM-9)
• R&S Whitepaper: LTE Transmission Modes and Beamforming

What's next with 802.11!

From another brilliant presentation by R&S from their LTE Summit 2013. Last year I had a similar overview from Agilent here. This one is much more detailed on what's coming next for WiFi.

802.11: a jet plane window’s view from Zahid Ghadialy

Introduction to M2M and its developments in LTE

LTE Innovation Summit 2013 - Anandamoy Sen from Rohde & Schwarz on Vimeo.

An interesting video on Introduction to M2M and its developments in LTE from Rohde&Schwarz LTE Innovation Summit 2013.

The presentation is also embedded below and can be downloaded from Slideshare.

Introduction to M2M by Sierra Wireless from Zahid Ghadialy

Present and Future Technologies for Internet of Things (IoT)

An Interesting presentation from our Future of Wireless Conference (#FWIC2013) in Cambridge earlier this month. A question being asked is what technology will be used for Internet of Things (IoT) or Internet of Everything (IoE) as its also referred to nowadays. These 3 slides below summarises what technologies are see applicable to which scenarios.

Complete slides are embedded below and if you like to see the video, its available here.

Mapping the Future of the Internet of (Every)Thing(s) from Zahid Ghadialy