Method and apparatus for supporting real-time data sharing for improving mutual decision-making for a group of autonomous or semi-autonomous robots with communication capability in a wireless communication system

Abstract

　The present disclosure relates to a wireless communication system. Specifically, the present disclosure relates to a method and an apparatus for supporting real-time data sharing for improving mutual decision-making for a group of autonomous or semi-autonomous robots with communication capabilities in a wireless communication system, wherein the method performed by a first node comprises: receiving, from a second node, a first data sharing request including a data sharing scope; determining a collaborative awareness benefit based on the first data sharing request; and transmitting, to the second node, a response message to the first data sharing request based on the collaborative awareness benefit.

Description

METHOD AND APPARATUS FOR SUPPORTING REAL-TIME DATA SHARING FOR IMPROVING MUTUAL DECISION-MAKING FOR A GROUP OF AUTONOMOUS OR SEMI-AUTONOMOUS ROBOTS WITH COMMUNICATION CAPABILITY IN A WIRELESS COMMUNICATION SYSTEM

[0001] The present disclosure relates to a wireless communication system. Specifically, the present disclosure relates to method and apparatus for supporting real-time data sharing for improving mutual decision-making for a group of autonomous or semi-autonomous robots with communication capability in a wireless communication system.

[0002]

[0003] In a high-demand warehouse setting, a fleet of autonomous mobile robots (AMRs) operates collectively to handle complex tasks such as inventory retrieval, sorting, and material transport. These robots rely on collaborative decision-making enabled by real-time data exchange and processing to optimize efficiency, avoid obstacles, and manage potential conflicts in task priority or navigation. Each robot is equipped with sensors (e.g., LIDAR, cameras) and onboard processing power to sense its surroundings and determine its actions. However, the efficiency of the fleet depends on the robots' ability to share data and make decisions collectively, with guidance from a central fleet management system that coordinates their individual tasks based on warehouse conditions, task priorities, and the real-time location of each robot. Recently, the expected benefits of "data and AI sharing" was addressed with the focus on an interesting concept of "Delta Sharing", which is supposedly an open standard for secure sharing of data and AI assets in digital economy. Along with philosophy laid behind the concept, it would be a great benefit for the telecom industry verticals to consider diverse applications of the concept of "sharing of data and AI (or AI assets)" among a group of autonomous robots.

[0004]

[0005] In order to solve the above-described problems, the present disclosure provides method and apparatus for supporting real-time data sharing for improving mutual decision-making for a group of autonomous or semi-autonomous robots with communication capability in a wireless communication system.

[0006] The technical objects to be achieved by the present disclosure are not limited to those that have been described hereinabove merely by way of example, and other technical objects that are not mentioned can be clearly understood by those skilled in the art, to which the present disclosure pertains, from the following descriptions.

[0007]

[0008] According to various embodiments of the present disclosure, there is provided a method performed by a first node, comprising: receiving, from a second node, a first data sharing request including a data sharing scope; determining a collaborative awareness benefit based on the first data sharing request; and transmitting, to the second node, a response message to the first data sharing request based on the collaborative awareness benefit.

[0009] According to various embodiments of the present disclosure, there is provided a method performed by a second node, comprising: transmitting, to a first node, a first data sharing request including a data sharing scope; and receiving, from the first node, a response message to the first data sharing request based on a collaborative awareness benefit related to the first data sharing request.

[0010] According to various embodiments of the present disclosure, there is provided a first node in a wireless communication system, the first node comprising a transceiver, at least one processor, and at least one memory operably connectable to the at least one processor and storing instructions performing operations based on being executed by the at least one processor, and the operations comprise all steps of a method of operating the first node according to various embodiments of the present disclosure.

[0011] According to various embodiments of the present disclosure, there is provided a second node in a wireless communication system, the second node comprising a transceiver, at least one processor, and at least one memory operably connectable to the at least one processor and storing instructions performing operations based on being executed by the at least one processor, and the operations comprise all steps of a method of operating the second node according to various embodiments of the present disclosure.

[0012] According to various embodiments of the present disclosure, there is provided a control device controlling a first node in a wireless communication system, the control device comprising at least one processor and at least one memory operably connected to the at least one processor, and the at least one memory stores instructions performing operations based on being executed by the at least one processor, and the operations comprise all steps of a method of operating the first node according to various embodiments of the present disclosure.

[0013] According to various embodiments of the present disclosure, there is provided a control device controlling a second node in a wireless communication system, the control device comprising at least one processor and at least one memory operably connected to the at least one processor, and the at least one memory stores instructions performing operations based on being executed by the at least one processor, and the operations comprise all steps of a method of operating the second node according to various embodiments of the present disclosure.

[0014] According to various embodiments of the present disclosure, there are provided one or more non-transitory computer readable mediums storing one or more instructions, and the one or more instructions perform operations based on being executed by one or more processors, and the operations comprise all steps of a method of operating a first node according to various embodiments of the present disclosure.

[0015] According to various embodiments of the present disclosure, there are provided one or more non-transitory computer readable mediums storing one or more instructions, and the one or more instructions perform operations based on being executed by one or more processors, and the operations comprise all steps of a method of operating the second node according to various embodiments of the present disclosure.

[0016]

[0017] In order to solve the above-described problems, the present disclosure can provide method and apparatus for supporting real-time data sharing for improving mutual decision-making for a group of autonomous or semi-autonomous robots with communication capability in a wireless communication system.

[0018]

[0019] The accompanying drawings, which are included to provide a further understanding of the present disclosure and constitute a part of the detailed description, illustrate embodiments of the present disclosure and serve to explain technical features of the present disclosure together with the description. Technical features of the present disclosure are not limited to specific drawings, and features disclosed in each drawing can be combined with each other to form a new embodiment. Reference numerals in each drawing may denote structural elements.

[0020] FIG. 1 illustrates physical channels used in a system applicable to the present disclosure and an example of a general signal transmission method using the physical channels.

[0021] FIG. 2 illustrates an example of a structure of a radio frame used in a system applicable to the present disclosure.

[0022] FIG. 3 illustrates an example of a slot structure used in a system applicable to the present disclosure.

[0023] FIG. 4 illustrates an example of a slot structure of a radio frame used in a system applicable to the present disclosure.

[0024] FIG. 5 illustrates a data flow example in the 3GPP NR system.

[0025] FIG. 6 illustrates an example of the overall architecture of an NG-RAN to which technical features of the present disclosure can be applied.

[0026] FIG. 7 illustrates an interface protocol structure for F1-C to which technical features of the present disclosure can be applied.

[0027] FIG. 8 illustrates High-demand complex warehouse with multiple zones served by different NPNs (non-public networks).

[0028] FIG. 9 illustrates a proposed method of the present disclosure.

[0029] FIG. 10 illustrates an example of a process of operating a first device in a system applicable to the present disclosure.

[0030] FIG. 11 illustrates an example of a process of operating a second device in a system applicable to the present disclosure.

[0031] FIG. 12 illustrates an example of a structure of a first device and a second device in a system applicable to the present disclosure.

[0032]

[0033] In various embodiments of the present disclosure, "A or B" may mean "only A," "only B" or "both A and B." In other words, in various embodiments of the present disclosure, "A or B" may be interpreted as "A and / or B." For example, in various embodiments of the present disclosure, "A, B or C" may mean "only A," "only B," "only C" or "any combination of A, B and C."

[0034] A slash ( / ) or comma used in various embodiments of the present disclosure may mean "and / or." For example, "A / B" may mean "A and / or B." Hence, "A / B" may mean "only A," "only B" or "both A and B." For example, "A, B, C" may mean "A, B, or C."

[0035] In various embodiments of the present disclosure, "at least one of A and B" may mean "only A," "only B" or "both A and B." In addition, in various embodiments of the present disclosure, the expression of "at least one of A or B" or "at least one of A and / or B" may be interpreted in the same meaning as "at least one of A and B."

[0036] Further, in various embodiments of the present disclosure, "at least one of A, B, and C" may mean "only A," "only B," "only C" or "any combination of A, B and C." In addition, "at least one of A, B or C" or "at least one of A, B and / or C" may mean "at least one of A, B, and C."

[0037] Further, parentheses used in various embodiments of the present disclosure may mean "for example." Specifically, when "control information (PDCCH)" is described, "PDCCH" may be proposed as an example of "control information." In other words, "control information" in various embodiments of the present disclosure is not limited to "PDCCH," and "PDDCH" may be proposed as an example of "control information." In addition, even when "control information (i.e., PDCCH)" is described, "PDCCH" may be proposed as an example of "control information."

[0038] Technical features described individually in one drawing in various embodiments of the present disclosure may be implemented individually or simultaneously.

[0039] General Signal Transmission Method in 3GPP

[0040] Physical Channels and General Signal Transmission

[0041] FIG. 1 illustrates physical channels used in a system applicable to the present disclosure and an example of a general signal transmission method using the physical channels. More specifically, FIG. 1 illustrates physical channels and general signal transmission used in the 3GPP system.

[0042] FIG. 1 illustrates physical channels and general signal transmission used in the 3GPP system. In a wireless communication system, the UE receives information from the eNB through Downlink (DL) and the UE transmits information from the eNB through Uplink (UL). The information which the eNB and the UE transmit and receive includes data and various control information and there are various physical channels according to a type / use of the information which the eNB and the UE transmit and receive.

[0043] A UE that is powered on again while being powered off or enters a new cell performs an initial cell search operation such as synchronizing with a base station (BS) in S11. To this end, the UE receives a primary synchronization channel (PSCH) and a secondary synchronization channel (SSCH) from the base station to synchronize with the base station and acquires information such as a cell identity (ID), etc. Further, the UE may receive a physical broadcast channel (PBCH) from the base station and acquire in-cell broadcast information. The UE may receive a downlink reference signal (DL RS) in an initial cell search step to check a downlink channel state.

[0044] The UE that completes the initial cell search may receive a physical downlink control channel (PDCCH) and a physical downlink shared channel (PDSCH) corresponding to the PDCCH to acquire more detailed system information, in S12.

[0045] Next, the UE may perform a random access procedure in order to complete an access to the base station, in S13 to S16. Specifically, the UE may transmit a preamble on a physical random access channel (PRACH) in S13, and receive a random access response (RAR) for the preamble on the PDCCH and the PDSCH corresponding to the PDCCH in S14. Thereafter, the UE may transmit a physical uplink shared channel (PUSCH) using scheduling information within the RAR in S15, and perform a contention resolution procedure such as the PDCCH and the PDSCH corresponding to the PDCCH in S16.

[0046] Next, the UE that performs the above-described procedure may perform PDCCH / PDSCH reception S17 and PUSCH / physical uplink control channel (PUCCH) transmission S18, as a general uplink / downlink signal transmission procedure. Control information that the UE transmits to the base station is referred to as uplink control information (UCI). The UCI includes hybrid automatic repeat and request (HARQ) acknowledgement / negative ACK (ACK / NACK), scheduling request (SR), channel state information (CSI), etc. The CSI includes a channel quality indication (CQI), a precoding matrix indicator (PMI), a rank indicator (RI), etc. The UCI is generally transmitted on the PUCCH, but if control information and data need to be transmitted at the same time, the UCI may be transmitted on the PUSCH. The UE may aperiodically transmit the UCI on the PUSCH based on a request / indication of the network.

[0047] Orthogonal Frequency Division Multiplexing (OFDM) Numerology

[0048] A new RAT system uses an OFDM transmission scheme or a similar transmission scheme thereto. The new RAT system may follow different OFDM parameters from OFDM parameters of LTE. Alternatively, the new RAT system may follow numerology of existing LTE / LTE-A as it is but have a larger system bandwidth (e.g., 100 MHz). Alternatively, one cell may support a plurality of numerologies. In other words, UEs that operate with different numerologies may coexist in one cell.

[0049] Radio Frame Structure

[0050] FIG. 2 illustrates an example of a structure of a radio frame used in a system applicable to the present disclosure.

[0051] In NR, uplink and downlink transmission consists of frames. A radio frame has a length of 10 ms and is defined as two 5 ms half-frames (HFs). The half-frame is defined as five 1 ms subframes (SFs). The subframe is split into one or more slots, and the number of slots in the subframe depends on a subcarrier spacing (SCS). Each slot includes 12 or 14 OFDM(A) symbols depending on a cyclic prefix (CP). When a normal CP is used, each slot includes 14 symbols. When an extended CP is used, each slot includes 12 symbols. The symbol may include an OFDM symbol (or CP-OFDM symbol) and an SC-FDMA symbol (or DFT-s-OFDM symbol).

[0052] Table 1 shows that when the normal CP is used, the number of symbols per slot, the number of slots per frame, and the number of slots per subframe vary depending on the SCS.

[0053] SCS (15*2^u)NslotsymbNframe,uslotNsubframe,uslot15KHz (u=0)1410130KHz (u=1)1420260KHz (u=2)14404120KHz (u=3)14808240KHz (u=4)1416016

[0054] Nslotsymbis the number of symbols in the slot. Nframe,uslotis the number of slots in the frame. Nsubframe,uslotis the number of slots in the subframe.

[0055] Table 2 shows that when the extended CP is used, the number of symbols per slot, the number of slots per frame, and the number of slots per subframe vary depending on the SCS.

[0056] SCS (15*2^u)NslotsymbNframe,uslotNsubframe,uslot60KHz (u=2)12404

[0057] The NR supports multiple numerologies (or subcarrier spacing (SCS)) for supporting diverse 5G services. For example, when the SCS is 15 kHz, a wide area in traditional cellular bands is supported, when the SCS is 30 kHz / 60 kHz, dense-urban, lower latency, and wider carrier bandwidth are supported, and when the SCS is 60 kHz or more, a bandwidth larger than 24.25 GHz is supported to overcome phase noise. An NR frequency band may be defined as two types of frequency ranges (FR1 and FR2). Values of the frequency ranges may be changed, and, for example, the two types of frequency ranges (FR1 and FR2) may be as shown in Table 3 below. For convenience of description, among frequency ranges used in an NR system, FR1 may denote "sub 6GHz range", and FR2 may denote "above 6GHz range" and may be referred to as millimeter wave (mmW).

[0058] Frequency Range DesignationCorresponding Frequency RangeSubcarrier SpacingFR1450MHz - 6000MHz15, 30, 60kHzFR224250MHz - 52600MHz60, 120, 240kHz

[0059] As described above, the values of the frequency ranges in the NR system may be changed. For example, FR1 may include a frequency band from 410 MHz to 7125 MHz, as shown in Table 4 below. That is, FR1 may include a frequency band of 6 GHz (or 5850, 5900, 5925 MHz, etc.) or higher. For example, the frequency band of 6 GHz (or 5850, 5900, 5925 MHz, etc.) or higher included in FR1 mat include an unlicensed band. The unlicensed band may be used for diverse purposes, for example, used for communication for vehicles (e.g., self-driving).

[0060] Frequency Range DesignationCorresponding Frequency RangeSubcarrier SpacingFR1410MHz - 7125MHz15, 30, 60kHzFR224250MHz - 52600MHz60, 120, 240kHz

[0061] In the NR system, OFDM(A) numerology (e.g., SCS, CP length, etc.) may be differently configured between a plurality of cells merged into one UE. Hence, an (absolute time) duration of a time resource (e.g., SF, slot or TTI) (for convenience, collectively referred to as a time unit (TU)) consisting of the same number of symbols may be configured differently between the merged cells. FIG. 3 illustrates an example of a slot structure used in a system applicable to the present disclosure.

[0062] A slot includes a plurality of symbols in a time domain. For example, one slot includes 7 symbols in a normal CP, while one slot includes 6 symbols in an extended CP. A carrier includes a plurality of subcarriers in a frequency domain. A resource block (RB) is defined as a plurality of (e.g., 12) consecutive subcarriers in the frequency domain. A bandwidth part (BWP) is defined as a plurality of consecutive (P)RBs in the frequency domain and may correspond to one numerology (e.g., SCS, CP length, etc.). The carrier may include up to N (e.g., 5) BWPs. The data communication may be performed through an activated BWP, and only one BWP may be activated in one UE. In a resource grid, each element is referred to as a resource element (RE), and one complex symbol may be mapped to each RE.

[0063] FIG. 4 illustrates an example of a slot structure of a radio frame used in a system applicable to the present disclosure.

[0064] More specifically, FIG. 4 illustrates a slot structure of a frame of the NR system as an exemplary system.

[0065] As illustrated in FIG. 4, a frame structure of NR is characterized by a self-contained structure in which all of DL control channel, DL or UL data, UL control channel, etc. can be included in one slot. In this instance, DL data scheduling information, UL data scheduling information, etc. may be transmitted on the DL control channel, and ACK / NACK information for DL data, CSI information (modulation and coding scheme information, MIMO transmission related information, etc.), scheduling request, etc. may be transmitted on the UL control channel. In FIG. 4, a time gap for DL-to-UL or UL-to-DL switching may exist between a control region and a data region. Further, a part of the DL control channel / DL data / UL data / UL control channel may not be configured within one slot. Alternatively, order of the channels constituting one slot may vary. (e.g., DL control / DL data / UL control / UL data or UL control / UL data / DL control / DL data, etc.)

[0066] BACKGROUND

[0067] FIG. 5 illustrates a data flow example in the 3GPP NR system.

[0068] In FIG. 5, "RB" denotes a radio bearer, and "H" denotes a header. Radio bearers are categorized into two groups: data radio bearers (DRB) for user plane data and signalling radio bearers (SRB) for control plane data. The MAC PDU is transmitted / received using radio resources through the PHY layer to / from an external device. The MAC PDU arrives to the PHY layer in the form of a transport block.

[0069] In the PHY layer, the uplink transport channels UL-SCH and RACH are mapped to their physical channels PUSCH and PRACH, respectively, and the downlink transport channels DL-SCH, BCH and PCH are mapped to PDSCH, PBCH and PDSCH, respectively. In the PHY layer, uplink control information (UCI) is mapped to PUCCH, and downlink control information (DCI) is mapped to PDCCH. A MAC PDU related to UL-SCH is transmitted by a UE via a PUSCH based on an UL grant, and a MAC PDU related to DL-SCH is transmitted by a BS via a PDSCH based on a DL assignment.

[0070] FIG. 6 illustrates an example of the overall architecture of an NG-RAN to which technical features of the present disclosure can be applied.

[0071] Referring to FIG. 6, a gNB may include a gNB-CU (hereinafter, gNB-CU may be simply referred to as CU) and at least one gNB-DU (hereinafter, gNB-DU may be simply referred to as DU).

[0072] The gNB-CU is a logical node hosting RRC, SDAP and PDCP protocols of the gNB or an RRC and PDCP protocols of the en-gNB. The gNB-CU controls the operation of the at least one gNB-DU.

[0073] The gNB-DU is a logical node hosting RLC, MAC, and physical layers of the gNB or the en-gNB. The operation of the gNB-DU is partly controlled by the gNB-CU. One gNB-DU supports one or multiple cells. One cell is supported by only one gNB-DU.

[0074] The gNB-CU and gNB-DU are connected via an F1 interface. The gNB-CU terminates the F1 interface connected to the gNB-DU. The gNB-DU terminates the F1 interface connected to the gNB-CU. One gNB-DU is connected to only one gNB-CU. However, the gNB-DU may be connected to multiple gNB-CUs by appropriate implementation. The F1 interface is a logical interface. For NG-RAN, the NG and Xn-C interfaces for a gNB consisting of a gNB-CU and gNB-DUs, terminate in the gNB-CU. For E-UTRAN-NR dual connectivity (EN-DC), the S1-U and X2-C interfaces for a gNB consisting of a gNB-CU and gNB-DUs, terminate in the gNB-CU. The gNB-CU and connected gNB-DUs are only visible to other gNBs and the 5GC as a gNB.

[0075] Functions of the F1 interface includes F1 control (F1-C) functions as follows.

[0076] (1) F1 interface management function

[0077] The error indication function is used by the gNB-DU or gNB-CU to indicate to the gNB-CU or gNB-DU that an error has occurred.

[0078] The reset function is used to initialize the peer entity after node setup and after a failure event occurred. This procedure can be used by both the gNB-DU and the gNB-CU.

[0079] The F1 setup function allows to exchange application level data needed for the gNB-DU and gNB-CU to interoperate correctly on the F1 interface. The F1 setup is initiated by the gNB-DU.

[0080] The gNB-CU configuration update and gNB-DU configuration update functions allow to update application level configuration data needed between gNB-CU and gNB-DU to interoperate correctly over the F1 interface, and may activate or deactivate cells.

[0081] The F1 setup and gNB-DU configuration update functions allow to inform the single network slice selection assistance information (S-NSSAI) supported by the gNB-DU.

[0082] The F1 resource coordination function is used to transfer information about frequency resource sharing between gNB-CU and gNB-DU.

[0083] (2) System Information management function

[0084] Scheduling of system broadcast information is carried out in the gNB-DU. The gNB-DU is responsible for transmitting the system information according to the scheduling parameters available.

[0085] The gNB-DU is responsible for the encoding of NR master information block (MIB). In case broadcast of system information block type-1 (SIB1) and other SI messages is needed, the gNB-DU is responsible for the encoding of SIB1 and the gNB-CU is responsible for the encoding of other SI messages.

[0086] (3) F1 UE context management function

[0087] The F1 UE context management function supports the establishment and modification of the necessary overall UE context.

[0088] The establishment of the F1 UE context is initiated by the gNB-CU and accepted or rejected by the gNB-DU based on admission control criteria (e.g., resource not available).

[0089] The modification of the F1 UE context can be initiated by either gNB-CU or gNB-DU. The receiving node can accept or reject the modification. The F1 UE context management function also supports the release of the context previously established in the gNB-DU. The release of the context is triggered by the gNB-CU either directly or following a request received from the gNB-DU. The gNB-CU request the gNB-DU to release the UE Context when the UE enters RRC_IDLE or RRC_INACTIVE.

[0090] This function can be also used to manage DRBs and SRBs, i.e., establishing, modifying and releasing DRB and SRB resources. The establishment and modification of DRB resources are triggered by the gNB-CU and accepted / rejected by the gNB-DU based on resource reservation information and QoS information to be provided to the gNB-DU. For each DRB to be setup or modified, the S-NSSAI may be provided by gNB-CU to the gNB-DU in the UE context setup procedure and the UE context modification procedure.

[0091] The mapping between QoS flows and radio bearers is performed by gNB-CU and the granularity of bearer related management over F1 is radio bearer level. For NG-RAN, the gNB-CU provides an aggregated DRB QoS profile and QoS flow profile to the gNB-DU, and the gNB-DU either accepts the request or rejects it with appropriate cause value. To support packet duplication for intra-gNB-DU carrier aggregation (CA), one data radio bearer should be configured with two GPRS tunneling protocol (GTP)-U tunnels between gNB-CU and a gNB-DU.

[0092] With this function, gNB-CU requests the gNB-DU to setup or change of the special cell (SpCell) for the UE, and the gNB-DU either accepts or rejects the request with appropriate cause value.

[0093] With this function, the gNB-CU requests the setup of the secondary cell(s) (SCell(s)) at the gNB-DU side, and the gNB-DU accepts all, some or none of the SCell(s) and replies to the gNB-CU. The gNB-CU requests the removal of the SCell(s) for the UE.

[0094] (4) RRC message transfer function

[0095] This function allows to transfer RRC messages between gNB-CU and gNB-DU. RRC messages are transferred over F1-C. The gNB-CU is responsible for the encoding of the dedicated RRC message with assistance information provided by gNB-DU.

[0096] (5) Paging function

[0097] The gNB-DU is responsible for transmitting the paging information according to the scheduling parameters provided.

[0098] The gNB-CU provides paging information to enable the gNB-DU to calculate the exact paging occasion (PO) and paging frame (PF). The gNB-CU determines the paging assignment (PA). The gNB-DU consolidates all the paging records for a particular PO, PF and PA, and encodes the final RRC message and broadcasts the paging message on the respective PO, PF in the PA.

[0099] (6) Warning messages information transfer function

[0100] This function allows to cooperate with the warning message transmission procedures over NG interface. The gNB-CU is responsible for encoding the warning related SI message and sending it together with other warning related information for the gNB-DU to broadcast over the radio interface.

[0101] FIG. 7 illustrates an interface protocol structure for F1-C to which technical features of the present disclosure can be applied.

[0102] A transport network layer (TNL) is based on Internet protocol (IP) transport, comprising a stream control transmission protocol (SCTP) layer on top of the IP layer. An application layer signaling protocol is referred to as an F1 application protocol (E1AP).

[0103] PROBLEM DESCRIPTION

[0104] 1. Description

[0105] In a high-demand warehouse setting, a fleet of autonomous mobile robots (AMRs) operates collectively to handle complex tasks such as inventory retrieval, sorting, and material transport. These robots rely on collaborative decision-making enabled by real-time data exchange and processing to optimize efficiency, avoid obstacles, and manage potential conflicts in task priority or navigation. Each robot is equipped with sensors (e.g., LIDAR, cameras) and onboard processing power to sense its surroundings and determine its actions. However, the efficiency of the fleet depends on the robots' ability to share data and make decisions collectively, with guidance from a central fleet management system that coordinates their individual tasks based on warehouse conditions, task priorities, and the real-time location of each robot. Recently, the expected benefits of "data and AI sharing" was addressed with the focus on an interesting concept of "Delta Sharing", which is supposedly an open standard for secure sharing of data and AI assets in digital economy. Along with philosophy laid behind the concept, it would be a great benefit for the telecom industry verticals to consider diverse applications of the concept of "sharing of data and AI (or AI assets)" among a group of autonomous robots.

[0106] FIG. 8 illustrates High-demand complex warehouse with multiple zones served by different NPNs (non-public networks).

[0107] Zone 1 and Zone 2 are places where each site is shared by AMRs and human works, respectively. Zone 3 is shared by different types of AMRs but not by human workers. Zone 1 is served by NPN1 whereas Zone 2 and Zone 3 are served by NPN2. The allowed limits of maneuvering speed vary depending on which zone the AMR comes from, which zone the AMR plan to go to, what role the AMR is undertaking (e.g., heavy load of items) and so on.

[0108] 2. Pre-conditions

[0109] (1) The warehouse is equipped with a dedicated network that enables low-latency data sharing among robots and between the robots and the edge servers. FIG. 8 for the network coverage plans. Each NPN has one or more edge servers sufficient to support the users (UE's) dwelling in each coverage areas at any given time. Zone 1 and Zone 2 are places where each site is shared by AMRs and human workers, respectively. Zone 3 is shared by different types of AMRs but not by human workers. Zone 1 is served by NPN1 whereas Zone 2 and Zone 3 are served by NPN2. When two or more AMRs served by one or two different NPNs need to use the shared road, they share collaborative awareness data to mutually help each other in that shared area.

[0110] (2) Each AMR (UE) has multi-modal sensors, such as 3GPP sensing modules, LIDAR, cameras, and ultrasonic sensors, for obstacle detection and environment mapping. They also have antennas compatible with the warehouse's high-speed, low-latency wireless communication network.

[0111] (3) The edge servers process large volumes of data and facilitate real-time decision-making for collaboration among multiple AMRs.

[0112] (4) There is no central coordination system; instead, the edge servers put necessary sub-tasks in the common bulletin boards so that different participating AMRs can collaboratively volunteer to take some of those posted sub-tasks.

[0113] (5) Each AMR is fully charged, calibrated, and assigned an initial set of tasks by the fleet management system. It is pre-configured to autonomously assess its battery status, task completion level, and current location in real-time.

[0114] (6) The warehouse layout includes common areas, narrow aisles, and designated docking or charging stations. Certain areas may have higher traffic or more obstacles depending on the time of day and operations, requiring careful planning and dynamic rerouting. See FIG. 8 for the zoning plans.

[0115] (7) There are multiple levels of maneuvering speed allowed for different zones, including shared roads, and for different types of AMRs according to the level of potential risk, mobility capabilities, and types of role (e.g., carrying a simple item, carrying a stack of heavy items which leads to more ample time to prepare when something has happened).

[0116] NOTE: The use case has the primary focus on single story warehouse setting. Consideration points needed for communication service in a multi-story setting is FFS.

[0117] 3. Service Flows

[0118] NOTE: The AMRs in this scenario (invention disclosure) are equipped with the UE's functionalities such as communication and others, and are considered as UEs.

[0119] (1) Posting a list of sub-tasks and taking some of them by AMRs:

[0120] (1-a) Each edge server puts the new sub-task (including its characteristics, such as urgency, load) on a common bulletin board. Example: transporting items from one aisle to a packing area or sorting items in specific zones.

[0121] (1-b) Each AMR with its capability available for additional load of sub-task regularly scans the bulletin board.

[0122] (1-c) Each AMR on its own decision volunteers to take a specific sub-task on a contention basis. Contention resolution is performed among those AMRs involved.

[0123] (2) Real-Time Awareness Data Sharing:

[0124] (2-a) AMRs share awareness data with nearby AMRs. The awareness data that an AMR shares with others can include the real-time control / maneuver with its immediate plans, and its allowed range on ground mobility during a specific time window of common interests, types of roles with which other AMRs can get aware of what would be necessary for that AMR in mutual decision-making in the warehouse

[0125] (2-b) For example, AMR1 is coming out of zone 1 with a set of ground mobility related parameters based on its capability and the route planned to travel. AMR2 and AMR3 are also coming out of zone 2 and zone 3, respectively, with their sets of parameters as well.

[0126] (2-c) While AMR1 is attempting to share its awareness data, it has temporarily lost the connectivity.

[0127] (2-d) The 6G system promptly help recover the connectivity from communication interruption. AMR1 can continue to share the data with a minimal interruption.

[0128] (2-e) AMRs 1, 2, and 3 will need to share a certain spot on the shared road at certain point in time, and they share their awareness data with each other.

[0129] (3) Collaborative Decision-Making:

[0130] (3-a) Each AMR uses this data to adjust its navigation strategy and plan around obstacles or bottlenecks in high-traffic areas on the shared road.

[0131] (3-b) Each AMR can solve the navigation strategy planning problem, e.g., using game-theoretic approach (given that other AMR's options are known to each other), or requesting an edge server to solve that problem in coordination.

[0132] 4. Post-conditions

[0133] AMR1 was able to share the awareness data with a minimum level of interruption owing to the immediate support from 6G system. In turn,

[0134] AMR2 and AMR3 were able to receive AMR1's awareness data promptly;

[0135] AMR1 was able to receive AMR2's and AMR3's awareness data promptly.

[0136] AMR1, AMR2, and AMR3 were able to make mutual decisions so that they can avoid collision (ideal case), minimize the collision (e.g., within a given threshold value in practice), and / or avoid disturbing other nearby AMR from moving its optimal speed within the allowance

[0137] 5. Existing features partly or fully covering the use case functionality

[0138] Requirements on communicating indications in operations of cyber-physical systems (3GPP TS 22.186, 3GPP TS 22.104).

[0139] The data sharing between UEs served by different networks has been specified by 5G LAN-type service defined in 3GPP TS 22.261, however, no solution has been concluded in stage 2 work. The data sharing between UEs within the same network can be partially covered by 5G LAN-type service. However, the group is managed by the subscription which cannot satisfy the requirement of group initiation by the AMR itself. In addition, for a short term or emergency task, the communication service provided to the group of AMRs should be established in a relatively short time to match time-efficiency of the task. However, the high time-efficiency requirement is hard to meet by 5G-LAN since 5G-LAN service requires lots of manual operations, e.g. LAN configuration, subscription, Data Network Name / Single Network Slice Selection Assistance Information configuration, etc. The same gap can also be applied to the NPN defined in 3GPP TS 22.261.

[0140] 6. Potential New Requirements needed to support the use case

[0141] (1) Subject to operator's policy and regulatory requirements, the 6G system shall be able to provide a means to support data sharing among multiple UEs (AMRs) served by one or more 6G networks moving in a coverage area according to the following KPIs (Table 5).

[0142] NOTE 1: The shared data is collaborative awareness data that a UE (AMR) shares with other UEs (AMRs) and can include the real-time control / maneuver with its immediate plans, and its allowed range on ground mobility, types of role with which other UEs (AMRs) can get aware of what would be necessary for that UE (AMR) in mutual decision-making in the warehouse.

[0143] NOTE 2: The data sharing is via direct network connection or via direct device connection.

[0144] Table 5 corresponds to Performance requirements on collaborative awareness data sharing.

[0145] Scenariolatency (ms)(note 1)Experienced data rate (DL)Experienced data rate (UL)Area traffic capacity(DL)Area traffic capacity(UL)Overall user densityReliabilityUE speed(note 2)UE typeCommunication range (km)(note 5)AMRs performing tasks with low acceleration-sensitivity

[0100] N / AN / ATBDN / AN / A[99.9999%]Up to

[0010] m / sAMR> 0.4(note 4)AMRs performing tasks with relatively high acceleration-sensitivity

[0010] N / AN / ATBDN / AN / A[99.9999%]Up to

[0010] m / sAMR> 0.6(note 4)NOTE 1: The latency considered for up to two hops only. The latency is measured in the time interval between the time that collaborative awareness data is ready to be sent and the time that the data is received so that the information can be delivered to a nearby UE to prepare for necessary action to take.NOTE 2: Relative speed between a pair of UEs (AMRs) is considered.NOTE 3: The latency and reliability may vary depending on the type of application and the role of AMR performing different sub-tasks.NOTE 4: It is assumed that AMRs with heavy payloads are operating passively (e.g. at a very low acceleration level) such that the time it takes for them to make a complete stop is long (e.g. more than 20 seconds).NOTE 5: This means the minimum required distance when the UEs need to start communication in order to provide minimum ample time for UEs (AMRs) to prepare.

[0146] (2) Subject to operator's policy and regulatory requirements, the 6G system shall be able to provide a means to support efficient data sharing among multiple UEs (e.g. AMRs) initiated by a UE (e.g. AMR) considering the dynamics of the communication, e.g. frequent change of the involved UEs and the varied duration of the group communication to match the lifecycle of the task, etc.

[0147] NOTE 3: The shared data is collaborative awareness data that a UE (AMR) shares with other UEs (AMRs) and can include the real time control / manoeuvre with its immediate plans.

[0148]

[0149] DETAILD DESCRIPTION

[0150] If there is no information shared among near-by robots, they can only achieve a limited performance (e.g., limited speed of moving in the shared zone) - this can be explained by "competitive games" in which a robot (a player) can only make decision without the knowledge of the other robot (i.e., its neighbor dwelling in the shared zone).

[0151] In the 6G service framework, it is expected that advanced forms of cyber physical systems (e.g., robots with intelligence) perform certain task with certain levels of autonomy.

[0152] As in factory floor, enterprise building area, and CCRC, multiple robots would share the common geographical area (such as road, hallway).

[0153] This invention is to propose a method of sharing data (e.g., "intent", "maneuver") to improve collaborative awareness so that the respective robots (that are acting as UE's) can make decision with their mutual information (such as intent, maneuver, plans) shared in real-time.

[0154] If there is partial information or maximum available information that is shared among these nearby robots, they can achieve a better performance (e.g., no need to reduce the speed as each of them will be aware of each other's intent and plans of movement directions and speeds, and so on).

[0155] FIG. 9 illustrates a proposed method of the present disclosure.

[0156] Real-Time Awareness Data Sharing:

[0157] (a) AMRs (that are UEs) share awareness data with nearby AMRs. This data may include real-time control or maneuvering information, immediate plans, allowed ranges of ground mobility within a specific time window, and role-related details that help other AMRs understand what may be required for mutual decision-making in the warehouse.

[0158] (b) Example: AMR1 exits Zone 1 with a set of ground mobility parameters based on its capability and planned route. Similarly, AMR2 and AMR3 exit Zone 2 and Zone 3, respectively, with their own parameter sets.

[0159] (c) While AMR1 is attempting to share its awareness data, it temporarily loses connectivity.

[0160] (d) The 6G system promptly restores connectivity after the interruption, enabling AMR1 to continue data sharing with minimal disruption.

[0161] (e) AMRs 1, 2, and 3 must share access to a specific spot on the road at a certain time. They exchange awareness data to coordinate this shared use.

[0162] Collaborative Decision-Making:

[0163] (a) Each AMR uses this data to adjust its navigation strategy and plan around obstacles or bottlenecks in high-traffic areas on the shared road.

[0164] (b) Each AMR can solve the navigation strategy planning problem, e.g., using game-theoretic approach (given that other AMR's options are known to each other), or requesting an edge server to solve that problem in coordination.

[0165] As shown in the FIG. 9, an example procedure is illustrated for establishing and operating a collaborative awareness data sharing arrangement between a first autonomous mobile robot and a second autonomous mobile robot, under coordination of a base station and a server. In the illustrated example, AMR1 corresponds to a first user equipment (UE1), AMR2 corresponds to a second user equipment (UE2), the gNB corresponds to a base station (BS), and the server corresponds to an application server, edge server, or network server that stores negotiation results and orchestrates subsequent reporting missions.

[0166] (1) Presence announcement by AMR1 and delivery of AMR1 identifier

[0167] In a first stage, AMR1 detects or determines that neighboring UEs may exist within a discovery range, and AMR1 broadcasts or transmits a presence notification indicating that AMR1 is available. In the FIG. 9, this operation is represented by the block "Notify 'I'm here' to neighboring UEs." The presence notification may be transmitted using a proximity discovery mechanism, sidelink discovery, a broadcast message, or any other short range or cellular based discovery signaling. Along with the presence notification, AMR1 provides an identifier, denoted as AMR1 ID1 in the FIG. 9. The identifier may be a temporary identifier, a pseudonymous identifier, a group identifier, or an application layer identifier used for collaborative awareness negotiation. The arrow labeled "AMR1 ID1" represents delivery of ID1 from AMR1 to AMR2.

[0168] (2) Neighbor recognition by AMR2 and delivery of AMR2 identifier

[0169] Upon receiving the presence notification and AMR1 ID1, AMR2 recognizes that a neighboring robot is present and that the neighboring robot is a candidate participant for collaborative awareness. In the FIG. 9, this operation is represented by the block "Recognize the neighbor: Send Response." As part of the response, AMR2 transmits its own identifier, denoted as AMR2 ID2 in the FIG. 9, toward AMR1. The arrow labeled "AMR2 ID2" represents delivery of ID2 from AMR2 to AMR1. In some implementations, this response also confirms reachability, indicates supported collaboration features, or provides a minimal capability description that allows AMR1 to decide whether to proceed to a negotiation phase.

[0170] (3) Data sharing request from AMR2 including a data sharing scope

[0171] After neighbor recognition, AMR2 initiates negotiation for collaborative awareness data sharing by transmitting a first data sharing request toward AMR1. In the FIG. 9, this operation is represented by the block "Request for Data Sharing (for Collaborative Awareness) with sharing scope (content, time)" and the arrow labeled "Req (ID2)." The request may explicitly indicate that it is associated with AMR2 ID2, and may also reference AMR1 ID1, so that both parties can bind the negotiation to a particular pair of robots. The request includes a data sharing scope. The data sharing scope may define, for example, data sharing content and data sharing time. Data sharing content may include one or more of location information, pose information, velocity information, planned trajectory, sensed obstacles, environmental map fragments, confidence metrics, signal quality related information, or any other information that contributes to collaborative awareness. Data sharing time may indicate a duration for sharing, a validity interval, a reporting periodicity, an event based trigger condition, or an update rate requirement. In some implementations, the scope may further include granularity, accuracy requirements, data size limits, compression requirements, privacy constraints, security requirements, or priority levels.

[0172] According to various embodiments of the present disclosure, the "data sharing scope" included in a data sharing request may define an operational contract that constrains what awareness data is shared, how the awareness data is shared, and for what time or under what conditions the sharing is valid. The data sharing scope may include data sharing content and data sharing time, and may further include one or more of an update periodicity, an event trigger condition, a reporting granularity, an accuracy or precision target, a data size limit, a compression requirement, a confidentiality level, an integrity protection requirement, an authorization condition, a priority level, or a validity interval. For example, the data sharing content may include at least one of pose and velocity, planned trajectory, intended maneuver, zone transition intent, obstacle detections, local map fragments, risk indicators, or radio and sensing quality indicators, while the data sharing time may specify a start time and end time, a duration, or a time window during which sharing is active. In some implementations, the data sharing scope is negotiable such that a requesting node proposes an initial scope and a responding node may accept the initial scope, reject the initial scope, or transmit a counter-proposal specifying a modified scope that reduces overhead while preserving a minimum collaborative awareness benefit, thereby enabling dynamic, context-dependent selection of content, timing, and reporting mode for reliable real-time coordination.

[0173] According to various embodiments of the present disclosure, the data sharing scope included in a data sharing request defines a machine-enforceable operational contract that explicitly constrains what awareness data is exchanged, when the exchange is active, and how the exchange is performed, so that the system can avoid uncontrolled and unnecessary sharing while still achieving the minimum awareness needed for mutual decision-making. The data sharing scope may include data sharing content and data sharing time, and may further include at least one of a reporting periodicity, an event trigger condition, an update rate bound, a spatial or semantic granularity, an accuracy target, a data size limit, an encoding or compression constraint, a priority level, a confidentiality or access control level, an integrity protection requirement, an authorization condition, or a validity interval. For example, the content may be limited to intent and maneuver, planned trajectory, zone transition intent, or a risk indicator, while the time may be limited to a bounded validity interval associated with a shared road segment or a predicted encounter window. In addition, the scope may be negotiated such that a responding node can accept the proposed scope, reject the proposed scope, or counter-propose a modified scope that reduces at least one of content breadth, time duration, or reporting frequency while maintaining a target collaborative awareness benefit, thereby enabling context-dependent minimization of signaling overhead without sacrificing coordination performance.

[0174] (4) Analysis by AMR1 and construction or update of a collaborative awareness benefit function

[0175] Upon receiving the first data sharing request, AMR1 analyzes the request. In the FIG. 9, this operation is represented by the block "Analyze received request; Build update Collaborative Awareness benefit function." AMR1 may evaluate expected benefits and expected costs associated with the requested data sharing scope. For example, AMR1 may estimate how much the requested content and time would improve collision avoidance, path planning, or task efficiency, and may also estimate costs such as power consumption, computational load, bandwidth usage, latency impact, privacy exposure, or risk of sharing sensitive map or mission data. In order to make this evaluation consistent across repeated negotiations and varying environments, AMR1 builds, updates, or maintains a collaborative awareness benefit function. The collaborative awareness benefit function may take as inputs the requested scope, current context (for example proximity, relative motion, congestion, or mission criticality), and historical outcomes. The function may output a quantitative collaborative awareness benefit value that represents an expected improvement in collaborative awareness if AMR1 accepts the request under the proposed scope.

[0176] According to various embodiments of the present disclosure, the term "collaborative awareness benefit" may refer to a quantitative or categorical measure representing an expected improvement in mutual decision-making performance among a plurality of robots when a proposed awareness data sharing arrangement is established under a particular data sharing scope. The collaborative awareness benefit may be computed based on one or more benefit factors and one or more cost factors. The benefit factors may include, for example, an expected reduction in collision risk, an expected reduction in near-miss probability, an expected decrease in navigation uncertainty, an expected improvement in route efficiency, an expected decrease in waiting time at a shared road segment, an expected improvement in throughput of task execution, or an expected improvement in compliance with zone-specific mobility constraints. The cost factors may include, for example, an estimated increase in wireless resource usage, an estimated increase in uplink or sidelink traffic volume, an estimated increase in energy consumption, an estimated increase in processing load, an estimated increase in latency sensitivity, or an estimated privacy or confidentiality exposure. In some implementations, the collaborative awareness benefit may be obtained from a collaborative awareness benefit function that maps at least the data sharing scope and contextual information (for example relative distance, relative speed, congestion level, role type, task urgency, and connectivity stability) to a benefit value, and the function may be constructed, updated, or adapted over time based on observed outcomes of prior sharing sessions or mission execution results.

[0177] According to various embodiments of the present disclosure, the collaborative awareness benefit is not merely a qualitative notion, but a computable technical metric used for admission control and scope adaptation of real-time awareness data sharing. In particular, a responding node may compute the collaborative awareness benefit as a function of (i) predicted safety improvement and mutual decision-making gain and (ii) predicted resource and risk cost incurred by the requested data sharing scope, and may output a scalar value, a multi-dimensional vector, or a categorical level that is comparable against a threshold. The safety and decision-making gain may reflect at least one of an estimated reduction in collision probability, an estimated reduction in near-miss probability, an estimated decrease in trajectory uncertainty, an estimated decrease in expected waiting time at a shared segment, an estimated improvement in throughput of task execution, or an estimated improvement in compliance with zone-dependent mobility constraints, while the resource and risk cost may reflect at least one of estimated radio resource usage, estimated traffic volume, estimated energy consumption, estimated processing load, estimated latency sensitivity, or estimated confidentiality exposure. Further, the collaborative awareness benefit function may be constructed, maintained, or updated based on context information such as relative distance and velocity, congestion level, task urgency, role type, battery status, and connectivity stability, and may be adaptively tuned using outcomes of prior sharing sessions, thereby enabling a technically grounded decision on whether to accept a requested scope or to counter-propose a modified scope that preserves a minimum benefit under constrained resources.

[0178] (5) Threshold comparison at AMR1 and generation of a response

[0179] After determining the collaborative awareness benefit value, AMR1 compares the benefit to a threshold. In the FIG. 9, this decision is represented by the diamond "Benefit greater than Threshold?" If the benefit exceeds the threshold, AMR1 generates an acceptance response. If the benefit does not exceed the threshold, AMR1 may either reject the request or attempt to revise the scope through a counter proposal, as described later.

[0180] (6) Acceptance path: AMR1 sends acceptance and the network records the negotiation result

[0181] When the benefit exceeds the threshold, AMR1 transmits a response indicating acceptance to AMR2. In the FIG. 9, this is represented by the arrow "Resp. Yes." The response may confirm acceptance of the data sharing scope as requested, and may optionally include parameters that operationalize the sharing, such as start time, end time, reporting schedule, or security credentials.

[0182] After AMR2 receives the acceptance, the negotiation is considered achieved, and AMR2, the gNB, or both may report the negotiation result to the server. In the FIG. 9, this is represented by the block at the gNB lane "Report to Server: Collaborative Awareness negotiation achieved (ID1, ID2, scope)" and the arrow toward the server. The reported information may include AMR1 ID1, AMR2 ID2, and the agreed data sharing scope. The gNB may function as a relay and may also provide authorization, integrity protection, and scheduling support for signaling to the server.

[0183] (7) Server side storage and mission assignment for collaborative awareness data sharing

[0184] Upon receiving the negotiation report, the server stores the received information. In the FIG. 9, this is represented by the block "Store the received info (ID's, scope)." The server may maintain a table of active collaboration pairs or groups, with associated scopes and validity times. Based on the stored negotiation result, the server assigns missions to the involved UEs to enable actual data sharing for collaborative awareness. In the FIG. 9, this is represented by the block "Assign mission to these UE's to report necessary info (location, signal quality, etc.) to perform Collaborative Awareness data sharing (periodically or in an event based manner)." The assigned missions may indicate what data should be reported, when it should be reported, and under what triggers it should be reported. For example, the server may instruct AMR1 and AMR2 to report location updates every predefined interval, and additionally report an event triggered update when a sudden obstacle is detected or when the relative distance becomes smaller than a threshold. The server may also specify uplink reporting resources, priority, quality of service settings, or application level endpoints.

[0185] The gNB delivers the mission assignments to each UE. In the FIG. 9, this delivery is represented by the arrows labeled "Assign missions to UE1" and "Assign missions to UE2," which indicate that the base station provides downlink signaling that conveys the mission configuration to AMR1 and AMR2. After mission delivery, AMR1 and AMR2 perform the requested reporting and data sharing under the agreed scope, thereby realizing collaborative awareness.

[0186] According to various embodiments of the present disclosure, the server and the base station (gNB) cooperate to enforce a negotiated awareness data sharing arrangement and to orchestrate subsequent reporting behavior in a manner that is consistent, traceable, and resource-aware. After a negotiation between participating robots is concluded, the gNB may relay or report, to the server, negotiation outcome information including identifiers of the participating nodes and an agreed data sharing scope, and the server may store such information as an active collaboration record associated with a validity interval. Based on the stored collaboration record, the server may generate and assign one or more missions that specify concrete reporting and sharing actions to be performed by the participating nodes, including at least one of which information items to report, a periodic reporting schedule, event-based reporting triggers, required quality or latency constraints, and an endpoint or application context for delivery. The gNB may deliver the mission configuration to each participating node using downlink signaling or other control signaling, and may further support the missions by allocating or prioritizing radio resources consistent with the agreed scope, thereby reducing unnecessary transmissions and stabilizing real-time awareness data exchange. Accordingly, the disclosed server-and-gNB-assisted orchestration provides a technical mechanism that bridges a local inter-robot negotiation with network-managed execution, enabling policy-consistent sharing, reducing signaling overhead, and improving reliability and timeliness of collaborative awareness under dynamic wireless conditions.

[0187] According to various embodiments of the present disclosure, the server and the base station are assigned differentiated technical roles that convert a local inter-robot negotiation into a network-managed execution pipeline with enforceability and scalability. After a negotiation is completed, the base station may (i) relay or report negotiation outcome information including participating identifiers and an agreed data sharing scope to the server with integrity protection, (ii) translate the agreed scope into radio and protocol level configurations, and (iii) support real-time execution by allocating or prioritizing uplink or sidelink resources, providing congestion-aware scheduling, and delivering control signaling that activates periodic reporting or event-triggered reporting consistent with the agreed scope. Meanwhile, the server may (i) store an active collaboration record bound to a validity interval, (ii) apply policy checks such as authorization, zone-specific constraints, and confidentiality requirements, (iii) generate one or more missions specifying concrete reporting items, triggers, cadence, and endpoints that implement the agreed scope, and (iv) maintain traceability and lifecycle management including activation, update, suspension, or expiration of collaboration records. By separating the radio resource enforcement role of the base station from the policy, orchestration, and audit role of the server, the disclosed architecture improves reliability under dynamic wireless conditions and prevents scope divergence during execution, while enabling fleet-scale operation across multiple zones and networks.

[0188] (8) Non acceptance path: AMR1 evaluates whether a counter proposal is necessary

[0189] If, at step (5), the benefit does not exceed the threshold, AMR1 proceeds to an additional decision regarding whether to issue a counter proposal. In the FIG. 9, this is represented by the block "Check necessity of making counter proposal (that is modified scope of sharing content, time)" followed by the diamond "Necessary?" AMR1 may determine that a counter proposal is necessary when the requested scope is too costly but a reduced scope may still provide sufficient benefit. For example, AMR1 may consider shortening the data sharing time, reducing the frequency of updates, limiting the content to a subset such as coarse location, or restricting sharing to event based reporting rather than periodic reporting.

[0190] If AMR1 determines that a counter proposal is not necessary, AMR1 transmits a negative response to AMR2, represented by the arrow "Resp. No," and the negotiation may terminate or may be retried later.

[0191] (9) Counter proposal: AMR1 transmits a second data sharing request with a modified scope

[0192] If AMR1 determines that a counter proposal is necessary, AMR1 transmits a counter proposal to AMR2. In the FIG. 9, this is represented by the block "Counter proposal: Request for Data Sharing with modified scope (content, time)" and the arrow labeled "Req (ID2)." The counter proposal may be formatted as a second data sharing request, and may include a modified data sharing scope. The modified scope may include, for example, modified data sharing time, modified data sharing content, or both. For instance, AMR1 may propose that sharing be limited to a shorter duration, or that only essential elements of the requested content be shared, or that updates be delivered only when an event trigger is satisfied.

[0193] (10) Analysis by AMR2 for the modified scope and threshold comparison

[0194] Upon receiving the counter proposal, AMR2 analyzes the received request and builds or updates its own collaborative awareness benefit function. In the FIG. 9, this is represented by the block "Analyze received request; Build update Collaborative Awareness benefit function." AMR2 determines a benefit value corresponding to the modified scope, and compares the benefit to a threshold, represented by the diamond "Benefit greater than Threshold?" If the modified scope still does not justify participation for AMR2, AMR2 transmits a negative response "Resp. No" to AMR1 and the negotiation may end. If the modified scope satisfies AMR2's threshold criterion, AMR2 transmits an acceptance response "Resp. Yes" to AMR1, thereby concluding the negotiation based on the modified scope.

[0195] (11) Reporting of negotiated modified scope to the server and mission assignment

[0196] When AMR2 accepts the counter proposal, a negotiation result is reported to the server. In the FIG. 9, this is represented by the block "Report to Server: Collaborative Awareness Negotiation achieved (ID1, ID2, modified scope)" and the arrow toward the server. The server stores the identifiers and the modified scope, as represented by the block "Store the received info (ID's, scope)." The server then assigns missions to the UEs consistent with the modified scope, again represented by the block "Assign mission to these UE's to report necessary info (location, signal quality, etc.) to perform Collaborative Awareness data sharing (periodically or in an event based manner)." The gNB delivers the mission assignments to UE1 and UE2, represented by "Assign missions to UE1" and "Assign missions to UE2." Thereafter, AMR1 and AMR2 perform collaborative awareness data sharing according to the modified scope, which may reduce overhead while still providing sufficient awareness improvement.

[0197] In this manner, the FIG. 9 illustrates an end to end negotiation and enforcement framework in which neighboring robots exchange identifiers, negotiate a data sharing scope based on a collaborative awareness benefit and a threshold decision, optionally refine the scope through a counter proposal, and then utilize network side coordination through the base station and the server to store the agreed scope and assign concrete reporting missions for subsequent collaborative awareness data sharing.

[0198] Advantageous Effects

[0199] The present disclosure provides an efficient and scalable collaborative awareness framework in which neighboring autonomous mobile robots can dynamically negotiate data sharing based on an explicitly evaluated collaborative awareness benefit, rather than relying on static or always-on sharing. By determining whether a requested data sharing scope satisfies a threshold and, when it does not, generating a counter-proposal with a modified scope (for example reduced content and or shortened sharing time), the robots can achieve a practical balance between awareness improvement and resource consumption, thereby reducing unnecessary uplink and sidelink traffic, power usage, and processing load while still maintaining safety and operational efficiency. In addition, reporting the negotiation result to a server and distributing mission assignments via the base station enables consistent enforcement of the agreed scope, centralized storage and traceability of participating identifiers and scopes, and coordinated periodic or event-based reporting tailored to the operational context. As a result, the disclosed procedure improves reliability and timeliness of awareness information, supports adaptive collaboration under changing environments, and enhances overall system performance for multi-robot operation in cellular-connected deployments.

[0200] According to various embodiments of the present disclosure, the present disclosure provides practical and technical advantageous effects by enabling real-time awareness data sharing among multiple robots through a benefit-based negotiation and a network-assisted execution mechanism. Specifically, by determining a collaborative awareness benefit for a requested data sharing scope and selectively accepting, rejecting, or counter-proposing a modified scope, the disclosed technique reduces unnecessary transmissions compared to always-on sharing, thereby decreasing uplink and sidelink traffic, lowering energy consumption, and reducing processing overhead while preserving or improving safety and operational efficiency. In addition, because the agreed data sharing scope explicitly constrains sharing content, timing, and reporting mode (for example periodic or event-based reporting), the system can adapt the sharing behavior to dynamic conditions such as congestion, task urgency, role differences, and connectivity stability, which improves timeliness and reliability of shared awareness information and mitigates performance degradation caused by intermittent wireless links. Further, reporting negotiation outcomes to a server and distributing mission assignments via a base station enables scope-consistent enforcement, centralized traceability of participating identifiers and negotiated scopes, and resource-aware orchestration of reporting configurations, which collectively improves scalability for large robot fleets and supports consistent operation across multiple coverage zones and networks. As a result, the disclosed embodiments enhance mutual decision-making quality, improve collision avoidance and throughput in shared environments, and provide a robust framework for deploying collaborative robot services over wireless communication systems.

[0201] The present disclosure provides technical and practical advantageous effects by enabling benefit-driven negotiation and network-assisted enforcement of real-time awareness data sharing among multiple robots, rather than relying on static configuration or unconditional sharing. First, by computing a collaborative awareness benefit for a requested data sharing scope and deciding acceptance, rejection, or counter-proposal based on a threshold, participating robots can suppress unnecessary transmissions and processing, thereby reducing traffic volume, energy consumption, and computational load while retaining the minimum awareness required for safe and efficient mutual decision-making. Second, because the agreed data sharing scope explicitly constrains content, validity time, and reporting mode including periodic and event-triggered reporting, the sharing behavior can be adaptively optimized to operational context such as congestion, task urgency, role differences, and connectivity stability, which improves timeliness and reliability of received awareness information and mitigates performance degradation caused by intermittent links. Third, by reporting negotiation outcomes to a server and delivering mission assignments through a base station, the system achieves scope-consistent execution with centralized traceability and policy control, and the base station can further stabilize performance through resource-aware scheduling aligned with the agreed scope. Accordingly, the disclosed technique improves collision avoidance performance, reduces bottlenecks in shared areas, enhances throughput of multi-robot task execution, and enables scalable deployment across multiple zones and networks.

[0202] Features of various embodiments of the present disclosure

[0203] - Broadcasting, by a first autonomous mobile robot UE (AMR1), a presence notification to neighboring UEs indicating availability for collaborative awareness interaction.

[0204] - Transmitting, by AMR1, a first identifier (ID1) usable to bind subsequent negotiation messages to a specific AMR1 instance.

[0205] - Recognizing, by a second autonomous mobile robot UE (AMR2), the neighboring AMR1 based on the presence notification and returning a response including a second identifier (ID2).

[0206] - Initiating a collaborative awareness negotiation by transmitting, from AMR2 to AMR1, a first data sharing request that includes a data sharing scope.

[0207] - Defining the data sharing scope to include at least data sharing content and data sharing time, to explicitly constrain what information is shared and for how long.

[0208] - Analyzing, by AMR1, the received data sharing request and determining a collaborative awareness benefit value associated with the requested scope.

[0209] - Building, maintaining, or updating, by AMR1, a collaborative awareness benefit function used to compute the collaborative awareness benefit value for a given request and context.

[0210] - Comparing, by AMR1, the determined collaborative awareness benefit value with a threshold to decide whether to accept the requested scope.

[0211] - Transmitting, by AMR1 to AMR2, an acceptance response when the benefit exceeds the threshold, thereby concluding negotiation under the requested scope.

[0212] - Reporting, via a base station (gNB), a negotiation achievement message to a server, the message including at least ID1, ID2, and the agreed data sharing scope.

[0213] - Storing, by the server, the received negotiation information, including the participating identifiers and the agreed data sharing scope, to enable traceability and subsequent orchestration.

[0214] - Assigning, by the server, one or more missions to the participating UEs to report necessary information for collaborative awareness data sharing.

[0215] - Delivering, by the gNB, mission assignments to UE1 and UE2, thereby enabling network-assisted configuration of subsequent reporting behavior.

[0216] - Supporting, based on the mission assignments, periodic reporting for collaborative awareness data sharing according to the agreed scope.

[0217] - Supporting, based on the mission assignments, event-based reporting for collaborative awareness data sharing according to the agreed scope.

[0218] - Determining, by AMR1 when the benefit does not exceed the threshold, whether a counter-proposal is necessary to adjust the requested sharing scope rather than immediately rejecting.

[0219] - Generating and transmitting, by AMR1 to AMR2, a counter-proposal as a second data sharing request including a modified data sharing scope.

[0220] - Defining the modified data sharing scope to include a modified data sharing time, thereby reducing or reshaping sharing overhead while preserving awareness utility.

[0221] - Evaluating, by AMR2, the counter-proposed modified scope by analyzing the second data sharing request and determining an updated collaborative awareness benefit value.

[0222] - Building, maintaining, or updating, by AMR2, a collaborative awareness benefit function used to evaluate the modified scope.

[0223] - Comparing, by AMR2, the benefit corresponding to the modified scope with a threshold and transmitting either an acceptance response or a rejection response accordingly.

[0224] - Reporting, via the gNB, a negotiation achievement message to the server that includes the modified scope when the counter-proposal is accepted.

[0225] - Storing, by the server, the modified scope together with ID1 and ID2 and assigning updated missions consistent with the modified scope.

[0226] - Enforcing the agreed scope through mission-driven reporting so that the shared information remains within the negotiated content and time constraints.

[0227] [Description of claims related to a first node (UE1 or AMR1)]

[0228] Below, the above-described embodiments are described in detail from a perspective of an operation of a first node with reference to FIG. 10. Methods to be described below are merely distinguished for convenience of explanation. Thus, as long as the methods are not mutually exclusive, it is obvious that partial configuration of any method can be substituted or combined with partial configuration of another method.

[0229] FIG. 10 illustrates an example of an operation process of a first node in a system applicable to the present disclosure.

[0230] A first node may be a first user equipment (UE1) or a first autonomous mobile robot (AMR1). A second node may be a second user equipment (UE2) or a second autonomous mobile robot (AMR2).

[0231] In step S1010, a first node receives, from a second node, a first data sharing request including a data sharing scope.

[0232] In step S1020, the first node determines a collaborative awareness benefit based on the first data sharing request.

[0233] In step S1030, the first node transmits, to the second node, a response message to the first data sharing request based on the collaborative awareness benefit.

[0234] According to various embodiments of the present disclosure, based on the determined collaborative awareness benefit exceeding a threshold value, the response message is a first response accepting the first data sharing request.

[0235] According to various embodiments of the present disclosure, the embodiments of FIG. 10 further comprise, after the first response is transmitted to the second node, transmitting, to a server, a negotiation result based on the data sharing scope.

[0236] According to various embodiments of the present disclosure, the embodiments of FIG. 10 further comprise, based on the collaborative awareness benefit not exceeding a threshold value, transmitting, to the second node, a second data sharing request including a modified data sharing scope.

[0237] According to various embodiments of the present disclosure, the modified data sharing scope includes a modified data sharing time.

[0238] According to various embodiments of the present disclosure, the data sharing scope included in the first data sharing request includes modified data sharing content.

[0239] According to various embodiments of the present disclosure, the collaborative awareness benefit is based on an update of a collaborative awareness benefit function.

[0240] According to various embodiments of the present disclosure, there is provided a first node in a wireless communication system. The first node may include a transceiver and at least one processor, and the at least one processor may be configured to perform the operation method of the first node based on FIG. 10.

[0241] According to various embodiments of the present disclosure, there is provided a device controlling a first node in a wireless communication system. The device may include at least one processor and at least one memory operably connected to the at least one processor. The at least one memory may be configured to store instructions performing the operation method of the first node based on FIG. 10 based on being executed by the at least one processor.

[0242] According to various embodiments of the present disclosure, there are provided one or more non-transitory computer readable mediums (CRMs) storing one or more instructions. The one or more instructions may be configured to perform operations based on being executed by one or more processors, and the operations may include the operation method of the first node based on FIG. 10.

[0243]

[0244] [Description of claims related to a second node (UE2 or AMR2)]

[0245] Below, the above-described embodiments are described in detail from a perspective of an operation of a second node with reference to FIG. 11. Methods to be described below are merely distinguished for convenience of explanation. Thus, as long as the methods are not mutually exclusive, it is obvious that partial configuration of any method can be substituted or combined with partial configuration of another method.

[0246] FIG. 11 illustrates an example of an operation process of a second node in a system applicable to the present disclosure.

[0247] A first node may be a first user equipment (UE1) or a first autonomous mobile robot (AMR1). A second node may be a second user equipment (UE2) or a second autonomous mobile robot (AMR2).

[0248] In step S1110, a second node transmits, to a first node, a first data sharing request including a data sharing scope.

[0249] In step S1120, the second node receives, from the first node, a response message to the first data sharing request based on a collaborative awareness benefit related to the first data sharing request.

[0250] According to various embodiments of the present disclosure, based on the determined collaborative awareness benefit exceeding a threshold value, the response message is a first response accepting the first data sharing request.

[0251] According to various embodiments of the present disclosure, after the first response is received from the first node, a negotiation result based on the data sharing scope is transmitted to a server.

[0252] According to various embodiments of the present disclosure, the embodiments of FIG. 11 further comprise, based on the collaborative awareness benefit not exceeding a threshold value, receiving, from the first node, a second data sharing request including a modified data sharing scope.

[0253] According to various embodiments of the present disclosure, the modified data sharing scope includes a modified data sharing time.

[0254] According to various embodiments of the present disclosure, the data sharing scope included in the first data sharing request includes modified data sharing content.

[0255] According to various embodiments of the present disclosure, the collaborative awareness benefit is based on an update of a collaborative awareness benefit function.

[0256] According to various embodiments of the present disclosure, there is provided a second node in a wireless communication system. The second node may include a transceiver and at least one processor, and the at least one processor may be configured to perform the operation method of the second node based on FIG. 11.

[0257] According to various embodiments of the present disclosure, there is provided a device controlling a second node in a wireless communication system. The device may include at least one processor and at least one memory operably connected to the at least one processor. The at least one memory may be configured to store instructions performing the operation method of the second node based on FIG. 11 based on being executed by the at least one processor.

[0258] According to various embodiments of the present disclosure, there are provided one or more non-transitory computer readable mediums (CRMs) storing one or more instructions. The one or more instructions may be configured to perform operations based on being executed by one or more processors, and the operations may include the operation method of the second node based on FIG. 11.

[0259] Wireless device applicable to the present disclosure

[0260] Examples of wireless devices to which various embodiments of the present disclosure are applied are described below.

[0261] FIG. 12 illustrates an example of a structure of a first device and a second device in a system applicable to the present disclosure.

[0262] A first device 1600 may include a processor 1610, an antenna unit 1620, a transceiver 1630, and a memory 1640.

[0263] The processor 1610 may perform baseband-related signal processing and include a higher layer processing unit 1611 and a physical layer processing unit 1615. The higher layer processing unit 1611 may process operations of the MAC layer, the RRC layer, or higher layers. The physical layer processing unit 1615 may process the operation of the PHY layer. For example, if the first device 1600 is a base station (BS) device in BS-UE communication, the physical layer processing unit 1615 may perform uplink reception signal processing, downlink transmission signal processing, and the like. For example, if the first device 1600 is a first UE device in inter-UE communication, the physical layer processing unit 1615 may performs downlink reception signal processing, uplink transmission signal processing, sidelink transmission signal processing, and the like. The processor 1610 may control the overall operation of the first device 1600 in addition to performing the baseband-related signal processing.

[0264] The antenna unit 1620 may include one or more physical antennas and support MIMO transmission / reception if the antenna unit 1620 includes a plurality of antennas. The transceiver 1630 may include a radio frequency (RF) transmitter and an RF receiver. The memory 1640 may store information processed by the processor 1610 and software, operating systems, and applications related to the operation of the first device 1600. The memory 1640 may also include components such as a buffer.

[0265] The processor 1610 of the first device 1600 may be configured to implement the operation of the BS in the BS-UE communication (or the operation of the first UE device in the inter-UE communication) in embodiments described in the present disclosure.

[0266] The second device 1650 may include a processor 1660, an antenna unit 1670, a transceiver 1680, and a memory 1690.

[0267] The processor 1660 may perform baseband-related signal processing and include a higher layer processing unit 1661 and a physical layer processing unit 1665. The higher layer processing unit 1661 may process the operation of the MAC layer, the RRC layer, or higher layers. The physical layer processing unit 1665 may process the operation of the PHY layer. For example, if the second device 1650 is a UE device in BS-UE communication, the physical layer processing unit 1665 may perform downlink reception signal processing, uplink transmission signal processing, and the like. For example, if the second device 1650 is a second UE device in inter-UE communication, the physical layer processing unit 1665 may perform downlink reception signal processing, uplink transmission signal processing, sidelink reception signal processing, and the like. The processor 1660 may control the overall operation of the second device 1660 in addition to performing the baseband-related signal processing.

[0268] The antenna unit 1670 may include one or more physical antennas and support MIMO transmission / reception if the antenna unit 1670 includes a plurality of antennas. The transceiver 1680 may include an RF transmitter and an RF receiver. The memory 1690 may store information processed by the processor 1660 and software, operating systems, and applications related to the operation of the second device 1650. The memory 1690 may also include components such as a buffer.

[0269] The processor 1660 of the second device 1650 may be configured to implement the operation of the UE in the BS-UE communication (or the operation of the second UE device in the inter-UE communication) in embodiments described in the present disclosure.

[0270] The descriptions for the BS and the UE in the BS-UE communication (or the first UE device and the second UE device in the inter-UE communication) in the examples of the present disclosure can be equally applied to the operations of the first device 1600 and the second device 1650, and redundant descriptions are omitted.

[0271] Wireless communication technologies implemented in the devices 1600 and 1650 according to the present disclosure may include LTE, NR, and 6G, as well as various other wireless communication technologies.

[0272] The claims described in various embodiments of the present disclosure can be combined in various ways. For example, technical features of the method claims of various embodiments of the present disclosure can be combined and implemented as a device, and technical features of the device claims of various embodiments of the present disclosure can be combined and implemented as a method. In addition, the technical features of the method claims and the technical features of the device claims in various embodiments of the present disclosure can be combined and implemented as a device, and the technical features of the method claims and the technical features of the device claims in various embodiments of the present disclosure can be combined and implemented as a method.

Claims

1.A method performed by a first node, comprising:receiving, from a second node, a first data sharing request including a data sharing scope;determining a collaborative awareness benefit based on the first data sharing request; andtransmitting, to the second node, a response message to the first data sharing request based on the collaborative awareness benefit.2.The method of claim 1, wherein, based on the determined collaborative awareness benefit exceeding a threshold value, the response message is a first response accepting the first data sharing request.3.The method of claim 2, further comprising, after the first response is transmitted to the second node, transmitting, to a server, a negotiation result based on the data sharing scope.4.The method of claim 1, further comprising, based on the collaborative awareness benefit not exceeding a threshold value, transmitting, to the second node, a second data sharing request including a modified data sharing scope.5.The method of claim 4, wherein the modified data sharing scope includes a modified data sharing time.6.The method of claim 1, wherein the data sharing scope included in the first data sharing request includes modified data sharing content.7.The method of claim 1, wherein the collaborative awareness benefit is based on an update of a collaborative awareness benefit function.8.A method performed by a second node, comprising:transmitting, to a first node, a first data sharing request including a data sharing scope; andreceiving, from the first node, a response message to the first data sharing request based on a collaborative awareness benefit related to the first data sharing request.9.The method of claim 8, wherein, based on the determined collaborative awareness benefit exceeding a threshold value, the response message is a first response accepting the first data sharing request.10.The method of claim 9, wherein, after the first response is received from the first node, a negotiation result based on the data sharing scope is transmitted to a server.11.The method of claim 8, further comprising, based on the collaborative awareness benefit not exceeding a threshold value, receiving, from the first node, a second data sharing request including a modified data sharing scope.12.The method of claim 11, wherein the modified data sharing scope includes a modified data sharing time.13.The method of claim 8, wherein the data sharing scope included in the first data sharing request includes modified data sharing content.14.The method of claim 8, wherein the collaborative awareness benefit is based on an update of a collaborative awareness benefit function.15.A first node comprising:a transceiver;at least one processor; andat least one memory operably coupled to the at least one processor and storing instructions that, when executed by the at least one processor, cause the first node to perform the method of any one of claims 1 to 7.16.A second node comprising:a transceiver;at least one processor; andat least one memory operably coupled to the at least one processor and storing instructions that, when executed by the at least one processor, cause the second node to perform the method of any one of claims 8 to 14.17.A control apparatus for controlling a first node, the control apparatus comprising:at least one processor; andat least one memory operably coupled to the at least one processor and storing instructions that, when executed by the at least one processor, cause the control apparatus to perform the method of any one of claims 1 to 7.18.A control apparatus for controlling a second node, the control apparatus comprising:at least one processor; andat least one memory operably coupled to the at least one processor and storing instructions that, when executed by the at least one processor, cause the control apparatus to perform the method of any one of claims 8 to 14.19.A non-transitory computer-readable medium storing one or more instructions which, when executed by one or more processors, cause the one or more processors to perform the method of any one of claims 1 to 7.20.A non-transitory computer-readable medium storing one or more instructions which, when executed by one or more processors, cause the one or more processors to perform the method of any one of claims 8 to 14.

Images