Article citation information:

Piech, A., Kwapiński, M., Mickiewicz, M., Kanawka, K. LTE/GNSS IoT technology as a backbone for airport ground handling operations. Scientific Journal of Silesian University of Technology. Series Transport. 2022, 114, 131-142. ISSN: 0209-3324. DOI: https://doi.org/10.20858/sjsutst.2022.114.11.

 

 

Adam PIECH[1], Maciej KWAPIŃSKI[2], Maciej MICKIEWICZ[3], Krzysztof KANAWKA[4]

 

 

 

LTE/GNSS IOT TECHNOLOGY AS A BACKBONE FOR AIRPORT GROUND HANDLING OPERATIONS

 

Summary. The necessity of a positioning service for various ground handling assets is key to improving airport performance. Reported in this article is a system named “Ground Eye”, designed to be a test of a possible implementation of the independent LTE-based communication system and GNSS-based location services. The test campaign used a total of nine prototype devices for a period of one month at Gdańsk airport (Poland). The main goal of this demonstration was to verify the possibility of using the GNSS/LTE system as a fast-deployment option in the airport environment, as well as to evaluate its positioning and communication capabilities in conjunction with React.JS/Deck.GL/Node.JS dedicated application. The test campaign verified that even with simple processing and relatively simple single-frequency measurements, multi-constellation GNSS receivers, it is possible to obtain location with precision reaching better than 2.5 metres. This precision should be good enough for all ground handling operations at modern airports, without the need for additional fixed infrastructure.

Keywords: GNSS, LTE, IoT, asset tracking, ground handling

 

 

1. INTRODUCTION

 

Typical ground handling operations within any commercial airport that are capable of servicing passenger airplanes requires a multitude of ground support assets. Examples of assets are stairs, pushers, baggage carriers, and other small and medium-sized vehicles, as well as large and very specialised equipment such as container loaders. The larger the airport is, the more ground equipment it is required to accommodate for concurrent aircraft servicing. Even in a medium-sized airport, the number of assets can be counted in hundreds of items. However, the typical ground handling operations for the most part still rely on radio voice communications, even though airports are one of the areas where digital tracking systems were available early. Typically, as of 2021, these systems depend on multilateration positioning rather than direct GNSS service. Multilateration is not as flexible as direct GNSS measurements and it was not intended to cooperate with a large number of assets, which is the case of almost every airport.

However, there are many emerging technologies, especially in the range of IoT solutions that can have an impact on airport operations and compete with multilateration. IoT or the Internet of Things typically refer to low-power devices that are capable of sending various information including positioning information as in the case of asset trackers. Although IoT is a relatively new concept, the general idea behind the technology is not that different from the concepts that have been used in airports. Hence, airports were one of the first places to use the early concepts of technology that we would presently call IoT.

A typical operation for ground handling assets is generally limited to an operational area that is relatively small in size - something that is not unusual for an IoT based system. When looking at asset allocation on airports it becomes obvious that this equipment is usually divided into several or more ‘standby zones’. The main problem that arises is a short turnaround time for aircraft, which is usually less than 40 minutes. During this time, any unexpected problem, even with a single item of ground supporting equipment, can cause significant and costly delays. Moreover, there is a risk of propagation of the delay over more than one flight, disrupting operations at the airport. Thus, a digital system capable of reporting positioning information for ground handling assets has the potential to be an essential tool to provide logistical support, even if the associated location precision is less than several metres.

The problem with existing, airport-based infrastructure-dependent solutions is that they are required to meet very high industry standards. Often, they require significant investment into local airport infrastructure to be effective and with airports usually having full control of the design and implementation. A collaboration with an airport operator or companies active within the airport as supporting contractors is often the best option for the development of a platform. This complex cooperation creates a situation that directly contrasts IoT in other fields where a multitude of options are readily available for implementation that can be done in days rather than months. Additionally, widely adapted multilateration systems that are already part of an airport asset tracking use existing transponder broadcasts, which may become severely limited especially with high traffic, as the system of messages has not been originally designed for ground use.

These multilateral systems for the most part were not designed to handle potentially hundreds of devices working within a relatively small or confined space. In recent years, however, significant progress has been made in the topic of low power, GNSS-enabled IoT devices, opening opportunities for systems that could bring positioning options for a large number of devices possibly including assets without any power supply to them. One of the visible trends is the implementation of RFID technology. However, as expected for such and similar architectures, many of these systems require elements to be installed within the airport infrastructure to serve as the operational IT backbone. Such a situation may become problematic for several reasons with the most significant ones being the following:

·         incorporating new infrastructure over a functioning airport is generally not a simple process that can be accomplished in a short time span; typically, before the project is implemented, it has to become part of the airport budget plan and operational plan which can take up to a year or in some cases even more,

·         necessity for the system to uphold very restrictive security measures – both regarding the system itself as well as the personnel involved in system implementation, as the personnel, in theory, could gain access to elements critical to airport operations, even though the system itself could be regarded as non-critical to airport operation,

·         integration of the system within the existing IT infrastructure, both from the hardware and software points, requires possible incorporations of new fibre-optic or electrical wiring, connection and configuration within existing networks, etc.,

·         possible implementation only through airport dependant subcontractors, as some airports policy prohibits external contractors from working directly on their functioning IT infrastructure.

 

The purpose of this study was to design, build and test whether or not it is possible to operate a ground handling asset tracking system capable of providing a location with at least 50% of positions being within 2.5m distance from their physical locations and if such system can be operated reliably. Therefore, the eventual system was required to include all three layers required for operation - the physical layer, the network layer and the application layer, making it a complete system acting independently to currently employed airport solutions, which in the case of Gdańsk airport, was using either existing MLAT system or through the direct use of GNSS in a limited number of pushback vehicles or lead cars. Other options are also possible but typically they do not rely on available, but external, independent wireless infrastructure.

 

 

2. SYSTEM ARCHITECTURE CONCEPT

 

Initial research was carried out to identify the possible technologies that could become the IoT backbone for the required hardware platform regarding the classical three-layered IoT architecture. Several possible options were considered for physical and network layers, divided into independent and third-party infrastructure-dependent solutions. Three possible communication solutions were identified as the most suitable – a mesh type architecture, a radio-based system with a centralised gateway and an LTE-based cellular communication over available external infrastructure. While all three options have been laboratory tested on a small scale and could act as a backbone for the physical layer, the main issue with the first two architectures was the general inability for such systems to be installed without the support of the airport itself.

As mentioned in the introduction, airports, in general, tend to limit access to such infrastructure for security reasons, as it is part of their operation critical assets. Ultimately, the requirement for non-invasive rapid-deployment has been considered most important. Thus, the combination of an LTE-based cellular communication with the perspective of moving into the emerging LTE V2X/M2M as technology advances merged with location information provided by GNSS, single-frequency, multi-constellation receivers, has been selected for implementation. Additionally, in the opinion of the authors of this article, LTE-based communications are best suited for the role as they offer an exceptional range, sufficient bandwidth for near real-time, low latency data exchange as well as tolerable power consumption. Currently, the LTE/5G technology is undergoing rapid development, especially in a broad range of IoT applications. LTE/5G has the potential to become a primary method of using communication for low-powered devices as it overcomes the necessity of possessing gateways for wide area networks in its entirety, relying on existing cell phone operators' infrastructure. The new 3GPP protocol (release 16 and subsequent) for LTE/5G already contains a baseline for independent positioning with an initial precision of 10 metres, but this will be further developed to potentially reach sub-metre values. The very same release also defined Non-Public-Networks features that would be based on smaller, dedicated and otherwise isolated cell base stations enabling a high level of security and very low latency times. Both elements were designed with the IoT in mind and would be very beneficial from the Ground Eye system architecture standpoint described in this article.

The hardware for tracking units was developed using an STM32 M4 platform with GNSS navigation and LTE communication subsystems. The intended use of this platform was to act as active, unrelated nodes that should always be active; therefore, the design included a DC power conversion block capable of supporting the required current while lowering the input voltage to the required 5VDC. The GNSS subsystem used the uBlox provided Neo M8U chips with dead reckoning capability, which during tests allowed for sufficient positioning precision. The communication system was based on the LARA R-211 LTE modem and was configured for data exchange. The platform was set to be running custom-built firmware written in C language, which was actively developed throughout the testing campaign.

The data sent by each test unit was in the JSON format for ease of system troubleshooting. The data was relayed by one of the available cellular operators and received by a dedicated server running Node.JS as a backend.  The backend system was responsible for analysis, data conversion and data relay into connected frontend clients, allowing a multitude of independent visualisation windows. The frontend subsystem was designed to visualise the information inside a 3D environment based on React.JS with Deck.GL – a Web.GL-powered workflow that is very efficient in presenting numerical information as a map. The general UX incorporated a 3D representation of the airport with additional windows containing settings and supplementary information and it was based on requirements issued by the ground handling company. Necessary airport visualisation layers in the GeoJSON format were designed and built using the QGIS software and with an aid of aerial imagery as well as airport documentation.  Further, the frontend included options to filter positioning data and provide an option for the user to limit the number of visible devices. The backend-frontend solution was tested with simulated devices first to provide some insight into the system capability.

For a test campaign, 9 different ground handling assets were selected to verify the multitude of working conditions spanning from near-terminal zones that were considered likely to become most problematic due to multipath effects, through aircraft servicing zones up to the open sky conditions. Devices were tested in varying weather ranging from full Sun to moderate rainfall/foggy conditions and thermally from 20 Celsius to below freezing conditions.


 

3. PRINCIPLE OF OPERATION

 

Each device was designed with an ‘always-active’ mode of operation in mind. Eventually, a second (active-standby state) and a third (deep sleep state) were introduced in the later versions of the firmware to prolong operation on the auxiliary power source. The data broadcast intervals are presented in Table 1.

 

Tab. 1

Data broadcast intervals in each of the power state

 

State

Active

Active-standby

Deep sleep

Interval [s]

2

60

1800

 

 

In the active-standby state, the platform still retains the main power source, and thus, keeps the GNSS and LTE subsystems active, but the information is being event-driven. In a situation, in which the unit is not moving there is also no need for constant reporting of its position. This lowers the drain on the main power, allowing for better management of backup power charging. The expected impact on the host asset power level was, however, considered low, as the assets, typically, are optimised for hop-operation - in, for example, driving from one point to the other or otherwise becoming stationary and usually powered off. Furthermore, in the case of ground handling equipment, the assets typically contain much more powerful charging units and the overall trend is to introduce more electrically powered assets rather than diesel.

All units were also eventually configured for a deep sleep mode – if the primary power source was disconnected. This scenario assumed that the asset was inactive and non-moving, therefore the need to relay positioning information in real-time became non-priority. However, there existed the necessity to inform operators if the asset is still present at a certain location, because it was not impossible for such asset to be moved while unpowered, that is, due to malfunction. Therefore, units working in this state were allowed to send positioning information every 30 minutes. Each incoming data was evaluated by the backend for its integrity and then compiled into all vehicles list and this information was pushed to all connected frontends for visualisation purposes. The frontend itself was also capable of processing positioning information for zone violation purposes, while the backend was capable of generating a broad range of events that included alerts, warnings and notifications.

 

 

4. TEST CAMPAIGN RESULTS

 

The initial testing was conducted within Gdańsk Airport with a total of 9 prototype devices. Several configurations were prepared as described in Table 2.

 

Tab. 2

Configuration of the test devices

 

Tracked asset

LTE antenna used

GNSS antenna used

GPU

fixed whip

active patch mounted internally

BLTL

fixed whip

active patch mounted internally

TSU

fixed whip

active patch mounted internally

WSU

fixed whip

helix, casing mounted

PUSHBACK

fixed whip

active patch mounted internally

CAR

fixed whip

active patch magnetically mounted externally

BUS

flexible patch mounted internally

active patch mounted internally

STAIRS

fixed whip

active patch mounted internally

de-icing vehicle (DIV)

fixed whip

flexible patch mounted internally

 

Tests were conducted in conditions that became more demanding with the coming of the winter season; therefore, the campaign was also useful in determining the potential problems with the backup battery sources. Lithium polymer or lithium-ion batteries are well known for not being able to retain the same performance level in a broad range of weather conditions especially when it comes to temperatures [6]. Most of the ground handling assets (GHA) are relatively simple machines with minimum or no heating systems usually limited to the driver compartment. Therefore, even tracking units mounted inside the assets were exposed to relatively low temperatures – an effect that was clearly visible with the typical, periodic operation of GHA. At the end of the tests, all devices were configured with an updated firmware to operate for at least 50 hours without any external power source. Such a long time of operations is considered to be unlikely in typical airport operations.

The positioning subsystem evaluated under the testing campaign showed that using even single-frequency, multi-constellation GNSS receivers are a useful solution for positioning of assets. Figures 1 and 2 present examples of position measurements (in form of a scatter plot and a heatmap; heatmap contains Gaussian filter) for two different types of assets. The left chart shows a GPU while the middle and the right present a BLTL (baggage loading vehicle). In the case of GPU, a long duration (24 h) data was considered with the unit being located near aircraft with a partially obscured sky; the middle chart shows position scattering for BLTL, while it is located in unfavourable conditions near the main terminal building and very close to one of the pylons; the right image shows BLTL at a different location, under better conditions. The long-term scattering for GPU shows that even with some expected scattering, it is possible to obtain better results with server processing of positions with a simple centroid solution, as the positioning errors tend to cancel each other out. A similar tendency can also be observed with lower duration observations such as in both cases of BLTL. An example of position scattering registered during the tests can be seen in Figure 1. Dark points represent original locations provided by the receiver’s navigation engine. While the lighter points are a result of backend processing.

The collected information was used to generate heatmaps (with Gaussian filter) as seen in Figure 2. Heatmaps provide a better understanding and visualisation of the overall precision range for the location information as seen by the system prior to backend processing. Similar to the plots seen in Figure 1, the left picture shows long-duration data for GPU, the middle image shows BLTL positions in a problematic spot near the main terminal building and the right image shows BLTL in an alternative, more favourable location that was less prone to signal interference.

The backend processing of the original positioning information included analysis of the timestamp originating in the receiver and based on GNSS data, therefore, all units essentially became synchronised. Backend analysis of the interval made it possible for the system to recognise if the units were moving or not, and in the latter case, assumed each incoming positioning information as originated in the same place. Therefore, the system used each incoming position in such a case to calculate the centre point (centroid) of all the locations, which in effect could limit the scattering to more manageable values, even though with a small number of measurements it would likely contain some level of errors, but possibly lower than unprocessed data. This approach proved to be effective, especially after some data were collected. The idea was similarly tested with a unit operating temporarily solely in active mode to determine if it would be possible to influence the results in a shorter time span and intervals. The results can be seen in Figure 3, which shows an example of the DIV positions being relayed in active mode with 2 seconds of interval. During this time, the vehicle was parked in a relatively open area; however, the antenna was mounted on the dashboard inside the vehicle, which was less than ideal. Dark points represent positions relayed by the receiver, while the lighter points are positions of calculated centroid; a subsequent heatmap shows the aggregation of positions with the Gaussian filter applied.

 

 

Fig. 1. Example of position scattering for two tracked units

 

 

Although simple, the backend processing of information allows for the overall decrease in discrepancy, especially if enough data is collected; however, considering the nominal operation modes, data should be gathered every 2 seconds for the active state and every minute for the active-standby state. Furthermore, typical operation of the assets is also beneficial, because the situation where at least some of them are being placed in certain locations for a prolonged time, is not uncommon. Table 3 shows the summary of discrepancy ranges for an unaltered position and positions calculated with the assistance of the backend.

Data in Table 3 indicate that for more than 95% of measurements, the precision was higher than 2.5 m (in case of a relatively good position) - even for more challenging positions of assets. This is positive information, clearly indicating the value of GNSS-based positioning for ground handling. In the case of a challenging position, the percentage of positioning better than 2.5 m dropped below 50%, yet it was still close to our initial assumption of 50%.

 

Fig. 2. Position scattering heatmap (with Gaussian filter)

 

Fig. 3. Example of the DIV(de-icing vehicle) position relayed in active mode

 

Tab. 3

Summary of the discrepancy ranges for unaltered and processed positions

 

Range

GPU

BLTL (Pos. #1)

BLTL (Pos. #2)

Unprocessed

Processed

Unprocessed

Processed

Unprocessed

Processed

Less than 1 m

58

784

5

21

39

334

1-2 m

145

606

14

46

74

42

2-3 m

239

32

14

41

96

34

3-4 m

235

 

19

38

69

7

4-5 m

200

 

22

18

39

 

5-6 m

173

 

17

 

21

 

6-7 m

136

 

15

 

22

 

7-8 m

77

 

11

 

16

 

8-9 m

69

 

10

 

12

 

9-10 m

39

 

6

 

13

 

10-11 m

19

 

6

 

9

 

11-12 m

13

 

3

 

5

 

12-13 m

11

 

5

 

2

 

13-14 m

5

 

3

 

1

 

14-15 m

2

 

2

 

 

 

More than 15 m

2

 

13

 

 

 

Sum

1423

1422

165

164

418

417

% of positions better than 2.5 m

21.57%

99.86%

14.55%

46.95%

39.95%

95.44%

 

Without any aid, seeking certain assets can take up to several minutes, and often requires one of the employees to physically drive through all standby zones until the assets have been found. This situation is problematic because each vehicle that moves around the airport operation zone usually needs to cross aircraft taxiways – which is always undesirable. Therefore, even a position that contains an error in the range that exceeds several metres could be beneficial, because it allows pinpointing specific standby zones over which the unit is placed.

The observed latency for all units was in all cases similar and low enough (typically ~2 seconds) for good near real-time visualisations. The observed stability of the communication was high with the only issue being caused by voltage drops when using a close-to-discharge backup power source while waking from deep sleep mode. The voltage drops in question caused either the platform to reset, the inability to write the JSON data into a file in modem memory prior to sending or the interruption of data transmission, which led to the backend not being able to process the information. No interruptions caused by service being unavailable from the operator side was reported.

As a last testing effort, a next-generation, dual-frequency receiver was tested on a car platform with an externally mounted patch antenna with the support of the local RTK reference station. The testing phase was cut short due to time constraints but the positioning data that were collected showed much improvement. Both by limiting the positioning discrepancy for locations and providing some measure of reducing the multipath issues even in locations that previously were a source of significant positioning errors. Collected data was used to plot movements that showed the trail of the tracked car as it moved around the airport zone of allowance. Some noticeable gaps in the data were observed. This was caused by positioning errors that were disregarded by the system. A static test was also performed over a short duration in a relatively open area to compare the results with single-frequency receivers.

The LTE communication subsystem used for the data exchange provided sufficient bandwidth for the data with adequate latency for near real-time. The main issue encountered was the stability of the operation. The most common problem identified in the test campaign was associated with the return from the deep sleep mode into the active mode, which sometimes caused connection problems triggering fail-safe platform reboot.

It is important to note that the next generation modems using the LTE Cat M1 standard, which is designed with IoT solutions in mind, can provide similar capability to tested devices with regards to expected data transmissions, especially when moved from JSON to binary format, however, with limited power consumption. On the other hand, the capability of the modem fully supporting LTE standard makes it possible for a system to become enhanced with additional functionalities like the two-way data exchange, voice communication, etc.

Throughout this project, the incoming data was saved to the master log file on the server. Finally, at the end of the tests, it had gathered almost 1 million lines of data. This transferred to more than 8 million unique data points. Besides, positions logs included the information about the device battery level, temperature, charging state, date and time (including GNSS originated time and server reception time) and error codes.

This collected information was sufficient for analysis purposes, which confirms that the LTE/GNSS-based method could be implemented as an IoT system for ground handling used within airport operation zones. Initially, that data was processed to provide a complete movement heatmap showing the recorded assets position as a function of time, therefore, identifying the places where tracked assets were the most active. This allowed comparison between the actual data and the assumption over activity, which was supposed to occur at the ‘standby zones’ and zones of allowed movement. The resulting heatmap showed that the data corresponds with the assumption as expected with two exceptions being caused by pushback assets naturally operating periodically beyond the zone of allowance as well as the DIV operating near aircraft at the designated area.

Another study allowed for the analysis of the actual activity times and distances driven by each of the assets, showing the actual working methodology for all of the tracked units. This information was essential in making changes in the power management subsystem that in effect allowed more stable and longer operation. The analysis showed that most of the units – especially the ones that only used ignition dependent power sources - are only periodically active and usually for a short duration. In contrast, the devices that were connected independently to the power system had continuous data flow. Introduction of firmware changes in the tracking units introduced several features, such as management of low-power states, which was able to reduce the delay between unit power-up to active state. Resultantly, the system unit was more responsive, although, in the case of power-up at ignition, a delay of 15-25 seconds was noted. However, with newer, dual-frequency receivers, this activation time has been significantly reduced to a maximum delay of up to 10 seconds. This confirms that dual-frequency GNSS receivers have the potential to improve IoT operations.

Once the system was operational, the supplied data was within expectations. In some cases, degradation of GNSS data occurred - because in some cases, the tracking units had to be installed inside the vehicle itself, which obviously was not ideal. Additionally, some technical challenge to overcome is connected to the assets themselves as at least some of them contain chassis that are non-metallic, which makes magnetic mounts for antennas ineffective, unless modification of the vehicle is allowed.

 The positioning data collected from the aprons were notably the most precise with limited position scattering usually caused by assets being positioned very close to the aircraft. The positioning precision was seen to degrade with the asset position getting gradually closer to the main terminal building, with the worst conditions being near the pylons that allowed direct access to aircraft. In extreme single cases, where only a limited number of satellites were available, with significant multipath errors, the position error could have exceeded 10-15 metres.

 

5. CONCLUSION

 

The testing phase collected enough data to prove that the system is capable of providing very good positioning information in most cases, with some degradation observed when multipath effects or limited signals availability are present. This issue can be mitigated by incorporating the next generation dual-band receivers and additionally improved by a supplementary positional aiding technology such as RTK, as well as advanced processing of data on the server-side. Furthermore, the LTE subsystem that was employed is already fully capable of supporting the required communication bandwidth to support this aiding technique. From a security perspective - considering the safety of information - the existing cellular architecture allows for regulated connectivity architecture. In such a scenario, the local BTS station can be configured to operate a network that is otherwise separated from the Internet and is only active locally, thus, limited to only a specific area within one or several BTS. More importantly, the introduction of the next generation cellular IoT solutions is expected to further enhance the possibility of employing LTE/5G dependant tracking platforms that can be quickly and effortlessly mounted within the available assets without much interference in normal operations and bypassing the need of investments in local airport IT infrastructure altogether. Furthermore, it is also possible that the LTE/5G technology would incorporate positioning capabilities that would be mandatory and independent to GNSS, especially as progress is being made in the field of V2X. Similarly, a new version of 5G/LTE would incorporate solutions dedicated to IoT, such as dedicated, independent BTS platforms that would offer low latency and highly secure connections.

An interesting case that presented itself is the integration of additional data using ADS-B (Automatic Dependent Surveillance-Broadcast), which can provide enough information to formulate a more of a general-purpose solution rather than ground handling alone. Inclusion of ADS-B or airport independent MLAT technology could enable near real-time preview of operations for ground handling equipment as well as aircraft. Consequently, such a system would be capable of presenting the live situation of all the traffic in all weather conditions, possibly also aiding the operators of the ground handling as the communication backbone and general requirement for frontend is presently relatively low. An experimental unit was developed using the Raspberry Pi 3+ to test the approach. Although the initial results were somewhat unimpressive due to the lack of a dedicated GPU that would support a 3D environment, we are confident that either a simpler, non-3D map environment or a more powerful board would solve the issue. Moving to this option, however, would require improvements in obtaining positioning information, which can be achieved by incorporating the next generation receivers and techniques mentioned above on a larger scale.

The backend and frontend subsystems remained stable and provided constant positioning information in a visual form, which was an efficient and accurate representation of real data. Both positions and backend issued events were acknowledged by the frontend without problems. During test phases, a total of 10 concurrent clients were run independently without any noticeable degradation in performance.

Furthermore, the system was reconfigured to store incoming data into a MongoDB database and the configuration worked without issues. We believe that the natural next step for a system of this kind would be to achieve enough positioning capability for a possible implementation of higher-level functions such as dynamic asset directing, manual asset-specific feedback information, automatic pre-planning of operations. A possible solution for the hardware level implementation could be the use of RTK based systems with a new generation of receivers. For IoT, this approach was also evaluated through a separate FLAMINGO project with very favourable results, which were presented at the European Navigation Conference 2020. The idea behind it is based on the possibility of collecting raw GNSS data and sending it for external processing rather than doing it through an internal navigation engine. With this, the architecture server will be responsible for processing all incoming information to produce location information that could be used by the system, as would normally be the case. Thus, this architecture enables the possibility of using an RTK station(s) to provide corrections for all available devices. We are confident that even with the current COVID situation which dramatically reduced the number of airport operations, there is still room for a low-cost supplementary system specifically designed for monitoring the ground handling vehicles, especially from the operator standpoint. More so, PANSA (Polish Air Navigation Services Agency) recently became interested in solutions that could enable such tracking information to be available for ATC personnel at airport towers.

 

 

References

 

1.        Abdullah Alghadeir, Hasan Al-Sakran. 2016. “Smart Airport Architecture Using Internet of Things”. International Journal of Innovative Research in Computer Science & Technology (IJIRCST) 4(5): 148-155. ISSN: 2347-5552.

2.        Peter Baum. 2019. “Airports - a Platform for IoT technology?”. In: 30th European Conference of the International Telecommunications Society (ITS): "Towards a Connected and Automated Society". International Telecommunications Society (ITS). 16th-19th June, 2019. Helsinki, Finland.

3.        Sean Bryan. 2019. “Moving with the times”. Airside International Autumn 2019: 12-15. ISSN: 1754-1166.

4.        Qualcomm Europe. “Propelling 5G forward: A closer look at 3GPP Release 16”. Available at: https://www.qualcomm.com/news/onq/2020/07/07/propelling-5g-forward-closer-look-3gpp-release-16.

5.        Multilateration (MLAT) concept of use: Edition 1.0. 2007. ICAO.

6.        Kiela Karolis, Vaidotas Barzdenas, Marijan Jurgo, Vytautas Macaitis, Romualdas Navickas. 2020. "Review of V2X–IoT Standards and Frameworks for ITS Applications". Applied Sciences 10(12): 4314. DOI: https://doi.org/10.3390/app10124314.

7.        Roberts William, Joshua Critchley-Marrows, Maria Ivanovici, Malgorzata Siutkowska, Valentin Barreau, Laurent Arzel, Soufian Ayachi, Alex Lopez, Xavier Banque-Casanovas, Miquel Garcia, Thiago Tavares, Maria Kirova, Patrisia Costenco, Krzysztof Kanawka, Adam Piech. 2020. “High accuracy navigation for the mass market - The FLAMINGO initiative”. In: 2020 European Navigation Conference. Deutsche Gesellschaft für Ortung und Navigation (DGON). 23-24th November, 2020, Dresden, Germany. ISBN: 978-1-7281-4430-6.

 

 

Received 05.10.2021; accepted in revised form 29.11.2021

 

 

Scientific Journal of Silesian University of Technology. Series Transport is licensed under a Creative Commons Attribution 4.0 International License


[1] Blue Dot Solutions sp. z o.o., Al. Grunwaldzka 472, 80-309 Gdansk, Poland. Email: adam.piech@bluedotsolutions.eu. ORCID: https://orcid.org/0000-0002-4181-2430

[2] Blue Dot Solutions sp. z o.o., Al. Grunwaldzka 472, 80-309 Gdansk, Poland. Email: maciej.kwapinski@bluedotsolutions.eu. ORCID: https://orcid.org/0000-0002-8602-8666

[3] Blue Dot Solutions sp. z o.o., Al. Grunwaldzka 472, 80-309 Gdansk, Poland. Email: maciej.mickiewicz@bluedotsolutions.eu. ORCID: https://orcid.org/0000-0002-4683-4655

[4] Blue Dot Solutions sp. z o.o., Al. Grunwaldzka 472, 80-309 Gdansk, Poland. Email: krzysztof.kanawka@bluedotsolutions.eu. ORCID: https://orcid.org/0000-0002-8106-7818