Sunday, February 26, 2017

LTE for drone flight management and situational awareness

A nice LTE based drone solution was shown successfully by Nokia in UAE Drones for Good competition in Dubai. It was so nice that Nokia won the Drones for Good Award in the international category.

Public safety organizations can use LTE networks - also deployable LTE networks - for new applications and solutions such as unmanned aerial vehicles equipped with video cameras. LTE coverage significantly improves the drone flight control capabilities compared to traditional remote control radios. And at the same time LTE provides broadband capacity for multiple live video streams from drones.

It is coming reality that emergency services can use LTE broadband and drones for improved efficiency in firefighting, search & rescue and many other public safety missions. It is important to note that this is possible already now - even before any 3GPP Release 14 mission critical video and robot control features.




Thursday, February 16, 2017

Prioritization in commercial network

The market signals from various countries indicate a global trend to start public safety LTE (PS LTE) services together with commercial operators. The benefits are quite obvious i.e. commercial LTE coverage is already widely deployed and PS LTE total cost is reduced when radio access is shared with commercial use. Additionally mobile operators have good spectrum assets. Operators have commonly 50 - 60 MHz FDD spectrum, which makes it quite easy to guarantee adequate capacity for future mission critical broadband services.

Mobile operators dimension and design networks for typical need and not necessarily to extreme load such as mass events. So, regardless of available spectrum, commercial mobile networks can get highly loaded or even overloaded. Still in all conditions public safety users must get reliable service access and good quality services. There are various technologies for prioritization like discussed earlier here.

You may now ask, what is the news. Well, operators are getting interested in public safety services and they need to enhance their networks for priority services. This time the news comes from Finland. Elisa, one of the mobile operators in Finland, has been testing LTE prioritization technologies and demonstrated them to some public order and security authorities. Read the whole press release here.

This is a great step. Let's see, if mobile operators in all countries take similar steps and start learning how to develop LTE networks for critical communication services. There is certainly a business opportunity to serve first responders and potentially much larger opportunity with industries demanding business critical services.

Saturday, January 21, 2017

APNs in MCPTT smartphone

LTE smartphones provide mobile broadband connection to Internet. The prerequisite is that the UE has correct settings, which depend on the mobile operator. Nowadays device vendors and operators have made the use of mobile data so easy that usually users do not need to do any manual configuration. Each smartphone has an internet APN (Access Point Name) configuration, which matches with the operator's network configuration. In general certain APN configuration allows UE to connect (when included in subscription) to certain IP network called packet data network (PDN). So, smartphones know operator's internet APN setting, which enables UE to connect to Internet.

Operators have also other APNs and respective PDNs, which offer operator specific services. Some of those services are standardized. On old, still existing service is MMS (Multimedia Messaging Service). MMS is supported by all smartphones and probably automatically configured in all devices and networks. The question is just that does anybody really use MMS anymore, while there are more widely used messaging services such as WhatsApp, Facebook Messenger and iMessage. Another operator service behind own APN is VoLTE (Voice over LTE). VoLTE usage is actually increasing when more are more operators enable VoLTE in their networks. People are still dependent on calling telephone numbers even though smartphones and Internet services allow to make voice over IP calls with multiple different apps such as Skype, Viber and Facetime Audio. So, let's forget the MMS (if user does not use it, there is no impact on UE's network connections) and focus on internet access and VoLTE services. Smartphone has at least active IP connection to Internet and optionally also active IP connection to operator's VoLTE service. VoLTE is accessed via so called IMS APN.

The figure below shows on top a VoLTE smartphone having two connections for VoLTE and Internet access services. At bottom there is a so called CS fallback (CSFB) UE, which makes any operator voice calls in 3G or 2G networks using traditional CS voice service. The CSFB UE has just one IP connection to Internet.

PDN connections of commercial LTE smartphones.

Mission critical push to talk (MCPTT) architecture specification 23.179 defines additional use of APNs for MCPTT service. UE must of course know the APN configuration before it can connect to MCPTT service. The APN information can be made available to the UE for example via UE pre-configuration.

1) One option is that there is a dedicated APN for mission critical services. One clear benefit would be enhanced security, when mission critical services are separated from all other services with dedicated PDN.

2) 3GPP also suggests that mission critical functions can be separated to three different PDN connections as listed below. This would cause quite a lot additional complexity, while the benefits are questionable.
  • Mission critical identity management service APN and PDN
  • Mission critical common core services APN and PDN
  • Mission critical PTT service APN and PDN
3) Third model for MCPTT is to share APN and PDN connection with other services that have compatible QoS. 3GPP gives one example based on shared IMS APN in case same operator provides VoLTE and MCPTT services.

One could consider that separating MCPTT service from all other services is important, but then again solution should be fairly simple. So the first option could be used. This is depicted in the figure below.
MCPTT UE with dedicated APN for MCPTT service.

Are there any issues with the model shown above?

Each active PDN connection consumes at least one default EPS bearer from UE resources. This is important to note, because LTE device can have only limited amount of data radio bearers (DRB) and respective EPS bearers. LTE UE informs network about its capability support multiple data radio bearers with feature group indicators (see 36.331). Every LTE device supports at minimum 4 data radio bearers and in maximum 8 data radio bearers. 8 bearers is commonly supported in modern LTE smartphones so in principle there is possibility to have simultaneously active connections to multiple PDNs. In practice this is not so simple for service providers to use multiple APNs and PDN connections for single subscriber.

MCPTT UE client can be implemented as software application. Thus it could be installed on any commercial smartphone. Applications can easily access the UE hardware resources like touchscreen, microphone, speaker and any physical buttons. So, user interface for MCPTT can be implemented to basically any modern smartphone. And then the application only has to request connection to MCPTT APN(s) in order to access the PDN(s) providing mission critical services. This is easy - or is it?

Let's consider Android OS, which is the dominating smartphone OS (87% market share 2016 Q3 according to IDC). Those, who are familiar with Android smartphone settings, may have noticed that user can configure different APN settings to Android, but only one data APN setting can be active. So user cannot activate multiple data APNs for Android applications. There is also another APN configurable by user, but it is for the operator MMS service. Then we know that VoLTE smartphones use dedicated APN for the VoLTE service. This is however implemented so that the APN is standardized by GSM Association (so called IMS well-known APN defined in IR.88) and therefore there is no need to configure APN for VoLTE service.

Although Android does not support OS level capability to configure multiple data APNs for applications, could application developer implement application specific APN? Now this is actually the main problem. Applications have to have permission to perform different actions, but the permission to define and modify APN settings (WRITE_APN_SETTINGS) is not available for 3rd party applications. Only the Android system tools can modify APN.

As mentioned, 3GPP has also considered that the IMS APN could be shared between VoLTE and MCPTT. However IMS APN is tightly integrated to VoLTE and 3rd party applications do not have any access to IMS APN connection either.

Conclusion is that operator cannot implement MCPTT service to be used by commercial smartphones so that MCPTT would have dedicated APN and internet would be accessed via another APN.

Now someone thinks that MCPTT is a service for users, who always require special rugged devices with dedicated PTT button and highly secure HW and modified secure OS. Yes, some user groups will require such devices. In that case, the device vendor can implement tightly integrated MCPTT application, which has permissions to use dedicated MCPTT APN, while other data applications can use another data APN (see the previous figure). This is possible approach, but if MCPTT service is designed only for such devices, then there is no easy "fast track" option for MCPTT deployments based on existing commercial devices.

There is still another approach, which allows to use existing smartphones with 3rd party MCPTT application. And this model could be actually even better option for secure connection to Internet. The idea is that the single data APN in a smartphone connects to MCPTT operator's PDN, which offers mission critical services such as MCPTT as well as secure connection to Internet. This mission critical PDN can have enhanced firewalls, malware detection and content filtering in addition to the UE based security. The model with single data APN is depicted below. This enables use of both commercial smartphones and special rugged, secure public safety smartphones.

MCPTT UE connecting to Internet via "mission critical" PDN. 

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.