Patent Description:
The <NUM>rd Generation Partnership Project (3GPP) supports gNB deployment in a disaggregated architecture which allows the gNB to be decomposed into a gNB-CU (Centralized Unit) and a gNB-DU (Distributed Unit), as will be shown in <FIG> and <FIG> below. The disaggregated architecture impacts the mechanisms for providing and broadcasting System Information (SI), since some portions of SI are handled in the gNB-CU, while others are handled in the gNB-DU. In current specifications, the gNB-DU owns and encodes MIB and SIB1, while the gNB-CU owns and encodes all the other remaining System Information Broadcasts (SIBs). The present disclosure applies to the following:
Any scenario in which the gNB-DU is able to provide System Information that is originally intended to be triggered from the gNB-CU, such as SIB9, yet the gNB-DU is able to generate it autonomously and broadcast it without further assistance from the gNB-CU. This functionality can greatly reduce signaling over the interface as the gNB-CU is no longer required to provide continuous updates over the interface between the gNB-CU and the gNB-DU, which in some scenarios can be as frequent as every <NUM>, such as, in case of reference-time delivery in SIB9.

Any scenario in which the gNB-CU may benefit from receiving the gNB-DU-derived information and use it to deliver it to the user equipment (UE) via dedicated unicast signaling, such as, an encoded SIB, or another piece of information, such as time reference. The benefit of doing this is two-fold. Firstly, there is information that is more reliable/accurate if generated/retrieved at the gNB-DU, such as time-reference information. Thus, it is preferable to use the information the gNB-DU has generated rather than to have the gNB-CU generate it by itself. If the gNB-DU provides the SI in encoded form, that is, as an SIB, the gNB-CU can copy and paste it directly without further de-coding/re-encoding. Secondly, the information received, for example, time-reference information, may also be applicable to multiple UEs. Thus, a single information retrieval can suffice to apply it to multiple UEs. In this case, unencoded information is preferred. Depending on the scenario, the gNB-CU may also provide it directly to UEs, or encode it in the form of an SIB.

The present disclosure is applicable to disaggregated architecture both in <NUM> and LTE, that is, to the F1 and W1 interfaces defined by 3GPP. Although, in the present disclosure, the F1 scenario is used as the basis for discussion, the same solution is also applicable for W1.

There is a need for a solution that allows:.

The issue of having SIB9 owned and encoded at the gNB-CU rather than at the gNB-DU has been under discussion. Implementing SIB9 delivery based on encoding on the gNB-CU is complex, given that the gNB-CU does not have accurate time information unless there is a very tight synchronization with the gNB-DU. Although it was proposed to change the existing System Information framework so that the gNB-DU would own and encode SIB9, this proposal has not been accepted because of concerns with backward compatibility and implementations with earlier versions of the specifications which would still have the gNB-CU encode SIB9. Instead, there was a compromise to have the gNB-CU still own and encode SIB9, yet allow the gNB-DU to re-encode it prior to broadcasting it.

As will be pointed out in the present disclosure, the capability of the gNB-DU to re-encode SIB9 still has multiple shortcomings and is not efficient in that excessive signaling is not resolved, and the gNB-CU still provides inaccurate information in dedicated signaling (unicast) cases. Further, it is not applicable on a general level to all other system information cases and instead only partially tackles the issue of SIB9. This is a major shortcoming, given that as part of new work items, there are new SIBs being considered which would also not work optimally under the current framework which has MIB/SIB1 owned and encoded at gNB-DU and all other SIBs owned and encoded at the gNB-CU. Such examples are, for instance, new SIBs being considered for Non-Public Networks (NPN), as well as unicast delivery of very accurate information, possibly via a new SIB, required for Industrial IoT (IIoT) in 3GPP Release <NUM> work items.

<CIT> relates to a method whereby a DU of a base station: receives system information from a CU of the base station; receives a request for system information from a UE; forwards the request to the CU; receives a command from the CU to provide the system information; and broadcasts the system information based on the command.

It should be understood, in the discussion to follow, that the term "gNB" should be understood to mean "network node". The term "gNB" is used to denote a network node in <NUM>. However, it should be understood that the present invention, as described below, is not limited to <NUM>, but may be applicable to other generations yet to be developed or to earlier generations being further developed. As a consequence, "gNB" should be understood more broadly as a network node.

The invention is defined in the claims. It will be understood that aspects of the disclosure falling within the scope of the claims are part of the invention.

The foregoing and other aspects of these teachings are made more evident in the following detailed description, when read in conjunction with the attached drawing figures.

<FIG> is a block diagram of one possible and non-limiting example in which the subject matter of the present disclosure may be practiced. A user equipment (UE) <NUM>, radio access network (RAN) node <NUM>, and network element(s) <NUM> are illustrated. In the example of <FIG>, the user equipment (UE) <NUM> is in wireless communication with a wireless network <NUM>. A UE is a wireless device, typically mobile, that can access the wireless network. The UE <NUM> includes one or more processors <NUM>, one or more memories <NUM>, and one or more transceivers <NUM> interconnected through one or more buses <NUM>. The one or more buses <NUM> may be address, data, or control buses, and may include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, fiber optics or other optical communication equipment, and the like. The UE <NUM> includes a module <NUM>, comprising one of or both parts <NUM>-<NUM> and/or <NUM>-<NUM>, which may be implemented in a number of ways. The module <NUM> may be implemented in hardware as module <NUM>-<NUM>, such as being implemented as part of the one or more processors <NUM>. The module <NUM>-<NUM> may be implemented also as an integrated circuit or through other hardware such as a programmable gate array. In another example, the module <NUM> may be implemented as module <NUM>-<NUM>, which is implemented as computer program code <NUM> and is executed by the one or more processors <NUM>. For instance, the one or more memories <NUM> and the computer program code <NUM> may be configured, with the one or more processors <NUM>, to cause the user equipment <NUM> to perform one or more of the operations as described herein. The UE <NUM> communicates with RAN node <NUM> via a wireless link <NUM>.

The RAN node <NUM> in this example is a base station that provides access by wireless devices, such as the UE <NUM>, to the wireless network <NUM>. The RAN node <NUM> may be, for example, a base station for <NUM>, also called New Radio (NR). In <NUM>, the RAN node <NUM> may be an NG-RAN node, which is defined as either a gNB or an ng-eNB. A gNB is a node providing NR user plane and control-plane protocol terminations toward the UE, and connected via the NG interface to a 5GC, such as, for example, the network element(s) <NUM>. The ng-eNB is a node providing E-UTRA user plane and control plane protocol terminations towards the UE, and connected via the NG interface to the 5GC. The NG-RAN node may include multiple gNBs, which may also include a centralized unit (CU) (gNB-CU) <NUM> and distributed unit(s) (DUs) (gNB-DUs), of which DU <NUM> is shown. Note that the DU may include or be coupled to and control a radio unit (RU). The gNB-CU is a logical node hosting RRC, SDAP and PDCP protocols of the gNB or RRC and PDCP protocols of the en-gNB that controls the operation of one or more gNB-DUs. The gNB-CU terminates the F1 interface connected with the gNB-DU. The F1 interface is illustrated as reference <NUM>, although reference <NUM> also illustrates a link between remote elements of the RAN node <NUM> and centralized elements of the RAN node <NUM>, such as between the gNB-CU <NUM> and the gNB-DU <NUM>. The gNB-DU is a logical node hosting RLC, MAC and PHY layers of the gNB or ng-eNB, and its operation is partly controlled by gNB-CU. One gNB-CU supports one or multiple cells. One cell is supported by only one gNB-DU. The gNB-DU terminates the F1 interface <NUM> connected with the gNB-CU. Note that the DU <NUM> is considered to include the transceiver <NUM>, for example, as part of a RU, but some examples of this may have the transceiver <NUM> as part of a separate RU, for example, under control of and connected to the DU <NUM>. The RAN node <NUM> may also be an eNB (evolved NodeB) base station, for LTE (long term evolution), or any other suitable base station or node.

The RAN node <NUM> includes a module <NUM>, comprising one of or both parts <NUM>-<NUM> and/or <NUM>-<NUM>, which may be implemented in a number of ways. The module <NUM> may be implemented in hardware as module <NUM>-<NUM>, such as being implemented as part of the one or more processors <NUM>. The module <NUM>-<NUM> may be implemented also as an integrated circuit or through other hardware such as a programmable gate array. In another example, module <NUM> may be implemented as module <NUM>-<NUM>, which is implemented as computer program code <NUM> executed by the one or more processors <NUM>. For instance, the one or more memories <NUM> and the computer program code <NUM> are configured, with the one or more processors <NUM>, to cause the RAN node <NUM> to perform one or more of the operations as described herein. Note that the functionality of the module <NUM> may be distributed, such as being distributed between the DU <NUM> and the CU <NUM>, or be implemented solely in the DU <NUM>.

The one or more buses <NUM> may be address, data, or control buses, and may include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, fiber optics or other optical communication equipment, wireless channels, and the like. For example, the one or more transceivers <NUM> may be implemented as a remote radio head (RRH) <NUM> for LTE or a distributed unit (DU) <NUM> for gNB implementation for <NUM>, with the other elements of the RAN node <NUM> possibly being physically in a different location from the RRH/DU, and the one or more buses <NUM> could be implemented in part as, for example, fiber optic cable or other suitable network connection to connect the other elements (e.g., a centralized unit (CU), gNB-CU) of the RAN node <NUM> to the RRH/DU <NUM>. Reference <NUM> also indicates those suitable network link(s).

It is noted that description herein indicates that "cells" perform functions, but it should be clear that equipment which forms the cell will perform the functions. The cell makes up part of a base station. That is, there can be multiple cells per base station. For example, there could be three cells for a single carrier frequency and associated bandwidth, each cell covering one-third of a <NUM>° area so that the single base station's coverage area covers an approximate oval or circle. Furthermore, each cell can correspond to a single carrier and a base station may use multiple carriers. So if there are three <NUM>° cells per carrier and two carriers, then the base station has a total of <NUM> cells.

The wireless network <NUM> may include a network element or elements <NUM> that may include core network functionality, and which provides connectivity via a link or links <NUM> with a further network, such as a telephone network and/or a data communications network (e.g., the Internet). Such core network functionality for <NUM> may include access and mobility management function(s) (AMF(S)) and/or user plane functions (UPF(s)) and/or session management function(s) (SMF(s)). Such core network functionality for LTE may include MME (Mobility Management Entity)/SGW (Serving Gateway) functionality. These are merely exemplary functions that may be supported by the network element(s) <NUM>, and note that both <NUM> and LTE functions might be supported. The RAN node <NUM> is coupled via a link <NUM> to a network element <NUM>. The link <NUM> may be implemented as, for example, an NG interface for <NUM>, or an S1 interface for LTE, or other suitable interface for other standards. The network element <NUM> includes one or more processors <NUM>, one or more memories <NUM>, and one or more network interfaces (N/W I/F(s)) <NUM>, interconnected through one or more buses <NUM>. The one or more memories <NUM> and the computer program code <NUM> are configured, with the one or more processors <NUM>, to cause the network element <NUM> to perform one or more operations.

The computer-readable memories <NUM>, <NUM>, and <NUM> may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor-based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. The computer-readable memories <NUM>, <NUM>, and <NUM> may be means for performing storage functions. The processors <NUM>, <NUM>, and <NUM> may be of any type suitable to the local technical environment, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on a multi-core processor architecture, as non-limiting examples. The processors <NUM>, <NUM>, and <NUM> may be means for performing functions, such as controlling the UE <NUM>, RAN node <NUM>, and other functions as described herein.

<FIG> and <FIG> show an example of New Radio (NR) architecture having the <NUM> core (5GC) and the NG-RAN. The base stations gNB are coupled to the 5GC by the interface to Core NGs, and the gNBs are coupled to each other by the inter-base stations interface Xn.

Having thus introduced one suitable but non-limiting technical context for the practice of the example embodiments, the example embodiments will now be described with greater specificity. 3GPP TS <NUM> defines that System Information be distributed as follows:.

The SIBs can be delivered to UEs in the following ways:.

Broadcast delivery is the default mechanism. The F1 Interface, defined in 3GPP TS <NUM> and 3GPP TS <NUM>, supports exchanging their corresponding SIBs between the gNB-DU and the gNB-CU via both the F1 setup procedure as well as via DU configuration update and CU configuration update messages, respectively. Likewise, the gNB-CU can command the gNB-DU to broadcast SIBs belonging to Other-SI via the System Information delivery command message.

The frequency of broadcast is configurable. However, there is a possibility to have "always on" broadcast, meaning that the SIBs will continuously be broadcasted. If the SIB is owned/encoded by the gNB-CU and is part of the Other-SI, this will require the gNB-CU to provide the updated SIB as every time its contents change when it is to be transmitted by the gNB-DU. This will be necessary even if the gNB-DU is capable of re-encoding a certain SIBs, such as SIB9. Likewise, for some SIBs, such as SIB9, this can be as frequent as every <NUM>.

The present disclosure tackles this issue by introducing a mechanism that has the gNB-DU indicate to the gNB-CU that it has capability of generating information related to Other-SI. With this information, the gNB-CU can opt out from continuously providing updates for the indicated SIBs, and send an acknowledge indication back to the gNB-DU. After this message exchange, the gNB-DU will autonomously generate the agreed SIBs without requiring any further communication with the gNB-CU. In addition, an option for the gNB-CU to enable/disable this function at the gNB-DU, if, for some reason, the gNB-CU is the preferable entity to generate the SIB, is proposed.

Changes required in the F1 interface are a new Information Elements (IE) to the F1 setup procedure, the DU configuration update procedure, and the CU configuration update procedure.

Additionally, 3GPP specifications allow for "on-demand" delivery of System Information. One of the methods is via Message <NUM> (Msg1). In this scenario, a UE can directly contact the gNB-DU and request certain SIBs to be broadcasted. After receiving the request and assuming that the gNB-DU already has the information available, such as because it has received it from the gNB-CU beforehand via any of the F1 methods, it is able to broadcast it accordingly without gNB-CU intervention. If the SIB requested is not available at the gNB-DU, the gNB-DU will have to request it from the gNB-CU prior to broadcasting it.

The present disclosure tackles this issue. The method is the same as with the previous scenario, since the method to indicate and allow the gNB-DU to autonomously generate and broadcast a certain SIB is also applicable. If the gNB-DU received a request for a SIB it had not received, however, it is able to generate it by itself, it can do so and broadcast it without need to interact with the gNB-CU.

The SI delivery via dedicated signaling is currently mainly used for two purposes: to provide SIB <NUM> during handover; and to provide updated SIB1 and/or ETWS/CMAS notifications (SIB6, SIB7 and SIB8) to specific UEs in RRC CONNECTED state that are utilizing a Bandwidth Part (BWP) which does not support broadcast, such as by having no Common Search Space (CSS) configured. That is, the UEs utilizing that BWP are unable to receive any SIBs via the default broadcast mechanism. In this case, the gNB-DU provides a list of UEs, which cannot receive the broadcast, to the gNB-CU. Then, the gNB-CU provides the SIBs to each UE separately.

A general issue with the existing mechanism is that the information provided by the gNB to different UEs within SIB will comprise exactly the same information. Further, if the information is generated at the gNB-CU, as with any of the Other-SI, it may not be optimal. One such case is SIB9, although this could apply to other SIBs in the future, in which the time-reference information that the gNB-DU can generate is more accurate and reliable. Therefore, it is preferable to use the information that the gNB-DU can generate.

The present disclosure tackles this issue by introducing a mechanism that extends the method described for broadcast scenarios above. Given that the gNB-CU has already become aware that the gNB-DU can generate certain information used in Other-SI, it can request such information rather than generating it by itself. Further, depending on the information, it should be possible for the gNB-CU to request an encoded SIB, or just some of its contents to be delivered as IEs. This is useful as some information may be the same for multiple UEs, or possibly applicable to multiple SIBs. In such case, it will be beneficial to have the flexibility at the gNB-CU to decide whether to encode the SIB itself using "assistance" information from the gNB-DU, or request an already encoded SIB from the gNB-DU, which could be transmitted without any changes. Providing assistance information enables the CU to prepare the unicast signaling to UEs, without increasing the signaling overhead over F1. The CU receiving an already encoded SIB could imply that the F1 procedure has to be executed per UE. The use of some of the not encoded contents of system information for some other purpose, such as coordination between the gNB-CUs or sharing the information with core network, is also envisioned.

Changes required in F1 interface are new IEs to indicate the information that the gNB-CU is requesting the gNB-DU to generate. For this purpose, both reuse of the CU configuration update procedure, as well as introduction of a new procedure for this purpose, are both viable choices.

Embodiments of this proposal are presented in <FIG>.

In step <NUM>, one or multiple UEs request the gNB-CU to provide a certain SIB or time-reference information via unicast RRC signaling. The request may be implemented either via RRC System Info Request message or a new "Time reference info request" message. The request may additionally indicate whether the UE is interested in receiving the information periodically or just "one-time".

Once the request is received from at least one UE, the gNB-CU decides that the requested information should originate from the gNB-DU. In step <NUM>, it sends the SIB/Time Info request to the gNB-DU indicating whether it wants to receive the information one time or periodically.

In step <NUM>, the gNB-DU responds with the requested information to the gNB-CU. Note that since unicast RRC messages are encoded by the gNB-CU, the gNB-DU cannot send the information directly to the UE.

In step <NUM>, the requested information is provided with a dedicated RRC signaling to the UEs which requested the information, such as via an RRC Reconfiguration message containing dedicated SIB IE or via a DL Information Transfer message.

In case the information which was requested by the UE is needed on a periodic basis, which can be determined either by an explicit indication from the UE or by the nature of the request, for example, time-reference information may be assumed to be always needed to be updated on a periodic basis, then steps <NUM> and <NUM> are repeated periodically, as represented by steps <NUM>' and <NUM>' in <FIG>.

It should be also noted that step <NUM> in <FIG> is not supported by the current specifications. 3GPP specifications allow requesting an SIB, but only in case gNB indicates in SIB1 that a certain SIB or SI message is available but currently is in a "not broadcasting" state. Based on that indication and on an additional configuration, a UE in an RRC IDLE or RRC INACTIVE state may request a certain SIB or SI message to be provided using one of the two methods:.

Hence, there are two additional issues with the current on-demand SI delivery mechanism:.

It is proposed to handle this issue by introducing the following new UE and network behavior for on-demand SI request mechanism, and thus making step <NUM> of the procedure in <FIG> possible: Allowing the UE to send a msg3-based SIB delivery request to a network in two new cases:.

Once such request is received by the network from a UE in an RRC CONNECTED state, the network delivers it via dedicated RRC signaling instead of broadcasting it, as is done at the moment for on-demand SI.

A high-level view of possible changes in IE definitions (IE names are just indicative) is as follows:.

A high level-view of the changes in procedures includes:.

An example of the new procedure for SI request for SIB9 by a UE in RRC CONNECTED state is presented in <FIG>. New steps are marked with an asterisk (*).

The procedure may result in SI request being sent by the UE which is either able to receive the SI via broadcast (that is, it is in an RRC CONNECTED state, but in the BWP supporting broadcast SI delivery) or which is only able to receive the requested SIB via dedicated RRC signaling, that is, it is in a BWP not supporting SI delivery. In the first case, the network has a choice to either provide the SI via broadcast or unicast depending on its preferences (for example, depending on whether more than a single UE requested a certain SIB). In the second case, there is no choice and the delivery should be via RRC-dedicated signaling. To make the UE aware of which method has been chosen, the gNB could indicate this in the confirmation message (at the moment, UE always initiates broadcast SI delivery when receiving a confirmation). Alternatively, the gNB may not send the confirmation, but deliver the message with a requested SIB right away or at its earliest possibility.

The above procedure and IE changes will provide the following benefits:.

<FIG> is a flow chart illustrating a method performed by a gNB-DU in accordance with the present disclosure. In block <NUM>, the gNB-DU indicates, to a second node, a capability information element for generating information related to Other-System Information (OSI). In block <NUM>, the gNB-DU receives an acknowledge indication from the second node. And, in block <NUM>, the gNB-DU generates system information broadcast information to at least one user equipment.

<FIG> is a flow chart illustrating a method performed by a gNB-CU in accordance with the present disclosure. In block <NUM>, the gNB-CU receives, from a first node, a capability information element for generating information related to Other-System Information (OSI). And, in block <NUM>, the gNB-CU transmits an acknowledge indication to the first node.

For example, some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software, which may be executed by a controller, microprocessor or other computing device, although the invention is not limited thereto.

While various aspects of the exemplary embodiments of this invention may be illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

It should thus be appreciated that at least some aspects of the exemplary embodiments of the inventions may be practiced in various components, such as integrated circuit chips and modules, and that the exemplary embodiments of this invention may be realized in an apparatus that is embodied as an integrated circuit. The integrated circuit, or circuits, may comprise circuitry, as well as possibly firmware, for embodying at least one or more of a data processor or data processors, a digital signal processor or processors, baseband circuitry and radio frequency circuitry that are configurable so as to operate in accordance with the exemplary embodiments of this invention.

Various modifications and adaptations to the foregoing exemplary embodiments of this invention may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings. For example, while the exemplary embodiments have been described above in the context of advancements to the <NUM> NR system, it should be appreciated that the exemplary embodiments of this invention are not limited for use with only this one particular type of wireless communication system. The exemplary embodiments of the invention presented herein are explanatory and not exhaustive or otherwise limiting of the scope of the invention.

The following abbreviations have been used in the preceding discussion:.

The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiment was chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.

Various modifications and adaptations may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings. However, any and all modifications of the teachings of this disclosure will still fall within the scope of the non-limiting embodiments of this invention.

Claim 1:
A gNodeB centralized unit comprising:
means for receiving, from a gNodeB distributed unit, information indicating the gNodeB distributed unit's capability for generating other-system information, wherein the other-system information comprises system information other than master information block and system information block <NUM> information;
means for transmitting, to the gNodeB distributed unit, a request for the other-system information, wherein the other-system information comprises time reference information generated by the gNodeB distributed unit;
means for receiving a delivery of the other-system information from the gNodeB distributed unit; and
means for generating system information broadcast information to be sent via dedicated signaling to at least one user equipment based at least in part on the other-system information.