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.



Comments

  1. AnonymousAugust 3, 2016 at 9:38 PM

    Hei Mika, Great blog! Regarding control of robots and drones. You mentioned latency of 50 ms which is requirement for controlling UAVs which is very tight requirement. Which QCI (as defined in 3GPP TS 23.203) shall be used in this case? Does some new QCI needs to be added for this case as any of those already defined might not be suited for this use case?

    Ex-Nokian

    ReplyDelete
    Replies
    1. Mika AaltoAugust 4, 2016 at 8:26 AM

      Good question. Packet delay budget for standardized QCIs is considered as upper limit. In principle non of the existing QCIs would fulfill this requirement in the worst case scenario. In practice commercial networks support even with QCI9 commonly 15-20 ms ping (two way) latency. So typically 50 ms e2e latency is no problem. Of course congestion impacts latency.

      Another aspects is that any wirelessly controlled device should not rely on well working radio link. The drone SW should take into account packet losses and radio link failures in which case there must be a safety mode (e.g. continue based on preplanned route or wait until radio is working again or carefully search for radio connection and monitor surrounding environment while moving).

      I hope 3GPP will not specify any new QCIs, because there are already too many (my personal opinion).

      Delete
  2. UnknownAugust 4, 2016 at 7:36 AM

    As exciting as it can be, flying drones and taking photos from the air are limited by rules you need to follow. Otherwise you could get fined or even have a penal file made for reckless behavior. It may seem a bit harsh, especially when you consider that drones are a lot of fun and you aren’t doing anything wrong (from your point of view). See more http://mydronelab.com/blog/rules-for-drone-photography.html

    ReplyDelete
    Replies
    1. Mika AaltoAugust 4, 2016 at 8:28 AM

      Alisa, you are right. Drone regulation is a critical topic. There are country specific limits on professional and hobby use of flying drones. Aviation regulation should be developed further to support use of drones for public safety.

      Delete
  3. UnknownMarch 30, 2017 at 5:59 PM

    Wow, this is an amazing and creative idea. I have known robots to have a lot of application in the industries and research institutions but I did not know they can also be used to provide safety to human beings especially during unplanned incidences such as a fire outbreak. Thanks for sharing this information with us. Check out my article by clicking on The Benefits of Using a Professional Editing Service.

    ReplyDelete

Post a Comment

Popular posts from this blog

Mission Critical Push To Talk and EPS bearers

Image
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 LT
Read more

APNs in MCPTT smartphone

Image
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
Read more

Public Safety prioritization

Image
LTE QoS and prioritization for mission critical communication Public safety (PS) users have the most stringent requirements for network & service accessibility and service quality. Various mechanisms can be used to fulfill these requirements in different network conditions. Those mechanisms must be able to differentiate both users and applications based on certain priorities.  PS users can have different priority levels, which can also change dynamically. For example paramedic engaged in emergency mission has a higher priority than policemen on a lunch break. LTE networks can be shared serving both PS users and commercial subscriber with same resources (e.g. same carriers), in which case there is also a need to prioritize PS users over regular subscribers. Key reason for adopting LTE for mission critical communication is of course broadband capability for data applications. At the same time LTE certainly supports also voice calls (both group calls & one-to-one calls)
Read more