Operational data logging by an aerial communicaiton device

By configuring aerial communication devices to log operational data during flight path changes, the solution addresses the inadequacy of existing MDT solutions for aerial devices, enabling effective self-organizing network tasks and improved network performance.

WO2025065468A1PCT designated stage expired Publication Date: 2025-04-03TELEFONAKTIEBOLAGET LM ERICSSON (PUBL) +1
View PDF 3 Cites 0 Cited by

Patent Information

Application Number
PCT/CN2023/122438
Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Filing Date
2023-09-28
Publication Date
2025-04-03

AI Technical Summary

Technical Problem

Existing Minimization of Drive Test (MDT) solutions for wireless communication networks are not suitable for aerial communication devices due to their distinct mobility profile, which includes higher altitudes and speeds.

Method used

An aerial communication device is configured to log operational data when its targeted flight path changes to or from a planned flight path, using specific logging trigger conditions such as path change, speed change, and altitude change, to facilitate self-organizing network tasks.

Benefits of technology

This approach allows for the collection of aerial-specific operational data that can be used by the communication network to perform self-organizing tasks, such as configuring radio resources and optimizing flight paths to avoid contingencies.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN2023122438_03042025_PF_FP_ABST
    Figure CN2023122438_03042025_PF_FP_ABST
Patent Text Reader

Abstract

An aerial communication device (10) detects that each of one or more logging trigger conditions (20C) in a log trigger set (20) are met. The one or more logging trigger conditions (20C) include a path change condition that is met upon a targeted flight path (16T) of the aerial communication device (10) changing to or from a planned flight path (16P). Based on detecting that each of the one or more logging trigger conditions (20C) in the log trigger set (20) are met, the aerial communication device (10) logs aerial-specific operational data (18) at the aerial communication device (10) describing aerial operation of the aerial communication device (10).
Need to check novelty before this filing date? Find Prior Art

Description

OPERATIONAL DATA LOGGING BY AN AERIAL COMMUNICAITON DEVICETECHNICAL FIELD

[0001] The present application relates generally to an aerial communication device, and relates more specifically to logging of operational data by the aerial communication device.BACKGROUND

[0002] Traditionally, a wireless communication network operator conducted drive tests dedicated to collecting radio measurements for self-organizing network (SON) tasks, such as network planning, network optimization, network parameter tuning, and / or positioning (e.g., RF pattern matching based positioning) . Using drive tests for SON thereby proved costly and burdensome.

[0003] So-called minimization of drive test (MDT) measurements minimize the drive tests that a communication network operator must conduct for SON tasks. MDT in this regard exploits subscribers’ own communication devices for performing the radio measurements, relieving the need for the operator to itself conduct drive tests. The MDT measurements may for example include radio measurements and location measurements, usable for analyzing radio coverage and performance in different locations.

[0004] A communication device can perform MDT measurements even when the communication device does not have an established connection with the network, e.g., when the communication device is in a radio resource control (RRC) idle or inactive state. In this case, the communication device can log the MDT measurements at the device, e.g., storable for up to 48 hours. The communication device can then report the logged MDT measurements later on once the communication device has an established connection with the network, e.g., once the communication device transitions to an RRC connected state.

[0005] Existing MDT solutions are however tailored to the mobility profile of mobile broadband (MBB) communication devices. Because aerial communication devices have a different mobility profile, e.g., higher altitude and / or speed, re-using existing MDT solutions to perform SON tasks targeting aerial communication devices proves unsuitable. A need therefore exists for MDT solutions that are appropriate for performing SON tasks for aerial communication devices.SUMMARY

[0006] Some embodiments herein exploit the changing of an aerial communication device’s targeted flight path to or from a planned flight path as a useful opportunity for the aerial communication device to log operational data, e.g., as minimization of drive test (MDT) data, for immediate or delayed reporting to a communication network. Operational data logged in association with the targeted flight path changing may be aerial-specific and for example include data indicating the planned flight path, data indicating a flight path to or from which the targeted  flight path was changed, data indicating a reason for the targeted flight path changing to or from the planned flight path, and / or data indicating a time and / or location of the aerial communication device when the targeted flight path was. These and / or other types of operational data may prove particularly useful for the communication network to perform one or more self-organizing network (SON) tasks based on the reported operational data, e.g., as needed to avoid, reduce the impact of, adapt to, or accommodate for the offending contingency in the future, for the same or a different aerial communication device. As one example, armed with such operational data, the communication network may advantageously configure or reserve sufficient radio resource (e.g., larger bandwidth, higher output power, beamforming, additional carriers, etc. ) in base stations deployed in area (s) where aerial communication devices tend to have to change their targeted flight plan away from a planned flight plan. As another example, the communication network may use logged operational data to advantageously configure the same or different aerial communication devices with a flight path which avoids locations in which flight path changing contingencies tend to occur.

[0007] More particularly, embodiments herein include a method performed by an aerial communication device. The method comprises detecting that each of one or more logging trigger conditions in a log trigger set are met. In some embodiments, the one or more logging trigger conditions include a path change condition that is met upon a targeted flight path of the aerial communication device changing to or from a planned flight path. In some embodiments, the planned flight path is a path of flight that the aerial communication device plans to follow absent occurrence of a contingency. The method also comprises, based on detecting that each of the one or more logging trigger conditions in the log trigger set are met, logging aerial-specific operational data at the aerial communication device describing aerial operation of the aerial communication device.

[0008] In some embodiments, the path change condition is met upon the targeted flight path of the aerial communication device changing from the planned flight back to a backup flight path. In some embodiments, the backup flight path is a path of flight that the aerial communication device reverts to upon occurrence of a contingency. In some embodiments, the planned flight path is planned before initiation of the aerial communication device along the planned flight path, and the backup flight path is dynamically determined upon occurrence of a contingency.

[0009] In some embodiments, the planned flight path is a path of flight that the aerial communication device plans to follow absent occurrence of a contingency deemed by the aerial communication device as a critical or emergency contingency. In some embodiments, a critical or emergency contingency includes at least inability of the aerial communication device to fly. In other embodiments, a critical or emergency contingency includes at least inability of the aerial communication device to fly along the planned flight path. In yet other embodiments, a critical or emergency contingency includes at least an emergency landing of the aerial communication device. In still yet other embodiments, a critical or emergency contingency includes at least  malfunctioning of the aerial communication device. In still yet other embodiments, a critical or emergency contingency includes at least a battery level of the aerial communication device falling below a minimum threshold. In still yet other embodiments, a critical or emergency contingency includes at least a fuel level of the aerial communication device falling below a minimum threshold. In still yet other embodiments, a critical or emergency contingency includes at least actual or expected collision with an object.

[0010] In some embodiments, the aerial-specific operational data includes data indicating the planned flight path. In some embodiments, the aerial-specific operational data includes data indicating a flight path to or from which the targeted flight path was changed.

[0011] In some embodiments, the aerial-specific operational data includes data indicating a reason for the targeted flight path changing to or from the planned flight path. In other embodiments, the aerial-specific operational data alternatively or additionally includes data indicating a time and / or location of the aerial communication device when the targeted flight path was changed to or from the planned flight path. In yet other embodiments, the aerial-specific operational data alternatively or additionally includes data describing an aerial-specific maneuver detected by the aerial communication device upon detecting that each of the one or more logging trigger conditions are met. In still yet other embodiments, the aerial-specific operational data alternatively or additionally includes data describing an aerial mobility state of the aerial communication device. In some embodiments, the aerial mobility state includes one or more of a speed, acceleration, direction of movement, or altitude of the aerial communication device.

[0012] In some embodiments, the one or more logging trigger conditions in the log trigger set further include at least a speed change condition that is met upon a speed of the aerial communication device changing by more than a speed change threshold. In other embodiments, the one or more logging trigger conditions in the log trigger set further alternatively or additionally include at least a direction change condition that is met upon a direction of movement of the aerial communication device changing by more than a direction change threshold. In yet other embodiments, the one or more logging trigger conditions in the log trigger set further alternatively or additionally include at least an altitude change condition that is met upon an altitude of the aerial communication device changing by more than an altitude change threshold. In still yet other embodiments, the one or more logging trigger conditions in the log trigger set further alternatively or additionally include at least a maneuver condition that is met upon the aerial communication device performing one or more types of aerial maneuvers. In still yet other embodiments, the one or more logging trigger conditions in the log trigger set further alternatively or additionally include a location change condition that is met upon a location of the aerial communication device changing by more than a location change threshold. In still yet other embodiments, the one or more logging trigger conditions in the log trigger set further alternatively or additionally include a time condition that is met upon a  measured or estimated time at the aerial communication device exceeding a time threshold or exceeding a sum of the time threshold and a defined duration. In still yet other embodiments, the one or more logging trigger conditions in the log trigger set further alternatively or additionally include a waypoint condition that is met upon the aerial communication device reaching a defined waypoint in the planned flight path. In still yet other embodiments, the one or more logging trigger conditions in the log trigger set further alternatively or additionally include a received signal level (RSL) condition that is met upon a magnitude of a RSL of the aerial communication device changing by more than a RSL change threshold.

[0013] In some embodiments, logging the aerial-specific operational data at the aerial communication device comprises logging aerial-specific operational data at the aerial communication device on an ongoing or periodic basis. In some embodiments, the method further comprises, after starting to log the aerial-specific operational data at the aerial communication device, detecting that each of one or more logging stop conditions in a log stop set are met. In some embodiments, the method further comprises, after starting to log the aerial-specific operational data at the aerial communication device, based on detecting that each of one or more logging stop conditions in the log stop set are met, stopping logging the aerial-specific operational data at the aerial communication device. In some embodiments,

[0014] In some embodiments, each of the one or more logging stop conditions in the log stop set is met if none of the one or more logging trigger conditions in the log trigger set are met. In some embodiments, the one or more logging stop conditions in the log stop set include at least a path revert condition that is met upon the aerial communication device reverting to the planned flight path. In other embodiments, the one or more logging stop conditions in the log stop set alternatively or additionally include at least a timer condition that is met upon expiry of a timer started by the aerial communication device upon starting logging of the aerial-specific operational data. In yet other embodiments, the one or more logging stop conditions in the log stop set alternatively or additionally include at least a stable state condition that is met when a flight path, altitude, location, and / or speed of the aerial communication device has remained stable for a threshold duration of time. In still yet other embodiments, the one or more logging stop conditions in the log stop set alternatively or additionally include at least a maneuver absence condition that is met when the aerial communication device has not detected any of one or more types of aerial-specific maneuvers having been performed for a threshold duration of time. In still yet other embodiments, the one or more logging stop conditions in the log stop set alternatively or additionally include at least a stable received signal level (RSL) condition that is met upon a magnitude of a RSL of the aerial communication device not changing by more than a RSL change threshold.

[0015] In some embodiments, the method further comprises receiving a configuration message from a network node requesting the aerial communication device to log the aerial-specific operational data upon detecting the one or more logging trigger conditions in the log trigger set  and / or to stop logging the aerial-specific operational data upon detecting one or more logging stop conditions in a log stop set.

[0016] In some embodiments, the aerial-specific operational data is logged as Minimization of Drive Test, MDT, data.

[0017] In some embodiments, the method further comprises reporting the logged aerial-specific operational data to a network node.

[0018] Other embodiments herein include a method performed by a network node. The method comprises receiving, from an aerial communication device, aerial-specific operational data logged at the aerial communication device in association with each of one or more logging trigger conditions in a log trigger set being met. In some embodiments, the one or more logging trigger conditions include a path change condition that is met upon a targeted flight path of the aerial communication device changing to or from a planned flight path. In some embodiments, the planned flight path is a path of flight that the aerial communication device plans to follow absent occurrence of a contingency. In some embodiments, the aerial-specific operational data describes aerial operation of the aerial communication device.

[0019] In some embodiments, the path change condition is met upon the targeted flight path of the aerial communication device changing from the planned flight back to a backup flight path. In some embodiments, the backup flight path is a path of flight that the aerial communication device reverts to upon occurrence of a contingency. In some embodiments, the planned flight path is planned before initiation of the aerial communication device along the planned flight path, and the backup flight path is dynamically determined upon occurrence of a contingency.

[0020] In some embodiments, the planned flight path is a path of flight that the aerial communication device plans to follow absent occurrence of a contingency deemed by the aerial communication device as a critical or emergency contingency. In some embodiments, a critical or emergency contingency includes at least inability of the aerial communication device to fly. In other embodiments, a critical or emergency contingency includes at least inability of the aerial communication device to fly along the planned flight path. In yet other embodiments, a critical or emergency contingency includes at least an emergency landing of the aerial communication device. In still yet other embodiments, a critical or emergency contingency includes at least malfunctioning of the aerial communication device. In still yet other embodiments, a critical or emergency contingency includes at least a battery level of the aerial communication device falling below a minimum threshold. In still yet other embodiments, a critical or emergency contingency includes at least a fuel level of the aerial communication device falling below a minimum threshold. In still yet other embodiments, a critical or emergency contingency includes at least actual or expected collision with an object.

[0021] In some embodiments, the aerial-specific operational data includes data indicating the planned flight path. In some embodiments, the aerial-specific operational data includes data indicating a flight path to or from which the targeted flight path was changed.

[0022] In some embodiments, the aerial-specific operational data includes data indicating a reason for the targeted flight path changing to or from the planned flight path. In other embodiments, the aerial-specific operational data alternatively or additionally includes data indicating a time and / or location of the aerial communication device when the targeted flight path was changed to or from the planned flight path. In yet other embodiments, the aerial-specific operational data alternatively or additionally includes data describing an aerial-specific maneuver detected by the aerial communication device upon detecting that each of the one or more logging trigger conditions are met. In still yet other embodiments, the aerial-specific operational data alternatively or additionally includes data describing an aerial mobility state of the aerial communication device. In some embodiments, the aerial mobility state includes one or more of a speed, acceleration, direction of movement, or altitude of the aerial communication device.

[0023] In some embodiments, the one or more logging trigger conditions in the log trigger set further include at least a speed change condition that is met upon a speed of the aerial communication device changing by more than a speed change threshold. In other embodiments, the one or more logging trigger conditions in the log trigger set further alternatively or additionally include at least a direction change condition that is met upon a direction of movement of the aerial communication device changing by more than a direction change threshold. In yet other embodiments, the one or more logging trigger conditions in the log trigger set further alternatively or additionally include at least an altitude change condition that is met upon an altitude of the aerial communication device changing by more than an altitude change threshold. In still yet other embodiments, the one or more logging trigger conditions in the log trigger set further alternatively or additionally include at least a maneuver condition that is met upon the aerial communication device performing one or more types of aerial maneuvers. In still yet other embodiments, the one or more logging trigger conditions in the log trigger set further alternatively or additionally include at least a location change condition that is met upon a location of the aerial communication device changing by more than a location change threshold. In still yet other embodiments, the one or more logging trigger conditions in the log trigger set further alternatively or additionally include at least a time condition that is met upon a measured or estimated time at the aerial communication device exceeding a time threshold or exceeding a sum of the time threshold and a defined duration. In still yet other embodiments, the one or more logging trigger conditions in the log trigger set further alternatively or additionally include at least a waypoint condition that is met upon the aerial communication device reaching a defined waypoint in the planned flight path. In still yet other embodiments, the one or more logging trigger conditions in the log trigger set further alternatively or additionally include at least a received signal level (RSL) condition that is met upon a magnitude of a RSL of the aerial communication device changing by more than a RSL change threshold.

[0024] In some embodiments, receiving the aerial-specific operational data comprises receiving a log including the aerial-specific operational data. In some embodiments, the log includes aerial-specific operational data logged on an ongoing or periodic basis until each of one or more logging stop conditions in a log stop set are met. In some embodiments, each of the one or more logging stop conditions in the log stop set is met if none of the one or more logging trigger conditions in the log trigger set are met. In some embodiments, the one or more logging stop conditions in the log stop set include at least a path revert condition that is met upon the aerial communication device reverting to the planned flight path. In other embodiments, the one or more logging stop conditions in the log stop set alternatively or additionally include at least a timer condition that is met upon expiry of a timer started by the aerial communication device upon starting logging of the aerial-specific operational data. In yet other embodiments, the one or more logging stop conditions in the log stop set alternatively or additionally include at least a stable state condition that is met when a flight path, altitude, location, and / or speed of the aerial communication device has remained stable for a threshold duration of time. In still yet other embodiments, the one or more logging stop conditions in the log stop set alternatively or additionally include at least a maneuver absence condition that is met when the aerial communication device has not detected any of one or more types of aerial-specific maneuvers having been performed for a threshold duration of time. In still yet other embodiments, the one or more logging stop conditions in the log stop set alternatively or additionally include at least a stable received signal level (RSL) condition that is met upon a magnitude of a RSL of the aerial communication device not changing by more than a RSL change threshold.

[0025] In some embodiments, the aerial-specific operational data is logged as Minimization of Drive Test, MDT, data.

[0026] In some embodiments, the method further comprises performing one or more self-organizing network, SON, tasks based on the aerial-specific operational data.

[0027] In some embodiments, the method further comprises configuring the aerial communication device to log the aerial-specific operational data upon detecting the one or more logging trigger conditions and / or to stop logging the aerial-specific operational data upon detecting one or more logging stop conditions.

[0028] Other embodiments herein include an aerial communication device. The aerial communication device is configured to detect that each of one or more logging trigger conditions in a log trigger set are met. In some embodiments, the one or more logging trigger conditions include a path change condition that is met upon a targeted flight path of the aerial communication device changing to or from a planned flight path. In some embodiments, the planned flight path is a path of flight that the aerial communication device plans to follow absent occurrence of a contingency. The aerial communication device is also configured to, based on detecting that each of the one or more logging trigger conditions in the log trigger set are met,  log aerial-specific operational data at the aerial communication device describing aerial operation of the aerial communication device.

[0029] In some embodiments, the aerial communication device is configured to perform the steps described above for an aerial communication device.

[0030] Other embodiments herein include a network node. The network node is configured to receive, from an aerial communication device, aerial-specific operational data logged at the aerial communication device in association with each of one or more logging trigger conditions in a log trigger set being met. In some embodiments, the one or more logging trigger conditions include a path change condition that is met upon a targeted flight path of the aerial communication device changing to or from a planned flight path, wherein the planned flight path is a path of flight that the aerial communication device plans to follow absent occurrence of a contingency. In some embodiments, the aerial-specific operational data describes aerial operation of the aerial communication device.

[0031] In some embodiments, the network node is configured to perform the steps described above for a network node.

[0032] In some embodiments, a computer program comprises instructions which, when executed on at least one processor of an aerial communication device, cause the aerial communication device to perform the steps described above for an aerial communication device.

[0033] In some embodiments, a computer program comprises instructions which, when executed on at least one processor of a network node, cause the network node to perform the steps described above for a network node.

[0034] Other embodiments herein include an aerial communication device. The aerial communication device comprises communication circuitry and processing circuitry. The processing circuitry is configured to detect that each of one or more logging trigger conditions in a log trigger set are met. In some embodiments, the one or more logging trigger conditions include a path change condition that is met upon a targeted flight path of the aerial communication device changing to or from a planned flight path. In some embodiments, the planned flight path is a path of flight that the aerial communication device plans to follow absent occurrence of a contingency. The processing circuitry is also configured to, based on detecting that each of the one or more logging trigger conditions in the log trigger set are met, log aerial-specific operational data at the aerial communication device describing aerial operation of the aerial communication device.

[0035] In some embodiments, the processing circuitry is configured to perform the steps described above for an aerial communication device.

[0036] Other embodiments herein include a network node. The network node comprises communication circuitry and processing circuitry. The processing circuitry is configured to receive, from an aerial communication device, aerial-specific operational data logged at the  aerial communication device in association with each of one or more logging trigger conditions in a log trigger set being met. In some embodiments, the one or more logging trigger conditions include a path change condition that is met upon a targeted flight path of the aerial communication device changing to or from a planned flight path. In some embodiments, the planned flight path is a path of flight that the aerial communication device plans to follow absent occurrence of a contingency. In some embodiments, the aerial-specific operational data describes aerial operation of the aerial communication device.

[0037] In some embodiments, the processing circuitry is configured to perform the steps described above for a network node.

[0038] Of course, the present disclosure is not limited to the above features and advantages. Indeed, those skilled in the art will recognize additional features and advantages upon reading the following detailed description, and upon viewing the accompanying drawings.BRIEF DESCRIPTION OF THE DRAWINGS

[0039] Figure 1 is a block diagram of a communication network according to some embodiments.

[0040] Figure 2 is a block diagram of the network reconfiguring measurement reporting configurations for the UE when it crosses a height threshold according to some embodiments.

[0041] Figure 3 is a block diagram of an Unmanned Aircraft Systems (UAS) Traffic Management (UTM) according to some embodiments.

[0042] Figure 4 is a block diagram of minimization of drive test (MDT) logging conditions according to some embodiments.

[0043] Figure 5 is a logic flow diagram of a method performed by an aerial communication device according to some embodiments.

[0044] Figure 6 is a logic flow diagram of a method performed by a network node according to some embodiments.

[0045] Figure 7 is a block diagram of an aerial communication device according to some embodiments.

[0046] Figure 8 is a block diagram of a network node according to some embodiments.

[0047] Figure 9 is a block diagram of a communication system in accordance with some embodiments.

[0048] Figure 10 is a block diagram of a user equipment according to some embodiments.

[0049] Figure 11 is a block diagram of a network node according to some embodiments.

[0050] Figure 12 is a block diagram of a host according to some embodiments.

[0051] Figure 13 is a block diagram of a virtualization environment according to some embodiments.

[0052] Figure 14 is a block diagram of a host communicating via a network node with a UE over a partially wireless connection in accordance with some embodiments.DETAILED DESCRIPTION

[0053] Figure 1 shows an aerial communication device 10 according to some embodiments. The aerial communication device 10 is a communication device equipped, housed, or located in a flying object which flies in air or free space. The aerial communication device 10 may for example be an unmanned aerial vehicle (UAV) , a drone, or an air-to-ground (ATG) vehicle. The aerial communication device 10 is equipped with communication circuitry (not shown) for communicating with a communication network 12 during, before, and / or after flight. The communication network 12 in this regard includes network nodes 14, e.g., base stations, that provide access to the communication network 12 over different respective areas of coverage. The aerial communication device 10 may communicate with the communication network 12 in order to transmit data (e.g., photographic data) to the communication network 12 and / or to receive flight assistance data that commands, controls, or otherwise assists with the aerial communication device’s flight.

[0054] With or without assistance from the communication network 12, though, the aerial communication device 10 as shown includes a flight controller 10F that controls the aerial communication device’s flight. Under some circumstances, the flight controller 10F controls the aerial communication device’s flight in an attempt to have the aerial communication device 10 follow a certain path of flight referred to as the targeted flight path 16T. The targeted flight path 16T is therefore the path of flight that the flight controller 10F targets to follow at any given time. The targeted flight path 16T may be represented as an ordered series of waypoints to be targeted by the aerial communication device 10, e.g., where each waypoint is defined by a pair of longitude and latitude coordinates coupled with an altitude. In an attempt to have the aerial communication device 10 follow the targeted flight path 16T, the flight controller 10F may adjust the roll, pitch, yaw, altitude, and / or speed of the aerial communication device 10 as needed to keep the aerial communication device 10 on the targeted flight path 16T, or at least as close as practically possible given flight conditions, e.g., as needed to minimize any discrepancy between the targeted flight path 16T and the aerial communication device’s actual flight path.

[0055] The aerial communication device 10 in Figure 1 also includes a path controller 10P that controls what flight path the aerial communication device 10 targets to follow. The path controller 10P may for example select the targeted flight path 16T from among one or more flight paths 16 defined as candidates for selection, e.g., with each candidate flight path 16 being represented as a respective set of ordered waypoints. Different candidate flight path (s) 16 may be appropriate for selection under different circumstances and / or for different missions. In some embodiments, one or more of these candidate flight path (s) 16 may be predefined and stored in memory 10M. Alternatively or additionally, one or more of the candidate flight path (s) 16 may be dynamically generated by the path controller 10P.

[0056] According to embodiments herein, at least one of the candidate flight path (s) 16 is a planned flight path 16P. A planned flight path 16P is a flight path that has been planned for the  aerial communication device 10 to follow. In some embodiments, for example, a planned flight path 16P is planned to advance the purpose of the aerial communication device’s flight. For instance, the purpose of flight may to accomplish a desired task or objective, e.g., transporting goods from one location to another, conducting surveillance over a certain area, and / or capturing photographs and / or video along the planned flight path 16P. In this case, a planned flight path 16P is a flight path planned for the aerial communication device 10 to follow in order to accomplish the desired task or objective. The planned flight path 16P may thereby be the desired or preferred flight path 16P.

[0057] In the example of Figure 1, the plan is for the aerial communication device 10 to start (e.g., take off) at a starting point 16P-1, fly through a series of waypoints 16P-2 through 16P- (N-1) , and arrive (e.g., land) at a destination point 16P-N. The planned flight path 16P in this case may thereby be discretely represented by N points, including the starting point 16P-1, the intermediate waypoints 16P-2 through 16P- (N-1) , and the destination point 16P-N, ordered in series according to the times at which the aerial communication device 10 is to traverse the points. If things go according to plan, following the planned flight path 16P advances the purpose of the aerial communication device’s flight, e.g., delivery of goods from the starting point 16P-1 to the destination point 16P-N.

[0058] Embodiments herein nonetheless recognize that things do not always go according to plan. Any number of contingencies may occur which would frustrate the aerial communication device’s flight, threaten the purpose of the flight, and / or otherwise undesirably jeopardize a planned flight path 16P. Such contingencies may for example include another object threatening collision with the aerial communication device 10, weather conditions upsetting the ability of the aerial communication device 10 to maintain its flight path and / or altitude, a shortage of fuel or equipment malfunctioning threatening the ability of the aerial communication device 10 to reach the destination point, an actual collision of the aerial communication device 10 with one or more objects damaging the aerial communication device 10, etc.

[0059] In the undesirable event that a contingency occurs, the aerial communication device 10 may be forced or otherwise configured to change its targeted flight path 16T away from the planned flight path 16P. This change away from the planned flight path 16P may be premature in that it occurs even before arrival at the destination point of the planned flight path 16P.

[0060] Some types of contingencies, such as a mere threatened collision with another object, may warrant the aerial communication device 10 changing its targeted flight path 16T away from the planned flight path 16P on just a temporary basis, with the possibility to revert back to the planned flight path 16P after addressing the contingency. Figure 1 for example shows that the aerial communication device 10 may change its targeted flight path 16T from the planned flight path 16P to a bypass flight path 16B upon the occurrence of a contingency involving an airplane threatening collision with the aerial communication device 10. After having bypassed the potential collision by following the bypass flight path 16B, the aerial communication device  10 may revert back to its planned flight path 16P. The bypass flight path 16B therefore effectively operates as a backup flight path, for the aerial communication device 10 to revert to as needed upon the occurrence of a contingency.

[0061] Other types of contingencies, though, such as low fuel, depleted battery, equipment malfunctioning, an actual collision, or some other type of critical or emergency contingency, may force the aerial communication device 10 to altogether abort any purpose or mission associated with the planned flight path 16P, and thereby change its targeted flight path 16T away from the planned flight path 16P on more than just a temporary basis. In the example of Figure 1, for instance, the aerial communication device 10 changes its targeted flight path 16T from the planned flight path 16P to an emergency flight path 16E upon the occurrence of a contingency involving low fuel. In this case, the planned flight path 16P is aborted altogether, with no possibility to revert back to the planned flight path 16P due to the nature of the contingency. Indeed, the aerial communication device 10 may revert to the emergency flight path 16E in order to perform an emergency landing. Generally, then, some types of contingencies may be deemed by the aerial communication device 10 as a critical or emergency contingency. Critical or emergency contingencies may for instance include inability of the aerial communication device 10 to fly, inability of the aerial communication device 10 to fly along the planned flight path 16P, an emergency landing of the aerial communication device 10, malfunctioning of the aerial communication device 10, a battery level of the aerial communication device 10 falling below a minimum threshold, a fuel level of the aerial communication device 10 falling below a minimum threshold, or the actual or expected collision with an object. Regardless of the particular type of critical or emergency contingency, the emergency flight path 16E again operates as a backup flight path, for the aerial communication device 10 to revert to as needed upon the occurrence of a critical or emergency contingency.

[0062] At least for some types of contingencies, then, a backup flight path may not advance the purpose, objective, or mission of the planned flight path 16P. In fact, the backup flight path in some embodiments may delay such purpose, objective, or mission, or may only be reverted to upon the aerial communication device 10 aborting such purpose, objective, or mission. Either way, a backup flight path in some embodiments differs from a planned flight path 16P in the sense that a backup flight path may be dynamically determined or generated upon the occurrence of a contingency during flight of the aerial communication device 10 on a planned flight path 16P. By contrast, a planned flight path 16P in some embodiments is planned before initiation of the aerial communication device 10 along the planned flight path 16P. Note, though, that in other embodiments a backup flight path may be determined in advance as well, e.g., it may be predetermined how the aerial communication device 10 is to maneuver in order to avoid a collision, in terms of one or more predetermined manuevers. In this case, then, a planned flight path 16P and a backup flight path may both be determined in advance of flight on the  planned flight path 16P, but the backup flight path does not further the purpose of the planned flight path 16P and is only reverted to upon the occurrence of a contingency.

[0063] In this context, some embodiments herein exploit the changing of the aerial communication device’s targeted flight path 16T to or from a planned flight path 16P as a useful opportunity for the aerial communication device 10 to log operational data 18, e.g., as minimization of drive test (MDT) data, for immediate or delayed reporting to the communication network 12. Operational data 18 logged in association with the targeted flight path 16T changing to or from a planned flight path 16P may be aerial-specific and for example include data indicating the planned flight path 16P, data indicating a flight path to or from which the targeted flight path 16T was changed, data indicating a reason for the targeted flight path 16T changing to or from the planned flight path 16P, and / or data indicating a time and / or location of the aerial communication device 10 when the targeted flight path 16T was changed to or from the planned flight path 16P. Alternatively or additionally, the operational data 18 may include data describing an aerial-specific maneuver detected by the aerial communication device 10 and / or data describing an aerial mobility state of the aerial communication device, 10, e.g., a speed, acceleration, direction of movement, or altitude of the aerial communication device 10. These and / or other types of operational data 18 may prove particularly useful for the communication network 12 to perform one or more self-organizing network (SON) tasks based on the reported operational data 18, e.g., as needed to avoid, reduce the impact of, adapt to, or accommodate for the offending contingency in the future, for the same or a different aerial communication device. As one example, armed with such operational data 18, the communication network 12 may advantageously configure or reserve sufficient radio resource (e.g., larger bandwidth, higher output power, beamforming, additional carriers, etc. ) in base stations deployed in area (s) where aerial communication devices have or tend to have to change their targeted flight plan 16T away from a planned flight plan 16P. In another example, the communication network 12 may apply a transmission scheme that ensures stable operation in these area (s) , to better safeguard against the aerial communicaiton devices having to change their targeted flight path away from their planned flight path. As another example, the communication network 12 may use logged operational data 18 to advantageously configure the same or different aerial communication devices with a flight path which avoids locations in which flight path changing contingencies tend to occur.

[0064] Figure 1 more particularly shows that the aerial communication device 10 includes a log controller 10C. The log controller 10C controls logging of operational data 18 to a log 10L, e.g., where the log 10L may take the form of a data file, database, or other data structure. The log controller 10C may control when to write operational data 18 to the log 10L and / or what operational data 18 to write to the log 10L. In order to control when to write operational data 18 to the log 10L, the log controller 10C in Figure 1 monitors one or more log trigger sets 20. Each log trigger set 20 includes one or more logging trigger conditions. If each of the logging trigger  conditions in a log trigger set 20 is met, that log trigger set 20 triggers the log controller 10C to log operational data 18 to the log 10L. Accordingly, for each log trigger set 20, the log controller 10C monitors for whether each of the logging trigger condition (s) in that log trigger set 20 are met. Based on detecting that each of the logging trigger condition (s) in a log trigger set 20 are met, the log controller 10C logs operational data 18 to the log 10C.

[0065] According to some embodiments herein, the logging trigger condition (s) in at least one of the log trigger set (s) 20 include a so-called path change condition. The path change condition is met upon the targeted flight path 16T of the aerial communication device 10 changing to or from a planned flight path 16P. More particularly, in one embodiment, the path change condition is met upon the targeted flight path 16T of the aerial communication device 10 changing to a planned flight path 16P. Alternatively or additionally, the path change condition in other embodiments is met upon the targeted flight path 16T of the aerial communication device 10 changing from a planned flight path 16P, e.g., to a backup flight path. In yet other embodiments, the path change condition is met upon the targeted flight path 16T changing to a planned flight path 16P or upon the targeted flight path 16T changing from a planned flight path 16P.

[0066] In order to detect the path change condition being met, then, the path controller 10P as shown in Figure 1 provides the targeted flight path 16T to not only the flight controller 10F but also the log controller 10C. In one embodiment, this signaling from the path controller 10P indicates whether the targeted flight path 16T has changed to or from a planned flight path 16P. In other embodiments, by contrast, the log controller 10C also receives as input information about the candidate path (s) 16, so that the log controller 10C can use that information to determine whether the targeted flight path 16T has changed to or from a planned flight path 16P.

[0067] Note that the targeted flight path 16T changing means that the flight path that the aerial communication device 10 is targeting to follow has changed. The targeted flight path 16T changing therefore is different than the actual flight path of the aerial communication device 10 potentially deviating from a targeted or planned flight path, e.g., as may practically occur due to weather conditions or positioning inaccuracies.

[0068] In some embodiments, the path change condition is the only logging trigger condition in at least one of the log trigger set (s) 20. In this case, then, detection by the log controller 10C that the targeted flight path 16T has changed to or from a planned flight path 16P triggers the aerial communication device 10 to log operational data 18 to the log 10L.

[0069] In other embodiments, the path change condition is one of multiple logging trigger conditions in at least one of the log trigger set (s) 20. This means that the path change condition being met is a necessary but not sufficient condition for triggering the aerial communication device 10 to log operational data 18 to the log 10L. As one example, a log trigger set 20 may include not only the path change condition but also an altitude change condition that is met upon an altitude of the aerial communication device 10 changing by more than an altitude  change threshold. In this example, then, logging targets the scenario where the targeted flight path 16T has changed to or from a planned flight path in conjunction with a meaningful altitude change, e.g., as may occur in a critical or emergency contingency. Alternatively or additionally, the log trigger set 20 may include a speed change condition that is met upon a speed of the aerial communication device 10 changing by more than a speed change threshold, a direction change condition that is met upon a direction of movement of the aerial communication device 10 changing by more than a direction change threshold, and / or a maneuver condition that is met upon the aerial communication device 10 performing one or more types of aerial maneuvers, e.g., evasive maneuvers consistent with the aerial communication device 10 having to avoid a collision. As yet other examples, the log trigger set 20 may alternatively or additionally include a location change condition that is met upon a location of the aerial communication device 10 changing by more than a location change threshold, a time condition that is met upon a measured or estimated time at the aerial communication device 10 exceeding a time threshold or exceeding a sum of the time threshold and a defined duration, and / or a waypoint condition that is met upon the aerial communication device 10 reaching a defined waypoint in the planned flight path 16P. Such changes may for instance be consistent with meaningful deviations from the planned flight path 16P. In still other examples, the log trigger set 20 may alternatively or additionally include a received signal level (RSL) condition that is met upon a magnitude of a RSL of the aerial communication device 10 changing by more than a RSL change threshold. Here, RSL may for instance be a reference signal received power (RSRP) or a reference signal received quality (RSRQ) . The RSL condition in such case may for instance selectively capture operational data 18 for flight path changes that suffer from undesirable RSL, e.g., to support the communication network 12 performing SON task (s) to improve such RSL.

[0070] No matter whether any other condition (s) combine with the path change condition to trigger operational data logging, the aerial communication device 10 in some embodiments logs the operational data 18 as a single snapshot of the operational data 18 at the time the logging trigger condition (s) are met. In other embodiments shown in Figure 1, though, the logging trigger condition (s) being met triggers the aerial communication device 10 to log operational data 18 an ongoing or periodic basis until each of one or more logging stop conditions in a log stop set 22 are met, e.g., where one or more log stop sets 22 may be defined, any of which may prompt the log controller 10C to stop logging operational data 18. In this case, after starting to log operational data 18 at the aerial communication device 10, the log controller 10C may detect that each of one or more logging stop conditions in a log stop set 22 are met. Based on detecting that each of the one or more logging stop conditions in the log stop set 22 are met, the log controller 10C stops logging the operational data 18 at the aerial communication device 10.

[0071] In some embodiments, each of the logging stop condition (s) in at least one of the log stop set (s) 22 is met if none of the logging trigger condition (s) in a log trigger set 20 are met. In  these embodiments, then, the log controller 10C logs operational data 18, on an ongoing or periodic basis, while each of the logging trigger condition (s) in a log trigger set 20 are met. In one such embodiment, the logging stop condition (s) are defined explicitly to realize this. For example, the logging stop condition (s) in a log stop set 22 may include a path revert condition that is met upon the aerial communication device 10 reverting to the planned flight path 16P. In another embodiment, though, the logging stop condition (s) are only implicitly defined as the converse of the logging trigger condition (s) .

[0072] In other embodiments, though, the condition (s) that prompt the log controller 10C to stop logging operational data 18 are different than the condition (s) that prompt the log controller 10C to start logging operational data 18, e.g., in the sense that they are not even simply the converse of the logging trigger condition (s) 20. For example, in one embodiment, the logging stop condition (s) in a log stop set 22 include a timer condition that is met upon expiry of a timer started by the aerial communication device 10 upon starting logging of the operational data 18. In this case, then, the aerial communication device 10 logs operational data 18 for the duration of the timer, e.g., so as to capture operational data 18 relevant to the times at which the targeted flight path 16T changes.

[0073] In other embodiments, the logging stop condition (s) in a log stop set 22 alternatively or additionally include a stable state condition that is met when a flight path, altitude, location, and / or speed of the aerial communication device 10 has remained stable for a threshold duration of time. Similarly, in yet other embodiments, the logging stop condition (s) in a log stop set 22 may alternatively or additionally include a maneuver absence condition that is met when the aerial communication device 10 has not detected any of one or more types of aerial-specific maneuvers having been performed for a threshold duration of time. Alternatively or additionally, the logging stop condition (s) in a log stop set 22 may alternatively or additionally include a stable received signal level (RSL) condition that is met upon a magnitude of a RSL of the aerial communication device 10 not changing by more than a RSL change threshold. Such conditions may for example drive the log controller 10C to stop logging operational data 18 when the aerial communication device’s flight has become stable enough to not warrant interesting operational data 18 to log, e.g., in favor of conserving battery life and / or memory resources of the aerial communication device 10.

[0074] Irrespective of the particular logging trigger set (s) 20 and / or the logging stop set (s) 22, at least one of the logging trigger set (s) 20 and / or at least one of the logging stop set (s) 22 may be preconfigured at the aerial communication device 10. Alternatively, in other embodiments, at least one of the logging trigger set (s) 20 and / or at least one of the logging stop set (s) 22 may be configured by the communication network 12.

[0075] As shown in Figure 1, for instance, the aerial communication device 10 may receive a configuration message 15 from a network node 14 in the communication network indicating one or more logging trigger conditions 20C in a logging trigger set 20. In one such embodiment, the  configuration message 15 may be a message that configures the aerial communication device 10 with a planned flight path 16P. Alternatively or additionally, the configuration message 15 may be a message that requests the aerial communication device 10 to log the operational data 18 upon detecting the one or more logging trigger conditions 20C in a log trigger set 20.

[0076] Although not shown, the aerial communication device 10 may alternatively or additionally receive a configuration message 15 from the network node 14 indicating one or more logging stop conditions in a log stop set 22. For example, the configuration message 15 may be a message that requests the aerial communication device 10 to stop logging the operational data 18 upon detecting one or more logging stop conditions in a log stop set 22.

[0077] Consider now some embodiments herein as exemplified in a context where the communication network 12 is a 5G network based on New Radio (NR) and the aerial communication device 10 is exemplified as a UAV. In NR, which is based on Orthogonal Frequency Division Multiplexing (OFDM) , multiple numerologies are supported for operation, e.g., transmission and / or reception of signals. The term numerology may characterize any one or more of: frame duration, subframe or transmission time interval (TTI duration) , slot duration, min-slot duration, symbol durations subcarrier spacing, number of resource blocks (RBs) within the bandwidth, number of subcarriers per physical channel (e.g., per RB) , cyclic prefix (CP) length (e.g., normal and extended CP lengths) , etc. A scaling approach (based on a scaling factor 2N, N=1, 2, …) is considered for deriving subcarrier spacings for NR: 15kHz, 30 kHz, 60 kHz, 120 kHz, 240 kHz, etc. The numerology-specific time resource durations (e.g., slot, subframe, etc. ) can then be determined based on the subcarrier spacing: subcarrier spacing of (2N*15) kHz corresponds to a symbol duration of 1 /  (15000*2N) second.

[0078] Furthermore, NR supports a large number of bandwidths, which depends on the frequency range of signals transmitted in the cell. Examples of frequency ranges are frequency range 1 (FR1) and frequency range 2 (FR2) . In FR1 the frequencies are lower than the frequencies belonging to FR2. An example of FR1 comprises a range of frequencies up to 7 GHz. An example of FR2 comprises a range of frequencies between 24 and 52.6 GHz. In FR1, examples of supported bandwidths are 5 MHz, 10 MHz, 20 MHz, 30 MHz, 40 MHz, 50 MHz, 80 MHz, 100 MHz etc. In FR2, examples of supported bandwidths are 50 MHz, 100 MHz, 200 MHz, 400 MHz, etc.

[0079] Although traditionally UAVs could only be flown by a controller within the visual line of sight (VLoS) , the 3rd Generation Partnership Project (3GPP) has specified multiple features in Long Term Evolution (LTE) Rel-15 aiming at improving the efficiency and robustness of terrestrial LTE network for providing aerial connectivity services, particularly for low altitude UAVs. These features target both command-and-control traffic for flying a UAV and the data (also known as payload) traffic from the UAV to the cellular network. The key features specified include support for subscription-based identification of UAVs, reporting of height, 3D location, and vertical speed when a UAV crosses a height threshold, RSRP / RSRQ reporting  per event of N cells’ signal power above a threshold, UE-specific uplink power control, and providing of flight path information from UE to eNB. Flight path information reporting includes network polling and providing the network with a list of waypoints (3D location) as well as time stamp if available.

[0080] These features were introduced targeting special needs when serving the UAVs by the LTE network, e.g., the need for flying mode detection, interference detection, and interference mitigation. The first important issue was the flying mode detection, which is also related to interference detection as the interference conditions for flying aerial UEs are different from aerial UEs in terrestrial mode. For interference detection, which may also serve as input to flying mode detection, an enhancement to existing events triggering of RSRP / RSRQ / RS-SINR reports was introduced in LTE Rel-15. The UE may be configured to trigger an event such as A3, A4, A5, which all consider neighbor cell measurements. In such event triggers, a measurement report is triggered when multiple cells’ measured RSRPs (RSRQs / RS-SINRs) are above a threshold.

[0081] Another input to flying mode detection is event triggered height and location reporting. A new configurable event within Radio Resource Management (RRM) with height threshold is introduced for Rel-15 Aerial UEs. When the UE is configured with an event, a report is triggered when the UE’s altitude crosses the threshold altitude. In addition to flying mode detection, the exact height information is considered useful as the network may choose to reconfigure, for example, measurement reporting configurations for the UE when it crosses a height threshold. Figure 2 depicts this situation. As shown, when the UE 10 is below a height of 100m, the aerial UE is Radio Resource Control (RRC) configured with measurement reporting configurations and event-triggered height / location reporting corresponding to a height threshold of 200m. As the aerial UE crosses a height threshold of 200m, a report is triggered from the UE 10 to the network 12. After receiving the report from the aerial UE 10, the network RRC reconfigures the aerial UE 10 with new measurement reporting configurations.

[0082] Figure 3 shows a system called Unmanned Aircraft Systems (UAS) Traffic Management (UTM) 17 according to some embodiments. The UTM 17 manages the traffic of a UAS 13 composed of a UAV 10 and a UAV controller 11 used by an operator with unique credentials and identities. UTM 17 is a collaborative, automated, and federated airspace management approach that enables safe, efficient, and equitable small UAS operations at scale. The UTM 17 provides many flight-related functions for UAVs and UAV operators, including for example UAV identification, flight planning considering various aspects such as UAV performance and weather conditions, message exchange between operators for e.g., position and status information, provision of on-demand, periodic, or event-triggered communications with Federal Aviation Administration (FAA) systems to meet regulatory requirements, provision of mapping information about airspace restrictions, obstacles, and  sensitive regions, and conflict advisory for real-time alerting for collision avoidance.

[0083] Mobile networks can enable reliable connectivity between the UAV 10 and its controller 11. Meanwhile, as shown in Figure 3, the UTM 17 according to some embodiments can connect to the UAV 10 and the associated UAV controller 11 through core network (s) 12C and radio access network (s) 12A.

[0084] According to some embodiments in this context, operational data 18 is or includes Minimization of drive test (MDT) data. MDT is used as an alternative to the drive tests for obtaining certain types of UE measurement results for self-organizing network (SON) related features such as network planning, network optimization, network parameter tuning or setting (e.g., base station transmit power, number of receive and / or transmit antennas, etc. ) , or even for positioning (e.g., radio frequency (RF) pattern matching based positioning) . The UE is configured by the network for logging the measurements. Two MDT modes exist: immediate MDT and logged MDT. Immediate MDT comprises measurements performed by a UE in the high RRC activity states (e.g., RRC CONNECTED state in LTE and NR, etc. ) and the reporting of the measurements to a network node (e.g., eNodeB, gNode B, etc. ) when reporting condition is met e.g., event is triggered. Logged MDT functionality by contrast comprises measurement performed by a UE when operating in a low RRC activity state (e.g., RRC idle, RRC inactive, etc. ) .

[0085] The communication network may use a Logged Measurement Configuration message to configure the UE to perform logging of measurement results in low RRC activity state which can be stored in the UE for up to 48 hours before reporting. The configuration comprises information such as absolute time in the cell, logging duration, logging interval or periodicity (e.g., how often the measurements are logged) , information about area where logging is required etc. The logging duration can vary from a few minutes to several hours. The UE transmits the measurement results along with relative time stamp for each log, which indicates the time of logging measurement results relative to the absolute time received (received from the network) , location information of the logged results (optional) etc. SON operation which includes MDT measurements are supported in NR since NR release 16 and in LTE since early LTE release.

[0086] Some embodiments herein address the problem that existing MDT measurements rely on the mobile broadband (MBB) UE mobility profile, i.e., they are logged in areas where a UE can reach. The mobility profile of MBB UE (e.g., handheld device) has certain characteristics which are different compared to the mobility profile of an aerial device (e.g., UAV UE, ATG UE) UE which is operating at higher altitude than a MBB UE. For example, the notable characteristics of aerial device operation comprises operation at higher altitude, operation at higher speed, operation following fixed flight path, unmanned operation, and / or operation in areas where typical MBB UEs may not be able to operate in. Given this difference, existing MDT solutions are tailored to operate in MBB UE scenarios and neglect to accommodate aerial UEs. Yet an important advantage of aerial devices over MBB UE is that the former  encompasses much broader mobility profile compared to the latter. Another difference is that, for certain types of aerial devices (such as UEs mounted in aircraft) , UE power consumption is not an issue unlike a MBB UE. Therefore, MBB UE cannot guarantee some of the advantages that aerial devices can provide for SON related measurements. In order to efficiently serve UEs in the airspace, the deployment of radio nodes and network parameter setting need to be customized to the aerial radio environment. Therefore, existing network planning solutions relying on classical MDT logging principles are not suitable for the planning, deploying, and tuning of the radio network in the aerial environment.

[0087] Even if an AUE logs information related to the changes in its height and changes in its speed, in practice the AUE flight path can be quite complicated and could change over time e.g., under a critical situation. Some embodiments herein advantageously address logging related to such unplanned changes in the flight path.

[0088] According to some embodiments herein in this regard where an AUE 10 exemplifies an aerial communication device 10 in Figure 1, an AUE 10 is configured to log MDT data associated with aerial operation of the AUE. The logged MDT data in this case exemplifies the operational data 18 described in Figure 1.

[0089] In one embodiment, the MDT data logging is triggered in the AUE 10 when there is change in the trajectory or flight path of the AUE 10. In one example, MDT data logging is triggered when the flight path of the AUE 10 changes from a first flight path to a second flight path, where the first flight path is the planned or normal flight path while the second flight path is a fallback (e.g., used under emergency or critical situation) . The first flight path may thereby exemplify the planned flight path 16P in Figure 1, and the second flight path may exemplify a bypass flight path or an emergency flight path in Figure 1. In another example, MDT data logging is triggered when the fight path of the AUE 10 changes from the second flight path to the first flight path e.g., AUE upon leaving or recovering from the critical situation. In either example, the difference between the first flight path and the second flight path is that the former one is the planned flight path while the latter one is a fallback (e.g., emergency path) , which is used under critical or emergency contingencies. Examples of critical or emergency contingencies are collision with an object, emergency landing, sudden change in weather conditions, fuel shortage etc. In any event, such change in the trajectory or flight path of the AUE 10 may thereby exemplify the path change condition described with respect to Figure 1.

[0090] In another embodiment, the MDT logging is triggered in the AUE 10 when there is change in the trajectory or flight path of the AUE 10 and one or more additional conditions or criteria are met / detected by the AUE 10. Examples of the additional conditions or criteria are: (i) aerial-specific maneuver is detected by the AUE 10, e.g., rolling, pitching, yawing, etc; (ii) change in the direction of the AUE 10 by more than a threshold; (iii) change in the speed of the AUE 10 by more than a threshold; (iv) change in the height of the AUE 10 by more than a threshold; (v) the AUE location changes with respect to a certain threshold; (vi) when a  combination of events is fulfilled, e.g., location and RSRP change by their respective thresholds or height and RSRP change by their respective thresholds or location and height change by their respective thresholds etc.; (vii) current time (e.g., UTC time) at the AUE 10 exceeds a threshold or reference value; or (viii) the AUE 10 reaches a certain waypoint in the AUE’s flight path report, where the certain waypoint can be the mid waypoint, last one, or a configured one. These additional conditions or criteria thereby exemplify log triggering condition (s) 20C in Figure 1 that may supplement a path change condition in a log triggering set 20.

[0091] In the above embodiments, the MDT data logged by the AUE 10 may comprise at least one of the following parameters: (i) flight path information, e.g., old flight path, new flight path, reason for change of flight path; (ii) time stamp or relative time stamp when the triggering conditions are met; (iii) location information when the triggering conditions are met; (iv) type of aerial specific maneuver detected; and / or (v) AUE mobility state e.g., AUE speed, height, direction of motion, acceleration, etc.

[0092] In some embodiments, the AUE 10 is configured to stop the ongoing logging of MDT data in the AUE when one or more of following conditions are met, as examples of log stopping conditions described with respect to Figure 1: (i) the flight path has not changed over a period of time; (ii) the height or altitude of the AUE 10 has not changed over a period of time; (iii) the speed of the AUE 10 has not changed over a period of time; (iv) the flight operational mode of the AUE 10 is considered as stable or normal or according to the plan, i.e., aerial specific maneuver is detected for a period of time; (v) the MDT log triggering conditions are no longer met; and / or (vi) upon expiry of a timer, where the timer may start upon starting the logging of the MDT data or at certain reference time (e.g., UTC time, cell timing such as at certain System Frame Number (SFN) or Hyper SFN (HSFN) , etc. ) .

[0093] Generally, then, an AUE 10 according to some embodiments herein logs MDT data related to the changes in the flight path of the AUE 10, especially due to a critical situation e.g., emergency landing, malfunctioning, collision with an object, running out of fuel etc. The logged MDT data may be used by the network 12 for improving network planning to enhance AUE operation and mobility, especially under a critical situation. Furthermore, the AUE 10 may stop the logging of the MDT data when none of the conditions related to the change in the flight path are met.

[0094] Certain embodiments may provide one or more of the following technical advantage (s) . In general, the obtained MDT data can be used to improve the network planning and deployment of access nodes to serve aerial devices such as airplanes, drones e.g. The logged data may also provide more accurate information about the actual aerial specific operational data as experienced by the AUE 10. The network may accordingly use the logged data for optimizing the network parameters, enhancing and improving the efficiency of radio resources. Moreo0ver, some embodiments enable the network 12 to optimize the flight path of  the AUE 10. For example, the network 12 may configure the AUE 10 with a flight path (e.g., a set of waypoints) which avoids or minimizes the emergency situation. Alternatively or additionally, some embodiments enable the network 12 to configure or reserve sufficient radio resources (e.g., larger bandwidth, higher output power, beamforming, additional carriers, etc. ) in access nodes stations deployed in the areas or location where the AUE 10 could encounter one or more contingencies such as an emergency situation.

[0095] Consider now additional details of some embodiments in a specific scenario. The scenario comprises an AUE 10 served by a first cell (cell1) , which is managed or served by a first network node (NW1) . The AUE 10 may be configured by NW1 by receiving a message containing different types of configurations for enabling the AUE 10 to perform measurements, e.g., measurement configuration, measurement gap configuration, etc. For example, the AUE 10 may be configured by NW1 to perform measurements on one or more cells operating on one or more carrier frequencies. This may be realized for example by NW1 configuring the AUE 10 with information, which can identify the carrier frequencies. An example of such information is a carrier frequency number or identifier such as absolute radio frequency channel number (ARFCN) . Examples of ARFCN are EUTRA ARFCN (EARFCN) , NR-ARFCN, etc. In some embodiments, the aerial device housing or containing the UE (i.e., AUE) is flying from first cell (cell1) to a second cell (cell2) which is managed or served by NW1 or by a second network node (NW2) . In some embodiments, NW1 and NW2 are the same, e.g., served by same base station. In some embodiments, NW1 and NW2 are different. Cell1 and cell2 may operate on the same carrier frequency (e.g., F1) or on different carrier frequencies (e.g., cell1 and cell2 on F1 and F2, respectively) .

[0096] Some embodiments herein concern a method for the AUE 10 to initiate logging of MDT-related data. Initiation (triggering or starting) of logging MDT data associated with aerial operation may be based on at least one criterion related to the flight operational mode of the AUE 10. More specifically, the AUE 10 in some embodiments initiates logging MDT data when one or more of following events are triggered.

[0097] In one embodiment, the AUE 10 logs or starts to log the MDT data upon detecting a change of trajectory or flight path of the AUE 10. The logged MDT data comprises information related to the change or transition of the flight path or trajectory. This is explained with examples below.

[0098] In one example, the AUE 10 logs the MDT data when the flight path of the AUE 10 changes from a first flight path to a second flight path. The first flight path is the planned or normal path (or default path) while the second flight path is a fallback (e.g., used under emergency or critical situation) .

[0099] In another example, the AUE 10 logs the MDT data when the AUE’s flight path changes from the second flight path to the first flight path.

[0100] In some embodiments, the flight path (or flight trajectory) is defined in terms of a set of geographical coordinates.

[0101] In one example, the first flight path is a planned flight path while the second flight path is a fallback flight path, backup flight path or emergency flight path. The planned flight path may be pre-configured by a network node at the start of the flight or is pre-configured in the AUE (e.g., in the Subscriber Identity Module (SIM)  / Multiple Universal SIM (MUSIM) ) . The fallback flight path may be dynamically configured by a network node during the flight path e.g., under certain conditions such as sudden change in weather, autonomously determined by the AUE 10, pre-defined, e.g., in the standard, or pre-configured in the AUE 10 as a secondary flight path (e.g., emergency flight path) e.g., pre-configured by the operator via the SIM / USIM card.

[0102] Consider now some examples of the situations under which the AUE 10 may change its flight path between the first path and the second flight path. In one example, the AUE 10 changes its flight path from the first flight path to the second flight path upon entering in or encountering a critical situation. In the critical situation, the AUE 10 may face an unexpected flight operation, e.g., sudden drop in speed, change in direction, inability to fly or fly as planned, maneuver harming or impacting the AUE aerodynamics, etc. Examples of such critical situations are emergency landing, malfunctioning, battery power or fuel level falling below threshold, unable to maintain the flight path (e.g., due to storm or strong headwind, etc. ) , collision with an object, in close range with more than a certain number of objects, expected collision with an object if continue following the planned flight path etc. The object can be an active object operating wireless signals (e.g., another AUE, a base station radio equipment, etc. ) or a passive object (e.g., tower, skyscraper, hot air balloon, airplane, helicopter, etc) .

[0103] In another example, the AUE 10 changes its flight path from the second flight path to the first flight path upon leaving or recovering from the critical situation, i.e., reverting to a normal situation from the critical situation. The AUE 10 not in any critical situation is assumed to be operating in the normal situation.

[0104] In other embodiments, MDT data is logged upon the AUE 10 triggering multiple events comprising at least a change in its flight path. In one embodiment, for example, the AUE 10 logs or starts to log the MDT data upon detecting the change of trajectory or flight path of the AUE and when at least one of the following additional conditions / criteria / events is also met.

[0105] A first example of the additional criteria is the AUE’s speed changing by more than a threshold. The AUE may be expressed in terms of physical speed (e.g., distance per unit time) and / or in terms of Doppler speed, which depends on the physical speed and the carrier frequency of operation and / or changes in the received signal level of a cell (e.g., serving cell) ,

[0106] A second example is a change in direction of movement of the AUE 10 being more than a threshold. The direction can be defined with respect to a reference location or point.  Examples of reference location are previous locations of the AUE 10, or location of the serving base station. The direction can be expressed in terms of one or more angular measurements, e.g., azimuth angle and / or zenith angle,

[0107] A third example is a change in height or altitude of the AUE exceeding a certain threshold (H11) or dropping below a certain threshold (H12) or being outside a certain height range (e.g., not within two different thresholds) .

[0108] A fourth example detection of an aerial-specific maneuver by the AUE 10. For example, the aerial object housing the AUE performs a certain type of maneuver. Examples of the aerial maneuvers are pitching (e.g., ascending or descending) , yawing (e.g., moving / turning / tilting left or right) , rolling (e.g., spinning / revolving / rolling / rotating clockwise or counterclockwise) , any combination thereof, etc.

[0109] A fifth example is the AUE location changing by at least a threshold. The threshold can be predefined or can be configured by a network node. AUE 10 can determine its location by means of a Global Navigation Satellite System (GNSS) .

[0110] A sixth example is when a combination of two or more events is fulfilled. For example, when the AUE’s location and received signal level (e.g., RSRP, RSRQ, SINR, etc. ) with respect to a cell (e.g., serving cell) change by their respective thresholds. Or, when the AEU’s height and signal measurement (e.g., RSRP, RSRQ, SINR, etc. ) with respect to a cell (e.g., serving cell) change by their respective thresholds.

[0111] A seventh example is the measured or estimated time (e.g., measured UTC time) at the AUE 10 exceeding a threshold or the measured time exceeding a sum of a threshold and a duration. The threshold and the duration can be pre-defined or configured by a network node.

[0112] An eight example is the AUE 10 reaching a certain waypoint in the UE’s flight path. The certain waypoint may be any waypoint, last one, or a configured one or pre-defined one (e.g., mid waypoint) in the flight path. The AUE 10 determines the waypoint by comparing its location (e.g., geographical co-ordinates) with a set of waypoints.

[0113] Regardless, the logged MDT data in some embodiments comprises information related to the change or transition of the flight path as well as information related to the one or more conditions triggering the AUE 10 to log the MDT data.

[0114] The logging of the flight operation mode related data by AUE based on the above listed criteria may be motivated by the fact that the AUE 10 encompasses much broader mobility profile compared to legacy handheld MBB devices as explained above. This enables the collection of vital flight operational data which cannot be obtained using the measurements from the legacy handheld MBB devices.

[0115] Consider now criteria for stopping logging of MDT-related data according to some embodiments. Stopping logging of MDT-related data may include merely suspending or postponing the ongoing logging of MDT data related to aerial operation. Regardless, such  stopping may be based on one or more criteria. Such criteria that can be predefined, preconfigured or dynamically configured in the AUE. Non-limiting examples of the criteria comprises: (i) none of the conditions / criteria that triggered the start of the MDT logging related to aerial operation described in above is met any longer; (ii) the AUE 10 has reverted to the first flight path, i.e., normal flight path; (iii) upon expiry of a timer, where the timer may start upon starting the logging of the MDT data or at certain reference time (e.g., UTC time, cell timing such as at certain SFN or HSFN, etc. ) ; (iv) the flight path has not changed over a period of time; (v) the height or altitude has not changed over a period of time; (vi) the AUE location has not changed over a period of time; (vii) the AUE speed has not changed over a period of time; (viii) the time elapsed since last MDT measurement is less than a threshold; or (ix) the flight operational mode is considered as stable or normal or according to the plan, i.e., no aerial specific maneuver is detected for a period of time, as may be the case if the AUE 10 has been cruising without any yawing, rolling, or pitching movements.

[0116] Of course, the stopping of the logging of MDT data may be based on any one or more combinations of the stopping conditions listed above. In one example, the AUE 10 may stop the MDT logging related to aerial operation data if any of the stopping conditions is met. But in another example, the UE may stop the logging if at least X number of stopping conditions are met, where X > 1 e.g., X = 2, 3 etc.

[0117] An example is shown in Figure 4 where the MDT logging conditions are configured at a first time instance (T1) . The AUE 10 meets the logging conditions at a second time instance (T2) upon which the logging is initiated. However, the MDT logging is stopped at a third time instance (T3) since the logging conditions are no longer met. The MDT logging is later resumed at a fourth time instance (T4) when the logging conditions are met again.

[0118] Consider now additional details about the logged MDT-related data according to some embodiments. In one embodiment, the AUE 10 is configured by higher layer signaling (e.g. an RRC message) with information indicating the MDT-related data to be logged by the AUE 10 when one or more triggering condition (s) are met as described above. The information to be logged by the AUE 10 in one example may comprise at least the AUE’s flight path and location information, the AUE mobility state, type of detected aerial maneuver, and associated information.

[0119] In some embodiments, the AUE 10 logs the MDT data when the triggering condition (s) are met and uses it for one or more operational tasks. Examples of such tasks are transmitting the logged data to a network node (e.g., serving base station) or to another AUE, using the logged data for internal operation, etc.

[0120] The logged MDT data may comprise one or more of the following non-limiting examples of parameters: (i) flight path information, e.g., old flight path, new flight path, reason for change of flight path when the conditions are met or at the time of logging; (ii) time stamp or relative time stamp when the triggering conditions are met or at the time of logging; (iii)  location information (e.g., geographical coordinates) when the conditions are met or at the time of logging; (iv) type of aerial specific maneuver detected at the triggering conditions are met or at the time of logging; (v) AUE mobility state, e.g., AUE speed, height, direction of motion, acceleration etc. when the triggering conditions are met or at the time of logging; (vi) results of measurements performed at the time the triggering conditions were met or at the time of logging; (vii) time stamp or relative time stamp when the triggering conditions were met or at the time of logging; and / or (viii) duration of the log, e.g., indicating for how long the triggering conditions were met or for how long the flight operation mode data / parameters deviated from the normal or expected or stable mode. Therefore, the duration may be a variable set by the UE or it may have any configurable value.

[0121] The logging of MDT data based on the above embodiments is described below in detail with several examples. Although the examples include a certain specific set of logging information, the embodiments cover any combination of the MDT logging parameters. In one example, the logged information may include only a subset of the MDT information associated with aerial operation in the above. But in another example, the logged information may contain all the MDT information associated with aerial operation.

[0122] Logging example #1:

[0123] A general example is shown in Table 1 where the AUE 10 is configured to log MDT data associated with aerial operation, and the logged information (as an example of operational data 18) includes: flight path information (old flight path and new flight path) , location information and relative time. It is assumed that the AUE 10 can log up to N values over time instances T1, T2, T3, …, TN respectively. The relative time with respect to Tr for logging Nj is denoted as ΔTj, therefore j≤N. ΔTj is also called as logging time with respect to reference time Tr. For example, Tr can be the absolute time in the serving cell when the AUE 10 is configured by the network node for logging MDT data associated with aerial operation. In another example, Tr can be any type of absolute time with which the AUE 10 is configured by the network node for logging MDT data e.g. UTC time. As an example, ΔTj = (Tj –Tr) , e.g., ΔT1 = (T1 –Tr) and so on. As a special case ΔT1 = ΔT2 =, ..., =ΔTN, e.g., the logging period or interval may comprise L number of discontinuous reception (DRX) cycles or it can be a fixed value. The logging starts when the AUE 10 has met one or more of the triggering conditions (as described earlier) are met.

[0124] The logged old flight path information (PO_j) contains information about the first path (sometimes also noted at primary flight path or original flight path or main flight path) . The logged new flight path information (PN_j) contains information about the new flight path that the AUE 10 has started to use upon change in flight operation mode, e.g., upon emergency or critical situations. The new path may also be called a secondary path, emergency path, or fallback path. The new flight path may be predefined or preconfigured by the operator (e.g., stored in the SIM / eSIM) or it can be configured dynamically by the serving node.

[0125] The logged location information (Lj) contains information about the location where the MDT logging containing aerial operation has been initiated or triggered. The location information can be represented using geographical coordinates or predefined, preconfigured, or configurable reference locations.

[0126] Table 1

[0127] Logging example #2:

[0128] Table 2 shows another general example where the AUE 10 is configured to log MDT data associated with aerial operation. In this example, the logged information (as an example of operational data 18) includes flight path information (old flight path and new flight path) , maneuver information, location information and relative time information. The path-, location-, and relative time information is similar to those described in example #1 above.

[0129] The maneuver information (Mj) contains information about the type of maneuver performed by the AUE 10 at the time of Tj for switching from the first (old flight path) to the second (new) flight path at the given location Lj. In other words, the logged information in this example does not only contain the flight path, location, and time information, but also the reason for switching the path, i.e., the aerial device specific maneuver information may reveal the reason for switching the path. Examples of maneuvers are the following.

[0130] A pitching movement which occurs around the lateral axis that runs along the wing of the AUE. 10 In simple terms, in pitching the nose of the AUE 10 moves up and down.

[0131] A yawing movement occurs around the vertical axis, which is perpendicular to the wing of the AUE 10. In simple terms, in yawing the nose of the AUE 10 moves left and right.

[0132] A rolling movement occurs around the longitudinal axis, which runs along the fuselage of the AUE 10. In simple terms, in rolling the fuselage of the AUE 10, the AUE 10 rotates or spins clockwise or counterclockwise.

[0133] Some of the above movements or maneuver combination of the movements can also be recognized when flying an aerial device: ascend, cruise, descend, turn right (e.g. tilt right) , turn left (e.g. tilt left) .

[0134] Table 2

[0135] Logging example #3:

[0136] Table 3 shows yet another general example where the AUE 10 is configured to log MDT data associated with aerial operation. In this example, the logged information (as an example of operational data 18) includes flight path information (old flight path and new flight path) , maneuver information, mobility state information and relative time information. The flight path-, location-, maneuver-, and relative time information is similar to those described in examples 1 and 2 above.

[0137] The additional mobility state information may contain information indicating the height, speed, direction of movement / motion, acceleration at the time when the AUE 10 has performed a certain type of maneuver at time ΔTj at location Lj. This information may be useful, afterwards, to analyze the reason for maneuver which required the AUE 10 to switch to a fallback or land in an emergency location, etc.

[0138] Table 3

[0139] Note that the term node as used herein can be a network node or a user equipment (UE) .

[0140] Examples of network nodes are NodeB, base station (BS) , multi-standard radio (MSR) radio node such as MSR BS, eNodeB, gNodeB, MeNB, SeNB, location measurement unit (LMU) , integrated access backhaul (IAB) node, network controller, radio network controller (RNC) , base station controller (BSC) , relay, donor node controlling relay, base transceiver station (BTS) , Central Unit (e.g. in a gNB) , Distributed Unit (e.g. in a gNB) , Baseband Unit, Centralized Baseband, C-RAN, access point (AP) , transmission points, transmission nodes, transmission reception point (TRP) , RRU, RRH, nodes in distributed antenna system (DAS) , core network node (e.g. MSC, MME, etc. ) , O&M, OSS, SON, positioning node (e.g. E-SMLC) , etc.

[0141] The non-limiting term UE refers to any type of communication device capable of communicating with a network node and / or with another UE in a cellular or mobile communication system. Examples of UE are target device, air-to-ground (ATG) UE, device to device (D2D) UE, vehicular to vehicular (V2V) , machine type UE, MTC UE or UE capable of machine to machine (M2M) communication, PDA, tablet, mobile terminals, smart phone, laptop embedded equipment (LEE) , laptop mounted equipment (LME) , USB dongles, etc. In some embodiments, the non-limiting term ‘aerial UE (AUE) ’ is used, and it refers to any type of UE equipped or housed or located in any type of flying object. The flying object moves or flies in air or in free space. The term flying object is interchangeably called a flying vehicle, aerial vehicle (AV) , aerial object, aerial device, IAB node, air to ground (ATG) UE, etc. Examples of  the flying object are aircraft, drone, chopper, helicopter, flying balloon, glider, flying bus, etc. In some embodiments, aerial vehicle (AV) may also refer to aerial UE (AUE) .

[0142] The term radio access technology, or RAT, may refer to any RAT, e.g., UTRA, E-UTRA, narrow band internet of things (NB-IoT) , WiFi, Bluetooth, next generation RAT, New Radio (NR) , 4G, 5G, etc. Any of the equipment denoted by the term node, network node or radio network node may be capable of supporting a single or multiple RATs.

[0143] In view of the modifications and variations herein, Figure 5 depicts a method performed by an aerial communication device 10 in accordance with particular embodiments. The method includes detecting that each of one or more logging trigger conditions 20C in a log trigger set 20 are met (Block 510) . In some embodiments, the one or more logging trigger conditions 20C include a path change condition that is met upon a targeted flight path 16T of the aerial communication device 10 changing to or from a planned flight path 16P. In some embodiments, the planned flight path 16P is a path of flight that the aerial communication device 10 plans to follow absent occurrence of a contingency. The method also comprises, based on detecting that each of the one or more logging trigger conditions 20C in the log trigger set 20 are met, logging aerial-specific operational data 18 at the aerial communication device 10 describing aerial operation of the aerial communication device 10 (Block 520) .

[0144] In some embodiments, the path change condition is met upon the targeted flight path 16T of the aerial communication device 10 changing from the planned flight back to a backup flight path. In some embodiments, the backup flight path is a path of flight that the aerial communication device 10 reverts to upon occurrence of a contingency. In some embodiments, the planned flight path 16P is planned before initiation of the aerial communication device 10 along the planned flight path 16P, and the backup flight path is dynamically determined upon occurrence of a contingency.

[0145] In some embodiments, the planned flight path 16P is a path of flight that the aerial communication device 10 plans to follow absent occurrence of a contingency deemed by the aerial communication device 10 as a critical or emergency contingency. In some embodiments, a critical or emergency contingency includes at least inability of the aerial communication device 10 to fly. In other embodiments, a critical or emergency contingency includes at least inability of the aerial communication device 10 to fly along the planned flight path 16P. In yet other embodiments, a critical or emergency contingency includes at least an emergency landing of the aerial communication device 10. In still yet other embodiments, a critical or emergency contingency includes at least malfunctioning of the aerial communication device 10. In still yet other embodiments, a critical or emergency contingency includes at least a battery level of the aerial communication device 10 falling below a minimum threshold. In still yet other embodiments, a critical or emergency contingency includes at least a fuel level of the aerial communication device 10 falling below a minimum threshold. In still yet other embodiments, a critical or emergency contingency includes at least actual or expected collision with an object.

[0146] In some embodiments, the aerial-specific operational data 18 includes data indicating the planned flight path 16P. In some embodiments, the aerial-specific operational data 18 includes data indicating a flight path 16T to or from which the targeted flight path 16T was changed.

[0147] In some embodiments, the aerial-specific operational data 18 includes data indicating a reason for the targeted flight path 16T changing to or from the planned flight path 16P. In other embodiments, the aerial-specific operational data 18 alternatively or additionally includes data indicating a time and / or location of the aerial communication device 10 when the targeted flight path 16T was changed to or from the planned flight path 16P. In yet other embodiments, the aerial-specific operational data 18 alternatively or additionally includes data describing an aerial-specific maneuver detected by the aerial communication device 10 upon detecting that each of the one or more logging trigger conditions 20C are met. In still yet other embodiments, the aerial-specific operational data 18 alternatively or additionally includes data describing an aerial mobility state of the aerial communication device 10. In some embodiments, the aerial mobility state includes one or more of a speed, acceleration, direction of movement, or altitude of the aerial communication device 10.

[0148] In some embodiments, the one or more logging trigger conditions 20C in the log trigger set 20 further include at least a speed change condition that is met upon a speed of the aerial communication device 10 changing by more than a speed change threshold. In other embodiments, the one or more logging trigger conditions 20C in the log trigger set 20 further alternatively or additionally include at least a direction change condition that is met upon a direction of movement of the aerial communication device 10 changing by more than a direction change threshold. In yet other embodiments, the one or more logging trigger conditions 20C in the log trigger set 20 further alternatively or additionally include at least an altitude change condition that is met upon an altitude of the aerial communication device 10 changing by more than an altitude change threshold. In still yet other embodiments, the one or more logging trigger conditions 20C in the log trigger set 20 further alternatively or additionally include at least a maneuver condition that is met upon the aerial communication device 10 performing one or more types of aerial maneuvers. In still yet other embodiments, the one or more logging trigger conditions 20C in the log trigger set 20 further alternatively or additionally include a location change condition that is met upon a location of the aerial communication device 10 changing by more than a location change threshold. In still yet other embodiments, the one or more logging trigger conditions 20C in the log trigger set 20 further alternatively or additionally include a time condition that is met upon a measured or estimated time at the aerial communication device 10 exceeding a time threshold or exceeding a sum of the time threshold and a defined duration. In still yet other embodiments, the one or more logging trigger conditions 20C in the log trigger set 20 further alternatively or additionally include a waypoint condition that is met upon the aerial communication device 10 reaching a defined waypoint in the planned flight path 16P. In still yet  other embodiments, the one or more logging trigger conditions 20C in the log trigger set 20 further alternatively or additionally include a received signal level (RSL) condition that is met upon a magnitude of a RSL of the aerial communication device 10 changing by more than a RSL change threshold.

[0149] In some embodiments, logging the aerial-specific operational data 18 at the aerial communication device 10 comprises logging aerial-specific operational data 18 at the aerial communication device 10 on an ongoing or periodic basis. In some embodiments, the method further comprises, after starting to log the aerial-specific operational data 18 at the aerial communication device 10, detecting that each of one or more logging stop conditions in a log stop set 22 are met. In some embodiments, the method further comprises, after starting to log the aerial-specific operational data 18 at the aerial communication device 10, based on detecting that each of one or more logging stop conditions in the log stop set 22 are met, stopping logging the aerial-specific operational data 18 at the aerial communication device 10. In some embodiments,

[0150] In some embodiments, each of the one or more logging stop conditions in the log stop set 22 is met if none of the one or more logging trigger conditions 20C in the log trigger set 20 are met. In some embodiments, the one or more logging stop conditions in the log stop set 22 include at least a path revert condition that is met upon the aerial communication device 10 reverting to the planned flight path 16P. In other embodiments, the one or more logging stop conditions in the log stop set 22 alternatively or additionally include at least a timer condition that is met upon expiry of a timer started by the aerial communication device 10 upon starting logging of the aerial-specific operational data 18. In yet other embodiments, the one or more logging stop conditions in the log stop set 22 alternatively or additionally include at least a stable state condition that is met when a flight path 16T, altitude, location, and / or speed of the aerial communication device 10 has remained stable for a threshold duration of time. In still yet other embodiments, the one or more logging stop conditions in the log stop set 22 alternatively or additionally include at least a maneuver absence condition that is met when the aerial communication device 10 has not detected any of one or more types of aerial-specific maneuvers having been performed for a threshold duration of time. In still yet other embodiments, the one or more logging stop conditions in the log stop set 22 alternatively or additionally include at least a stable received signal level (RSL) condition that is met upon a magnitude of a RSL of the aerial communication device 10 not changing by more than a RSL change threshold.

[0151] In some embodiments, the method further comprises receiving a configuration message 15 from a network node 14 requesting the aerial communication device 10 to log the aerial-specific operational data 18 upon detecting the one or more logging trigger conditions 20C in the log trigger set 20 and / or to stop logging the aerial-specific operational data 18 upon detecting one or more logging stop conditions in a log stop set 22 (Block 500) .

[0152] In some embodiments, the aerial-specific operational data 18 is logged as Minimization of Drive Test, MDT, data.

[0153] In some embodiments, the method further comprises reporting the logged aerial-specific operational data 18 to a network node 14 (Block 530) .

[0154] Figure 6 depicts a method performed by a network node 14 in accordance with other particular embodiments. The method includes receiving, from an aerial communication device 10, aerial-specific operational data 18 logged at the aerial communication device 10 in association with each of one or more logging trigger conditions 20C in a log trigger set 20 being met (Block 610) . In some embodiments, the one or more logging trigger conditions 20C include a path change condition that is met upon a targeted flight path 16T of the aerial communication device 10 changing to or from a planned flight path 16P. In some embodiments, the planned flight path 16P is a path of flight that the aerial communication device 10 plans to follow absent occurrence of a contingency. In some embodiments, the aerial-specific operational data 18 describes aerial operation of the aerial communication device 10.

[0155] In some embodiments, the path change condition is met upon the targeted flight path 16T of the aerial communication device 10 changing from the planned flight back to a backup flight path. In some embodiments, the backup flight path is a path of flight that the aerial communication device 10 reverts to upon occurrence of a contingency. In some embodiments, the planned flight path 16P is planned before initiation of the aerial communication device 10 along the planned flight path 16P, and the backup flight path is dynamically determined upon occurrence of a contingency.

[0156] In some embodiments, the planned flight path 16P is a path of flight that the aerial communication device 10 plans to follow absent occurrence of a contingency deemed by the aerial communication device 10 as a critical or emergency contingency. In some embodiments, a critical or emergency contingency includes at least inability of the aerial communication device 10 to fly. In other embodiments, a critical or emergency contingency includes at least inability of the aerial communication device 10 to fly along the planned flight path 16P. In yet other embodiments, a critical or emergency contingency includes at least an emergency landing of the aerial communication device 10. In still yet other embodiments, a critical or emergency contingency includes at least malfunctioning of the aerial communication device 10. In still yet other embodiments, a critical or emergency contingency includes at least a battery level of the aerial communication device 10 falling below a minimum threshold. In still yet other embodiments, a critical or emergency contingency includes at least a fuel level of the aerial communication device 10 falling below a minimum threshold. In still yet other embodiments, a critical or emergency contingency includes at least actual or expected collision with an object.

[0157] In some embodiments, the aerial-specific operational data 18 includes data indicating the planned flight path 16P. In some embodiments, the aerial-specific operational data 18 includes data indicating a flight path to or from which the targeted flight path 16T was changed.

[0158] In some embodiments, the aerial-specific operational data 18 includes data indicating a reason for the targeted flight path 16T changing to or from the planned flight path 16P. In other embodiments, the aerial-specific operational data 18 alternatively or additionally includes data indicating a time and / or location of the aerial communication device 10 when the targeted flight path 16T was changed to or from the planned flight path 16P. In yet other embodiments, the aerial-specific operational data 18 alternatively or additionally includes data describing an aerial-specific maneuver detected by the aerial communication device 10 upon detecting that each of the one or more logging trigger conditions 20C are met. In still yet other embodiments, the aerial-specific operational data 18 alternatively or additionally includes data describing an aerial mobility state of the aerial communication device 10. In some embodiments, the aerial mobility state includes one or more of a speed, acceleration, direction of movement, or altitude of the aerial communication device 10.

[0159] In some embodiments, the one or more logging trigger conditions 20C in the log trigger set 20 further include at least a speed change condition that is met upon a speed of the aerial communication device 10 changing by more than a speed change threshold. In other embodiments, the one or more logging trigger conditions 20C in the log trigger set 20 further alternatively or additionally include at least a direction change condition that is met upon a direction of movement of the aerial communication device 10 changing by more than a direction change threshold. In yet other embodiments, the one or more logging trigger conditions 20C in the log trigger set 20 further alternatively or additionally include at least an altitude change condition that is met upon an altitude of the aerial communication device 10 changing by more than an altitude change threshold. In still yet other embodiments, the one or more logging trigger conditions 20C in the log trigger set 20 further alternatively or additionally include at least a maneuver condition that is met upon the aerial communication device 10 performing one or more types of aerial maneuvers. In still yet other embodiments, the one or more logging trigger conditions 20C in the log trigger set 20 further alternatively or additionally include at least a location change condition that is met upon a location of the aerial communication device 10 changing by more than a location change threshold. In still yet other embodiments, the one or more logging trigger conditions 20C in the log trigger set 20 further alternatively or additionally include at least a time condition that is met upon a measured or estimated time at the aerial communication device 10 exceeding a time threshold or exceeding a sum of the time threshold and a defined duration. In still yet other embodiments, the one or more logging trigger conditions 20C in the log trigger set 20 further alternatively or additionally include at least a waypoint condition that is met upon the aerial communication device 10 reaching a defined waypoint in the planned flight path 16P. In still yet other embodiments, the one or more logging trigger conditions 20C in the log trigger set 20 further alternatively or additionally include at least a received signal level (RSL) condition that is met upon a magnitude of a RSL of the aerial communication device 10 changing by more than a RSL change threshold.

[0160] In some embodiments, receiving the aerial-specific operational data 18 comprises receiving a log including the aerial-specific operational data 18. In some embodiments, the log includes aerial-specific operational data 18 logged on an ongoing or periodic basis until each of one or more logging stop conditions in a log stop set 22 are met. In some embodiments, each of the one or more logging stop conditions in the log stop set 22 is met if none of the one or more logging trigger conditions 20C in the log trigger set 20 are met. In some embodiments, the one or more logging stop conditions in the log stop set 22 include at least a path revert condition that is met upon the aerial communication device 10 reverting to the planned flight path 16P. In other embodiments, the one or more logging stop conditions in the log stop set 22 alternatively or additionally include at least a timer condition that is met upon expiry of a timer started by the aerial communication device 10 upon starting logging of the aerial-specific operational data 18. In yet other embodiments, the one or more logging stop conditions in the log stop set 22 alternatively or additionally include at least a stable state condition that is met when a flight path, altitude, location, and / or speed of the aerial communication device 10 has remained stable for a threshold duration of time. In still yet other embodiments, the one or more logging stop conditions in the log stop set 22 alternatively or additionally include at least a maneuver absence condition that is met when the aerial communication device 10 has not detected any of one or more types of aerial-specific maneuvers having been performed for a threshold duration of time. In still yet other embodiments, the one or more logging stop conditions in the log stop set 22 alternatively or additionally include at least a stable received signal level (RSL) condition that is met upon a magnitude of a RSL of the aerial communication device 10 not changing by more than a RSL change threshold.

[0161] In some embodiments, the aerial-specific operational data 18 is logged as Minimization of Drive Test, MDT, data.

[0162] In some embodiments, the method further comprises performing one or more self-organizing network, SON, tasks based on the aerial-specific operational data 18 (Block 620) .

[0163] In some embodiments, the method further comprises configuring the aerial communication device 10 to log the aerial-specific operational data 18 upon detecting the one or more logging trigger conditions 20C and / or to stop logging the aerial-specific operational data 18 upon detecting one or more logging stop conditions (Block 600) .

[0164] Embodiments herein also include corresponding apparatuses. Embodiments herein for instance include an aerial communication device 10 configured to perform any of the steps of any of the embodiments described above for the aerial communication device 10.

[0165] Embodiments also include an aerial communication device 10 comprising processing circuitry and power supply circuitry. The processing circuitry is configured to perform any of the steps of any of the embodiments described above for the aerial communication device 10. The power supply circuitry is configured to supply power to the aerial communication device 10.

[0166] Embodiments further include an aerial communication device 10 comprising processing circuitry. The processing circuitry is configured to perform any of the steps of any of the embodiments described above for the aerial communication device 10. In some embodiments, the aerial communication device 10 further comprises communication circuitry.

[0167] Embodiments further include an aerial communication device 10 comprising processing circuitry and memory. The memory contains instructions executable by the processing circuitry whereby the aerial communication device 10 is configured to perform any of the steps of any of the embodiments described above for the aerial communication device 10.

[0168] Embodiments moreover include a user equipment (UE) . The UE comprises an antenna configured to send and receive wireless signals. The UE also comprises radio front-end circuitry connected to the antenna and to processing circuitry, and configured to condition signals communicated between the antenna and the processing circuitry. The processing circuitry is configured to perform any of the steps of any of the embodiments described above for the aerial communication device 10. In some embodiments, the UE also comprises an input interface connected to the processing circuitry and configured to allow input of information into the UE to be processed by the processing circuitry. The UE may comprise an output interface connected to the processing circuitry and configured to output information from the UE that has been processed by the processing circuitry. The UE may also comprise a battery connected to the processing circuitry and configured to supply power to the UE.

[0169] Embodiments herein also include a network node 14 configured to perform any of the steps of any of the embodiments described above for the network node 14.

[0170] Embodiments also include a network node 14 comprising processing circuitry and power supply circuitry. The processing circuitry is configured to perform any of the steps of any of the embodiments described above for the network node 14. The power supply circuitry is configured to supply power to the network node 14.

[0171] Embodiments further include a network node 14 comprising processing circuitry. The processing circuitry is configured to perform any of the steps of any of the embodiments described above for the network node 14. In some embodiments, the network node 14 further comprises communication circuitry.

[0172] Embodiments further include a network node 14 comprising processing circuitry and memory. The memory contains instructions executable by the processing circuitry whereby the network node 14 is configured to perform any of the steps of any of the embodiments described above for the network node 14.

[0173] More particularly, the apparatuses described above may perform the methods herein and any other processing by implementing any functional means, modules, units, or circuitry. In one embodiment, for example, the apparatuses comprise respective circuits or circuitry configured to perform the steps shown in the method figures. The circuits or circuitry in this regard may comprise circuits dedicated to performing certain functional processing and / or one  or more microprocessors in conjunction with memory. For instance, the circuitry may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs) , special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as read-only memory (ROM) , random-access memory, cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory may include program instructions for executing one or more telecommunications and / or data communications protocols as well as instructions for carrying out one or more of the techniques described herein, in several embodiments. In embodiments that employ memory, the memory stores program code that, when executed by the one or more processors, carries out the techniques described herein.

[0174] Figure 7 for example illustrates an aerial communication device 10 as implemented in accordance with one or more embodiments. As shown, the aerial communication device 10 includes processing circuitry 710 and communication circuitry 720. The communication circuitry 720 (e.g., radio circuitry) is configured to transmit and / or receive information to and / or from one or more other nodes, e.g., via any communication technology. Such communication may occur via one or more antennas that are either internal or external to the communication device 700. The processing circuitry 710 is configured to perform processing described above, e.g., in Figure 5, such as by executing instructions stored in memory 730. The processing circuitry 710 in this regard may implement certain functional means, units, or modules.

[0175] Figure 8 illustrates a network node 14 as implemented in accordance with one or more embodiments. As shown, the network node 14includes processing circuitry 810 and communication circuitry 820. The communication circuitry 820 is configured to transmit and / or receive information to and / or from one or more other nodes, e.g., via any communication technology. The processing circuitry 810 is configured to perform processing described above, e.g., in Figure 6, such as by executing instructions stored in memory 830. The processing circuitry 810 in this regard may implement certain functional means, units, or modules.

[0176] Those skilled in the art will also appreciate that embodiments herein further include corresponding computer programs.

[0177] A computer program comprises instructions which, when executed on at least one processor of an apparatus, cause the apparatus to carry out any of the respective processing described above. A computer program in this regard may comprise one or more code modules corresponding to the means or units described above.

[0178] Embodiments further include a carrier containing such a computer program. This carrier may comprise one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

[0179] In this regard, embodiments herein also include a computer program product stored on a non-transitory computer readable (storage or recording) medium and comprising instructions  that, when executed by a processor of an apparatus, cause the apparatus to perform as described above.

[0180] Embodiments further include a computer program product comprising program code portions for performing the steps of any of the embodiments herein when the computer program product is executed by a computing device. This computer program product may be stored on a computer readable recording medium.

[0181] Figure 9 shows an example of a communication system 900 in accordance with some embodiments.

[0182] In the example, the communication system 900 includes a telecommunication network 902 that includes an access network 904, such as a radio access network (RAN) , and a core network 906, which includes one or more core network nodes 908. The access network 904 includes one or more access network nodes, such as network nodes 910a and 910b (one or more of which may be generally referred to as network nodes 910) , or any other similar 3rd Generation Partnership Project (3GPP) access nodes or non-3GPP access points. Moreover, as will be appreciated by those of skill in the art, a network node is not necessarily limited to an implementation in which a radio portion and a baseband portion are supplied and integrated by a single vendor. Thus, it will be understood that network nodes include disaggregated implementations or portions thereof. For example, in some embodiments, the telecommunication network 902 includes one or more Open-RAN (ORAN) network nodes. An ORAN network node is a node in the telecommunication network 902 that supports an ORAN specification (e.g., a specification published by the O-RAN Alliance, or any similar organization) and may operate alone or together with other nodes to implement one or more functionalities of any node in the telecommunication network 902, including one or more network nodes 910 and / or core network nodes 908.

[0183] Examples of an ORAN network node include an open radio unit (O-RU) , an open distributed unit (O-DU) , an open central unit (O-CU) , including an O-CU control plane (O-CU-CP) or an O-CU user plane (O-CU-UP) , a RAN intelligent controller (near-real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time control application (e.g., rApp) , or any combination thereof (the adjective “open” designating support of an ORAN specification) . The network node may support a specification by, for example, supporting an interface defined by the ORAN specification, such as an A1, F1, W1, E1, E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an ORAN access node may be a logical node in a physical node. Furthermore, an ORAN network node may be implemented in a virtualization environment (described further below) in which one or more network functions are virtualized. For example, the virtualization environment may include an O-Cloud computing platform orchestrated by a Service Management and Orchestration Framework via an O-2 interface defined by the O-RAN Alliance or comparable technologies.  The network nodes 910 facilitate direct or indirect connection of user equipment (UE) , such as by connecting UEs 912a, 912b, 912c, and 912d (one or more of which may be generally referred to as UEs 912) to the core network 906 over one or more wireless connections.

[0184] Example wireless communications over a wireless connection include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, the communication system 900 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals whether via wired or wireless connections. The communication system 900 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system.

[0185] The UEs 912 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and / or operable to communicate wirelessly with the network nodes 910 and other communication devices. Similarly, the network nodes 910 are arranged, capable, configured, and / or operable to communicate directly or indirectly with the UEs 912 and / or with other network nodes or equipment in the telecommunication network 902 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in the telecommunication network 902.

[0186] In the depicted example, the core network 906 connects the network nodes 910 to one or more hosts, such as host 916. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network 906 includes one more core network nodes (e.g., core network node 908) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and / or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 908. Example core network nodes include functions of one or more of a Mobile Switching Center (MSC) , Mobility Management Entity (MME) , Home Subscriber Server (HSS) , Access and Mobility Management Function (AMF) , Session Management Function (SMF) , Authentication Server Function (AUSF) , Subscription Identifier De-concealing function (SIDF) , Unified Data Management (UDM) , Security Edge Protection Proxy (SEPP) , Network Exposure Function (NEF) , and / or a User Plane Function (UPF) .

[0187] The host 916 may be under the ownership or control of a service provider other than an operator or provider of the access network 904 and / or the telecommunication network 902, and may be operated by the service provider or on behalf of the service provider. The host 916 may host a variety of applications to provide one or more service. Examples of such applications include live and pre-recorded audio / video content, data collection services such as retrieving  and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server.

[0188] As a whole, the communication system 900 of Figure 9 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM) ; Universal Mobile Telecommunications System (UMTS) ; Long Term Evolution (LTE) , and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G) ; wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi) ; and / or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax) , Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and / or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox.

[0189] In some examples, the telecommunication network 902 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunications network 902 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 902. For example, the telecommunications network 902 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and / or Massive Machine Type Communication (mMTC)  / Massive IoT services to yet further UEs.

[0190] In some examples, the UEs 912 are configured to transmit and / or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network 904 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 904. Additionally, a UE may be configured for operating in single-or multi-RAT or multi-standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multi-radio dual connectivity (MR-DC) , such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio –Dual Connectivity (EN-DC) .

[0191] In the example, the hub 914 communicates with the access network 904 to facilitate indirect communication between one or more UEs (e.g., UE 912c and / or 912d) and network nodes (e.g., network node 910b) . In some examples, the hub 914 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub 914 may be a broadband router enabling access to the core network 906 for the UEs. As another example, the hub 914 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes 910, or by executable code, script, process, or other  instructions in the hub 914. As another example, the hub 914 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub 914 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, the hub 914 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 914 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In still another example, the hub 914 acts as a proxy server or orchestrator for the UEs, in particular if one or more of the UEs are low energy IoT devices.

[0192] The hub 914 may have a constant / persistent or intermittent connection to the network node 910b. The hub 914 may also allow for a different communication scheme and / or schedule between the hub 914 and UEs (e.g., UE 912c and / or 912d) , and between the hub 914 and the core network 906. In other examples, the hub 914 is connected to the core network 906 and / or one or more UEs via a wired connection. Moreover, the hub 914 may be configured to connect to an M2M service provider over the access network 904 and / or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes 910 while still connected via the hub 914 via a wired or wireless connection. In some embodiments, the hub 914 may be a dedicated hub –that is, a hub whose primary function is to route communications to / from the UEs from / to the network node 910b. In other embodiments, the hub 914 may be a non-dedicated hub –that is, a device which is capable of operating to route communications between the UEs and network node 910b, but which is additionally capable of operating as a communication start and / or end point for certain data channels.

[0193] Figure 10 shows a UE 1000 in accordance with some embodiments. As used herein, a UE refers to a device capable, configured, arranged and / or operable to communicate wirelessly with network nodes and / or other UEs. Examples of a UE include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA) , wireless cameras, gaming console or device, music storage device, playback appliance, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE) , laptop-mounted equipment (LME) , smart device, wireless customer-premise equipment (CPE) , vehicle, vehicle-mounted or vehicle embedded / integrated wireless device, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP) , including a narrow band internet of things (NB-IoT) UE, a machine type communication (MTC) UE, and / or an enhanced MTC (eMTC) UE.

[0194] A UE may support device-to-device (D2D) communication, for example by implementing a 3GPP standard for sidelink communication, Dedicated Short-Range Communication (DSRC) , vehicle-to-vehicle (V2V) , vehicle-to-infrastructure (V2I) , or vehicle-to-everything (V2X) . In other examples, a UE may not necessarily have a user in the sense of a human user who owns and / or operates the relevant device. Instead, a UE may represent a device that is intended for  sale to, or operation by, a human user but which may not, or which may not initially, be associated with a specific human user (e.g., a smart sprinkler controller) . Alternatively, a UE may represent a device that is not intended for sale to, or operation by, an end user but which may be associated with or operated for the benefit of a user (e.g., a smart power meter) .

[0195] The UE 1000 includes processing circuitry 1002 that is operatively coupled via a bus 1004 to an input / output interface 1006, a power source 1008, a memory 1010, a communication interface 1012, and / or any other component, or any combination thereof. Certain UEs may utilize all or a subset of the components shown in Figure 10. The level of integration between the components may vary from one UE to another UE. Further, certain UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0196] The processing circuitry 1002 is configured to process instructions and data and may be configured to implement any sequential state machine operative to execute instructions stored as machine-readable computer programs in the memory 1010. The processing circuitry 1002 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field-programmable gate arrays (FPGAs) , application specific integrated circuits (ASICs) , etc. ) ; programmable logic together with appropriate firmware; one or more stored computer programs, general-purpose processors, such as a microprocessor or digital signal processor (DSP) , together with appropriate software; or any combination of the above. For example, the processing circuitry 1002 may include multiple central processing units (CPUs) .

[0197] In the example, the input / output interface 1006 may be configured to provide an interface or interfaces to an input device, output device, or one or more input and / or output devices. Examples of an output device include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smartcard, another output device, or any combination thereof. An input device may allow a user to capture information into the UE 1000. Examples of an input device include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a web camera, etc. ) , a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smartcard, and the like. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. A sensor may be, for instance, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as an input device. For example, a Universal Serial Bus (USB) port may be used to provide an input device and an output device.

[0198] In some embodiments, the power source 1008 is structured as a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet) , photovoltaic device, or power cell, may be used. The power source 1008 may further include power circuitry for delivering power from the power source 1008 itself, and / or an external power  source, to the various parts of the UE 1000 via input circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging of the power source 1008. Power circuitry may perform any formatting, converting, or other modification to the power from the power source 1008 to make the power suitable for the respective components of the UE 1000 to which power is supplied.

[0199] The memory 1010 may be or be configured to include memory such as random access memory (RAM) , read-only memory (ROM) , programmable read-only memory (PROM) , erasable programmable read-only memory (EPROM) , electrically erasable programmable read-only memory (EEPROM) , magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, the memory 1010 includes one or more application programs 1014, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data 1016. The memory 1010 may store, for use by the UE 1000, any of a variety of various operating systems or combinations of operating systems.

[0200] The memory 1010 may be configured to include a number of physical drive units, such as redundant array of independent disks (RAID) , flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, high-density digital versatile disc (HD-DVD) optical disc drive, internal hard disk drive, Blu-Ray optical disc drive, holographic digital data storage (HDDS) optical disc drive, external mini-dual in-line memory module (DIMM) , synchronous dynamic random access memory (SDRAM) , external micro-DIMM SDRAM, smartcard memory such as tamper resistant module in the form of a universal integrated circuit card (UICC) including one or more subscriber identity modules (SIMs) , such as a USIM and / or ISIM, other memory, or any combination thereof. The UICC may for example be an embedded UICC (eUICC) , integrated UICC (iUICC) or a removable UICC commonly known as ‘SIM card. ’ The memory 1010 may allow the UE 1000 to access instructions, application programs and the like, stored on transitory or non-transitory memory media, to off-load data, or to upload data. An article of manufacture, such as one utilizing a communication system may be tangibly embodied as or in the memory 1010, which may be or comprise a device-readable storage medium.

[0201] The processing circuitry 1002 may be configured to communicate with an access network or other network using the communication interface 1012. The communication interface 1012 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna 1022. The communication interface 1012 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or a network node in an access network) . Each transceiver may include a transmitter 1018 and / or a receiver 1020 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth) . Moreover, the transmitter 1018 and receiver 1020 may be  coupled to one or more antennas (e.g., antenna 1022) and may share circuit components, software or firmware, or alternatively be implemented separately.

[0202] In the illustrated embodiment, communication functions of the communication interface 1012 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communications such as Bluetooth, near-field communication, location-based communication such as the use of the global positioning system (GPS) to determine a location, another like communication function, or any combination thereof. Communications may be implemented in according to one or more communication protocols and / or standards, such as IEEE 802.11, Code Division Multiplexing Access (CDMA) , Wideband Code Division Multiple Access (WCDMA) , GSM, LTE, New Radio (NR) , UMTS, WiMax, Ethernet, transmission control protocol / internet protocol (TCP / IP) , synchronous optical networking (SONET) , Asynchronous Transfer Mode (ATM) , QUIC, Hypertext Transfer Protocol (HTTP) , and so forth.

[0203] Regardless of the type of sensor, a UE may provide an output of data captured by its sensors, through its communication interface 1012, via a wireless connection to a network node. Data captured by sensors of a UE can be communicated through a wireless connection to a network node via another UE. The output may be periodic (e.g., once every 15 minutes if it reports the sensed temperature) , random (e.g., to even out the load from reporting from several sensors) , in response to a triggering event (e.g., when moisture is detected an alert is sent) , in response to a request (e.g., a user initiated request) , or a continuous stream (e.g., a live video feed of a patient) .

[0204] As another example, a UE comprises an actuator, a motor, or a switch, related to a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input the states of the actuator, the motor, or the switch may change. For example, the UE may comprise a motor that adjusts the control surfaces or rotors of a drone in flight according to the received input or to a robotic arm performing a medical procedure according to the received input.

[0205] A UE, when in the form of an Internet of Things (IoT) device, may be a device for use in one or more application domains, these domains comprising, but not limited to, city wearable technology, extended industrial application and healthcare. Non-limiting examples of such an IoT device are a device which is or which is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door / window sensor, a flood / moisture sensor, an electrical door lock, a connected doorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a head-mounted display for Augmented Reality (AR) or Virtual Reality (VR) , a wearable for tactile augmentation or sensory enhancement, a water  sprinkler, an animal-or item-tracking device, a sensor for monitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV) , and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. A UE in the form of an IoT device comprises circuitry and / or software in dependence of the intended application of the IoT device in addition to other components as described in relation to the UE 1000 shown in Figure 10.

[0206] As yet another specific example, in an IoT scenario, a UE may represent a machine or other device that performs monitoring and / or measurements, and transmits the results of such monitoring and / or measurements to another UE and / or a network node. The UE may in this case be an M2M device, which may in a 3GPP context be referred to as an MTC device. As one particular example, the UE may implement the 3GPP NB-IoT standard. In other scenarios, a UE may represent a vehicle, such as a car, a bus, a truck, a ship and an airplane, or other equipment that is capable of monitoring and / or reporting on its operational status or other functions associated with its operation.

[0207] In practice, any number of UEs may be used together with respect to a single use case. For example, a first UE might be or be integrated in a drone and provide the drone’s speed information (obtained through a speed sensor) to a second UE that is a remote controller operating the drone. When the user makes changes from the remote controller, the first UE may adjust the throttle on the drone (e.g. by controlling an actuator) to increase or decrease the drone’s speed. The first and / or the second UE can also include more than one of the functionalities described above. For example, a UE might comprise the sensor and the actuator, and handle communication of data for both the speed sensor and the actuators.

[0208] Figure 11 shows a network node 1100 in accordance with some embodiments. As used herein, network node refers to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or equipment, in a telecommunication network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points) , base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs) and NR NodeBs (gNBs) ) , O-RAN nodes or components of an O-RAN node (e.g., O-RU, O-DU, O-CU) .

[0209] Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and so, depending on the provided amount of coverage, may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node controlling a relay. A network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units, distributed units (e.g., in an O-RAN access node) and / or remote radio units (RRUs) , sometimes referred to as Remote Radio Heads (RRHs) . Such remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS) .

[0210] Other examples of network nodes include multiple transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs) , base transceiver stations (BTSs) , transmission points, transmission nodes, multi-cell / multicast coordination entities (MCEs) , Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes, Self-Organizing Network (SON) nodes, positioning nodes (e.g., Evolved Serving Mobile Location Centers (E-SMLCs) ) , and / or Minimization of Drive Tests (MDTs) .

[0211] The network node 1100 includes a processing circuitry 1102, a memory 1104, a communication interface 1106, and a power source 1108. The network node 1100 may be composed of multiple physically separate components (e.g., a NodeB component and a RNC component, or a BTS component and a BSC component, etc. ) , which may each have their own respective components. In certain scenarios in which the network node 1100 comprises multiple separate components (e.g., BTS and BSC components) , one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, the network node 1100 may be configured to support multiple radio access technologies (RATs) . In such embodiments, some components may be duplicated (e.g., separate memory 1104 for different RATs) and some components may be reused (e.g., a same antenna 1110 may be shared by different RATs) . The network node 1100 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 1100, for example GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, Radio Frequency Identification (RFID) or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within network node 1100.

[0212] The processing circuitry 1102 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and / or encoded logic operable to provide, either alone or in conjunction with other network node 1100 components, such as the memory 1104, to provide network node 1100 functionality.

[0213] In some embodiments, the processing circuitry 1102 includes a system on a chip (SOC) . In some embodiments, the processing circuitry 1102 includes one or more of radio frequency (RF) transceiver circuitry 1112 and baseband processing circuitry 1114. In some embodiments, the radio frequency (RF) transceiver circuitry 1112 and the baseband processing circuitry 1114 may be on separate chips (or sets of chips) , boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry 1112 and baseband processing circuitry 1114 may be on the same chip or set of chips, boards, or units.

[0214] The memory 1104 may comprise any form of volatile or non-volatile computer-readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM) , read-only memory (ROM) , mass storage media (for example, a hard disk) , removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD) ) , and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory devices that store information, data, and / or instructions that may be used by the processing circuitry 1102. The memory 1104 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and / or other instructions capable of being executed by the processing circuitry 1102 and utilized by the network node 1100. The memory 1104 may be used to store any calculations made by the processing circuitry 1102 and / or any data received via the communication interface 1106. In some embodiments, the processing circuitry 1102 and memory 1104 is integrated.

[0215] The communication interface 1106 is used in wired or wireless communication of signaling and / or data between a network node, access network, and / or UE. As illustrated, the communication interface 1106 comprises port (s)  / terminal (s) 1116 to send and receive data, for example to and from a network over a wired connection. The communication interface 1106 also includes radio front-end circuitry 1118 that may be coupled to, or in certain embodiments a part of, the antenna 1110. Radio front-end circuitry 1118 comprises filters 1120 and amplifiers 1122. The radio front-end circuitry 1118 may be connected to an antenna 1110 and processing circuitry 1102. The radio front-end circuitry may be configured to condition signals communicated between antenna 1110 and processing circuitry 1102. The radio front-end circuitry 1118 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. The radio front-end circuitry 1118 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters 1120 and / or amplifiers 1122. The radio signal may then be transmitted via the antenna 1110. Similarly, when receiving data, the antenna 1110 may collect radio signals which are then converted into digital data by the radio front-end circuitry 1118. The digital data may be passed to the processing circuitry 1102. In other embodiments, the communication interface may comprise different components and / or different combinations of components.

[0216] In certain alternative embodiments, the network node 1100 does not include separate radio front-end circuitry 1118, instead, the processing circuitry 1102 includes radio front-end circuitry and is connected to the antenna 1110. Similarly, in some embodiments, all or some of the RF transceiver circuitry 1112 is part of the communication interface 1106. In still other embodiments, the communication interface 1106 includes one or more ports or terminals 1116, the radio front-end circuitry 1118, and the RF transceiver circuitry 1112, as part of a radio unit (not shown) , and the communication interface 1106 communicates with the baseband processing circuitry 1114, which is part of a digital unit (not shown) .

[0217] The antenna 1110 may include one or more antennas, or antenna arrays, configured to send and / or receive wireless signals. The antenna 1110 may be coupled to the radio front-end circuitry 1118 and may be any type of antenna capable of transmitting and receiving data and / or signals wirelessly. In certain embodiments, the antenna 1110 is separate from the network node 1100 and connectable to the network node 1100 through an interface or port.

[0218] The antenna 1110, communication interface 1106, and / or the processing circuitry 1102 may be configured to perform any receiving operations and / or certain obtaining operations described herein as being performed by the network node. Any information, data and / or signals may be received from a UE, another network node and / or any other network equipment. Similarly, the antenna 1110, the communication interface 1106, and / or the processing circuitry 1102 may be configured to perform any transmitting operations described herein as being performed by the network node. Any information, data and / or signals may be transmitted to a UE, another network node and / or any other network equipment.

[0219] The power source 1108 provides power to the various components of network node 1100 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component) . The power source 1108 may further comprise, or be coupled to, power management circuitry to supply the components of the network node 1100 with power for performing the functionality described herein. For example, the network node 1100 may be connectable to an external power source (e.g., the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source 1108. As a further example, the power source 1108 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail.

[0220] Embodiments of the network node 1100 may include additional components beyond those shown in Figure 11 for providing certain aspects of the network node’s functionality, including any of the functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, the network node 1100 may include user interface equipment to allow input of information into the network node 1100 and to allow output of information from the network node 1100. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node 1100.

[0221] Figure 12 is a block diagram of a host 1200, which may be an embodiment of the host 916 of Figure 9, in accordance with various aspects described herein. As used herein, the host 1200 may be or comprise various combinations hardware and / or software, including a standalone server, a blade server, a cloud-implemented server, a distributed server, a virtual machine, container, or processing resources in a server farm. The host 1200 may provide one or more services to one or more UEs.

[0222] The host 1200 includes processing circuitry 1202 that is operatively coupled via a bus 1204 to an input / output interface 1206, a network interface 1208, a power source 1210, and a memory 1212. Other components may be included in other embodiments. Features of these components may be substantially similar to those described with respect to the devices of previous figures, such as Figures 10 and 11, such that the descriptions thereof are generally applicable to the corresponding components of host 1200.

[0223] The memory 1212 may include one or more computer programs including one or more host application programs 1214 and data 1216, which may include user data, e.g., data generated by a UE for the host 1200 or data generated by the host 1200 for a UE. Embodiments of the host 1200 may utilize only a subset or all of the components shown. The host application programs 1214 may be implemented in a container-based architecture and may provide support for video codecs (e.g., Versatile Video Coding (VVC) , High Efficiency Video Coding (HEVC) , Advanced Video Coding (AVC) , MPEG, VP9) and audio codecs (e.g., FLAC, Advanced Audio Coding (AAC) , MPEG, G. 711) , including transcoding for multiple different classes, types, or implementations of UEs (e.g., handsets, desktop computers, wearable display systems, heads-up display systems) . The host application programs 1214 may also provide for user authentication and licensing checks and may periodically report health, routes, and content availability to a central node, such as a device in or on the edge of a core network. Accordingly, the host 1200 may select and / or indicate a different host for over-the-top services for a UE. The host application programs 1214 may support various protocols, such as the HTTP Live Streaming (HLS) protocol, Real-Time Messaging Protocol (RTMP) , Real-Time Streaming Protocol (RTSP) , Dynamic Adaptive Streaming over HTTP (MPEG-DASH) , etc.

[0224] Figure 13 is a block diagram illustrating a virtualization environment 1300 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 1300 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host) , then the node may be entirely virtualized. In some embodiments, the virtualization environment 1300 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated by a Service Management and Orchestration Framework via an O-2 interface.

[0225] Applications 1302 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc. ) are run in the virtualization environment Q400 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein.

[0226] Hardware 1304 includes processing circuitry, memory that stores software and / or instructions executable by hardware processing circuitry, and / or other hardware devices as described herein, such as a network interface, input / output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 1306 (also referred to as hypervisors or virtual machine monitors (VMMs) ) , provide VMs 1308a and 1308b (one or more of which may be generally referred to as VMs 1308) , and / or perform any of the functions, features and / or benefits described in relation with some embodiments described herein. The virtualization layer 1306 may present a virtual operating platform that appears like networking hardware to the VMs 1308.

[0227] The VMs 1308 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 1306. Different embodiments of the instance of a virtual appliance 1302 may be implemented on one or more of VMs 1308, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV) . NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.

[0228] In the context of NFV, a VM 1308 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs 1308, and that part of hardware 1304 that executes that VM, be it hardware dedicated to that VM and / or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 1308 on top of the hardware 1304 and corresponds to the application 1302.

[0229] Hardware 1304 may be implemented in a standalone network node with generic or specific components. Hardware 1304 may implement some functions via virtualization. Alternatively, hardware 1304 may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 1310, which, among others, oversees lifecycle management of applications 1302. In some embodiments, hardware 1304 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In  some embodiments, some signaling can be provided with the use of a control system 1312 which may alternatively be used for communication between hardware nodes and radio units.

[0230] Figure 14 shows a communication diagram of a host 1402 communicating via a network node 1404 with a UE 1406 over a partially wireless connection in accordance with some embodiments. Example implementations, in accordance with various embodiments, of the UE (such as a UE 912a of Figure 9 and / or UE 1000 of Figure 10) , network node (such as network node 910a of Figure 9 and / or network node 1100 of Figure 11) , and host (such as host 916 of Figure 9 and / or host 1200 of Figure 12) discussed in the preceding paragraphs will now be described with reference to Figure 14.

[0231] Like host 1200, embodiments of host 1402 include hardware, such as a communication interface, processing circuitry, and memory. The host 1402 also includes software, which is stored in or accessible by the host 1402 and executable by the processing circuitry. The software includes a host application that may be operable to provide a service to a remote user, such as the UE 1406 connecting via an over-the-top (OTT) connection 1450 extending between the UE 1406 and host 1402. In providing the service to the remote user, a host application may provide user data which is transmitted using the OTT connection 1450.

[0232] The network node 1404 includes hardware enabling it to communicate with the host 1402 and UE 1406. The connection 1460 may be direct or pass through a core network (like core network 906 of Figure 9) and / or one or more other intermediate networks, such as one or more public, private, or hosted networks. For example, an intermediate network may be a backbone network or the Internet.

[0233] The UE 1406 includes hardware and software, which is stored in or accessible by UE 1406 and executable by the UE’s processing circuitry. The software includes a client application, such as a web browser or operator-specific “app” that may be operable to provide a service to a human or non-human user via UE 1406 with the support of the host 1402. In the host 1402, an executing host application may communicate with the executing client application via the OTT connection 1450 terminating at the UE 1406 and host 1402. In providing the service to the user, the UE's client application may receive request data from the host's host application and provide user data in response to the request data. The OTT connection 1450 may transfer both the request data and the user data. The UE's client application may interact with the user to generate the user data that it provides to the host application through the OTT connection 1450.

[0234] The OTT connection 1450 may extend via a connection 1460 between the host 1402 and the network node 1404 and via a wireless connection 1470 between the network node 1404 and the UE 1406 to provide the connection between the host 1402 and the UE 1406. The connection 1460 and wireless connection 1470, over which the OTT connection 1450 may be provided, have been drawn abstractly to illustrate the communication between the host 1402  and the UE 1406 via the network node 1404, without explicit reference to any intermediary devices and the precise routing of messages via these devices.

[0235] As an example of transmitting data via the OTT connection 1450, in step 1408, the host 1402 provides user data, which may be performed by executing a host application. In some embodiments, the user data is associated with a particular human user interacting with the UE 1406. In other embodiments, the user data is associated with a UE 1406 that shares data with the host 1402 without explicit human interaction. In step 1410, the host 1402 initiates a transmission carrying the user data towards the UE 1406. The host 1402 may initiate the transmission responsive to a request transmitted by the UE 1406. The request may be caused by human interaction with the UE 1406 or by operation of the client application executing on the UE 1406. The transmission may pass via the network node 1404, in accordance with the teachings of the embodiments described throughout this disclosure. Accordingly, in step 1412, the network node 1404 transmits to the UE 1406 the user data that was carried in the transmission that the host 1402 initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In step 1414, the UE 1406 receives the user data carried in the transmission, which may be performed by a client application executed on the UE 1406 associated with the host application executed by the host 1402.

[0236] In some examples, the UE 1406 executes a client application which provides user data to the host 1402. The user data may be provided in reaction or response to the data received from the host 1402. Accordingly, in step 1416, the UE 1406 may provide user data, which may be performed by executing the client application. In providing the user data, the client application may further consider user input received from the user via an input / output interface of the UE 1406. Regardless of the specific manner in which the user data was provided, the UE 1406 initiates, in step 1418, transmission of the user data towards the host 1402 via the network node 1404. In step 1420, in accordance with the teachings of the embodiments described throughout this disclosure, the network node 1404 receives user data from the UE 1406 and initiates transmission of the received user data towards the host 1402. In step 1422, the host 1402 receives the user data carried in the transmission initiated by the UE 1406.

[0237] One or more of the various embodiments improve the performance of OTT services provided to the UE 1406 using the OTT connection 1450, in which the wireless connection 1470 forms the last segment.

[0238] In an example scenario, factory status information may be collected and analyzed by the host 1402. As another example, the host 1402 may process audio and video data which may have been retrieved from a UE for use in creating maps. As another example, the host 1402 may collect and analyze real-time data to assist in controlling vehicle congestion (e.g., controlling traffic lights) . As another example, the host 1402 may store surveillance video uploaded by a UE. As another example, the host 1402 may store or control access to media content such as video, audio, VR or AR which it can broadcast, multicast or unicast to UEs. As  other examples, the host 1402 may be used for energy pricing, remote control of non-time critical electrical load to balance power generation needs, location services, presentation services (such as compiling diagrams etc. from data collected from remote devices) , or any other function of collecting, retrieving, storing, analyzing and / or transmitting data.

[0239] In some examples, a measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection 1450 between the host 1402 and UE 1406, in response to variations in the measurement results. The measurement procedure and / or the network functionality for reconfiguring the OTT connection may be implemented in software and hardware of the host 1402 and / or UE 1406. In some embodiments, sensors (not shown) may be deployed in or in association with other devices through which the OTT connection 1450 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software may compute or estimate the monitored quantities. The reconfiguring of the OTT connection 1450 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not directly alter the operation of the network node 1404. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling that facilitates measurements of throughput, propagation times, latency and the like, by the host 1402. The measurements may be implemented in that software causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection 1450 while monitoring propagation times, errors, etc.

[0240] Although the computing devices described herein (e.g., UEs, network nodes, hosts) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and / or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and / or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the components may be partitioned between the processing circuitry and the communication  interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

[0241] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer-readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally.

[0242] Notably, modifications and other embodiments of the present disclosure will come to mind to one skilled in the art having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the present disclosure is not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of this disclosure. Although specific terms may be employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims

1.A method performed by an aerial communication device (10) , the method comprising:detecting that each of one or more logging trigger conditions (20C) in a log trigger set (20) are met, wherein the one or more logging trigger conditions (20C) include a path change condition that is met upon a targeted flight path (16T) of the aerial communication device (10) changing to or from a planned flight path (16P) , wherein the planned flight path (16P) is a path of flight that the aerial communication device (10) plans to follow absent occurrence of a contingency; andbased on detecting that each of the one or more logging trigger conditions (20C) in the log trigger set (20) are met, logging aerial-specific operational data (18) at the aerial communication device (10) describing aerial operation of the aerial communication device (10) .2.The method of claim 1, wherein the path change condition is met upon the targeted flight path (16T) of the aerial communication device (10) changing from the planned flight back to a backup flight path, wherein the backup flight path is a path of flight that the aerial communication device (10) reverts to upon occurrence of a contingency.3.The method of claim 2, wherein the planned flight path (16P) is planned before initiation of the aerial communication device (10) along the planned flight path (16P) .4.The method of any of claims 2-3, wherein the backup flight path is predetermined or preconfigured at the aerial communication device (10) , or configured by a network node of a communication network, but does not further a purpose of the planned flight path (16P) .5.The method of any of claims 1-4, wherein the planned flight path (16P) is a path of flight that the aerial communication device (10) plans to follow absent occurrence of a contingency deemed by the aerial communication device (10) as a critical or emergency contingency.6.The method of claim 5, wherein a critical or emergency contingency includes one or more of:inability of the aerial communication device (10) to fly;inability of the aerial communication device (10) to fly along the planned flight path (16P) ;an emergency landing of the aerial communication device (10) ;malfunctioning of the aerial communication device (10) ;a battery level of the aerial communication device (10) falling below a minimum threshold;a fuel level of the aerial communication device (10) falling below a minimum threshold; oractual or expected collision with an object.7.The method of any of claims 1-6, wherein the aerial-specific operational data (18) includes:data indicating the planned flight path (16P) ; anddata indicating a flight path to or from which the targeted flight path (16T) was changed.8.The method of any of claims 1-7, wherein the aerial-specific operational data (18) includes:data indicating a reason for the targeted flight path (16T) changing to or from the planned flight path (16P) ;data indicating a time and / or location of the aerial communication device (10) when the targeted flight path (16T) was changed to or from the planned flight path (16P) ;data describing an aerial-specific maneuver detected by the aerial communication device (10) upon detecting that each of the one or more logging trigger conditions (20C) are met; and / ordata describing an aerial mobility state of the aerial communication device (10) , wherein the aerial mobility state includes one or more of a speed, acceleration, direction of movement, or altitude of the aerial communication device (10) .9.The method of any of claims 1-8, wherein the one or more logging trigger conditions (20C) in the log trigger set (20) further include one or more of:a speed change condition that is met upon a speed of the aerial communication device (10) changing by more than a speed change threshold;a direction change condition that is met upon a direction of movement of the aerial communication device (10) changing by more than a direction change threshold;an altitude change condition that is met upon an altitude of the aerial communication device (10) changing by more than an altitude change threshold;a maneuver condition that is met upon the aerial communication device (10) performing one or more types of aerial maneuvers;a location change condition that is met upon a location of the aerial communication device (10) changing by more than a location change threshold;a time condition that is met upon a measured or estimated time at the aerial communication device (10) exceeding a time threshold or exceeding a sum of the time threshold and a defined duration;a waypoint condition that is met upon the aerial communication device (10) reaching a defined waypoint in the planned flight path (16P) ; and / ora received signal level (RSL) condition that is met upon a magnitude of a RSL of the aerial communication device (10) changing by more than a RSL change threshold.10.The method of any of claims 1-9, wherein logging the aerial-specific operational data (18) at the aerial communication device (10) comprises logging aerial-specific operational data (18) at the aerial communication device (10) on an ongoing or periodic basis, wherein the method further comprises, after starting to log the aerial-specific operational data (18) at the aerial communication device (10) :detecting that each of one or more logging stop conditions in a log stop set (22) are met; andbased on detecting that each of one or more logging stop conditions in the log stop set (22) are met, stopping logging the aerial-specific operational data (18) at the aerial communication device (10) .11.The method of claim 10, wherein each of the one or more logging stop conditions in the log stop set (22) is met if none of the one or more logging trigger conditions (20C) in the log trigger set (20) are met.12.The method of claim 10, wherein the one or more logging stop conditions in the log stop set (22) include one or more of:a path revert condition that is met upon the aerial communication device (10) reverting to the planned flight path (16P) ;a timer condition that is met upon expiry of a timer started by the aerial communication device (10) upon starting logging of the aerial-specific operational data (18) ;a stable state condition that is met when a flight path, altitude, location, and / or speed of the aerial communication device (10) has remained stable for a threshold duration of time;a maneuver absence condition that is met when the aerial communication device (10) has not detected any of one or more types of aerial-specific maneuvers having been performed for a threshold duration of time; and / ora stable received signal level (RSL) condition that is met upon a magnitude of a RSL of the aerial communication device (10) not changing by more than a RSL change threshold.13.The method of any of claims 1-12, further comprising receiving a configuration message (15) from a network node (14) requesting the aerial communication device (10) to log the aerial-specific operational data (18) upon detecting the one or more logging trigger conditions (20C) in the log trigger set (20) and / or to stop logging the aerial-specific operational data (18) upon detecting one or more logging stop conditions in a log stop set (22) .14.The method of any of claims 1-13, wherein the aerial-specific operational data (18) is logged as Minimization of Drive Test, MDT, data.15.The method of any of claims 1-14, further comprising reporting the logged aerial-specific operational data (18) to a network node (14) .16.A method performed by a network node (14) , the method comprising:receiving, from an aerial communication device (10) , aerial-specific operational data (18) logged at the aerial communication device (10) in association with each of one or more logging trigger conditions (20C) in a log trigger set (20) being met, wherein the one or more logging trigger conditions (20C) include a path change condition that is met upon a targeted flight path (16T) of the aerial communication device (10) changing to or from a planned flight path (16P) , wherein the planned flight path (16P) is a path of flight that the aerial communication device (10) plans to follow absent occurrence of a contingency, wherein the aerial-specific operational data (18) describes aerial operation of the aerial communication device (10) .17.The method of claim 16, wherein the path change condition is met upon the targeted flight path (16T) of the aerial communication device (10) changing from the planned flight back to a backup flight path, wherein the backup flight path is a path of flight that the aerial communication device (10) reverts to upon occurrence of a contingency.18.The method of claim 17, wherein the planned flight path (16P) is planned before initiation of the aerial communication device (10) along the planned flight path (16P) .19.The method of any of claims 17-18, wherein the backup flight path is predetermined or preconfigured at the aerial communication device (10) , or configured by the network node (14) , but does not further a purpose of the planned flight path (16P) .20.The method of any of claims 16-19, wherein the planned flight path (16P) is a path of flight that the aerial communication device (10) plans to follow absent occurrence of a contingency deemed by the aerial communication device (10) as a critical or emergency contingency.21.The method of claim 20, wherein a critical or emergency contingency includes one or more of:inability of the aerial communication device (10) to fly;inability of the aerial communication device (10) to fly along the planned flight path (16P) ;an emergency landing of the aerial communication device (10) ;malfunctioning of the aerial communication device (10) ;a battery level of the aerial communication device (10) falling below a minimum threshold;a fuel level of the aerial communication device (10) falling below a minimum threshold; oractual or expected collision with an object.22.The method of any of claims 16-21, wherein the aerial-specific operational data (18) includes:data indicating the planned flight path (16P) ; anddata indicating a flight path to or from which the targeted flight path (16T) was changed.23.The method of any of claims 16-22, wherein the aerial-specific operational data (18) includes:data indicating a reason for the targeted flight path (16T) changing to or from the planned flight path (16P) ;data indicating a time and / or location of the aerial communication device (10) when the targeted flight path (16T) was changed to or from the planned flight path (16P) ;data describing an aerial-specific maneuver detected by the aerial communication device (10) upon detecting that each of the one or more logging trigger conditions (20C) are met; and / ordata describing an aerial mobility state of the aerial communication device (10) , wherein the aerial mobility state includes one or more of a speed, acceleration, direction of movement, or altitude of the aerial communication device (10) .24.The method of any of claims 16-23, wherein the one or more logging trigger conditions (20C) in the log trigger set (20) further include one or more of:a speed change condition that is met upon a speed of the aerial communication device (10) changing by more than a speed change threshold;a direction change condition that is met upon a direction of movement of the aerial communication device (10) changing by more than a direction change threshold;an altitude change condition that is met upon an altitude of the aerial communication device (10) changing by more than an altitude change threshold;a maneuver condition that is met upon the aerial communication device (10) performing one or more types of aerial maneuvers;a location change condition that is met upon a location of the aerial communication device (10) changing by more than a location change threshold;a time condition that is met upon a measured or estimated time at the aerial communication device (10) exceeding a time threshold or exceeding a sum of the time threshold and a defined duration;a waypoint condition that is met upon the aerial communication device (10) reaching a defined waypoint in the planned flight path (16P) ; and / ora received signal level (RSL) condition that is met upon a magnitude of a RSL of the aerial communication device (10) changing by more than a RSL change threshold.25.The method of any of claims 16-24, wherein receiving the aerial-specific operational data (18) comprises receiving a log (10C) including the aerial-specific operational data (18) , wherein the log (10C) includes aerial-specific operational data (18) logged on an ongoing or periodic basis until each of one or more logging stop conditions in a log stop set (22) are met.26.The method of claim 25, wherein each of the one or more logging stop conditions in the log stop set (22) is met if none of the one or more logging trigger conditions (20C) in the log trigger set (20) are met.27.The method of claim 25, wherein the one or more logging stop conditions in the log stop set (22) include one or more of:a path revert condition that is met upon the aerial communication device (10) reverting to the planned flight path (16P) ;a timer condition that is met upon expiry of a timer started by the aerial communication device (10) upon starting logging of the aerial-specific operational data (18) ;a stable state condition that is met when a flight path, altitude, location, and / or speed of the aerial communication device (10) has remained stable for a threshold duration of time;a maneuver absence condition that is met when the aerial communication device (10) has not detected any of one or more types of aerial-specific maneuvers having been performed for a threshold duration of time; and / ora stable received signal level (RSL) condition that is met upon a magnitude of a RSL of the aerial communication device (10) not changing by more than a RSL change threshold.28.The method of any of claims 16-27, wherein the aerial-specific operational data (18) is logged as Minimization of Drive Test, MDT, data.29.The method of any of claims 16-28, further comprising performing one or more self-organizing network, SON, tasks based on the aerial-specific operational data (18) .30.The method of any of claims 16-29, further comprising configuring the aerial communication device (10) to log the aerial-specific operational data (18) upon detecting the one or more logging trigger conditions (20C) and / or to stop logging the aerial-specific operational data (18) upon detecting one or more logging stop conditions.31.An aerial communication device (10) configured to:detect that each of one or more logging trigger conditions (20C) in a log trigger set (20) are met, wherein the one or more logging trigger conditions (20C) include a path change condition that is met upon a targeted flight path (16T) of the aerial communication device (10) changing to or from a planned flight path (16P) , wherein the planned flight path (16P) is a path of flight that the aerial communication device (10) plans to follow absent occurrence of a contingency; andbased on detecting that each of the one or more logging trigger conditions (20C) in the log trigger set (20) are met, log aerial-specific operational data (18) at the aerial communication device (10) describing aerial operation of the aerial communication device (10) .32.The aerial communication device (10) of claim 31, configured to perform the method of any of claims 2-15.33.A network node (14) configured to:receive, from an aerial communication device (10) , aerial-specific operational data (18) logged at the aerial communication device (10) in association with each of one or more logging trigger conditions (20C) in a log trigger set (20) being met, wherein the one or more logging trigger conditions (20C) include a path change condition that is met upon a targeted flight path (16T) of the aerial communication device (10) changing to or from a planned flight path (16P) , wherein the planned flight path (16P) is a path of flight that the aerial communication device (10) plans to follow absent occurrence of a contingency, wherein the aerial-specific operational data (18) describes aerial operation of the aerial communication device (10) .34.The network node (14) of claim 33, configured to perform the method of any of claims 17-30.35.A computer program comprises instructions which, when executed on at least one processor of an aerial communication device (10) , cause the aerial communication device (10) to perform the method of any of claims 1-15.35.A computer program comprises instructions which, when executed on at least one processor of a network node (14) , cause the network node (14) to perform the method of any of claims 16-30.37.An aerial communication device (10) comprising:communication circuitry (720) ; andprocessing circuitry (710) configured to:detect that each of one or more logging trigger conditions (20C) in a log trigger set (20) are met, wherein the one or more logging trigger conditions (20C) include a path change condition that is met upon a targeted flight path (16T) of the aerial communication device (10) changing to or from a planned flight path (16P) , wherein the planned flight path (16P) is a path of flight that the aerial communication device (10) plans to follow absent occurrence of a contingency; andbased on detecting that each of the one or more logging trigger conditions (20C) in the log trigger set (20) are met, log aerial-specific operational data (18) at the aerial communication device (10) describing aerial operation of the aerial communication device (10) .38.The aerial communication device (10) of claim 37, the processing circuitry (710) configured to perform the method of any of claims 2-15.39.A network node (14) comprising:communication circuitry (820) ; andprocessing circuitry (810) configured to:receive, from an aerial communication device (10) , aerial-specific operational data (18) logged at the aerial communication device (10) in association with each of one or more logging trigger conditions (20C) in a log trigger set (20) being met, wherein the one or more logging trigger conditions (20C) include a path change condition that is met upon a targeted flight path (16T) of the aerial communication device (10) changing to or from a planned flight path (16P) , wherein the planned flight path (16P) is a path of flight that the aerial communication device (10) plans to follow absent occurrence of a contingency, wherein the aerial-specific operational data (18) describes aerial operation of the aerial communication device (10) .40.The network node (14) of claim 39, the processing circuitry (810) configured to perform the method of any of claims 17-30.

Citation Information

Patent Citations

  • Multi-use UAV docking station systems and methods

    US10112712B1

  • Aerial coverage mapping for wireless communications with aerial user equipment

    WO2022260976A1

  • MDT configuration and reporting for drone ues

    WO2022264086A1