Method of concatenating IP packets in a communication system

Abstract

In one aspect of the disclosure, a method, a computer-readable medium, and an apparatus are provided. The apparatus can be a transmitter in a wireless communication network. The transmitter determines whether a plurality of Internet Protocol (IP) packets are concatenable. In response to determining that the plurality of IP packets are concatenable, the transmitter concatenates the plurality of IP packets into a concatenated data block. An IP header of each IP packet in the concatenated data block indicates a boundary between the IP packet and a next IP packet. The transmitter treats the concatenated data block as a single data unit for performing a corresponding action.

Description

[0001] Cross-references

[0002] This disclosure is part of a non-provisional application claiming priority to U.S. Patent Application No. 63 / 569,781, filed March 26, 2024, the contents of which are incorporated herein by reference in their entirety. Technical Field

[0003] This invention relates generally to wireless communication, and more particularly to techniques for cascading IP packets in communication systems. Background Technology

[0004] The statements in this section are provided only as background information in relation to the present invention and do not constitute prior art.

[0005] Wireless communication systems are widely deployed to provide a variety of telecommunications services, such as telephone, video, data, messaging, and broadcasting. Typical wireless communication systems employ multiple access technologies that enable communication with multiple users by sharing available system resources. Examples of such multiple access technologies include Code Division Multiple Access (CDMA) systems, Time Division Multiple Access (TDMA) systems, Frequency Division Multiple Access (FDMA) systems, Orthogonal Frequency Division Multiple Access (OFDMA) systems, Single Carrier Frequency Division Multiple Access (SC-FDMA) systems, and Time Division Synchronous Code Division Multiple Access (TD-SCDMA) systems.

[0006] These multiple access technologies have been adopted in various telecommunications standards to provide a common protocol enabling different wireless devices to communicate at the city, national, regional, and even global levels. An exemplary telecommunications standard is 5G New Radio (NR). 5G NR is part of the ongoing evolution of mobile broadband driven by the 3rd Generation Partnership Project (3GPP) to meet new requirements related to latency, reliability, security, scalability (e.g., related to the Internet of Things (IoT),) and other requirements. Some aspects of 5G NR can be based on the 4G Long Term Evolution (LTE) standard. Further improvements to 5G NR technology are still needed. These improvements can also be applied to other multiple access technologies and telecommunications standards that employ them. Summary of the Invention

[0007] The following is a simplified overview of one or more aspects to provide a basic understanding of these aspects. This overview is not an exhaustive summary of all anticipated aspects, nor is it intended to identify key or necessary elements of all aspects, nor to define the scope of any or all aspects. Its sole purpose is to present certain concepts of one or more aspects in a simplified form as a prelude to a more detailed explanation later.

[0008] In one aspect of the invention, a method, a computer-readable medium, and an apparatus are provided. The apparatus may be a transmitter in a wireless communication network. The transmitter determines whether a plurality of Internet Protocol (IP) packets are concatenable. In response to determining that the plurality of IP packets are concatenable, the transmitter concatenates the plurality of IP packets into a concatenated data block. The IP header of each IP packet in the concatenated data block indicates the boundary between that IP packet and the next IP packet. The transmitter treats the concatenated data block as a single data unit to perform corresponding actions.

[0009] To achieve the foregoing and related objectives, the one or more aspects include the features fully described below and specifically pointed out in the claims. Certain illustrative features of the one or more aspects are set forth in detail in the following description and accompanying drawings. However, these features represent only a few of the various ways in which the principles of the aspects can be applied, and this description is intended to cover all such aspects and their equivalents. Attached Figure Description

[0010] Figure 1 This is a schematic diagram illustrating an example of a wireless communication system and access network.

[0011] Figure 2 This is a schematic diagram illustrating communication between a base station and a UE in an access network.

[0012] Figure 3 An exemplary logical architecture of a distributed access network is shown.

[0013] Figure 4 An exemplary physical architecture of a distributed access network is shown.

[0014] Figure 5 This is a schematic diagram illustrating an example of a time slot centered on DL.

[0015] Figure 6 This is a schematic diagram illustrating an example of a UL-centric time slot.

[0016] Figure 7 This is a schematic diagram illustrating IP packet transmission in a 5G communication system.

[0017] Figure 8 This is a schematic diagram illustrating the transmission of cascaded data blocks.

[0018] Figure 9(A) is a schematic diagram showing an example of an IPv4 header.

[0019] Figure 9(B) is a schematic diagram showing an example of an IPv6 header.

[0020] Figure 10 This is a schematic diagram illustrating multiple examples of a cascading set of IP packets.

[0021] Figure 11(A) shows a flowchart of the process of cascading IP packets in a communication system.

[0022] Figure 11(B) shows a flowchart of another process for cascading IP packets in a communication system. Detailed Implementation

[0023] The detailed description below, taken in conjunction with the accompanying drawings, is intended to describe various configurations, and not to represent the only configuration in which the concepts described herein can be practiced. This detailed description includes specific details to provide a thorough understanding of the various concepts. However, those skilled in the art will appreciate that these specific details can be practiced without them. In some cases, to avoid obscuring such concepts, well-known structures and components are shown in block diagram form.

[0024] Various aspects of a telecommunications system will now be presented with reference to a variety of devices and methods. These devices and methods will be described in detail below and illustrated in the accompanying drawings as various blocks, components, circuits, processes, algorithms, etc. (collectively, “elements”). These elements can be implemented using electronic hardware, computer software, or any combination thereof. Whether such elements are implemented in hardware or software depends on the specific application and the design constraints imposed on the system as a whole.

[0025] For example, an element, any part of an element, or any combination of elements can be implemented as a "processing system" including one or more processors. Examples of processors include microprocessors, microcontrollers, graphics processing units (GPUs), central processing units (CPUs), application processors, digital signal processors (DSPs), reduced instruction set computing (RISC) processors, system-on-a-chip (SoCs), baseband processors, field-programmable gate arrays (FPGAs), programmable logic devices (PLDs), state machines, gated logic, discrete hardware circuits, and other suitable hardware configured to perform the various functions described throughout this invention. One or more processors in the processing system can execute software. Software should be interpreted broadly to mean instructions, instruction sets, code, code segments, program code, programs, subroutines, software components, applications, software applications, software packages, routines, subroutines, objects, executable files, threads of execution, procedures, functions, etc., whether referred to as software, firmware, middleware, microcode, hardware description languages, or otherwise.

[0026] Therefore, in one or more example aspects, the functionality can be implemented in hardware, software, or any combination thereof. If implemented in software, these functions can be stored on or encoded as one or more instructions or code on a computer-readable medium. Computer-readable media include computer storage media. Storage media can be any available medium accessible by a computer. For example, and not as a limitation, such computer-readable media can include random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), optical disk storage, magnetic disk storage, other magnetic storage devices, combinations of computer-readable media of the foregoing types, or any other medium that can be used to store computer-executable code in the form of instructions or data structures accessible by a computer.

[0027] Figure 1 This is a schematic diagram illustrating an example of a wireless communication system and access network 100. The wireless communication system (also referred to as a Wireless Wide Area Network (WWAN)) includes a base station 102, a UE 104, an evolved packet core (EPC) 160, and another core network 190 (e.g., a 5G core network (5GC)). Base station 102 may include macro cells (high-power cellular base stations) and / or small cells (low-power cellular base stations). Macro cells include base stations. Small cells include nanocells, picocells, and microcells.

[0028] Base station 102 configured for 4G LTE (collectively referred to as Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN)) can interface with EPC 160 via backhaul link 132 (e.g., S1 interface). Base station 102 configured for 5G NR (collectively referred to as Next Generation Radio Access Network (NG-RAN)) can interface with core network 190 via backhaul link 184. Among other functions, base station 102 can perform one or more of the following functions: user data transmission, radio channel encryption and decryption, integrity protection, header compression, mobility control functions (e.g., handover, dual connectivity), inter-cell interference coordination, connection establishment and release, load balancing, distribution of non-access stratum (NAS) messages, NAS node selection, synchronization, radio access network (RAN) sharing, multimedia broadcast multicast service (MBMS), user and device tracking, RAN information management (RIM), paging, location, and delivery of warning messages. Base stations 102 can communicate with each other directly or indirectly (e.g., via EPC 160 or core network 190) via backhaul link 134 (e.g., X2 interface). Backhaul link 134 can be wired or wireless.

[0029] Base station 102 can wirelessly communicate with UE 104. Each of base stations 102 can provide communication coverage for its respective geographic coverage area 110. Geographic coverage areas 110 may overlap. For example, small cell 102' may have a coverage area 110' that overlaps with the coverage areas 110 of one or more macro base stations 102. A network that includes both small cells and macro cells can be called a heterogeneous network. A heterogeneous network may also include a Home Evolution Node B (HeNB), which can provide services to a restricted group called a Closed Subscriber Group (CSG). The communication link 120 between base station 102 and UE 104 may include uplink (UL) (also called reverse link) transmission from UE 104 to base station 102 and / or downlink (DL) (also called forward link) transmission from base station 102 to UE 104. Communication link 120 may use multiple-input multiple-output (MIMO) antenna technologies, including spatial multiplexing, beamforming, and / or transmit diversity. This communication link may be carried out via one or more carriers. Base station 102 / UE 104 may use spectrum with a bandwidth of up to 7 MHz per carrier (e.g., 5, 10, 15, 20, 100, 400 MHz, etc.), which is allocated in carrier aggregation totaling up to Yx MHz (x component carriers) for transmission in each direction. These carriers may be adjacent to each other or not. The allocation of carriers may be asymmetrical with respect to DL and UL (e.g., more or fewer carriers may be allocated to DL than to UL). These component carriers may include one primary component carrier and one or more secondary component carriers. The primary component carrier may be referred to as the primary cell (PCell), and the secondary component carriers may be referred to as secondary cells (SCells).

[0030] Some UEs 104 may communicate with each other using device-to-device (D2D) communication link 158. D2D communication link 158 may use DL / UL WWAN spectrum. D2D communication link 158 may use one or more sideline channels, such as Physical Sideline Broadcast Channel (PSBCH), Physical Sideline Discovery Channel (PSDCH), Physical Sideline Shared Channel (PSSCH), and Physical Sideline Control Channel (PSCCH). D2D communication can be performed through various wireless D2D communication systems, such as FlashLinQ, WiMedia, Bluetooth, ZigBee, Wi-Fi based on the IEEE 802.11 standard, LTE, or NR.

[0031] The wireless communication system may also include a Wi-Fi access point (AP) 150, which communicates with a Wi-Fi station (STA) 152 via a communication link 154 in the 5 GHz unlicensed spectrum. When communicating in the unlicensed spectrum, the STA 152 / AP 150 may perform a free channel assessment (CCA) before communication to determine whether the channel is available.

[0032] Small cell 102' can operate in licensed and / or unlicensed spectrum. When operating in unlicensed spectrum, small cell 102' can employ NR and use the same 5 GHz unlicensed spectrum as Wi-Fi AP 150. Small cell 102' employing NR in unlicensed spectrum can enhance the coverage and / or increase the capacity of the access network.

[0033] Base station 102, whether it is a small cell 102' or a large-area (e.g., a macro base station), may include an eNB, a gNodeB (gNB), or another type of base station. Some base stations, such as gNB 180, may operate in conventional sub-6 GHz spectrum, millimeter wave (mmW) frequencies, and / or near-mmW frequencies to communicate with UE 104. When gNB 180 operates in mmW or near-mmW frequencies, gNB 180 may be referred to as an mmW base station. Extremely high frequency (EHF) is a radio frequency portion of the electromagnetic spectrum. The EHF range is from 30 GHz to 300 GHz, with wavelengths between 1 mm and 10 mm. Radio waves in this band may be referred to as millimeter waves. Near-mmW extends down to 3 GHz, with wavelengths of 100 mm. Ultra-high frequency (SHF) bands are between 3 GHz and 30 GHz, also known as centimeter waves. Communication using mmW / near mmW radio frequency bands (e.g., 3 GHz to 300 GHz) suffers from extremely high path loss and short transmission distances. The mmW base station 180, together with the UE 104, can utilize beamforming 182 to compensate for this extremely high path loss and short transmission distance.

[0034] Base station 180 may transmit beamformed signals to UE 104 in one or more transmit directions 108a. UE 104 may receive the beamformed signals from base station 180 in one or more receive directions 108b. UE 104 may also transmit beamformed signals to base station 180 in one or more transmit directions. Base station 180 may receive the beamformed signals from UE 104 in one or more receive directions. Base station 180 / UE 104 may perform beamtraining to determine the optimal receive and transmit directions for each of base station 180 / UE 104. The transmit and receive directions of base station 180 may be the same or different. The transmit and receive directions of UE 104 may be the same or different.

[0035] EPC 160 may include Mobility Management Entity (MME) 162, other MMEs 164, Serving Gateway 166, Multimedia Broadcast Multicast Service (MBMS) Gateway 168, Broadcast Multicast Service Center (BM-SC) 170, and Packet Data Network (PDN) Gateway 172. MME 162 can communicate with Home Subscriber Server (HSS) 174. MME 162 is the control node for handling signaling between UE 104 and EPC 160. Generally, MME 162 provides bearer and connection management. All user Internet Protocol (IP) packets are transmitted through Serving Gateway 166, which is itself connected to PDN Gateway 172. PDN Gateway 172 provides UE IP address allocation and other functions. PDN Gateway 172 and BM-SC 170 are connected to IP Service 176. IP Service 176 may include the Internet, intranet, IP Multimedia Subsystem (IMS), PS streaming service, and / or other IP services. The BM-SC 170 provides functionality for MBMS user service activation and delivery. The BM-SC 170 can serve as an entry point for content provider MBMS transmissions, authorizing and initiating MBMS bearer services within the Public Land Mobile Network (PLMN), and scheduling MBMS transmissions. The MBMS gateway 168 can distribute MBMS traffic to base station 102 within a Broadcast-Specific Service Multicast Single Frequency Network (MBSFN) area, and is responsible for session management (start / stop) and collecting eMBMS-related billing information.

[0036] Core network 190 may include Access and Mobility Management Function (AMF) 192, other AMFs 193, Location Management Function (LMF) 198, Session Management Function (SMF) 194, and User Plane Function (UPF) 195. AMF 192 can communicate with Unified Data Management (UDM) 196. AMF 192 is the control node for processing signaling between UE 104 and core network 190. Generally, SMF 194 provides QoS flow and session management. All user Internet Protocol (IP) packets are transmitted through UPF 195. UPF 195 provides UE IP address allocation and other functions. UPF 195 connects to IP service 197. IP service 197 may include the Internet, intranet, IP Multimedia Subsystem (IMS), PS streaming service, and / or other IP services.

[0037] This base station may also be referred to as a gNB, Node B, Evolved Node B (eNB), access point, base transceiver, wireless base station, wireless transceiver, transceiver function, Basic Services Set (BSS), Extended Services Set (ESS), Transmitter Receiver Point (TRP), or some other suitable term. Base station 102 provides UE 104 with access to EPC 160 or core network 190. Examples of UE 104 include cellular phones, smartphones, Session Initiation Protocol (SIP) phones, laptops, personal digital assistants (PDAs), satellite radios, GPS devices, multimedia devices, video devices, digital audio players (e.g., MP3 players), cameras, game consoles, tablets, smart devices, wearable devices, vehicles, electricity meters, gas pumps, large or small kitchen appliances, healthcare devices, implants, sensors / actuators, displays, or any other device with similar functionality. Some UEs 104 may be referred to as IoT devices (e.g., parking meters, gas pumps, toasters, vehicles, heart monitors, etc.). UE 104 may also be referred to as station, mobile station, subscriber station, mobile unit, subscriber unit, radio unit, remote unit, mobile device, radio device, wireless communication device, remote device, mobile subscriber station, access terminal, mobile terminal, radio terminal, remote terminal, mobile phone, user agent, mobile client, client or some other suitable term.

[0038] Although this invention may refer to 5G New Radio (NR), it is also applicable to other similar fields, such as LTE, Advanced LTE (LTE-A), Code Division Multiple Access (CDMA), Global System for Mobile Communications (GSM) or other wireless / wireless access technologies.

[0039] Figure 2This is a block diagram illustrating communication between base station 210 and UE 250 in the access network. In the DL, IP packets from EPC 160 can be provided to controller / processor 275. Controller / processor 275 implements Layer 3 and Layer 2 functions. Layer 3 includes the Radio Resource Control (RRC) layer, and Layer 2 includes the Packet Data Convergence Protocol (PDCP) layer, Radio Link Control (RLC) layer, and Media Access Control (MAC) layer. The controller / processor 275 provides: RRC layer functions related to system information (e.g., MIB, SIB) broadcasting, RRC connection control (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release), inter-Radio Access Technology (RAT) mobility, and measurement configuration for UE measurement reporting; PDCP layer functions related to header compression / decompression, security (encryption, decryption, integrity protection, integrity verification), and handover support functions; RLC layer functions related to upper-layer packet data unit (PDU) transmission, error correction via ARQ, RLC service data unit (SDU) concatenation, segmentation and reassembly, RLC data PDU resegmentation, and RLC data PDU reordering; and MAC layer functions related to mapping between logical channels and transport channels, multiplexing of MAC SDUs to transport blocks (TBs), demultiplexing MAC SDUs from TBs, scheduling information reporting, error correction via HARQ, priority processing, and logical channel priority ordering.

[0040] Transmit (TX) processor 216 and receive (RX) processor 270 implement Layer 1 functions related to various signal processing functions. Layer 1 includes a physical (PHY) layer, which may include error detection on the transport channel, forward error correction (FEC) encoding / decoding of the transport channel, interleaving, rate matching, mapping to the physical channel, modulation / demodulation of the physical channel, and MIMO antenna processing. TX processor 216 processes the mapping to the signal constellation based on various modulation schemes (e.g., binary phase shift keying (BPSK), quadrature phase shift keying (QPSK), M-phase phase shift keying (M-PSK), and M-order quadrature amplitude modulation (M-QAM)). The encoded and modulated symbols can then be split into parallel streams. Each stream can then be mapped to OFDM subcarriers, multiplexed with a reference signal (e.g., a pilot) in the time and / or frequency domains, and then combined using an inverse fast Fourier transform (IFFT) to generate a physical channel carrying a stream of time-domain OFDM symbols. This OFDM stream is spatially precoded to generate multiple spatial streams. The channel estimate from channel estimator 274 can be used to determine the coding and modulation scheme and to perform spatial processing. This channel estimate can be derived from a reference signal transmitted by UE 250 and / or channel condition feedback. Each spatial stream can then be provided to a different antenna 220 via its respective transmitter 218TX. Each transmitter 218TX can modulate an RF carrier with its respective spatial stream for transmission.

[0041] At UE 250, each receiver 254RX receives signals through its respective antenna 252. Each receiver 254RX recovers the information modulated onto the RF carrier and provides this information to the receive (RX) processor 256. The TX processor 268 and RX processor 256 implement Layer 1 functions related to various signal processing functions. The RX processor 256 can perform spatial processing on this information to recover any spatial streams destined for UE 250. If multiple spatial streams are destined for UE 250, they can be combined by the RX processor 256 into a single OFDM symbol stream. The RX processor 256 then uses a Fast Fourier Transform (FFT) to transform the OFDM symbol stream from the time domain to the frequency domain. This frequency domain signal comprises a separate OFDM symbol stream for each subcarrier of the OFDM signal. The symbols on each subcarrier, along with the reference signal, are recovered and demodulated by determining the most probable signal constellation point transmitted by base station 210. These soft decisions can be based on channel estimates calculated by channel estimator 258. These soft decisions are then decoded and deinterleaved to recover the data and control signals initially transmitted by base station 210 on the physical channel. These data and control signals are then provided to controller / processor 259, which implements Layer 3 and Layer 2 functions.

[0042] Controller / processor 259 may be associated with memory 260, which stores program code and data. Memory 260 may be referred to as computer-readable medium. In UL, controller / processor 259 provides demultiplexing, packet reassembly, decryption, header decompression, and control signal processing between transport and logical channels to recover IP packets from EPC 160. Controller / processor 259 is also responsible for error detection using ACK and / or NACK protocols to support HARQ operation.

[0043] Similar to the DL transmission function combined with base station 210, controller / processor 259 provides: RRC layer functions related to system information (e.g., MIB, SIB) acquisition, RRC connection, and measurement reporting; PDCP layer functions related to header compression / decompression and security (encryption, decryption, integrity protection, integrity verification); RLC layer functions related to upper-layer PDU transmission, error correction via ARQ, RLC SDU concatenation, segmentation and reassembly, RLC data PDU resegmentation, and RLC data PDU reordering; and MAC layer functions related to mapping between logical channels and transport channels, multiplexing of MAC SDU to TB, demultiplexing MACSDU from TB, scheduling information reporting, error correction via HARQ, priority processing, and logical channel priority ordering.

[0044] The channel estimate derived by the channel estimator 258 from the reference signal transmitted from the base station 210 or from feedback can be used by the TX processor 268 to select an appropriate coding and modulation scheme and facilitate spatial processing. The spatial stream generated by the TX processor 268 can be provided to different antennas 252 via respective transmitters 254TX. Each transmitter 254TX can modulate an RF carrier with its own spatial stream for transmission. This UL transmission is processed at the base station 210 in a manner similar to that described in conjunction with the receiver function at the UE 250. Each receiver 218RX receives the signal through its respective antenna 220. Each receiver 218RX recovers the information modulated onto the RF carrier and provides this information to the RX processor 270.

[0045] Controller / processor 275 may be associated with memory 276, which stores program code and data. Memory 276 may be referred to as computer-readable medium. In the UL, controller / processor 275 provides demultiplexing, packet reassembly, decryption, header decompression, and control signal processing between transport and logical channels to recover IP packets from UE 250. IP packets from controller / processor 275 may be provided to EPC 160. Controller / processor 275 is also responsible for error detection using ACK and / or NACK protocols to support HARQ operation.

[0046] New Radio (NR) can refer to a radio configured to operate based on a new air interface (e.g., an air interface not based on Orthogonal Frequency Division Multiple Access (OFDMA)) or a fixed transport layer (e.g., a non-Internet Protocol (IP) layer). NR may utilize OFDM with a cyclic prefix (CP) on both the uplink and downlink, and may include support for half-duplex operation using Time Division Duplex (TDD). NR may include mission-critical applications for enhanced mobile broadband (eMBB) services with wide bandwidths (e.g., above 80 MHz), millimeter wave (mmW) services with high carrier frequencies (e.g., 60 GHz), massive MTC (mMTC) services with non-backward-compatible MTC technologies, and / or ultra-reliable low-latency communication (URLLC) services.

[0047] It supports a single component carrier bandwidth of 100 MHz. In one example, an NR resource block (RB) can span 12 subcarriers with a subcarrier bandwidth of 60 kHz and a duration of 0.25 ms, or a subcarrier bandwidth of 30 kHz and a duration of 0.5 ms (similarly, 50 MHz bandwidth with a duration of 1 ms at 15 kHz SCS). Each radio frame can consist of 10 subframes (10, 20, 40, or 80 NR slots) of 10 ms in length. Each slot can indicate the link direction (i.e., DL or UL) used for data transmission, and the link direction of each slot can be dynamically switched. Each slot can include DL / UL data and DL / UL control data. The UL and DL slots of NR can be referenced below. Figure 5 and Figure 6 A more detailed description is required.

[0048] NR RAN may include a Central Unit (CU) and a Distributed Unit (DU). NR BS (e.g., gNB, 5G Node B, Node B, Transmit / Receive Point (TRP), Access Point (AP)) may correspond to one or more BSs. NR cells may be configured as Access Cells (ACells) or Data-Only Cells (DCells). For example, the RAN (e.g., a Central Unit or a Distributed Unit) may configure these cells. DCells may be cells used for carrier aggregation or dual connectivity and may not be used for initial access, cell selection / reselection, or handover. In some cases, DCells may not transmit synchronization signals (SS); in other cases, DCells may transmit SS. NR BSs may transmit downlink signals to the UE indicating the cell type. Based on this cell type indication, the UE may communicate with the NR BS. For example, the UE may determine which NR BSs to consider for cell selection, access, handover, and / or measurement based on the indicated cell type.

[0049] Figure 3An exemplary logical architecture of a distributed RAN 300 according to various aspects of the present invention is shown. A 5G access node 306 may include an access node controller (ANC) 302. This ANC may be the central unit (CU) of the distributed RAN. The backhaul interface to the next-generation core network (NG-CN) 304 may terminate at this ANC. The backhaul interface to the adjacent next-generation access node (NG-AN) 310 may terminate at this ANC. This ANC may include one or more TRPs 308 (which may also be referred to as BS, NR BS, Node B, 5GNB, AP, or some other terminology). As mentioned above, TRP can be used interchangeably with "cell".

[0050] TRP 308 may be a Distributed Unit (DU). These TRPs may be connected to one ANC (ANC 302) or more ANCs (not shown). For example, for RAN sharing, Radio as a Service (RaaS), and service-specific ANC deployments, TRPs may be connected to more than one ANC. TRPs may include one or more antenna ports. These TRPs may be configured to provide traffic services to the UE individually (e.g., dynamically selected) or jointly (e.g., jointly transmitted).

[0051] The local architecture of the distributed RAN 300 can be used to illustrate the definition of fronthaul. An architecture supporting fronthaul solutions across different deployment types can be defined. For example, this architecture can be based on transmit network capabilities (e.g., bandwidth, latency, and / or jitter). This architecture can share features and / or components with LTE. Depending on various aspects, the next-generation AN (NG-AN) 310 can support dual connectivity with NR. This NG-AN can share a common fronthaul for LTE and NR.

[0052] This architecture enables collaboration between TRPs 308 and between individual TRPs. For example, collaboration can be pre-defined within a single TRP and / or across multiple TRPs via ANC 302. Depending on the circumstances, inter-TRP interfaces may be unnecessary or nonexistent.

[0053] Depending on various factors, the distributed RAN 300 architecture can have dynamic configurations for segmentation logic functions. PDCP, RLC, and MAC protocols can be adaptively placed at the ANC or TRP.

[0054] Figure 4An exemplary physical architecture of a distributed RAN 400 according to various aspects of the present invention is shown. A centralized core network unit (C-CU) 402 can carry core network functions. This C-CU can be centrally deployed. To handle peak capacity, the functions of the C-CU can be offloaded (e.g., offloaded to Advanced Radio Services (AWS)). A centralized RAN unit (C-RU) 404 can carry one or more ANC functions. Optionally, the C-RU can carry core network functions locally. The C-RU can be deployed in a distributed manner. The C-RU can be located closer to the network edge. A distributed unit (DU) 406 can carry one or more TRPs. The DU can be located at the network edge and have radio frequency (RF) functions.

[0055] Figure 5 A schematic diagram 500 illustrates an example of a DL-centered time slot. This DL-centered time slot may include a control section 502. The control section 502 may be present at the beginning or start portion of the DL-centered time slot. The control section 502 may include various scheduling and / or control information corresponding to the various portions of the DL-centered time slot. In some configurations, such as... Figure 5 As shown, the control portion 502 may be a physical DL control channel (PDCCH). The DL-centric time slot may also include a DL data portion 504. The DL data portion 504 may sometimes be referred to as the payload of the DL-centric time slot. The DL data portion 504 may include communication resources for transmitting DL data from a scheduling entity (e.g., UE or BS) to a lower-level entity (e.g., UE). In some configurations, the DL data portion 504 may be a physical DL shared channel (PDSCH).

[0056] The DL-centered time slot may also include a common UL portion 506. The common UL portion 506 may sometimes be referred to as a UL burst, a common UL burst, and / or various other suitable terms. The common UL portion 506 may include feedback information corresponding to various other portions of the DL-centered time slot. For example, the common UL portion 506 may include feedback information corresponding to control portion 502. Non-limiting examples of feedback information may include ACK signals, NACK signals, HARQ indicators, and / or various other suitable types of information. The common UL portion 506 may include additional or alternative information, such as information related to the Random Access Channel (RACH) procedure, scheduling requests (SR), and various other suitable types of information.

[0057] like Figure 5As shown, the end of the DL data section 504 may be temporally separated from the beginning of the common UL section 506. This time separation may sometimes be referred to as a gap, protection period, protection interval, and / or various other suitable terms. This separation provides time for the transition from DL communication (e.g., the receiving operation of a lower-level entity (e.g., the UE)) to UL communication (e.g., the transmission of a lower-level entity (e.g., the UE)). Those skilled in the art will understand that the foregoing is merely one example of a DL-centric time slot, and alternative structures with similar characteristics may exist without departing from the aspects described herein.

[0058] Figure 6 A schematic diagram 600 illustrates an example of a UL-centered time slot. This UL-centered time slot may include a control section 602. The control section 602 may be present at the beginning or start portion of the UL-centered time slot. Figure 6 The control section 602 in the reference above can be similar to the one mentioned above. Figure 5 The control section 502 is described above. The UL-centric time slot may also include a UL data section 604. The UL data section 604 may sometimes be referred to as the payload of the UL-centric time slot. The UL section may refer to the communication resources used to transmit UL data from a lower-level entity (e.g., the UE) to a scheduling entity (e.g., the UE or BS). In some configurations, the control section 602 may be a Physical DL Control Channel (PDCCH).

[0059] like Figure 6 As shown, the end of control section 602 may be time-separated from the beginning of UL data section 604. This time separation may sometimes be referred to as a gap, protection period, protection interval, and / or various other suitable terms. This separation provides time for switching from DL communication (e.g., receiving operations of a scheduling entity) to UL communication (e.g., transmitting operations of a scheduling entity). This UL-centric time slot may also include common UL section 606. Figure 6 The public UL section 606 in the reference above can be similar to the one mentioned above. Figure 5 The aforementioned common UL portion 506. Common UL portion 606 may additionally or alternatively include information related to the Channel Quality Indicator (CQI), the Sound Reference Signal (SRS), and various other suitable types of information. Those skilled in the art will understand that the foregoing is merely one example of a UL-centric time slot, and that alternative structures with similar features may exist without departing from the aspects described herein.

[0060] In certain scenarios, two or more subordinate entities (e.g., UEs) may communicate with each other using sidelink signals. Practical applications of such sidelink communication can include public safety, proximity services, UE-to-network relay, vehicle-to-vehicle (V2V) communication, Internet of Things (IoE) communication, IoT communication, mission-critical meshes, and / or various other suitable applications. Generally, a sidelink signal can refer to a signal transmitted from one subordinate entity (e.g., UE1) to another subordinate entity (e.g., UE2) without relaying the communication through a scheduling entity (e.g., a UE or BS), although this scheduling entity may be used for scheduling and / or control purposes. In some examples, these sidelink signals may be transmitted using licensed spectrum (unlike wireless LANs that typically use unlicensed spectrum).

[0061] Figure 7 This is a schematic diagram 700 illustrating IP packet transmission in a 5G communication system. (For example...) Figure 7 As shown, IP packets are transmitted through various protocol stack layers, including: Service Data Adaptation Protocol (SDAP) layer, Packet Data Convergence Protocol (PDCP) layer, Radio Link Control (RLC) layer, and Media Access Control (MAC) layer.

[0062] The SDAP layer is responsible for mapping Quality of Service (QoS) flows from the core network to Data Radio Bearers (DRBs) in the Radio Access Network (RAN). A DRB is a logical channel established between the RAN and the User Equipment (UE) to carry user plane data. Each DRB is associated with specific QoS parameters, and one or more QoS flows can be mapped to a single DRB. An SDAP Service Data Unit (SDAP SDU) is a data unit processed and transmitted by the SDAP layer. Each SDAP SDU corresponds to a QoS flow, which represents a different type of service traffic with specific QoS requirements (such as bandwidth, latency, and packet loss rate).

[0063] The PDCP layer sits below the SDAP layer and above the RLC layer, performing functions such as data encryption, header compression, and sequence number management. A PDCP SDU is a data unit received by the PDCP layer from the SDAP layer. The PDCP layer processes this PDCP SDU and encapsulates it into a PDCP Protocol Data Unit (PDCP PDU) for transmission to the lower layers.

[0064] The RLC layer, located below the PDCP layer and above the MAC layer, performs functions such as segmentation, reassembly, retransmission control, and flow control. An RLC SDU is a data unit received by the RLC layer from the PDCP layer. The RLC layer processes this RLC SDU and encapsulates it into an RLC PDU for transmission to the MAC layer. The RLC layer transmits the RLC PDU to the MAC layer via logical channels (LCHs), where each LCH has specific characteristics and priorities.

[0065] The MAC layer, located below the RLC layer and above the physical layer, is responsible for mapping logical channels to transport channels, scheduling, and Hybrid Automatic Repeat Request (HARQ) operations. The MAC layer multiplexes and processes multiple RLC PDUs to form a transport block (TB), which is then encoded and modulated before being transmitted through the physical layer.

[0066] Each IP packet is processed independently at these protocol stack layers, with each layer adding its own header. For example, the SDAP layer adds its own header 702. PDCP adds its own header 704. RLC adds its own header 706. MAC adds its own header 708. This causes processing overhead to vary with the packet rate rather than the data rate. For example, for a 5 Gbps downlink stream with each IP packet being 1,500 bytes long, approximately 415 packets need to be processed per millisecond.

[0067] Conversely, if 415 packets are sent on the downlink, 415 acknowledgments (ACKs) may be sent on the uplink. Although these uplink ACKs are small, they still require similar packet rate processing even with asymmetrical data rates (e.g., 133 Mbps uplink versus 5 Gbps downlink).

[0068] From a data processing perspective, the scaling of processing overhead with packet rate rather than data rate is not ideal. This means that even if the total amount of data transmitted is not very large, a large number of small packets can still cause a significant processing burden.

[0069] In the LTE specification, IP packets can be concatenated at the RLC layer. The RLC header contains a length field indicating the length of the concatenated RLC Service Data Unit (SDU). For example, there is a first length field indicating the length of the first RLC SDU, a second length field for the second RLC SDU, a third length field for the third RLC SDU, and so on. Therefore, current RLC concatenation requires generating a large amount of length information for the concatenated dataset, resulting in a significant processing burden.

[0070] Figure 8A schematic diagram 800 illustrates the transmission of concatenated data blocks. To address the aforementioned issues, this invention proposes concatenating a group of IP packets into a Layer 2 (L2) payload 802 (without inserting additional headers or length fields between the concatenated IP packets) and adding an L2 header 804 to the concatenated group of packets. The L2 header 804 may include one or a combination of a sequence number (SN), a DRB identifier (DRBID), a stream identifier, and a QoS flow identifier (QoS flow ID). This type of concatenation effectively treats a group of IP packets as a single data block for transmission. In the L2 payload 802, each IP header can point to the location of the next IP header. By reusing existing IP headers to indicate packet boundaries, the need for additional headers is eliminated. This type of concatenated data block reduces processing overhead by treating the aggregated packets across protocol layers (e.g., SDAP, PDCP, RLC, MAC) as a single data unit (e.g., SDU).

[0071] Figure 9(A) is a schematic diagram 900 showing an example of an IPv4 header, and Figure 9(B) is a schematic diagram 950 showing an example of an IPv6 header. As shown in Figure 9(A), the total length field 902 in the IPv4 header can be used to indicate packet boundaries. Similarly, as shown in Figure 9(B), the payload length field 952 in the IPv6 header can be used to indicate packet boundaries. By using the existing length fields within the IP header itself, multiple IP packets can be concatenated without including additional length information in the header to indicate IP packet boundaries, thereby reducing overhead and improving processing efficiency.

[0072] The cascading process is primarily applicable to IP packets. Specifically, it operates on multiple IP packets, utilizing their inherent header information to facilitate boundary identification and subsequent processing.

[0073] However, not all IP packets can be concatenated. Concatenation can be performed on a group of IP packets that share the same or similar QoS requirements. Examples of IP packets with the same or similar QoS requirements include, but are not limited to, one or a combination of the following: (1) A group of IP packets belonging to the same QoS flow; (2) A group of IP packets belonging to the same radio bearer; (3) A group of IP packets that need to be delivered "in order" within a radio bearer or a QoS stream; (4) A group of IP packets arriving together; (5) A set of IP packets that need to be submitted together; and (6) A group of IP packets belonging to the same Protocol Data Unit (PDU) set.

[0074] Generally, packets belonging to different QoS flows may require different processing. Referring to Example (1), this invention proposes to perform concatenation on a group of IP packets that may belong to the same QoS flow. Similarly, referring to Example (2), this invention also proposes to perform concatenation on a group of IP packets that may belong to the same radio bearer.

[0075] Multiple applications can exist within a single radio bearer. However, only data within an application needs to be delivered in sequence. Once the group of packets that needs to be delivered in sequence is identified, the group of IP packets within a radio bearer or a QoS stream can be concatenated, as described in Example (3). Different applications within a radio bearer can be processed separately, and all packets belonging to a single application can be concatenated.

[0076] Another scenario for cascading is when multiple packets arrive at the same time, as described in Example (4). Specifically, if multiple packets (e.g., 50) arrive at the same time, these 50 packets are cascaded. Alternatively, a group of packets that need to be submitted together within a specific deadline can be cascaded, as described in Example (5).

[0077] Example (6) involves a set of packets belonging to a PDU set, a concept introduced by the 3rd Generation Partnership Project (3GPP) to describe larger blocks of information, such as video frames. This concept was introduced to handle virtual reality (VR), augmented reality (AR), and extended reality (XR) information. A video frame is typically about 65 kilobytes in size and consists of about 40 to 50 IP packets. All of these IP packets can be concatenated.

[0078] In addition to the concatenation criteria, this scheme also involves coordination between the transmitter and receiver. At the transmitter end, the transmitter can check whether the length field in the IP header matches the data length before concatenation. This length field is used to identify the data length, thereby determining the position of the next IP header. Verification is necessary to ensure that the IP length value matches the received data length. If a mismatch exists, the IP packet will not be concatenated with other packets, as this would lead to erroneous behavior at the receiver due to the loss of the IP header's boundary indication function.

[0079] Similarly, complete IP packets should be concatenated. If an IP packet is fragmented, the location of the next boundary may not be determined. Therefore, generally only complete IP packets can be concatenated.

[0080] Furthermore, the transmitter can be configured with an upper limit on the amount of data to be concatenated. In some configurations, this upper limit can be the maximum number of IP packets, the maximum size of the concatenated data block, or the time period for accumulating IP packets for concatenation. For example, data arriving within a 1-millisecond time period (i.e., the aggregation time window) can be concatenated. In other words, the transmitter can wait for a 1-millisecond period, accumulate all data arriving within that interval, and transmit it as a single entity. This limit can also be based on the size of the concatenated data block or the packet count.

[0081] At the receiver, the receiver can examine the IP length field of the first packet to identify the location of the next IP header in the received concatenated data block. This process is performed iteratively until the end of the concatenated data block is reached.

[0082] Furthermore, the transmitter can be configured with an upper limit on the amount of data to be concatenated, which can be set by the transmitter or informed by the receiver. In some configurations, the upper limit on the concatenation amount can be informed by the receiver, rather than set by the transmitter. For example, the receiver can inform the transmitter of the maximum number of IP packets it can process or the maximum size of the concatenated data blocks. In other words, the receiver can specify that it can only process a maximum of N concatenated packets or data blocks of size N. This information is then transmitted from the receiver to the transmitter.

[0083] Reference Figure 8 The L2 header information describes the nature of the concatenated data block. Specifically, the header provides a unique serial number (SN) to identify and distinguish a concatenated data block. The header may also include a field indicating whether concatenation is being performed (i.e., whether concatenation is occurring within the packet). This allows the receiver to determine whether to check the IP length field, thereby enabling the identification of individual concatenated packets.

[0084] The header may also include fields to identify the QoS stream, radio bearer, or data stream within or on the radio bearer to which the group belongs.

[0085] Concatenation can occur at various levels. IP packets concatenated in a group are treated as a single data block (e.g., a single SDU) in all subsequent operations following the concatenation process. For example, if concatenation is performed above the SDAP layer, the resulting concatenated data block is treated as a single SDU in the SDAP layer and in subsequent processing at the PDCP, RLC, and MAC layers. If concatenation is performed within the SDAP layer, the concatenated group of packets is treated as a single SDU at the PDCP, RLC, and MAC layers. Similarly, if concatenation is performed within the PDCP layer, the concatenated group is processed jointly at the RLC or MAC layer. Specifically, examples include the following: (1) If cascading is performed above the SDAP layer, the grouping of the cascaded group forms one or a combination of SDAP / PDCP / RLC / MAC SDU.

[0086] (2) If cascading is performed within the SDAP layer, the cascaded groups form one or a combination of PDCP / RLC / MAC SDU (or SDAPPDU).

[0087] (3) If cascading is performed within the PDCP layer, the grouping of the cascaded group forms one or a combination of RLC / MAC SDU (or PDCP PDU).

[0088] (4) If cascading is performed within the CU, the grouping of the cascaded group forms one or a combination of the Central Unit (CU) PDU and the Distributed Unit (DU) SDU.

[0089] For example, if a set of groups is cascaded within a CU, the resulting cascaded block is treated as a single unit; specifically, it is treated as a single SDU at the DU end.

[0090] In 5G, PDCP currently has a 9,000-byte limit. A typical IP packet size is 1,500 bytes, so a maximum of six IP packets can be concatenated. This applies to 5G. However, the 9,000-byte limit for the PDCP layer in 5G may differ in 6G because the maximum size of PDCP may vary. Therefore, the maximum number of IP packets that can be concatenated may also change accordingly.

[0091] Furthermore, if the concatenated IP packets are very large, fragmentation may need to be performed at lower layers. For example, the RLC layer or MAC layer can perform fragmentation on the concatenated IP packets.

[0092] Therefore, the concatenated data block can be split into two blocks. The first block is transmitted in the first transport block, and the second block is transmitted subsequently. The receiver can determine from the header information that the two blocks belong to the same block and will reassemble them.

[0093] For downlink data, if the operation occurs in the core network, the transmitter can be a User Plane Function (UPF). If it occurs in the RAN or at a network radio node, the transmitter can be a gNB or DU, such as base station 102. The receiver can be a User Equipment (UE), such as UE 104. For uplink data, the transmitter is a UE and the receiver is a gNB.

[0094] Therefore, in this invention, the term "transmitter-receiver" is used generally. Depending on the data direction (downlink or uplink), the transmitter or receiver can be a gNB or a UE.

[0095] Figure 10 A schematic diagram 1000 illustrates an example of how multiple IP packets can be concatenated and mapped to various Quality of Service (QoS) flows and Data Radio Bearers (DRBs). Sub-diagrams (a) through (d) highlight different scenarios where IP packets sharing certain characteristics (such as similar QoS requirements or in-order delivery constraints) can be grouped into a concatenated block at a lower protocol layer. In all these scenarios, each IP packet includes an IP header 1004 and a payload 1002. By examining the IP header 1004, the transmitter can determine the boundaries of each packet within the concatenated block, and the receiver can similarly reconstruct the individual packets without relying on additional length fields or boundary indicators from layers such as RLC.

[0096] exist Figure 10 In sub-diagram (a), this schematic shows DRB 1 carrying two different application flows, labeled Flow 1 and Flow 2. Although these flows are carried by the same DRB, packets belonging only to specific applications or flows requiring strict in-order delivery can be concatenated together. Therefore, if Flow 1 corresponds to an application that requires in-order delivery, its IP packets are grouped into a single concatenated block, while packets from Flow 2, if they have different QoS or ordering requirements, can be concatenated separately or processed independently.

[0097] In subgraph (b), DRB 2 carries traffic for multiple QoS flows (labeled QoS flow 2 and QoS flow 3) that belong to flow 3. Even if the packets in flow 3 originate from different QoS flows, each flow can still be concatenated individually. When subgraph (b) shows two blocks, it means that IP packets belonging to QoS flow 2 are concatenated together, and IP packets belonging to QoS flow 3 are concatenated together, thus creating two different concatenated data blocks within the same DRB or flow.

[0098] Subgraph (c) depicts DRB 3, where QoS flow 4 is shown as a single flow in which its IP packets are concatenated. This scenario represents the aggregation of all packets mapped to a particular QoS flow into a single block. Since they share the same QoS constraints and ordering requirements, concatenating them reduces processing overhead by treating multiple IP packets as a single large data unit in subsequent protocol layer operations.

[0099] Subgraph (d) shows that the same DRB (labeled DRB 4) can carry multiple QoS flows (shown as QoS flows 5 and 6), which can be concatenated if they require similar processing. In this example, the sender has chosen to aggregate packets from QoS flows 5 and QoS flows 6 into a single concatenated block, highlighting that these flows can be merged if their QoS characteristics and reordering constraints allow. Each flow retains the ability to be distinguished at the receiver by referring to the associated IP header fields.

[0100] As shown in the figure, the IP header length field (e.g., IPv4 total length or IPv6 payload length) is used at the receiver to identify the boundary of the current IP packet, thereby locating the next IP header. Therefore, there is no need to set additional length or boundary fields at the RLC or MAC layer. The existing IP header information is sufficient to mark packet boundaries, thus reducing overhead compared to existing concatenation schemes that require setting new length indicators in lower-layer protocol headers for concatenated data blocks. By avoiding the inclusion of a separate header dedicated to packet boundary identification, this system significantly reduces processing overhead, especially when many short packets (e.g., acknowledgment packets) arrive. This is advantageous in wireless technologies such as 5G or higher (e.g., 6G), where high packet rates would otherwise lead to disproportionately high processing overhead.

[0101] Furthermore, concatenation can be configured based on various grouping criteria, such as arriving packets sharing the same QoS flow, packets mapped to the same DRB, or packets that need to be delivered together within a specific deadline or in sequence. In any of these cases, the concatenated packets are treated as a single data block in subsequent protocol layer functions (e.g., as a single unit of service at SDAP, PDCP, or RLC). However, if the resulting concatenated block is larger than the maximum transmission unit of the lower layer, fragmentation can still be used at the RLC or MAC layer. After fragmentation, the receiver first reassembles the original concatenated block and then parses each IP packet using its respective IP header length field.

[0102] As described above, unlike the existing cascading mechanisms specified by LTE (where multiple length fields must be included in the RLC header to describe the boundaries of each packet), the scheme disclosed herein relies solely on the IP header length field, thus avoiding the insertion of additional per-packet length information. This reduces the overhead required to identify packet boundaries. Specifically, since the total length or payload length field in each IP header already indicates the size of the packet, this system does not require introducing a separate length field at Layer 2 to determine the start position of the next IP header. Each IP packet remains intact and can be efficiently delimited at the receiver using a standardized IP header structure.

[0103] To facilitate correct resolution of concatenated packets, the L2 header in the transmitter may include a "concatenation indicator" field, which indicates whether the data block consists of multiple IP packets. If this indicator is set, the receiver follows an iterative process, reading the length field of each IP header and jumping to the next IP header accordingly. This contrasts with the conventional approach of generating a separate length field in the RLC subheader for each packet. By using pre-existing IP header information, duplicate length fields are avoided, simplifying assembly on the transmitter side and reassembling packet boundaries on the receiver side.

[0104] Before concatenation, the sender verifies that the IP header length of each packet matches the actual data length of that packet. Any IP packets found to be inconsistent during this length check are excluded from concatenation to prevent misalignment at the receiver. Once valid groups of IP packets are identified, the sender may wait for additional packets or follow thresholds related to size, count, or buffer duration, after which these packets are aggregated into a single data block. This single data block is then passed as a unified SDU or PDU to subsequent layers in the protocol stack, depending on the level at which concatenation was performed. At the receiver, no additional information is required for reassembly, except to identify that a block has been concatenated and subsequently read each IP header sequentially to identify the boundaries that make up the packets.

[0105] This concatenation technique is not limited to a specific maximum SDU size. While current 5G systems enforce a 9,000-byte limit at the PDCP layer, future systems such as 6G may increase or modify this limit. Therefore, the maximum possible number of concatenated IP packets can vary. When the resulting concatenated data block exceeds the transport block size granted by the scheduler, lower-level segmentation can still occur, just as with any large SDU in existing 3GPP systems. In such cases, the receiver seamlessly reassembles the individual segments of the concatenated block using standard procedures for processing segmented SDUs.

[0106] Furthermore, the processing overhead in current 5G systems scales with packet rate rather than data rate, which is particularly inefficient for asymmetric traffic patterns. For example, in the case of 5 Gbps downlink traffic consisting of 1,500-byte packets, approximately 415 packets need to be processed every millisecond. Although the corresponding uplink acknowledgments (ACKs) for these packets may only constitute a data rate of about 133 Mbps (because ACK packets are typically only 40 bytes), the processing burden remains similar because the same number of packets (415) must be processed. This asymmetry between data rate and processing overhead is particularly problematic when processing small packets such as ACKs, as the processing overhead is disproportionately high compared to the actual amount of data transmitted.

[0107] This concatenation scheme can be implemented at various protocol stack locations. For example, if concatenation occurs at the SDAP layer, the concatenated IP packet block will be treated as a single SDAP SDU, which will then become a PDCP SDU, an RLC SDU, and a MAC SDU as it moves down the protocol stack. This reduces processing overhead compared to processing each IP packet separately through the protocol stack.

[0108] The transmitter can impose various constraints on cascading to effectively manage system resources. These constraints can be based on a maximum packet count (e.g., no more than N packets per cascade block), a maximum size (e.g., no more than X bytes), or time-based constraints (e.g., the number of packets arriving in the cascade within a 1-millisecond window). The receiver can also communicate its capabilities to the transmitter, specifying the maximum number or size of packets in the cascade block it can efficiently handle. This bidirectional coordination ensures efficient operation while preventing overflow at the receiver.

[0109] In video frame transmission, the concept of PDU sets becomes particularly relevant. A typical video frame size may be around 65 kilobytes, and it is usually transmitted as 40 to 50 individual IP packets. By concatenating these related packets together, this system can process the content of a logically defined video frame as a single unit through the protocol stack, significantly reducing processing overhead while maintaining the logical relationships between the packets.

[0110] Figure 11(A) illustrates a flowchart 1100 of the process of cascading IP packets in a communication system. This process can be performed by a transmitter. In some configurations, the transmitter can be a user plane function (UPF), such as a gNodeB (gNB) of base station 102, a distributed unit (DU), or a user equipment (UE) such as UE 104.

[0111] At box 1102, the transmitter determines whether multiple Internet Protocol (IP) packets can be cascaded.

[0112] At box 1104, in response to determining that the multiple IP packets can be concatenated, the transmitter concatenates the multiple IP packets into a concatenated data block. The IP header of each IP packet in the concatenated data block indicates the boundary between that IP packet and the next IP packet.

[0113] At box 1106, the transmitter treats the cascaded data block as a separate data unit to perform the corresponding action.

[0114] In some configurations, concatenating the multiple IP packets into the concatenated data block may include: concatenating the multiple IP packets into a single Layer 2 (L2) payload; and appending an L2 header to the single L2 payload. In some configurations, the L2 header may include one or a combination of a sequence number (SN), a Data Radio Bearer Identifier (DRB ID), a stream identifier, and a Quality of Service (QoS) flow identifier.

[0115] In some configurations, treating the cascaded data block as a separate data unit to perform the corresponding action may include transmitting the cascaded data block to the receiver.

[0116] In some configurations, determining whether multiple IP packets can be concatenated may include one or a combination of the following: determining whether the multiple IP packets belong to the same Quality of Service (QoS) flow; determining whether the multiple IP packets belong to the same radio bearer; determining whether the multiple IP packets need to be delivered in order; determining whether the multiple IP packets need to be delivered in order within a radio bearer or a QoS flow; determining whether the multiple IP packets arrive together; determining whether the multiple IP packets need to be delivered together; and determining whether the multiple IP packets belong to the same Protocol Data Unit (PDU) set.

[0117] In some configurations, the process may also include verifying that the length value in the IP header matches the actual length of the IP packet before concatenation.

[0118] In some configurations, this boundary can be indicated by the total length field in the IPv4 header or the payload length field in the IPv6 header.

[0119] In some configurations, the transmitter can be configured with an upper limit on the amount of data contained in the cascaded data block. In other configurations, this upper limit can be informed by the receiver.

[0120] In some configurations, the upper limit can be the maximum number of IP packets, the maximum size of the cascaded data block, or the aggregation time window for cascading the IP packets.

[0121] In some configurations, the cascading of these multiple IP packets can be configured at different protocol stack layers.

[0122] In some configurations, when this concatenation is performed above the Serving Data Adaptation Protocol (SDAP) layer, the concatenated data block can form one or a combination of SDAP Serving Data Unit (SDU), Packet Data Convergence Protocol (PDCP) SDU, Radio Link Control (RLC) SDU, and Media Access Control (MAC) SDU.

[0123] In some configurations, when the cascading is performed within the SDAP layer, the cascaded data block can form one or a combination of the PDCP SDU, the RLC SDU, the MAC SDU, and the SDAP Protocol Data Unit (PDU).

[0124] In some configurations, when the cascading is performed within the PDCP layer, the cascaded data block can form one or a combination of the RLC SDU, the MAC SDU, and the PDCP PDU.

[0125] In some configurations, when the cascading is performed within the Central Unit (CU), the cascaded data blocks can form one or a combination of the CU PDU and the Distributed Unit (DU) SDU.

[0126] Figure 11(B) illustrates a flowchart 1150 of the process of cascading IP packets in a communication system. This process can be performed by a receiver. In some configurations, the receiver can be a gNodeB (gNB) such as base station 102, or a user equipment (UE) such as UE 104.

[0127] At box 1152, the receiver receives a concatenated data block from the transmitter, wherein the concatenated data block is formed by multiple Internet Protocol (IP) packets.

[0128] At box 1154, the receiver iteratively parses the concatenated data block to locate each of the multiple IP packets, based on the IP header of each IP packet in the concatenated data block indicating the boundary between the IP packet and the next IP packet.

[0129] In some configurations, the process may also include: identifying multiple segments belonging to the cascaded data block; and reassembling the multiple segments to form the cascaded data block.

[0130] In some configurations, the process may also include informing the sender of an upper limit on the amount of data contained in the cascaded data block.

[0131] In some configurations, the upper limit can be the maximum number of IP packets, the maximum size of the cascaded data block, or the aggregation time window for cascading the IP packets.

[0132] It should be understood that the specific order or hierarchy of the boxes in the disclosed process / flowchart is an illustration of an exemplary scheme. Based on design preferences, it should be understood that the specific order or hierarchy of the boxes in the process / flowchart may be rearranged. Furthermore, some boxes may be combined or omitted. The appended method claims present the elements of the boxes in an exemplary order and are not intended to be limited to the specific order or hierarchy presented.

[0133] The foregoing description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects. Therefore, the claims are not intended to be limited to the aspects shown herein, but should be given the broadest scope consistent with the language of the claims, wherein reference to an element in the singular is not intended to mean "one and only one" (unless expressly stated otherwise), but rather "one or more". The term "exemplary" as used herein means "as an example, instance, or illustration". Any aspect described herein as "exemplary" is not necessarily to be construed as superior to or better than other aspects. Unless expressly stated otherwise, the term "some" means one or more. Combinations such as "at least one of A, B, or C", "one or more of A, B, or C", "at least one of A, B, and C", "one or more of A, B, and C", and "A, B, C, or any combination thereof" include any combination of A, B, and / or C, and may include multiple A, multiple B, or multiple C. Specifically, combinations such as "at least one of A, B, or C", "one or more of A, B, or C", "at least one of A, B, and C", "one or more of A, B, and C", and "A, B, C, or any combination thereof" can be A only, B only, C only, A and B, A and C, B and C, or A and B and C, wherein any such combination may include one or more members of A, B, or C. All structural and functional equivalents known or subsequently learned by those skilled in the art to be equivalent to elements of all aspects described herein are expressly incorporated herein by reference and are intended to be covered by the claims. Furthermore, nothing disclosed herein is intended to be offered to the public, whether or not such disclosure is expressly stated in the claims. Terms such as "module", "mechanism", "element", and "device" are not intended to replace the word "means". Therefore, unless an element is expressly stated as "means for...", no claim element should be construed as a means plus a function.

Claims

1. A wireless communication method for a transmitter in a wireless communication network, comprising: Determine whether multiple Internet Protocol (IP) packets can be concatenated; In response to determining that the plurality of IP packets can be concatenated, the plurality of IP packets are concatenated into a concatenated data block, wherein the IP header of each IP packet in the concatenated data block indicates the boundary between the IP packet and the next IP packet; as well as The cascaded data blocks are treated as individual data units to perform corresponding actions.

2. The method according to claim 1, wherein concatenating the plurality of IP packets into the concatenated data block comprises: The multiple IP packets are concatenated into a single Layer 2 (L2) payload; as well as The L2 header is attached to the single L2 payload.

3. The method of claim 2, wherein the L2 header includes one or a combination of a sequence number (SN), a data radio bearer identifier (DRB ID), a stream identifier (stream ID), and a quality of service (QoS) flow identifier (QoS flow ID).

4. The method of claim 1, wherein treating the cascaded data block as the individual data unit to perform the corresponding action comprises: The cascaded data blocks are transmitted to the receiver.

5. The method of claim 1, wherein determining whether the plurality of IP packets can be cascaded includes one or a combination of the following: Determine whether the multiple IP packets belong to the same Quality of Service (QoS) flow; Determine whether the multiple IP packets belong to the same wireless bearer; Determine whether the multiple IP packets need to be delivered in sequence; Determine whether the multiple IP packets need to be delivered sequentially within a single radio bearer or a single QoS flow; Determine whether the multiple IP packets arrived together; Determine whether the multiple IP packets need to be submitted together; as well as Determine whether the multiple IP packets belong to the same Protocol Data Unit (PDU) set.

6. The method according to claim 1, further comprising: Before concatenation, verify that the length value in the IP header matches the actual length of the IP packet.

7. The method of claim 1, wherein the boundary is indicated by the total length field in the IPv4 header or the payload length field in the IPv6 header.

8. The method of claim 1, wherein the transmitter is configured with an upper limit on the amount of data contained in the cascaded data block.

9. The method of claim 8, wherein the upper limit is informed by the receiver.

10. The method of claim 8, wherein the upper limit is the maximum number of the plurality of IP packets, the maximum size of the concatenated data block, or the aggregation time window for accumulating the plurality of IP packets for concatenation.

11. The method of claim 1, wherein the concatenation of the plurality of IP packets is configured on different protocol stack layers.

12. The method of claim 11, wherein When the concatenation is performed above the Service Data Adaptation Protocol (SDAP) layer, the concatenated data blocks form one or a combination of SDAP Service Data Unit (SDU), Packet Data Convergence Protocol (PDCP) SDU, Radio Link Control (RLC) SDU, and Media Access Control (MAC) SDU. When the concatenation is performed within the SDAP layer, the concatenated data blocks form one or a combination of the PDCP SDU, the RLCSDU, the MAC SDU, and the SDAP Protocol Data Unit (PDU). When the cascading is performed within the PDCP layer, the cascaded data blocks form one or a combination of the RLC SDU, the MAC SDU, and the PDCP PDU; or When the cascading is performed within the Central Unit (CU), the cascaded data blocks form one or a combination of the CU PDU and the Distributed Unit (DU) SDU.

13. The method of claim 1, wherein the transmitter is a User Plane Function (UPF), gNodeB (gNB), Distributed Unit (DU), or User Equipment (UE).

14. A wireless communication method for a receiver in a wireless communication network, comprising: The transmitter receives concatenated data blocks, wherein the concatenated data blocks are formed by multiple Internet Protocol (IP) packets; as well as The concatenated data block is iteratively parsed to locate each of the plurality of IP packets, based on the IP header of each IP packet in the concatenated data block indicating the boundary between that IP packet and the next IP packet.

15. The method of claim 14, further comprising: Identify multiple blocks belonging to the cascaded data block; as well as The multiple blocks are reorganized to form the cascaded data block.

16. The method of claim 14, wherein the receiver is a gNodeB (gNB) or a user equipment (UE).

17. The method of claim 14, further comprising: The transmitter is informed of the upper limit of the amount of data contained in the cascaded data block.

18. The method of claim 17, wherein the upper limit is the maximum number of the plurality of IP packets, the maximum size of the concatenated data block, or the aggregation time window for accumulating the plurality of IP packets for concatenation.

19. An apparatus for wireless communication, the apparatus being a transmitter in a wireless communication network, the transmitter comprising: Memory; as well as At least one processor, coupled to the memory and configured to: Determine whether multiple Internet Protocol (IP) packets can be concatenated; In response to determining that the plurality of IP packets can be concatenated, the plurality of IP packets are concatenated into a concatenated data block, wherein the IP header of each IP packet in the concatenated data block indicates the boundary between the IP packet and the next IP packet; as well as The cascaded data blocks are treated as individual data units to perform corresponding actions.

20. A computer-readable medium storing computer-executable code for wireless communication of a transmitter in a wireless communication network, comprising code for performing the following operations: Determine whether multiple Internet Protocol (IP) packets can be concatenated; In response to determining that the plurality of IP packets can be concatenated, the plurality of IP packets are concatenated into a concatenated data block, wherein the IP header of each IP packet in the concatenated data block indicates the boundary between the IP packet and the next IP packet; as well as The cascaded data blocks are treated as individual data units to perform corresponding actions.

21. An apparatus for wireless communication, the apparatus being a receiver in a wireless communication network, the receiver comprising: Memory; as well as At least one processor, coupled to the memory and configured to: The transmitter receives concatenated data blocks, wherein the concatenated data blocks are formed by multiple Internet Protocol (IP) packets; as well as The concatenated data block is iteratively parsed to locate each of the plurality of IP packets, based on the IP header of each IP packet in the concatenated data block indicating the boundary between that IP packet and the next IP packet.

22. A computer-readable medium storing computer-executable code for wireless communication of a receiver in a wireless communication network, comprising code for performing the following operations: The transmitter receives concatenated data blocks, wherein the concatenated data blocks are formed by multiple Internet Protocol (IP) packets; and The concatenated data block is iteratively parsed to locate each of the plurality of IP packets, based on the IP header of each IP packet in the concatenated data block indicating the boundary between that IP packet and the next IP packet.

Images