Narrowband internet of things uplink channel processing framework and resource multiplexing and conflict protection method

Abstract

The application provides an NB-IoT uplink channel processing framework and a resource multiplexing and conflict protection method, relates to the technical field of narrowband Internet of Things data processing, and solves the problems of resource waste, data conflict, repeated requests and other limitations in the prior art. In the system, the front interface adaptation layer receives the C-plane message issued by the O-DU and the FFT frequency domain data output by the DFE, and distributes them to the subsequent processing layer; the control plane analysis and configuration layer analyzes the eAxC ID related information, distinguishes the channel type to which the data flow belongs, and dynamically configures the operation parameters; the DFE data acquisition and multiplexing layer acquires the uplink IQ data and stores it with the full quantum frame identifier, and performs data multiplexing determination during the readback; the signal demapping and packing layer performs demapping processing of the IQ data from the FFT frequency domain data to the RE, finally generates the U-plane data and reports it to the O-DU. The application effectively eliminates the data conflict risk and greatly improves the scalability of the system.

Description

Technical Field

[0001] This invention relates to the field of narrowband Internet of Things (NB-IoT) data processing technology, and is applied to open radio frequency units (O-RUs). Specifically, it relates to the NB-IoT uplink channel processing framework and its resource reuse and collision prevention methods. Background Technology

[0002] Narrowband Internet of Things (NB-IoT), as an important IoT technology, includes the Narrowband Physical Random Access Channel (NPRACH) and the Narrowband Physical Uplink Shared Channel (NPUSCH) in its uplink direction. In the Open Radio Access Network (O-RAN) architecture, the Open Radio Unit (O-RU) needs to interact with the Open Distributed Unit (O-DU) via the fronthaul interface to exchange control plane (C-plane) and user plane (U-plane) messages to complete the reception and reporting of uplink signals.

[0003] When integrating NB-IoT channels into an O-RU hardware platform that already supports Long Term Evolution (LTE) and New Radio (NR), the fronthaul interface typically allocates independent extended antenna carrier (eAxC) identifier intervals according to channel type to distinguish data streams. Because NB-IoT channels have narrow bandwidth and limited concurrency, allocating intervals independently for each channel would consume a large amount of address resources, resulting in extremely low fronthaul interface resource utilization.

[0004] In the data buffering and scheduling phase, NPRACH supports repetition and frequency hopping mechanisms. The subframe numbers indicated by the control plane messages issued by the O-DU are often non-contiguous (e.g., subframes 0, 1, 2, 4, rather than the contiguous 0, 1, 2, 3). Existing designs, under conventional continuous subframe scheduling, typically use only the least significant bit of the subframe number as the buffer addressing identifier (because the parity interval is sufficient for differentiation under conventional continuous subframe scheduling). However, in non-contiguous scheduling scenarios, the least significant bit of different subframe numbers is very likely to be the same (e.g., the least significant bit of subframes 2 and 4 are both 0). This will cause newly arriving data messages to directly overwrite previously unprocessed data, leading to serious data errors or fronthaul interface section description conflicts, thus compromising the integrity and correctness of uplink data.

[0005] During the data acquisition phase, the fronthaul protocol allows the O-DU to describe the scheduling information of different resource blocks (RBs) within the same uplink symbol through multiple consecutively arriving C-plane Section messages. If the adapter on the O-RU side re-initiates a single data request to the Digital Front End (DFE) for each arriving Section message, a large number of unnecessary duplicate requests will be generated in scenarios where the same symbol is repeatedly referenced by multiple segments. This not only significantly increases the bandwidth consumption and processing latency of the digital front end interface, but also poses a potential risk of obtaining inconsistent data due to misaligned request timing, seriously affecting the real-time performance and stability of the system.

[0006] In the frequency domain demapping stage, the extraction rules for the frequency domain data output from the Fast Fourier Transform (FFT) of NPRACH and NPUSCH channels differ significantly, involving different parameters such as FFT size, effective number, fold boundaries, and inversion bit width. Existing engineering implementations typically design independent demapping hardware modules for each channel type and fix their proprietary parameters. When a new supported standard or sub-format is added, a complete new hardware path must be added, causing hardware resource consumption and development and verification costs to rise sharply with the increase in the number of supported standards, lacking sufficient flexibility and scalability.

[0007] The aforementioned problems exist in different stages, including fronthaul interface address allocation, buffer addressing, DFE data acquisition, and frequency domain demapping. However, their common root cause lies in the isolated and independent resource allocation and signal processing design approach adopted when integrating narrowband low-rate channels into a broadband hardware platform. This fragmented design not only results in severe waste of hardware and interface resources but also introduces multiple potential conflict risks. Therefore, there is an urgent need for a globally unified collaborative processing mechanism that can coordinate fronthaul interface resources, subframe addressing, data multiplexing, and hardware demapping paths to completely resolve resource bottlenecks and conflict risks in multi-standard fusion scenarios and improve the overall system's processing efficiency and reliability. Summary of the Invention

[0008] The purpose of this invention is to address the problems arising from the independent design of resource allocation and signal processing methods for each channel when integrating NB-IoT uplink channels into a broadband O-RU hardware platform. These problems include wasted eAxC ID resources, buffer data overlay conflicts under discontinuous scheduling, duplicate DFE data requests in multi-section scenarios with the same symbol, and redundant construction of FFT to RE demapping hardware paths. This invention proposes an NB-IoT uplink channel processing framework and its resource reuse and conflict prevention methods. It achieves this by sharing eAxC IDs between NPRACH and NPUSCH and jointly decoding C-plane message fields to dynamically configure parameters. Simultaneously, it combines full quantum frame identifier storage along the path, DFE data reuse determination based on symbol key values, and a parameterized FFT to RE demapping pipeline shared by multiple standards for collaborative processing. This invention can significantly reduce the resource consumption and overall hardware complexity of the O-RAN fronthaul interface while ensuring no interference between channels, effectively eliminating data conflict risks and greatly improving system scalability.

[0009] The present invention employs the following technical solutions to achieve its objective: An NB-IoT uplink channel processing framework includes a fronthaul interface adaptation layer, a control plane parsing and configuration layer, a DFE data acquisition and multiplexing layer, and a signal demapping and packaging layer; the narrowband physical random access channel NPRACH and the narrowband physical uplink shared channel NPUSCH share the overall structure of this framework. The fronthaul interface adaptation layer is used to receive the O-RAN fronthaul control plane C-plane messages issued by the Open Distributed Unit (O-DU) and the Fast Fourier Transform (FFT) frequency domain data output by the Digital Front-End (DFE), and adapts and distributes the C-plane messages and FFT frequency domain data to the subsequent processing layer; NPRACH and NPUSCH share the interface resources of the fronthaul interface adaptation layer. The control plane parsing and configuration layer is used to parse the antenna carrier identifier eAxC ID and associated control fields in the C-plane message, distinguish the channel type to which the current data stream belongs and determine the corresponding sub-format configuration parameters, and dynamically configure the operating parameters of the hardware processing module based on the channel type and sub-format configuration parameters. The DFE data acquisition and multiplexing layer is used to initiate data requests to the DFE based on the scheduling information in the C-plane message, acquire the corresponding uplink IQ data and store it in the buffer along with the full quantum frame identifier. During data readback, the buffer addressing and data differentiation are performed based on the full quantum frame identifier. Data multiplexing is determined for multiple consecutive C-plane segment section messages of the same uplink symbol, and the IQ data to be processed is output. The signal demapping and packing layer is used to perform FFT frequency domain data to resource element (RE) demapping on the IQ data to be processed according to the subformat configuration parameters, extract the valid RE data and compress and pack it to generate user plane U-plane data and report it to O-DU.

[0010] Specifically, NPRACH and NPUSCH share the same eAxC ID range; the control plane parsing and configuration layer is also used to read the filterIndex field corresponding to the eAxC ID in the C-plane message. When the filterIndex field takes the first specific value, it indicates that the current data stream belongs to the NPRACH processing path. When the filterIndex field takes the second specific value, it indicates that the current data stream belongs to the NPUSCH processing path. The control plane parsing and configuration layer is also used to read the lower 4 bits of the FrameStructure field after determining the channel type, and then decode the specific sub-format currently used by the channel, including the combination of subcarrier spacing, FFT size and RE number; The control plane parsing and configuration layer is also used to combine the channel type and specific sub-format obtained by joint decoding as an index to drive the hardware processing module to perform parameter configuration lookup.

[0011] Preferably, the DFE data acquisition and multiplexing layer is also used in the non-continuous subframe scheduling scenario of NPRACH to expand the subframe identification signal into a 4-bit full quantum frame identification to represent the complete subframe number, and then write the full quantum frame identification as part of the data, together with the actually received uplink IQ data, into the corresponding storage unit of the buffer. The DFE data acquisition and multiplexing layer is also used to backfill the latched full quantum frame identifier into the subframe identifier field in the uplink forward data message header during data readback, so as to perform buffer addressing and data differentiation based on the complete subframe number.

[0012] Specifically, the DFE data acquisition and multiplexing layer is also used in the NPUSCH scenario when the same uplink symbol corresponds to multiple consecutively arriving C-plane Section messages. It calculates a symbol key value for each arriving Section message. The symbol key value is determined by a combination of carrier identifier, layer identifier, subframe number and symbol number to uniquely identify the specific symbol described by the Section message. The DFE data acquisition and reuse layer is also used to compare the corresponding calculated symbol key value with the previously processed and cached symbol key value when processing each newly arrived Section message. If the comparison result is the same, it is determined to be a subsequent Section message of the same symbol, and the cached DFE data is directly reused without repeatedly sending data requests to the DFE. If the comparison result is different, it is determined to be a new symbol, and a data request is sent to the DFE to update the cached symbol key value.

[0013] Specifically, the signal demapping and packing layer includes a set of parameterized FFT frequency domain data to RE sequence space demapping hardware pipeline shared by NPRACH and NPUSCH; The signal demapping and packing layer is also used to look up the corresponding FFT size, effective RE count, frequency domain folding boundary and bit-reverse width parameters by using the decoded format and sub-format combination value as an index. The demapping operation unit in the demapping hardware pipeline is used to perform demapping operations on the IQ data to be processed, extracting valid RE data, using the FFT size, number of valid REs, frequency domain folding boundary and bit-reverse width parameters obtained by looking up the table.

[0014] This invention also provides a resource reuse and collision prevention method based on the aforementioned NB-IoT uplink channel processing framework, the method comprising the following steps: S1. Receive the O-RAN fronthaul C-plane message sent by O-DU and the FFT frequency domain data output by DFE, and make NPRACH and NPUSCH share the same eAxC ID interval; parse the eAxC ID and associated control fields in the C-plane message, distinguish the channel type to which the current data stream belongs and determine the corresponding sub-format configuration parameters, and dynamically configure the operating parameters of the hardware processing module. S2. Expand the subframe identifier signal into a multi-bit full quantum frame identifier to represent the complete subframe number; store the full quantum frame identifier as part of the data along with the actual received uplink IQ data in the corresponding storage unit of the buffer; during data readback, fill the latched full quantum frame identifier back into the subframe identifier field in the uplink forward data message header, and perform buffer addressing and data differentiation based on the complete subframe number; S3. Calculate a symbol key value for each arriving C-plane Section message. The symbol key value is determined by a combination of carrier identifier, layer identifier, subframe number, and symbol number. When processing a newly arriving Section message, compare its calculated symbol key value with the previously processed and cached symbol key value. If they are the same, directly reuse the cached DFE data. If they are different, send a data request to the DFE and update the cached symbol key value, and output the IQ data to be processed. S4. Using the format and sub-format combination value obtained from decoding as an index, look up the table to obtain the corresponding FFT size, number of valid REs, frequency domain folding boundary and bit-reverse width parameters; use the parameters obtained from the lookup table to perform FFT frequency domain data to RE sequence space demapping operation on the IQ data to be processed, extract valid RE data and compress and pack it to generate U-plane data and report it to O-DU.

[0015] Specifically, in step S1, the filterIndex field corresponding to the eAxC ID in the C-plane message is read. When the filterIndex field takes the first specific value, it indicates that the current data stream belongs to the NPRACH processing path. When the filterIndex field takes the second specific value, it indicates that the current data stream belongs to the NPUSCH processing path. After determining the channel type, the lower 4 bits of the FrameStructure field are read, and the specific sub-format currently used by the channel is decoded a second time, including the combination of subcarrier spacing, FFT size, and RE number; The channel type and specific sub-format obtained from joint decoding are combined as the standard and sub-format combination value, and the operating parameters of the hardware processing module are dynamically configured.

[0016] Preferably, in step S2, for the non-continuous subframe scheduling scenario of NPRACH, the subframe identifier signal is extended into a 4-bit full quantum frame identifier to represent the complete subframe number; the full quantum frame identifier and uplink IQ data are written together into the corresponding storage unit of the BRAM buffer. During data readback, buffer addressing and data differentiation are performed based on the complete 4-bit subframe number.

[0017] Specifically, in step S3, for the case where the same uplink symbol corresponds to multiple consecutively arriving C-plane Section messages in the NPUSCH scenario, the carrier identifier, layer identifier, subframe number and symbol number in the current C-plane Section message are extracted, and a symbol key value that uniquely identifies the specific symbol described by the C-plane Section message is generated by combining and calculating. When processing a newly arrived Section message and comparing its symbol key value with the previously processed and cached symbol key value, if the comparison result is the same, the current C-plane Section message is determined to be a subsequent Section message of the same symbol, and the cached DFE data is directly read as the IQ data to be processed without initiating a data request to the DFE; if the comparison result is different, the current C-plane Section message is determined to be a new symbol, and a data request is initiated to the DFE to obtain the new uplink IQ data as the IQ data to be processed, and the cached symbol key value is updated to the currently calculated symbol key value.

[0018] Specifically, in step S4, NPRACH and NPUSCH share the same set of parameterized FFT frequency domain data to RE sequence space demapping hardware pipeline, which includes demapping operation units. The demapping operation unit uses the FFT size, effective RE number, frequency domain folding boundary and bit-reverse width parameters obtained by looking up the table to perform demapping operation on the IQ data to be processed and extract the effective RE data; When a new supported standard or sub-format is added, the lookup table used for the lookup table is expanded to configure the FFT size, number of effective REs, frequency domain folding boundary, and bit-reverse width parameters for the corresponding new standard or sub-format.

[0019] In summary, due to the adoption of this technical solution, the beneficial effects of this invention are as follows: This invention significantly reduces the hardware complexity of the O-RU and the resource consumption of the O-RAN fronthaul interface by coordinating the allocation of fronthaul interface resources, subframe addressing, data multiplexing, and hardware demapping paths, while ensuring that different channels do not interfere with each other.

[0020] This invention dynamically configures parameters by sharing the eAxC ID range and jointly decoding the C-plane message field, completely changing the traditional method of independently allocating address space for each channel. This design effectively avoids resource waste caused by independently allocating ranges for narrowband channels without expanding the address space or adding new message fields, significantly improving the overall utilization rate of fronthaul interface address resources.

[0021] This invention fundamentally eliminates buffer data overwriting conflicts caused by low-order bit repetition in non-contiguous subframe scheduling scenarios by extending the full quantum frame identifier in-path storage, thus ensuring the integrity and correctness of uplink data. Simultaneously, the DFE data reuse determination mechanism based on symbol keys effectively avoids redundant requests caused by the same symbol being repeatedly referenced by multiple Section messages, significantly reducing bandwidth usage and processing latency of the DFE interface, and eliminating the risk of data inconsistency introduced by multiple independent requests.

[0022] This invention constructs a multi-standard shared parameterized FFT to RE demapping hardware pipeline. This design breaks away from the independent path mode of fixing dedicated parameters according to channel type, allowing for adaptation to new standards or sub-formats simply by expanding the lookup table, eliminating the need to repeatedly build dedicated hardware paths. This not only significantly reduces hardware resource consumption and development verification costs but also endows the system with strong flexibility and scalability, providing efficient support for the convergence and evolution of multiple standards. Attached Figure Description

[0023] The present invention is described in detail with reference to the following figures, specifically including 5 figures as follows: Figure 1 This is a schematic diagram illustrating the overall architecture and functional logic of the NB-IoT uplink channel processing framework of the present invention. Figure 2 This is a schematic diagram of the eAxC ID multiplexing and hardware parameter configuration process based on the joint decoding of filterIndex and FrameStructure in this invention; Figure 3 This is a comparative diagram of the 4-bit subframe identifier anti-collision mechanism and the 1-bit method in the NPRACH non-contiguous subframe scheduling scenario of the present invention, wherein (a) is the existing 1-bit subframe identifier method and (b) is the 4-bit subframe identifier method of the present invention. Figure 4 This is a schematic diagram of the DFE data reuse determination process based on symbol key value in the NPUSCH multi-section scenario with the same symbol in this invention; Figure 5 This is a schematic diagram of the structure of the multi-standard shared parameterized FFT-RE demapping pipeline in this invention. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0025] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0026] This embodiment first provides an NB-IoT uplink channel processing framework. Figure 1 The overall composition and functional logic of the framework are shown and can be viewed simultaneously. The framework includes a fronthaul interface adaptation layer, a control plane parsing and configuration layer, a DFE data acquisition and multiplexing layer, and a signal demapping and packaging layer. The narrowband physical random access channel NPRACH and the narrowband physical uplink shared channel NPUSCH share the overall structure of the framework. The fronthaul interface adaptation layer is used to receive the O-RAN fronthaul control plane C-plane messages issued by the Open Distributed Unit (O-DU) and the Fast Fourier Transform (FFT) frequency domain data output by the Digital Front-End (DFE), and adapts and distributes the C-plane messages and FFT frequency domain data to the subsequent processing layer; NPRACH and NPUSCH share the interface resources of the fronthaul interface adaptation layer. The control plane parsing and configuration layer is used to parse the antenna carrier identifier eAxC ID and associated control fields in the C-plane message, distinguish the channel type to which the current data stream belongs and determine the corresponding sub-format configuration parameters, and dynamically configure the operating parameters of the hardware processing module based on the channel type and sub-format configuration parameters. The DFE data acquisition and multiplexing layer is used to initiate data requests to the DFE based on the scheduling information in the C-plane message, acquire the corresponding uplink IQ data and store it in the buffer along with the full quantum frame identifier. During data readback, the buffer addressing and data differentiation are performed based on the full quantum frame identifier. Data multiplexing is determined for multiple consecutive C-plane segment section messages of the same uplink symbol, and the IQ data to be processed is output. The signal demapping and packing layer is used to perform FFT frequency domain data to resource element (RE) demapping on the IQ data to be processed according to the subformat configuration parameters, extract the valid RE data and compress and pack it to generate user plane U-plane data and report it to O-DU.

[0027] Based on the above NB-IoT uplink channel processing framework, this embodiment also provides a resource reuse and collision prevention method that it can implement. The key steps of this method can be summarized as follows: S1. Receive the O-RAN fronthaul C-plane message sent by O-DU and the FFT frequency domain data output by DFE, and make NPRACH and NPUSCH share the same eAxC ID interval; parse the eAxC ID and associated control fields in the C-plane message, distinguish the channel type to which the current data stream belongs and determine the corresponding sub-format configuration parameters, and dynamically configure the operating parameters of the hardware processing module. S2. Expand the subframe identifier signal into a multi-bit full quantum frame identifier to represent the complete subframe number; store the full quantum frame identifier as part of the data along with the actual received uplink IQ data in the corresponding storage unit of the buffer; during data readback, fill the latched full quantum frame identifier back into the subframe identifier field in the uplink forward data message header, and perform buffer addressing and data differentiation based on the complete subframe number; S3. Calculate a symbol key value for each arriving C-plane Section message. The symbol key value is determined by a combination of carrier identifier, layer identifier, subframe number, and symbol number. When processing a newly arriving Section message, compare its calculated symbol key value with the previously processed and cached symbol key value. If they are the same, directly reuse the cached DFE data. If they are different, send a data request to the DFE and update the cached symbol key value, and output the IQ data to be processed. S4. Using the format and sub-format combination value obtained from decoding as an index, look up the table to obtain the corresponding FFT size, number of valid REs, frequency domain folding boundary and bit-reverse width parameters; use the parameters obtained from the lookup table to perform FFT frequency domain data to RE sequence space demapping operation on the IQ data to be processed, extract valid RE data and compress and pack it to generate U-plane data and report it to O-DU.

[0028] This implementation will then provide a detailed description of the NB-IoT uplink channel processing framework and its resource reuse and collision prevention methods, which can be summarized into four main technical points. Figure 1 The corresponding annotations are provided and can be viewed simultaneously. Overall, the NB-IoT uplink channel processing framework in the O-RU proposed in this implementation includes four functional layers: the fronthaul interface adaptation layer, the control plane parsing and configuration layer, the DFE data acquisition and multiplexing layer, and the signal demapping and packaging layer. The NPRACH and NPUSCH channels share the overall structure of this framework, with differences only in their respective unique processing stages (this difference corresponds to...). Figure 1 (Technical points two and three in the text).

[0029] The input to the NB-IoT uplink channel processing framework is the O-RAN fronthaul C-plane message sent by the O-DU and the FFT frequency domain data output by the DFE. The C-plane message contains fields such as eAxC ID, filterIndex, FrameStructure, startPrbc / numPrbc, and subframe / symbol number. The output of the framework is the U-plane data sent to the O-DU after compression and packaging.

[0030] The four key technical points will be introduced and explained in turn.

[0031] Technical point 1: eAxC ID reuse method based on joint decoding of filterIndex and FrameStructure, see the corresponding documentation. Figure 2 The illustration.

[0032] In this implementation, NPRACH and NPUSCH share the same eAxC ID range and no longer occupy separate address spaces. After receiving the C-plane message from the O-DU, the O-RU-side adapter first reads the filterIndex field corresponding to the eAxC ID. In this example, when the filterIndex field takes a specific value of 4, it indicates that the data stream belongs to the NPRACH processing path; when it takes another specific value of 8, it indicates that the data stream belongs to the NPUSCH processing path, thereby determining the channel type.

[0033] After determining the channel type, the lower 4 bits of the FrameStructure field are further read, and a second decoding is performed to determine the specific sub-format currently used by the channel, including the subcarrier spacing, FFT size, and RE number combination. For example, in the NPRACH scenario, a certain value in the lower 4 bits of FrameStructure corresponds to a 1.25kHz subcarrier spacing, 144 REs, and a 1024-point FFT configuration, while another value corresponds to a 3.75kHz, 48 REs, and a 512-point FFT configuration; similarly, the NPUSCH scenario distinguishes between 15kHz and 3.75kHz configurations. This method achieves the joint decoding process.

[0034] The joint decoding result directly drives the parameter configuration lookup process of subsequent hardware modules, such as buffer controllers and demapping pipelines. The entire process does not require adding special fields to the O-RAN message, nor does it require expanding the independent eAxC ID address space for the NB-IoT channel.

[0035] Technical point two: Anti-collision method for extending the subframe identifier bit width in non-contiguous subframe scenarios, please refer to the relevant section. Figure 3 The indication, Figure 3(b) refers to the means employed in this embodiment.

[0036] To address the issue of discontinuous subframe scheduling caused by repeated transmissions and frequency hopping mechanisms in NPRACH, this implementation changes the subframe identifier signal, which was originally represented by only 1 bit ( Figure 3 The method used in (a) is extended to 4 bits, which can represent the complete subframe number, i.e., 0 to 9 or a larger range defined by the frame structure. This 4-bit subframe identifier is written as part of the data, along with the actual received IQ data, into the corresponding storage unit of the BRAM buffer; and during data readback, the latched 4-bit subframe identifier is used to backfill the subframe identifier field in the uplink forward data message header.

[0037] Because addressing and differentiation are based on the complete subframe number rather than just the least significant bit, even if the scheduling instruction issued by the O-DU is for non-contiguous subframes, such as subframes 0, 1, 2, and 4, there will be no problem of new data overwriting old data that has not yet been processed due to the repetition of the least significant bit of the subframe number. (See also...) Figure 3 The illustration shows a comparison of the two methods, thus this implementation fundamentally avoids the conflict problem of such fronthaul interface section descriptions.

[0038] Technical point 3: Data reuse method for multiple sections of DFE with the same symbol based on symbolic key values, please refer to the relevant section. Figure 4 The illustration.

[0039] In the NPUSCH scenario, where the same uplink symbol may correspond to multiple consecutively arriving C-plane Section messages, this implementation calculates a symbol key value for each arriving Section message. This key value is determined by a combination of parameters such as carrier identifier, layer identifier, subframe number, and symbol number, and uniquely identifies the specific symbol described by the Section.

[0040] When processing each newly arrived Section message, the adapter compares its calculated symbol key value with the previously processed and cached symbol key value. If they are the same, it is determined that the subsequent Section belongs to the same symbol, and the cached DFE data is directly reused without sending a data request to the DFE again. If they are different, it is determined that the symbol is new, and a data request is sent to the DFE normally, and the cached symbol key value is updated.

[0041] This implementation avoids redundant DFE requests when the same symbol is repeatedly referenced by multiple Sections, reduces DFE interface bandwidth usage and processing latency, and avoids the risk of data inconsistency that may be introduced by multiple independent requests.

[0042] Technical Point 4: A multi-standard parametric FFT-RE demapping pipeline, see below for details. Figure 5 The illustration.

[0043] In this embodiment, NPRACH and NPUSCH share the same hardware pipeline for demapping FFT frequency domain data to RE sequence space; furthermore, other standards such as LTE PRACH and NR PRACH that the framework can expand to support also share this demapping hardware pipeline.

[0044] The demapping hardware pipeline uses the standard and sub-format combination value obtained from decoding in Technique 1 as an index to look up parameters such as the corresponding FFT size, number of valid REs, frequency domain folding boundaries, and bit-reverse width. The demapping operation unit in the demapping hardware pipeline employs a unified folding mapping logic, mapping the low-frequency band of the FFT output to the low segment of the RE sequence number, mapping the high-frequency band of the FFT output to the high segment of the RE sequence number, and discarding the remaining frequency band data by setting it to 0. Before folding, a bit-reverse transformation is performed on the address according to the lookup table width to match the subcarrier mapping order. The circuit structure of the demapping operation unit remains consistent across different standards and sub-formats, with only the operation parameters differing. When adding a new supported standard or sub-format, only the corresponding entry needs to be added to the lookup table; the demapping operation unit itself does not need to be modified.

[0045] In this embodiment, the eAxC ID multiplexing mechanism solves the problem of fronthaul interface address resource allocation. Its decoding result simultaneously drives the parameter configuration of NPRACH subframe anti-collision and unified demapping pipeline. Extending the subframe identifier signal to 4 bits addresses the discontinuous scheduling problem unique to the NPRACH channel, while calculating a symbol key value for each arriving Section message addresses the multi-Section scenario unique to the NPUSCH channel. Therefore, techniques two and three are respectively protected and optimized at the differentiated stages of their respective channels, without mutual interference. The demapping hardware pipeline, as the underlying signal processing hardware path, serves both NPRACH and NPUSCH channels and is driven by the configuration of the eAxC ID multiplexing mechanism. Thus, layered collaboration within the same processing framework constitutes the NB-IoT uplink channel processing framework and its resource multiplexing and collision prevention method of this embodiment.

Claims

1. An NB-IoT uplink channel processing framework, characterized in that, The framework includes a fronthaul interface adaptation layer, a control plane parsing and configuration layer, a DFE data acquisition and multiplexing layer, and a signal demapping and packetization layer; the narrowband physical random access channel NPRACH and the narrowband physical uplink shared channel NPUSCH share the overall structure of this framework. The fronthaul interface adaptation layer is used to receive the O-RAN fronthaul control plane C-plane messages issued by the Open Distributed Unit (O-DU) and the Fast Fourier Transform (FFT) frequency domain data output by the Digital Front-End (DFE), and adapts and distributes the C-plane messages and FFT frequency domain data to the subsequent processing layer; NPRACH and NPUSCH share the interface resources of the fronthaul interface adaptation layer. The control plane parsing and configuration layer is used to parse the antenna carrier identifier eAxC ID and associated control fields in the C-plane message, distinguish the channel type to which the current data stream belongs and determine the corresponding sub-format configuration parameters, and dynamically configure the operating parameters of the hardware processing module based on the channel type and sub-format configuration parameters. The DFE data acquisition and multiplexing layer is used to initiate data requests to the DFE based on the scheduling information in the C-plane message, acquire the corresponding uplink IQ data and store it in the buffer along with the full quantum frame identifier, and perform buffer addressing and data differentiation based on the full quantum frame identifier during data readback. It also performs data multiplexing determination for multiple consecutive C-plane segment section messages of the same uplink symbol and outputs the IQ data to be processed. The signal demapping and packing layer is used to perform FFT frequency domain data to resource element (RE) demapping on the IQ data to be processed according to the subformat configuration parameters, extract the valid RE data and compress and pack it to generate user plane U-plane data and report it to O-DU.

2. The NB-IoT uplink channel processing framework according to claim 1, characterized in that: NPRACH and NPUSCH share the same eAxC ID range; the control plane parsing and configuration layer is also used to read the filterIndex field corresponding to the eAxC ID in the C-plane message. When the filterIndex field takes the first specific value, it indicates that the current data stream belongs to the NPRACH processing path. When the filterIndex field takes the second specific value, it indicates that the current data stream belongs to the NPUSCH processing path. The control plane parsing and configuration layer is also used to read the lower 4 bits of the FrameStructure field after determining the channel type, and then decode the specific sub-format currently used by the channel, including the combination of subcarrier spacing, FFT size and RE number; The control plane parsing and configuration layer is also used to combine the channel type and specific sub-format obtained by joint decoding as an index to drive the hardware processing module to perform parameter configuration lookup.

3. The NB-IoT uplink channel processing framework according to claim 1, characterized in that: The DFE data acquisition and multiplexing layer is also used in the non-continuous subframe scheduling scenario of NPRACH to expand the subframe identification signal into a 4-bit full quantum frame identification to represent the complete subframe number. Then, the full quantum frame identification is written into the corresponding storage unit of the buffer along with the actual received uplink IQ data as part of the data. The DFE data acquisition and multiplexing layer is also used to backfill the latched full quantum frame identifier into the subframe identifier field in the uplink forward data message header during data readback, so as to perform buffer addressing and data differentiation based on the complete subframe number.

4. The NB-IoT uplink channel processing framework according to claim 1, characterized in that: The DFE data acquisition and multiplexing layer is also used in NPUSCH scenarios when the same uplink symbol corresponds to multiple consecutively arriving C-plane Section messages. It calculates a symbol key value for each arriving Section message. The symbol key value is determined by a combination of carrier identifier, layer identifier, subframe number and symbol number to uniquely identify the specific symbol described by the Section message. The DFE data acquisition and reuse layer is also used to compare the corresponding calculated symbol key value with the previously processed and cached symbol key value when processing each newly arrived Section message. If the comparison result is the same, it is determined to be a subsequent Section message of the same symbol, and the cached DFE data is directly reused without repeatedly sending data requests to the DFE. If the comparison result is different, it is determined to be a new symbol, and a data request is sent to the DFE to update the cached symbol key value.

5. The NB-IoT uplink channel processing framework according to claim 1, characterized in that: The signal demapping and packing layer includes a set of parameterized FFT frequency domain data to RE sequence space demapping hardware pipeline shared by NPRACH and NPUSCH; The signal demapping and packing layer is also used to look up the corresponding FFT size, effective RE count, frequency domain folding boundary and bit-reverse width parameters by using the decoded format and sub-format combination value as an index. The demapping operation unit in the demapping hardware pipeline is used to perform demapping operations on the IQ data to be processed, extracting valid RE data, using the FFT size, number of valid REs, frequency domain folding boundary and bit-reverse width parameters obtained by looking up the table.

6. A method for resource reuse and collision prevention in the NB-IoT uplink channel processing framework according to claim 1, characterized in that, The method includes the following steps: S1. Receive the O-RAN fronthaul C-plane message sent by O-DU and the FFT frequency domain data output by DFE, and make NPRACH and NPUSCH share the same eAxC ID interval; parse the eAxC ID and associated control fields in the C-plane message, distinguish the channel type to which the current data stream belongs and determine the corresponding sub-format configuration parameters, and dynamically configure the operating parameters of the hardware processing module. S2. Extend the subframe identifier signal into a multi-bit full quantum frame identifier to represent the complete subframe number; The full quantum frame identifier is included as part of the data and stored along with the actual received uplink IQ data in the corresponding storage unit of the buffer. During data readback, the latched full quantum frame identifier is filled back into the subframe identifier field in the uplink forward data message header, and buffer addressing and data differentiation are performed based on the complete subframe number. S3. Calculate a symbol key value for each arriving C-plane Section message. The symbol key value is determined by a combination of carrier identifier, layer identifier, subframe number, and symbol number. When processing a newly arriving Section message, compare its calculated symbol key value with the previously processed and cached symbol key value. If they are the same, directly reuse the cached DFE data. If they are different, send a data request to the DFE and update the cached symbol key value, and output the IQ data to be processed. S4. Using the format and sub-format combination value obtained from decoding as an index, look up the table to obtain the corresponding FFT size, number of valid REs, frequency domain folding boundary and bit-reverse width parameters; use the parameters obtained from the lookup table to perform FFT frequency domain data to RE sequence space demapping operation on the IQ data to be processed, extract valid RE data and compress and pack it to generate U-plane data and report it to O-DU.

7. The resource reuse and conflict prevention method according to claim 6, characterized in that: In step S1, the filterIndex field corresponding to the eAxC ID in the C-plane message is read. When the filterIndex field takes the first specific value, it indicates that the current data stream belongs to the NPRACH processing path. When the filterIndex field takes the second specific value, it indicates that the current data stream belongs to the NPUSCH processing path. After determining the channel type, the lower 4 bits of the FrameStructure field are read, and the specific sub-format currently used by the channel is decoded a second time, including the combination of subcarrier spacing, FFT size, and RE number; The channel type and specific sub-format obtained from joint decoding are combined as the standard and sub-format combination value, and the operating parameters of the hardware processing module are dynamically configured.

8. The resource reuse and conflict prevention method according to claim 6, characterized in that: In step S2, for the non-continuous subframe scheduling scenario of NPRACH, the subframe identifier signal is extended into a 4-bit full quantum frame identifier to represent the complete subframe number; the full quantum frame identifier and uplink IQ data are written together into the corresponding storage unit of the BRAM buffer. During data readback, buffer addressing and data differentiation are performed based on the complete 4-bit subframe number.

9. The resource reuse and conflict prevention method according to claim 6, characterized in that: In step S3, for the case where the same uplink symbol corresponds to multiple consecutively arriving C-plane Section messages in the NPUSCH scenario, the carrier identifier, layer identifier, subframe number and symbol number in the current C-plane Section message are extracted, and a symbol key value that uniquely identifies the specific symbol described by the C-plane Section message is generated by combining and calculating. When processing a newly arrived Section message and comparing its symbol key value with the previously processed and cached symbol key value, if the comparison result is the same, the current C-plane Section message is determined to be a subsequent Section message of the same symbol, and the cached DFE data is directly read as the IQ data to be processed without initiating a data request to the DFE; if the comparison result is different, the current C-plane Section message is determined to be a new symbol, and a data request is initiated to the DFE to obtain the new uplink IQ data as the IQ data to be processed, and the cached symbol key value is updated to the currently calculated symbol key value.

10. The resource reuse and conflict prevention method according to claim 6, characterized in that: In step S4, NPRACH and NPUSCH share the same set of parameterized FFT frequency domain data to RE sequence space demapping hardware pipeline, which includes demapping operation units. The demapping operation unit uses the FFT size, effective RE number, frequency domain folding boundary and bit-reverse width parameters obtained by looking up the table to perform demapping operation on the IQ data to be processed and extract the effective RE data; When a new supported standard or sub-format is added, the lookup table used for the lookup table is expanded to configure the FFT size, number of effective REs, frequency domain folding boundary, and bit-reverse width parameters for the corresponding new standard or sub-format.

Images