6g physical layer-link layer data multicast and in-situ computing method

Abstract

This invention discloses a 6G physical layer-link layer data multicast and in-path computation method. The method includes: a base station configuring multicast group information and assigning a group identifier G_RNTI to a group of UEs; transmitting structured multicast data containing control data and data payload through a physical layer shared channel; the receiving end identifying and computing PDUs at the physical layer or link layer, and performing in-path computation tasks according to the pipe ID and operator code; and storing, reporting, or relaying the computation results locally through the physical channel. This invention achieves deep integration of data transmission and computation through a layered in-path mechanism, a dedicated multicast DCI design, and a physical layer relay mechanism, effectively reducing latency and air interface resource overhead.

Description

Technical Field

[0001] This invention relates to wireless network protocols and network architectures, and more particularly to 6G wireless communication systems that support ultra-low latency, ultra-high reliability, and determinism. Specifically, it relates to a 6G physical layer-link layer data multicast and in-path computation method. Background Technology

[0002] Currently, the design requirements for 6G networks have evolved from the traditional "pipeline bits" to "information as a service, perception as an interface, and intelligence as a network." The 6G intelligent sensing and computing network aims to upgrade the "communication network" into a cyber-physical system with "radar eyes, AI brain, and computing power heart," achieving integrated services of local perception, intra-network intelligence, green and low-carbon operation, and security and reliability while meeting the ultimate performance requirements of Tbps-0.1ms. To achieve this goal, 6G networks need to innovate in multiple capability domains, including integrated sensing, intrinsic intelligence, computing power networks, and multi-mode data.

[0003] In the multi-mode data capability domain, a key requirement is support for in-the-path computing and arbitrary topology multicast. In-the-path computing requires data plane nodes to be able to load WASM / Python operators to implement functions such as filtering, downsampling, and AI inference, thereby reducing backhaul latency and bandwidth pressure. Arbitrary topology multicast aims to break the limitations of traditional unicast / broadcast, enabling the network to natively support "efficient many-to-many data transmission between any nodes," especially optimizing wireless air interface resources.

[0004] However, existing 5G networks face numerous challenges in supporting these converged "sensing and intelligent computing" services. First, 5G's user plane architecture, based on a unicast tree, cannot meet the "arbitrary DAG" requirements of sensing services, leading to increased computing resource consumption and latency. Second, sensing data processing nodes are typically "external," requiring data to traverse multiple hops (RAN->UPF->MEC), each requiring decapsulation and recapsulation, further increasing latency. More importantly, 5G's protocol stack header format lacks computational semantics, failing to carry information such as "operator ID + data pipeline ID," making it difficult to support in-path computing requirements. Furthermore, 5G also has shortcomings in synchronization and phase continuity, and computing power deployment. These issues prevent 5G networks from natively meeting the core requirements of sensing and intelligent computing, such as "multicast / in-path computing / stateful caching."

[0005] To address the aforementioned issues, this invention proposes a 6G physical layer-link layer data multicast and in-path computation method. Its core lies in introducing an independent data plane protocol to achieve the integration of data transmission and in-path processing. This invention, through innovative design of the link layer and physical layer, supports layered multicast, in-path computation, and dynamic CP-UP-DP data collaborative offloading, thereby better meeting the needs of 6G intelligent computing services. Summary of the Invention

[0006] To overcome the existing problems and shortcomings, this invention proposes a 6G physical layer-link layer data multicast and in-path computation method, including the following steps:

[0007] S1 Multicast Group Configuration: The base station configures multicast group information for a group of user equipment (UE) through signaling and assigns a multicast group identifier (G_RNTI).

[0008] S2 Multicast Transmission: The sending node sends multicast data to the receiving node group through the physical layer shared channel; the multicast data adopts a structured data format at the physical layer and includes physical layer control data and data payload;

[0009] S3 layered in-path processing: After receiving multicast data, the receiving node performs the following layered processing:

[0010] At the physical layer, identify structured data segments within the data payload;

[0011] Identify the computed PDU (CompPDU) carried in a protocol data unit (PDU) at least in at least one of the packet data convergence protocol (PDCP) layer, radio link control (RLC) layer, or media access control (MAC) layer.

[0012] And execute the corresponding in-path computation task based on the pipe ID and operator code;

[0013] S4 Result Processing: Based on the results of the in-path calculation, the results are stored locally, reported to the upper layer, or relayed through the physical channel.

[0014] Furthermore, the multicast transmission described in step S2 includes downlink multicast transmission:

[0015] The sending node is the base station, and the receiving node is the UE;

[0016] The base station is configured with a dedicated group search space for multicast groups, within which the UE listens for the physical downlink control channel (PDCCH).

[0017] The base station transmits control information containing Dedicated Multicast Scheduling (DCI format Multi-cast G) on the PDCCH to schedule multicast data transmission on the Physical Downlink Shared Channel (PDSCH);

[0018] The UE distinguishes between co-transmitted data blocks and independent data blocks according to the DCI format Multi-cast G, and performs corresponding data demodulation.

[0019] Furthermore, the multicast transmission described in step S2 includes uplink multicast transmission:

[0020] The transmitting node is a UE, and the receiving node is a base station group or multiple base stations;

[0021] The UE adopts a pre-allocated resource mode and transmits multicast data on the Physical Uplink Shared Channel (PUSCH) based on the multicast group base station identifier (NBG_RNTI) pre-allocated by the network side.

[0022] The PUSCH is used to carry uplink signals containing multicast control information (PHY Control Data) and multicast data payload; the base station receiving the multicast data determines whether to forward a copy of the data to other base stations in the multicast group based on the indication information in the multicast control information.

[0023] Furthermore, in the multicast group configuration described in step S1, when the signaling is a paging message, the UE implicitly provides feedback on whether the G_RNTI has been correctly received through the uplink reference signal (SRS);

[0024] The UE generates a first SRS sequence using the cyclic shift value α_(i_g) associated with the G_RNTI, and generates a second SRS sequence using the cyclic shift value α_i not associated with the G_RNTI;

[0025] The UE transmits the first SRS sequence and the second SRS sequence on the specified symbols respectively, so that the base station can determine the feedback result by measuring the signal deviation between the two;

[0026] The calculation formula for the cyclic shift value α_(i_g) incorporates a pre-distortion compensation amount to avoid it being the same as the value of α_i.

[0027] Furthermore, the multicast group configuration described in step S1 also includes a multicast paging reliability enhancement mechanism, which comprises at least one of the following:

[0028] Paging range narrowing retransmission: If no feedback is received within the expected time, the base station will exclude UEs that have already responded in the retransmitted paging message based on the feedback information already received, and only paging UEs that have not responded.

[0029] Paging frequency hopping: At each paging opportunity (PO), the base station uses different physical resource blocks (PRBs) to send paging messages in order to combat frequency selective fading;

[0030] PO density dynamic adjustment: After the UE detects the first multicast group creation notification, it starts PO adjustment to increase PO density. The UE and the base station use implicit synchronization to expand the PO time domain density, and select the downlink time slot at the middle position between the original PO positions as the new PO position.

[0031] Furthermore, in the multicast group configuration described in step S1, when the signaling is a Group Media Access Control Unit (Group MAC CE), a fixed control unit radio network temporary identifier (CE_RNTI) is used to distinguish the Group MAC CE; the UE uses the CE_RNTI to receive the Group MAC CE during network configuration monitoring.

[0032] Furthermore, in the multicast transmission described in step S2, the demodulation reference signal (DMRS) of the physical layer control channel is a code division multiplexing (CDM) orthogonal sequence generated based on the Frank-Heimiller sequence to support multilayer multiple input multiple output (MIMO) transmission.

[0033] Furthermore, it also includes a reference signal spatial multiplexing step:

[0034] In the multicast transmission described in step S2, when transmitting reference signals (RS) for different antenna ports, a spatial multiplexing mechanism using shared resource elements (REs) is employed.

[0035] Different antenna ports transmit their respective reference signals at the same time-frequency resource location, reducing RS resource overhead through spatial isolation or code domain differentiation.

[0036] Furthermore, in the multicast data described in step S2, the physical layer control data includes a data type indicator bitmap.

[0037] The bitmap is used to indicate the data types contained in the data payload, including: multicast group management and control data, channel state and QoS adaptation data, synchronization and timing data, security and privacy protection data, and AI model inference input data.

[0038] Furthermore, in the hierarchical as-along processing described in step S3, the PDU structure of the link layer includes:

[0039] PDCP layer: The PDCP PDU header contains common information, in-path localized PDU control information, and transport PDU control information forwarded by the upper layer;

[0040] RLC layer: The RLC PDU header contains segmentation information and transmission sequence number, and includes a multiplexed field indicating the length or sequence number of subsequent data blocks;

[0041] MAC layer: The extended logical channel identifier (eLCID) is used in the subheading of the MAC PDU to indicate that the current data packet carries a CompPDU, and the number and length of the CompPDUs are indicated in the subsequent bytes;

[0042] The CompPDU contains data that is processed only at the current layer, and its header contains a group UE identifier bitmap or ID to indicate which UEs in the group need to process the data; the TransPDU contains data that needs to be forwarded to the upper or lower layer.

[0043] Furthermore, the Pipe ID used in the in-path computation task described in step S3 is used for at least one of the following functions:

[0044] Distinguish between concurrent multicast computation task flows;

[0045] As an intermediate node, it maintains the index key for computational state information;

[0046] Bind specific computational logic or operator functions;

[0047] Supports instantiation and resource isolation of multicast trees.

[0048] Furthermore, in the result processing described in step S4, the relay transmission via physical channel includes:

[0049] Set up a relay data segment at the end of the payload of the physical layer data structure or at a specified position, and indicate the dataset to be relayed through a relay indicator;

[0050] The receiving node identifies the relay indicator and relays the corresponding dataset through the sidelink or uplink / downlink, carrying the operator ID + pipe ID in the forwarding protocol header.

[0051] Beneficial effects:

[0052] This invention proposes a 6G physical layer-link layer data multicast and in-path computation method, which has the following advantages compared with the prior art:

[0053] Improve air interface resource utilization: By introducing multicast group identifier (G_RNTI) and multicast scheduling DCI, multiple users can share the same set of control and data channel resources; combined with the spatial multiplexing mechanism of reference signal, pilot overhead is further reduced in multi-TRP scenarios.

[0054] Achieving low-latency in-path computing: By introducing structured PDUs containing pipe IDs and operator codes into PDCP, RLC, MAC, and the physical layer, network nodes can directly identify and execute computing tasks during data transmission, avoiding the long latency caused by repeated data uploads to the cloud for processing, and meeting the real-time requirements of 6G intelligent computing services.

[0055] Enhanced multicast transmission reliability: It provides an implicit feedback mechanism based on SRS sequences and a dynamic paging timing (PO) density adjustment mechanism, which effectively solves the problems of lack of feedback confirmation and low reception success rate in traditional multicast / paging scenarios.

[0056] Supports flexible network topology and relay transmission: By directly parsing relay indicators and forwarding datasets through the physical layer, it supports direct relay forwarding of data between UEs or nodes without uploading to higher layers for decoding, thus adapting to the multi-hop transmission requirements of any topology in 6G networks. Attached Figure Description

[0057] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0058] Figure 1 This application provides a logical architecture diagram of a 6G network supporting synergistic intelligent computing on three sides.

[0059] Figure 2 This application provides a schematic diagram of the interaction between core network and wireless network data plane functional network elements in an embodiment of the present application.

[0060] Figure 3 A layered protocol stack architecture diagram of control plane, user plane, and data plane provided for embodiments of this application;

[0061] Figure 4 This application provides a data plane and user plane / control plane protocol layer mapping diagram for embodiments of the present application.

[0062] Figure 5 This application provides a functional module architecture diagram for the link layer (L2) sublayer, as shown in the embodiments of this application.

[0063] Figure 6 This is a flowchart of the PDCP layer multicast data transmission process provided in an embodiment of this application;

[0064] Figure 7 A flowchart of PDCP layer multicast data reception and offloading processing provided in the embodiments of this application;

[0065] Figure 8 A schematic diagram of the general structure of the PDCP data protocol data unit (PDU) provided in the embodiments of this application;

[0066] Figure 9 This application provides a diagram illustrating the field definitions of the calculated PDU and transmitted PDU in the PDCPPDU.

[0067] Figure 10 A flowchart of RLC layer multicast data transmission processing provided in the embodiments of this application;

[0068] Figure 11 A flowchart of RLC layer multicast data reception and processing provided in the embodiments of this application;

[0069] Figure 12 This is a schematic diagram of the RLCPDU structure and its associated calculation fields provided in the embodiments of this application;

[0070] Figure 13 A flowchart of MAC layer multicast data transmission processing provided in an embodiment of this application;

[0071] Figure 14 A flowchart of MAC layer multicast data reception and processing provided in an embodiment of this application;

[0072] Figure 15 A diagram of the MACPDU subheader structure based on the extended logical channel identifier (eLCID) provided for embodiments of this application;

[0073] Figure 16 A schematic diagram of the PDCCH multicast scheduling DCI format and search space provided for embodiments of this application;

[0074] Figure 17 A flowchart of physical layer signal processing for multicast and unicast DCI multiplexing provided in this application embodiment;

[0075] Figure 18 This is a schematic diagram of the PDSCH / PUSCH physical layer structured multicast data format provided in an embodiment of this application;

[0076] Figure 19 A flowchart of paging-based multicast group configuration and SRS implicit feedback provided for embodiments of this application;

[0077] Figure 20 A flowchart illustrating the multicast group configuration and signaling interaction based on MAC CE provided in this application embodiment;

[0078] Figure 21 A schematic diagram of the physical layer multicast relay transmission data structure and Flag indicator bits provided in the embodiments of this application;

[0079] Figure 22 A schematic diagram illustrating the spatial multiplexing principle of the reference signal (RS) port resources provided in this application embodiment. Detailed Implementation

[0080] The present application will be described below with reference to specific embodiments:

[0081] Example 1:

[0082] This embodiment provides a 6G network system architecture and protocol processing method that supports the integration of communication, sensing, intelligence, and computing. The system architecture is logically divided into a control plane (CP), a user plane (UP), and a data plane (DP), achieving efficient multicasting and in-path computing through a three-plane cooperation mechanism.

[0083] To facilitate understanding of the technical solutions of this application, the following explains the abbreviations, technical terms, and English codes used in this application:

[0084] User Equipment (UE)

[0085] Group Radio Network Temporary Identifier (G_RNTI): Used to identify a specific multicast group;

[0086] Packet Data Convergence Protocol (PDCP)

[0087] Radio Link Control (RLC)

[0088] Medium Access Control (MAC);

[0089] Protocol Data Unit (PDU)

[0090] Computation PDU (CompPDU): A data unit that carries a computing task, as defined in this application.

[0091] Transmission PDU (TransPDU): A data unit defined in this application for regular data forwarding;

[0092] Pipe ID: Pipeline Identifier, used to identify specific data computation logic and routing path;

[0093] Operator Code (OpCode): Operation Code, used to indicate the specific type of computation operator;

[0094] Group Search Space;

[0095] Physical Downlink Control Channel (PDCCH);

[0096] Physical Downlink Shared Channel (PDSCH);

[0097] Physical Uplink Shared Channel (PUSCH);

[0098] Dedicated Multicast Scheduling (DCI): DCI format Multi-cast G;

[0099] Multicast Group Base Station Identifier (NBG_RNTI): Network Based Group RNTI, used for base station group identifiers pre-assigned by the network side;

[0100] Multicast control information: PHY Control Data;

[0101] Upward Reference Signal (SRS)

[0102] Paging Occasion (PO)

[0103] Physical Resource Block (PRB)

[0104] Group Media Access Control Layer Control Unit: Group MAC CE;

[0105] Control Element RNTI (CE_RNTI);

[0106] Demodulation Reference Signal (DMRS)

[0107] Code Division Multiplexing (CDM)

[0108] Multiple-Input Multiple-Output (MIMO)

[0109] Reference Signal (RS)

[0110] Resource Element (RE)

[0111] Data Type Indicator Bitmap;

[0112] Extended Logical Channel Identifier (eLCID);

[0113] Relay Indicator;

[0114] Sidelink: refers to a link that allows direct communication between devices.

[0115] like Figure 1 As shown, the overall design framework of this invention covers three dimensions: business scenarios, network protocols, and management orchestration. Regarding the network-side logical architecture, as... Figure 2 As shown, the 6G core network (6GC), while retaining control plane network elements (such as AMF, SMF, etc.) and user plane network elements (UPF), sets up a data plane function network element (DPF). The DPF, as the aggregation and processing center for data plane information, is responsible for interacting with service gateway nodes such as network intelligent data analysis and sensing functions, and processing connectionless machine data streams. On the radio access network (6GR) side, the internal protocol stack of the base station (XNB) extends the radio access network data plane (RAN-DP) beyond the control plane and user plane. RAN-DP is used to support connectionless data transmission and in-band computation processing, enabling real-time data processing during transmission.

[0116] To further illustrate the functional distribution of network elements at each level, such as Figure 3 As shown, the system is designed in a hierarchical manner from UE, RAN, core node to gateway node. Regarding the protocol stack architecture, as... Figure 4As shown, this embodiment employs a layered design for the interface protocols between User Equipment (UE), base stations, and the core network. Above the logical link layer, the system introduces a Data Analysis Function (DAF) module. This module, as a functional entity of the data plane L3 layer, is responsible for multicast transmission management, higher-layer in-path processing, and data forwarding between network elements. Accordingly, the system defines three types of radio bearers: Signaling Radio Bearer (SRB) for transmitting control plane signaling; User Radio Bearer (URB) for transmitting connection-oriented traditional communication services (such as video and voice), which follows IP 5-tuple addressing and intermediate nodes maintain stateless forwarding; and Data Radio Bearer (DRB) dedicated to the data plane. The Data Radio Bearer (DRB) is configured as a computable, orchestratable, machine-oriented distributed pipeline, supporting the opening, processing, and reassembly of data at intermediate nodes along the transmission path.

[0117] To enable interaction between the user plane and the data plane, as well as precise control of in-path computation, this embodiment defines the interaction interface information elements between the user plane and the data plane, specifically including Pipe ID, Operator Code, Computation Version Number, Computation Result Verification Code, and Cache Snapshot Token.

[0118] The pipeline ID identifies a specific data computation logic and routing path, with a configurable length of 32 bits. Data plane nodes select the corresponding computation graph and next-hop routing list based on the pipeline ID, thereby distinguishing concurrent multicast computation task flows and ensuring end-to-end data routing consistency. The operator code (OpCode) indicates the specific computation operator type, with a configurable length of 16 bits. Operator types include, but are not limited to, pass-through, downsampling, gradient averaging, and AI inference. Data plane nodes dynamically load the corresponding lightweight operator (such as WASM or Python operators) based on the OpCode to process the data. The computation version number is carried during data plane back-injection, allowing the user plane to determine whether to update the model cache or trigger incremental billing. The computation result checksum (such as CRC-8) is used for data reliability verification, supporting only retransmission of failed computation segments. The cache snapshot token supports stateful computation, enabling hot state migration between data plane nodes.

[0119] Based on the above architecture and parameters, the system's cross-layer collaboration process is as follows: Figure 5As shown: The control plane (such as the RRC layer) is responsible for system message broadcasting, connection management, and configuring resources such as computing power forecasting and intelligent wireless slicing, providing configuration information for the user plane and data plane. The user plane's SDAP layer has the ability to exchange information laterally with the data plane module DAF, and is responsible for identifying service flow attributes and guiding them to the corresponding URB or DRB. The link layer (including PDCP, RLC, and MAC layers) uniformly supports the CP, UP, and DP planes. The PDCP layer can simultaneously process signaling, user data, and data plane data. For data plane data, the link layer and physical layer identify and execute the corresponding multicast transmission and in-path computation tasks based on the pipe ID and operator code carried in the data packet. The core network and base stations use the GTP-D protocol as the data plane transmission bearer protocol.

[0120] Example 2:

[0121] This embodiment, in conjunction with the accompanying drawings, details the specific processing logic and Protocol Data Unit (PDU) structure of each sublayer of the Link Layer (L2) when performing multicast and in-path computation, covering the complete process of the PDCP, RLC, and MAC layers in the sending and receiving directions.

[0122] (1) PDCP layer processing mechanism and PDU format

[0123] Reference Figure 6 and Figure 7 This section explains the bidirectional processing logic of the PDCP layer. At the sending end, the PDCP entity receives SDUs from the SDAP layer and encapsulates them into PDCP PDUs containing both a "Computed PDU (CompPDU)" and a "Transmitted PDU (TransPDU)". At the receiving end, the process is no longer a simple decapsulation. After parsing the PDU, the PDCP entity performs a splitting operation: on one hand, it identifies and extracts the CompPDU, which directly enters the local "CompPDU processing" module for in-path computation (such as aggregation or inference based on operator ID); on the other hand, it identifies and extracts the TransPDU, which, after reordering, is restored to an SDU and delivered to the upper layer (SDAP).

[0124] To support the above process, this invention defines a dedicated PDU structure. Please refer to... Figure 8 The PDU consists of three parts: PDCP Header, which contains common control information; Computation PDU, which contains data that needs to be processed locally and consists of Subheader and Data; and Transmission PDU, which contains data that needs to be forwarded and also consists of Subheader and Data.

[0125] Further refine the internal fields of the PDU, such as Figure 9 As shown in the diagram, the definition of each byte (Oct 1) is illustrated in detail. The first byte (Oct 1) contains the D / C field, the PDU type field, and the TransPDU SN (transmission sequence number). All TransPDUs share this SN for reordering and reporting to higher layers. A special transmission end indication mechanism is used here: when the TransPDU SN is all 0, it indicates that this round of data collection has ended, meaning that this PDU is the last in the current transmission sequence.

[0126] The second byte (Oct 2) contains CompPDU Length / SN, which is a variable multiplexing field where the bits of SN that can be borrowed are notified to the UE via RRC configuration.

[0127] The following bytes (Oct m to n) illustrate the specific structure of the CompPDU Block. CompPDU, or Computed PDU, is the data processed by the PDCP layer. It consists of two parts: a Subheader and Data. The Subheader contains UE identification information within the group and the length of the Padding bytes. As shown in the figure, this identification can take the form of a UE RNTI (16-bit), a short ID within the group (8-bit / 4-bit), or a UE Bitmap. This allows the sender to flexibly indicate which UEs within the group can ignore the subPDU (i.e., indicating which UEs do not need to process the data, or conversely, indicating which UEs do need to process it), thus saving processing overhead. Similar to TransPDU, if all SNs in the Subheader are 0, it also indicates that the current round of data collection is complete. The Data part contains valid data and padding.

[0128] The following bytes (Oct x to y) show the TransPDU Block, i.e., the transport PDU, used to forward data to or from the upper layer, containing valid data and padding. The tail of the PDU may contain an optional MAC-I field for integrity protection. (2) RLC layer processing mechanism and PDU format

[0129] For information on the processing mechanism of the RLC layer, please refer to [link / reference]. Figure 10 The RLC layer and PDCP layer employ an asynchronous pipelined model, exchanging data in a first-in, first-out (FIFO) manner using a buffer. As shown in the diagram, in the receiving direction, the RLC entity decomposes the received RLC PDU into RLC CompPDU and RLC TransPDU. The RLC CompPDU is sent to the local processing entity of the RLC layer; the RLC TransPDU is reassembled into an SDU and delivered to the PDCP layer.

[0130] Correspondingly, such as Figure 11 As shown, in the transmission direction, the RLC entity receives the PDU from the PDCP layer as the RLC SDU, and may combine it with locally generated computational data to construct an RLC PDU containing RLC CompPDU and RLC TransPDU, which is then delivered to the MAC layer.

[0131] Please refer to the specific PDU format of the RLC layer. Figure 12 The diagram shows that RLC PDUs also use a segmented structure. The first byte contains segmentation information (SI) and a transmission sequence number (TransPDU SN). The TransPDU SN is used by the receiver to report to higher layers after reordering and other operations; all TransPDUs share a single SN. When the SN is all 0, it indicates that the data collection for this round is complete, and this PDU is the last one.

[0132] Following this is the CompPDU Length / SN field, which is a variable multiplexing field. The bits that the SN can borrow are notified to the UE through configuration.

[0133] CompPDU is the data processed by the RLC layer. Its structure includes a Subheader and Data. The Subheader contains the length of the Padding bytes and the UE identifier within the group (UE RNTI, 8-bit or 4-bit group sequence number), used to indicate which UEs within the group can ignore this subPDU to save overhead; if the SN in the Subheader is all 0, it also indicates that the data collection for this round is complete. The Data part contains the valid data and Padding data. TransPDU is the data forwarded to the upper layer for processing, containing valid data and Padding data.

[0134] Furthermore, this embodiment defines a multicast lifecycle management mechanism based on the RLC / PDCP layer: multicast is defined as a temporary behavior that can be continuously reassembled into groups as needed. A group begins when the configuration of the relevant UE is complete; it ends when the source indicates the end of this round of data collection (e.g., via the aforementioned all-zero SN indicator), at which point the temporary group has terminated for that UE. If the UE is not indicated to have terminated, it continues to use the group. It should be noted that a UE may simultaneously be in multiple groups for data transmission and reception. If a UE's data is still in transmission while other UEs in the same group have completed their current round of transmission and reception, that UE can continue to use the corresponding group for data transmission and reception until successful transmission or timeout. Ultimately, the RAN side determines the start and termination behavior of a group.

[0135] (3) MAC layer processing mechanism and PDU format

[0136] The MAC layer is the first hurdle in implementing multicast routing. For example... Figure 13 At the receiving end, the MAC entity receives transport blocks from the physical layer (PHY) and parses out the MAC PDU. The MAC entity identifies the multicast computed sub-PDU (CompPDU) and ordinary sub-PDU within the PDU. The CompPDU is extracted and processed or fed back at the MAC layer, while the subPDU is restored to an RLC PDU and delivered to the RLC layer.

[0137] Correspondingly, such as Figure 14 At the sending end, the MAC entity receives the SDU from the RLC layer and combines it with the multicast computed data (MAC CompPDU) generated by the MAC layer itself and the possible MAC CE to construct a complete MAC PDU, which is then sent to the physical layer as a transport block.

[0138] To quickly identify at the MAC layer that "this is a packet of multicast data that needs to be computed," this invention utilizes eLCID (Extended Logical Channel Identifier) ​​in the MAC subheader. The specific structure is as follows: Figure 15 As shown:

[0139] The first byte contains the standard R / F / LCID field, where the LCID value points to the extended identifier. The second byte (eLCID-CompPDU) uses the eLCID value reserved for 5G / 6G, specifically indicating that the current MAC SDU carries a CompPDU. The third byte contains the Total number of CompPDUs (indicating the total number of subsequent computed PDUs) and the U bit (Unitbit). The U bit is a crucial length granularity indicator: when U=0, it indicates that the subsequent length field is in units of 8 bytes (N=8); when U=1, it indicates that it is in units of 16 bytes (N=16). This design effectively compresses the overhead of the length indicator field. Subsequent bytes list the length of each CompPDU, followed by the specific Data Block.

[0140] This invention supports bidirectional multicast and in-path computation for both downlink (DL) and uplink (UL).

[0141] For the downlink, refer to Figure 16 The entire DL MAC PDU is composed of multiple MAC SubPDUs cascaded together. The MAC SubPDU containing the CompPDU (carrying the eLCID) is placed at the front of the PDU or in a designated position, followed by the SubPDU containing the MACCE or MAC SDU and the padding.

[0142] For the uplink, refer to Figure 17 UL MAC PDUs also support carrying multicast CompPDUs. As shown in the figure, SubPDUs containing CompPDUs, together with other SubPDUs carrying MAC SDUs or MAC CEs, form an uplink transport block, enabling the UE to send computed data or feedback information that needs to be processed along with the network while uploading data.

[0143] With the above MAC layer design, when the MAC entity is parsing, once it scans a Subheader containing a specific eLCID, it directly extracts the CompPDU part for physical layer feedback or local calculation based on the subsequent length indication, without having to pass this part of the data through the RLC layer, thus achieving efficient "zero-copy link layer" processing.

[0144] Example 3:

[0145] This embodiment focuses on the design of data transmission format, channel processing flow, and control information of the physical layer (PHY) when supporting multicast and in-path computing. Unlike traditional physical layers that only focus on bit transmission, the physical layer in this embodiment has the ability to identify "multicast groups" and "computation tasks," and supports efficient multicast scheduling and feedback through PDCCH, PDSCH, and PUSCH channels.

[0146] (1) Physical layer multicast scheduling and control mechanism

[0147] To achieve dynamic scheduling of multicast data, this embodiment introduces a dedicated multicast scheduling mechanism (DCI formatMulti-cast G). When the UE monitors the PDCCH, its monitoring space is logically divided into the following three categories:

[0148] Common Search Space: Used to monitor common control information such as system broadcast (BCCH), paging (PCH), and random access (RACH).

[0149] UE-specific Search Space: Used to monitor unicast scheduling information scrambled by C-RNTI and process dedicated data (DCCH / DTCH) for specific UEs.

[0150] Group Search Space: This is a new logical space added in this embodiment, where the UE monitors the DCI scrambled by G_RNTI (Group RNTI).

[0151] When a UE detects DCI format Multi-cast G in the group search space, it receives multicast data packets on the PDSCH according to the indication information in the DCI. This DCI format is designed to include a common field, a shared data scheduling field, and an independent data scheduling field. The shared data scheduling field allows multiple UEs to share the same set of DCI control and resource allocation information to save control channel overhead; the independent data scheduling field indicates the independent control parameters for each UE.

[0152] For the signal processing flow of PDCCH, this embodiment supports the multiplexing of multicast and unicast DCI. The specific processing logic is as follows: The physical layer first performs CRC attachment on the multicast DCI (DCI Data) and uses G_RNTI to scramble the CRC; then channel coding and rate matching are performed; in the multiplexing stage, the multicast DCI and unicast DCI are multiplexed, and after scrambling, modulation and resource element mapping, it is finally mapped to the PDCCH physical resources for transmission.

[0153] To further improve the capacity and reliability of PDCCH, this embodiment introduces a PDCCH MIMO transmission mechanism. By introducing CDM orthogonal sequences of PDCCH DMRS, multi-layer capability extension is achieved, enabling spatial multiplexing.

[0154] The UE assumes that the complex-valued modulation symbol to be transmitted Modulation symbols are mapped to several layers according to the following rules. ,in , Indicates the number of floors. This indicates the number of modulation symbols in each layer. The specific mapping relationship is shown in Table 1:

[0155] Table 1. Mapping relationship between Modulation symbols and layers

[0156] Number of layers Modulation symbols to layer mapping 1 = 2 = 3 =

[0157] Regarding antenna port mapping, data vectors Mapped to antenna port set according to a one-to-one rule :

[0158]

[0159] in ,and .

[0160] Correspondingly, PDCCH DMRS uses orthogonal sequences for differentiation. The UE will use the sequences... Map to resource elements according to the following rules :

[0161]

[0162] in:

[0163]

[0164]

[0165]

[0166] in It is a Frank-Heimiller sequence, defined as shown in Table 2:

[0167] Table 2 PDCCH DM-RS CDM group definition

[0168] CDM group 1 1 1 1 2 1 3 1

[0169] (2) PDSCH / PUSCH multicast data transmission format

[0170] Multicast data carried by the Physical Downlink / Uplink Shared Channel (PDSCH / PUSCH) uses a structured definition. Please refer to [link / reference]. Figure 18 This data structure does not need to be reported to higher layers; instead, it is directly parsed or constructed by the physical layer. The specific data format includes a control data portion and a data payload portion.

[0171] The control data section, as shown in the figure, includes a Data Type Indicator Bitmap, an OpCode, and a Pipe ID. The Data Type Indicator Bitmap indicates the type of dataset carried in this data structure (e.g., Type 1 Dataset...Type n Dataset).

[0172] Data load section: contains actual business data or calculation results.

[0173] The PDSCH multicast data transmission signal processing flow is as follows: The physical layer obtains the above-mentioned structured multicast data (PHY Multi-cast Data) as a transport block; CRC is attached to the transport block; scrambling is performed, where G_RNTI can be used for scrambling to distinguish multicast groups; then LDPC basemap selection, channel coding, rate matching, and code block concatenation are performed sequentially; the scrambled data is modulated, layer mapped, antenna port mapped, and VRB to PRB mapped, finally generating an OFDM baseband signal for transmission.

[0174] The transmission process of PUSCH multicast data is similar to that of PDSCH, but a transform precoding (optional) stage is added after modulation to reduce the peak-to-average power ratio.

[0175] For uplink multicast services, the UE transmits the PUSCH signal on pre-allocated or dynamically scheduled resources. In this case, the uplink signal carried by the PUSCH is logically configured as a composite stream containing multicast control information and multicast data payload.

[0176] During transmission, the UE uses the multicast group base station identifier (NBG_RNTI) pre-allocated by the network side to scramble or mask the data. NBG_RNTI is a special type of G_RNTI, specifically used to identify the target set of uplink multicast base stations. When any base station in the base station group receives the PUSCH signal and successfully descrambles it using NBG_RNTI, it recognizes the data as a multicast service. At this point, the receiving base station, based on the forwarding indication information in the multicast control information, determines whether to forward a copy of the data to other base stations in the group through the inter-base station interface (such as the Xn interface), thereby reducing backhaul overhead while achieving necessary collaborative processing.

[0177] (3) Multicast group configuration and paging feedback mechanism

[0178] The base station notifies the UE to establish a multicast group via paging messages. To address the lack of feedback in traditional paging, this embodiment introduces multiple feedback mechanisms, the interaction flow of which is as follows: Figure 19 As shown.

[0179] The base station (XNB) sends a paging message carrying the G_RNTI to a group of UEs. Upon receiving the paging message, a UE can acknowledge receipt to the base station using one of two methods:

[0180] Method 1: Implicit feedback based on uplink reference signal (SRS).

[0181] When generating the SRS sequence, the UE performs a cyclic shift of the SRS sequence. Associated with G_RNTI. Specifically, the UE uses normal cyclic shift on two specified adjacent OFDM symbols. and the associated cyclic shift of G_RNTI Generate SRS sequences.

[0182] Antenna port Corresponding cyclic shift The calculation formula is as follows:

[0183]

[0184] in:

[0185]

[0186] , This indicates the maximum number of cyclic shift values, and is configurable.

[0187] Used as the base circular shift index;

[0188] The pre-distortion compensation amount (deltaCS) is used to avoid and overlapping;

[0189] For frequency hopping or scrambling functions related to system frame number, time slot number and symbol index;

[0190] This refers to the transmission comb factor.

[0191] After receiving the SRS, the base station respectively based on and Channel measurements are performed on the corresponding sequence. If If the measured value of the sequence is higher than the specified threshold, it is determined that the UE has correctly received G_RNTI.

[0192] Method 2: Explicit feedback based on physical channels.

[0193] The UE carries acknowledgment information in the uplink physical control channel (PUCCH) or physical uplink shared channel (PUSCH). Specifically, the UE encodes and transmits G_RNTI ACK / NACK as part of the uplink control information (UCI). This feedback can be transmitted independently on the PUCCH resource or multiplexed with the HARQ-ACK of unicast data on the same PUCCH or PUSCH resource.

[0194] Furthermore, this embodiment also supports multicast group configuration via multicast MAC CE (Group MAC CE). The specific interaction process is as follows: Figure 20 As shown, it includes the following steps:

[0195] Step 1: Preliminary parameter configuration: The base station RRC layer sends out SRS parameters (cyclic shift index, repetition factor, deltaCS, etc.) and multicast control parameters (monitoring timing, feedback method configuration).

[0196] Step 2: Group creation: The base station RRC layer allocates G_RNTI and notifies the L2 layer to maintain the multicast group status.

[0197] Step 3: Send MAC CE: The base station MAC entity constructs a Multi-cast MAC CE, uses a fixed CE_RNTI scrambling, and sends G_RNTI configuration information to all UEs in the group.

[0198] Step 4: UE feedback: After receiving the MAC CE, the UE uses Alt 1 (SRS implicit feedback) or Alt 2 (explicit ACK / NACK) to confirm the configuration is effective to the base station.

[0199] Step 5 Maintenance: The base station physical layer reports the feedback results, and the RRC layer completes the multicast group activation.

[0200] (4) Multicast paging reliability enhancement mechanism

[0201] To address issues that may arise in multicast scenarios, such as UEs experiencing short periods of uplink transmission failure, poor channel quality, or paging loss, this embodiment designs three progressive reliability enhancement mechanisms:

[0202] Narrowing & Retrying: If the base station does not receive any feedback (SRS or ACK / NACK) from the UE within the expected time, or only receives feedback from some UEs, the retransmission mechanism is triggered first. During retransmission, the base station can narrow the target UE range for paging. That is, based on the feedback information already received, the base station excludes UEs that have already responded in the retransmitted paging message and only paging UEs that have not responded, thereby reducing air interface resource consumption and continuously sending several paging messages.

[0203] Paging Hopping: To combat frequency-selective fading, a paging hopping mechanism is introduced. During each paging occasion (PO), the base station uses different physical resource blocks (PRBs) to send paging messages. If no response is received after a certain number of frequency hopping retransmissions, the UE is deemed to have failed to join the group, and subsequent operations are abandoned.

[0204] Dynamic Paging Opportunity (PO) Density Adjustment: For data plane multicast services with high timeliness, PO density is dynamically expanded.

[0205] Triggering condition: When the UE has been configured with a data plane radio bearer and detects the first multicast group creation notification, PO density extension is initiated and a high-density PO window period is entered.

[0206] Extension Algorithm: PO time-domain density extension employs an implicit synchronization method. Between the two locations of the old PO, the UE and network select the intermediate DL Slot as the new PO location. The extended PO location set is calculated as follows:

[0207] PO_additional∈{slide(PO_base)∩DLslot,...slide[(PO factor -1)*(PO_base / PO factor )]∩DLslot},

[0208] Where, PO_base = floor[(PO n + PO n+1 ) / PO factor ].

[0209] Fallback mechanism: If no new multicast group notification is received within the high-density window, the UE automatically falls back to the default PO density to save power consumption.

[0210] (5) Physical layer multicast relay transmission mechanism

[0211] This embodiment supports relaying multicast data directly at the physical layer, without needing to upload it to a higher layer for decoding. The data structure for relay transmission is as follows: Figure 21 .

[0212] As shown in the figure, the physical layer structured data contains an F indicator bit (Flag).

[0213] When F=1, it indicates that the payload tail contains data to be relayed (Relay Data).

[0214] The Relay Data is indicated by the Relay Indicator, which specifies the dataset to which it belongs, and includes "operator ID + pipeline ID".

[0215] After the UE or relay node parses the data at the physical layer, it determines whether to perform a forwarding operation based on the Relay Indicator and the current channel status. If forwarding is performed, the data relay is carried out directly through the Sidelink (SL) or UL / DL channel.

[0216] The Pipe ID plays a crucial role in this mechanism, distinguishing concurrent multicast computation task flows, supporting intermediate nodes in state management and context identification, and binding computation logic with routing paths to ensure accurate matching between computation operations and data flows.

[0217] To address the reference signal (RS) overhead issue caused by multi-antenna transmission, this embodiment supports a space division multiplexing (SDM) mechanism for the reference signal. The specific processing flow is as follows: Figure 22 As shown.

[0218] In Multi-TRP or Combined Cell scenarios, because different antenna ports cover different geographical areas or have strong spatial isolation, the physical layer allows these ports to share the same resource elements (REs).

[0219] The specific implementation steps are as follows:

[0220] Resource configuration: The base station RRC layer (XNB RRC) determines the set of antenna ports with spatial isolation based on the network topology and the UE's channel state information.

[0221] Layer mapping and RE allocation: When the base station physical layer (XNB L1) performs CSI-RS or SRS resource mapping, it will allocate the first antenna port (Port) The reference signal is mapped to a specific time-frequency resource location (RE set). Simultaneously, the second antenna port, which is spatially isolated from the first antenna port, will... The reference signal is also mapped to the same set of REs. Instead of allocating orthogonal RE resources, it allocates them to the top.

[0222] Transmission and Detection: The base station simultaneously transmits reference signals from different ports at the same RE location. The receiving end (UE or base station) uses spatial filtering or beamforming gain to separate and measure the reference signals from different ports on the same time-frequency resources. Through this mechanism, "frequency domain concurrency" and "spatial domain multiplexing" of RS resources are realized, significantly reducing the occupation of data transmission resources by reference signals without reducing measurement accuracy.

[0223] It should be noted that the above embodiments can be freely combined as needed. The above are merely preferred embodiments of the present invention. It should be pointed out that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

[0224] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

Claims

1. A 6G physical layer-link layer data multicast and in-path computation method, characterized in that, Includes the following steps: S1 multicast group configuration: The base station configures multicast group information for a group of UEs via signaling and assigns G_RNTI; S2 Multicast Transmission: The sending node sends multicast data to the receiving node group through the physical layer shared channel; the multicast data adopts a structured data format at the physical layer and includes physical layer control data and data payload; S3 layered in-path processing: After receiving multicast data, the receiving node performs the following layered processing: At the physical layer, identify structured data segments within the data payload; Identify the CompPDU carried in the PDU at least in at least one of the PDCP, RLC, or MAC layers of the link layer; And execute the corresponding in-path computation task based on the Pipe ID and OpCode; S4 Result Processing: Based on the results of the in-path calculation, the results are stored locally, reported to the upper layer, or relayed through the physical channel.

2. The method as described in claim 1, characterized in that, The multicast transmission mentioned in step S2 includes downlink multicast transmission: The sending node is the base station, and the receiving node is the UE; The base station is configured with a dedicated Group Search Space for multicast groups, and the UE listens for the PDCCH within the Group Search Space; The base station sends control information containing dedicated multicast scheduling DCI format Multi-cast G on the PDCCH to schedule multicast data transmission on the PDSCH; The UE distinguishes between co-transmitted data blocks and independent data blocks according to the DCI format Multi-cast G, and performs corresponding data demodulation.

3. The method as described in claim 1, characterized in that, The multicast transmission mentioned in step S2 includes uplink multicast transmission: The transmitting node is a UE, and the receiving node is a base station group or multiple base stations; The UE adopts a pre-allocated resource mode and sends multicast data on the PUSCH based on the NBG_RNTI pre-allocated by the network side. The PUSCH is used to carry uplink signals containing PHY Control Data and multicast data payloads; the base station receiving the multicast data determines whether to forward a data copy to other base stations in the multicast group based on the indication information in the PHY Control Data.

4. The method as described in claim 1, characterized in that, In the multicast group configuration described in step S1, when the signaling is a paging message, the UE implicitly feedbacks via SRS whether it has correctly received the G_RNTI; The UE uses the cyclic shift value associated with the G_RNTI. Generate the first SRS sequence and use the cyclic shift value of the unassociated G_RNTI. Generate a second SRS sequence; The UE transmits the first SRS sequence and the second SRS sequence on the specified symbols respectively, so that the base station can determine the feedback result by measuring the signal deviation between the two; Wherein, the cyclic shift value The calculation formula introduces a predistortion compensation amount to avoid [interference with] They have the same value.

5. The method as described in claim 1, characterized in that, The multicast group configuration described in step S1 also includes a multicast paging reliability enhancement mechanism, which includes at least one of the following: Paging range narrowing retransmission: If no feedback is received within the expected time, the base station will exclude UEs that have already responded in the retransmitted paging message based on the feedback information already received, and only paging UEs that have not responded. Paging frequency hopping: At each PO, the base station uses different PRB resources to send paging messages to combat frequency selective fading; PO density dynamic adjustment: After the UE detects the first multicast group creation notification, it starts PO adjustment to increase PO density. The UE and the base station use implicit synchronization to expand the PO time domain density, and select the downlink time slot at the middle position between the original PO positions as the new PO position.

6. The method as described in claim 1, characterized in that, In the multicast group configuration described in step S1, when the signaling is Group MAC CE, a fixed CE_RNTI is used to distinguish the Group MAC CE; the UE uses the CE_RNTI to receive the Group MAC CE during network configuration monitoring.

7. The method as described in claim 1, characterized in that, In the multicast transmission described in step S2, for the DMRS of the physical layer control channel, a CDM orthogonal sequence based on the Frank-Heimiller sequence is used to support MIMO transmission.

8. The method as described in claim 1, characterized in that, It also includes the reference signal spatial multiplexing step: In the multicast transmission described in step S2, when RS is transmitted for different antenna ports, the spatial multiplexing mechanism of RE is used; Different antenna ports transmit their respective reference signals at the same time-frequency resource location, reducing RS resource overhead through spatial isolation or code domain differentiation.

9. The method as described in claim 1, characterized in that, The multicast data mentioned in step S2 includes a Data Type Indicator Bitmap in its physical layer control data. The Data Type Indicator Bitmap is used to indicate the data types contained in the data payload, including: multicast group management and control data, channel state and QoS adaptation data, synchronization and timing data, security and privacy protection data, and AI model inference input data.

10. The method as described in claim 1, characterized in that, In the hierarchical as-along processing described in step S3, the PDU structure of the link layer includes: PDCP layer: The PDCP PDU header contains common information, in-path localized PDU control information, and TransPDU control information for forwarding to the upper layer; RLC layer: The RLC PDU header contains segmentation information and transmission sequence number, and includes a multiplexed field indicating the length or sequence number of subsequent data blocks; MAC layer: The subheading of the MAC PDU uses eLCID to indicate that the current data packet carries a CompPDU, and the number and length of the CompPDUs are indicated in the subsequent bytes; The CompPDU contains data that is processed only in the current layer, and its header contains a group UE identifier bitmap or ID to indicate which UEs in the group need to process the data; the TransPDU contains data that needs to be forwarded to the upper or lower layer.

11. The method as described in claim 1, characterized in that, The Pipe ID used in the in-path computing task described in step S3 is used for at least one of the following functions: Distinguish between concurrent multicast computation task flows; As an intermediate node, it maintains the index key for computational state information; Bind specific computational logic or operator functions; Supports instantiation and resource isolation of multicast trees.

12. The method as described in claim 1, characterized in that, In the result processing described in step S4, the relay transmission via physical channel includes: Set a relay data segment at the end of the payload of the physical layer data structure or at a specified position, and use RelayIndicator to indicate the dataset to be relayed; The receiving node identifies the Relay Indicator, relays the corresponding dataset via Sidelink or uplink / downlink, and carries the operator ID and Pipe ID in the forwarding protocol header.

Images