Showing posts with label NTT DoCoMo. Show all posts
Showing posts with label NTT DoCoMo. Show all posts

Friday, 14 September 2018

End-to-end Network Slicing in 5G

I recently realised that I have never written a post just on Network slicing. So here is one on the topic. So the first question asked is, why do we even need Network Slicing? Alan Carlton from Interdigital wrote a good article on this topic. Below is what I think is interesting:

Network slicing is a specific form of virtualization that allows multiple logical networks to run on top of a shared physical network infrastructure. The key benefit of the network slicing concept is that it provides an end-to-end virtual network encompassing not just networking but compute and storage functions too. The objective is to allow a physical mobile network operator to partition its network resources to allow for very different users, so-called tenants, to multiplex over a single physical infrastructure. The most commonly cited example in 5G discussions is sharing of a given physical network to simultaneously run Internet of Things (IoT), Mobile Broadband (MBB), and very low-latency (e.g. vehicular communications) applications. These applications obviously have very different transmission characteristics. For example, IoT will typically have a very large number of devices, but each device may have very low throughput. MBB has nearly the opposite properties since it will have a much smaller number of devices, but each one will be transmitting or receiving very high bandwidth content. The intent of network slicing is to be able to partition the physical network at an end-to-end level to allow optimum grouping of traffic, isolation from other tenants, and configuring of resources at a macro level.

Source: ITU presentation, see below

The key differentiator of the network slicing approach is that it provides a holistic end-to-end virtual network for a given tenant. No existing QoS-based solution can offer anything like this. For example, DiffServ, which is the most widely deployed QoS solution, can discriminate VoIP traffic from other types of traffic such as HD video and web browsing. However, DiffServ cannot discriminate and differentially treat the same type of traffic (e.g. VoIP traffic) coming from different tenants.

Also, DiffServ does not have the ability to perform traffic isolation at all. For example, IoT traffic from a health monitoring network (e.g. connecting hospitals and outpatients) typically have strict privacy and security requirements including where the data can be stored and who can access it. This cannot be accomplished by DiffServ as it does not have any features dealing with the compute and storage aspects of the network. All these identified shortfalls of DiffServ will be handled by the features being developed for network slicing.

I came across this presentation by Peter Ashwood-Smith from Huawei Technologies who presented '5G End to-end network slicing Demo' at ITU-T Focus Group IMT-2020 Workshop and Demo Day on 7 December 2016. Its a great presentation, I wish a video of this was available as well. Anyway, the presentation is embedded below and the PPT can be downloaded from here.



The European Telecommunications Standards Institute (ETSI) has established a new Industry Specification Group (ISG) on Zero touch network and Service Management (ZSM) that is working to produce a set of technical specifications on fully automated network and service management with, ideally, zero human intervention. ZSM is targeted for 5G, particularly in network slice deployment. NTT Technical review article on this is available here.

Finally, here is a presentation by Sridhar Bhaskaran of Cellular Insights blog on this topic. Unfortunately, not available for download.


Related Posts:

Tuesday, 3 July 2018

Terahertz and Beyond 100 GHz progress

There seems to be a good amount of research going on in higher frequencies to see how a lot more spectrum with a lot more bandwidth can be used in future radio communications. NTT recently released information about "Ultra high-speed IC capable of wireless transmission of 100 gigabits per second in a 300 GHz band". Before we discuss anything, lets look at what Terahertz means from this article.

Terahertz wave: Just as we use the phrase ‘kilo’ to mean 103 , so we use the term ‘giga’ to mean 109 and the term ‘tera’ to mean 1012 . “Hertz (Hz)” is a unit of a physical quantity called frequency. It indicates how many times alternating electric signals and electromagnetic waves change polarity (plus and minus) per second. That is, one terahertz (1 THz = 1,000 GHz) is the frequency of the electromagnetic wave changing the polarity by 1 × 1012 times per second. In general, a terahertz wave often indicates an electromagnetic wave of 0.3 THz to 3 THz.

While there are quite a few different numbers, this is the one that is most commonly being used. The following is the details of research NTT did.

In this research, we realized 100 Gbps wireless transmission with one wave (one carrier), so in the future, we can extend to multiple carriers by making use of the wide frequency band of 300 GHz band, and use spatial multiplexing technology such as MIMO and OAM. It is expected to be an ultra high-speed IC technology that enables high-capacity wireless transmission of 400 gigabits per second. This is about 400 times the current LTE and Wi-Fi, and 40 times 5G, the next-generation mobile communication technology. It is also expected to be a technology that opens up utilization of the unused terahertz wave frequency band in the communications field and non-communication fields.

Complete article and paper available here.

Huawei has also been doing research in W (92 - 114.5 GHz) and D (130 - 174.5 GHz) bands.


A recent presentation by Debora Gentina, ETSI ISG mWT WI#8 Rapporteur at the UK Spectrum Policy Forum is embedded below.



This presentation can be downloaded from UK SPF site here. Another event on beyond 100GHz that took place last year has some interesting presentations too. Again, on UKSPF site here.


Ericsson has an interesting article in Technology Review, looking at beyond 100GHz from backhaul point of view. Its available here.

If 5G is going to start using the frequencies traditionally used by backhaul then backhaul will have to start looking at other options too.

Happy to listen to your thoughts and insights on this topic.

Wednesday, 16 May 2018

100 Gbps wireless transmission using Orbital Angular Momentum (OAM) multiplexing


From a press release by NTT Group:

Nippon Telegraph and Telephone Corporation (NTT, Head Office: Chiyoda-ku, Tokyo, President and CEO: Hiroo Unoura) has successfully demonstrated for the first time in the world 100 Gbps wireless transmission using a new principle — Orbital Angular Momentum (OAM) multiplexing — with the aim of achieving terabit-class wireless transmission to support demand for wireless communications in the 2030s. It was shown in a laboratory environment that dramatic leaps in transmission capacity could be achieved by an NTT devised system that mounts data signals on the electromagnetic waves generated by this new principle of OAM multiplexing in combination with widely used Multiple-Input Multiple-Output (MIMO) technology. The results of this experiment revealed the possibility of applying this principle to large-capacity wireless transmission at a level about 100 times that of LTE and Wi-Fi and about 5 times that of 5G scheduled for launch. They are expected to contribute to the development of innovative wireless communications technologies for next-generation of 5G systems such as connected cars, virtual-reality/augmented-reality (VR/AR), high-definition video transmission, and remote medicine.


NTT is to present these results at Wireless Technology Park 2018 (WTP2018) to be held on May 23 – 25 and at the 2018 IEEE 87th Vehicular Technology Conference: VTC2018-Spring, an international conference sponsored by the Institute of Electrical and Electronics Engineers (IEEE) to be held on June 3 – 6.


For more technical details look at the bottom of this link.

Related Post:

Wednesday, 7 March 2018

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 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

Network Equipment Vendors

Handset Manufacturers

Chipset Manufacturers

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


MWC Summary from other Analysts:


Tuesday, 26 September 2017

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:

Sunday, 21 May 2017

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:



Saturday, 27 August 2016

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.



Sunday, 17 April 2016

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:

Sunday, 1 November 2015

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:

Saturday, 10 October 2015

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:



Sunday, 12 July 2015

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



Wednesday, 7 January 2015

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.



Related links:

Tuesday, 23 December 2014

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:




Monday, 12 May 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, 5 May 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:


Friday, 18 April 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, 13 February 2014

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




Monday, 20 January 2014

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:



Friday, 13 December 2013

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:



Other related posts: