Showing posts with label Release 14. Show all posts
Showing posts with label Release 14. Show all posts

Thursday, 26 January 2017

3GPP Rel-14 IoT Enhancements

A presentation (embedded below) by 3GPP RAN3 Chairman - Philippe Reininger - at the IoT Business & Technologies Congress (November 30, in Singapore). Main topics are eMTC, NB-IOT and EC-GSM-IoT as completed in 3GPP Release 13 and enhanced in Release 14. Thanks to Eiko Seidel for sharing the presentation.

Sunday, 6 November 2016

LTE, 5G and V2X

3GPP has recently completed the Initial Cellular V2X standard. The following from the news item:

The initial Cellular Vehicle-to-Everything (V2X) standard, for inclusion in the Release 14, was completed last week - during the 3GPP RAN meeting in New Orleans. It focuses on Vehicle-to-Vehicle (V2V) communications, with further enhancements to support additional V2X operational scenarios to follow, in Release 14, targeting completion during March 2017.
The 3GPP Work Item Description can be found in RP-161894.
V2V communications are based on D2D communications defined as part of ProSe services in Release 12 and Release 13 of the specification. As part of ProSe services, a new D2D interface (designated as PC5, also known as sidelink at the physical layer) was introduced and now as part of the V2V WI it has been enhanced for vehicular use cases, specifically addressing high speed (up to 250Kph) and high density (thousands of nodes).


For distributed scheduling (a.k.a. Mode 4) a sensing with semi-persistent transmission based mechanism was introduced. V2V traffic from a device is mostly periodic in nature. This was utilized to sense congestion on a resource and estimate future congestion on that resource. Based on estimation resources were booked. This technique optimizes the use of the channel by enhancing resource separation between transmitters that are using overlapping resources.
The design is scalable for different bandwidths including 10 MHz bandwidth.
Based on these fundamental link and system level changes there are two high level deployment configurations currently defined, and illustrated in Figure 3.
Both configurations use a dedicated carrier for V2V communications, meaning the target band is only used for PC5 based V2V communications. Also in both cases GNSS is used for time synchronization.
In “Configuration 1” scheduling and interference management of V2V traffic is supported based on distributed algorithms (Mode 4) implemented between the vehicles. As mentioned earlier the distributed algorithm is based on sensing with semi-persistent transmission. Additionally, a new mechanism where resource allocation is dependent on geographical information is introduced. Such a mechanism counters near far effect arising due to in-band emissions.
In “Configuration 2” scheduling and interference management of V2V traffic is assisted by eNBs (a.k.a. Mode 3) via control signaling over the Uu interface. The eNodeB will assign the resources being used for V2V signaling in a dynamic manner.

5G Americas has also published a whitepaper on V2X Cellular Solutions. From the press release:

Vehicle-to-Everything (V2X) communications and solutions enable the exchange of information between vehicles and much more - people (V2P), such as bicyclists and pedestrians for alerts, vehicles (V2V) for collision avoidance, infrastructure (V2I) such as roadside devices for timing and prioritization, and the network (V2N) for real time traffic routing and other cloud travel services. The goal of V2X is to improve road safety, increase the efficiency of traffic, reduce environmental impacts and provide additional traveler information services. 5G Americas, the industry trade association and voice of 5G and LTE for the Americas, today announced the publication of a technical whitepaper titled V2X Cellular Solutions that details new connected car opportunities for the cellular and automotive industries.

The whitepaper describes the benefits that Cellular V2X (C-V2X) can provide to support the U.S. Department of Transportation objectives of improving safety and reducing vehicular crashes. Cellular V2X can also be instrumental in transforming the transportation experience by enhancing traveler and traffic information for societal goals.

C-V2X is part of the 3GPP specifications in Release 14. 3GPP announced the completion of the initial C-V2X standard in September 2016. There is a robust evolutionary roadmap for C-V2X towards 5G with a strong ecosystem in place. C-V2X will be a key technology enabler for the safer, more autonomous vehicle of the future.

The whitepaper is embedded below:

Related posts:
Further Reading:

Sunday, 14 August 2016

3GPP Release-14 & Release-15 update

3GPP is on track for 5G as per a news item on the 3GPP website. In 5G World in London in June, Erik Guttman, 3GPP TSG SA Chairman, and Consultant for Samsung Electronics spoke about progress on Release-14 and Release-15. Here is his presentation.

According to 3GPP:

The latest plenary meeting of the 3GPP Technical Specifications Groups (TSG#72) has agreed on a detailed workplan for Release-15, the first release of 5G specifications.
The plan includes a set of intermediate tasks and check-points (see graphic below) to guide the ongoing studies in the Working Groups. These will get 3GPP in a position to make the next major round of workplan decisions when transitioning from the ongoing studies to the normative phase of the work in December 2016:- the start of SA2 normative work on Next Generation (NexGen) architecture and in March 2017:- the beginning of the RAN Working Group’s specification of the 5G New Radio (NR).
3GPP TSG RAN further agreed that the target NR scope for Release 15 includes support of the following:
  • ■ Standalone and Non-Standalone NR operation (with work for both starting in conjunction and running together)
    • ■ Non-standalone NR in this context implies using LTE as control plane anchor. Standalone NR implies full control plane capability for NR.
    • ■ Some potential architecture configuration options are shown in RP-161266 for information and will be analyzed further during the study
  • ■ Target usecases: Enhanced Mobile Broadband (eMBB), as well as Low Latency and High Reliability to enable some Ultra-Reliable and Low Latency Communications (URLCC) usecases
  • ■ Frequency ranges below 6GHz and above 6GHz
During the discussion at TSG#72 the importance of forward compatibility - in both radio and protocol design - was stressed, as this will be key for phasing-in the necessary features, enabling all identified usecases, in subsequent releases of the 5G specification.

Telecom TV has posted a video interview with Erik Guttman which is embedded below:

Related posts:

Sunday, 26 July 2015

LTE vs TETRA for Critical Communications

Sometime back I was reading this interview between Martin Geddes and Peter Clemons on 'The Crisis in UK Critical Communications'. If you haven't read it, I urge you to read it here. One thing that stuck out was as follows:

LTE was not designed for critical communications.

Commercial mobile operators have moved from GSM to UMTS to WCDMA networks to reflect the strong growth in demand for mobile data services. Smartphones are now used for social media and streaming video. LTE technology fulfils a need to supply cheap mass market data communications.

So LTE is a data service at heart, and reflects the consumer and enterprise market shift from being predominantly voice-centric to data-centric. In this wireless data world you can still control quality to a degree. So with OFDM-A modulation we have reduced latency. We have improved how we allocate different resource blocks to different uses.

The marketing story is that we should be able to allocate dedicated resources to emergency services, so we can assure voice communications and group calling even when the network is stressed. Unfortunately, this is not the case. Even the 3GPP standards bodies and mobile operators have recognised that there are serious technology limitations.
This means they face a reputational risk in delivering a like-for-like mission-critical voice service.

Won’t this be fixed by updated standards?
The TETRA Critical Communications association (TCCA) began to engage with the 3GPP standards process in 2012. 3GPP then reached out to peers in the USA and elsewhere: the ESMCP project here in the UK, the US FirstNet programme, and the various European associations.

These lobbied 3GPP for capabilities specifically aimed at critical communications requirements. At the Edinburgh meeting in September 2014, 3GPP set up the SA6specification group, the first new group in a decade.

The hope is that by taking the critical communications requirement into a separate stream, it will no longer hold up the mass market release 12 LTE standard. Even with six meetings a year, this SA6 process will be a long one. By the end of the second meeting it had (as might be expected) only got as far as electing the chairman.

It will take time to scope out what can be achieved, and develop the critical communications functionality. For many players in the 3GPP process this is not a priority, since they are focusing solely on mass market commercial applications.

Similar point was made in another Critical communications blog here:

LTE has emerged as a long term possible replacement for TETRA in this age of mobile broadband and data. LTE offer unrivalled broadband capabilities for such applications as body warn video streaming, digital imaging, automatic vehicle location, computer-assisted dispatch, mobile and command centre apps, web access, enriched e-mail, mobile video surveillance apps such as facial recognition, enhanced Telemetry/remote diagnostics, GIS and many more. However, Phil Kidner, CEO of the TCCA pointed out recently that it will take many LTE releases to get us to the point where LTE can match TETRA on key features such as group working, pre-emptive services, network resilience, call set-up times and direct mode.
The result being, we are at a point where we have two technologies, one offering what end users want, and the other offering what end users need. This has altered the discussion, where now instead of looking at LTE as a replacement, we can look at LTE as a complimentary technology, used alongside TETRA to give end users the best of both worlds. Now the challenge appears to be how we can integrate TETRA and LTE to meet the needs and wants of our emergency services, and it seems that if we want to look for guidance and lessons on the possible harmony of TETRA and LTE we should look at the Middle East.
While I was researching, I came across this interesting presentation (embedded below) from the LTE World Summit 2015

The above is an interesting SWOT (Strengths, Weaknesses, Opportunities and Threats) analysis for TETRA and LTE. While I can understand that LTE is yet unproven, I agree on the lack of spectrum and appropriate bands.

I have been told in the past that its not just the technology which is an issue, TETRA has many functionalities that would need to be duplicated in LTE.

As you can see from this timeline above, while Rel-13 and Rel-14 will have some of these features, there are still other features that need to be included. Without which, safety of the critical communication workers and public could be compromised.

The complete presentation as follows. Feel free to voice your opinions via comments.

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