WO2025104016A1

WO2025104016A1 - Discovery of mobile edge application servers

Info

Publication number: WO2025104016A1
Application number: PCT/EP2024/082038
Authority: WO
Inventors: Nassima TOUMI; Yonatan Woldeleul SHIFERAW; Lucia D'ACUNTO
Original assignee: Nederlandse Organisatie voor Toegepast Natuurwetenschappelijk Onderzoek TNO; Koninklijke KPN NV
Current assignee: Nederlandse Organisatie voor Toegepast Natuurwetenschappelijk Onderzoek TNO; Koninklijke KPN NV
Priority date: 2023-11-14
Filing date: 2024-11-12
Publication date: 2025-05-22
Anticipated expiration: 2026-05-14

Abstract

Systems and methods are described for enabling discovery of mobile Edge Application Servers (EAS) which follow the same or similar trajectory as a User Equipment (UE). For example, an Edge Enabler Server (EES) may be configured to enable a requesting entity to discover such mobile EAS for a UE. For that purpose, the EES may keep track of the trajectories of mobile EAS and match them with the UE mobility. To enable such matching, in some embodiments, mobility information may be included in profiles of the respective entities, with the mobility information comprising a trajectory identifier which identifies a trajectory which is, or is expected to be, followed by the respective entity. By enabling a mobile EAS to be assigned to UE on the basis of similarity in trajectory, there may be less need for Application Context Relocations (ACRs), which otherwise may run the risk of service interruptions and which may be expensive in terms of required bandwidth, storage, etc. Additionally, systems and methods are described for enabling discovery of mobile EES.

Description

DISCOVERY OF MOBILE EDGE APPLICATION SERVERS

TECHNICAL FIELD

The invention relates to an edge enabler server for a telecommunications network and to a computer-implemented method for being performed at the edge enabler server. The invention further relates to a user equipment and a computer- implemented method for being performed at the user equipment. The invention further relates to an edge configuration server and a computer-implemented method for being performed at the edge configuration server. The invention further relates to a trajectory identification server and to a computer-implemented method for trajectory identification. The invention further relates to a mobile edge application server, and to a computer- readable medium comprising data representing instructions for causing a processor system to perform any one of the computer-implemented methods.

BACKGROUND

There has been a significant trend towards shifting the execution of computational tasks closer to the edge of the telecommunications network. In 3GPP, this concept is also referred to as Multi-access Edge Computing (MEC) and may involve positioning distributed resources, such as Edge Application Servers (EAS), in proximity to the end-user. MEC and similar edge computing approaches may be particularly valuable for Artificial Intelligence (Al) applications where data can be processed in proximity to the end-user. This may negate the need to transmit large volumes of data over large network distances for remote processing, thereby reducing latency, conserving bandwidth, and potentially enhancing user experience. For example, an Al-driven traffic monitoring system deployed at a city intersection may benefit from localized processing to ensure real-time responses and decision-making.

EAS are typically configured to serve user equipment (UE) within a certain area, which area may also be referred to as service area or serving area. When a UE moves, for example by being onboard in a moving vehicle, the UE may move out of the service area of an EAS which currently serves the UE and into the service area of another EAS. To ensure service continuity, an Application Context Relocation (ACR) may be performed by which the application context of the edge application utilized by the UE is transferred to the other EAS. Disadvantageously, while ACR is designed to minimize service interruptions, such service interruptions cannot always be avoided. Moreover, ACR can be expensive in terms of required bandwidth, storage, etc. In transport scenarios, multiple UEs may move collectively, for example by being co-located within a same vehicle. For example, a group of UEs may be aboard a train, bus, or boat, or may trail behind each other in separate vehicles on the same road, for example in a vehicle platoon. In such cases, rather than executing ACRs individually as each UE travels, a more efficient approach may be to connect all these UEs to a shared edge resource, namely a mobile EAS. This mobile EAS may move, either physically or virtually, in tandem with the group of UEs, ensuring consistent service access and reducing or outright eliminating the frequent need for ACRs.

Vehicular Edge Computing (VEC) is a growing research area, where vehicles make their resources available for caching or to host computations and services [1], In related work, mobility-aware concepts have been proposed for predicting the mobility of vehicles, and based on the predicted mobility, optimizing task migration by selecting the timing and target of the task migration [2],

Disadvantageously, current standards, including relevant 3GPP standards [3], do not account for or support the mobility of mobile edge resources such as mobile EAS. More critically, the standards do not provide guidance on managing the combined mobility of the mobile EAS and served UEs. This gap in standardization poses challenges for achieving truly mobile and dynamic edge computing experiences.

References

[1] Liu, L., Chen, C., Pei, Q. et al. Vehicular Edge Computing and Networking: A Survey. Mobile Netw Appl 26, 1145-1168 (2021). https://doi.Org/10.1007/sl 1036-020-01624-1

[2] Y. Zhang, H. Zhang, K. Long, Q. Zheng and X. Xie, "Software- Defined and Fog-Computing-Based Next Generation Vehicular Networks," in IEEE Communications Magazine, vol. 56, no. 9, pp. 34-41, Sept. 2018, doi:

10.1109/MCGM.2018.1701320

[3] 3GPP TS 23.558, Technical Specification Group Services and System Aspects; Architecture for enabling Edge Applications; (Release 18); V18.3.0

SUMMARY

In accordance with a first aspect of the invention, an edge enabler server is provided for a telecommunications network. The edge enabler server may comprise:

- a network interface to the telecommunications network;

- a processor subsystem which may be configured to: access a data storage comprising profiles of edge application servers, wherein at least a subset of the edge application servers may be mobile edge application servers, wherein a profile of a mobile edge application server may comprise a server trajectory identifier, wherein the server trajectory identifier may be indicative of a trajectory of the mobile edge application server; receive a discovery request to discover an edge application server for a user equipment, wherein the discovery request may comprise an identifier of the user equipment; obtain a client trajectory identifier of the user equipment, wherein the client trajectory identifier may be indicative of a trajectory of the user equipment; identify, based on the profiles of the edge application servers, one or more mobile edge application servers of which the server trajectory identifier at least partially matches the client trajectory identifier; and send identifiers of the one or more mobile edge application servers as a response to the discovery request.

In accordance with a further aspect of the invention, a computer- implemented method is provided for execution at an edge enabler server of a telecommunications network. The method may comprise:

- accessing a data storage comprising profiles of edge application servers, wherein at least a subset of the edge application servers may be mobile edge application servers, wherein a profile of a mobile edge application server may comprise a server trajectory identifier, wherein the server trajectory identifier may be indicative of a trajectory of the mobile edge application server;

- receiving a discovery request to discover an edge application server for a user equipment, wherein the discovery request may comprise an identifier of the user equipment;

- obtaining a client trajectory identifier of the user equipment, wherein the client trajectory identifier may be indicative of a trajectory of the user equipment;

- identifying, based on the profiles of the edge application servers, one or more mobile edge application servers of which the server trajectory identifier at least partially matches the client trajectory identifier; and

- sending identifiers of the one or more mobile edge application servers as a response to the discovery request.

In accordance with a further aspect of the invention, a user equipment is provided for a telecommunications network. The user equipment may comprise:

- a network interface to the telecommunications network; - a processor subsystem which may be configured to, during operation, execute an application client and an edge enabler client, wherein the processor subsystem may be further configured to, using the edge enabler client: send a discovery request to an edge enabler server, wherein the discovery request may comprise a client trajectory identifier, wherein the client trajectory identifier may be indicative of a trajectory of the user equipment; receive identifiers of one or more mobile edge application servers from the edge enabler server in response to the discovery request, wherein the one or more mobile edge application servers may each be assigned a server trajectory identifier which at least partially matches the client trajectory identifier; and configure the application client with a mobile edge application server selected from the one or more mobile edge application servers.

In accordance with a further aspect of the invention, a computer- implemented method is provided for execution at a user equipment of a telecommunications network. The user equipment may be configured to, during operation, execute an application client and an edge enabler client. The method may comprise:

- sending a discovery request to an edge enabler server, wherein the discovery request may comprise a client trajectory identifier, wherein the client trajectory identifier may be indicative of a trajectory of the user equipment;

- receiving identifiers of one or more mobile edge application servers from the edge enabler server in response to the discovery request, wherein the one or more mobile edge application servers may each be assigned a server trajectory identifier which at least partially matches the client trajectory identifier; and

- configuring the application client with a mobile edge application server selected from the one or more mobile edge application servers.

In accordance with a further aspect of the invention, a trajectory identification server is provided for a telecommunications network. The trajectory identification server may comprise:

- a network interface to the telecommunications network;

- a processor subsystem which may be configured to: access a trajectory repository comprising trajectory identifiers for trajectories, wherein an entry in the trajectory repository may comprise trajectory information defining of a trajectory and a trajectory identifier assigned to the trajectory; receive a trajectory identification request, wherein the trajectory identification request may comprise location information indicative of a device trajectory of a device; search the trajectory repository for a trajectory identifier for the device trajectory by comparing the location information to the trajectory information stored in respective entries of the trajectory repository; and send the trajectory identifier as a response to the trajectory identification request.

In accordance with a further aspect of the invention, a computer- implemented method is provided for trajectory identification in a telecommunications network. The method may comprise:

- accessing a trajectory repository comprising trajectory identifiers for trajectories, wherein an entry in the trajectory repository may comprise trajectory information defining of a trajectory and a trajectory identifier assigned to the trajectory;

- receiving a trajectory identification request, wherein the trajectory identification request may comprise location information indicative of a device trajectory of a device;

- searching the trajectory repository for a trajectory identifier for the device trajectory by comparing the location information to the trajectory information stored in respective entries of the trajectory repository; and

- sending the trajectory identifier as a response to the trajectory identification request.

The above measures may facilitate the discovery of mobile edge application servers (EAS). For that purpose, an edge enabler server (EES) may be provided which may be configured to enable mobile EAS to be discovered. The EES may specifically be configured to take the mobility of UEs and mobile EAS into account. Namely, as is known per se, the EES may access, and typically maintain, a collection of profiles of EAS. In accordance with the above measures, the EES may also maintain information about the trajectories of mobile EAS. Here, the term ‘trajectory’ may refer to the route or path followed by an entity moving through physical space. For example, if a mobile EAS is placed onboard a train, the mobile EAS may follow the trajectory represented by the train’s journey. In addition, the trajectory being ‘of’ an entity may indicate that the entity follows, or is expected to follow, the trajectory, either now or in the (near) future.

The information about the trajectory of a mobile EAS may be maintained by way of trajectory identifiers. Each respective trajectory identifier may represent a unique identification of a particular trajectory. For example, a first trajectory identifier may identify trajectory A, a second trajectory identifier (which may be different from the first identifier) may identify trajectory B, etc. In a specific example, the trajectory identifier may be numerical or alphanumerical value assigned to a respective trajectory. In another example, a trajectory identifier may represent an encoding of a respective trajectory, e.g., an encoding of geographical locations defining the trajectory.

During operation, the EES may receive a request for discovery of an EAS. As is known per se, such a discovery request is typically submitted for, and in some cases also by, a UE, meaning that the discovery request may be intended to discover an EAS for serving a UE. In response to the discovery request, the EES may obtain a trajectory identifier of a trajectory of the UE. The trajectory identifier for the trajectory of the UE may take a same form as the trajectory identifiers for the EAS, meaning that they may follow a same assignment systematic, format, etc. Accordingly, the EES may have access to the trajectory identifier of the trajectory of the UE and to the trajectory identifiers of the trajectories of the mobile EAS registered with the EES. Based on these trajectory identifiers, the EES may identify, based on (e.g., from) the profiles of the EASs, one or more EAS which currently follow or are expected to follow a trajectory which at least partially matches the trajectory of the UE. This may typically involve the EES searching the profiles of the EAS for matching EAS using one or more EAS discovery filters while using the trajectory identifier as an EAS discovery filter. It will be appreciated that additional EAS discovery filters may also be used in the search.

A partial matching of trajectories may occur when a trajectory portion is the same or similar. In some embodiments, the matching of trajectories may take the current position of entities along the trajectories into account. In some embodiments, the EES may assess the match between trajectories by determining the degree of match between trajectory identifiers. Namely, the trajectory identifiers may be designed to allow such a quantification. For example, the fact that the trajectory identifiers are the same may indicate that the trajectories are the same or similar within a certain margin. Likewise, in some embodiments, a partial match in trajectory identifiers may indicate a partial match of trajectories. For example, different parts of a trajectory identifier may pertain to different parts of a trajectory. A partial match between trajectory identifiers may thus indicate that parts of the trajectories correspond.

The search by the EES may result in one or more at least partial matches, meaning that one or more mobile EAS may be identified of which the trajectory at least partially matches the trajectory of the UE. The identified one or more mobile EAS may be considered as having been selected or pre-selected as being suitable for use by the UE based on the employed criteria, e.g., based on the used EAS discovery filters which may include the trajectory identifier of the UE. The EES may send identifiers of the found mobile EAS to the requesting entity. The requesting entity may then select a mobile EAS for service migration, e.g., for moving a UE’s service or application instance to the mobile EAS, or for service deployment, e.g., for setting-up or initiating a service or application instance at the mobile EAS, or for another type of purpose. If a plurality of identifiers were provided in response to the discovery request, such selection may involve selecting from the plurality of mobile EAS identified by the respective identifiers. If the requesting entity is for example the UE, the EES may send the identifier(s) to the UE, while if the requesting entity is an EAS which currently serves the UE, the EES may send the identifier(s) to this currently serving EAS. Based on these identifiers, various actions may be taken associated with the aforementioned service migration or service deployment. For example, the currently serving EAS may initiate an ACR. Another example is that the UE may trigger the service migration. It will be appreciated that such actions may be subject to further decision making processes. For example, the UE may trigger the service migration only if local measurements indicate that the quality of service provided by the currently serving EAS deteriorates.

The above measures may enable the discovery of a mobile EAS for a UE in a way which takes mobility of both the mobile EAS and the UE into account. By doing so, there may be less need for ACRs, which otherwise may run the risk of service interruptions and which may be expensive in terms of required bandwidth, storage, etc. In addition, by discovering matching mobile EAS on the basis of trajectory identifiers, an abstraction is provided from the actual trajectories. Such abstraction may facilitate the comparisons, for example by enabling trajectories which differ inconsequentially, e.g., because of technical reasons (e.g., measurement inaccuracies) or infrastructure- related reasons (e.g., vehicles following different lanes of a highway), being assigned a same trajectory identifier, since for the purpose of discovering EAS, such trajectories may be considered the same. Another advantage may be that the EES and the requesting entity, being for example the UE or the EAS, may not need to concern themselves with the complexity of comparing the actual trajectories. Namely, the latter may be handled by a separate network entity in form of a trajectory identification server. The trajectory identification server may represent a network entity which may be concerned with, in a centralized manner, maintaining trajectories and their identifiers and which may enable other network entities, such as the aforementioned EES, UE and/or EAS, to look-up trajectory identifiers by submitting location information. The above measures thus jointly establish a mechanism to manage the combined mobility of the mobile EAS and UEs in relation to the discovery of the mobile EAS. The following embodiments may relate to the edge enabler server but may also denote corresponding limitations in the user equipment and trajectory identification server and in any one of the described computer-implemented methods.

In an embodiment, the processor subsystem may be configured to obtain the client trajectory identifier by one of:

- the client trajectory identifier being included in discovery request; and

- obtaining location information indicative of the trajectory of the user equipment and determining the client trajectory identifier based on the location information.

The trajectory identifier of the UE may thus be obtained by the EES by already being included in the discovery request. Alternatively, after receiving the discovery request containing the identifier of the user equipment, the EES may obtain location information indicative of the trajectory of the user equipment, for example from a network function in the telecommunications network which is configured to provide data analytics such as the 5G network data analytics function (NWDAF) or an application data analytics enabler (ADAE) server, or a location management network function. For example, such location information may comprise one or more recent locations of the UE. The location information may typically be indicative of a trajectory. Accordingly, the EES may determine a trajectory identifier of the trajectory based on the location information, for example by sending the location information to the trajectory identification system.

In an embodiment, the processor subsystem may be configured to include the server trajectory identifiers of the one or more mobile edge application servers in the response to the discovery request. The requesting entity may thus not only be provided with the identifiers of the one or more mobile EAS but also with their trajectory identifiers. This may assist the receiving entity in further decision making, for example when having to select one of the one or more mobile EAS, or when determining whether to proceed with a service migration or not. In general, by providing the trajectory identifiers to the receiving entity, a two-step selection process is made possible whereby an initial selection (‘pre-selection’) is performed by the EES, e.g., based on the trajectory identifiers and optionally based on additional further criteria, and a subsequent selection is made by the receiving entity, e.g., resulting in one EAS or in some cases no EAS being selected. This may be advantageous since the receiving entity may have information which may be of relevance to the subsequent selection, and which information may not be available to the EES. In an embodiment, the profile of a respective edge application server may comprise an indication whether the edge application server is mobile. The profile of an EAS may thus be extended with a mobility indicator, e.g., in form of a Boolean. This may allow entities such as the EES itself to determine whether or not an EAS is mobile. This may be advantageous since it may enable the EES to specifically search for mobile EAS instead of a stationary EAS, e.g., if the UE is following a trajectory.

The following embodiments may relate to the user equipment but may also denote corresponding limitations in the edge enabler server and trajectory identification server and in any one of the described computer-implemented methods. It is noted that in these embodiments, some or all of the functionality attributed to the processor subsystem may be functionality implemented by or in an edge enabler client (EEC).

In an embodiment, the processor subsystem may be configured to:

- receive said server trajectory identifiers of the one or more mobile edge application servers from the edge enabler server; and

- select the mobile edge application server for the application client based on a degree of match between the client trajectory identifier and a respective server trajectory identifier.

The UE, and specifically the EEC, may thus not only be provided with the identifiers of the one or more mobile EAS but also with their trajectory identifiers. This may assist the UE in further decision making, for example when having to select one of the one or more mobile EAS identified by the EES, or when determining whether to proceed with triggering a service migration or not. In particular, by providing the trajectory identifiers to the UE, a two-step selection process is made possible whereby an initial selection (‘pre-selection’) is performed by the EES and a subsequent selection is made by the UE, e.g., resulting in one EAS or in some cases no EAS being selected. In particular, the UE may quantify the degree of match between its trajectory identifier and the trajectory identifiers of the EAS and use the degree of match with respect to each EAS in the selection process. It is noted that the UE may also use other information in the selection process, such as data from local measurements.

In an embodiment, the processor subsystem may be configured to obtain the trajectory identifier based on information obtained from at least one of:

- the application client, for example based on an action performed by the application client;

- a network function in the telecommunications network for providing data analytics; a location management network function in the telecommunications network; and

- a signal received by the user equipment, wherein the signal is emitted by a device which is positioned along, or which follows, the trajectory.

The UE may have access to various information which may be indicative of the trajectory that the UE follows or is expected to follow. For example, the application client may perform or may be aware of navigational actions, payment actions, etc., relating to a journey which takes place along the trajectory. Another example is that the UE may sense signals of other devices along or following the trajectory. These types of information may be attributable to a trajectory, which in turn may allow the UE to obtain the trajectory identifier, e.g., via a look-up on the trajectory identification system as described elsewhere. Yet another example is that the UE may retrieve location information from a network function in the telecommunications network which is configured to provide data analytics, such as a location management network function.

In an embodiment, the processor subsystem may be configured to obtain the trajectory identifier by providing information indicative of the trajectory to a trajectory identification server and in response receiving the trajectory identifier from the trajectory identification server.

The following embodiments may relate to the trajectory identification server but may also denote corresponding limitations in the edge enabler server and user equipment and in any one of the described computer-implemented methods.

In an embodiment, the processor subsystem may be further configured to create and/or update trajectory identifiers based on received location information.

The trajectory identification server may thus actively maintain a repository of trajectories and their trajectory identifiers, e.g., by being able to create and update trajectory identifiers based on location information received from other entities, such as for example UEs (which may provide their own location information) or EES (which may provide location information relating to, e.g., a UE or an EAS). By administering such trajectory identifiers centrally, e.g., by a single or distributed trajectory identification server, it may be ensured that trajectory identifiers take a same form throughout the network or at least part thereof, e.g., follow a same assignment systematic, format, etc.

In an embodiment, the processor subsystem may be configured to create and/or update the trajectory identifiers such that a degree of similarity between trajectory identifiers is indicative of a degree of similarity between trajectories identified by the respective trajectory identifiers. The trajectory identifiers may be designed to allow a degree of similarity between trajectories to be determined from a degree of similarity between the trajectory identifiers. For example, dimensionality reduction techniques may be used to encode data to obtain lower-dimensional representations of the trajectory data (e.g., in form of embeddings) which may then be compared for similarity (e.g., using simple pairwise similarity measures such as the Euclidean distance) to determine the similarity of the original data. This may allow network entities such as the EES and UE to determine a match between trajectory identifiers, and if the match is a partial match, treat the degree of the partial match as an indication of the similarity of the corresponding trajectories. This may be highly advantageous since on the one hand, an abstraction is obtained from the actual trajectories, while on the other hand, the abstraction still allows for the similarities of trajectories to be determined.

In an embodiment, the trajectory repository may further identify portions of trajectories, wherein a respective portion of a trajectory may be identifiable by a subidentifier of the trajectory identifier, a location, and/or an estimated time of arrival of a device. Two trajectories may overlap only over a certain distance, e.g., by sharing a common portion of the trajectories. By identifying different portions of trajectories and making them separable identifiable within the trajectory identifier, e.g., as separate parts of the identifier or by other auxiliary data (such as the location or the estimated time of arrival of a device), it may be determined whether two trajectories, which may not be identical, nevertheless share a common portion. This may be relevant information for the selection of a mobile EAS and/or for further decision making associated with service migration or service deployment. For example, it may allow different mobile EAS to be selected for different portions of the trajectory of the UE.

In an embodiment, the edge enabler server may be a mobile edge enabler server, for example a vehicular edge enabler server. It has been recognized that it may be advantageous if the EES itself is also mobile. Namely, similar as a mobile UE leaving the service area of a stationary EAS, the mobile UE may also leave the service area of a stationary EES, which may trigger a handover to another EES. While such handovers between EES may be less frequent and less disruptive than handovers between stationary EAS, e.g., since the service area of an EES may be larger than that of an EAS, it may nevertheless be advantageous to reduce the frequency of such handovers. This may be achieved providing a mobile EES and by using an edge configuration server which is configured to provision EES based on their mobility and the UE mobility, as also further elucidated in the following aspect of the invention.

In a further aspect of the invention, which is related to the aforementioned mobile edge enabler server, an edge configuration server is provided for a telecommunications network. The edge configuration server may comprise: - a network interface to the telecommunications network;

- a processor subsystem which may be configured to: access a data storage comprising profiles of edge enabler servers, wherein at least a subset of the edge enabler servers may be mobile edge enabler servers, wherein a profile of a mobile edge enabler server may comprise a server trajectory identifier, wherein the server trajectory identifier may be indicative of a trajectory of the mobile edge enabler server; receive a provisioning request for provisioning an edge enabler server, wherein the provisioning request may comprise an identifier of the user equipment; obtain a client trajectory identifier of the user equipment, wherein the client trajectory identifier may be indicative of a trajectory of the user equipment; identify, based on the profiles of the edge enabler servers, one or more mobile edge enabler servers of which the server trajectory identifier at least partially matches the client trajectory identifier; and send identifiers of the one or more mobile edge enabler servers as a response to the provisioning request.

In a further aspect of the invention, a computer-implemented method is provided for execution at an edge configuration server of a telecommunications network. The method may comprise:

- accessing a data storage comprising profiles of edge enabler servers, wherein at least a subset of the edge enabler servers may be mobile edge enabler servers, wherein a profile of a mobile edge enabler server may comprise a server trajectory identifier, wherein the server trajectory identifier may be indicative of a trajectory of the mobile edge enabler server;

- receiving a provisioning request for provisioning an edge enabler server, wherein the provisioning request may comprise an identifier of the user equipment;

- identifying, based on the profiles of the edge enabler servers, one or more mobile edge enabler servers of which the server trajectory identifier at least partially matches the client trajectory identifier; and

- sending identifiers of the one or more mobile edge enabler servers as a response to the provisioning request.

The above aspects of the invention provide an edge configuration server (ECS) which may be configured to identify one or more EES to a requesting entity in response to a provisioning request received from the requesting entity. The mechanism which is employed by the ECS may be similar to that used by the EES to enable the discovery of mobile EAS based on the mobility of the EAS and the mobility of the UE. Namely, the ECS may maintain or otherwise access data storage comprising profiles of EES which may include one or more mobile EES. A profile of a mobile EES may, like the profile of a mobile EAS, comprise a trajectory identifier of a trajectory which is followed, or is expected to be followed, by the mobile EES. When a provisioning request is received for a UE, the ECS may determine the trajectory identifier of the trajectory of the UE and may then identify one or more mobile EES for which there exists a (partial) correspondence between the trajectory identifier of the respective mobile EES and the trajectory identifier of the UE by searching the profiles of the EESs. This way, the response to the provisioning request may take the mobility of both the mobile EES and the mobility of the UE into account. By doing so, there may be less need for context relocation between EES. Likewise, the abstraction from the actual trajectories by means of trajectory identifiers may provide the advantages as described elsewhere in this specification.

In a further aspect of the invention, an edge application server is provided for a telecommunications network, wherein the edge application server is a mobile edge application server, wherein the edge application server may be co-located with a mobile base station relay, for example by being provided in a same vehicle as the mobile base station relay. It has been recognized that, when employing a mobile EAS, the mobile EAS may be advantageously co-located with a mobile base station relay as this may avoid or reduce the need for context relocation for the mobile EAS between stationary base stations and/or mobile base station relays.

In a further aspect of the invention, a telecommunications network is provided comprising at least one of: the edge enabler server, the edge configuration server, the trajectory identification server, and the edge application server. The telecommunications network may be a mobile telecommunications network.

It will be appreciated by those skilled in the art that two or more of the above-mentioned embodiments, implementations, and/or aspects of the invention may be combined in any way deemed useful.

Modifications and variations of any one of the systems or devices (e.g., servers, network functions, user equipment, etc.), computer-implemented methods, and/or computer programs, which correspond to the described modifications and variations of another one of these systems or devices, computer-implemented methods, and/or computer programs, or vice versa, may be carried out by a person skilled in the art on the basis of the present description.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other aspects of the invention are apparent from and will be elucidated with reference to the embodiments described hereinafter. In the drawings,

Fig. 1 shows a UE following a trajectory which necessitates multiple ACRs between static EASs along the trajectory of the UE;

Fig. 2 shows the UE being served by a mobile EAS which follows a same or similar trajectory as the UE;

Fig. 3A shows a UE being connected to a static EAS while the UE is predicted to follow a trajectory which is similar to that of a second mobile EAS2;

Figs 3B show ACR being performed towards the second mobile EAS2;

Fig. 4 shows a mobile EAS and UE moving from the service area of a first static EES1 into the service area of a second static EES2;

Fig. 5 shows a mobile EES and mobile EAS moving along with the UE;

Fig. 6 shows a processor system which may be exemplary for an edge enabler server, a user equipment, for example comprising an edge enabler client and/or an application client, an edge configuration server, an edge application server, and/or a trajectory identification server, as described in this specification;

Fig. 7 shows a non-transitory computer-readable medium comprising data;

Fig. 8 shows an exemplary data processing system.

Reference signs list

The following list of references and abbreviations is provided for facilitating the interpretation of the drawings and shall not be construed as limiting the claims.

AC application client

EAS edge application server

ECS edge configuration server

EEC edge enabler client

EES edge enabler server

UE user equipment

10 (predicted) trajectory of UE 20-22 (planned) trajectory of EAS

30 (planned) trajectory of EES

40-41 application context relocation (ACR)

50 enable enabler client context relocation transfer

60-66 service area of EAS

70-71 service area of EES

100 system

120 network interface

122 received data

124 sent data

140 processor subsystem

160 data storage

200 non-transitory computer-readable medium

210 stored data

300 application client

310-314 edge application server

320 edge configuration server

330 edge enabler client

340-342 edge enabler server

350 user equipment

1000 exemplary data processing system

1002 processor

1004 memory element

1006 system bus

1008 local memory

1010 bulk storage device

1012 input device

1014 output device

1016 network adapter

1018 application DESCRIPTION OF EMBODIMENTS

The following embodiments are described in the context of a 5G telecommunications network adhering to one or more 3GPP, ETSI NFV and/or related standards. The following also specifically references entities and mechanisms defined in standard document [3], which pertains to Multi-access Edge Computing (MEC). Nonetheless, the embodiments described in this specification are not confined solely to this context. Rather, they can be adapted and applied to other telecommunications networks, such as those adhering to different standards like earlier generation (e.g., 4G) or subsequent generation (e.g., 6G or 7G) standards, especially those that facilitate offloading computations to edge resources. Hence, terms like ‘edge enabler server’, ‘edge enabler client’, and ‘edge configuration server’, which may be commonly recognized as MEC entities, also have a broader application. To illustrate, ‘edge enabler server’ may denote any entity that serves a client to enable the edge-related processes described in this specification.

Briefly speaking, the following embodiments may involve measures to support the mobility of mobile edge resources, such as mobile User Equipment (UE), mobile Edge Application Servers (EAS) and mobile Edge Enabler Servers (EES).

Fig. 1 shows a UE following a trajectory 10. For example, the UE may be onboard a vehicle that follows the trajectory 10. The UE may be configured to make use of an edge application service provided by edge resources of the telecommunications network. For example, the UE may initially be located in a service area 60 of a first EAS (‘EAS T) and may utilize the edge application service from the EAS 1. The EAS 1 may be a static EAS, meaning that the service area 60 of the EAS 1 may remain substantially in place over time. When travelling along the trajectory 10, the UE may leave the service area 60 of the EAS 1 and enter the service area 61 of a second EAS (‘EAS 2’). When then continuing to travel along the trajectory 10, the UE may again leave the service area 61 of the EAS 2 and enter the service area 62 of a third EAS (‘EAS 3’). Fig. 1 thus serves to illustrate that a UE may connect, and indeed may need to connect, to multiple EASs along its trajectory in order to continue utilizing the edge application service. At the EASs, this may necessitate application context relocations (ACR) 40, 41 between the EASs along the trajectory of the UE. Namely, when moving into the service area 61 of the EAS 2, the application context may need to be relocated by an ACR 40 from the EAS 1 to the EAS 2. Furthermore, when moving into the service area 62 of the EAS 3, the application context may again need to be relocated by an ACR 41 from the EAS 2 to the EAS 3. Disadvantageously, such ACRs may cause service interruption, management overhead, require bandwidth, etc. Fig. 2 shows the UE again following the trajectory 10 but now being served by a mobile EAS which follows a same or similar trajectory 20 as the UE. Such a mobile EAS may also be considered an ‘extreme edge mobile EAS’ by being located at the (very) edge of the telecommunications network. The trajectory 20 of the EAS may be the same or similar as the trajectory 10 of the UE for a number of reasons. For example, the EAS may be installed onboard a vehicle which carries the UE, such as a train, tram, bus, boat, airplane, etc. Another example is that the EAS may be in a different vehicle than the UE, but both vehicles may travel together in a platoon. Due to the mobile EAS moving along with the UE, the UE may stay within the service area 63 of the mobile EAS while travelling along the trajectory 10. Accordingly, instead of having to connect to multiple successive static EASs along its path, as in the Fig. 1 example, the UE may connect to a mobile EAS that has a matching trajectory with the UE. This may significantly reduce the number of ACRs which are required along the trajectory 10. In this respect, it is noted that the UE may either directly connect to a mobile EAS when initially starting to use the edge application service, or may be directed to the mobile EAS from another, e.g., static, EAS, using an ACR.

It may be of particular interest to be able to discover a mobile EAS which follows the same or similar trajectory as a UE. The following embodiments describe an EES which may be configured to enable a requesting entity to discover such a mobile EAS for a UE. For that purpose, the EES may keep track of the trajectories of mobile EASs and match them with the UE mobility. To enable such matching, in some embodiments, mobility information may be included in profiles of mobile entities, with the mobility information comprising a trajectory identifier which identifies a trajectory which is, or is expected to be, followed by the respective mobile entity. For example, such mobility information of a UE may be stored in the Application Client (AC) profile, mobility information of an EAS may be stored in an EAS profile, and mobility information of an EES may be stored in an EES profile. The AC profile may be stored in the UE, e.g., in the EEC, and may be sent to the EES during EAS discovery. The EAS profile may be stored in the EES. The EES profile may be stored in the ECS.

As illustrated in table 1 below, the EAS profile and EES profile may include a ‘mobility indication’ information element which may indicate whether or not a respective entity is mobile. The AC Profile, EAS profile, and where applicable the EES profile may also include the aforementioned ‘trajectory identifier’, in short ‘trajectory ID’, information. The trajectory ID information element information element may indicate a current, planned, or predicted path of a respective entity. An entity in the Edge Enabler Layer (EEL), such as the aforementioned EES, may use the trajectory IDs from the AC profile and the EAS profile to determine which trajectories are matching, and optionally for which duration/distance. Based on this comparison, a most suitable mobile EAS may then be selected for the UE.

Table 1. Example of an AC profile, EAS profile or EES profile including the mobility indication and trajectory ID

Fig. 3A shows a UE which is currently connected to a static EAS (but which may also be a mobile EAS that would not be able to serve the UE anymore for any reason). The static EAS is shown to have a service area 64 while the UE is shown to have a planned and/or predicted trajectory 10 which would cause the UE to leave the service area 64. The planned and/or predicted trajectory of the UE and the planned and/or predicted trajectories of mobile EASs may be known to EES, for example by being included in form of a trajectory ID in the AC profile and in the EAS profile, respectively. Due to the UE’s mobility, a detecting entity (e.g., EEC, EAS, or EES) may determine that there is a probable need for an ACR, and a decision entity (e.g., EEC, EAS, or EES) may determine that the ACR is required and instruct an execution entity (e.g., EEC, EAS, or EES) to perform the ACR. The execution entity (e.g., EEC, EAS, or EES) may then trigger an EAS discovery operation to determine the target EAS for the ACR. In this embodiment, the EES may use the trajectory IDs of both the AC and the mobile EAS for discovery of a suitable target EAS so as to be able to trigger an ACR to the selected target EAS. In this embodiment, the EES may not select the mobile EAS 1 even though the UE with its EEC is currently within its service area 65. Namely, the EES may compare the trajectories 21 , 22 of the mobile EASs with the predicted trajectory 10 of the UE to determine the target EAS for the UE. Accordingly, the EES may find that the trajectory 21 of the mobile EAS 1 deviates significantly from the trajectory 10 of the UE, while the trajectory 22 of the mobile EAS 2 with its service area 66 may be sufficiently similar to the trajectory 10 of the UE. Consequently, as shown in Fig. 3B, the ACR 42 may be performed between the static EAS and the mobile EAS 2. It is noted that when the respective mobile EAS (e.g., “EAS 2” in the Fig.

3A/3B embodiment) and the UE continue to move along their trajectory, they may leave the coverage area of the EES. In that case, both the mobile EAS and the EEC within the UE may need to connect to a different EES. In that case, as also shown in Fig. 4, the mobile EAS or the EES may determine that the mobile EAS may need to register with a new EES as the mobile EAS is likely to leave the service area 70 of the EES 1 , and may trigger a T-EES (“Target EES”) retrieval operation on the Edge Configuration Server (ECS). The ECS may then use mobility information included in the EAS profile, such as the trajectory ID, to determine a suitable EES that the mobile EAS should register with. In the example of Fig. 4, the T-EES may be the static EES 2 having a service area 71 located further along the trajectory 20 of the mobile EAS. The mobile EAS may then de-register from the static EES 1 and may register with the static EES 2, and the EEC context may be transferred to the static EES 2 using an EEC context relocation 50. In this embodiment, ACRs may be avoided as long as the UE and mobile EAS trajectories are similar. Moreover, the EEC context may only need to be transferred between EESs when the UE with its EEC and the mobile EAS are moving between the service areas of different static EESs. Since the service area of an EES may be larger than the service area of an EAS, the EEC context transfers may be less frequent than ACRs, which may reduce overhead and possible service interruptions.

Fig. 5 describes an embodiment which is concerned with reducing the number of EEC context transfers and the de-registrations and registration of the mobile EASs with static EESs. In this embodiment, a mobile EES may be provided. The mobile EES may in some cases be assigned to one or more mobile EASs, in that the mobile EES may manage the mobile EASs that are on the same or similar trajectory (e.g., onboard the same vehicle) as the EES. This is illustrated in Fig. 5 by the mobile EES having a trajectory 30 which is substantially similar to the trajectory 20 of the mobile EAS, and indeed similar to the trajectory 10 of the UE. The service area 70 of the EES may thus move along the trajectory 30 causing the mobile EAS to stay within this service area. This may avoid or reduce a need for the mobile EAS to connect to other EESs and avoid or reduce EEC context transfers and de-registration and reregistration. In such an embodiment, the EES profile may include mobility information such as a trajectory ID, and the EES profile may be used by the ECS to determine the EES location and either provision (configure) the EEC with a matching EES, or perform T-EES retrieval for the EAS depending on which entity triggers the ACR. The triggering entity may then perform an EAS discovery procedure on the selected target mobile EES to determine the target mobile EAS and perform ACR. This way, the EEC may be connected with the mobile EES and the AC may be connected with the mobile EAS that have a similar trajectory, and ACR and EEC context transfers may be avoided.

The following describes procedures which may be carried out by entities in the EEL. While reference is made to existing procedures in [3], the procedures described below may represent modified or extended versions of the existing procedures to take mobility information, such as the trajectory ID, into account.

A service provisioning procedure may allow the UE to discover a suitable EES. As part of such a procedure, the EEC may send a service provisioning request to the ECS that includes the AC profile (which AC profile may include the trajectory ID) as well as additional filter criteria that allow the ECS to determine the appropriate EES by matching the trajectory ID of the UE with those of the mobile EESs and the positions of the static EESs, and to verify whether the EES satisfies the additional filters. See also Figure 8.3.3.2.2-1 titled “Service provisioning - Request/Response” of [3],

An EAS discovery procedure may be used to select the target EAS for ACR. The EAS discovery procedure may be performed by the EES based on the AC profile and the EAS profiles of the EASs that are registered in the EES. The target EAS may be selected by matching EAS discovery filters and the trajectory IDs of the UE and EASs. See also Figure 8.5.2.2-1 titled “EAS Discovery procedure” of [3],

If no suitable EAS is found, the EES may request the ECS to select a different target EES that has a suitable registered EAS, then the source EES may send the EAS discovery request to the selected target EES. In that case, the EEC context may be transferred to the target EES that manages the target EAS for ACR. See also Figure 8.8.3.3-1 titled “Retrieve T-EES procedure” of [3],

When triggered by the EEC, the EAS discovery procedure may be performed in multiple ways:

- The EES may directly select the target EAS based on the discovery filters and the trajectory IDs;

- The EES may perform a preliminary filtering, e.g., based on approximately matching trajectory IDs and/or the discovery filters, and send a list of potential target EASs to the EEC. The EEC may then perform the target EAS selection.

The target EAS discovery may also be triggered by the source EAS or the source EES. In that case, the EAS discovery request may include the trajectory ID of the AC. See also Figure 8.8.3.2-1 titled “Discover T-EAS” of [3],

With continued reference to the trajectory IDs, it is noted that these trajectory IDs may be managed by a centralized entity that may be configured to allocate IDs to trajectories. This centralized entity may elsewhere also be referred to as a trajectory identification server. By centralizing the management of those IDs, a consistent identification of trajectories may be provided throughout the EEL. As such, entities within the EEL which follow or are planned or predicted to follow a similar trajectory may be assigned the same trajectory ID, which may facilitate the matching or mapping of UE mobility to EAS mobility. In some examples, the trajectory identification server role may be performed by the ECS or another dedicated component in the EEL, or it could be an external function. In some examples, the centralized entity may be configured to update and/or create trajectory IDs based on location information received from entities. In some examples, trajectory IDs may be generated to allow the degree of similarity between trajectories to be identified based on the degree of similarity between trajectory IDs.

In some examples, the trajectory of the mobile EAS and optionally the mobile EES may be known in advance. Thus, the corresponding trajectory IDs may be initially already included in the EAS and EES profile, for example during registration.

The trajectory of the UE may be less likely to be known in advance. Nevertheless, the trajectory of the UE may be determined in multiple ways, e.g.:

- The AC may provide location information which is indicative of the trajectory of the UE to the EEL, for example by detecting that the UE has started a navigation application to reach a certain destination. Such location information may also be obtained from a ticket being purchased to use public transit, e.g., a bus or train, or from the UE connecting to the public transit Wi-Fi network, or in various other ways.

- The location information may also be provided by the 5G core, e.g., by the 5G network data analytics function (NWDAF), or the Application Data Analytics Enablement (ADAE) server in the application layer [4] (see ‘further references’ at the end of the detailed description), where the UE mobility may be determined or predicted based on, e.g., the UE’s movements, past trajectories, and/or behavior patterns.

In some examples, the trajectory ID may allow portions of the trajectory to be identified, e.g., by sub-identifier of the trajectory ID, a location, and/or an estimated time of arrival of a device. This may be useful in reducing the number of trajectory IDs that are stored in the system. Namely, trajectory IDs may be allocated to the most frequently used trajectories (e.g., roads between cities, or statistically popular trajectories). An AC profile may then store additional information next to the trajectory ID in order to delimit the portion of the trajectory that applies to the UE. As indicated above, such additional information may for example be a time limitation or locations (e.g., the EEC is expected to take the road number X between cities A and B only). The further identification of portions of trajectories may also be useful to facilitate trajectory matching between the UE and the mobile EAS. For example, if the mobile EAS is onboarded on a bus connecting cities A and B, and the UE is expected to also be onboard that bus, the UE may receive the trajectory ID of the mobile EAS of the bus when purchasing a ticket, and provide the trajectory ID to the EEL via the AC. The EEL may then direct the EEC and thereby the UE to the mobile EAS on the bus.

In some examples, multiple trajectory IDs may be combined to reconstruct a full journey of an entity, such as a UE, which may help to plan a series of ACRs between multiple mobile EASs in advance, for example in case the UE onboards multiple vehicles on its journey (e.g., a journey combining two trains and a bus).

In some examples, the trajectory of any of the EAS or EES may be dynamic, meaning that it is not confirmed and may change over time. To reduce the need for frequent changes in the trajectory ID, an alternative may be to only include the mobility indication in the profile. Then, when the current trajectory of the entity is needed (e.g., for T-EES retrieval of EAS discovery), the EES or ECS may trigger a request on the Application Data Analytics Enablement (ADAE) layer in the application layer [4] to determine the entity’s current position and trajectory or the latest prediction of its trajectory. The static EES may also directly query the mobile EAS for its position, and the ECS may query the mobile EES for its position. In another alternative embodiment, the latest position or trajectory may be retrieved periodically.

In some examples, a mobile EAS may be co-located with a Mobile Base Station Relay (MBSR). Examples of MBSR are defined in [5], For example, both a MBSR and a mobile EAS may be onboarded on the same vehicle, which may allow to provide both 5G connectivity and edge computation services to a UE and may reduce network load and communication latency with the mobile EAS since the mobile EAS may be directly deployed on the access point of the UE. Furthermore, in such examples, the Location Services (LCS) provided by the 5G core may be used to retrieve the location information and velocity of the MBSR (and thus the mobile EAS and possibly the mobile EES) through the Location Management Function (LMF) [6],

In some examples, an artificial intelligence (Al) and/or machine learning (ML) model may be used for various prediction and selection purposes. For example, an AI/ML model may be generated, e.g., by training, and subsequently used to create and update trajectory IDs in a way that allows mobile EAS to be optimally assigned to UEs and thereby to optimally create mobile EAS and UE associations. Namely, the AI/ML model may be used to detect similarities between trajectories of UEs and mobile EASs and may assign similar trajectory IDs to similar trajectories to facilitate EAS selection for the UE. The decision entity may then determine the target EAS according to the trajectory ID and additional parameters such as EAS discovery filters.

An AI/ML model may also be used for prediction and selection purposes while taking into account more parameters than only the trajectory of an entity. For example, for frequent travels which often follow same path, an AI/ML model may be trained and subsequently used to predict the appropriate mobile EAS for the UE based on information such as their past trajectory, past mobile EAS utilization, and/or past performance. Such an AI/ML model may for example be deployed at the ADAE layer. The EEL may provide the identifiers of the UEs and static and mobile EASs. The ADAE layer may then retrieve or predict the trajectory of the UEs and mobile EAS and establish optimal UE and mobile EAS associations considering mobility and optionally other performance metrics. The AI/ML model may also be deployed on the NWDAF in the 5G core, which may be accessed through the Network Exposure Function (NEF) [7], Additionally, using the trajectory predictions, the UE and EAS associations may take into account a longer term period, whereby a set of successive mobile EASs may be selected for mobility of the UE, which may allow for a more complex scheduling of ACRs for a longer time in advance and which may allow sufficient resources to be reserved on the EASs for when the UE is within a respective EAS’s service area.

In general, the functionality described in this specification may represent functionality of one or more network functions which are implemented in the respective telecommunications network, e.g., by a network node or a system of network nodes. The network function(s) may be made available within the telecommunications network so as to establish the respective functionality in the telecommunications network.

Fig. 6 shows a system 100 which may represent one or more of an edge enabler server, a user equipment, for example comprising an edge enabler client and/or an application client, an edge configuration server, an edge application server, and a trajectory identification server, as also described elsewhere in this specification. The system 100 may comprise a network interface 120 for network data communication, e.g., to receive data 122 and to send data 124. The network interface 120 may for example be a wired communication interface, such as an Ethernet or fiberoptic based interface, to a fixed (e.g., non-mobile) part of a mobile telecommunications network. Alternatively, for example when the system 100 embodies a mobile entity, the network interface 120 may be a wireless communication interface, such as a 4G, 5G, or previous generation or later generation radio interface. In yet other examples, the system 100 may be a subsystem of a larger system, e.g., a supra-system implementing several network functions. In such cases, the network interface 120 may be an internal interface of the supra-system, for example a virtual, software-based network interface. The system 100 may further comprise a processor subsystem 140 which may be configured, e.g., by hardware design or software, to perform the operations described in this specification in as far as pertaining to the entity that the system is embodying, e.g., the aforementioned edge enabler server, edge enabler client, user equipment, edge configuration server, and/or edge application server. In particular, the processor subsystem 140 may be configured to perform the actions attributed to the respective entity as described in this specification with reference to Figs. 1-5 and elsewhere.

In general, the processor subsystem 140 may be embodied by a single Central Processing Unit (CPU), such as a x86 or ARM-based CPU, but also by a combination or system of such CPUs and/or other types of processing units. In embodiments where the system 100 is distributed over different entities, e.g., over different servers, the processor subsystem 140 may also be distributed, e.g., over the CPUs of such different servers. As also shown in Fig. 6, the system 100 may comprise a data storage 160, such as a hard drive, a solid-state drive, or an array of such hard and/or solid-state drives, etc., which may be used to store data. In some examples, the system 100 may be implemented by a network node, or by a system of network nodes.

With continued reference to the embodiment in which the system 100 represent user equipment, or a device representing user equipment, it is noted that examples of such user equipment or devices include, but are not limited to, a mobile phone, a tablet device, a computer, a pair of smart glasses, or an loT device such as a robot, a connectivity enabled vehicle, etc. In such cases, the network interface 120 may represent a radio access network interface to a mobile network, and the processor subsystem 140 may be configured, e.g., by hardware design or software, to perform the operations described in this specification in as far as pertaining to the entity that the processor system is embodying, e.g., the user equipment or the device.

In general, each entity described in this specification may be embodied as, or in, a device or apparatus. The device or apparatus may comprise one or more (micro) processors which execute appropriate software. The processor(s) of a respective entity may be embodied by one or more of these (micro)processors. Software implementing the functionality of a respective entity may have been downloaded and/or stored in a corresponding memory or memories, e.g., in volatile memory such as RAM or in non-volatile memory such as Flash. Alternatively, the processor(s) of a respective entity may be implemented in the device or apparatus in the form of programmable logic, e.g., as a Field-Programmable Gate Array (FPGA). Any input and/or output interfaces may be implemented by respective interfaces of the device or apparatus. In general, each functional unit of a respective entity may be implemented in the form of a circuit or circuitry. A respective entity may also be implemented in a distributed manner, e.g., involving different devices or apparatus.

It is noted that any of the methods described in this specification, for example in any of the claims, may be implemented on a computer as a computer implemented method, as dedicated hardware, or as a combination of both. Instructions for the computer, e.g., executable code, may be stored on a computer-readable medium 200 as for example shown in Fig. 7, e.g., in the form of a series 210 of machine-readable physical marks and/or as a series of elements having different electrical, e.g., magnetic, or optical properties or values. The executable code may be stored in a transitory or non-transitory manner. Examples of computer-readable mediums include memory devices, optical storage devices, integrated circuits, servers, online software, etc. Fig. 7 shows by way of example a memory card 200.

Fig. 8 is a block diagram illustrating an exemplary data processing system 1000 that may be used in the embodiments described in this specification. Such data processing systems include data processing entities described in this specification, including but not limited to an edge enabler server, a user equipment, for example comprising an edge enabler client and/or an application client, an edge configuration server, an edge application server, and a trajectory identification server. The data processing system 1000 may include at least one processor 1002 coupled to memory elements 1004 through a system bus 1006. As such, the data processing system may store program code within memory elements 1004. Furthermore, processor 1002 may execute the program code accessed from memory elements 1004 via system bus 1006. In one aspect, data processing system may be implemented as a computer that is suitable for storing and/or executing program code. It should be appreciated, however, that data processing system 1000 may be implemented in the form of any system including a processor and memory that is capable of performing the functions described within this specification. The memory elements 1004 may include one or more physical memory devices such as, for example, local memory 1008 and one or more bulk storage devices 1010. Local memory may refer to random access memory or other non-persistent memory device(s) generally used during actual execution of the program code. A bulk storage device may be implemented as a hard drive, solid state disk or other persistent data storage device. The data processing system 1000 may also include one or more cache memories (not shown) that provide temporary storage of at least some program code in order to reduce the number of times program code is otherwise retrieved from bulk storage device 1010 during execution. Input/output (I/O) devices depicted as input device 1012 and output device 1014 optionally can be coupled to the data processing system. Examples of input devices may include, but are not limited to, for example, a microphone, a keyboard, a pointing device such as a mouse, a game controller, a Bluetooth controller, a VR controller, and a gesture-based input device, or the like. Examples of output devices may include, but are not limited to, for example, a monitor or display, speakers, or the like. Input device and/or output device may be coupled to data processing system either directly or through intervening I/O controllers. A network adapter 1016 may also be coupled to data processing system to enable it to become coupled to other systems, computer systems, remote network devices, and/or remote storage devices through intervening non-public or public networks. The network adapter may comprise a data receiver for receiving data that is transmitted by said systems, devices and/or networks to said data and a data transmitter for transmitting data to said systems, devices and/or networks. Radios, modems, cable modems, and ethernet cards are examples of different types of network adapter that may be used with data processing system 1000. As shown in Fig. 8, memory elements 1004 may store an application 1018. It should be appreciated that data processing system 1000 may further execute an operating system (not shown) that can facilitate execution of the application. The application, being implemented in the form of executable program code, can be executed by data processing system 1000, e.g., by processor 1002. Responsive to executing the application, the data processing system may be configured to perform one or more operations to be described herein in further detail. For example, data processing system 1000 may represent an edge enabler server. In that case, application 1018 may represent an application that, when executed, configures data processing system 1000 to perform the functions described with reference to the edge enabler server. In another example, data processing system 1000 may represent an embodiment of an edge application server as described in this specification. In that case, application 1018 may represent an application that, when executed, configures data processing system 1000 to perform the functions described with reference to the edge application server. In another example, data processing system 1000 may represent an embodiment of an edge configuration server as described in this specification. In that case, application 1018 may represent an application that, when executed, configures data processing system 1000 to perform the functions described with reference to the edge configuration server. In another example, data processing system 1000 may represent an embodiment of a trajectory identification server as described in this specification. In that case, application 1018 may represent an application that, when executed, configures data processing system 1000 to perform the functions described with reference to the trajectory identification server. In another example, data processing system 1000 may represent an embodiment of user equipment or a device representing user equipment as described in this specification. In that case, application 1018 may represent an application that, when executed, configures data processing system 1000 to perform the functions described with reference to the user equipment and/or device.

An abstract for the present specification may read as follows: Systems and methods are described for enabling discovery of mobile EAS which follow the same or similar trajectory as a UE. For example, an EES may be configured to enable a requesting entity to discover such mobile EAS for a UE. For that purpose, the EES may keep track of the trajectories of mobile EAS and match them with the UE mobility. To enable such matching, in some embodiments, mobility information may be included in profiles of the respective entities, with the mobility information comprising a trajectory identifier which identifies a trajectory which is, or is expected to be, followed by the respective entity. By enabling a mobile EAS to be assigned to UE on the basis of similarity in trajectory, there may be less need for ACRs, which otherwise may run the risk of service interruptions and which may be expensive in terms of required bandwidth, storage, etc.

It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims.

In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. Use of the verb "comprise" and its conjugations does not exclude the presence of elements or stages other than those stated in a claim. The article "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. Expressions such as “at least one of” when preceding a list or group of elements represent a selection of all or of any subset of elements from the list or group. For example, the expression, “at least one of A, B, and C” should be understood as including only A, only B, only C, both A and B, both A and C, both B and C, or all of A, B, and C. The invention may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In the device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. Further references

[4] 3GPP TS 23.436, Technical Specification Group Services and System Aspects; Functional architecture and information flows for Application Data Analytics Enablement Service; (Release 18); V18.0.0.

[5] 3GPP TS 23.501, Technical Specification Group Services and System Aspects; System architecture for the 5G System (5GS); Stage 2 (Release 18); V18.2.0

[6] 3GPP TS 23.273, Technical Specification Group Services and System Aspects; 5G System (5GS) Location Services (LOS); Stage 2; (Release 18); V18.2.0 [7] 3GPP TS 23.288, Technical Specification Group Services and System

Aspects; Architecture enhancements for 5G System (5GS) to support network data analytics services (Release 18); V18.0.0

Claims

Claim 1. An edge enabler server for a telecommunications network, comprising: a network interface to the telecommunications network; a processor subsystem configured to: access a data storage comprising profiles of edge application servers, wherein at least a subset of the edge application servers are mobile edge application servers, wherein a profile of a mobile edge application server comprises a server trajectory identifier, wherein the server trajectory identifier is indicative of a trajectory of the mobile edge application server; receive a discovery request to discover an edge application server for a user equipment, wherein the discovery request comprises an identifier of the user equipment; obtain a client trajectory identifier of the user equipment, wherein the client trajectory identifier is indicative of a trajectory of the user equipment; identify, based on the profiles of the edge application servers, one or more mobile edge application servers of which the server trajectory identifier at least partially matches the client trajectory identifier; and send identifiers of the one or more mobile edge application servers as a response to the discovery request.

Claim 2. The edge enabler server according to claim 1, wherein the processor subsystem is configured to obtain the client trajectory identifier by one of: the client trajectory identifier being included in discovery request; and obtaining location information indicative of the trajectory of the user equipment and determining the client trajectory identifier based on the location information.

Claim 3. The edge enabler server according to claim 1 or 2, wherein the processor subsystem is configured to include the server trajectory identifiers of the one or more mobile edge application servers in the response to the discovery request.

Claim 4. The edge enabler server according to any one of claims 1 to 3, wherein the profile of a respective edge application server comprises an indication whether the edge application server is mobile.

Claim 5. The edge enabler server according to any one of claims 1 to 4, wherein the edge enabler server is a mobile edge enabler server, for example a vehicular edge enabler server.

Claim 6. A user equipment for a telecommunications network, comprising: a network interface to the telecommunications network; a processor subsystem configured to, during operation, execute an application client and an edge enabler client, wherein the processor subsystem is further configured to, using the edge enabler client: send a discovery request to an edge enabler server, wherein the discovery request comprises a client trajectory identifier, wherein the client trajectory identifier is indicative of a trajectory of the user equipment; receive identifiers of one or more mobile edge application servers from the edge enabler server in response to the discovery request, wherein the one or more mobile edge application servers are each assigned a server trajectory identifier which at least partially matches the client trajectory identifier; and configure the application client with a mobile edge application server selected from the one or more mobile edge application servers.

Claim 7. The user equipment according to claim 6, wherein the processor subsystem is configured to: receive said server trajectory identifiers of the one or more mobile edge application servers from the edge enabler server; and select the mobile edge application server for the application client based on a degree of match between the client trajectory identifier and a respective server trajectory identifier.

Claim 8. The user equipment according to claim 6 or 7, wherein the processor subsystem is configured to obtain the trajectory identifier based on information obtained from at least one of: the application client, for example based on an action performed by the application client; a network function in the telecommunications network for providing data analytics; a location management network function in the telecommunications network; and a signal received by the user equipment, wherein the signal is emitted by a device which is positioned along, or which follows, the trajectory.

Claim 9. The user equipment according to any one of claims 6 to 8, wherein the processor subsystem is configured to obtain the trajectory identifier by providing information indicative of the trajectory to a trajectory identification server and in response receiving the trajectory identifier from the trajectory identification server.

Claim 10. An edge configuration server for a telecommunications network, comprising: a network interface to the telecommunications network; a processor subsystem configured to: access a data storage comprising profiles of edge enabler servers, wherein at least a subset of the edge enabler servers are mobile edge enabler servers, wherein a profile of a mobile edge enabler server comprises a server trajectory identifier, wherein the server trajectory identifier is indicative of a trajectory of the mobile edge enabler server; receive a provisioning request for provisioning an edge enabler server, wherein the provisioning request comprises an identifier of the user equipment; obtain a client trajectory identifier of the user equipment, wherein the client trajectory identifier is indicative of a trajectory of the user equipment; identify, based on the profiles of the edge enabler servers, one or more mobile edge enabler servers of which the server trajectory identifier at least partially matches the client trajectory identifier; and send identifiers of the one or more mobile edge enabler servers as a response to the provisioning request.

Claim 11. The edge configuration server according to claim 10, wherein the profile of a respective edge enabler server comprises an indication whether the edge enabler server is mobile.

Claim 12. A trajectory identification server for a telecommunications network, comprising: a network interface to the telecommunications network; a processor subsystem configured to: access a trajectory repository comprising trajectory identifiers for trajectories, wherein an entry in the trajectory repository comprises trajectory information defining of a trajectory and a trajectory identifier assigned to the trajectory; receive a trajectory identification request, wherein the trajectory identification request comprises location information indicative of a device trajectory of a device; search the trajectory repository for a trajectory identifier for the device trajectory by comparing the location information to the trajectory information stored in respective entries of the trajectory repository; and send the trajectory identifier as a response to the trajectory identification request.

Claim 13. The trajectory identification server according to claim 12, wherein the processor subsystem is further configured to create and/or update trajectory identifiers based on received location information.

Claim 14. The trajectory identification server according to claim 13, wherein the processor subsystem is configured to create and/or update the trajectory identifiers such that a degree of similarity between trajectory identifiers is indicative of a degree of similarity between trajectories identified by the respective trajectory identifiers.

Claim 15. The trajectory identification server according to any one of claims 12 to 14, wherein the trajectory repository further identifies portions of trajectories, wherein a respective portion of a trajectory is identifiable by a sub-identifier of the trajectory identifier, a location, and/or an estimated time of arrival of a device.

Claim 16. An edge application server for a telecommunications network, wherein the edge application server is a mobile edge application server, wherein the edge application server is co-located with a mobile base station relay, for example by being provided in a same vehicle as the mobile base station relay.

Claim 17. A telecommunications network comprising at least one of: the edge enabler server according to any one of claims 1 to 5, the edge configuration server according to claim 10 or 11 , the trajectory identification server according to any one of claims 12 to 15, and the edge application server according to claim 16.

Claim 18. A computer-implemented method for execution at an edge enabler server of a telecommunications network, comprising: accessing a data storage comprising profiles of edge application servers, wherein at least a subset of the edge application servers are mobile edge application servers, wherein a profile of a mobile edge application server comprises a server trajectory identifier, wherein the server trajectory identifier is indicative of a trajectory of the mobile edge application server; receiving a discovery request to discover an edge application server for a user equipment, wherein the discovery request comprises an identifier of the user equipment; obtaining a client trajectory identifier of the user equipment, wherein the client trajectory identifier is indicative of a trajectory of the user equipment; identifying, based on the profiles of the edge application servers, one or more mobile edge application servers of which the server trajectory identifier at least partially matches the client trajectory identifier; and sending identifiers of the one or more mobile edge application servers as a response to the discovery request.

Claim 19. A computer-implemented method for execution at a user equipment of a telecommunications network, wherein the user equipment is configured to, during operation, execute an application client and an edge enabler client, comprising: sending a discovery request to an edge enabler server, wherein the discovery request comprises a client trajectory identifier, wherein the client trajectory identifier is indicative of a trajectory of the user equipment; receiving identifiers of one or more mobile edge application servers from the edge enabler server in response to the discovery request, wherein the one or more mobile edge application servers are each assigned a server trajectory identifier which at least partially matches the client trajectory identifier; and configuring the application client with a mobile edge application server selected from the one or more mobile edge application servers.

Claim 20. A computer-implemented method for execution at an edge configuration server of a telecommunications network, comprising: accessing a data storage comprising profiles of edge enabler servers, wherein at least a subset of the edge enabler servers are mobile edge enabler servers, wherein a profile of a mobile edge enabler server comprises a server trajectory identifier, wherein the server trajectory identifier is indicative of a trajectory of the mobile edge enabler server; receiving a provisioning request for provisioning an edge enabler server, wherein the provisioning request comprises an identifier of the user equipment; obtaining a client trajectory identifier of the user equipment, wherein the client trajectory identifier is indicative of a trajectory of the user equipment; identifying, based on the profiles of the edge enabler servers, one or more mobile edge enabler servers of which the server trajectory identifier at least partially matches the client trajectory identifier; and sending identifiers of the one or more mobile edge enabler servers as a response to the provisioning request.

Claim 21. A computer-implemented method for trajectory identification in a telecommunications network, comprising: accessing a trajectory repository comprising trajectory identifiers for trajectories, wherein an entry in the trajectory repository comprises trajectory information defining of a trajectory and a trajectory identifier assigned to the trajectory; receiving a trajectory identification request, wherein the trajectory identification request comprises location information indicative of a device trajectory of a device; searching the trajectory repository for a trajectory identifier for the device trajectory by comparing the location information to the trajectory information stored in respective entries of the trajectory repository; and sending the trajectory identifier as a response to the trajectory identification request.

Claim 22. A transitory or non-transitory computer-readable medium comprising data representing a computer program, the computer program comprising instructions for causing a processor system to perform the method according to any one of claims 18 to 21.