Friday, November 25, 2016

The Emperor's New Clothes

This blog is about European spectrum harmonization for BB-PPDR. ECC has created a very nice Report 218 about a year ago with proposals for frequency arrangement for BB-PPDR in CEPT countries. The final report proposes a concept called "flexible harmonization" based on three major elements:
  • common technical standard (i.e. LTE and its evolutions); 
  • national flexibility to decide how much spectrum and which specific frequency ranges should be designated for BB-PPDR networks within harmonised tuning range(s), according to national needs; 
  • national choice of the most suitable implementation model (either dedicated, commercial or hybrid).
If we examine the document in more detail, we find various frequency ranges and bands proposed for BB-PPDR. The report has identified following candidates within 400 MHz and 700 MHz ranges:
  • UL 410-420 MHz, DL 420-430 MHz (tuning range)
  • UL 450-460 MHz, DL 460-470 MHz (tuning range)
  • UL 703-713 MHz, DL 758-768 MHz (2 x 10 MHz)
  • UL 698-703 MHz, DL 753-758 MHz (2 x 5 MHz)
  • UL 733-736 MHz, DL 788-791 MHz (2 x 3 MHz)
  • UL 698-708 MHz, DL 753-763 MHz (2 x 10 MHz)
If we compare the above list to LTE bands that are actually standardized, we can conclude that there is only Band 31 on 450 MHz (to be exact UL 452,5-457,5 MHz, DL 462,5-467,5 MHz) and on 700 MHz we have Band 68 (UL 698-728 MHz, DL 753-783 MHz) and Band 28 (UL 703-748 MHz, DL 758-803 MHz). These are just 3GPP specifications. The critical thing is to check the ecosystem. Are there network infrastructure products, are there mobile devices, are there mobile device components especially chipsets and filters?

The reality is that B31 is still emerging with device ecosystem including some handsets but mostly just data modems. And B68 does not have anything yet! On the other hand B28 (both lower and upper duplexer) is well supported. The reason is that B28 is commercially used band. B31 license owners are often small data only operators instead of the major mobile operators. Therefore B31 progress has been somewhat slow. But B68 is currently intended exclusively for BB-PPDR with existing allocation for example in France. B68 is not very attractive taking into account typically very low number of PPDR users compared.

This is not all. According to ECC Decision 16(02), CEPT administrations are wishing to introduce additional spectrum for BB-PPDR.
  • UL 450,5-456 MHz, DL 460,5-466 MHz
  • UL 452-457,5 MHz, DL 462-467,5 MHz
You can notice that these new band proposals are mostly overlapping with B31, but it just happens to be so that big countries like Germany and Spain are not fully aligned with B31. By the way, these new bands are now proposed as new work item in 3GPP.
  • Europe, how many bands and frequency options do we need for "harmonization"?
  • Europe, how can "harmonization" be also "flexible" allowing each country to decide which specific frequency ranges should be designated for BB-PPDR?
  • Europe, congratulations. You have agreed on one thing - to use LTE for BB-PPDR.
UK has decided to deploy BB-PPDR services by using commercially existing bands. I have heard some Brexit jokes, but did UK actually made one sensible decision not to follow CEPT proposals?

I'm desperately waiting an innocent child crying loudly: "But Europe has no BB-PPDR spectrum harmonization at all!"

Friday, September 16, 2016

Drones, deployable LTE networks and sunshine

It was a very nice and quite warm sunny day today in Espoo, Finland. So it was time to go out with some equipment and other stuff. The list was roughly following:

  • a drone with LTE connection for mission control
  • plenty of drone batteries
  • a smartphone running LTE radio measurement software (carried by the drone)
  • a compact LTE network (eNB + embedded EPC) - about 5 kg
  • a small directional X-pol antenna
  • a small telescope mast for the antenna
  • feeder cables, Ethernet cables, power cables
  • USIMs
  • Windows and Linux PCs (drone control, LTE throughput measurements, LTE network management)
  • a portable AC generator (power for PCs, drone battery charger and LTE network)
  • duct tape
  • screwdrivers
  • a van
  • licenses for flying drones and using LTE spectrum
And the questions was that how well the LTE uplink performs when a drone is flying up to 150 meters above the ground. And it worked very well. 

Before any results were available, there were of course many problems. The linux PC, which was the FTP server for throughput testing, did not run like the day before. Finally it was working somehow for testing purposes in non-GUI mode although some reboots were necessary during the day. Of course the EPC did not have all USIMs provisioned so some HSS re-configuration was necessary. Also some changes had to be made to the firewall of the LTE network before all IP flows were working. The test smartphone with test software had some difficulties to continue FTP upload in case the radio signal was too weak. Luckily the radio parameters were optimized correctly the day before so there was a nice over 20 Mbps uplink throughput with 10 MHz FDD channel. 

The result was that the area with permission to fly drones was too small. The drone was in 150 m above ground about 430 m from the eNB antenna and uplink throughput was still very nice 18-20 Mbps. 

Conclusion is that a larger area is needed to test the limits of using drones with a small deployable LTE network.  

Wednesday, June 15, 2016

Mission critical LTE in practice

I had a chance to participate the SALUS final validation event, which was arranged on 14. – 15.6.2016 at the Emergency Services College in Kuopio, Finland.
Approaching Kuopio.
SALUS is a EU funded project studying technologies, networks & business models and developing demo systems illustrating next generation PPDR communication tools. Key enablers for the anticipated new applications and communication methods are broadband radios i.e. LTE and WiFi.

A short excerpt from the SALUS final validation event introduction:
This event will include a variety of simulated public safety emergency conditions similar to real emergencies, occurring in a specialized 38-hectar-wide training ground. The goal is to prove the need and the advantages of using LTE mobile broadband technology in public safety scenarios whilst still ensuring interworking with Wi-Fi, TETRA and TETRAPOL technologies. Many key functionalities, such as push-to-talk, group communications, messaging, video streaming, video call, video-group call, high-speed access to data, seamless roaming and support for emergency calls by the public in affected areas, will be demonstrated.

And many interesting working demos were shown in the event. Below I briefly explain some applications and use cases implemented by the SALUS consortium members

Video was of course widely used for situational awareness. Different video cameras were used including body cameras, cameras in drones and fixed surveillance cameras with remote controlled pan-tilt-zoom (PTZ). And live video was streamed over LTE. Quite interesting learning was that videos sent from body cameras are not very useful for situational awareness due to shaky images and missing PTZ control. Maybe with some significantly improved image stabilization the body cameras could be used also for situational awareness. Probably the role of body cameras is to create video records for any later analysis of events or to be used as potential evidence. On the other hand a live video from a drone was giving excellent situational awareness information for command and control center (CCC).

CCC can see live videos from multiple sources.
Live video from a drone (large display on the table)
Location of emergency service teams is commonly available already today in CCCs. But of course this was demonstrated also in the event. Interesting application in CCC was based on smart board allowing CCC officers to draw easily instructions to a map and send them quickly to first responders with smartphones. CCC officer could for example give graphical navigation guidance to first responder team approaching the scene.
Smart board application.

Furthermore it was shown how CCC can also know the indoor location of first responders in known buildings. The demo system was using WiFi radios providing beacon signals from known indoor locations allowing the indoor positioning device to report the indoor location.

Monitoring applications were demonstrated especially focusing on safety of first responders. For example CCC got real time bio-vital signs such as heart rate.

In the event some scenarios used WiFi as complementary radio technology. One use case was WiFi mesh network providing coverage extension from the edge of LTE coverage. Another use case was WiFi based direct communication.
WiFi mesh in vehicles.
Although voice communication is not the reason for mission critical LTE, group call interworking was also a very interesting demo. There were live TETRA, Tetrapol and LTE networks in the event and it was shown how dispatcher can dynamically connect TETRA, Tetrapol and PTT over LTE users to same call group. And interworking between systems enabled group calls between all technologies.

It was a great event and proved that modern mobile broadband technology enables innovative applications for emergency services improving efficiency and safety.
A drone with streaming video camera.

Friday, May 27, 2016

TETRA+LTE smartphone

Airbus has launched a new handset, which combines TETRA radio for group voice communication and LTE for broadband data. The product is called Tactilon Dabat.

Very little information is available yet. It has 4.7 inch touch screen. It has normal TETRA handset features including PTT button, loud audio and rugged hardware with IP65 & IP67 rating. Security of the smartphone is covered simply stating that all data within the device is encrypted.

Nothing is said about the LTE features. Very likely the LTE band selection matches with common commercial LTE bands in TETRA markets. Because the announcement does not highlight LTE features it probably does not have any of the 3GPP mission critical features like release 12 QCIs.

So the device has two radios, which can be used simultaneously. Therefore the current consumption could be an issue especially, if the applications use LTE radio frequently during missions. Battery capacity is not yet known except it is "long-lasting" and battery can be changed.

The device is useful at least for improved situational awareness. There are front and back cameras in the smartphone, which can used for sharing images and videos with control center and other colleagues. Large screen allows to check the received images and videos from the scene shared by the first teams already on the site.

This is very positive step towards mission critical LTE. With a right set of data applications and high performance LTE, TETRA users will learn the benefits of MBB resulting in data application becoming as critical as group voice calls are today. As soon as the user groups notice improved efficiency, there is no return back to legacy voice only procedures.

Sunday, May 15, 2016

Robots for public safety

3GPP has started working on release 14 content. Public safety will again get enhancements especially on application layer. Mission critical push to talk (MCPTT) was specified in release 13 and next 3GPP introduces mission critical video and mission critical data service. Both include group communication capabilities i.e. group calls with video and group messaging. However the interesting thing is use cases considering various unmanned vehicles or even robots that require highly reliable, low latency and secure connection for remote control and live video streaming.

Let's first check what kind of "things" 3GPP expects to be relevant for first responders. Unmanned aerial vehicles (UAV) a.k.a. drones are nowadays common even as consumer toys. What is not common is the idea to control the drones and transmit live video over LTE. Remote flight control understandably requires low latency. Furthermore live video feed from the 360 camera of the drone needs to be real time especially, if remote flight control relies on the transmitted video. The key use case in public safety missions is improved situational awareness. Drones help control room operations in crises situation by providing live video from any direction.

In addition to UAVs, 3GPP has identified terrestrial unmanned vehicles. Latency requirements are tighter for controlling flying objects than for terrestrial objects. 3GPP has also considered submarine vehicles. Video streaming from all vehicles or robots is of course important.

3GPP specification 22.282 has defined end-to-end latency requirement for drone and robot control. The latency is measured between the action of the pilot and the movement of the robot. Following figures are specified for the control.
  • 50 ms for an unmanned aerial vehicle
  • 200 ms for an aquatic or submarine vehicle
  • 400 ms for a terrestrial robot
3GPP specification 22.281 includes latency for video camera control (e.g. pan, tilt, zoom).
  • during take-off and landing of an UAV, the video control latency shall remain under 100 ms
  • while flying an UAV, the video control latency shall remain under 300 ms
  • for an aquatic or submarine unmanned vehicle, the video control latency shall remain under 500 ms
  • for a terrestrial unmanned vehicle moving at less than 120 km/h, the video control latency shall remain under 400 ms

22.281 defines also requirements for the video delivery from transmitting camera to receiving device:
  • latency of the video transmission is less than 500 ms when the video is used by the pilot
  • latency for high priority video (e.g. emergency) is less  than 1 s
  • latency for normal video is less than 10 s

Thus 3GPP has identified not only quite obvious use case for UAVs, but also other robots for public safety. Submarine is somewhat interesting for LTE radio communication. Probably idea is that a submarine has an antenna above water level. Futuristic idea, which is not anymore too far away, is a robot handling dangerous tasks such as fire fighting. Just think about robots like Atlas developed by Boston Dynamics, Google working as fire fighter. Watch the impressive video about Atlas, The Next Generation.

Friday, April 15, 2016

MCPTT latency requirements

Mission critical communication has strict performance requirements for the push-to-talk (PTT) voice calls. The groups calls should be of course established as soon as possible, but the most important thing is that floor control is 'instant' and mouth-to-ear voice delay is minimal during mission critical PTT calls.

3GPP 22.179 specifies some key performance indicators (KPI), and the interesting ones are:
  • MCPTT access time (KPI 1)
  • Mouth-to-ear latency (KPI 3)
The figure below (from 22.179) illustrates the definitions of these two KPIs. The same specification defines also target values for these KPIs. The exact definition includes some probabilities and assumptions, but in order to keep it simple we need just to remember that KPI 1 should be less than 300 ms and KPI 3 should be also less than 300 ms.

One might ask whether LTE networks can guarantee such low latency targets. Well, these figures are actually coming from the existing 'oldish' legacy systems like TETRA. LTE is the latest commercial cellular technology so such end-to-end latency requirements give actually a lot of buffer for loaded network elements and mobile devices to forward packets and process signaling & voice within the required limits.

To get some perspective for the end-to-end (E2E) latency in LTE networks and Internet I have below two examples based on the Speedtest using iPhone6 over commercial LTE network in Finland. The E2E latency from Espoo to a server in Paris (distance 1900 km) was 52 milliseconds and to the closest server in Helsinki 14 ms. (Note: Speedtest reports the lowest ping, not an average)


Although the Speedtest latency and throughout results indicate that the LTE cell was quite empty, we can anyway notice that LTE radio, IP networks and optical transmission are able to guarantee low latency even over long distances with best effort data service. When we take into account that optimized MCPTT service will use prioritized GBR (guaranteed bit rate) bearers for voice media and floor control, the LTE based networks are not going to be any limit for high performance MCPTT service.

If there are any issues with mouth-to-ear latency or floor control performance, the most likely problems are in UE client and application server (AS) implementations. Assuming that media processing in AS does not perform any transcoding, then MCPTT UE product is probably the key component to achieve the MCPTT KPI requirements.

Sunday, April 10, 2016

Isolated E-UTRAN operation for public safety

Updated 24.5.2016

Resiliency and service availability can be enhanced in terrestrial public safety LTE network based on capability called 'Isolated E-UTRAN Operation for Public Safety (IOPS)'. IOPS enables local services in case backhaul connection to centralized macro core is lost. IOPS assumes that local EPC function is co-sited with eNodeB. Local EPC can serve also multiple eNodeBs. Local EPC includes at least HSS, MME, SGW and PGW functions.

The figure below depicts an example of shared RAN, which is serving both PS users and commercial subscribers. There are separate PLMN identities for commercial customers (PLMN 'A')  and PS customers (PLMN 'PPDR') and there are also separate core networks. In normal condition commercial and PS subscribers are attached to their own centralized core networks and all data connectivity and communication services are provided by the centralized core networks. The lower part of figure depicts a transmission failure in backhaul. In that case eNodeBs can activate IOPS mode and offer local services. However IOPS services are available only for PS UEs that have subscription for IOPS mode including access class 11 or 15.

The fall-back procedure is illustrated in the next figure. Public safety UEs are normally attached to centralized EPC and there can be also UEs in active state when the backhaul connection is lost. Any RRC connected UEs are released and the eNodeB establishes S1 connection to local EPC. IOPS mode is indicated by broadcasting an 'IOPS' PLMN ID for which PS UE has a separate USIM application. The IOPS PLMN is marked in system information broadcast as reserved for operator use, which means that access classes 0-9 and 12-14 behave as if the cell status is "barred" (See 36.304).  

Because the minimum functionality of local EPC provides only IP connectivity service, it may be necessary to include also other functions for efficient isolated communication. Mission critical push to talk (MCPTT) is definitely important application for PS users. Also some broadband data applications can be considered for IOPS. For example real time video for situational awareness is typical application enabled by LTE.

IOPS is specified initially in 3GPP release 13 (23.401 Annex K) and it is optional in any public safety LTE network. 

Friday, April 8, 2016

Public Safety D2D devices to Korean market

Although 3GPP specified Proximity Services (ProSe) including direct communication for public safety already in release 12 (2015) there has been quite little evidence about real implementations. Qualcomm's interest seems to be more in commercial use cases based on the discovery functions of ProSe. Explanation is very likely the much higher volumes in consumer devices and applications compared to potential special public safety device volumes.

However now there are some English and Korean language news, which seem to indicate that Samsung is developing 3GPP direct communication (or device-to-device, D2D) for Korean market. Korea has been active in driving public safety LTE as the first significant market. The initial pilot phase of the public safety LTE network has been awarded to SK Telecom and KT.

Out of terrestrial network coverage

Updated 9.4.2016

Public safety terrestrial network coverage may not be always available for mission critical communication because of many reasons. Coverage may be missing by design in uninhabited areas, but temporary communication solution might be needed for example due to a forest fire. Some indoor or underground locations such as tunnels, basements and caves may not have coverage available. There could be also network outage due to natural disaster or broken transmission link. Still public safety users need communication solutions in case of an emergency.

Temporary coverage can be provided with deployable systems. Such a system can be fully standalone network without any connection to external networks or there can be a suitable transport connection for example over satellite to connect deployable eNB to a centralized core network. Deployable systems can also vary in coverage & capacity from large macro eNB with multiple sectors to a small micro or pico cell.

The figure below illustrates few options. The first on the left is a high capacity macro eNB including complete core network (at least MME, SGW, PGW and HSS). It can be a trailer or a truck installation with power supply and for example pneumatic mast antenna. In the middle there is outdoor micro eNB with single cell and satellite connectivity installed in a van. On the right there is a pico cell with embedded EPC and battery to be carried by one man easily to any location.

Deployable systems can be implemented today based on existing products, and the deployable systems can be used with all standard LTE devices. Though there is also 3GPP solution that can be used. 3GPP release 13 specifies isolated E-UTRAN operation for public safety (23.401 [Annex K] IOPS). IOPS can be the standalone solution for public safety users. Based on IOPS specification the main core functions are included in local EPC co-sited with eNB. In case of IOPS compliant solution, a dedicated PLMN identity is used and only UEs with access classes 11 - 15 can access the system.

Deployable base stations are quite common solutions for mobile operator, who can use them typically for temporary additional capacity. Below is a figure from millennial anniversary of Hanoi, where operators had to offer more capacity for the celebrating people.

Different companies have already deployable solutions targeted especially for public safety use cases. Few examples:

  • Nokia & Harris have launched deployable LTE in 2014 
  • Deployable cell on wheels by General Dynamics
  • Google's  project Loon is not specifically for public safety, but it is interesting concept with LTE basestation carried by a balloon 
  • Parallel Wireless offers 'instant LTE network for public safety' 
  • Star Solutions has LTE system in backpack 
  • Air-Lynx has compact deployable LTE network supporting different LTE bands
  • Oceus Networks offers compact rapidly deployable LTE system 

In the future public safety users will have also other option to communicate in areas without existing macro network coverage. The solution will be based on 3GPP Release 12 Proximity Services (ProSe) and especially on LTE direct communication, which is part of 3GPP proximity services.

LTE direct communication is based on direct LTE transmission between public safety UEs. This direct LTE connection is also called 'sidelink' in 3GPP radio specifications (see Rel-12 or Rel-13 36.331 RRC). When direct communication capable PS devices are out of coverage, they can use 'sidelink' for group communication. 3GPP Rel-13 mission critical push-to-talk (23.179 MCPTT) includes support for off-network communication based on ProSe direct communication.

Direct communication is specified in release 12 & 13 supporting selected LTE frequency bands and bandwidths (See 36.101 UE radio Tx and Rx):

  • Band 3 (1800 MHz), 10 MHz 
  • Band 7 (2600 MHz), 10 MHz
  • Band 14 (700 MHz), 10 MHz
  • Band 20 (800 MHz), 10 MHz
  • Band 26 (850 MHz), 10 MHz
  • Band 28 (700 MHz), 10 MHz
  • Band 31 (450 MHz), 5 MHz
  • new Rel-13 Band 68 (700 MHz), x MHz (info missing from version 13.3.0 specification)   

Direct communication UE uses the uplink frequencies of the FDD band for transmission and reception.

Sunday, January 24, 2016

Mission Critical Push To Talk and EPS bearers

Mission critical push to talk architecture defines several reference points and uses multiple
protocols over different EPS bearers.

23.179 specifies that UE connets to MCPTT specific APN in order to use MCPTT service. It is defined that SIP signaling uses QCI 69 bearer. Additionally HTTP is used for signaling. 23.179 defines also that QCI 8 or better is used for HTTP messaging.
Voice media is transmitted over secure RTP either using unicast GBR QCI65 bearer or optionally in multicasting downlink media over MBMS GBR QCI65 bearer. Same bearer (unicast or multicast) is used also floor control.

Following figure depicts how these MCPTT reference points can be mapped to unicast and multicast bearers. Although the 23.179 states that SIP and HTTP can be mapped to different unicast bearers that have different QoS, it can be also interpreted that QCI69 is better than QCI8 and therefore it should be possible to carry both SIP and HTTP signalling over the default QCI69 bearer.

After LTE attach, UE performs authentication and authorization (33.179):

  • A: MCPTT user authentication (CSC-1)
  • B: SIP Registration and Authentication
  • C: MCPTT Service Authorization.

A and B can be performed in any order. A i.e MCPTT user authentication is performed over secure connection TLS, which can be established e.g. based on certificates.
B is based on IMS AKA as specific in 33.203. Confidentiality and integrity is provided according to Gm interface i.e. using IPsec.
MCPTT client uses credentials received in A for MCPTT service authorization in C.

MCPTT reference points:

  • CSC-1 is used for MCPTT user authentication between identity management client and server over secure HTTP/TLS. 
  • CSC-4 provides configuration information for MCPTT service. HTTP is used for non-subscription/notification related signaling and SIP is used for subscription/notification related signaling.
  • CSC-2 is used for configuration of group management data between server and client. HTTP is used for non-subscription/notification related signaling and SIP is used for subscription/notification related signaling. 
  • CSC-8 provides key material over HTTP/TLS from key management server for e2e communication security (keys for SRTP and SRTCP).
  • MCPTT-1 is used for MCPTT session establishment. MCPTT may also provides also location information with respect to multicast service availability. MCPTT-1 shall use SIP and it may use also HTTP. MCPTT-1 includes GC1 as described in 23.468.
  • MCPTT-4 is reference point for floor control over unicast bearer. Secure RTCP (SRTCP) is used for floor control.
  • MCPTT-5 reference point is used for policy control (QoS).
  • MCPTT-6 is used for requesting multicast resources. It uses MB2-C as defined in 29.468.
  • MCPTT-7 is for media distribution over unicast bearer using SGi interface. Secure RTP (SRTP) is used for media.
  • MCPTT-8 sends multicast media to MCPTT clients using MB2-U as defined in 23.468. Secure RTP (SRTP) is used for media.
  • MCPTT-9 provides floor control signaling over multicast bearer using MB2-U as defined in 23.468. Secure RTCP (SRTCP) is used for floor control .