Technique for location context handling in a core network domain of a mobile communication network

Abstract

The present disclosure provides a method performed in a core network domain of a mobile communication network, wherein the mobile communication network further comprises a radio access network (RAN) domain. The method comprises obtaining a Fully Qualified Tunnel Endpoint Identifier (F-TEID) allocated to a RAN domain endpoint of a user plane tunnel. The method also comprises determining, based on at least a portion of the F-TEID, a location context for the F-TEID. The location context thus determined may be used to execute, or trigger execution of, at least one location-aware action.

Description

[0001] Technique for location context handling in a core network domain of a mobile communication network

[0002] Technical Field

[0003] The present disclosure generally relates to mobile communication. In more detail, aspects concerning location context handling in a core network domain of a wireless communication network are presented. The location context may, for example, be evaluated in relation to an area of interest of a location-aware action. The aspects presented herein may be implemented as methods, computer program products, apparatuses and systems.

[0004] Background

[0005] The core network (CN) and the radio access network (RAN) are the two fundamental domains of a mobile communication network. The RAN is the part of the mobile communication network that connects wireless user terminals to the CN. The CN is the part of the mobile communication network that provides the interface to data networks such as the Internet. Moreover, the CN is also in charge of other tasks such as mobility handling, charging, and so on.

[0006] The RAN is made up of three essential elements: antennas, radio units and signal processing functions. The antennas convert electrical signals to radio waves, and vice versa. The radio units transform digital signals to electrical signals that can be sent wirelessly over the antennas, and vice versa. The signal processing functions act on the digital signals and include encryption / decryption as well as encoding / decoding, to name a few.

[0007] The antennas, radio units and signal processing functions are typically integrated into base stations. A base stations conforming to 4thgeneration (4G) mobile communication standards is called evolved Node B (or simply eNodeB or eNB). A base station conforming to 5thGeneration (5G) mobile communication standards is denoted as Next Generation Node B (or simply gNodeB or gNB). Each base station, and the area served thereby, is identified by an identifier, such as the E-UTRAN Cell Global Identiy (ECGI) in 4G networks or the New Radio Cell Global Identity (NCGI) in 5G networks. The location of a wireless user terminal can thus be indicated by the identifier of the base station to which the user terminal is attached, such as the ECGI or the NCGI. In other words, the base station identifier can be exploited to provide a location context for the user terminal. The location context, in turn, can be used for location-aware actions involving the user terminal or its data traffic.

[0008] Location-aware actions are often performed in the CN domain. For example, location- aware filters may be applied by the CN to limit the amount of information that is provided by CN-based reporting functions. Consequently, reporting may be limited to mobile user terminals within a predefined area of interest (e.g., that is served by one or more base stations identified by a set of one or more ECGIs or NCGIs). Other location aware-actions include traffic shaping by the CN with respect to an area of interest (e.g., to mitigate congestion of individual base stations).

[0009] The location-aware actions are typically performed on a user plane, for example by a User Plane Function (UPF) of a 5G-compliant CN domain. However, there presently do not exist standardized solutions for providing the UPF a the location context (e.g., as needed for evaluating whether data traffic from a particular user terminal is to be effected by a particular location-aware action).

[0010] It has been found that according to existing 5G standards of the 3rdGeneration Partnership Project (3GPP), certain CN functions such as the Access and Mobility Management Function (AMF) already receive a location context from the RAN domain, but this location context is not forwarded to the UPF (e.g., by the Session Management Function, SMF, to which the AMF reports the location context received from the RAN and that is connected via an N4 interface to the UPF). In other words, the UPF cannot be a consumer of the location information services in Service Based Architecture (SBA) standardized by 3GPP for the 5G CN domain.

[0011] There exist proprietary solutions, for example developed by Ericsson, that enable the SMF to forward location contexts to the UPF via the N4 network. However, such solutions also have drawbacks. To start with, any proprietary solution will transmit the location context to the UPF in a proprietary format, which is not an acceptable solution in multi-vendor environments.

[0012] Moreover, in certain proprietary implementations the AMFs do not update SMFs each time there is change on the side of the RAN, but just when the change affects Packet Data Unit (PDU) session management (e.g., when there is a change of a user plane tunnel termination point on the side of the RAN). While SMFs could request more frequent updates from AMFs (e.g., on a periodic basis), the signaling overhead would increase significantly between the AMFs and the SMFs, and as a result also between the SMFs and the UPFs. Additionally, such updates will even be undesired in certain situations (e.g., when a user terminal travelling along the border of two cells makes continuous handovers between the base stations associated with those cells).

[0013] Summary

[0014] There is a need for a technique that avoids one more of the above or other drawbacks, and that enables to efficient location context handling in a CN domain of a mobile communication network

[0015] A first aspect relates to a method performed in a Core Network (CN) domain of a mobile communication network, wherein the mobile communication network further comprises a Radio Access Network (RAN) domain. The method comprises obtaining a Fully Qualified Tunnel Endpoint Identifier (F-TEID) allocated to a RAN domain endpoint of a user plane tunnel and determining, based on at least a portion of the F-TEID, a location context for the F-TEID.

[0016] The user plane tunnel may extend from the RAN domain endpoint to an endpoint terminating the user plane tunnel in the CN domain. The method of the first aspect may be performed by a user plane entity that terminates the user plane tunnel in the CN domain. The user plane entity may constitute the CN domain endpoint of the user plane tunnel. The user plane entity may terminate multiple user plane tunnels. In such a case, the steps of obtaining the F-TEID and determining the associated location context may be performed for multiple or all of the user plane tunnels terminated by the user plane entity.

[0017] The location context may be determined from mapping information indicative of one or more associations between one or more F-TEIDs, or one or more portions thereof, and one or more location contexts. The mapping information may be formatted as a data structure, such as a look-up table or a mapping function. The mapping information may map the F-TEIDs (or portions thereof such as Internet Protocol addresses or TEIDs comprised thereby) to location contexts. In some variants, the F- TEID portions have been obtained by extraction from F-TEIDs (e.g., the IP address part may be extracted from an F-TEID by discarding the TEID part, and vice versa). The method may further comprise receiving the mapping information or at least a portion thereof. At least a portion of the mapping information may be received from a Session Management Function (SMF). As an example, an entity performing the method of the first aspect, such as the user plane entity, may send an event subscription to the SMF. This event subscription may trigger updates on mapping- information-related events by the SMF towards the entity that sent the event subscription. Each update may include at least an updated portion of the mapping information (e.g., at least one new or updated F-TEID / location context association). The event subscription towards the SMF may relate to events pertaining to at least one entity indicated in the event subscription. The at least one entity may be at least one of an F-TEID, a location context and a user terminal identifier. The user terminal identifier may, for example, take the form of a Subscriber Permanent Identifier (SUPI)

[0018] The method of the first aspect may comprise sending a mapping information discovery request. The mapping information, or at least a portion thereof, may be received in response to the mapping information discovery request. In some variants, the mapping information discovery request (e.g., an Nnwdaf_AnalyticsSubscription_Subscribe message) is sent to, and the mapping information or the portion thereof is received from (e.g., in a Nnwdaf_AnalyticsSubscription_Notify message), a Network Data Analytics Function (NWDAF).

[0019] In a first implementation, the mapping information discovery request indicates a first F-TEID. In this implementation, the received mapping information includes at least one of:

[0020] - a first location context associated with the first T-FEID;

[0021] - an association between one or more second F-TEIDs and the first location context; and

[0022] - an association between one or more third F-TEIDs and at least one second location context.

[0023] In a second implementation, the mapping information discovery request indicates a first location context. In this implementation, the received mapping information includes at least one of:

[0024] - one or more first F-TEIDs associated with the first location context; and an association between one or more second F-TEIDs and at least one second location context.

[0025] In a third implementation, the mapping information discovery request indicates a user terminal identifier associated with a first location context. In this implementation, the received mapping information includes at least one of:

[0026] - an association between one or more first F-TEIDs and the first location context; and

[0027] - an association between one or more second F-TEIDs and at least one second location context.

[0028] At least two of the first, second and third implementations may be combined in that the mapping information discovery request includes two or more of an F-TEID, a location context and a user terminal identifier.

[0029] In some variants, the mapping information discovery request is an event subscription that triggers updates on mapping information-related events. The event subscription may relate to events pertaining to at least one entity indicated in the mapping information discovery request, wherein the entity is one of the first F-TEID, the first location context and the user terminal identifier. The event subscription may pertain to the NWDAF. As an example, the mapping information discovery request may take the form of an Nnwdaf_AnalyticsSubscription_Subscribe message and the mapping information, or the portion thereof, may be received in a Nnwdaf_AnalyticsSubscription_Notify message.

[0030] The method of the first aspect may comprise receiving a data collection request by a, or the, user plane entity. The method may further comprise returning, in response to the data collection request, one or more fourth F-TEIDs associated with one or more user plane tunnels terminated by the user plane entity. In such a scenario, the method of the first aspect may further comprise determining one or more third location contexts associated with the one or more fourth F-TEIDs, wherein the one or more fourth F-TEIDs are returned in association with the corresponding one or more third location contexts that could be determined. The mapping information may then include the one or more fourth T-FEIDs and, optionally, the corresponding one or more third location contexts that could be determined. In some implementations, the data collection request may be an Nupf_EventExposure_Request message. The method of the first aspect may further comprise executing, or triggering execution of, at least one location-aware action in the CN domain based on the determined location context (e.g., in response to receiving a command indicative of the location-aware action). The method may comprise evaluating if the determined location context falls within an area of interest of a location-aware action. The location-aware action may comprise at least one of:

[0031] - location-aware traffic shaping;

[0032] - location-aware event reporting;

[0033] - location-aware data collection;

[0034] - location-aware data or traffic filtering; and

[0035] - location-aware handling of Packet Data Unit, PDU, sessions.

[0036] In some variants, the method of the first aspect may be triggered by the SMF, for example by sending to the UPF a Packet Detection Rule (PDR) (e.g., for a particular location-aware (e.g., traffic shaping) action). In particular, the PDR may trigger that the location-aware action shall be activated for one or more PDU sessions handled by the UPF.

[0037] The location context may comprise one or more of:

[0038] - User Location Information, ULI;

[0039] - one or more a cell or base station identifiers, in particular one or more Cell Global Identifiers, CGIs, such as ECGIs and / or NCGIs; and

[0040] - one or more area identifiers.

[0041] Each F-TEID may include an Internet Protocol (IP) address. The location context for a given F-TEID may be determined based on the IP address included in the given F- TEID, for example from a look-up table or any other data structure associating IP addresses with location contexts. In such an implementation, the method of the first aspect may comprise a step of determining the IP address included in a given F-TEID and a subsequent step of consulting the look-up table or other data structure for the location context associated with the IP address (and similarly for TEIDs)

[0042] In a first variant, the F-TEID is obtained from a header of a GPRS Tunneling Protocol, GTP, packet data unit (G-PDU). In a second variant, the F-TEID is obtained from an extension header of a G-PDU. The concepts of GTP and G-PDUs are described, inter alia, in 3GPP TS 29.281 V18.0.0 (2023 / 06). The G-PDUs may be received by the component executing the method of the first aspect in the context of one or more PDU sessions stretching through one or more user plane tunnels. The method of the first aspect may be performed by a User Plane Function (UPF). The UPF may be configured to be operated in a 5G mobile communication network as standardized by 3GPP.

[0043] A second aspect relates to a method performed in a CN domain of a mobile communication network, wherein the mobile communication network further comprises a RAN domain. The method comprises receiving a mapping information discovery request and generating mapping information indicative of one or more associations between one or more Fully Qualified Tunnel Endpoint Identifiers, F- TEIDs, or one or more portions thereof, and one or more location contexts, wherein the F-TEIDs are allocated to RAN domain endpoints of user plane tunnels. The method of the second aspect further comprises sending the mapping information, or a portion thereof, in response to the mapping information discovery request.

[0044] The method of the second aspect may comprise obtaining the one or more F-TEID portions by extraction from one or more F-TEIDs. For example, the IP address part may be extracted from an F-TEID by discarding the TEID part, and vice versa. The mapping information may then only associate the extracted IP address with a particular location context. In other variants, the mapping information may only associate the extracted TEID with a particular location context.

[0045] The mapping information generated according to the method of the first aspect may map the F-TEIDs (or portions thereof such as IP addresses or TEIDs comprised thereby) to location contexts. The mapping information may be generated before or after receipt of the mapping information discovery request. As explained above, the mapping information discovery request may be an Nnwdaf_AnalyticsSubscription_Subscribe message (e.g., with "Analytic-ID= F-TEID Discovery from NodeB ID", wherein the NodeB ID is representative of "location context"). As such, the mapping information, or the portion thereof, may be returned in an Nnwdaf_AnalyticsSubscription_Notify message.

[0046] The mapping information discovery request may be indicative of at least one of a first F-TEID and a user terminal identifier (e.g., SUPI) associated with the first F- TEID. In such a case, the method of the second aspect may comprise sending a location context request (e.g., an Namf_Location_ProvideLocationInfo_Request message) indicative of at least one of the first F-TEID and the associated user terminal identifier. The method may further comprise receiving, in response to the location context request and for example in an Namf_Location_ProvideLocationInfo_Notify message, a first location context associated with the first F-TEID. The mapping information may be generated to be indicative of the association between the first F-TEID and the first location context.

[0047] The method of the second aspect may comprise sending a data collection request (e.g., an Nupf_EventExposure_Request message) to a user plane entity terminating one or more user plane tunnels in the CN domain and receiving, in response to the data collection request (and for example in an Nupf_EventExposure_Notify message), at least one of

[0048] - one or more second F-TEIDs allocated to one or more RAN domain endpoints of the one or more user plane tunnels; and

[0049] - one or more user terminal identifiers associated with the one or more second F-TEIDs.

[0050] In some variants, each F-TEID includes an IP address uniquely associated with a location context. The method of the second aspect may then comprise determining, based on identical IP addresses, one or more second location contexts associated with the one or more second F-TEIDs to equal the known location context of another F-TEID. In this case, the mapping information may be generated to be indicative of one or more associations between the one or more second F-TEIDs and the one or more second location contexts.

[0051] In some variants, the method of the second aspect may include sending a location context request (e.g., an Namf_Location_ProvideLocationInfo_Request message) indicative of at least one of:

[0052] - at least one of the one or more second F-TEIDs; and

[0053] - at least one of the one or more user terminal identifiers associated with the one or more second F-TEIDs.

[0054] In such variants, the method of the second aspect may further include receiving, in response to the location context request (and, for example, in an Namf_Location_ProvideLocationInfo_Notify message), the at least one second location context associated with the at least one second F-TEID. In such a case, the mapping information may be generated to be indicative of the association between the at least one second F-TEID and the at least one second location context. In some of the above variants, the location context request is sent to an Access and Mobility Management Function (AMF).

[0055] In a first implementation, the mapping information discovery request indicates a third F-TEID. In this implementation, the mapping information may include at least one of:

[0056] - a third location context associated with the third T-FEID;

[0057] - an association between one or more fourth F-TEIDs and the third location context; and

[0058] - an association between one or more fifth F-TEIDs and at least one fourth location context.

[0059] In a second implementation, the mapping information discovery request indicates a third location context. In this implementation, the mapping information may include at least one of:

[0060] - one or more third F-TEIDs associated with the third location context; and

[0061] - an association between one or more fourth F-TEIDs and at least one fourth location context.

[0062] In a third implementation, the mapping information discovery request indicates a user terminal identifier (e.g., a SUPI) associated with a third location context. In this implementation, the mapping information may include at least one of:

[0063] - an association between one or more third F-TEIDs and the third location context; and

[0064] - an association between one or more fourth F-TEIDs and at least one fourth location context.

[0065] Two or all of the first to third implementations may be combined, as generally explained above in the context of the method of the first aspect.

[0066] As also explained above, the mapping information discovery request may be an event subscription that triggers updates on mapping information-related events. The event subscription may relate to events pertaining to an entity indicated in the mapping information discovery request, wherein the entity is one of the third F-TEID, the third location context and the user terminal identifier. As such, the method of the second aspect may comprise detecting an event that requires an update of the mapping information, determining, in response to the detected event, updated mapping information, and sending, in response to the event subscription, the updated mapping information.

[0067] The method of the second aspect may comprise determining, using machine learning, an assignment model indicative of how F-TEIDs are allocated in the RAN domain per location context. The method may further comprise determining, for a given F-TEID, the associated location context from the assignment model. The mapping information may then be generated from the associated location context thus determined.

[0068] The method of the second aspect may comprise obtaining a location context, consulting the mapping information to determine an F-TEID associated with the obtained location context, and triggering an action based on the determined F-TEID. As such, the mapping information may also be used locally by the entity that generated the mapping information (instead of or in addition to sending the mapping information responsive to the mapping information discovery request to another entity).

[0069] The method of the second aspect may be performed by an NWDAF.

[0070] A third aspect relates to a computer program product comprising program code portions configured to perform the method of any of the preceding claims when the computer program product is executed on one more processors. The computer program product may be stored on a computer-readable recording medium (e.g., in one or more of a semiconductor memory, a hard disk or a cloud-based storage).

[0071] Also provided is a first apparatus configured to be operated in a CN domain of a mobile communication network, wherein the mobile communication network further comprises a RAN domain. The apparatus is configured to obtain an F-TEID allocated to a RAN domain endpoint of a user plane tunnel, and to determine, based on at least a portion of the F-TEID, a location context for the F-TEID.

[0072] The first apparatus may be configured to perform the method of the first aspect discussed herein.

[0073] Further provided is a second apparatus configured to be operated in a CN domain of a mobile communication network, wherein the mobile communication network further comprises a RAN domain. The apparatus is configured to receive a mapping information discovery request, to generate mapping information indicative of one or more associations between one or more F-TEIDs, or one or more portions thereof, and one or more location contexts, wherein the F-TEIDs are allocated to RAN domain endpoints of user plane tunnels, and to send the mapping information, or a portion thereof, in response to the mapping information discovery request.

[0074] The second apparatus may be configured to perform the method of the second aspect discussed herein.

[0075] Also provided is a network system comprising the first apparatus (e.g., configured as a UPF) and the second apparatus (e.g., configured as an NWDAF). The network system may be configured to be deployed in a CN domain of a mobile communication system.

[0076] Brief Description of the Drawings

[0077] Further aspects, details and advantages of the present disclosure will become apparent from the detailed description of exemplary embodiments below and from the drawings, wherein:

[0078] Fig. 1 is a diagram illustrating a system realization of the present disclosure;

[0079] Fig. 2 is a block diagram illustrating an apparatus realization of the present disclosure;

[0080] Figs. 3A and B are flow diagrams illustrating method realizations of the present disclosure;

[0081] Fig. 3C is a mapping table illustrating an exemplary realization of mapping information;

[0082] Fig. 4 is a diagram illustrating an exemplary 5G network architecture that can form the basis of realizations of the present disclosure;

[0083] Fig. 5 is a diagram illustrating an exemplary 5G RAN split architecture; Fig. 6 is a diagram illustrating a user plane protocol stack for multiple serially arranged UPFs; and

[0084] Figs. 7A to C are schematic signalling diagrams illustrating further realizations of the present disclosure based on the 5G network architecture of Fig. 4.

[0085] Detailed Description

[0086] In the following description, for purposes of explanation and not limitation, specific details are set forth in order to provide a thorough understanding of the present disclosure. It will be apparent to one skilled in the art that the present disclosure may be practiced in other embodiments that depart from these specific details.

[0087] While, for example, the following description focuses on an exemplary core network configuration in accordance with 4G and 5G specifications, the present disclosure is not limited in this regard. The present disclosure could, for example, also be implemented in other cellular or non-cellular mobile communication networks having a core network (CN) domain and a radio access network (RAN) domain, such as those complying with "beyond-5G" specifications.

[0088] Those skilled in the art will further appreciate that the steps, services and functions explained herein may be implemented using individual hardware circuits, using software functioning in conjunction with a programmed processor or general purpose computer, using one or more application specific integrated circuits (ASICs) and / or using one or more digital signal processors (DSP). It will also be appreciated that when the present disclosure is described in terms of a method, it may also be embodied in one or more processors and one or more memories coupled to the one or more processors, wherein the one or more memories store one or more computer programs that control the one or more processors to perform the steps, services and functions disclosed herein when executed by the one or more processors.

[0089] In the following description of exemplary realizations of the present disclosure, the same reference numerals denote the same or similar components.

[0090] Fig. 1 illustrates an embodiment of a mobile communication network 100 in which the present disclosure can be implemented. The mobile communication network 100 may be configured as a cellular communication network operated by a mobile network operator (MNO).

[0091] As shown in Fig. 1, the mobile communication network 100 comprises a content provider domain 102 (e.g., the Internet) configured to provide digital content to a user domain 104. The network 100 further comprises a CN domain 106 and a RAN domain 108 functionally arranged between the content provider domain 102 and the user domain 104. As understood herein, a particular domain comprises one or more devices, nodes or functions under control of a particular domain owner, such as a user, an MNO or a content provider.

[0092] The CN domain 106 and the RAN domain 108 each comprises one or more network nodes or network functions (NFs). For example, the RAN domain 108 comprises one or more centralized or distributed base stations (not shown) configured to establish one or more wireless communication links to one or more wireless user terminals 110 in the user domain 104. Exemplary user terminals 110 comprise user equipment- (UE-) type devices (e.g., smartphones, tablets or television sets) or Internet of Things- (IoT-) type devices (e.g., cars or wearable devices such as head-, hand- or body-mounted devices) with wireless communication capabilities towards the RAN domain 108.

[0093] In some variants, at least the CN domain 106 and the RAN domain 108 are split into a user plane for transporting data traffic (e.g., digital content) and a control plane for transporting control signalling. Between the CN domain 106 and the RAN domain 108, the data traffic is transported via one or more user plane tunnels 120 configured to multiplex and / or encapsulate the data traffic into dedicated communication entities (e.g., traffic flows).

[0094] Each user plane tunnel 120 stretches between a first endpoint in the RAN domain 108 and a second endpoint in the CN domain 106. In some variants, the user plane tunnels 120 may be realized in accordance with the GPRS (General Packet Radio Service) Tunneling Protocol for the User Plane (GTP-U). GPT-U can be implemented in the mobile communication network 100 in accordance with any of 2G, 3G, 4G, 5G and "beyond-5G" mobile communication standards, as well as combinations thereof. Some aspects of GTP are described in 3GPP TS 29.281 V18.0.0 (2023 / 06), which is herewith incorporated by reference. A dedicated user plane tunnel 120 is identified at each endpoint terminating the tunnel 120 by an associated Tunnel Endpoint Identifier (TEID), such as a Fully Qualified TEID (F-TEID). The F-TEID of the RAN domain endpoint includes the Internet Protocol (IP) address of a RAN entity that terminates the user plane tunnel 120 in the RAN domain 108 and a TEID. In an exemplary 3GPP-compliant 5G implementation, the user plane tunnel 120 may be terminated by a Packet Processing Function (PPF) in the RAN domain 108, so that the associated F-TEID will include the IP address of that RAN domain entity. The PPF interacts with a User Plane Function (UPF) in the CN domain 106, so that the corresponding user plane tunnel 120 stretches from the PPF in the RAN domain 108 to the UPF in the CN domain 106. The user plane tunnel 120 can thus be identified by a first F-TEID allocated to its RAN-sided endpoint and a second F-TEID allocated to its UPF-sided endpoint.

[0095] Location-aware actions and other procedures in the CN domain 106 would benefit from knowledge of a location context associated with the RAN entity that terminates the user plane tunnel 120 in the RAN domain 108. This location context may, for example, be attributed to one or both of a user terminal 110 or a Packet Data Unit (PDU) session for which data traffic is routed through this user plane tunnel 120. However, IP addresses and F-TEIDs are location agnostic and, therefore, cannot provide the required location context. It has, on the other hand, been found that the PPF (or other RAN domain entity) terminating the user plane tunnel 120 in the RAN domain 108 is associated with one or more of User Location Information (ULI), a cell or base station identifier (e.g., NCGI or ECGI), an area identifier (e.g., a Tracking Area Identity, TAI), etc. capable of indicating a location context. As such, a relationship can be established that associates a dedicated F-TEID (or a portion thereof, such as the TEID or IP address included therein) on the one hand and a dedicated location context on the other hand. Whether or not an F-TEID portion is sufficient for looking up the associated location context may depend on network deployment. For example, some MNOs may decide to assign IP addresses for the RAN domain in a static way, others may use dynamic assignments.

[0096] Consequently, a dedicated F-TEID will have been allocated to a RAN domain endpoint of a user plane tunnel 120. At the same time, that RAN domain endpoint my be rooted in a RAN domain entity that may represent or belong to a base station having a dedicated NCGI or ECGI. As such, the dedicated F-TEID (or a portion thereof) can be associated with (e.g., mapped to) the dedicated NCGI or ECGI (as an exemplary location context associated with a serving area of a base station). In this way, mapping information can be defined that is indicative of one or more associations between one or more F-TEIDs (or portions thereof) and one or more location contexts. Based on the particular F-TEID allocated to a RAN domain endpoint of a user plane tunnel 120, the mapping information allows to determine the location context associated with that F-TEID. The location context thus determined can, in turn, be used for executing, or triggering execution of, a location- aware action. In some variants, the location context may be evaluated to determine if it falls within an area of interest of the location-aware action.

[0097] The CN domain 106 illustrated in Fig. 1 comprises, among others, an apparatus 130 configured to generate mapping information indicative of one or more associations between one or more F-TEIDs (or one or more portions thereof) and one or more location contexts. Moreover, the CN domain 106 further comprises an apparatus 140 configured for location context evaluation, for example based on the mapping information generated by the apparatus 130 and / or corresponding information determined otherwise (e.g., generated locally by the apparatus 140). The location context determination apparatus 140 may in some variants terminate the user plane tunnel 120.

[0098] The two apparatuses 130, 140 may each be realized by one or more network nodes or NFs in the CN domain 106, or they may be implemented as a single network node or NF. In an exemplary 3GPP-compliant 5G implementation, the mapping information generation apparatus 130 may be realized as a Network Data Analytics Function (NWDAF) and the location context determination apparatus 140 may be realized as a UPF. In an exemplary 3GPP-compliant 4G implementation, the location context determination apparatus 140 may be a Packet Gateway on the user plane (PGW-U) and the mapping information generation apparatus 130 can be realized by one or more other CN entities. Also mixed 4G / 5G solutions can be implemented.

[0099] In the following, exemplary realizations of each of the mapping information generation apparatus 130 and the location context determination apparatus 140 will be explained with reference to the block diagram of Fig. 2. As illustrated in Fig. 2, in one exemplary hardware implementation each apparatus 130, 140 comprises a processor 202 and a memory 204 coupled to the processor 202. The memory 204 stores program code (e.g., a computer program product) that controls operation of the processor 202 to implement one or more aspects of the present disclosure. As understood herein, the processor 202 may be realized using any processing circuitry and is not limited to, for example, a single, localized processing core but may, for example, also have a distributed (e.g., cloud-based) topology.

[0100] Each apparatus 130, 140 further comprises an optional input interface 206 and an optional output interface 208 for direct or indirect communication with the other apparatus 140, 130 and / or for communication with other entities in the mobile communication network 100 of Fig. 1.

[0101] Exemplary modes of operation of the of the mapping information generation apparatus 130 and the location context determination apparatus 140 of Figs. 1 and 2 will now be described with reference to the flow diagrams illustrated in Figs. 3A and 3B.

[0102] With reference to the flow diagram of Fig. 3A, operation of the mapping information generation apparatus 130 includes a step 310 of receiving a mapping information discovery request. In some implementations, the mapping information discovery request is received from, or at least triggered by, the location context determination apparatus 140. In other implementations, the mapping information discovery request is received from, or triggered by, a network node or NF in the CN domain 106 different from the location context determination apparatus 140.

[0103] In a further step 320, which can be performed before or after step 310 and in particular responsive to receipt of the mapping information discovery request in step 310, the mapping information generation apparatus 130 generates mapping information. As explained above, the mapping information is indicative of one or more associations between one or more F-TEIDs (or one or more portions thereof) and one or more location contexts, wherein the F-TEIDs are allocated to RAN domain endpoints of user plane tunnels 120. The mapping information can be structured in the form of a mapping table, see the example of Fig. 3C.

[0104] As illustrated in Fig. 3C, the mapping information associates each of multiple F-TEIDs with one or more location identifiers "Location IDs" (e.g., ECGIs or NCGIs) as exemplary location contexts. While the mapping information associates LocationlDl with a single F-TEID (i.e., F-TEID1), LocationID2 is associated with two F-TEIDs (i.e., F-TEID2 and F-TEID4). As such, multiple F-TEIDs may be associated with the same LocationlD, but a particular F-TEID is uniquely associated with a particular LocationlD. Different F-TEIDs (e.g., F-TEID2 and F-TEID4) may share the same IP address as one of their constituents and, as such, may be mapped to the same LocationlD. Each F-TEID may comprise a TEID as further constituent. In some variants, generating the mapping information comprises extracting the IP addresses or TEIDs from the F-TEIDs. For example, the IP addresses may be extracted from the F-TEIDs by discarding the TEIDs, and vice versa. The mapping information may then only associate the extracted IP addresses with respective location contexts. In other variants, the mapping information may only associate the extracted TEIDs with respective location contexts. The left-hand column in Fig. 3C would in such implementations only include the IP addresses or the TEIDs of F- TEID1 to F-TEID4.

[0105] The mapping information discovery request received in step 310 may indicate one or more of an F-TEID, a location context (e.g., a LocationlD as indicated in Fig. 3C) and a user terminal identifier (e.g., associated with a, or the, F-TEID and / or a, or the, location context) such as a Subscriber Permanent Identifier (SUPI). In such a scenario, the mapping information generated in step 320 may include an association involving a first entity (e.g., F-TEID or location context) indicated in the mapping information request and a corresponding second entity (if the first entity is the F- TEID, the second entity will be the associated location context, and vice versa).

[0106] The step 320 of generating the mapping information may involve gathering the required items of information from other entities in the CN domain 106, such as from one or more Access and Mobility Management Functions (AMFs) and one or more UPFs. For example, step 320 may include sending (e.g., to one or more AMFs) a location context request indicative of at least one of an F-TEID and a user terminal identifier associated with the F-TEID. The F-TEID may have been received in step 310 with the mapping information discovery request or may have been obtained otherwise. For example, the F-TEID may have been received in step 310 from the location context determination apparatus 140 that constitutes one endpoint of the user plane tunnel 120, wherein the F-TEID is allocated to the other endpoint of that user plane tunnel 120 in the RAN domain 108. The associated user terminal identifier may belong to a user terminal 110 for which data traffic (e.g., in the context of a particular PDU session) is transported via that user plane tunnel 120. In response to the location context request, the mapping information generation apparatus 130 may receive a location context (e.g., a LocationlD, see Fig. 3C) associated with the F- TEID. The mapping information may then be generated in step 320 to be indicative of the association between the F-TEID and the location context received in response to the location context request as illustrated in Fig. 3C. As another example, step 320 may include sending (e.g., multicasting or broadcasting) a data collection request to one or more user plane entities (e.g., UPFs) terminating one or more user plane tunnels 120 in the CN domain 106. In response to the data collection request, the mapping information generation apparatus 130 may receive one or more F-TEIDs allocated to RAN domain endpoints of the one or more user plane tunnels 120. Alternatively, or in addition, the apparatus 130 may receive one or more user terminal identifiers associated with those one or more F-TEIDs.

[0107] Based on the F-TEID(s) and / or the user terminal identifier(s) received in response to the data collection request, the apparatus 130 may send a location context request to infer the associated location context(s). The mapping information may then be generated in step 320 based on the location context(s) received in response to the location context request. Alternatively, or in addition, the location context(s) may be inferred by the apparatus 130 based on the knowledge that different F-TEIDs which include the same IP address are associated with the same RAN domain endpoint (since an IP address may uniquely be associated with a certain location context). So if the location context is known for one of these different F-TEIDs, the same location context can be attributed to one or more other F-TEIDs that include the same IP address. The mapping information may then be generated in step 320 based on the location context shared by different F-TEIDs that include the same IP address (see, e.g., F-TEID2 and F-TEID4 in Fig. 3C).

[0108] The step 320 of generating the mapping information may also make use of machine learning. For example, the apparatus 130 may determine, using machine learning, an assignment model indicative of how F-TEIDs are allocated in the RAN domain 108 per location context (e.g., per RAN domain entity such as per PPF). The apparatus 130 may then determine, for a given F-TEID, the associated location context from the assignment model.

[0109] The mapping information generated by the apparatus 130, or at least a portion thereof, is then sent in step 330 responsive to the mapping information discovery request received in step 310. If, for example, the mapping information discovery request has been received from the location context determination apparatus 140, the mapping information, or at least a portion thereof, will then be returned to the location context determination apparatus 140. The mapping information discovery request received in step 310 can in some variants be an event subscription that triggers updates on mapping information-related events. The event subscription can relate to all events or to events pertaining to one or more entities (e.g., F-TEID and / or location context and / or user terminal identifier) indicated in the mapping information discovery request. The apparatus 130 may then detect for a particular entity an event that requires an update of the mapping information (e.g., in a handover scenario). The apparatus 130 may further determine, in response to the detected event, updated mapping information and send, in step 330 and response to the event subscription, the updated mapping information. Step 330 may be repeated upon detecting a further event, or on a regular (e.g., periodic) basis.

[0110] The location context determination apparatus 140 may be operated in cooperation with the mapping information generation apparatus 130 or independently thereof. With reference to the flow diagram of Fig. 3B, operation of the location context determination apparatus 140 includes a step 340 of obtaining an F-TEID allocated to a RAN domain endpoint of a user plane tunnel 120. The apparatus 140 may terminate this user plane tunnel 120 in the CN domain 106, and the F-TEID obtained in step 340 may be allocated to the opposite endpoint of the user plane tunnel 120 in the RAN domain 108. Step 340 may be performed for each of multiple (e.g., for all) user plane tunnels 120 handled (e.g., terminated) by the location context determination apparatus 140.

[0111] Operation of the location context determination apparatus 140 further includes a step 350 of determining, based on at least a portion of the F-TEID (e.g., an IP address included therein), a location context for the F-TEID obtained in step 340. In some variants, the location context is determined from the mapping information generated by and received from the mapping information generation apparatus 130 (e.g., as explained in the context of Fig. 3A above), wherein the mapping information is indicative of one or more associations between one or more F-TEIDs (or one or more portions thereof) and one or more location contexts (see Fig. 3C). In other variants, the location context determination apparatus 140 may determine the location context locally (i.e., without resorting to mapping information received from the mapping information apparatus 130). As an example, the location context determination apparatus 140 may have generated the mapping information locally (e.g., in the same way as explained above with reference to step 320 of Fig. 3A for the mapping information generation apparatus 130). In more detail, the apparatus 140 may determine the location context in step 350 to equal the known location context of other F-TEIDs known to the apparatus 140 and that include the same IP address as the F-TEID obtained in step 340 (see again F-TEID2 and F-TEID4 in Fig. 3C). In such or other implementations, at least a portion of the mapping information may also be received (e.g., based on an event subscription) from a Session Management Function (SMF).

[0112] Of course, the location context determination apparatus 140 may also itself function as a source of mapping information for the mapping information generation apparatus 130. For example, the location context determination apparatus 140 may receive a data collection request from the mapping information generation apparatus 130 and return one or more requested items of information. As an example, the apparatus 140 may return for one or more (or all) user plane tunnels 120 terminated by the apparatus 140 the F-TEIDs associated with the corresponding RAN domain endpoints. If the apparatus 140 is additionally aware of location contexts associated with these F-TEIDs, such location contexts may be returned as well (e.g., in the form of a mapping table similar to the one illustrated in Fig. 3C).

[0113] If step 340 is performed for each of multiple (e.g., for all) user plane tunnels 120 handled (e.g., terminated) by the location context determination apparatus 140, step 350 may individually be performed for each multiple F-TEIDs thus obtained.

[0114] Once one or more location contexts have been determined in step 350, the location context determination apparatus 140 may execute, or trigger execution of, one or more optional steps that depend on those one or more location contexts. As an example, the location context determination apparatus 140 may in an optional step 360 execute, or trigger execution of, at lease one location-aware action based on the one or more location contexts. Additionally, or as an alternative, the location context determination apparatus 140 may determine if the one or more location contexts fall within an area of interest of a location-aware action. In some variants, step 340 is triggered by the location context determination apparatus 140 being commanded to perform a location-aware action, such as a location-aware data collection procedure. The location-aware data collection procedure may be limited to one or more areas that are prone to congestion to waste no processing, storage and communication resources for areas not affected by congestion. The corresponding command may be received by the location context determination apparatus 140 from another CN domain entity. In some cases, the command may be indicative of, for example, a set of NCGIs and / or a set of ECGIs of base stations that handle user traffic for which data is to be collected. The set of NCGIs and / or ECGIs may thus individually and collectively define a (geographic) area of interest, but the area of interest could of course also be defined by a set or one or more tracking area identities or any other ULI.

[0115] In response to the command to perform a location-aware data collection procedure, the location context determination apparatus 140 may in some variants determine data traffic (e.g., in terms of PDU sessions) that is both handled by the apparatus 140 and geographically effected by the data collection command. To this end, the apparatus 140 determines, for each user plane tunnel 120 terminated by the apparatus 140, the F-TEID of the associated RAN domain endpoint (step 340). The apparatus 140 then determines the associated location context (step 350), such as the associated NCGI or ECGI (e.g., using a mapping table as illustrated in Fig. 3C). Then, the apparatus 140 may evaluate if the NCGI or ECGI determined in step 350 falls within the set of NCGIs or a set of ECGIs indicated in the command to perform the location-aware data collection procedure. If this is the case, the data traffic routed through the corresponding user plane tunnel 120 is subjected to data collection. Otherwise, the corresponding data traffic is not considered for data collection purposes. The collected data may, for example, be an aggregated amount of data traffic, a data traffic throughput metric, etc.

[0116] In certain variants, the UPF 140 may perform step 320 itself and autonomously from the NWDAF 130 (e.g., in case the UPF 140 obtains the mapping information or portions of the mapping information via proprietary mechanisms from, e.g., the SMF 410 or other CN entities). Moreover, in some cases the UPF 140 may use the mapping information for purposes different from a location-aware action. In such cases, step 360 may be omitted or replaced. Generation of the mapping information in step 320 could also be performed independently from reception of a mapping information discovery request.

[0117] The above modes of operation generally described with reference to Figs. 3A to 3C will now be described in greater detail with reference to certain technical specifications (TSs) defined by 3GPP for 5G communication systems. 3GPP TS 23.501 V15.4.0 (2018-12) and later defines architectural aspects of a 5G service based architecture (SBA) in which the present disclosure can be implemented. According to this SBA, NFs use service-based interactions to consume services from other NFs. The discovery of services and of NFs producing them is provided by a network repository function (NRF). Service producing NFs register, update or deregister their profiles in the NRF. Service consuming NFs discover services offered by NF producer instances by querying the NRF about NF instances offering services of a given type. NFs may subscribe and unsubscribe to events pertaining to changes in the status of NFs registered in the NRF. Based on such subscriptions, the NRF may notify NFs of status changes of other NFs.

[0118] Fig. 4 depicts a portion of the 5G SBA as defined by 3GPP (see, e.g., Section 4.2.3 of 3GPP TS 23.501 V15.4.0 and later). The architectural CN entities (i.e., NFs), CN interfaces and other network entities relevant for some realizations of the present disclosure include the following:

[0119] - A user equipment (UE) is an exemplary realization of a user terminal 110 (see Fig. 1).

[0120] - An SMF 410 has N4 and Nsmf interfaces to other entities. The SMF 420 supports procedures such as PDU session establishment, modification and release as well as policy-related functionalities. The SMF 410 is configured to receive Policy and Charging Control (PCC) rules from a Policy Control Function (PCF) 420. Moreover, the SMF 410 configures UPFs 140 (as exemplary realizations of location context determination apparatuses) accordingly through the N4 interface using the Packet Forwarding Control Protocol (PFCP). The SMF 410 can also act as a source of mapping information, or portions thereof, for other CN domain entities such as the UPF 140.

[0121] - As said, the UPF 140 is an exemplary location context determination apparatus. It has an N4 interface to the SMF 410 and an N3 interface to the RAN domain 108. The UPF 140 supports handling of user plane data traffic (e.g., digital content) and of location-aware actions based on the rules received via the SMF 410 from the PCF 420. It can also be configured by other entities of the SBA to perform location-aware actions or it can trigger location- aware actions on the side of other SBA entities.

[0122] - An AMF 430 handles access and mobility for the UE 110. Moreover, it can function as a source of mapping information, or portions thereof, for other CN domain entities such as the UPF 140 and NWDAF 130.

[0123] The NWDAF 130, as an exemplary realization of a mapping information generation apparatus, is configured to interact with different CN domain entities for different purposes. For example, the NWDAF 130 is capable of providing, on an "on-demand" basis, data analytics to consumers. It also is capable of retrieving data from repositories in the CN domain 106 and to collect data, possibly based on an event subscription, from other CN domain entities such as the SMF 410, the AMF 430 and the UPF 140. In some variants, the NWDAF 130 is capable of commanding the UPF to perform (and possibly report the result of) location-aware actions.

[0124] The 5G SBA depicted in Fig. 4 further comprises the RAN domain 108 with associated entities. Fig. 5 illustrates a possible implementation of the RAN domain 108 in the form of a "split architecture". It is to be noted that the RAN domain 108 could also be implemented otherwise.

[0125] The exemplary "split architecture" RAN domain 108 illustrated in Fig. 5 comprises multiple entities of interest for the present disclosure, including a Radio Frequency / Baseband Frequency (RF / BF) entity 510, a Baseband Processing Function 520 interacting with the UE 110 via the RF / BF entity 510, and a Packet Processing Function (PPF) 530 interacting with the UPF 140 via the N3 interface (see Fig. 4). The PPF 530 may be the entity that allocates F-TEIDs in the RAN domain 108.

[0126] There exist different deployment scenarios for the PBF 520 and the PPF 530. In a distributed RAN (D-RAN), the BPF 520 and the PPF 530 are co-located. In a centralized RAN (C-RAN), the PPF 530 is centralized and configured to serve several PBFs 520. In C-RAN scenarios, the PPF 530 may allocate the F-TEIDs taking into account the specific BPF 520 which is serving a particular UE 110

[0127] Mobile network connectivity services (i.e., services that provide for the exchange of data packets between a UE 110 and the content provider domain 102; see Fig. 1) are supported by PDU sessions that are established upon a request from a UE 110. Between the RAN domain 108 and the CN domain 106, the corresponding data traffic is transferred over GTP-U tunnels 120 (see Fig. 1). As explained above, these tunnels 120 are identified at each endpoint by a dedicated F-TEID. In the exemplary implementation of Fig. 5, the F-TEID allocated on the side of the RAN domain 108 includes a concatenation of the IP address of the PPF 530 and a TEID.

[0128] Fig. 6 illustrates an exemplary GTP-U-based user plane (UP) protocol stack 600 between a UE 110 and a UPF 140B anchoring a PDU session in the CN domain 106. As shown in Fig. 6, the PDU session transparently stretches from the UE 110 through the RAN domain 108 and via zero, one or more intermediate UPFs 140A in the CN domain 106 to the PDU Session Anchor (PSA) UPF 140B. On the side of the UE 110, a PDU protocol layer 610 is arranged between an application layer 620 (terminating, on the opposite side, in the content provider domain 102) and lower protocol layers 630. On the side of the PSA UPF 140B, the protocol layers included a Layer 1 (LI) 640 as the lowest layer, followed by a Layer 2 (L2) 650, a User Datagram Protocol (UDP) / IP layer 660 and a GTP-U layer 670 (and similar for the RAN domain 108 and the UPF 140A).

[0129] In case one or more intermediate UPFs 140A are present in the UP data path, as illustrated in Fig. 6, the F-TEID allocated in the RAN domain 108 (e.g., to the PPF 530; see Fig. 5) will be overwritten in the GTP-U headers of the GTP-U PDUs by the F-TEIDs of the preceding hop in the data path. In the example of Fig. 6, the F-TEID allocated in the RAN domain 108 will thus be overwritten by the F-TEID of the UPF 140B. As a result, the PSA UPF 140B cannot infer the F-TEID allocated in the RAN domain 108 from the GTP-U headers (e.g., for the purpose of obtaining the corresponding F-TEID in step 340 of Fig. 3B or for the purpose of providing same to the mapping information generation apparatus 140 for generation the mapping information in step 320 of Fig. 3A). To address this situation, the F-TEID allocated in the RAN domain 108 will be included in an extension header of a GTP-U PDU to make sure that the corresponding information arrives at the PSA UPF 140B also in case of one or more intermediate UPFs 140A (or other intermediate hops). Some aspects of GTP-U PDUs are described in 3GPP TS 29.281 V18.0.0 (2023 / 06), which is herewith incorporated by reference.

[0130] In the following description, exemplary 5G signaling realizations implementing aspects of the present disclosure will be described with reference to Figs. 7A to 7C and the 5G entities discussed above with reference to Figs. 4 to 6. It will be apparent to one skilled in the art that similar signaling realizations will apply in case of a 4G or a combined 4G / 5G implementation.

[0131] In Figs. 7A to 7C, only the signalling steps relevant for understanding the technique presented herein are illustrated.

[0132] With reference to Fig. 7A, the exemplary network setup comprises four UEs 110A to HOD, two RAN domains 108A, 108B, a single UPF 140 configured for location context determination (although two or more UPFs 140A, 140B could be implemented in series, see Fig. 6), an AMF 430, an SMF 410 as well as an NWDAF 130 configured for generation of mapping information. For shortness, the UEs 110A to HOD will in the following also be denoted as UE1 to UE4, respectively.

[0133] In some variants, the UPF 140 can be co-located with the NWDAF 130 ("L-NWDAF"). In such variants, the UPF 140 may include the NWDAF analytic service contact information in profile information that it registers in the NRF. An analytics consumer may select the NWDAF 130 where so send analytics request messages using any of the discovery filters that apply to its paired UPF 140, such as "service area".

[0134] Steps 1 to 6 in Fig. 7A are conceptual representations of how the F-TEIDs are allocated in the different RAN domains 108A, 108B. It is assumed that UE1, UE2 and UE4 connect to a first dedicated entity (e.g., a PPF) in the first RAN domain 108A, while UE3 connects to a dedicated second entity (e.g., another PPF) in the second RAN domain 108B (see signalling steps 1, 2, 3 and 5 that can be performed in any order). The corresponding entities in the RAN domains 108A, 108B will have associated IP addresses IP1, IP2, respectively.

[0135] For establishment of a GTP-U tunnel 120 for the data traffic of, for example, UE1, an F-TEID will be allocated in the RAN domain 108A (e.g., by a PPF) to the RAN domain endpoint of the GTP-U tunnel 120 in the RAN domain 108A. The F-TEID is generated from an IP address and a TEID as constituents. Typically, the IP address is selected from an IP range and / or the TEID is selected from a TEID range associated with the RAN domain 108A, resulting in an associated F-TEID range. As a consequence, data traffic for UE1, UE2 and UE4 will be routed through GTP-U tunnels 120 respectively associated with F-TEID1 (= IP1 + TEID1), F-TEID2 (= IP1 + TEID2) and F-TEID4 (= IP2 + TEID4) included in a first F-TEID range associated with the RAN domain 108A. In a similar manner, data traffic for UE3 will be routed through a GTP-U tunnel 120 associated with F-TEID3 (= IP2 + TEID3) included in a second F-TEID range associated with the RAN domain 108B. See steps 4 and 6 in Fig. 7A.

[0136] After the UE1 to UE4 have obtained network access through the AMF 430, and after the AMF 430 has informed the SMF 410 accordingly, the SMF 410 in signaling steps 7 to 10 sends PFCP Session Establishment Request messages for UE1 to UE4 to the UPF 140. In this manner, the SMF 410 provides to the UPF 140 the relevant PDU session contexts for UE1 to UE4. The UPF 140 is however not informed about location contexts (e.g., ULI) associated with UE1 to UE4. For this reason, an F-TEID- based procedure for obtaining location contexts will be performed, as discussed hereinafter with reference to steps 11 to 24. In step 11, the UPF 140 subscribes to a new analytics service in accordance with the present disclosure (with the exemplary Analytic-ID = F-TEID Discovery from NodeB ID) for mapping information discovery. The subscription is triggered by sending an Nnwdaf_AnalyticsSubscription_Subscribe message to the NWDAF 130 (see, e.g., step 310 in Fig. 3A). This message may include one or more subscription-related filters, such as one or more of F-TEID1 and a user terminal identifier of UE1 (e.g., SUPU) to target the corresponding RAN domain 108A. Additionally or in the alternative, also a base station identifier such as an NCGI could be used as filter. Such information is readily available to the UPF 140 as it terminates the GTP-U tunnel 120 associated with F-TEID1.

[0137] It will in the following be assumed that the NWDAF 130 does not know the location context (e.g., NodeBIDl, which can be a dedicated NCGI) associated with F-TEID1. As such, the NWDAF 130 first has to infer this location context before it can generate mapping information (see step 320 in Fig. 3A). Therefore, in step 12 and responsive to the Nnwdaf_AnalyticsSubscription_Subscribe message received in step 11, the NWDAF 130 asks the AMF 430 for the location context associated with F-TEID1 by triggering an Namf_Location_ProvideLocationInfo_Request message. This message can include one or both of F-TEID1 and SUPI1.

[0138] The AMF 430 responds to the NWDAF 130 in step 13 by triggering an Namf_Location_ProvideLocationInfo_Notify message including the location context associated with the F-TEID1, in this case NodeBIDl.

[0139] Then, in step 14 (see Fig. 7B) and responsive to the Nnwdaf_AnalyticsSubscription_Subscribe message received in step 11, the NWDAF 130 additionally triggers data collection from the UPF 140 by sending an Nupf_EventExposure_Request message. This message can also be sent to one or more UPFs different from the UPF 140 that triggered the Nnwdaf_AnalyticsSubscription_Subscribe message in step 11. In many cases, steps 12 and 14 can be performed in any order.

[0140] The Nupf_EventExposure_Request message for data collection may be of a new event type (e.g., Event-Type = F-TEID discovery). The Nupf_EventExposure_Request message in some variants triggers data collection for all PDU sessions served by the UPF 140. As an option, the message may indicate a particular F-TEID or an F-TEID range (e.g., of a particular RAN domain 108A, 108B) as a filter. Of course, the message may also include other filters, such as a user terminal identifier or an NCGI as exemplary base station identifier.

[0141] In step 15, the UPF 140 returns an Nupf_EventExposure_Response message to the NWDAF 130. This message may be sent immediately or after some condition is reached (periodicity, event, etc.). The message in one implementation includes all the F-TEIDs observed by the UPF 140, optionally within the range indicated in the Nupf_EventExposure_Request message. In the present case, the UPF 140 reports F- TEID1 (= IP1 + TEID1), F-TEID2 (= IP1 + TEID2), F-TEID3 (= IP2 + TEID3) and F- TEID4 (= IP2 + TEID4).

[0142] The NWDAF 130 then generates mapping information by assigning the observed and reported F-TEIDs to individual location contexts, i.e., NodeB IDs. In this example, as the IP address IP1 was already observed by the NWDAF 130 (as constituent of F- TEID1), and since F-TEID2 and F-TEID4 share same IP address IP1 as constituent, they can be directly correlated to NodeBIDl, see the mapping table associated with step 15 in Fig. 7B (see also step 320 in Fig. 3A).

[0143] As becomes apparent from Fig. 7B, the table also includes F-TEID3 for which the NWDAF 130 cannot infer the location context. Therefore, the NWDAF 130 in step 16 again contacts the AMF 430 a to obtain the NodeB ID associated with F-TEID3 by sending an Namf_Location_ProvideLocationInfo_Request message including F-TEID3 (and / or an associated SUPI3 of UE3).

[0144] In step 17, the AMF 430 responds to the NWDAF 130 by an Namf_Location_ProvideLocationInfo_Notify message including the NodeB ID (e.g., obtained from the ULI) associated with F-TEID3, in this case NodeBID2. As such, the NWDAF 130 can supplement the missing portion of the mapping information (see the mapping table associated with step 17 in Fig. 7B and see also step 320 in Fig. 3A).

[0145] In step 18, the NWDAF 130 sends a response to the initial UPF subscription by triggering an Nnwdaf_AnalyticsSubscription_Notify message to the UPF 140. This message includes the generated mapping information (see step 330 in Fig. 3A) and all the observed F-TEIDs for the subscription. As explained above, the subscription is triggered in step 11 for PDU session "PDUl" and F-TEID1, whereupon the associated base station (with NodeBIDl) serving this PDU session is inferred (steps 12 and 13), and the further collection of mapping information is extended to all F-TEIDs known to that base station (steps 14 and 15). Once the UPF 140 has obtained the mapping information in step 18, it can use this information in the context of a location-aware action. For example, the UPF 140 may in a further step (not shown in Fig. 7B) be commanded by the SMF 410 and / or the NWDAF 130 to perform location-aware data collecting / reporting, such as for an individual NodeB ID like NodeBIDl. The UPF 140 then consults the mapping information obtained in step 18 to differentiate the PDU sessions served by the base stations (NodeBs) based on the GTP-U tunnels 120 to determine the PDU sessions that are to be covered by the data collecting / reporting on the one hand (here: those associated with F-TEID1, F-TEID2 and F-TEID4) and, on the other hand, the PDU sessions associated with GTP-U tunnels 120 that are not to be covered by the data collecting / reporting (here: the GTP-U tunnel 120 associated with F-TEID3).

[0146] The event subscription-based approach discussed above (see step 11 of Fig. 7A and step 18 of Fig. 7B) permits to update the UPF 140 in case of events that lead to mapping information changes. One such event is a dynamic re-allocation of IP addresses, and another such event is a UE handover. In this regard, Fig. 7C illustrates a corresponding handover scenario for the case of UE3 moving from RAN domain 108B to RAN domain 108A. In this case, the corresponding GTP-U tunnel endpoint in RAN domain 108A will be associated with F-TEID5 = IP1 + TEID5, see step 19 of Fig. 7C.

[0147] Steps 20 to 23 are similar to steps 14 to 17 as discussed above with reference to Fig. 7B. It should be noted that the NWDAF 130 could trigger step 20 in an event-driven manner or on a periodic basis. Steps 22 and 23 are required at least when the IP addresses can be allocated in a dynamic manner (e.g., since after a certain period of time, IP1 may no longer correspond to NodeBIDl). As a result, the mapping information can be updated in that the new F-TEID5 for UE3 is associated with NodeBIDl, see the table in Fig. 7C beneath step 23.

[0148] In step 24, the NWDAF 130 sends a further response in the UPF subscription context by triggering an Nnwdaf_AnalyticsSubscription_Notify message to the UPF 140. This message includes the updated mapping information (see step 330 in Fig. 3A). As such, the UPF 140 can from now on use the updated mapping information when executing, or triggering execution of, any location-aware action.

[0149] In some embodiments, the UPF 140 consulting the mapping information is triggered by the PCF 420 sending to the SMF 410 a PCC rule indicative of, for example, a traffic-shaping action. The SMF 410 translates the PCC rule in a Packet Detection Rule (PDR) with a user plane rule for the traffic-shaping action and sends the PDR to the UPF 140.. The UPF 140, upon reception of the PDR, subscribes to the NWDAF 130 to inquire about the UEs 110 in the particular cell. When the UPF 140 has been informed about the UEs 110 by the NWDAF 130, it aggregates one or more Key Performance Indicators (KPIs) associated with their PDU sessions and relevant for a congestion scenario (e.g., throughput or round-trip time, RTT). The UPF 140 may then calculate an associated congestion level to determine whether or not to apply the traffic shaping action with respect to the particular cell and its PDU sessions. The UPF 140 is thus enabled to selectively aggregate the KPIs (and, as a result, apply the traffic-shaping action) by evaluating, based on the mapping information and the F- TEIDs associated with all PDU sessions handled by the UPF 140, which PDU sessions are to be effected (see also step 360 in Fig. 3B).

[0150] As has become apparent from the above description of exemplary embodiments, and in particular from the signalling diagrams of Figs. 7A to 7C, the technique presented herein fits very well into the 3GPP framework for 5G and "beyond-5G" implementations of mobile communication networks 100. The technique presented herein in some implementations thus allows the UPF 140 to infer the location context of a certain RAN domain 108A, 108B (and, thus, of a certain UE 110 or PDU session(s) served thereby) independent of the suppliers of the RAN domains 108A, 108B and of the SMF 410, as there no longer is a need for proprietary solutions. Of course, the technique presented herein could also be combined with proprietary solutions. For example, the UPF 140 could obtain the location context in a proprietary Information Element, IE, from the SMF 410 and then construct the mapping information as discussed above with reference to step 320 of Fig. 3A. In all variants, the mapping information can be generated and maintained dynamically.

[0151] The technique presented herein makes the UPF 140 location-aware without the need for additional signaling. In some implementations there may be an exception when the NWDAF 130 needs to contact the AMF 430 (see step 12 in Fig. 7A and step 16 in Fig. 7B), but the NWDAF 130 does so only to request a supplemental location context when it has not been provided with the ULI or similar information, and typically once per base station. Furthermore, the analytics presented herein for generating mapping information may identify a pattern of how F-TEIDs are associated for a given location context (e.g., per base station) and predict (e.g., based on machine learning) the location context for other F-TEIDs falling within a certain F-TEID range (e.g., associated with a certain base station). Such an approach will reduce even more the signaling between the NWDAF 130 and the AMF 430.

[0152] The technique presented herein in some implementations simplifies the way the UPF 140 associates a PDU session with certain location context (e.g., a certain base station) as the technique is performed at the "F-TEID level", thus exploiting information in the headers of GTP-U PDUs that are anyhow handled and inspected for basic UPF functionalities. As such, no extra traffic processing may be needed on the side of the UPF 140, with the possible exception of UP paths with multiple UPFs 140A, 140B (see Fig. 6), where extension GTP-U headers should need to carry the RAN-allocated F-TEID to the PSA UPF 140B.

[0153] In certain implementations, the NWDAF 130 can use its analytic output (i.e., the generated mapping information) itself for other analytics purposes that require data aggregation for specific location contexts. An example in this regard includes basing a data collection command (e.g., to UPF 140), as an exemplary location-aware action, on the F-TEID instead of the ULI (or any other location context indication). As another example, an external consumer can subscribe to congestion events at a certain location (e.g., RAN domain or base station), and the NWDAF 130 can use F- TEIDs to request and aggregate the data (e.g., from UPF 140) in a location-aware manner.

[0154] It has been found that using the F-TEID as filter for location-aware data collection reacts better to UE mobility. Using F-TEID, an NWDAF 130 does not need to be subscribed to UE mobility updates (decreasing signaling), since the F-TEID range is typically fixed to a certain area (e.g., RAN domain 108 or base station contained therein). When a UE 110 enters this area, it (i.e., its associated user plane tunnel 120) is automatically granted an F-TEID within a certain F-TEID range, and when the UE 110 exits, its F-TEID is modified according to the new area.

[0155] The location context as presented herein can be attributed to a particular RAN domain 108 (e.g., a geographic area served by a particular base station), a particular PDU session stretching through the RAN domain 108 or a particular UE 110 served by the RAN domain 108. As such, the location-aware action may relate to any of these entities.

[0156] The mapping information generated as outlined herein cannot just be used by the NWDAF 130 and the UPF 140, but by any CN entity having access to F-TEIDs or portions thereof. The mapping information can easily be generated and maintained using, for example, a subscription-based communication mechanism.

[0157] While exemplary embodiments have been described above, the technique presented herein can be implemented in other embodiments.

Claims

Claims1. A method performed in a core network, CN, domain (106) of a mobile communication network (100), wherein the mobile communication network (100) further comprises a Radio Access Network, RAN, domain (108), the method comprising: obtaining (340) a Fully Qualified Tunnel Endpoint Identifier, F-TEID, allocated to a RAN domain endpoint of a user plane tunnel (120); and determining (350), based on at least a portion of the F-TEID, a location context for the F-TEID.

2. The method of claim 1, wherein the method is performed by a user plane entity (140) terminating the user plane tunnel (120) in the CN domain (106).

3. The method of an of the preceding claims, wherein the location context is determined from mapping information indicative of one or more associations between one or more F-TEIDs, or one or more portions thereof, and one or more location contexts.

4. The method of claim 3, wherein at least a portion of the mapping information is received from a Session Management Function, SMF (410).

5. The method of claim 3 or 4, comprising sending a mapping information discovery request; and receiving the mapping information, or at least a portion thereof, in response to the mapping information discovery request.

6. The method of claim 5, wherein the mapping information discovery request is sent to, and the mapping information or the portion thereof is received from, a Network Data Analytics Function, NWDAF (130).

7. The method of any of claims 5 and 6, wherein the mapping information discovery request indicates a first F-TEID, and wherein the received mapping information includes at least one of:- a first location context associated with the first T-FEID;- an association between one or more second F-TEIDs and the first location context; and- an association between one or more third F-TEIDs and at least one second location context.

8. The method of any of claims 5 and 6, wherein the mapping information discovery request indicates a first location context, and wherein the received mapping information includes at least one of:- one or more first F-TEIDs associated with the first location context; and- an association between one or more second F-TEIDs and at least one second location context.

9. The method of any of any of claims 5 and 6, wherein the mapping information discovery request indicates a user terminal identifier associated with a first location context, and wherein the received mapping information includes at least one of:- an association between one or more first F-TEIDs and the first location context; and- an association between one or more second F-TEIDs and at least one second location context.

10. The method of any of claims 5 to 9, wherein the mapping information discovery request is an event subscription that triggers updates on mapping information-related events.

11. The method of claim 10, wherein the event subscription relates to events pertaining to an entity indicated in the mapping information discovery request, wherein the entity is one of the first F-TEID, the first location context and the user terminal identifier.

12. The method of any of the preceding claims, comprising receiving a data collection request by a, or the, user plane entity (140);and returning, in response to the data collection request, one or more fourth F-TEIDs associated with one or more user plane tunnels (120) terminated by the user plane entity (140).

13. The method of claim 12, comprising determining one or more third location contexts associated with the one or more fourth F-TEIDs, wherein the one or more fourth F-TEIDs are returned in association with the corresponding one or more third location contexts that could be determined.

14. The method of claim 12 of 13 in combination with any of claims 3 to 11, wherein the mapping information includes the one or more fourth T-FEIDs and optionally, the corresponding one or more third location contexts that could be determined.

15. The method of any of the preceding claims, comprising executing, or triggering execution of, (260) at least one location-aware action in the CN domain (106) based on the location context determined (350) for the F-TEID.

16. The method of claim 15, wherein the location-aware action comprises at least one of:- location-aware traffic shaping;- location-aware event reporting;- location-aware data collection;- location-aware data or traffic filtering; and- location-aware handling of Packet Data Unit, PDU, sessions.

17. The method of any of the preceding claims, wherein the location context comprises one or more of:- User Location Information, ULI;- one or more a cell or base station identifiers, in particular one or more Cell Global Identifiers, CGIs; and- one or more area identifiers.

18. The method of any of the preceding claims, wherein each F-TEID includes an Internet Protocol, IP, address, and wherein the location context for a given F-TEID is determined based on the IP address included in the given F-TEID.

19. The method of any of the preceding claims, wherein the F-TEID is obtained from a header of a GPRS Tunneling Protocol, GTP, packet data unit, G-PDU.

20. The method of any of claims 1 to 19, wherein the F-TEID is obtained from an extension header of a GPRS Tunneling Protocol, GTP, packet data unit, G-PDU.

21. The method of any of the preceding claims, wherein the method is performed by a User Plane Function, UPF (140).

22. A method performed in a core network, CN, domain (106) of a mobile communication network (100), wherein the mobile communication network (100) further comprises a Radio Access Network, RAN, domain (108), the method comprising: receiving (310) a mapping information discovery request; generating (320) mapping information indicative of one or more associations between one or more Fully Qualified Tunnel Endpoint Identifiers, F-TEIDs, or one or more portions thereof, and one or more location contexts, wherein the F-TEIDs are allocated to RAN domain endpoints of user plane tunnels (120); and sending (330) the mapping information, or a portion thereof, in response to the mapping information discovery request.

23. The method of claim 22, comprising obtaining the one or more F-TEID portions by extraction from one or more F-TEIDs.

24. The method of claim 22 or 23, wherein the mapping information discovery request is indicative of at least one of a first F-TEID and a user terminal identifier associated with the first F-TEID.

25. The method of claim 24, comprising sending a location context request indicative of at least one of the first F-TEID and the associated user terminal identifier; and receiving, in response to the location context request, a first location context associated with the first F-TEID, wherein the mapping information is generated to be indicative of the association between the first F-TEID and the first location context.

26. The method of any of claims 22 to 25, comprising sending a data collection request to a user plane entity (140) terminating one or more user plane tunnels (120) in the CN domain (106); and receiving, in response to the data collection request, at least one of- one or more second F-TEIDs allocated to one or more RAN domain endpoints of the one or more user plane tunnels (120); and- one or more user terminal identifiers associated with the one or more second F-TEIDs.

27. The method of claim 26, wherein each F-TEID includes an Internet Protocol, IP, address uniquely associated with a location context; and comprising determining, based on identical IP addresses, one or more second location contexts associated with the one or more second F-TEIDs to equal the known location context of another F-TEID, wherein the mapping information is generated to be indicative of one or more associations between the one or more second F- TEIDs and the one or more second location contexts.

28. The method of claim 26, comprising sending a location context request indicative of at least one of:- at least one of the one or more second F-TEIDs; and- at least one of the one or more user terminal identifiers associated with the one or more second F-TEIDs; and receiving, in response to the location context request, the at least one second location context associated with the at least one second F-TEID, wherein the mapping information is generated to be indicative of the association between the at least one second F-TEID and the at least one second location context.

29. The method of claim 25 or 28, wherein the location context request is sent to an Access and Mobility Management Function, AMF (430).

30. The method of any of claims 22 to 29, wherein the mapping information discovery request indicates a third F-TEID, and wherein the mapping information includes at least one of:- a third location context associated with the third T-FEID;- an association between one or more fourth F-TEIDs and the third location context; and- an association between one or more fifth F-TEIDs and at least one fourth location context.

31. The method of any of claims 22 to 29, wherein the mapping information discovery request indicates a third location context, and wherein the mapping information includes at least one of:- one or more third F-TEIDs associated with the third location context; and- an association between one or more fourth F-TEIDs and at least one fourth location context.

32. The method of any of claims 22 to 29 wherein the mapping information discovery request indicates a user terminal identifier associated with a third location context, and wherein the mapping information includes at least one of:- an association between one or more third F-TEIDs and the third location context;- an association between one or more fourth F-TEIDs and at least one fourth location context.

33. The method of any of claims 22 to 32, wherein the mapping information discovery request is an event subscription that triggers updates on mapping information-related events.

34. The method of claim 33, wherein the event subscription relates to events pertaining to an entity indicated in the mapping information discovery request, wherein the entity is one of thethird F-TEID, the third location context and the user terminal identifier.

35. The method of claim 33 or 34, comprising detecting an event that requires an update of the mapping information; determining, in response to the detected event, updated mapping information; and sending, in response to the event subscription, the updated mapping information.

36. The method of any of claims 22 to 35, comprising determining, using machine learning, an assignment model indicative of how F-TEIDs are allocated in the RAN domain per location context; determining, for a given F-TEID, the associated location context from the assignment model.

37. The method of any of claims 22 to 36, comprising obtaining a location context; consulting the mapping information to determine an F-TEID associated with the obtained location context; and triggering an action based on the determined F-TEID.

38. The method of any of claims 22 to 37, wherein the method is performed by a Network Data Analytics Function, NWDAF (130).

39. A computer program product comprising program code portions configured to perform the method of any of the preceding claims when the computer program product is executed on one more processors (202).

40. The computer program product of claim 39, stored on a computer-readable recording medium.

41. An apparatus (140) configured to be operated in a core network, CN, domain (106) of a mobile communication network (100), wherein the mobile communication network (100) further comprises a Radio Access Network, RAN, domain (108), the apparatus (140) being configured to: obtain a Fully Qualified Tunnel Endpoint Identifier, F-TEID, allocated to a RAN domain endpoint of a user plane tunnel (120); anddetermine, based on at least a portion of the F-TEID, a location context for the F-TEID.

42. The apparatus of claim 41, configured to perform the method of any of claims 2 to 21.

43. An apparatus (130) configured to be operated in a core network, CN, domain (106) of a mobile communication network (100), wherein the mobile communication network (100) further comprises a Radio Access Network, RAN, domain (108), the apparatus (100)being configured to: receive a mapping information discovery request; generate mapping information indicative of one or more associations between one or more Fully Qualified Tunnel Endpoint Identifiers, F-TEIDs, or one or more portions thereof, and one or more location contexts, wherein the F-TEIDs are allocated to RAN domain endpoints of user plane tunnels (120); and send the mapping information, or a portion thereof, in response to the mapping information discovery request.

44. The apparatus of claim 43, configured to perform the method of any of claims 23 to 38.

45. A network system comprising the apparatus (140) of claim 41 or 42 and apparatus (130) of claim 43 or 44.

Images