Showing posts with label NTT DoCoMo. Show all posts
Showing posts with label NTT DoCoMo. Show all 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:

Sunday, 27 October 2013


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.

Monday, 29 April 2013

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:

Monday, 22 April 2013

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:

Monday, 1 April 2013

The 'Phantom Cell' concept in LTE-B

One of the LTE-B proposals by NTT Docomo is this 'Phantom Cell' concept. A recent article from the IEEE Communications Magazine expands this further:

Phantom Cell Concept — In the current deployments, there are a number of capacity solutions for indoor environments such as WiFi, femtocells, and in-building cells using distributed antenna systems (DAS). However, there is a lack of capacity solutions for high-traffic outdoor environments that can also support good mobility and connectivity. Thus, we propose the concept of macro-assisted small cells, called the Phantom Cell, as a capacity solution that offers good mobility support while capitalizing on the existing LTE network. In the Phantom Cell concept, the C-plane/U-plane are split as shown in Fig. The C-plane of UE in small cells is provided by a macrocell in a lower frequency band, while for UE in macrocells both the C-plane and U-plane are provided by the serving macrocell in the same way as in the conventional system. On the other hand, the Uplane of UE in small cells is provided by a small cell using a higher frequency band. Hence, these macro-assisted small cells are called Phantom Cells as they are intended to transmit UE-specific signals only, and the radio resource control (RRC) connection procedures between the UE and the Phantom Cell, such as channel establishment and release, are managed by the macrocell.

The Phantom Cells are not conventional cells in the sense that they are not configured with cell specific signals and channels such as cell-ID-specific synchronization signals, cell-specific reference signals (CRS), and broadcast system information. Their visibility to the UE relies on macrocell signaling. The Phantom Cell concept comes with a range of benefits. One important benefit of macro assistance of small cells is that control signaling due to frequent handover between small cells and macrocells and among small cells can be significantly reduced, and connectivity can be maintained even when using small cells and higher frequency bands. In addition, by applying the new carrier type (NCT) that contains no or reduced legacy cell-specific signals, the Phantom Cell is able to provide further benefits such as efficient energy savings, lower interference and hence higher spectral efficiency, and reduction in cellplanning effort for dense small cell deployments.

To establish a network architecture that supports the C/U-plane split, and interworking between the macrocell and Phantom Cell is required. A straightforward solution to achieve this is to support Phantom Cells by using remote radio heads (RRHs) belonging to a single macro eNB. This approach can be referred to as intra-eNB carrier aggregation (CA) using RRHs. However, such a tight CA-based architecture has some drawbacks as it requires single-node operation with low-latency connections (e.g., optical fibers) between the macro and Phantom Cells. Therefore, more flexible network architectures should be investigated to allow for relaxed backhaul requirements between macro and Phantom Cells and to support a distributed node deployment with separated network nodes for each (i.e., inter-eNB CA).

Monday, 28 January 2013

Overview of 3GPP Release-12 Study Item UPCON

Mobile operators are seeing significant increases in user data traffic. For some operators, user data traffic has more than doubled annually for several years. Although the data capacity of networks has increased significantly, the observed increase in user traffic continues to outpace the growth in capacity. This is resulting in increased network congestion and in degraded user service experience. Reasons for this growth in traffic are the rapidly increasing use of smart phones and tablet like devices, and the proliferation of data applications that they support, as well as the use of USB modem dongles for laptops to provide mobile Internet access using 3GPP networks. As the penetration of these terminals increases worldwide and the interest in content-rich multi-media services (e.g. OTT video streaming services) rises, this trend of rapidly increasing data traffic is expected to continue and accelerate.

Here are couple of presentations on this topic:

Related blog posts:

Wednesday, 23 January 2013

LTE-B, LTE-C, ... , LTE-X

Please make sure to read the comment from Kevin Flynn of 3GPP at the end

When I saw this picture above, I started wondering what LTE-B, etc. and started digging a bit deep. Came across this Ericsson presentation (embedded below) that shows the breakdown.

To just be sure that this is not Ericsson specific term, I also found a presentation by NTT Docomo (embedded below)
So I guess using LTE-B, LTE-C, etc. is better than saying 4.1G, 4.2G, etc. as we did in case of 3G/HSPA.

The presentations from Ericsson and NTT Docomo embedded below, available to download from Slideshare.