Patent Description:
To meet the demand for wireless data traffic having increased since deployment of <NUM>th generation (<NUM>) communication systems, efforts have been made to develop an improved <NUM>th generation (<NUM>) or pre-<NUM> communication system. Therefore, the <NUM> or pre-<NUM> communication system is also called a "Beyond <NUM> Network" or a "Post long-term evolution (LTE) System. " The <NUM> communication system is considered to be implemented in higher frequency millimeter wave (mmWave) bands, e.g., <NUM> bands, so as to accomplish higher data rates. In the <NUM> system, hybrid frequency shift keying (FSK) and quadrature amplitude modulation (QAM) (FQAM) and sliding window superposition coding (SWSC) as an advanced coding modulation (ACM), and filter bank multi carrier (FBMC), non-orthogonal multiple access (NOMA), and sparse code multiple access (SCMA) as an advanced access technology have also been developed.

As technology elements, such as "sensing technology," "wired/wireless communication and network infrastructure," "service interface technology," and "security technology" have been demanded for IoT implementation, a sensor network, a machine-to-machine (M2M) communication, machine type communication (MTC), and so forth have been recently researched.

A base station providing a mobile communication service has an integrated type in which a data processing unit or a digital unit (or distributed unit (DU)) of a base station and a wireless transmission/reception unit or a radio (radio unit or remote unit (RU)) are installed together at a cell site according to the related art. However, since this type of base station is not suitable for the needs of mobile operators who want to build a number of cell sites according to the increase in users and traffic, an improved centralized RAN (C-RAN or cloud RAN) structure has emerged. The C-RAN has a structure in which DUs are intensively arranged in one physical place and only RUs are left at a cell site that transmits and receives radio signals to and from the actual terminal, and the DU and the RU can be connected with an optical cable or a coaxial cable. In addition, as the RU and the DU are separated, an interface standard for communication between them is required, and standards such as common public radio interface (CPRI) are currently used between the RU and the DU. In addition, such a base station structure is standardized in 3rd generation partnership project (3GPP), and open radio access network (O-RAN), an open network standard applicable to <NUM> systems, has been studied.

In addition, in order to meet the demand for wireless data traffic, a <NUM> communication system (hereinafter, mixed with <NUM> system, NR (new radio or next radio) system, etc.) has been studied, it is expected that the <NUM> system will be able to provide services with high data rates to users, and it is expected that wireless communication services with various purposes, such as the Internet of Things and services that require high reliability for specific purposes, will be provided.

The above information is presented as background information only, and to assist with an understanding of the disclosure. <NPL>, provides control, user and synchronization plane specification. <CIT> relates to efficient usage of Multimedia Broadcast/Multicast Services over Single Frequency Network (MBSFN) subframes for unicast transmissions.

When the base station using the O-RAN operates the MBSFN, there is a need for a method of operation so that the DU transmits a control message including information related to the subframe structure to the RU so that the RU can efficiently determine whether zero padding is required before completing analysis of one subframe.

Aspects of the disclosure are to address at least the above-mentioned problems and/or disadvantages, and to provide at least the advantages described below.

In accordance with an aspect of the disclosure, a method of generating a control message of a digital unit (DU) of a base station in a wireless communication system supporting lower layer function split of the is provided. The method includes identifying subframe configuration information, generating a control message comprising multimedia broadcast multicast service single frequency network (MBSFN)-related information for the subframe, based on the identification, and transmitting the generated control message to a radio unit (RU) of the base station connected to the DU, wherein the MBSFN-related information is for zero padding in the subframe of the radio unit.

In accordance with another aspect of the disclosure, a method of processing a control message for an RU of a base station in a wireless communication system supporting lower layer function division is provided. The method includes receiving a control message including MBSFN-related information for a subframe from a DU of the base station, and performing zero padding in a subframe, based on the MBSFN-related information.

In accordance with another aspect of the disclosure, a DU device of a base station generating a control message in a wireless communication system supporting lower layer function division is provided. The base station includes a connector configured to transmit and receive a signal with an RU of the base station connected to the DU, and at least one processor or controller configured to identify subframe configuration information, generate a control message comprising MBSFN-related information for the subframe, based on the identification, and control to transmit the generated control message to the RU, wherein the MBSFN-related information is for zero padding in the subframe of the radio unit.

In accordance with another aspect of the disclosure, an RU device of a base station processing a control message in a wireless communication system supporting lower layer function division of the disclosure includes a connector configured to transmit and receive a signal with a DU of the base station, a transceiver configured to wirelessly transmit and receive a signal with a terminal, and at least one processor or controller configured to control to receive a control message comprising MBSFN-related information for a subframe from the DU through the connector, and control to perform zero padding in the subframe, based on the MBSFN-related information.

In accordance with another aspect of the disclosure, since all control plane section analysis of symbol configuration information of one subframe can be reduced by two flag analysis, the processing load of the RU can be reduced.

In accordance with another aspect of the disclosure, since the RU does not need to analyze the subframe structure in association with other control plane sections, the complexity may also be reduced.

In accordance with another aspect of the disclosure, since it is possible to determine whether or not zero padding is required through one control plane message before the analysis of one subframe is completed, a latency for zero padding can be reduced.

The above and other aspects, features, and advantages, of certain embodiments of the disclosure will be more apparent from the following description taken in conjunction with the accompanying drawings, in which:.

In addition, description of well-known functions and constructions may be omitted for clarity and conciseness.

The terms and words used in the following description and claims are not limited to the bibliographical meanings, but are merely used to enable a clear and consistent understanding of the disclosure. Accordingly, it should be apparent to those skilled in the art that the following description of various embodiments of the disclosure is provided for illustration purpose only, and not for the purpose of limiting the disclosure as defined by the appended claims.

These computer program instructions can be provided to a processor of a general-purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart block or blocks. These computer program instructions may also be stored in a non-transitory computer usable or computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer usable or computer-readable memory produce an article of manufacture including instruction means that implement the function specified in the flowchart block or blocks. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operations to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions that execute on the computer or other programmable apparatus provide operations for implementing the functions specified in the flowchart block or blocks.

As used herein, the "unit" refers to a software element or a hardware element, such as a Field Programmable Gate Array (FPGA) or an Application Specific Integrated Circuit (ASIC), which performs a predetermined function. However, the "unit" does not always have a meaning limited to software or hardware. The "unit" may be constructed either to be stored in an addressable storage medium or to execute one or more processors. Therefore, the "unit" includes, for example, software elements, object-oriented software elements, class elements or task elements, processes, functions, properties, procedures, sub-routines, segments of a program code, drivers, firmware, micro-codes, circuits, data, database, data structures, tables, arrays, and parameters. The elements and functions provided by the "unit" may be either combined into a smaller number of elements, or a "unit," or divided into a larger number of elements, or a "unit. " Moreover, the elements and "units" or may be implemented to reproduce one or more central processing units (CPUs) within a device or a security multimedia card.

Hereinafter, in the disclosure, uplink (UL) refers to a radio link through which a terminal transmits data or control signals to a base station, and downlink (DL) refers to a radio link through which a base station transmits data or control signals to a terminal. In addition, the base station may be at least one of an evolved NodeB (eNodeB or eNB), a Node B, a base station (BS), a next-generation Node B (gNB) radio access unit, a base station controller, or a node on a network as a subject performing resource allocation of the terminal. The terminal may include a user equipment (UE), a mobile station (MS), a cellular phone, a smart phone, a computer, or a multimedia system capable of performing a communication function.

In order to meet the demand for wireless data traffic, the <NUM>th generation (<NUM>) communication system has been commercialized, and it is expected that wireless communication services with various purposes, such as the Internet of Things (IoT) and services that require high reliability for specific purposes, can be provided.

In order to support the network system in which the current <NUM>th generation (<NUM>) communication system, <NUM> communication system, etc. are mixed, in the open radio access network alliance (O-RAN Alliance), established by business operators and equipment providers, the open radio access network (O-RAN) structure has emerged by defining new network elements (NEs) and interface standards based on the existing 3rd generation partnership project (3GPP) standards. O-RAN newly defined a radio unit (RU), a digital unit (DU), a central unit-control plane (CU-CP), and a central unit-user plane (CU-UP), which are the existing 3GPP NEs, as an O-RU, an O-DU, an O-CU-CP, and an O-CU-UP, respectively (these can be collectively referred to as an O-RAN base station), and additionally standardized a near-real-time radio access network (RAN) intelligent controller (RIC) and a non-real-time RAN intelligent controller (NRT-RIC). Each of the O-DU and RIC, O-CU-CP and RIC, and O-CU-UP and RIC can be connected by Ethernet. In addition, interface standards for communication between the O-DU and RIC, between the O-CU-CP and RIC, and between the O-CU-UP and RIC were required. Currently, standards such as an E2-DU, an E2-CU-CP, and an E2-CU-UP can be used between an O-DU, an O-CU-CP, an O-CU-UP, and an RIC.

<FIG> is a view illustrating an O-RAN network system according to an embodiment of the disclosure.

Referring to <FIG>, the O-RAN network is a standard that logically separates the functions of the eNB and gNB of the existing <NUM> and <NUM> systems, and in the O-RAN standard, an NRT-RIC <NUM>, an RIC <NUM>, an O-CU-CP <NUM>, an O-CU-UP <NUM>, an O-DU <NUM>, an O-RU <NUM>, and the like, in an O-RAN gNB <NUM> are defined.

The NRT-RIC <NUM> is a logical node that enables non-real-time control, optimization of RAN elements and resources, model training, update, and the like. The newly defined RIC <NUM> is a logical node that enables near-real-time control and optimization of RAN elements and resources, based on the data collected from O-DU <NUM>, O-CU-CP <NUM>, O-CU-UP <NUM>, etc. through an E2 interface by intensively arranging servers in one physical location. The O-CU including the O-CU-CP <NUM> and the O-CU-UP <NUM> is a logical node that provides functions of radio resource control (RRC), service data adaptation protocol (SDAP), and packet data convergence protocol (PDCP) protocols. The O-CU-CP <NUM> is a logical node that provides functions of a control plane portion of RRC and PDCP, and the O-CU-UP <NUM> is a logical node that provides functions of a user plane portion of SDAP and PDCP. The O-CU-CP <NUM> is connected to an access and mobility management function (AMF) included in a <NUM> network (<NUM> core) through a next generation (NG) application protocol (NGAP) interface. The O-DU <NUM> is a logical node that provides RLC, MAC, and higher physical layer (high-PHY) functions, and the O-RU <NUM> connected to the O-DU <NUM> is a logical node that provides low-PHY functions and radio frequency (RF) processing. In <FIG>, each logical node is shown in a singular number, but each logical node may be connected in plural. For example, a plurality of O-RUs <NUM> may be connected to one O-DU <NUM>, and a plurality of O-DUs <NUM> may be connected to one O-CU-UP <NUM>.

The disclosure is not limited by the name of each node described above, and in the case of a logical node or entity performing the above-described function, the configuration of the disclosure may be applied. In addition, the logical node may be physically located in the same location or different locations, and may be provided with a function by the same physical device (e.g., a processor, a controller, etc.) or by another physical device. As an example, the function of at least one logical node described above may be provided through virtualization in one physical device. Hereinafter, O-DU may be mixed with a DU and an O-RU may be mixed with an RU.

<FIG> is a view illustrating an example of a low layer function split through an RU and a DU according to an embodiment of the disclosure.

<NUM> is a view illustrating the format of a message transmitted between an O-RU and an O-DU according to an embodiment of the disclosure.

Referring to <FIG> and <FIG>, the RU and DU may be connected through a fronthaul (FH). In this case, the RU and DU may each perform a function of a physical layer.

In a physical layer for downlink in a <NUM> or <NUM> communication system, channel coding and scrambling for the received data by receiving downlink data from a media access control (MAC) layer <NUM> are performed at <NUM>, and layer mapping of the modulation symbol is performed at <NUM> after modulation is performed on the scrambled data at <NUM>. The modulation symbol mapped to each layer is mapped to each antenna port at <NUM> and is mapped to a corresponding resource element (RE, an allocation unit of resources consisting of one subcarrier and one symbol) at <NUM>. Digital beamforming (which can be mixed with precoding) is performed on the modulation symbol at <NUM>, and inverse fast Fourier transform (FFT) (IFFT) is performed to transform the same into a time domain signal. Thereafter, a cyclic prefix (CP) is added at <NUM>, and the modulation symbol is carried on a carrier frequency in an RF <NUM> and transmitted to the terminal through an antenna. In addition, in a physical layer for uplink in a <NUM> or <NUM> communication system, a signal of a carrier frequency received through an antenna is converted to a baseband signal at an RF <NUM>, the converted signal is transformed into a frequency domain signal through CP removal and FFT at <NUM>, the applied digital beamforming is reversely applied to combine the uplink signal at <NUM>, the signal is de-mapped at <NUM> in the RE to which the uplink signal was mapped, channel estimation at <NUM> is performed, layer de-mapping at <NUM> is performed to demodulate the aligned modulation symbols at <NUM>, and the bit sequence obtained as a result of demodulation is descrambled and decoded to obtain information bits at <NUM>. Thereafter, the information bits are transmitted to a MAC layer <NUM>.

There are various options for dividing the lower layer function, and in <FIG>, for example, option <NUM> (<NUM>), option <NUM>-<NUM> (<NUM>), option <NUM>-<NUM> (<NUM>), option <NUM>-2x category B (<NUM>), option <NUM>-2x category A (<NUM>), option <NUM>-<NUM> (<NUM>) and option <NUM> (<NUM>) are shown. In this case, it may be understood that a function located on the right side based on one option is performed by the DU, and a function located on the left side is performed by the RU. For example, the common public radio interface (CPRI) of the long-term evolution (LTE) system corresponds to option <NUM>, and in the case of downlink, a signal to which all the processes of the physical layer shown in <FIG> are performed in the DU is transmitted to the RU through the FH, and the RU only converts the received signal into an analog signal and transmits the converted analog signal to the terminal. However, as the number of functions performed by the DU increases, the bandwidth of the required fronthaul increases. Therefore, the O-RAN may support option <NUM>-2x category B (<NUM>) and option <NUM>-2x category A (<NUM>).

Specifically, category A (<NUM>) of option <NUM>-2x corresponds to the capability category of O-RUs that cannot process the precoding of data received by the O-RU from the O-DU, and category B (<NUM>) of option <NUM>-2x corresponds to the capability category of the O-RU capable of processing the precoding of data received by the O-RU from the O-DU. The O-DU shall support category A O-RU for <NUM> or fewer transport streams. That is, it can be said that the O-DU supports precoding of up to <NUM> transport streams. In this case, when option <NUM>-2x category B (<NUM>) is applied, the O-DU transmits information on the modulation symbol that has finished layer mapping and beamforming information to the O-RU, and the O-RU applies beamforming to the modulation symbol and converts the same into an analog signal and transmits the analog signal to the terminal through an antenna.

There are four types of information to be transmitted from the O-DU of Option <NUM>-2x to the O-RU. Information transmitted from a management-plane (M-plane) is transmitted in both directions of DL and UL by non-real-time transmission, and is information for initial configuration or reconfiguration (or reset) between O-DU and O-RU. Information transmitted in a synchronization-plane (the S-plane) is transmitted in real time, and is information for synchronizing or timing synchronization between O-DU and O-RU. Information transmitted in a control-plane (C-plane) is transmitted in the DL direction by real-time transmission, and is information for the O-DU to transmit a scheduling and/or beamforming command to the O-RU. Information transmitted from a U-plane (user-plane) is transmitted in both directions of DL and UL by real-time transmission. DL frequency domain in-phase and quadrature component data (IQ data) (including synchronization signal block (SSB) and reference signal), UL frequency domain IQ data (including a reference signal such as a sounding reference signal) and frequency domain IQ data for a physical random-access channel (PRACH) are transmitted in the U-plane. The information or data can be mixed with the message.

Next, information transmitted between the O-RU and the O-DU will be described in more detail. <FIG> is a view illustrating a format of a message transmitted between an O-RU and an O-DU. The O-RU and O-DU are connected by Ethernet, and the standard of the Ethernet message is the same as shown at <NUM>. The payload of the Ethernet message includes a message in a format according to each plane. For example, the format of the C-plane is shown at <NUM>. The C-plane format <NUM> includes an enhanced CPRI (eCPRI) header <NUM> and an O-RAN header <NUM>. In addition, the payload may include information of a U-plane format <NUM> or a format according to another plane.

<FIG> is a view illustrating in detail a standard of an Ethernet message according to an embodiment of the disclosure.

Referring to <FIG>, in the header of the Ethernet message, a destination MAC address <NUM> indicates the public address of the RU or massive MIMO unit (MMU) in the case of DL, and in the case of UL, a destination MAC address <NUM> indicates the public address of a specific port of the channel card (which can perform an operation of converting the data format according to the operation of the MAC layer in charge of scheduling, the operation of the high-PHY, and the interface between the RU and the DU) of the DU. A source MAC Address <NUM> indicates the public address of the RU or MMU in the case of UL, and indicates the public address of a specific port of a channel card of DU in the case of DL.

A virtual local area network (LAN) (VLAN) Tag <NUM> is <NUM> bytes, and allows C, U, or S-plane messages to be mapped to different VLAN tags to be managed. The tag protocol identifier (TPID) included in the VLAN tag is <NUM> bits and is configured as a value of 0x8100 to identify the frame as an IEEE <NUM>. 1Q tag frame. Since this field is located at the same position as the Ethertype/Length field <NUM> in the untagged frame, the field is used to distinguish the untagged frame from the general frame. The tag control information (TCI) included in the VLAN Tag is <NUM> bits and includes the following three fields. Apriority code point (PCP) expresses the priority of a frame with <NUM> bits. A drop eligible indicator (DEI) is <NUM> bit and is used separately from or in combination with PCP, and it is removed when traffic is congested so that good frames are classified. The VLAN identifier (VID) is a field indicating which frame the VLAN belongs to with <NUM> bits. All other values except for the reserved values, 0x000 and 0xFFF, are used as VLAN identifiers, and up to <NUM>,<NUM> VLANs are allowed. A preliminary value of 0x000 indicates that the frame does not belong to any VLAN. In this case, <NUM>. 1Q can only designate a priority and refer to it as a priority tag. Since Type/Length (Ethertype) is for eCPRI, it is configured as a fixed value of 0xAEFE.

A payload <NUM> may include a message according to each plane format including an eCPRI header as shown in <FIG>. The content of each field or information described in relation to <FIG> does not necessarily include all fields, and the disclosure may be implemented by omitting or/and adding other fields as necessary.

<FIG> is a view illustrating a format of an eCPRI header according to an embodiment of the disclosure.

Referring to <FIG>, the eCPRI header is a transport header and is located in front of the Ethernet payload (<NUM> in <FIG>). The eCPRI header is <NUM> bytes in total, and an ecpriVersion <NUM> is <NUM> bits, and a fixed value of 0001b is used, an ecpriReserved <NUM> is <NUM> bits and a fixed value of 0000b is used, an ecpriConcatenation <NUM> is <NUM> bit and a fixed value of 0b is used, and an ecpriMessage <NUM> is <NUM> byte and indicates the type of message. In the case of U-plane, a value of <NUM>0000b (0x0) may be used, in the case of a C-plane, a value of <NUM>0010b (0x2) may be used, and in the case of eCPRI delay measurement, a value of <NUM>0101b (0x5) may be used.

An ecpriPayload <NUM> is <NUM> bytes and represents the size of the payload in bytes, an ecpriRtcid/ecpriPcid <NUM> is <NUM> bytes, and the number of bits per field described below can be configured through M-plane configuration. The CU_Port_ID (x bits) included in the ecpriRtcid/ecpriPcid <NUM> allows the channel card of the RU to be distinguished, and in this case, even a modem can be distinguished. In this case, <NUM> bits may be used to distinguish a channel card and <NUM> bits may be used to distinguish a modem. BandSector_ID (y bits) may indicate a corresponding cell or sector. CC_ID (z bits) may indicate a corresponding component carrier. RU_Port_ID (w bits) may be configured to distinguish a layer, an antenna, and the like.

An ecpriSeqid <NUM> is <NUM> bytes and is a sequence ID managed for each ecpriRtcid/ecpriPcid <NUM>, and a sequence ID and a subsequence ID are separately managed. Radio-transport-level fragmentation is possible by using the subsequence ID. The content of each field or information described with respect to <FIG> does not necessarily include all fields, and the disclosure may be implemented by omitting and/or adding other fields as necessary.

Next, the C-plane message will be described in detail.

<FIG> is a view illustrating a flow in which scheduling and beamforming commands are transmitted through C-plane and U-plane messages according to an embodiment of the disclosure.

Referring to <FIG>, an O-DU <NUM> transmits a control (C-plane) message for U-plane data in slot #n to an O-RU <NUM> at <NUM>. The C-plane message is an eCPRI message type <NUM>, and transfers allocation information for a section and beamforming information corresponding to each section in <NUM> section Type messages. A section means an area in which RB resources having the same beam pattern are continuously allocated within one slot, and data of U-plane may be transmitted for each section. In general, one section may include <NUM> REs (or subcarriers) (that is, <NUM> resource block (RB)) to <NUM> RBs on the frequency axis, and may be a rectangle having <NUM> symbol to <NUM> symbols on the time axis. One section may include contiguous or non-contiguous allocations. If the beams applied within the <NUM> REs (1RB) are different, one section may be divided according to a plurality of REMasks having different bit patterns.

Six types of section types can be supported as follows:.

The O-DU <NUM> transmitting the C-plane message transmits IQ data for each OFDM symbol in slot #n as a U-plane message at <NUM>, <NUM>, and <NUM>. The U-Plane message transfers IQ data (and reference signal, SSB) and PRACH IQ data for a user using eCPRI message type <NUM>. There are two data formats in the U-plane data. In the case of DL/UL user data and static data format, the IQ format and compression method are fixed, and the IQ format and compression method are configured by the M-Plane message at the RU initialization time. In the case of DL/UL user data and dynamic data format, the IQ format and compression method may be dynamically changed, which is configured by a DL U-Plane message and a UL C-Plane message.

Thereafter, the O-DU <NUM> transmits a C-plane message for U-plane data in slot #n+<NUM> to the O-RU <NUM> at <NUM>. Thereafter, the O-DU <NUM> transmits IQ data for each OFDM symbol of slot #n+<NUM> to the O-RU <NUM> as a U-plane message at <NUM>, <NUM>, and <NUM>.

Although <FIG> illustrates the case of DL transmission, the UL transmission may be performed similarly. Specifically, the O-DU transmits a C-plane message, and the O-RU that receives the message transmits IQ data for each symbol of a corresponding slot to an O-DU as a U-plane message.

<FIG> is a view illustrating a format of a C-plane message of section type <NUM> according to an embodiment of the disclosure.

Referring to <FIG>, a transport header <NUM> may be an eCPRI header shown in <FIG> or information according to IEEE-<NUM>. A dataDirection <NUM> indicates the direction of the U-Plane message, <NUM> indicates UL, and <NUM> indicates DL. A filterIndex <NUM> indicates a channel filter of the RU, and may be configured as 0x1. A frameId <NUM> indicates a specific frame in units of <NUM>. A subframeId <NUM> indicates a specific subframe in units of <NUM> in the corresponding frame. A slotId <NUM> indicates a specific slot in a corresponding frame. A startSymbolid <NUM> indicates a start Symbol in a corresponding frame.

A numberOfsections <NUM> indicates the number of sections indicated by the corresponding message. In the case of a SectionType <NUM>, one C-plane message can have only one section type. AudCompHdr <NUM> indicates the width (bit) of IQ bits for IQ data of all sections of a corresponding message and a compression method. Specifically, upper <NUM> bits indicate <NUM> to <NUM> bits as iqWidth, and lower <NUM> bits indicate compMeth indicating a compression method. The above-described <NUM> to <NUM> are application headers <NUM> commonly applied to a corresponding message, and are similarly applied to all C-plane messages.

The C-plane message of section type <NUM> contains information on an arbitrary section. A sectionID <NUM> indicates the ID of a section, which can be used for matching the C-plane message and the U-plane message. An rb <NUM> may indicate which physical resource block (PRB) is used, <NUM> may indicate that all PRBs are used, and <NUM> may indicate that one PRB (every other PRB) is used for every two. A startPrbc <NUM> is used to indicate the first PRB of the section, and a numPrbc <NUM> is used to indicate the number of PRBs in the section. An reMask <NUM> is a bit pattern indicating an RE (or subcarrier) corresponding to a specific beam in a corresponding PRB, and different beams may be applied in one PRB through the reMask. A numSymbol <NUM> may indicate the number of symbols corresponding to the corresponding section, an ef <NUM> may indicate whether a beamforming weight is provided, <NUM> may indicate that no beamforming weight is provided, and <NUM> may indicate that a weight according to the beam identifier (beamId) is provided. A beamId <NUM> and <NUM> indicates a specific index of a weight table predefined for a corresponding section. The above-described <NUM> to <NUM> may be referred to as a section header <NUM> for each section.

In addition, a section extension may be included in the C-plane message, and whether the section extension is included may be indicated by an ef <NUM>. The content of each field or information described in relation to <FIG> does not necessarily include all fields, and the disclosure may be implemented by omitting or/and adding other fields as necessary.

<FIG> is a view illustrating section extension according to an embodiment of the disclosure.

Referring to <FIG>, the C-plane message may include a transport header <NUM>, an application header <NUM>, and one or more section headers <NUM>, and may include a section extension <NUM>. An ef <NUM> included in the section header <NUM> may indicate whether a section extension is included, and if there is a section extension, details thereof are as follows.

The section extension <NUM> may include the following fields. An ef <NUM> indicates whether another section extension is included, and an extType <NUM> indicates the type of the section extension. In the type of section extension, there may be cases in which a beamforming weight is transmitted, beamforming attributes are transmitted, a precoding setting and parameter is transmitted, a modulation compression related parameter is transmitted, information on non-consecutive PRB allocation is transmitted, and a plurality of extended antenna-carriers (eAxCs), a digital baseband user-plane required for reception or transmission of one carrier in one independent antenna element, which may mean transmission for each layer) are used as a destination. An extLen <NUM> indicates the length of the corresponding section extension in units of <NUM> bytes, and the section extension <NUM> may include zero padding <NUM> for alignment in units of <NUM> bytes. The content of each field or information described with respect to <FIG> does not necessarily include all fields, and the disclosure may be implemented by omitting and/or adding other fields as necessary.

In addition to the C-plane message according to the section type <NUM> described above, there may be a C-plane message corresponding to the section type as described above, and may contain the same or different fields or information according to the purpose of each section type.

In recent wireless communication systems, multimedia broadcast multicast service (MBMS) is provided. The MBMS is a broadcast service provided through wireless communication systems such as LTE.

<FIG> is a view illustrating a conceptual diagram of MBMS according to an embodiment of the disclosure.

Referring to <FIG>, an MBMS service area <NUM> is a network area composed of a plurality of base stations capable of performing MBSFN transmission. An MBSFN Area <NUM> is a network area composed of several cells integrated for MBSFN transmission, and all cells in the MBSFN Area are synchronized with MBSFN transmission. All cells except for MBSFN Area Reserved Cells <NUM> are used for MBSFN transmission. The MBSFN Area Reserved Cell <NUM> is a cell that is not used for MBSFN transmission, and can be transmitted for other purposes, but limited transmission power may be allowed for radio resources allocated for MBSFN transmission.

<FIG> is a view illustrating a downlink channel mapping diagram used for MBSFN transmission according to an embodiment of the disclosure.

Referring to <FIG>, a multicast channel (MCH) <NUM> is used between the MAC layer and the physical layer, and the MCH is mapped with a physical MCH (PMCH) <NUM> of the physical layer. The purpose of unicast mainly uses a physical downlink shared channel (PDSCH) <NUM>.

<FIG> is a view illustrating a structure of a downlink frame used in a wireless communication system according to an embodiment of the disclosure.

<FIG> illustrates a wireless communication system based on LTE, but the wireless communication system is not limited thereto. For example, the wireless communication system may also be applied to a <NUM> communication system, and in that case, a radio frame in the drawing may be matched to a frame and a subframe may be matched to a slot.

Referring to <FIG>, a radio frame <NUM> is composed of <NUM> subframes <NUM>, and each subframe has a 'normal subframe <NUM>' used for general data transmission/reception and an MBSFN subframe <NUM>' used for broadcasts. There is a difference between the normal subframe and MBSFN subframe in the number of orthogonal frequency division multiplexing (OFDM) symbols, the length of the cyclic prefix, and the structure and number of cell-specific reference signals (CRS). In the Rel-<NUM> and Rel-<NUM> systems, the MBSFN subframe was used only for the purpose of transmitting broadcast or multicast data.

However, with the evolution of the system, from LTE Rel-<NUM>, MBSFN subframes can be used not only for broadcast or multicast purposes, but also for unicast purposes. In LTE, in order to efficiently use the PDSCH, multi-antenna technology and transmission mode (TM) related to reference signal (RS) are classified and configured.

In LTE Rel-<NUM>, TM1 to TM9 exist. Each terminal has one TM for PDSCH transmission, and TM <NUM> is newly defined in Rel-<NUM> and TM <NUM> is newly defined in Rel-<NUM>. TM <NUM> supports single user-multi-input multi-output (SU-MIMO) having a maximum of <NUM> ranks. TM <NUM> supports transmission of multiple layers, and enables transmission of up to <NUM> layers by using a Rel-<NUM> demodulation reference signal (hereinafter referred to as "DMRS") during demodulation. Further, in the Rel-<NUM> DMRS, a pre-coded DMRS is transmitted, but there is no need to inform the receiving end of the corresponding precoder index. In addition, to support TM <NUM>, the downlink control information (hereinafter referred to as "DCI") format 2C has been newly defined in Rel-<NUM>. It is necessary to note that the terminals prior to Rel-<NUM> do not attempt decoding in the MBSFN subframe. Therefore, allowing all terminals to attempt decoding in the MBSFN subframe leads to an upgrade request from the terminal of the previous release. In the disclosure, instead of allowing all terminals to receive unicast data in an MBSFN subframe, the function is applied only to terminals requiring the above function, for example, high-speed data communication. Among the aforementioned TMs, TM <NUM> in particular is a transmission mode that maximizes transmission efficiency by using multiple antennas.

For example, the base station may configure TM <NUM> to a terminal that needs to increase data throughput by receiving unicast data even in the MBSFN subframe, and only the terminal configured with TM <NUM> can receive unicast data in the MBSFN subframe.

For unicast data transmission and reception, in the LTE system, the physical downlink control channel (PDCCH) informs of where data transmission and reception actually occur, and the PDSCH transmits actual data. Before receiving actual data, the terminal should determine whether there is resource allocation information allocated to the terminal in the PDCCH. The MBSFN obtains resource allocation information through a somewhat more complex process. The base station informs the terminal of the transmission location of the multicast control channel (MCCH) for each MBSFN Area provided by the cell through broadcast information SIB <NUM>. The MCCH includes resource allocation information for the MBSFN, and the terminal may decode the MCCH to determine the transmission position of the MBSFN subframe. The reason why the MBMS provides resource allocation information through a method different from the unicast is that the MBMS should be able to be provided to a terminal in a standby mode as well according to the related art. Accordingly, the transmission position of the control channel MCCH is informed of by broadcast information SIBI3.

<FIG> is a view for explaining a process for receiving an MBSFN by a terminal according to an embodiment of the disclosure.

Referring to <FIG>, a terminal <NUM> receives SIB2 from a base station <NUM> in operation <NUM>. In the MBSFN-SubframeConfigList IE of SIB2, subframes that can be used for MBSFN transmission purposes are indicated. The MBSFN-SubframeConfigList IE includes the MBSFN-SubframeConfig IE, and indicates which subframe of which radio frame can be the MBSFN subframe. The table below is a configuration table of MBSFN-SubframeConfig IE.

The MBSFN-SubframeConfigList IE may further include radioframeAllocationPeriod, radioframeAllocationOffset, and subframeAllocation information.

The radioFrameAllocationPeriod and radioFrameAllocationOffset are used to indicate a radio frame having an MBSFN subframe, and a radio frame satisfying the formula SFN mod radioFrameAllocationPeriod = radioFrameAllocationOffset has an MBSFN subframe. SFN is a system frame number and indicates a radio frame number. SFN has a range of <NUM> to <NUM> and is repeated.

The subframeAllocation indicates which subframe is the MBSFN subframe in the radio frame indicated by the above equation. It can be indicated in units of one radio frame or units of four radio frames. When using one radio frame unit, it is indicated in oneFrame IE. The MBSFN subframe may exist among 1st, 2nd, 3rd, 6th, 7th, and 8th subframes among a total of <NUM> subframes within one radio frame. Therefore, oneFrame IE indicates the MBSFN subframe among the subframes listed above using <NUM> bits. When using four radio frame units, it is indicated in the fourFrames IE. In order to cover four radio frames, a total of <NUM> bits are used to indicate an MBSFN subframe among the subframes listed above for each radio frame. Accordingly, the terminal can accurately know the subframe that can be the MB SFN subframe by using the MBSFN-SubframeConfigList IE.

If the terminal <NUM> wants to receive MBSFN, the terminal <NUM> receives the SIB13 from the base station <NUM> in operation <NUM>. The MBSFN-AreaInfoList IE of SIB13 includes location information for transmitting an MCCH for each MBSFN Area provided by the cell, and the terminal receives the MCCH using the information in operation <NUM>. The location of the resource used for MBSFN transmission is indicated to MBSFNAreaConfiguration IE of the MCCH, and the terminal receives the MBSFN subframe in operation <NUM> using this information. In operation <NUM>, the terminal acquires a location of an MBSFN subframe through which a desired multicast traffic channel (MTCH) is transmitted in the MCH scheduling information MAC CE, which is one of the MAC control elements (MAC CE) of the received MAC protocol data unit (PDU). The terminal decodes the desired MTCH in operation <NUM> using the MCH scheduling information.

An MBMS described below, as the name suggests, refers to a multimedia broadcast multicast service, and MBSFN refers to a network that provides one MBMS service by synchronizing multiple cells in the MBMS. In the description of the disclosure, MBMS and MBSFN may be mixed.

The MBSFN subframe may be composed of a non-MBSFN region and an MBSFN region. This is because a non-MBSFN area is required for periodic transmission of control information (PDCCH, cell-specific reference signal) even in the MBSFN subframe.

When subcarrier spacing is Δf, the first <NUM> or <NUM> OFDM symbols may be used in the non-MBSFN region in the MBSFN subframe with Δf = <NUM>.

In the non-MBSFN area, a PDCCH, a physical hybrid automatic repeat request (ARQ) indicator channel (PHICH), a cell-specific reference signal, etc. may be transmitted, and a normal CP may be used.

In the MBSFN region, a PMCH may be transmitted, and an extended CP may be used for the PMCH. When using the extended CP, one subframe may be composed of <NUM> symbols.

For example, if one normal CP is used in an MBSFN subframe, <NUM> extended CPs may be used. As another example, if two normal CPs are used, <NUM> extended CPs may be used.

However, as in the non-MBSFN region of the MBSFN subframe and the MBSFN area, when the normal CP and the extended CP are mixed, a gap may be issued by the length of the normal CP. That is, when a normal CP and an extended CP are mixed, the length of a subframe defined in the standard may not be met. In this case, a zero padding operation is required to fill the gap.

Examples of the zero padding length required to match the length of the subframe, that is, to match the length of the subframe defined in the standard, are as follows.

An example of the zero padding length when one normal CP is used and <NUM> extended CPs are used in the MBSFN subframe is as follows.

An example of the zero padding length when two normal CPs are used and <NUM> extended CPs are used in an MBSFN subframe is as follows.

As described above, in O-RAN, standardization work for lower layer function split is in progress.

The zero padding operation by interchangeably using (mixing) the normal CP and the extended CP operates after the iFFT and CP addition block, and the operation is performed in the RU in the categories of both category A and category B of lower layer function separation.

<FIG> is a view illustrating a process of performing a zero padding operation in an RU by separating a lower layer function according to Option <NUM>-<NUM> in an O-RAN according to an embodiment of the disclosure.

Referring to <FIG>, a DU <NUM> transmits control information for MBSFN and user data for MBSFN to an RU <NUM>. In this case, the control information for the MBSFN may include scheduling information for receiving user data for the MBSFN.

In this case, the control information transmitted from the DU <NUM> to the RU <NUM> should be concise in the control information itself and the configuration, and the use of resources for processing control information should be small.

In the disclosure, a method of concisely configuring control information is proposed.

<FIG> is a view illustrating a process in which a DU transfers control information and data to an RU using a C-plane message defined in an O-RAN according to an embodiment of the disclosure.

Referring to <FIG>, control information transmitted from a DU <NUM> to an RU <NUM> is referred to as a C-plane message, which can be classified into a section type described in <FIG>. In the disclosure, the C-plane message may be interchangeably referred to as a C-plane type, control message, control information, control command, and the like.

In the C-plane message, a type used may be classified according to a CP type of a symbol. For example, the DU <NUM> may transmit a C-plane message according to section type <NUM> to the RU <NUM> in the case of normal CP Symbols, and transmit a C-plane message according to Section type <NUM> to the RU <NUM> in the case of extended CP Symbols.

That is, in the case of MFSFN subframe, the DU <NUM> may transmit C-plane messages of one or more section types to the RU <NUM>.

Each C-plane message includes scheduling information independently. Accordingly, it is not possible to determine the association with information about other C-plane messages using one C-plane message.

Accordingly, the RU <NUM> may determine that a symbol <NUM> using the normal CP and a symbol <NUM> using the extended CP are simultaneously scheduled after identifying the symbol configuration information for one subframe, based on two C-plane messages according to section type <NUM> (may consist of more than one) and a C-plane message according to section type <NUM> (more than <NUM> may be configured).

Specifically, the RU <NUM> may analyze symbol configuration information from the received C-plane message according to section type <NUM> and the C-plane message according to section type <NUM>. In addition, the RU <NUM> may recognize that the corresponding subframe is an MBSFN subframe and that zero padding is required through the symbol configuration information of the subframe.

Thereafter, since the number of samples is determined by the FFP size, the RU <NUM> can determine the zero padding size, based on information on the number of symbols acquired in control section type <NUM> and information on the FFT size.

However, according to the above method, since the RU <NUM> needs to analyze control information of different control section types, processing time may be delayed and complexity may increase. For example, in order to determine the MBSFN subframe by combining the symbol configuration information of the subframe, the RU <NUM> needs to receive and process different control section types, so additional processing time is required. This may mean that the determination is delayed because it is possible to determine whether the subframe is an MBSFN subframe after all control section types (e.g., scheduling information) of one subframe are processed. In addition, the RU <NUM> may increase the complexity due to logic for determining the MBSFN subframe.

Accordingly, the disclosure proposes a method in which the DU of the base station efficiently transmits or transfers information on the MBSFN subframe configuration to the RU of the base station. Specifically, the disclosure proposes a method for reducing the processing load and complexity of the RU for analyzing whether the RU needs zero padding and, if necessary, the zero padding size.

<FIG> is a view illustrating a method of transmitting a C-plane message from a DU to an RU according to an embodiment of the disclosure.

Referring to <FIG> and <FIG>, a DU <NUM> transmits a C-plane message <NUM> according to the section type <NUM> and a C-plane message <NUM> according to the section type <NUM> according to the related art. Then, based on the two C-plane messages, an RU <NUM> identifies symbol configuration information for one subframe, and then may determine that the symbol <NUM> using the normal CP and the symbol <NUM> using the extended CP are simultaneously scheduled. Thereafter, the RU <NUM> determines a zero padding size, based on information on the number of symbols acquired in the control section type <NUM> and information on the FFT size.

MB SFN-related information (or flag) <NUM> is newly defined in a C-plane message <NUM> according to the section type <NUM>. The MBSFN-related information <NUM> may include information that zero padding is required because a corresponding subframe is an MBSFN subframe, and information on the number of symbols in which the normal CP is used.

For example, the MBSFN-related information may include information indicating whether CP types are mixed according to the MBSFN subframe configuration, and information on the number of symbols using the normal CP.

Alternatively, the MBSFN-related information may include a flag indicating whether to mix CP types according to the MBSFN subframe configuration, and a flag for the number of symbols using the normal CP.

Alternatively, the MBSFN-related information may include a flag indicating whether to mix CP types according to the MBSFN subframe configuration, a flag for the number of symbols using the normal CP, and the number of zero padding samples (or, zero padding size).

The state in which different CP types are mixed can be known in the upper layer, and information indicating this can also be generated in the upper layer. For example, the MBSFN subframe configuration may be information already determined in an upper layer, and information to be transmitted to the terminal may be already generated. Since the C-Plane message is generated according to the configuration of the MBSFN subframe, additional information may also be inserted when the C-Plane message is generated.

Accordingly, the DU <NUM> may generate the MBSFN information related information <NUM> and transmit the same to the RU <NUM> through a C-plane message. Then, even if the RU <NUM> does not refer to all C-plane messages for a specific subframe, it is possible to determine whether zero padding is required and determine the zero padding size by using MBSFN-related information included in the C-plane message by specific generation.

Alternatively, even if the RU <NUM> does not refer to all C-plane messages for a specific subframe, the RU <NUM> may identify whether zero padding is needed and the zero padding size using only the MBSFN-related information included in the C-plane message by specific generation.

In an embodiment for configuring the MBSFN-related information in an O-RAN C-plane message, the disclosure proposes a method for configuring in section extension fields, a method for configuring in common header fields, and a method for configuring in section fields.

<FIG> is a view illustrating a method of configuring MBSFN related information in a section extension field in a C-plane message according to an embodiment of the disclosure.

As described above, <FIG> illustrates a C-plane message according to type <NUM>, and <FIG> illustrates a C-plane message according to section type <NUM>. Each C-plane message includes a section extension field.

The DU according to an embodiment of the disclosure may insert MBSFN related information into a C-plane message using the section extension field and transmit the same to the RU.

Referring to <FIG> a method of inserting mixedCpFlag information <NUM> and mixedCpIdx information <NUM> into section extension fields as a method of inserting MBSFN-related information into a section extension field.

The mixedCpFlag information <NUM> may indicate whether a normal CP and an extended CP are mixed in a subframe. This may be indicated as <NUM> or <NUM>, and when configured as <NUM>, it indicates that the normal CP and the extended CP are not mixed, and when configured as <NUM>, it may indicate that the normal CP and the extended CP are mixed. However, it should be noted that the meaning of configuring <NUM> and <NUM> is only an example, and it is not necessarily limited to this. In addition, mixedCpFlag = <NUM> (non-mixed) may not be used.

The mixedCpIdx information <NUM> may indicate the number of normal CPs within a subframe. This may be indicated as <NUM> or <NUM>, and when configured as <NUM>, it may indicate that the number of normal CPs is <NUM>, and when configured as <NUM>, it may indicate that the number of normal CPs is <NUM>. Likewise, it should be noted that the meaning of the configuration of <NUM> and <NUM> is only an example, and it is not necessarily limited thereto.

Referring to <FIG> a method of inserting mixedCpFlag information <NUM>, mixedCpIdx information <NUM>, and numzeros information <NUM> into section extension fields as a method of inserting MBSFN-related information into a section extension field.

The mixedCpFlag information <NUM> may indicate whether a normal CP and an extended CP are mixed in a subframe. This may be indicated as <NUM> or <NUM>, and when configured as <NUM>, it indicates that normal CP and extended CP are not mixed, and when configured as <NUM>, it may indicate that normal CP and extended CP are mixed. However, it should be noted that the meaning of configuring <NUM> and <NUM> is only an example, and it is not necessarily limited thereto. Also, mixedCpFlag = <NUM> (non-mixed) may not be used.

The mixedCpIdx information <NUM> may indicate the number of Normal CPs in a subframe. This may be indicated as <NUM> or <NUM>, and when configured as <NUM>, it may indicate that the number of normal CPs is <NUM>, and when configured as <NUM>, it may indicate that the number of normal CPs is <NUM>. Likewise, it should be noted that the meaning of the configuring of <NUM> and <NUM> is only an example, and it is not necessarily limited thereto.

The numzeros information <NUM> may indicate the number of zero padding samples (or zero padding size) in a subframe. This may be indicated based on the <NUM> bits field length, which may indicate the number of maximum <NUM> zero padding samples. However, it should be noted that the meaning of the <NUM>-bit field length setting is only an example, and it is not necessarily limited to this.

The embodiment illustrated in <FIG> can be applied to both a C-plane message according to section type <NUM> and a C-plane message according to section type <NUM>.

<FIG> is a view illustrating a method of configuring MBSFN-related information in common header fields according to an embodiment of the disclosure.

Referring to <FIG>, the C-plane message according to section type <NUM> may include a common header field <NUM>. The common header field <NUM> includes reserved <NUM> bits, of which mixedCpFlag information <NUM> and mixedCpIdx information <NUM> may be configured in <NUM> bits.

The mixedCpFlag information <NUM> may indicate whether a normal CP and an extended CP are mixed in a subframe. This may be indicated as <NUM> or <NUM>, and when configured as <NUM>, it may indicate that the normal CP and the extended CP are not mixed, and when configured as <NUM>, it may indicate that the normal CP and the extended CP are mixed, or vice versa.

The mixedCpIdx information <NUM> may indicate the number of Normal CPs within a subframe. This may be indicated as <NUM> or <NUM>, and when configured as <NUM>, it may indicate that the number of normal CPs is <NUM>, and when configured as <NUM>, it may indicate that the number of normal CPs is <NUM>, or vice versa.

<FIG> is a view illustrating a method of configuring MBSFN-related information in a section field according to an embodiment of the disclosure.

Referring to <FIG>, the C-plane message according to section type <NUM> may include a section field <NUM>. The section field <NUM> includes reserved <NUM> bits, of which mixedCpFlag information <NUM> and mixedCpIdx information <NUM> may be configured in <NUM> bits.

The mixedCpIdx information <NUM> may indicate the number of normal CPs within a subframe. This may be indicated as <NUM> or <NUM>, and when configured as <NUM>, it may indicate that the number of normal CPs is <NUM>, and when configured as <NUM>, it may indicate that the number of normal CPs is <NUM>, or vice versa.

<FIG> and <FIG> are views illustrating a method of configuring a C-plane message by a DU using a section extension field in a mixed CP type of LTE MBSFN according to an embodiment of the disclosure.

In <FIG> and <FIG>, a situation in which two normal CP symbols are configured is exemplified and described.

As described above, the C-plane message may include a C-plane message <NUM> according to the section type <NUM> and a C-plane message <NUM> according to the section type <NUM>.

A C-Plane message according to section type <NUM> may include information on a normal CP symbol, and a C-plane message according to section type <NUM> may include information on an extended CP symbol. Each C-Plane message may include scheduling information for one or more symbols. In the examples shown in <FIG> and <FIG>, one C-plane message is configured for each section type, but the C-Plane message may be divided.

<FIG> illustrates a method of inserting MBSFN-related information into each section extension field of the C-plane message <NUM> according to section type <NUM> and the C-plane message <NUM> according to section type <NUM>. The MBSFN-related information may include mixedCpFlag information <NUM> and mixedCpIdx information <NUM>, and the configuration and meaning of each information are as described above.

<FIG> illustrates a method of inserting MBSFN-related information into the section extension fields of each of the C-plane message <NUM> according to section type <NUM> and the C-plane message <NUM> according to section type <NUM>. The MBSFN-related information may include mixedCpFlag information <NUM>, mixedCpIdx information <NUM>, and numzeros information <NUM>, and the configuration and meaning of each piece of information are as described above.

According to an embodiment of the disclosure, a section extension field may be added at three positions of section type <NUM>, section type <NUM>, section type <NUM> and section type.

<FIG> is a view illustrating a method of configuring a C-Plane message by a DU using a common header field in a mixed CP type of LTE MBSFN according to an embodiment of the disclosure.

Referring to <FIG>, <FIG> and <FIG>, a method of configuring the C-plane message <NUM> according to section type <NUM> when there are two normal CP symbols. As illustrated in <FIG>, the common header field included in the C-plane message according to section type <NUM> includes reserved <NUM> bits, and the DU may configure mixedCpFlag information <NUM> and mixedCpIdx information <NUM> by using <NUM> bits thereof. The configuration of each information and its meaning are as described above.

<FIG> is a view illustrating a method of configuring a C-Plane message by using a section field in a DU in a mixed CP type situation of LTE MBSFN according to an embodiment of the disclosure.

Referring to <FIG>, a method is illustrated for configuring a C-plane message according to section type <NUM> when there are two normal CP symbols. As illustrated in <FIG>, the section field included in the C-plane message according to section type <NUM> includes reserved <NUM> bits, and the DU may configure mixedCpFlag information <NUM> and mixedCpIdx information <NUM> using <NUM> bits thereof. The configuration of each information and its meaning are as described above.

<FIG> is a view illustrating examples in which an RU determines a zero padding size according to an embodiment of the disclosure.

<FIG> is another view illustrating an example in which an RU determines a zero padding size according to an embodiment of the disclosure.

Referring to <FIG> and <FIG>, the RU may analyze subframe configuration information, based on the C-plane message received from the DU. In an embodiment of the disclosure, it is possible to determine whether to perform zero padding, based on mixedCpFlag information and mixedCpIdx information included in the C-plane message.

For example, when mixedCpFlag information is configured as <NUM>, since a normal CP and an extended CP are not mixed within a subframe, the RU may not perform the zero padding operation.

As another example, when mixedCpFlag information is configured as <NUM> and mixedCpIdx information is configured as <NUM>, the RU may determine a zero padding size, based on the mixedCpFlag information, mixedCpIdx information, and FFT size as illustrated in <FIG>. As can be seen in <FIG>, since the number of samples of the OFDM symbol varies according to the FFT size, the zero padding size may be determined differently according to the FFT size.

For example, if the FFT size is <NUM>, the length of symbol #<NUM> using a normal CP is <NUM> samples, and the length of symbols using the remaining extended CP is <NUM> samples, so the zero padding size may be determined as <NUM> by the difference between the number of samples for a symbol using the extended CP and the number of samples for a symbol using the normal CP. When the FFT size is <NUM>, the zero padding size may be determined as <NUM>, and when the FFT size is <NUM>, the zero padding size may be determined as <NUM>. Zero padding is performed on a section between a symbol using a normal CP and a symbol using an extended CP, based on the determined size. Performing zero padding may mean that, for example, if the number of zero padding samples (or zero padding size) is <NUM>, <NUM> is added by the length of <NUM> samples.

As another example, when mixedCpFlag information is configured as <NUM> and mixedCpIdx information is configured as <NUM>, the RU may determine a zero padding size, based on the mixedCpFlag information, mixedCpIdx information, and FFT size as shown in <FIG>. As can be seen in <FIG>, since the number of samples varies according to the FFT size, the zero padding size may be determined differently according to the FFT size.

For example, when the FFT size is <NUM>, the zero padding size may be determined as <NUM>, when the FFT size is <NUM>, the zero padding size may be determined as <NUM>, and when the FFT size is <NUM>, the zero padding size may be determined as <NUM>.

In addition, the RU may analyze subframe configuration information, based on the C-plane message received from the DU. In an embodiment, whether to perform zero padding may be determined based on the mixedCpFlag information, mixedCpIdx information, and numzeros information included in the C-plane message.

For example, when the mixedCpFlag information is configured as <NUM>, since normal CP and extended CP are not mixed in a subframe, the RU may not perform the zero padding operation.

As another example, when the mixedCpFlag information is configured as <NUM>, the mixedCpIdx information is configured as <NUM>, and the numzeros information is configured as <NUM> (= <NUM>), the padding size may be determined to be <NUM> regardless of the FFT size in <FIG>.

Zero padding is performed on a section between a symbol using a normal CP and a symbol using an extended CP, based on the determined size. Performing zero padding may mean that, for example, if the number of zero padding samples (or the zero padding size) is <NUM>, adding <NUM> as much as <NUM> samples length.

As another example, when the mixedCpFlag information is configured as <NUM> and the mixedCpIdx information is configured as <NUM>, the RU may identify the zero padding size, based on the mixedCpFlag information, mixedCpIdx information, and numzeros information as shown in <FIG>.

For example, when the numzeros information is <NUM>, the zero padding size may be identified as <NUM>, when the numzeros information is <NUM>, the zero padding size may be identified as <NUM>, and when the numzeros information is <NUM>, the zero padding size may be identified as <NUM>.

<FIG> is a flow chart illustrating an operation sequence of a DU device of a base station according to an embodiment of the disclosure.

Referring to <FIG>, the DU device of a base station may identify configuration information for a specific subframe in operation S2310. The DU device of the base station may identify information on whether a normal CP and an extended CP are mixed in the subframe, and if they are mixed, the DU device may identify information on the number of normal CPs in operation S2320, according to the identification result.

The DU device of the base station may generate a C-plane message (or control message) according to an embodiment of the disclosure in operation S2330. In this case, the C-plane message may include MBSFN-related information. In this case, the MBSFN-related information may include mixedCpFlag information indicating whether the normal CP and the extended CP are mixed in the subframe and mixedCpIdx information indicating the number of normal CPs in the subframe.

Alternatively, the MBSFN-related information may include a flag indicating whether CP types are mixed according to the MBSFN subframe configuration, a flag for the number of symbols using normal CP, and the number of zero padding samples (or zero padding size).

The MBSFN-related information may be configured using a section extension field in a C-plane message, configured using a common header field, or configured using a section field according to an embodiment.

In addition, the DU device of the base station may transmit the generated C-plane message to the RU in operation S2340.

<FIG> is a flowchart illustrating an operation sequence of an RU device of a base station according to an embodiment of the disclosure.

Referring to <FIG>, the RU device of the base station may receive a C-plane message (or control message) from the DU device of the base station in operation S2410.

In addition, the RU device of the base station may check MBSFN-related information based on the C-plane message in operation S2420. In this case, the MBSFN-related information may include mixedCpFlag information indicating whether a normal CP and an extended CP are mixed in the subframe and mixedCpIdx information indicating the number of normal CPs in the subframe.

Alternatively, the MBSFN-related information includes a flag indicating whether CP types are mixed according to the MBSFN subframe configuration, a flag for the number of symbols using normal CP, and the number of zero padding samples (or zero padding size).

In addition, the RU device of the base station may determine whether zero padding is required in operation S2430, based on the result of the check. For example, if the normal CP and the extended CP are not mixed, it may be determined that zero padding is not required.

On the other hand, if the normal CP and the extended CP are mixed, the RU device of the base station may determine the zero padding size in operation S2440, based on the FFT size information and mixedCpIdx information indicating the number of normal CPs in the subframe. A specific example of determining the zero padding size is as illustrated in <FIG> and <FIG>.

In operation S2450, the RU device of the base station inserts zero padding by the determined zero padding size.

<FIG> is a block diagram illustrating an internal structure of an RU device of a base station and a DU device of the base station capable of performing according to an embodiment of the disclosure.

Referring to <FIG>, an RU device <NUM> of the base station includes a transceiver <NUM>, at least one processor and/or controller <NUM>, a connector <NUM>, and a storage unit <NUM>. However, the components of the RU device <NUM> of the base station are not limited to the above-described example, and for example, the RU device <NUM> of the base station may include more or fewer components than the illustrated components. In addition, the transceiver <NUM>, the storage unit <NUM>, and the controller <NUM> may be implemented in the form of a single chip.

The transceiver <NUM> may transmit and receive signals to and from a terminal. Here, the signal may include control information and data. To this end, the transceiver <NUM> may include an RF transmitter that upconverts and amplifies a frequency of a transmitted signal, and an RF receiver that amplifies a received signal with low noise and downconverts a frequency. However, this is only an embodiment of the transceiver <NUM>, and components of the transceiver <NUM> are not limited to the RF transmitter and the RF receiver. In addition, the transceiver <NUM> may receive a signal through a wireless channel, output the same to the controller <NUM>, and transmit the signal output from the controller <NUM> through a wireless channel. In addition, the transceiver <NUM> may separately include an RF transceiver for an LTE system and an RF transceiver for an NR system, or may perform physical layer processing of LTE and NR with one transceiver.

The storage unit <NUM> may store programs and data necessary for the operation of the RU device of the base station. In addition, the storage unit <NUM> may store control information or data included in signals transmitted and received by the RU device of the base station. The storage unit <NUM> may be composed of a storage medium such as read only memory (ROM), random access memory (RAM), hard disk, compact disc ROM (CD-ROM), and digital versatile disc (DVD), or a combination of storage media. Also, there may be a plurality of storage units <NUM>.

The controller <NUM> may control a series of processes so that the RU device <NUM> of the base station can operate according to the above-described embodiment. For example, the controller <NUM> may transmit/receive an LTE or NR signal to and from the terminal according to a C-plane message and a U-plane message received from a DU device <NUM> of the base station through the connector <NUM>. There may be a plurality of controllers <NUM>, and the controller <NUM> may perform a component control operation of the RU device <NUM> of the base station by executing a program stored in the storage unit <NUM>.

The controller <NUM> according to an embodiment may control to receive a control message including multimedia broadcast multicast service single frequency network (MBSFN)-related information for a subframe from a digital unit of a base station through a connection unit <NUM> to be described later, and control to perform zero padding in the subframe, based on the MBSFN-related information. In addition, the controller <NUM> may determine a zero padding size, based on a Fast Fourier Transform (FFT) size, and control to perform the zero padding based on the determined zero padding size.

The connector <NUM> is a device that connects the RU device <NUM> of the base station and the DU device <NUM> of the base station, and may perform physical layer processing for message transmission and reception, transmit a message to the DU device <NUM> of the base station, and receive a message from the DU device <NUM> of the base station.

The DU device <NUM> of the base station includes at least one processor and/or controller <NUM>, a connector <NUM>, and a storage unit <NUM>. However, the components of the DU device <NUM> of the base station are not limited to the above-described example, and for example, the DU device <NUM> of the base station may include more components or fewer components than the illustrated components. In addition, the connector <NUM>, the storage unit <NUM>, the controller <NUM>, and the like may be implemented in the form of a single chip.

The controller <NUM> may control a series of processes so that the DU device <NUM> of the base station can operate according to the above-described embodiment. For example, the controller <NUM> may generate a C-plane message and a U-plane message to be transmitted to the RU device <NUM> of the base station, and transmit the message to the RU device <NUM> of the base station through the connector <NUM>. There may be a plurality of controllers <NUM>, and the controller <NUM> may perform a component control operation of the DU device <NUM> of the base station by executing a program stored in the storage unit <NUM>.

According to an embodiment, the controller <NUM> may identify the subframe configuration information, and generate a control message including multimedia broadcast multicast service single frequency network (MBSFN)-related information for the subframe, based on the identification. In addition, the controller <NUM> may control to transmit the generated control message to a radio unit (RU) of the base station connected to the digital unit through a connector <NUM> to be described later.

The storage unit <NUM> may store programs and data necessary for the operation of the RU device of the base station. In addition, the storage unit <NUM> may store control information or data included in signals transmitted and received by the RU device of the base station. The storage unit <NUM> may be composed of a storage medium such as ROM, RAM, hard disk, CD-ROM, and DVD, or a combination of storage media. In addition, there may be a plurality of storage units <NUM>.

The connector <NUM> is a device that connects the RU device <NUM> of the base station and the DU device <NUM> of the base station, and may perform physical layer processing for message transmission/reception, transmit a message to the RU device <NUM> of the base station, and receive a message from the RU device <NUM> of the base station.

Claim 1:
A method performed by a distributed unit, DU, of a base station in a wireless communication system supporting lower layer function division, the method comprising:
identifying subframe configuration information;
generating a control message including multimedia broadcast multicast service single frequency network, MBSFN,-related information for a subframe, based on the identification; and
transmitting the generated control message to a radio unit, RU, of the base station connected to the DU through a fronthaul interface,
wherein the MBSFN-related information includes first information for indicating whether a normal cyclic prefix, CP, and an extended CP are mixed in the subframe or not and second information for indicating a number of one or more symbols using the normal CP in the subframe, and
wherein the MBSFN-related information is used for zero padding, to match a length of the subframe defined in a standard, in the RU.