Pages

Showing posts with label LTE. Show all posts
Showing posts with label LTE. Show all posts

Tuesday, 4 March 2014

LTE Radar - LTE proximity services

Last year, DT gave an interesting presentation on what they termed as 'LTE Radar'. Here is the video to explain the motivation:


The picture below summarises how this will work:


It is interesting to note that these problems are already being solved using Apps and other technologies. Once the 3GPP standard is finalised, it would be a challenge to get this to mass adoption. An example would be Bluetooth based Beacons that I blogged about earlier here. Nevertheless, it would be interesting to see how compelling the use cases would be once this is standardised. The complete DT presentation is embedded below:



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:



Wednesday, 8 January 2014

LTE-Broadcast (eMBMS) may fail again

I recently wrote a blog post for the Cisco SP Mobility blog on why the Cellular Broadcast may fail again (complete article embedded below). My main point is that small screen devices are not really suitable for mobile TV kind of applications. The larger devices like tablets are but since they do not contain the (U)SIM card, its not possible for them to receive cellular broadcast signals.

Anyway, I came across this picture below from the recent Ericsson Mobility report:

This highlights my point that more people are now preferring to watch videos over the tablets as compared to the smaller smartphone screens. Even though the other diagrams in the article does show a significant amount of users using their smartphones for viewing movies and long clips, my belief is that this will reduce over the time as the tablet share increases



A recent Business Insider article says that "One In Every 5 People In The World Own A Smartphone, One In Every 17 Own A Tablet". Once the users move to using bigger screens, their preferences on how they watch videos will definitely change.

A real interesting chart would be to show users viewing habits based on the screen size. Phablets are generally classified as smartphones but can be substitutes for tablets in many scenarios. They could definitely help the Mobile TV viewing habits on the smartphones.

Anyway, here is the complete article:



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:

Tuesday, 29 October 2013

ANDSF: Evolution and Roaming with Hotspot 2.0


Access Network Discovery and Selection Function (ANDSF) is still evolving and with the introduction of Hotspot 2.0 (HS 2), there is a good possibility to provide seamless roaming from Cellular to Wi-Fi, Wi-Fi to Wi-Fi and Wi-Fi to Cellular.


There is a good paper (not very recent) by Alcatel-Lucent and BT that explains these roaming scenarios and other ANDSF policies related information very well. Its embedded below:




Sunday, 27 October 2013

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.

Monday, 23 September 2013

Push to talk (PTT) via eMBMS


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



Friday, 13 September 2013

LTE for Utilities and Smart Grids

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

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


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

The whitepaper is embedded below:



Related posts:


Thursday, 5 September 2013

Throughput Comparison for different wireless technologies

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

Saturday, 31 August 2013

VoLTE Bearers

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

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

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

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

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

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

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



Related posts:

Wednesday, 21 August 2013

eIMTA: Enhanced Interference Mitigation & Traffic Adaptation


eIMTA is one of the features being discussed in 3GPP Rel-12. The pictures above and below provide the details.
As can be seen, at the moment all the eNodeB's associated with a network has to transmit the same UL/DL pattern throughout out the system. With eIMTA, each eNodeB can decide the UL/DL pattern itself depending on the load.
The main challenge would be interference management while using this scheme.

See also, this slideshare presentation for details:


Wednesday, 17 July 2013

Decision Tree of Transmission Modes (TM) for LTE


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

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

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

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

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

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

For more details, see the whitepaper available here.

Related posts:


Friday, 12 July 2013

Monday, 8 July 2013

Adaptive Video Streaming: Principles, Improvements and Innovation


An Interdigital presentation from last year explains the principle of adaptive streaming very well for those who would not know how it worked.


This process of adaptation could be improved based on the quality of coverage at any particular time.

Interdigital are proposing a further enhancement of improving the adaptation further based on the User behaviour. If for example the user is far away then the quality need not be great on the device. On the other hand if the user is very close-by, the quality should be as good as it can get. They have explained it in a whitepaper for whoever is interested here.

A video showing this method is embedded below:


Sunday, 30 June 2013

Multi-RAT mobile backhaul for Het-Nets

Recently got another opportunity to hear from Andy Sutton, Principal Network Architect, Network Strategy, EE. His earlier presentation from our Cambridge Wireless event is here. There were many interesting bits in this presentation and some of the ones I found interesting is as follows:

Interesting to see in the above that the LTE traffic in the backhaul is separated by the QCI (QoS Class Identifiers - see here) as opposed to the 2G/3G traffic.




This is EE's implementation. As you may notice 2G and 4G use SRAN (Single RAN) while 3G is separate. As I mentioned a few times, I think 3G networks will probably be switched off before the 2G networks, mainly because there are a lot more 2G M2M devices that requires little data to be sent and not consume lots of energy (which is an issue in 3G), so this architecture may be suited well.


Finally, a practical network implementation which looks different from the text book picture and the often touted 'flat' architecture. Andy did mention that they see a ping latency of 30-50ms in the LTE network as opposed to around 100ms in the UMTS networks.


Mark Gilmour was able to prove this point practically.

Here is the complete presentation:



Saturday, 29 June 2013

Timing Accuracy and Phase Performance Requirements in LTE/LTE-A/4G

Nice quick summary videos from Chronos.



If you are interested in learning more on this topic or discussions, I would recommend joining the Phase Ready Linkedin group.

Thursday, 20 June 2013

Economical M2M using LTE - #LTEWS

In the upcoming LTE World Summit 2013 (programme here), I will be doing a briefing on the topic 'Economical M2M using LTE'. I have some ideas but I would like to hear more on what you think? In fact, is LTE the right technology from the M2M device point of view? Or do they better stick to 2G (I dont think 3G is good enough generally from low data M2M point of view). What other issues can be foreseen? Security? Roaming?
A recent presentation from Telefonica shows how they are partnering with other operators worldwide to create universal solutions. Will this help? Why not use these solutions for everything, not just LTE? LTE is data only technology isn't it?

The presentation is embedded below to draw your own conclusion but I an interested in hearing your thoughts on Twitter or here on the blog.