Quick summary of Mobile World Congress 2018 (#MWC18)

This year at MWC, I took the time out to go and see as many companies as I can. My main focus was looking at connectivity solutions, infrastructure, devices, gadgets and anything else cool. I have to say that I wasn't too impressed. I found some of the things later on Twitter or YouTube but as it happens, one cannot see everything.

I have to be honest, haven't seen a WOW demo yet at #MWC18. While there are lots of interesting stuff, it's all the same, old and tired stuff.

— Zahid Ghadialy (@zahidtg) February 26, 2018

I will be writing a blog on Small Cells, Infrastructure, etc. later on but here are some cool videos that I have found. As its a playlist, if I find any more, it will be added to the same playlist below.



The big vendors did not open up their stands for everyone (even I couldn't get in 😉) but the good news is that most of their demos is available online. Below are the name of the companies that had official MWC 2018 websites. Will add more when I find them.

Operators

• NTT Group
• Telefonica
• Orange
• Verizon
• Deutsche Telekom

Network Equipment Vendors

• Huawei 
• Nokia
• Ericsson
• ZTE
• Samsung

Handset Manufacturers

• LG
• Huawei (see above)
• Samsung

Chipset Manufacturers

• Qualcomm
• Intel
• MediaTek

Did I miss anyone? Feel free to suggest links in comments.


MWC Summary from other Analysts:

• Mobile World Congress 2018 Event Report - ThinkSmallCell
• Mobile World Congress 2018: trends, news, announcements - Radio Electronics
• Observations from MWC 2018 - Frank Rayal
• Mobile World Congress: State of the Industry 2018 - Xona Partners
• Mobile World Congress 2018 Report: Day 1, Day 2, Day 3, Day 4 - CCS Insight
• MWC 2018 Roundup - Counterpoint Research

5G Dual Connectivity, Webinar and Architecture Overview

One of the things that will come as a result of NSA (Non-StandAlone) architecture will be the option for Dual Connectivity (DC). In fact, DC was first introduced in LTE as part of 3GPP Release 12 (see 3G4G Small Cells blog entry here). WWRF (Wireless World Research Forum) has a good whitepaper on this topic here and NTT Docomo also has an excellent article on this here.

A simple way to understand the difference between Carrier Aggregation (CA) and Dual Connectivity (DC) is that in CA different carriers are served by the same backhaul (same eNB), while in DC they are served by different backhauls (different eNB or eNB & gNB).


We have produced a short video showing different 5G architectures, looking mainly at StandAlone (SA) and Non-StandAlone (NSA) architectures, both LTE-Assisted and NR-Assisted. The video is embedded below:

Finally, 3GPP has done a short webinar with the 3GPP RAN Chairman Balazs Bertenyi explaining the outcomes from RAN#77. Its available on BrightTalk here. If you are interested in the slides, they are available here.

Related posts:

• 5G Core Network, System Architecture & Registration Procedure
• 5G: Architecture, QoS, gNB, Specifications - April 2017 Update
• 5G Security Updates - July 2017
• Enhanced 5G Security via IMSI Encryption
• 5G – Beyond the Hype
• Network Sharing is becoming more relevant with 5G

Research on Unvoiced Speech Communications using Smartphones and Mobiles

A startup on kickstarter is touting world's first voice mask for smartphones. Having said that Hushme has been compared to Bane from Batman and Dr. Hannibal Lecter. Good detail of Hushme at Engadget here.

This is an interesting concept and has come back in the news after a long gap. Even though we are well past the point of 'Peak Telephony' because we now use text messages and OTT apps for non-urgent communications. Voice will always be around though for not only urgent communications but for things like audio/video conference calls.

Back in 2003 NTT Docomo generated a lot of news on this topic. Their research paper "Unvoiced speech recognition using EMG - mime speech recognition" was the first step in trying to find a way to speak silently while the other party can hear voice. This is probably the most quoted paper on this topic. (picture source).

NASA was working on this area around the same time. They referred to this approach as 'Subvocal Speech'. While the original intention of this approach was for astronauts suits, the intention was that it could also be available for other commercial use. Also, NASA was effectively working on limited number of words using this approach (picture source).

For both the approaches above, there isn't a lot of recent updated information. While it has been easy to recognize certain characters, it takes a lot of effort to do the whole speech. Its also a challenge to play your voice rather than a robotic voice to the other party.

To give a comparison of how big a challenge this is, look at the Youtube videos where they do an automatic captions generation. Even though you can understand what the person is speaking, its always a challenge for the machine. You can read more about the challenge here.

A lot of research in similar areas has been done is France and is available here.

Motorola has gone a step further and patented an e-Tattoo that can be emblazoned over your vocal cords to intercept subtle voice commands — perhaps even subvocal commands, or even the fully internal whisperings that fail to pluck the vocal cords when not given full cerebral approval. One might even conclude that they are not just patenting device communications from a patch of smartskin, but communications from your soul. Read more here.

Another term used for research has been 'lip reading'. While the initial approaches to lip reading was the same as other approaches of attaching sensors to facial muscles (see here), the newer approaches are looking at exploiting smartphone camera for this.

Many researchers have achieved reasonable success using cameras for lip reading (see here and here) but researchers from Google’s AI division DeepMind and the University of Oxford have used artificial intelligence to create the most accurate lip-reading software ever.

Now the challenge with smartphones for using camera for speech recognition will be high speed data connectivity and ability to see lip movement clearly. While in indoor environment this can be solved with Wi-Fi connectivity and looking at the camera, it may be a bit tricky outdoors or not looking at the camera while driving. Who knows, this may be a killer use-case for 5G.

By the way, this is not complete research in this area. If you have additional info, please help others by adding it in the comments section.

Related links:

• Silent speech interface
• Japan: Phoning home may soon be at your fingertips as Japanese researchers develop phone which transmits sound through the hand
• Video: NASA Subvocal Speech Recognition
• Motorola patents e-tattoo that can read your thoughts by listening to unvocalized words in your throat
• Silent Communication: whispered speech-to-clear speech conversion
• Google’s AI can now lip read better than humans after watching thousands of hours of TV

Dedicated Core Networks (DCN) for different traffic types

Looking at a paper (embedded below) from NTT Docomo technical journal where they talk about Dedicated Core Network (DCN) for handling different traffic type (M2M/IoT for example). Note that this approach is different from NFV based network sliced architecture. For the latter, the network functions should have been virtualized.

There will be some signalling overhead in the core network to handle the new core and reroute the traffic according destined for the new dedicated core. I would still hope that this would be minuscule in the grand scheme of things. Anyway, let me know what you think about the paper below.

NTT Docomo's 5G Treasure Trove

NTT Docomo's recent technical journal has quite a few interesting 5G articles. While it is well known that 5G will be present in Japan in some or the other shape by 2020, for the summer Olympics, NTT Docomo started studying technologies for 5G in 2010. Some of these have probably ended in 4.5G, a.k.a. LTE-Advanced Pro.

While there are some interesting applications and services envisioned for 5G, I still think some of these can be met with LTE-A and some of them may not work with the initial versions of 5G

As far as 5G timetable is concerned, I recently posted a blog post on this topic here. Initial versions of 5G will have either little or no millimetre wave (mmWave) bands. This is because most of these would be finalised in 2019 after WRC-19 has concluded. It may be a touch challenge to move all the existing incumbents out of these bands or agree of a proper sharing mechanism.

'5G+' or '5G phase 3' will make extensive use of these higher frequency bands extensively in addition to the low and mid frequency bands. For anyone not familiar with different 5G phases, please see this earlier post here.

Enhanced LTE (or eLTE) is probably the same as LTE-Advanced Pro. Docomo believes that the initial 5G deployment would include new RAT but existing 4G core network which would be enhanced later for 5G+. Some of this new RAT technologies are discussed as well.

Core Network evolution is another interesting area. We looked at a possible architecture evolution here. To quote from the magazine:

The vision for future networks is shown in Figure 3. A future network will incorporate multiple radio technologies including LTE/LTE-Advanced, 5G New Radio Access Technology (RAT), and Wi-Fi, and be able to use them according to the characteristics of each service.

Utilizing virtualization technologies, network slices optimized for service requirements such as high efficiency or low delay can be created. Common physical devices such as general-purpose servers and Software Defined Network (SDN) transport switches will be used, and these networks will be provided to service providers. Network slices can be used either on a one service per network basis to increase network independence for originality or security, or with multiple services on one slice to increase statistical multiplexing gain and provide services more economically.

The specific functional architecture and the network topology for each network slice are issues to be studied in the future, but in the case of a network slice accommodating low latency services, for example, GateWay (GW) functions would need to be relatively close to radio access, service processing would be close to terminals, and routing control capable of finding the shortest route between terminals would be necessary to reduce latency. On the other hand, a network slice providing low volume communications to large numbers of terminals, such as with smart meters, would need functionality able to transmit that sort of data efficiently, and such terminals are fixed, so the mobility function can be omitted. In this way, by providing network slices optimized according to the requirements of each service, requirements can be satisfied while still reducing operating costs.

The magazine is embedded below and available to download from here:

See Also:

• IET Lecture: 5G – Getting Closer to Answers?
• Possible 5G Network Architecture Evolution
• 5G and Evolution of the Inter-connected Network
• 5G, NFV and Network Slicing
• 'Mobile Edge Computing' (MEC) or 'Fog Computing' (fogging) and 5G & IoT

Quick Summary of LTE Voice Summit 2015 (#LTEVoice)

Last year's summary of the LTE voice summit was very much appreciated so I have created one this year too.

The status of VoLTE can be very well summarised as can be seen in the image above.

‘VoLTE network deployment is the one of the most difficult project ever, the implementation complexity and workload is unparalleled in history’ - China Mobile group vice-president Mr.Liu Aili

Surprisingly, not many presentations were shared so I have gone back to the tweets and the pictures I took to compile this report. You may want to download the PDF from slideshare to be able to see the links. Hope you find it useful.

Related links:

• VoLTE Roaming with RAVEL (Roaming Architecture for Voice over IMS with Local Breakout)
• S8HR: Standardization of New VoLTE Roaming Architecture
• VoLTE Roaming: LBO, S8HR or HBO

VoLTE Roaming: LBO, S8HR or HBO

There was an interesting discussion on different roaming scenarios in the LTE Voice Summit on 29th, 30th Sep. in London. The above picture provides a brief summary of these well known options. I have blogged about LBO/RAVEL here and S8HR here. A presentation by NTT Docomo in a GSMA webinar here provides more details on these architectures (slide 29 onwards - though it is more biased towards S8HR).

Ajay Joseph, CTO, iBasis gave an interesting presentation that highlighted the problems present in both these approaches.

In case of LBO, the biggest issue is that the home operator need to do a testing with each roaming partner to make sure VoLTE roaming works smoothly. This will be time consuming and expensive.

In case of S8HR, he provided a very good example. Imagine a VoLTE subscriber from USA is visiting Singapore. He now needs to make a phone call to someone in Indonesia (which is just next to Singapore). The flow of data would be all the way from Singapore to USA to Indonesia and back. This can introduce delays and impact QoE. The obvious advantage of S8HR is that since the call setup and media go to Home PMN (Public Mobile Network), no additional testing with the Visited PMN is required. The testing time is small and rollouts are quicker.

iBasis are proposing a solution called Hub Breakout (HBO) which would offer the best of LBO and S8HR. Each VoLTE operator would need to test their interoperability only with iBasis. Emergency calls and lawful intercept that does not work with S8HR would work with the HBO solution.

While I agree that this is a good solution, I am sure that many operators would not use this solution and there may be other solutions proposed in due course as well. Reminds me of this XKCD cartoon:

Anyway, here is the iBasis presentation:

S8HR: Standardization of New VoLTE Roaming Architecture

VoLTE is a very popular topic on this blog. A basic VoLTE document from Anritsu has over 40K views and my summary from last years LTE Voice summit has over 30K views. I assume this is not just due to the complexity of this feature.

When I attended the LTE Voice summit last year, of the many solutions being proposed for roaming, 'Roaming Architecture for Voice over LTE with Local Breakout (RAVEL)' was being touted as the preferred solution, even though many vendors had reservations.

Since then, GSMA has endorsed a new VoLTE roaming architecture, S8HR, as a candidate for VoLTE roaming. Unlike previous architectures, S8HR does not require the deployment of an IMS platform in VPLMN. This is advantageous because it shortens time-to-market and provides services universally without having to depend on the capability of VPLMN.



Telecom Italia has a nice quick summary, reproduced below:

S8HR simplicity, however, is not only its strength but also its weakness, as it is the source of some serious technical issues that will have to be solved. The analysis of these issues is on the Rel13 3GPP agenda for the next months, but may overflow to Rel14. Let’s see what these issues are, more in detail:

Regulatory requirements - S8HR roaming architecture needs to meet all the current regulatory requirements applicable to voice roaming, specifically:

• Support of emergency calls - The issues in this context are several. For example, authenticated emergency calls rely on the existence if an IMS NNI between VPLMN and HPLMN (which S8HR does not provide); conversely, the unauthenticated emergency calls, although technically feasible in S8HR, are allowed only in some Countries subject to the local regulation of VPLMN. Also, for a non-UE-detectable IMS Emergency call, the P-CSCF in the HPLMN needs to be capable of deciding the subsequent action (e.g. translate the dialed number and progress the call or reject it with the indication to set up an emergency call instead), taking the VPLMN ID into account. A configuration of local emergency numbers per Mobile Country Code on P-CSCF may thus be needed.
• ­Support of Lawful Interception (LI) & data retention for inbound roamers in VPLMN -  S8HR offers no solution to the case where interception is required in the VPLMN for inbound roamers. 3GPP is required to define a solution that fulfill such vital regulatory requirement, as done today in circuit switched networks. Of course VPLMN and HPLMN can agree in their bilateral roaming agreement to disable confidentiality protection to support inbound roamer LI but is this practice really viable from a regulatory point of view?

Voice call continuity – The issue is that when the inbound roamers lose the LTE coverage to enter into  a 2G/3G CS area, the Single Radio Voice Call Continuity (SRVCC) should be performed involving the HPLMN in a totally different way than current specification (i.e. without any IMS NNI being deployed).
Coexistence of LBO and S8HR roaming architectures will have to be studied since an operator may need to support both LBO and S8HR VoLTE roaming architecture options for roaming with different operators, on the basis of bilateral agreement and depending on the capability.
Other issues relate to the capability of the home based S-CSCF and TAS (Telephony Application Server) to be made aware about the VPLMN identity for charging purposes and to enable the TAS to subsequently perform communication barring supplementary services. Also, where the roaming user calls a geo-local number (e.g. short code, or premium numbers), the IMS entities in HPLMN must do number resolution to correctly route the call.
From preliminary discussions held at Working Group level in SA2 (architecture) and SA3 (security) in April, it was felt useful to create a new 3GPP Technical Report to perform comprehensive technical analysis on the subject. Thus it is expected that the discussions will continue in the next months until the end of 2015 and will overheat Release 13 agenda due to their commercial and “political” nature. Stay tuned to monitor the progress of the subject or contact the authors for further information!

NTT Docomo also did some trials back in February and got some brilliant results:

In the trials, DOCOMO and KT achieved the world's first high-definition voice and video call with full end-to-end quality of service. Also, DOCOMO and Verizon achieved the world's first transoceanic high-definition VoLTE roaming calls. DOCOMO has existing commercial 3G and 4G roaming relations with Verizon Wireless and KT.

The calls were made on an IP eXchange (IPX) and network equipment to replicate commercial networks. With only two months of preparation, which also proved the technology's feasibility of speedy commercialization, the quality of VoLTE roaming calls using S8HR architecture over both short and long distances was proven to be better than that of existing 3G voice roaming services.

In fact, NTT Docomo has already said based on the survery from GSMA's Network 2020 programme that 80% of the network operators want this to be supported by the standards and 46% of the operators already have a plan to support this.

The architecture has the following technical characteristics:
(1) Bearers for IMS services are established on the S8 reference point, just as LTE data roaming.
(2) All IMS nodes are located at Home Public Land Mobile Network (HPLMN), and all signaling and media traffic for the VoLTE roaming service go through HPLMN.
(3) IMS transactions are performed directly between the terminal and P-CSCF at HPLMN. Accordingly, Visited Public Land Mobile Network (VPLMN) and interconnect networks (IPX/GRX) are not service-aware at the IMS level. The services can only be differentiated by APN or QoS levels.

These three technical features make it possible to provide all IMS services by HPLMN only and to minimize functional addition to VPLMN. As a result, S8HR shortens the time-to-market for VoLTE roaming services.

Figure 2 shows the attach procedure for S8HR VoLTE roaming. From Steps 1 to 3, there is no significant difference from the LTE data roaming attach procedure. In Step 4, HSS sends an update location answer message to MME. In order for the MME to select the PGW in HPLMN (Step 5), the MME must set the information element VPLMN Dynamic Address “Allowed,” which is included in the subscribed data, to “Not Allowed.” In Step 6, the bearer for SIP signaling is created between SGW and PGW with QCI=5. MME sends an attach accept message to the terminal with an IMS Voice over PS Session Support Indication information element, which indicates that VoLTE is supported. The information element is set on the basis of the MME’s internal configuration specifying whether there is a VoLTE roaming agreement to use S8HR. If no agreement exists between two PLMNs, the information element will not be set.

The complete article from the NTT Docomo technical journal is embedded

Enhancing voice services using VoLTE

VoLTE has been a very popular topic on this blog. My overview of the LTE Voice Summit missed out narrowly from the Top 10 posts of 2014 but there were other posts related to VoLTE that made it.

In this magazine article, NTT Docomo not only talks about its own architecture and transition from 3G to 4G for voice and video, it provides some detailed insights from its own experience.

There is also discussion into technical details of the feature and examples of signalling for VoLTE registration and originating/terminating calls (control, session and user plane establishment), SMS, SRVCC, Video over LTE (ViLTE) and voice to video call switching.

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

VoLTE for Enhancing Voice Services from Zahid Ghadialy

Related links:

• DOCOMO VoLTE and Next Steps
• VoLTE Roaming with RAVEL (Roaming Architecture for Voice over IMS with Local Breakout)
• 2015 will finally be the year of Voice over LTE (VoLTE)

M2M embedded UICC (eSIM) Architecture and Use Cases

Machine-to-Machine UICC, also known as M2M Form Factor (MFF) and is often referred to as embedded SIM (eSIM) is a necessity for the low data rate M2M devices that are generally small, single contained unit that is also sealed. The intention is that once this M2M device is deployed, then there is no need to remove the UICC from it. There may be a necessity to change the operator for some or the other reason. This gives rise to the need of multi-operator UICC (SIM) cards.

The GSMA has Embedded SIM specifications available for anyone interested in implementing this. There are various documents available on the GSMA page for those interested in this topic further.

While the complete article is embedded below, here is an extract of the basic working from the document:

A eUICC is a SIM card with a Remote Provisioning function, and is designed not to be removed or changed. It is able to store multiple communication profiles, one of which is enabled (recognized by the device and used for communication). The network of the MNO in the enabled profile is used for communication. Profiles other than the enabled profile are disabled (not recognized by the device). With conventional SIM cards, the ICCID is used as the unique key to identify the SIM card, but with eUICC, the ICCID is the key used to identify profiles, and a new ID is defined, called the eUICCID, which is used as the unique key for the eSIM

GSMA defines two main types of profile.
1) Provisioning Profile: This is the communication profile initially stored in the eUICC when it is shipped. It is a limited-application communication profile used only for downloading and switching Operational Profiles, described next.
2) Operational Profile: This is a communication profile for connecting to enterprise servers or the Internet. It can also perform the roles provided by a Provisioning profile

An eSIM does not perform profile switching as a simple IC card function, but rather switches profiles based on instructions from equipment called a Subscription Manager. A Subscription Manager is maintained and managed by an MNO. The overall eSIM architecture, centering on the Subscription Manager, is shown in Figure 3, using the example of switching profiles within the eUICC.

An eUICC must have at least one profile stored in it to enable OTA functionality, and one of the stored profiles must be enabled. The enabled profile uses the network of MNO A for communication. When the user switches profiles, a switch instruction is sent to the Subscription Manager. At that time, if the profile to switch to is not stored in the eUICC, the profile is first downloaded. When it receives a switch instruction, the eUICC performs a switch of the enabled profile as an internal process.

After the switch is completed, it uses the network of MNO B to send notification that the switch has completed to the Subscription Manager, completing the process. The same procedure is used to switch back to the original MNO A, or to some other MNO C.

Anyway, here is the complete paper on NTT Docomo website.

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:

Improved Interference Rejection and Suppression Technology in LTE Release 11 Specifications from Zahid Ghadialy

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:

• Alan Quayle: IMS and WebRTC Workshop
• Disruptive Analysis WebRTC Market Status & Forecast Update - March 2014
• Snapchat made a secret acquisition to power its new video chat - Verge

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:

NTT Docomo: Implementing LTE International Data Roaming from Zahid Ghadialy

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

VoLTE Roaming with RAVEL (Roaming Architecture for Voice over IMS with Local Breakout)

Voice over LTE or VoLTE has many problems to solve. One of the issues that did not have a clear solution initially was Roaming. iBasis has a whitepaper on this topic here, from which the above picture is taken. The following is what is said above:

The routing of international calls has always been a problem for mobile operators. All too often the answer—particularly in the case of ‘tromboning’ calls all the way back to the home network—has been inelegant and costly. LTE data sessions can be broken out locally, negating the need for convoluted routing solutions. But in a VoIMS environment all of the intelligence that decides how to route the call resides in the home network, meaning that the call still has to be routed back.

The industry’s solution to this issue is Roaming Architecture for Voice over LTE with Local Breakout (RAVEL). Currently in the midst of standardisation at 3GPP, RAVEL is intended to enable the home network to decide, where appropriate, for the VoIMS call to be broken out locally. 

Three quarters of respondents to the survey said they support an industry-wide move to RAVEL for VoLTE roaming. This is emphatic in its enthusiasm but 25 per cent remains a significant share of respondents still to be convinced. Just over half of respondents said they plan to support VoIMS for LTE roaming using the RAVEL architecture, while 12.3 per cent said they would support it, but not using RAVEL.

Until RAVEL is available, 27.4 per cent of respondents said they plan to use home-routing for all VoLTE traffic, while just under one fifth said they would use a non-standard VoLTE roaming solution.

Well, the solution was standardised in 3GPP Release-11. NTT Docomo has an excellent whitepaper (embedded below) explaining the issue and the proposed solution.

In 3GPP Release 11, the VoLTE roaming and interconnection architecture was standardized in cooperation with the GSMA Association. The new architecture is able to implement voice call charging in the same way as circuit-switched voice roaming and interconnection models by routing both C-Plane messages and voice data on the same path. This was not possible with the earlier VoLTE roaming and interconnection architecture.

Anyway, here is the complete whitepaper

NTT Docomo: VoLTE Roaming and Interconnection Standard Technology from Zahid Ghadialy

Different flavours of SRVCC (Single Radio Voice Call Continuity)

Single Radio Voice Call Continuity (SRVCC) has been quietly evolving with the different 3GPP releases. Here is a quick summary of these different flavors

In its simplest form, SRVCC comes into picture when an IMS based VoLTE call is handed over to the existing 2G/3G network as a normal CS call. SRVCC is particularly important when LTE is rolled out in small islands and the operator decided to provide VoLTE based call when in LTE. An alternative (used widely in practice) is to use CS Fallback (CSFB) as the voice option until LTE is rolled out in a wider area. The main problem with CSFB is that the data rates would drop to the 2G/3G rates when the UE falls back to the 2G/3G network during the voice call.

The book "LTE-Advanced: A Practical Systems Approach to Understanding 3GPP LTE Releases 10 and 11 Radio Access Technologies" by Sassan Ahmadi has some detailed information on SRVCC, the following is an edited version from the book:

SRVCC is built on the IMS centralized services (ICS) framework for delivering voice and messaging services to the users regardless of the type of network to which they are attached, and for maintaining service continuity for moving terminals.

To support GSM and UMTS, some modifications in the MSC server are required. When the E-UTRAN selects a target cell for SRVCC handover, it needs to indicate to the MME that this handover procedure requires SRVCC. Upon receiving the handover request, the MME triggers the SRVCC procedure with the MSC server. The MSC then initiates the session transfer procedure to IMS and coordinates it with the circuit-switched handover procedure to the target cell.

Handling of any non-voice packet-switched bearer is by the packet-switched bearer splitting function in the MME. The handover of non-voice packet-switched bearers, if performed, is according to a regular inter-RAT packet-switched handover procedure.

When SRVCC is enacted, the downlink flow of voice packets is switched toward the target circuit-switched network. The call is moved from the packet-switched to the circuit-switched domain, and the UE switches from VoIP to circuit-switched voice.

3GPP Rel-10 architecture has been recommended by GSMA for SRVCC because it reduces both voice interruption time during handover and the dropped call rate compared to earlier configurations. The network controls and moves the UE from E-UTRAN to UTRAN/GERAN as the user moves out of the LTE network coverage area. The SRVCC handover mechanism is entirely network-controlled and calls remain under the control of the IMS core network, which maintains access to subscribed services implemented in the IMS service engine throughout the handover process. 3GPP Rel-10 configuration includes all components needed to manage the time-critical signaling between the user’s device and the network, and between network elements within the serving network, including visited networks during roaming. As a result, signaling follows the shortest possible path and is as robust as possible, minimizing voice interruption time caused by switching from the packet-switched core network to the circuit-switched core network, whether the UE is in its home network or roaming. With the industry aligned around the 3GPP standard and GSMA recommendations, SRVCC-enabled user devices and networks will be interoperable, ensuring that solutions work in many scenarios of interest.

Along with the introduction of the LTE radio access network, 3GPP also standardized SRVCC in Rel-8 specifications to provide seamless service continuity when a UE performs a handover from the E-UTRAN to UTRAN/GERAN. With SRVCC, calls are anchored in the IMS network while the UE is capable of transmitting/ receiving on only one of those access networks at a given time, where a call anchored in the IMS core can continue in UMTS/GSM networks and outside of the LTE coverage area. Since its introduction in Rel-8, the SRVCC has evolved with each new release, a brief summary of SRVCC capability and enhancements are noted below

3GPP Rel-8: Introduces SRVCC for voice calls that are anchored in the IMS core network from E-UTRAN to CDMA2000 and from E-UTRAN/UTRAN (HSPA) to UTRAN/GERAN circuit-switched. To support this functionality, 3GPP introduced new protocol interface and procedures between MME and MSC for SRVCC from E-UTRAN to UTRAN/GERAN, between SGSN and MSC for SRVCC from UTRAN (HSPA) to UTRAN/GERAN, and between the MME and a 3GPP2-defined interworking function for SRVCC from E-UTRAN to CDMA 2000.

• 3GPP Rel-9: Introduces the SRVCC support for emergency calls that are anchored in the IMS core network. IMS emergency calls, placed via LTE access, need to continue when SRVCC handover occurs from the LTE network to GSM/UMTS/CDMA2000 networks. This evolution resolves a key regulatory exception. This enhancement supports IMS emergency call continuity from E-UTRAN to CDMA2000 and from E-UTRAN/UTRAN (HSPA) to UTRAN/ GERAN circuit-switched network. Functional and interface evolution of EPS entities were needed to support IMS emergency calls with SRVCC.

• 3GPP Rel-10: Introduces procedures of enhanced SRVCC including support of mid-call feature during SRVCC handover (eSRVCC); support of SRVCC packet-switched to circuit-switched transfer of a call in alerting phase (aSRVCC); MSC server-assisted mid-call feature enables packet-switched/ circuit-switched access transfer for the UEs not using IMS centralized service capabilities, while preserving the provision of mid-call services (inactive sessions or sessions using the conference service). The SRVCC in alerting phase feature adds the ability to perform access transfer of media of an instant message session in packet-switched to circuit-switched direction in alerting phase for access transfers.

• 3GPP Rel-11: Introduces two new capabilities: single radio video call continuity for 3G-circuit-switched network (vSRVCC); and SRVCC from UTRAN/GERAN to E-UTRAN/HSPA (rSRVCC). The vSRVCC feature provides support of video call handover from E-UTRAN to UTRAN-circuitswitched network for service continuity when the video call is anchored in IMS and the UE is capable of transmitting/receiving on only one of those access networks at a given time. Service continuity from UTRAN/GERAN circuitswitched access to E-UTRAN/HSPA was not specified in 3GPP Rel-8/9/10. To overcome this drawback, 3GPP Rel-11 provided support of voice call continuity from UTRAN/GERAN to E-UTRAN/HSPA. To enable video call transfer from E-UTRAN to UTRAN-circuit-switched network, IMS/EPC is evolved to pass relevant information to the EPC side and S5/S11/Sv/Gx/Gxx interfaces are enhanced for video bearer-related information transfer. To support SRVCC from GERAN to E-UTRAN/HSPA, GERAN specifications are evolved to enable a mobile station and base station sub-system to support seamless service continuity when a mobile station hands over from GERAN circuit-switched access to EUTRAN/ HSPA for a voice call. To support SRVCC from UTRAN to EUTRAN/ HSPA, UTRAN specifications are evolved to enable the RNC to perform rSRVCC handover and to provide relative UE capability information to the RNC.

NTT Docomo has a presentation on SRVCC and eSRVCC which is embedded below:

Improvement of VoLTE Domain HO with Operators Vision from Zahid Ghadialy

Advancements in Congestion control technology for M2M

NTT Docomo recently published a new article (embedded below) on congestion control approaches for M2M. In their own words:

Since 3GPP Release 10 (Rel. 10) in 2010, there has been active study of technical specifications to develop M2M communications further, and NTT DOCOMO has been contributing proactively to creating these technical specifications. In this article, we describe two of the most significant functions standardized between 3GPP Rel. 10 and Rel. 11: the M2M Core network communications infrastructure, which enables M2M service operators to introduce solutions more easily, and congestion handling technologies, which improve reliability on networks accommodating a large number of terminals.

Complete article as follows:

Core Network Infrastructure and Congestion Control Technology for M2M Communications from Zahid Ghadialy

Other related posts:

• Rise of the "Thing"
• Access Class Barring in LTE using System Information Block Type 2
• Extended Access Barring (EAB) in Release 11 to avoid MTC overload
• RAN mechanisms to avoid CN overload due to MTC
• Service Specific Access Control (SSAC) in 3GPP Release 9

TDD-FDD Joint CA

From a recent NTT Docomo presentation (embedded below). Whereas right now 3GPP has only been working on FDD or TDD scenarios, this proposal is a combination of FDD as P-Cell and TDD as S-Cell. Inter-Technology carrier aggregation is another possible option. Anyway, the complete presentation is below.

LTE-Advanced Enhancements and Future Radio Access Toward 2020 and Beyond from Zahid Ghadialy

Updated on 29/10/2013

3GPP has already started working on this work item. See RP-131399 for details.

NTT Docomo gives another shot to Mobile TV

Couple of news items from earlier this month from Japan about the nottv Mobile TV service. First was that it celebrated its 1st anniversary. The second is that it has racked up 700,000 subscribers; less than a million that it was expecting. I have posted in the past about attempts by various parties on Mobile TV that was unsuccessful. You can read more about that here and here.

One of the ways Mobile TV can provide additional value as compared to the normal TV is through audience participation. NOTTV is working to be able to provide this feature in future. Also it uses the ISDB-Tmm standard for broadcast. Hopefully in future when eMBMS is more popular, it may be used to transmit Mobile TV data as well. A picture showing the difference between the ISDB-T and ISDB-Tmm is shown below (from the presentation here)

A magazine article on NOTTV from the NTT Docomo magazine is embedded as follows:

Service Overview of NOTTV Mobile Multimedia Broadcasting for Smartphones from Zahid Ghadialy

eMBMS rollouts gathering steam in 2013

Its been a while since I last posted something on eMBMS. Its been even longer that we saw anything official from 3GPP on eMBMS. Recently I have seen some operators again starting to wonder if eMBMS makes business sense, while the vendors and standards are still working hard on the technology.

Not so long back, HEVC/H.265 codec was standardised. This codec helps transmission of the video using half the bandwidth. This means that it would be economical to use this for broadcast technologies. No wonder Nokia, Thompson and NTT Docomo are excited.

Interesting picture from a Qualcomm presentation (embedded in the end) shows how different protocols fit in the eMBMS architecture. My guess would be that the HEVC  may be part of the Codecs.

On the operators front, Korea Telecom (KT) has intentions for countrywide rollout. Korea is one of the very few countries where end users have embraced watching video on small form factors. Verizon wireless has already signalled the intention to rollout eMBMS in 2014; its working out a business case. Telenor Sweden is another player to join the band with the intention of adopting Ericsson's Multi screen technology.

One of the main reasons for the lack of support for the 3G MBMS technology was not a compelling business case. Qualcomm has a whitepaper that outlines some of the potential of LTE Broadcast technology here. A picture from this whitepaper on the business case below:

Finally, a presentation from Qualcomm research on eMBMS embedded below:

LTE eMBMS Technology Overview from Zahid Ghadialy