Wednesday, May 28, 2014

Case Study: RAN Sharing in Poland


The last post on Network sharing by NEC was surprisingly popular so I thought its worth doing a case study by Orange in Poland on how they successfully managed to share their network with T-Mobile. Full presentation embedded as follows:


Wednesday, May 21, 2014

Connected and Autonomous Car Revolution

Last week we had the Automotive and Transport SIG event in Cambridge Wireless. There is already some good writeup on that event here and here. In this post my interest in looking at the technologies discussed.

R&S (who were the sponsors) gave their introduction presentation quite well highlighting the need and approaches for the connected car. He also introduced the IEEE 802.11p to the group.

As per Wikipedia, "IEEE 802.11p is an approved amendment to the IEEE 802.11 standard to add wireless access in vehicular environments (WAVE), a vehicular communication system. It defines enhancements to 802.11 (the basis of products marketed as Wi-Fi) required to support Intelligent Transportation Systems (ITS) applications. This includes data exchange between high-speed vehicles and between the vehicles and the roadside infrastructure in the licensed ITS band of 5.9 GHz (5.85-5.925 GHz). IEEE 1609 is a higher layer standard based on the IEEE 802.11p."

Back in December, Dr. Paul Martin did an equally useful presentation in the Mobile Broadband SIG and his presentation is equally relevant here as he introduced the different terms live V2X, V2i, V2V, V2P, etc. I have embedded his presentation below:



Roger Lanctot from Strategy Analytics, gave us some interesting facts and figures. Being based in the US, he was able to give us the view of both US as well as Europe. According to him, “LTE is the greatest source of change in value proposition and user experience for the customer and car maker. Bluetooth, Wi-Fi, NFC and satellite connectivity are all playing a role, but LTE deployment is the biggest wave sweeping the connected car, creating opportunities for new technologies and applications.” His officially released presentation is embedded below (which is much smaller than his presentation on that day.



There were also interesting presentations that I have not embedded but other may find useful. One was from Mike Short, VP of Telefonica and the other was from Dr. Ireri Ibarra of MIRA.


The final presentation by Martin Green of Visteon highlighted some interesting discussions regarding handovers that may be required when the vehicle (and the passengers inside) is moving between different access networks. I for one believe that this will not be an issue as there may be ways to work the priorities of access networks out. Anyway, his presentation included some useful nuggets and its embedded below:


Saturday, May 17, 2014

NFV and SDN - Evolution Themes and Timelines


We recently held our first Virtual Networks SIG event in Cambridge Wireless. There were some great presentations. The one by the UK operator EE summarised everything quite well. For those who are not familiar with what NFV and SDN is, I would recommend watching the video on my earlier post here.

One of the term that keeps being thrown around is 'Orchestration'. While I think I understand what it means, there is no easy way to explain it. Here are some things I found on the web that may explain it:
Orchestration means Automation, Provisioning, Coordination and Management of Physical and Virtual resources.  
Intelligent service orchestration primarily involves the principles of SDN whereby switches, routers and applications at Layer 7 can be programmed from a centralized component called the controller with intelligent decisions regarding individual flow routing in real time.
If you can provide a better definition, please do so.
There are quite a few functions and services that can be virtualised and there are some ambitious timelines.

ETSI has been working on NFV and as I recently found out (see tweet below) there may be some 3GPP standardisation activity starting soon.
Anyway, here is the complete presentation by EE:



There was another brilliant presentation by Huawei but the substance was more in the talk, rather than the slides. The slides are here in case you want to see and download.

Related post:



Monday, May 12, 2014

Improvement in Interference Rejection and Suppression Technology


In the last post where I talked about FeICIC I mentioned about the advanced Interference rejecting receivers, here is one very good article from NTT Docomo technical journal. The following is from this article:

Rel. 11 LTE has introduced MMSE-Interference Rejection Combining (MMSE-IRC) receivers as a mobile terminal interference rejection and suppression technology to mitigate the effects of these interference signals and increase user throughput even in areas that are recently experiencing high interference. Rel. 8 LTE receivers support MIMO transmission technology, so receivers were equipped with at least two antennas since it was first introduced. The MMSE-IRC receivers in Rel. 11 LTE, are able to use the multiple receiver antennas to create points, in the arrival direction of the interference signal, where the antenna gain drops (“nulls”) and use them to suppress the interference signal (Figure 1). The terminal orients a null toward the main interference signal, which is the signal that particularly affects the degradation of throughput, thereby improving the Signal-to-Interferenceplus-Noise power Ratio (SINR) and improving throughput performance.

However, with the original MIMO multiplexed transmission, which realized high throughput using multiple transmit and receiver antennas, the receiver antennas are used to separate the signals between layers, so interference from adjacent cells cannot be suppressed and throughput cannot be improved, particularly for mobile terminals with two receiver antennas.

On the other hand, the 3GPP has already included interference rejection and suppression technology in performance specifications for mobile terminals equipped with W-CDMA/High-Speed Downlink Packet Access (HSDPA) in Rel. 7 of the Universal Mobile Telecommunications System (UMTS). With W-CDMA, receivers normally use one receiver antenna and perform Rake reception, but the effects of multipath interference degrading reception performance was an issue.

Thus, the following three receiver extensions were studied and introduced.
• Type 1/1i extends the Rake receiver to use two antennas.
• Type 2/2i extends the Rake receiver to an MMSE receiver that suppresses multipath and adjacent-cell interference.
• Type 3/3i extends the MMSE interference-suppressing receiver defined in Type 2/2i to use two receiver antennas.

The functional extensions in receivers in Rel.7 UMTS and Rel. 11 LTE are summarized in Table 1. The MMSE-IRC receivers in Rel. 11 LTE incorporate receiver algorithms that are generally equivalent to those in the Type 3/3i receivers introduced in WCDMA/HSDPA. However, in the WCDMA/HSDPA receivers they also operate to suppress inter-coding interference within a cell. There is no interference within a cell in LTE systems, so in the MMSE-IRC receivers introduced in Rel. 11 LTE, they operate to suppress interference arriving from adjacent cells.

From my understanding, a similar approach is being proposed for the Mobile Relay Node (MRN)

Anyway, the complete article is as follows:


Monday, May 5, 2014

WebRTC (Web Real-Time Communication) Updates

Its been a while since I last blogged about WebRTC. Things have been progressing as rather fast pace in this area.



WebRTC capabilities have quietly sneaked in our browsers. There is a debate about who would move to WebRTC before, Apple or Microssoft; Tsahi Levent-Levi makes his predictions here.



As per Light Reading, Japanese operator NTT has opened a WebRTC based chatroom recently.



The Korean operator SK Telecom as been showing off its WebRTC interworking with IMS platform.



The problem with WebRTC can be as seen in the slide above. Classic problem of what was promised and whats the reality.

There are 2 interesting presentations that I am embedding below that I found useful:






Additional Reading:


Thursday, May 1, 2014

Further enhanced Inter-Cell Interference Coordination (FeICIC)


Recently while delivering a training, I realised that this is a topic that I haven't covered in the blog before, even though I have been talking about it for a while. FeICIC has been introduced in Release-11 and there are a few enhancements as shown above. The main being that instead of an Almost Blank Subframe (ABS) with no other information except for the reference signals, now there is a possibility of reduced power ABS where the data on PDSCH can still be transmitted but on a reduced power level. This would ensure that the capacity of the interferer is not wasted.


Another enhancement on which FeICIC depends on are the advanced receivers (should do a post on it sometime soon). Another feature that allows a better probability of reception is the Transmission Mode 9 (TM9 - see blog post here)

An interesting comment that I received on my Deployments Dilemma Post is also relevant to the discussion here:

The ground reality is generally a lot different than theory. Metrocells often face interference not just from Macrocells but also other Metrocells. The ABS patterns are not just straightforward Macro to pico case but even pico to pico and multiple macros to pico.
Until all the handsets and other dongles could be upgraded with advanced interference cancellation receivers, there would be many scenarios where deployment option 2 may be chaotic. Deployment option 1 can serve the users well in the meantime. 
We can sacrifice efficiency for reliability in the meantime.

I recently posted the Small Cells Research Bible on the Small Cells blog here, the following is the Interference Management part that would help anyone willing to learn more about this feature.


Saturday, April 26, 2014

LTE Deployment Dilemma


Earlier this month during our Cambridge Wireless Small Cells SIG event, I presented a small quiz in the final session. The first part of the quiz was titled "LTE Deployment Dilemma" and it generated lots of interesting discussions. After the event, I did a more detailed writeup of that and Cisco has kindly published it in their SP Mobility Blog. Since many people have told me that they cannot anonymously post comments there, I am now bringing it to this blog. I am interested in hearing what others think.

Here is the complete post

Wednesday, April 23, 2014

Different flavours of Bluetooth: 4.0, 4.1, Low Energy, Smart, Smart Ready...

Once upon a time, Nokia proposed a standard called Wibree. That standard was good enough to be merged with Bluetooth SIG and then become part of Bluetooth Low Energy (Bluetooth LE or BLE) standards.


The Bluetooth Low Energy standards comes in two different flavours, 'Smart' and 'Smart Ready'
The Smart and Smart Ready were introduced in 2011 to explain which devices will be compatible to what. Here is a table which explains how interoperability would work.


One of the obvious use of Bluetooth Low Energy is in Beacons. Here is an excellent presentation on Bluetooth 4.0:



Bluetooth 4.1 brings new capabilities in Bluetooth for it to become a challenger for Internet of Things (IoT). Here is an extract from an article in Network Computing:

With 4.1, the Bluetooth SIG is aiming to become a major player in the much-hyped Internet of Things (IOT) market. While 4.0 steps on Wi-Fi’s turf for location-based interaction with client devices, Bluetooth 4.1 looks to leverage Bluetooth's broad name recognition, widespread acceptance, and new low-power capabilities to compete with technologies that also want in on the IOT. These include ZigBee and Near Field Communication, both which are arguably niche technologies that just aren't familiar to many people.

As IoT looms larger for environments of all sizes, Bluetooth 4.1 allows client devices to daisy-chain to each other and multiple devices simultaneously for larger networks that are more Zigbee-like. Perhaps the biggest change for those of us who have to guide our network environments into the future: Bluetooth’s latest version lays the groundwork for dedicated device channels and the use of IPv6 for smart sensors to bridge themselves out of the isolated PAN world and into the IOT. This represents a major and substantial change to the Bluetooth mission, and will absolutely impact the Zigbee market in some substantial way.

Other features with Bluetooth 4.1 make it generally better in its PAN role. Bluetooth has been improved to ensure that nearby LTE radios (frequently under the same device hood) are not interfered with. It has a longer allowable interval between service advertisements, for better battery life and less chatter in the busy 2. GHz band. One of the big gains with 4.1 is the Bulk Transfer feature. For example, the feature would allow my fitness gizmo to auto-transfer all the data it's recorded of my gym activities when I get within range of my cell phone to update the app that tracks my activities.

An FAQ from the Bluetooth SIG on 4.1 is embedded below:


Friday, April 18, 2014

International LTE Data and VoLTE Roaming - NTT Docomo


Quick recap of the Bearer Architecture: Remember the interface between S-GW and P-GW is known as S5/S8. S5 in case the S-GW and P-GW are part of the same network (non-roaming case) and S8 in case where P-GW belongs to another network than S-GW (roaming case). The S5/S8 interfaces are generally exactly the same. There is a possibility of different types of S5/S8 interfaces like GTP based and PMIP based but lets not discuss that here.

NTT Docomo published an excellent article in their magazine recently showing the different approaches to International Data roaming.


The different scenarios above are based on the guidelines provided in GSMA PRD IR.88. Each operator has to adopt one of the scenarios above, NTT Docomo has selected scenario 4. The Home PLMN (HPLMN) and the Visited PLMN (VPLMN) connect via IP eXchange (IPX).


As can be seen above, the MME in VPLMN communicates with HSS in HPLMN using Diameter Edge Agent (DEA).



Finally, it is well known that NTT Docomo is not launching VoLTE untill 2015. The above is their proposal on how they handle VoLTE while in Japan and when roaming.

The paper is an interesting read, embedded below:



Another article worth a read is the VoLTE roaming with RAVEL here.

Thursday, April 10, 2014

LTE-Broadcast of the operator, by the operator, for the operator!

Heard an insightful talk from EE in the CW event this week. While I agree with the intentions and approaches, I still think there may be too many assumptions in the eMBMS business model. I have made my intentions known all but too well in my earlier blog post here.

Some of the insights that I have gained in the last couple of months with regards to the way operators are planning to use the LTE broadcast is through the OTT Apps. Take for instance an OTT application like iPlayer or Hulu and some popular program is about to be broadcast, that program can be sent using LTE-B. Now some people may watch on the time (linear) and some may watch at a later time (non-linear or time-shifted). The App can be intelligent enough to buffer the program so there is no delay required when the user wants to watch it. This can open all sorts of issues like the user may have watched one episode on his device while the current one is being watched on his digital television. While the program is being buffered the battery and memory of the device is being consumed. How long should a program be stored on the device. There can be many other open issues.

Another question I had was how would the users be billed for these things. Would it be free since the data was received over LTE-B. Matt Stagg from EE said that the users would be billed normally as if they received it in case of streaming. He was more pragmatic though. He clearly said that in the initial phase everything would have to be free. This will ensure that any technical issues are ironed out and at the same time the users become familiar with how all this works.

Finally a point worth remembering, users prefer watching videos on their tablets. Most tablets are WiFi only which means the LTE-Broadcast wont work on it.

The presentation is embedded as follows: