Distributed sensing context management in a network

Abstract

In some examples, a method for distributed sensing context management in a network comprises receiving, at a network entity of multiple first entities, sensing data locally from the network entity of the multiple first entities or from one or more network entities of multiple second entities, labelling the sensing data as sensing context according to a data structure comprising one of an object‐based structured data format and a region‐based structured data format, the object‐based structured data format comprising an object identifier, object position, capture time, associated sensing data and optionally object state and object class information, and the region‐based structured data format comprising a region of interest, a sensing data set identifier, capture time and associated sensing data, and exchanging the sensing context with one or more of the network entities of the multiple first entities based on a triggering mechanism.

Description

[0001] DISTRIBUTED SENSING CONTEXT MANAGEMENT IN A NETWORK

[0002] TECHNICAL FIELD

[0003] The present disclosure relates, in general, to the management of sensing context in networks and, more particularly, to systems and methods for distributed management of sensing context in mobile and radio access networks. In various embodiments, the present invention addresses aspects of sensing data labelling, sensing context consolidating, and exchanging, where sensing data is derived from sensing signals and sensing context refers to sensing data together with the labels.

[0004] BACKGROUND

[0005] Modem radio access networks are primarily deployed to support communications by transmitting radio signals between network nodes. However, as these signals propagate through the environment, they are influenced by surrounding objects and conditions, thereby providing an opportunity to extract valuable environmental and object-related information. In nextgeneration mobile networks, the same radio nodes — ranging from base stations to user devices — can also function as sensing devices, capturing data such as spatial representations and occupancy information.

[0006] A range of applications, including intrusion detection in smart homes, tracking of vehicles or unmanned aerial vehicles, and monitoring public safety, rely on the ability to sense and interpret environmental conditions. Such applications require sensing data that may include point clouds or occupancy grids and can provide information on object position, motion, and classification. Traditionally, a centralised approach has been used where a single network entity is responsible for collecting and processing all sensing data. However, given the extensive scale of modem networks — with thousands to millions of nodes — the centralised approach often results in significant challenges, such as high data processing loads, increased latency, and reduced accuracy in the sensing results.

[0007] Some solutions from prior art have attempted to manage related information in a distributed manner by segmenting networks into smaller areas or tracking zones. For example, in location-based services, location information is collected and managed by multiple entities responsible for distinct geographical areas. Although such methods have proven effective for location management, they are not directly applicable to the management of sensing context. Unlike location data, sensing context encompasses a wider range of information, including detailed environmental data, object states, and associated labels, and is not necessarily bound to a single device.

[0008] Moreover, current solutions do not adequately support the sharing and consolidation of sensing context among distributed network entities. The lack of coordinated sharing limits the effectiveness of sensing applications, particularly when information from neighbouring areas could improve the detection and tracking of objects across overlapping or multiple regions.

[0009] SUMMARY

[0010] An objective of the present disclosure is to provide a sensing context management function, which manages sensing context exposure, discovery, consolidation, as well as sensing context sharing with other network entities.

[0011] The foregoing and other objectives are achieved by the features of the independent claims.

[0012] Further implementation forms are apparent from the dependent claims, the description and the Figures.

[0013] A first aspect of the present disclosure provides a method for distributed sensing context management in a network, the method comprising receiving, at a network entity of multiple first entities, sensing data locally from the network entity of the multiple first entities or from one or more network entities of multiple second entities, labelling the sensing data as sensing contextaccording to a data structure comprising one of an object-based structured data format and a region-based structured data format, the object-based structured data format comprising an object identifier, object position, capture time, associated sensing data and optionally object state and object class information, and the region-based structured data format comprising a region of interest, a sensing data set identifier, capture time and associated sensing data, and exchanging the sensing context with one or more of the network entities of the multiple first entities based on a triggering mechanism.

[0014] Labelling the sensing data may further comprise assigning a local object identifier or a local sensing data set identifier for the sensing context.

[0015] The method may further comprise consolidating the sensing context , whereby to obtain consolidated sensing context, wherein consolidating the sensing context comprises at least one of matching, merging, and extending of the sensing context based on the capture time and corresponding labels, wherein exchanging the sensing context with one or more of the network entities of the multiple first network entities comprises exchanging the consolidated sensing context.

[0016] Matching the sensing context may further comprise matching received sensing context based on at least one of object class, object position, object states, region of interest and capture time.

[0017] Consolidating the sensing context may comprise merging the sensing context when a capture time is identical and extending the sensing context when a capture time is different.

[0018] Exchanging the sensing context may comprise active sharing or passive sharing of the sensing context with the one or more of the network entities of the multiple first entities.

[0019] The passive sharing of the sensing context may comprise at least one of registering sensing context at a repository function, discovering sensing context via a repository function, receiving a request or subscription for sensing context sharing, and sending a request or subscription for sensing context sharing.

[0020] Exchanging the sensing context may be based on exchange criteria comprising: a sensing context type, labels , network topology / infrastructure, time, or location.

[0021] The method may further comprise updating a local sensing context database with the sensing context including mapping of object identifiers received from different network entities of the first network entities or the second network entities, wherein the local sensing context database further records source information indicative of origin of the sensing context.

[0022] The method may be implemented in implemented in a distributed sensing system comprising a plurality of sensing nodes, sensing functions and / or a plurality of sensing data storage entities interconnected via a network interface.

[0023] A second aspect of the present disclosure provides an apparatus for distributed sensing context management in a network, the apparatus comprising a receiver configured to receive sensing data, the sensing data received locally at the receiver or received from one or more network entities, a labeller configured to label the sensing data as sensing context according to a data structure comprising one of an object-based structured data format and a region-based structured data format, the objectbased structured data format comprising an object identifier, object position, capture time, associated sensing data and optionally object state and object class information, and the region-based structured data format comprising a region of interest, a sensing data set identifier, capture time and associated sensing data, and an exchanger configured to exchange the sensing context with one or more network entities based on a predetermined triggering mechanism.The apparatus may further comprise a mapping unit configured to assign a local object identifier or a local sensing data set identifier for the sensing context.

[0024] The apparatus may further comprise a consolidator configured to consolidate sensing context received from one or more network entities by performing matching, merging and extending of the sensing context based on the capture time and corresponding labels.

[0025] The consolidator may be configured to merge the sensing context when the capture time is identical and to extend the sensing context when the capture time is different.

[0026] A third aspect of the present disclosure provides a non-transitory computer-readable medium storing instructions which, when executed by a processor, cause the processor to perform a method for distributed sensing context management, the method comprising receiving, at a network entity of multiple first entities, sensing data locally from the network entity of the multiple first entities or from one or more network entities of multiple second entities, labelling the sensing data as sensing context according to a data structure comprising one of an object-based structured data format and a region-based structured data format, the object-based structured data format comprising an object identifier, object position, capture time, associated sensing data and optionally object state and object class information, and the region-based structured data format comprising a region of interest, a sensing data set identifier, capture time and associated sensing data, and exchanging the sensing context with one or more network entities of the multiple first network entities based on a predetermined triggering mechanism.

[0027] These and other aspects of the invention will be apparent from the embodiments) described below.

[0028] BRIEF DESCRIPTION OF THE DRAWINGS

[0029] In order that the present invention may be more readily understood, embodiments of the invention will now be described, by way of example, with reference to the accompanying drawings, in which:

[0030] Figure 1 is a flow chart of a method according to an example;

[0031] Figure 2a is an illustration of object-based sensing context consolidation according to an example;

[0032] Figure 2b is an illustration of region of interest-based sensing context consolidation according to an example;

[0033] Figure 3 is a flow chart of a procedure for sensing context consolidation according to an example;

[0034] Figure 4 is a schematic representation of a first network entity and a second network entity for sensing context sharing according to an example;

[0035] Figure 5 is a schematic representation of deployment of a network entity as part of SF / SE connected to 3GPP 5GC using SBI, according to an example;

[0036] Figure 6 is a schematic representation of deployment of a network entity as part of a data storage function / entity in a mobile network using SBI, according to an example;

[0037] Figure 7 is a schematic representation of deployment of a network entity as one type of a data processing entity connected to a data plane / data bus in a 6G mobile network, according to an example;Figure 8 is a schematic representation of an implementation of sensing context sharing in a hierarchical distributed architecture according to an example;

[0038] Figure 9 is a schematic representation of a general sensing context exposure and triggers according to an example;

[0039] Figure 10 is a schematic representation of passive context exposure / exposure based on a subscription or a request according to an example;

[0040] Figures 1 la-11c are schematic representations of implementation options in a 3GPP architecture according to an example; and

[0041] Figure 12 is a schematic representation of an apparatus according to an example.

[0042] DETAILED DESCRIPTION

[0043] Example embodiments are described below in sufficient detail to enable those of ordinary skill in the art to embody and implement the systems and processes herein described. It is important to understand that embodiments can be provided in many alternate forms and should not be construed as limited to the examples set forth herein.

[0044] Accordingly, while embodiments can be modified in various ways and take on various alternative forms, specific embodiments thereof are shown in the drawings and described in detail below as examples. There is no intent to limit to the particular forms disclosed. On the contrary, all modifications, equivalents, and alternatives falling within the scope of the appended claims should be included. Elements of the example embodiments are consistently denoted by the same reference numerals throughout the drawings and detailed description where appropriate.

[0045] The terminology used herein to describe embodiments is not intended to limit the scope. The articles “a,” “an,” and ‘The” are singular in that they have a single referent, however the use of the singular form in the present document should not preclude the presence of more than one referent. In other words, elements referred to in the singular can number one or more, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “includes,” and / or “including,” when used herein, specify the presence of stated features, items, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, items, steps, operations, elements, components, and / or groups thereof.

[0046] Unless otherwise defined, all terms (including technical and scientific terms) used herein are to be interpreted as is customary in the art. It will be further understood that terms in common usage should also be interpreted as is customary in the relevant art and not in an idealized or overly formal sense unless expressly so defined herein.

[0047] Examples in the present disclosure can be provided as methods, systems or machine-readable instructions, such as any combination of software, hardware, firmware or the like. Such machine-readable instructions may be included on a computer readable storage medium (including but not limited to disc storage, CD-ROM, optical storage, etc.) having computer readable program codes therein or thereon.

[0048] The present disclosure is described with reference to flow charts and / or block diagrams of the method, devices and systems according to examples of the present disclosure. Although the flow diagrams described above show a specific order of execution, the order of execution may differ from that which is depicted. Blocks described in relation to one flow chart may be combined with those of another flow chart. In some examples, some blocks of the flow diagrams may not be necessary and / or additional blocks may be added. It shall be understood that each flow and / or block in the flow charts and / or block diagrams, as well as combinations of the flows and / or diagrams in the flow charts and / or block diagrams can be realized by machine readable instructions.The machine-readable instructions may, for example, be executed by a machine such as a general-purpose computer, user equipment such as a smart device, e.g., a smart phone, a special purpose computer, an embedded processor or processors of other programmable data processing devices to realize the functions described in the description and diagrams. In particular, a processor or processing apparatus may execute the machine-readable instructions. Thus, modules of apparatus (for example, a module implementing a comparator unit, or a firewall structure and so on) may be implemented by a processor executing machine readable instructions stored in a memory, or a processor operating in accordance with instructions embedded in logic circuitry. The term 'processor' is to be interpreted broadly to include a CPU, processing unit, ASIC, logic unit, or programmable gate set etc. The methods and modules may all be performed by a single processor or divided amongst several processors.

[0049] Such machine-readable instructions may also be stored in a computer readable storage that can guide the computer or other programmable data processing devices to operate in a specific mode. For example, the instructions may be provided on a non-transitory computer readable storage medium encoded with instructions, executable by a processor.

[0050] Figure 1 is a flow chart of a method according to an example The method includes, in block 101, receiving, at a network entity among multiple first entities, sensing data. The sensing data may comprise one or more types of sensing results or derived sensing information, such as point clouds, occupancy grids, or other structured formats. The sensing results are derived from the sensing measurements, such as radio signals reflected from an object or environment, which can be processed to produce data in the form of point clouds, occupancy grids, or other structured formats.

[0051] In this context, the network entity among the multiple first entities obtains the sensing data either locally (that is, generated by itself) or externally from one or more network entities among multiple second entities. The term “network entity” may refer to any device or function in the network that is capable of handling, storing, or processing sensing data, such as a Sensing Context Management Function (SCMF), a Sensing Function (SF), a data storage function, a RAN node or another suitable node. In some implementations, the multiple first entities and the multiple second entities can be of the same type, meaning that a single node may act in different roles (as a sensing data producer or consumer) depending on the system configuration. Meanwhile, each one of the first entities may comprise a sensing data producer and consumer at the same time. That is, each of the first entities may be able to label the sensing data produced by itself. In contrast, each one of the second entities may comprise a pure sensing data producer, not being capable of performing the sensing data labelling, sensing context consolidation and exchange capability.

[0052] Throughout the specification, the terms “network entity” and “SCMF” are used interchangeably to refer to an entity configured to collect or receive sensing data, label that data in accordance with an object-based or region-based format, and facilitate the exchange of such data or context with other nodes in the network. The SCMF may be integrated within an SF, may operate as a standalone component, or may be included as part of a data storage or processing function, depending on the requirements of the network deployment.

[0053] In block 102, the method comprises labelling the sensing data as sensing context according to a data structure comprising one of an object-based structured data format and a region-based structured data format. In other words, the ‘sensing data’ may be transformed into ‘sensing context’ once it is labelled according to the proposed data structure. The object-based structured data format may include associated sensing data (such as data from a point cloud or an occupancy grid in two or three dimensions), an object identifier, the object’s position or location, one or more attributes or state information of the object, object class information (for example, car, pedestrian, drone, cyclist, building, animal or bird, or unknown), and the capture time. The region-based structured data format may include associated sensing data (such as data from a point cloud or occupancy grid),information regarding the dynamicity of the sensed region, a defined region of interest, a sensing data set identifier (for example, a point cloud identifier and / or an occupancy grid identifier), and the capture time.

[0054] Labelling the sensing data may further comprise assigning a local object identifier or a local sensing data set identifier for the sensing context.

[0055] The method comprises, in block 103, exchanging the sensing context with one or more of the network entities of the multiple first entities based on a triggering mechanism.

[0056] The method may further comprise consolidating the sensing context, whereby to obtain consolidated sensing context. Consolidating the sensing context may comprise at least one of matching, merging, and extending of the sensing context based on the capture time and corresponding labels. Exchanging the sensing context (block 103) may comprise exchanging the consolidated sensing context.

[0057] To aid understanding of the consolidation, reference will now be made to Figures 2a and 2b. Figure 2a is an illustration of object-based sensing context consolidation according to an example, whereas Figure 2b is an illustration of region of interestbased sensing context consolidation according to an example.

[0058] Sensing context can be exchanged between network entities in both directions, or transferred from one entity to another entity in one direction. The network entity may consolidate the sensing context received from other network entities prior to storing the sensing context in a local database and / or exchange that with further network entities. Based on the capture time information, the consolidation of the sensing context information from different sources (i.e., from different network entities) may be either a merge or an extension. In particular, consolidating the sensing context may comprise merging the sensing context when a capture time is identical, and extending the sensing context when a capture time is different. This will be described in more detail in relation to Figures 2a and 2b.

[0059] Object-based sensing context may relate to an object. The data structure may comprise an object ID 211, an object position 212, a capture time 213, and associated sensing data (e.g., point cloud) 214. The data structure may also comprise an object state 215 and an object class 216. Upon receiving the object-based sensing context, the network entity of the first network entities may check whether there is a matching object received from other sourced (e.g., stored in a database, or received at the same time from another network entity) based on the contents of the received sensing context (e.g., associated sensing data, object state 215, or object class 216). If a match is found, the network entity may perform merging or extension of the sensing context based on the capture time, and then store them as consolidated sensing context in the local database. The consolidated sensing contest 220 may use the same local object ID 211 assigned by the consolidating network entity. If the capture time 213 is the same, the network entity may merge sensing context, replacing the object position 212, object state 215, object class 216 by a consolidated position 222, consolidated state 225 and consolidated class 226. The sensing data 214 may comprise consolidated sensing data 224, or merged sensing data with respective source information (e.g., SCMF1 and SCMF2). If the capture time 213 is different, the network entity may extend the sensing context (e.g., in the local database) of the object with the dynamic part of the received sensing context (e.g., position, state) and capture time.

[0060] For each object, the consolidated sensing context may be stored in the local database with the following information: source, object ID, time and other object-related sensing context. The source information may comprise the local IP address or the ID of the source network entity, or “all”, indicating that the consolidated sensing context comes from multiple sources. The object ID may differ depending on the source of the sensing context, such that the network entity is able to map the object ID of the same object processed by different network entities. An example of indication of the source of the consolidated sensing contextmay comprise, for example, an Object M point cloud part A / B from SCMF1 / SCMF2, and / or an Object M capture time X from SCMF1.

[0061] Region-of-interest (Rol) or region-based sensing context may be used in case of an overlapping sensing area, or objects which cannot easily been identified, have not been distinguished from each other, or have not been identified yet. A region of interest in 2D / 3D can be defined using mathematical expressions, or reference coordinates and a radius. Rol-based sensing context may have the following structure: region of interest 251, point cloud ID 252, capture time 253, associated sensing data (e.g., point cloud) 254. After receiving the Rol-based sensing context, the network entity may check whether there is a matching Rol from other sources. If there is a match, the network entity may perform merging or extension of the sensing context based on the capture time, prior to storing the sensing context as consolidated sensing context in the local base, similarly to the object-based sensing context procedure described above in relation to Figure 2a. The consolidated sensing context may use the same local point cloud ID 252 assigned by the network entity responsible for the consolidation. If the captured time is the same, the network entity may merge the sensing context. The sensing data information (e.g., the point cloud) may include consolidated sensing data from different network entities, or merged sensing data comprising the source information. If the capture time is different, the network entity may extend the sensing context (e.g., in the local database) of the Rol with received sensing data and the capture time.

[0062] For each Rol, the consolidated sensing context may be stored in the local database with the following information: source, Rol, time, context type, and other related sensing context (e.g., point cloud, point cloud ID). The source information may comprise a local IP address of the source network entity, or “all”, indicating that the consolidated sensing context comes from multiple sources. The point cloud ID 252 may differ depending on the source of the sensing context, such that the network entity is able to map the ID of the same point cloud from different network entities.

[0063] Figure 3 is a flow chart of a procedure for sensing context consolidation according to an example. Rol-based sensing context consolidation may be seen as the first step of object-based sensing context consolidation for an object that has not yet been identified. As such, the following description of object-based sensing context consolidation procedure also covers the case of Rol-based sensing context consolidation.

[0064] The sensing context consolidation at a network entity may comprise three phases, following the sensing data labelling phase as described before, or the context collection / sharing phase (which will be described in more detail further in the description). The context collection / sharing phase 301 may comprise receiving, by the network entity of the multiple first network entities, sensing context from other network entities.

[0065] During the context matching phase 302, the network entity may perform three steps to match the received context. At first, the network entity may check whether the object has already been identified. In other words, the network entity may check whether the received sensing context type is an object-based sensing context, as described above in relation to Figure 2a. If the object has not yet been identifier, the network entity may identify the region of interest and merge the point cloud / occupancy grid from different network entities.

[0066] The network entity may then identify the at least one object. The identification may be achieved by, for example, a trained object recognition model. The exact specifics of the implementation of the Al model are beyond the scope of this disclosure.

[0067] After identifying the object, the network entity may identify the same object from different network entities. This may be achieved, for example, by mapping the point-cloud data, and / or by matching the states of the object in the local database. Further details regarding how to map to an existing object - for example, using an object library - are beyond the scope of this disclosure.The context matching phase 302 may be based on proposed labels / data structures of the sensing context, described above in relation to Figures 2a and 2b. If the same object has been identified, the network entity may perform object ID pairing between various network entities.

[0068] Following the context matching phase 302, the context aggregation phase 303 may take place. During this phase, the network entity may merge or extend the sensing context per object / per Rol as described in relation to the context matching phase 302. If no objects are identified during the context aggregation phase 303, the phase may continue with the Rol-based sensing context aggregation. In contrast, if the same objects are identified as during the context matching phase 302, the context aggregation phase 303 may proceed with object-based sensing context aggregation. If new objects have been detected during the context matching phase 302, during the context aggregation phase 303, no sensing context aggregation may be performed.

[0069] Finally, during the database update phase 304, the network entity may update the local sensing context database per object / per Rol using the data structure described above. For new objects / new point cloud / new Rol, a new sensing context entry and a new local object / point cloud ID may be generated in the local database. For the same object / same point cloud / same Rol, the related sensing context entry may be updated with the consolidated sensing context.

[0070] After the sensing context consolidation, the network entity may send the sensing context (per Rol, per object or per point-cloud, consolidated or not consolidated) to other network entities, as described in more detail further in this specification.

[0071] Figure 4 is a schematic representation a first network entity and a second network entity for sensing context sharing according to an example. In particular, Figure 4 depicts a first network entity 401 of multiple first network entities, and a second network entity 402 of multiple first network entities. Firstly, the first network entity 401 may request or subscribe to sensing context of the second network entity 402 with an object sensing context (OSC) filter. The OSC may include the selected sensing context label information as described before (e.g., object class: UAV, type of the sensing context: Point cloud, Aol: 3D (Xmin, Xmax, Ymin, Ymax, Zmin, Zmax), etc. ) Based on sensing context label information in a local configuration, or OSC in the sensing context request / subscription from the first network entity 401, the second network entity 402 may indicate the sensed object(s) / available sensing context (e.g., class, ID, etc.), matching label to the first network entity 401. The first network entity 401 may then determine whether to request the sensing context of an object from the second network entity 402, and what to request (e.g., object ID, object class, context type). The first network entity 401 may send the sensing context request to the second network entity 402, indicating the object ID, context type, and / or context source. The second network entity 402 may provide the labelled sensing context to the first network entity 401 in response.

[0072] Based on the received sensing context, the first network entity 401 may identify whether there is a matched object locally. The first network entity 401 may generate a mapping of the local object ID to the object ID at the second network entity 402. If no object has been matched locally, the first network entity 401 may generate a new local object ID.

[0073] The first network entity 401 may then determine whether to extend the local sensing context, or whether to integrate all of the sensing context into a merged sensing context, and update the local database accordingly.

[0074] The first network entity 401 may then indicate the second network entity 402 on available sensing context to be shared, with the object ID and mapped object ID at the second network device 402. Ther same procedure applies in case the sensing context sharing is per Rol; however, the context labels will be different and additional steps during the contest match phase may be present.In some embodiments, based on configuration from OAM or mobility of an object, the second network entity 402 may trigger the sensing context transfer to the first network entity 401. The second network entity 402 may then provide structured sensing context to the first network entity 401.

[0075] Based on the received sensing context, the first network entity 401 may identify whether a matching object exists locally. In the case of a match, the first network entity 401 may generate a mapping between its local object identifier and the object identifier assigned by the second network entity 402. If no matching object exists locally, the first network entity 401 may generate a new local object identifier.

[0076] Thereafter, the first network entity 401 may determine whether to extend its local sensing context or to integrate all of the sensing context into a merged sensing context, and update its local database accordingly. Finally, the first network entity 401 may acknowledge the sensing context transfer to the second network entity 402 by providing the object identifier along with the mapped identifier.

[0077] The same procedure may be applied in the case of sensing context sharing based on a region of interest, wherein the context labels differ and additional steps in the context matching phase may be performed.

[0078] Figure 5 is a schematic representation of deployment of a network entity as part of SF / SE connected to 3GPP 5GC using SBI according to an example. In particular, Figure 5 illustrates a schematic representation of a network entity 501 implemented as part of a sensing function or sensing entity (SF / SE), connected to a 3GPP 5G core (5GC) via a service-based interface (SBI). The 5G Core may include various network functions such as:

[0079] • 502: NSSF (Network Slice Selection Function)

[0080] • 503: NEF (Network Exposure Function)

[0081] • 504: NRF (NF Repository Function)

[0082] • 505: PCF (Policy Control Function)

[0083] • 506: UDM (Unified Data Management)

[0084] • 507: AF (Application Function)

[0085] • 508: NWDAF (Network Data Analytics Function )

[0086] • 509: AMF (Access and Mobility Management Function)

[0087] • 510: SMF (Session Management Function)

[0088] In some embodiments, the SF / SE 501 may provide sensing services within a 5G mobile network by collecting and processing sensing data. The sensing data may be collected from 511 (R)AN ((Radio) Access Network), AF, NEF, UE, etc. The SF / SE 501 may be responsible for labelling the collected sensing data, managing and exchanging sensing context, including objectbased or region-based structured data, with other network entities. These other entities may include: other SF / SE instances, NWDAF, NEF, (R)AN

[0089] Figure 6 is a schematic representation of deployment of a network entity as part of a data storage function / entity in a mobile network using SBI, according to an example. In the figure, shown is a data provider 601, which may comprise a sensing function (SF), (R)AN or another network entity capable of supplying sensing context or related data. Also present are a data consumer 602, which may also comprise a SF, NWDAF or another network function requesting sensing context or related data. Data storage entities 603, 604 may comprise the network entity arranged to label, store and manage the sensing context. The figure shows that the data provider 601, the data consumer 602, and the data storage entities 603 and 604 may communicate using SBI in a mobile network.Figure 7 is a schematic representation of deployment of a network entity as one type of a data processing entity connected to a data plane / data bus in a 6G mobile network, according to an example. In the figure, shown is a data provider 701, which may comprise the SF, (R)AN or another network entity capable of supplying sensing context or related data. Also present is a data consumer 702, which may also comprise a SF, NWDAF or another network function requesting sensing context or related data. One or more data processing entities 703 are connected to a data plane / data bus 704 with multiple data storage 705 in a 6G mobile network. The data processing entity 703 may be arranged to label, store, and manage the sensing context, while the data provider 701 and the data consumer 702 may exchange data with the data processing entity 703 through the data plane / data bus 704.

[0090] Figure 8 is a schematic representation of an implementation of sensing context sharing in a hierarchical distributed architecture according to an example. Sensing context sharing may happen among the network entities at the same hierarchical level (e.g., neighbouring SFs - for example, neighbour SF 804 and neighbour SF 803), or between the network entities across different hierarchical levels. For example, a network entity at a higher hierarchical level (e.g., aggregate SF 801, sensing function 802) may manage the sensing context of a bigger sensing area / region, compared to the network entity at a lower hierarchical level (e.g., sensing function 805, sensing function 806). A network entity at the higher hierarchical level may manage the sensing context of multiple object classes (e.g., UAV, vehicle), or sensing context of multiple types (e.g., object-based, Rol-based), while the network entity at the lower hierarchical level may manage the sensing context of a single object class / context type.

[0091] Additionally, certain constraints may apply regarding the direction, source, or target of local or consolidated sensing context sharing. Such constraints may be motivated by security considerations or the need to maintain efficient sensing context management. They may be configured at the network entity providing the sensing context, at the network entity consuming the sensing context, or at a registry network function.

[0092] Figure 9 is a schematic representation of a general sensing context exposure and triggers according to an example. In some embodiments, sensing context may be exchanged through either active sharing or passive sharing.

[0093] In active sharing, also known as a “push” mode, a sensing context provider may proactively transmit certain types of sensing context to selected network entities. For example, an aggregate sensing function 901 or a sensing function 902 may push sensing context to neighbouring sensing functions 904 and 905. The decision to push may be based on factors such as network topology, infrastructure, the time or location of the sensing context, and the class or state (e.g., speed, direction) of the sensed objects.

[0094] Figure 10 is a schematic representation of passive context expo sure / expo sure based on a subscription or a request according to an example. Passive sharing may also be referred to as a “pull” mode, in contrast to the “push” mode described above.

[0095] In Figure 10, the sensing function 1001 may first register its supported context type (for example, object-based or region-based formats, point cloud, occupancy grid in two or three dimensions), object class, and service area with a registry 1002. This registration forms part of the network function or service profile. The request NF 1003 may then discover the appropriate sensing function via the registry 1002, select the desired sensing function based on the retrieved NF profile, and initiate a request or subscription for the sensing context. Operator policy may determine which sensing context can be discovered or requested by each request NF, as well as how it is exposed to each request NF, based on criteria including location, time, object class, object state, or sensing context type. Such operator policy may be configured at the sensing function 1001, the request NF 1003, or the service registry 1002 and be used during the registration, discovery and selection of the sensing function. Here, the request NF may be an example of sensing data consumer, and the sensing function may be an example of sensing data producer.Figures 1 la-11c are schematic representations of implementation options in a 3GPP architecture according to an example. In some embodiments, the SCMF may be implemented as part of core network functions - such as the SF, the network data analytics function (NWDAF), the network exposure function (NEF), or the unified data repository (UDR) - or within the radio access network (RAN) or as an application function (AF).

[0096] In one embodiment, illustrated in Figure 1 la, the SCMF is implemented as part of the sensing function, identified by reference numeral 1101. In this configuration, the SF 1101 aggregates sensing context from next-generation NodeBs (gNBs) 1102 and provides sensing services to other network functions.

[0097] In another embodiment, depicted in Figure 1 lb, the SCMF is implemented within the NWDAF, identified by reference numeral 1201. Here, the NWDAF 1201 collects sensing context from various SFs 1202, for instance, to train an object recognition machine learning model.

[0098] In a further embodiment, shown in F igure 11 c, the SCMF is integrated into the NEF 1301. In this case, the NEF 1301 aggregates sensing context from distributed SFs 1302 and exposes the consolidated context to external applications.

[0099] Depending on the specific implementation, the interface and protocols used for communication between SCMFs may differ -for example, the Xn interface, the NG interface, or service-based interfaces - while the underlying information elements exchanged remain consistent.

[0100] Figure 12 is a schematic representation of an apparatus according to an example. The apparatus 1200 for distributed sensing contest management in a network comprises a receiver 1201 arranged to receive sensing data, the sensing data received locally at the receiver or received from one or more network entities. The apparatus 1200 comprises a labeller 1202 configured to label the sensing data as sensing context according to a data structure comprising one of an object-based structured data format and a region-based structured data format. The object-based structured data format comprises an object identifier, object position, capture time, associated sensing data and optionally object state and object class information. The region-based structured data format comprises a region of interest, a point cloud identifier, capture time and associated sensing data. The apparatus 1200 further comprises an exchanger 1203 configured to exchange the sensing context with one or more network entities based on a predetermined triggering mechanism. In other words, the apparatus 1200 is arranged to perform the method described above in relation to Figures 1-11.

[0101] Advantageously, the method and apparatuses described herein provide a unified method for labelling sensing data and / or context within a distributed network. By defining an object-based data structure that includes information such as an object identifier, object position, capture time, associated sensing data, and optional object state and object class information — and a region-based data structure that encompasses a region of interest, a sensing data set identifier, capture time, and associated sensing data — the invention enables accurate identification and discovery of object-related sensing context. This structured approach facilitates consistent and efficient management of sensing data and / or sensing context across distributed network entities.

[0102] Furthermore, the invention enables a robust consolidation process for sensing context management. Through a three-phase consolidation procedure that involves identifying objects, and matching received / derived sensing context based on proposed data structure (such as object class, state, region of interest, and capture time), and then merging or extending the context accordingly, the invention permits the mapping of local object or point cloud identifiers between different network entities. This process enriches the locally stored context while simultaneously reducing data duplication. As a result, the sensing system can benefit from reduced data processing overhead and lower latency in delivering accurate sensing results.Additionally, the invention also support selective and on-demand context sharing based on a service-based architecture (SBA) principle and the proposed data structure. The invention details procedures for context discovery, selection, exposure, and exchange that may be adapted to various deployment scenarios, such as flat, hierarchical, or hybrid networks. Operator policies may be implemented to determine which sensing context information can be exposed or requested — based on criteria such as location, time, object class, object state, or context type — thus further reducing signalling overhead and enabling more efficient and secure sensing context management across the network.

[0103] According to an example, machine-readable instructions can be loaded onto a computer or other programmable data processing devices, so that the computer or other programmable data processing devices perform a series of operations to produce computer-implemented processing, thus the instructions executed on the computer or other programmable devices provide an operation for realizing functions specified by flow(s) in the flow charts and / or block(s) in the block diagrams.

[0104] Further, the teachings herein may be implemented in the form of a computer or software product, such as a non-transitory machine-readable storage medium, the computer software or product being stored in a storage medium and comprising a plurality of instructions, e.g., machine readable instructions, for making a computer device implement the methods recited in the examples of the present disclosure.

[0105] In some examples, some methods can be performed in a cloud-computing or network-based environment. Cloud-computing environments may provide various services and applications via the Internet. These cloud-based services (e.g., software as a service, platform as a service, infrastructure as a service, etc.) may be accessible through a web browser or other remote interface of the user equipment for example. Various functions described herein may be provided through a remote desktop environment or any other cloud-based computing environment.

[0106] While various embodiments have been described and / or illustrated herein in the context of fully functional computing systems, one or more of these exemplary embodiments may be distributed as a program product in a variety of forms, regardless of the particular type of computer-readable-storage media used to actually carry out the distribution. The embodiments disclosed herein may also be implemented using software modules that perform certain tasks. These software modules may include script, batch, or other executable files that may be stored on a computer-readable storage medium or in a computing system. In some embodiments, these software modules may configure a computing system to perform one or more of the exemplary embodiments disclosed herein. In addition, one or more of the modules described herein may transform data, physical devices, and / or representations of physical devices from one form to another.

[0107] The preceding description has been provided to enable others skilled in the art to best utilize various aspects of the exemplary embodiments disclosed herein. This exemplary description is not intended to be exhaustive or to be limited to any precise form disclosed. Many modifications and variations are possible without departing from the spirit and scope of the instant disclosure. The embodiments disclosed herein should be considered in all respects illustrative and not restrictive. Reference should be made to the appended claims and their equivalents in determining the scope of the instant disclosure.

Claims

CLAIMS1. A method for distributed sensing context management in a network, the method comprising:receiving, at a network entity of multiple first entities, sensing data locally from the network entity of the multiple first entities or from one or more network entities of multiple second entities (101);labelling the sensing data as sensing context according to a data structure comprising one of an objectbased structured data format and a region-based structured data format, the object-based structured data format comprising an object identifier, object position, capture time, associated sensing data and optionally object state and object class information, and the region-based structured data format comprising a region of interest, a sensing data set identifier, capture time and associated sensing data (102); andexchanging the sensing context with one or more of the network entities of the multiple first entities based on a triggering mechanism (103).

2. The method of claim 1, wherein labelling the sensing data (102) further comprises assigning a local object identifier or a local sensing data set identifier for the sensing context.

3. The method of claim 1 or 2, further comprising:consolidating the sensing context, whereby to obtain consolidated sensing context, wherein consolidating the sensing context comprises at least one of matching, merging, and extending of the sensing context based on the capture time and corresponding labels,wherein exchanging the sensing context with one or more of the network entities of the multiple first network entities (103) comprises exchanging the consolidated sensing context.

4. The method of claim 3, wherein matching the sensing context comprises matching received sensing context based on at least one of object class, object position, object states, region of interest and capture time.

5. The method of claim 3 or 4, wherein consolidating the sensing context comprises merging the sensing context when a capture time is identical and extending the sensing context when a capture time is different.

6. The method of any one of claims 1 to 5, wherein exchanging the sensing context (103) comprises active sharing or passive sharing of the sensing context with the one or more of the network entities of the multiple first entities.

7. The method of claim 6, wherein the passive sharing of the sensing context comprises at least one of registering sensing context at a repository function, discovering sensing context via a repository function, receiving a request or subscription for sensing context sharing, and sending a request or subscription for sensing context sharing.

8. The method of any one of claims 1 to 7, wherein exchanging the sensing context (103) is based on exchange criteria comprising: a sensing context type, labels, network topology / infrastructure, time, or location.

9. The method of any one of claims 1 to 8, further comprising updating a local sensing context database with the sensing context including mapping of object identifiers received from different network entities of the first network entitiesor the second network entities, wherein the local sensing context database further records source information indicative of origin of the sensing context.

10. The method of any one of claims 1 to 9, wherein the method is implemented in a distributed sensing system comprising a plurality of sensing nodes, sensing functions and / or a plurality of sensing data storage entities interconnected via a network interface.

11. An apparatus (1200) for distributed sensing context management in a network, the apparatus (1200) comprising:a receiver (1201) configured to receive sensing data, the sensing data received locally at the receiver (1201) or received from one or more network entities;a labeller (1202) configured to label the sensing data as sensing context according to a data structure comprising one of an object-based structured data format and a region-based structured data format, the object-based structured data format comprising an object identifier, object position, capture time, associated sensing data and optionally object state and object class information, and the region-based structured data format comprising a region of interest, a sensing data set identifier, capture time and associated sensing data;and an exchanger (1203) configured to exchange the sensing context with one or more network entities based on a predetermined triggering mechanism.

12. The apparatus (1200) of claim 11, further comprising a mapping unit configured to assign a local object identifier or a local sensing data set identifier for the sensing context.

13. The apparatus (1200) of claim 11, further comprising a consolidator configured to consolidate sensing context received from one or more network entities by performing matching, merging and extending of the sensing context based on the capture time and corresponding labels.

14. The apparatus (1200) of claim 13, wherein the consolidator is configured to merge the sensing context when the capture time is identical and to extend the sensing context when the capture time is different.

15. A non-transitory computer-readable medium storing instructions which, when executed by a processor, cause the processor to perform a method for distributed sensing context management, the method comprising:receiving, at a network entity of multiple first entities, sensing data locally from the network entity of the multiple first entities or from one or more network entities of multiple second entities;labelling the sensing data as sensing context according to a data structure comprising one of an objectbased structured data format and a region-based structured data format, the object-based structured data format comprising an object identifier, object position, capture time, associated sensing data and optionally object state and object class information, and the region-based structured data format comprising a region of interest, a sensing data set identifier, capture time and associated sensing data; andexchanging the sensing context with one or more network entities of the multiple first network entities based on a predetermined triggering mechanism.

Images