Patent Application
20210051569
This application claims priority from Indian Application No.: 201941032866 filed on Aug. 14, 2019, which is hereby incorporated in its entirety.
This disclosure concerns mechanisms for providing and broadcasting System Information (SI) in an environment where a gNB has been decomposed into a gNB-CU (Centralized Unit) and a gNB-DU (Distributed Unit).
The 3rd 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
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 160 ms, 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 5G 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 SIB s 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 16 work items.
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 5G. However, it should be understood that the present invention, as described below, is not limited to 5G, 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.
In a first aspect of the present disclosure, a method comprises: indicating, by a first node to a second node, a capability information element for generating information related to Other-System Information (OSI); receiving an acknowledge indication from the second node; and generating, by the first node, system information broadcast information to at least one user equipment.
In a second aspect of the present disclosure, an apparatus comprises: at least one processor; and at least one memory including computer program code, the at least one memory and the computer program code being configured, with the at least one processor, to cause the apparatus to perform the following: indicating, by a first node to a second node, a capability information element for generating information related to Other-System Information (OSI); receiving an acknowledge indication from the second node; and generating, by the first node, system information broadcast information to at least one user equipment.
In a third aspect of the present disclosure, an apparatus comprises: means for indicating, by a first node to a second node, a capability information element for generating information related to Other-System Information (OSI); means for receiving an acknowledge indication from the second node; and means for generating, by the first node, system information broadcast information to at least one user equipment.
In a fourth aspect of the present disclosure, a computer program product comprises a non-transitory computer-readable storage medium bearing computer program code embodied therein for use with a computer, the computer program code comprising code for performing: indicating, by a first node to a second node, a capability information element for generating information related to Other-System Information (OSI); receiving an acknowledge indication from the second node; and generating, by the first node, system information broadcast information to at least one user equipment.
In a fifth aspect of the present disclosure, a method comprises: receiving, by a second node from a first node, a capability information element for generating information related to Other-System Information (OSI); and transmitting an acknowledge indication to the first node.
In a sixth aspect of the present disclosure, an apparatus comprises: at least one processor; and at least one memory including computer program code, the at least one memory and the computer program code being configured, with the at least one processor, to cause the apparatus to perform the following: receiving, by a second node from a first node, a capability information element for generating information related to Other-System Information (OSI); and transmitting an acknowledge indication to the first node.
In a seventh aspect of the present disclosure, an apparatus comprises: means for receiving, by a second node from a first node, a capability information element for generating information related to Other-System Information (OSI); and means for transmitting an acknowledge indication to the first node.
In an eighth aspect of the present disclosure, a computer program product comprises a non-transitory computer-readable storage medium bearing computer program code embodied therein for use with a computer, the computer program code comprising code for performing: receiving, by a second node from a first node, a capability information element for generating information related to Other-System Information (OSI); and transmitting an acknowledge indication to the first node.
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.
The RAN node 170 in this example is a base station that provides access by wireless devices, such as the UE 110, to the wireless network 100. The RAN node 170 may be, for example, a base station for 5G, also called New Radio (NR). In 5G, the RAN node 170 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) 190. 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) 196 and distributed unit(s) (DUs) (gNB-DUs), of which DU 195 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 198, although reference 198 also illustrates a link between remote elements of the RAN node 170 and centralized elements of the RAN node 170, such as between the gNB-CU 196 and the gNB-DU 195. 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 198 connected with the gNB-CU. Note that the DU 195 is considered to include the transceiver 160, for example, as part of a RU, but some examples of this may have the transceiver 160 as part of a separate RU, for example, under control of and connected to the DU 195. The RAN node 170 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 170 includes one or more processors 152, one or more memories 155, one or more network interfaces (N/W I/F(s)) 161, and one or more transceivers 160 interconnected through one or more buses 157. Each of the one or more transceivers 160 includes a receiver, Rx, 162 and a transmitter, Tx, 163. The one or more transceivers 160 are connected to one or more antennas 158. The one or more memories 155 include computer program code 153. The CU 196 may include the processor(s) 152, memories 155, and network interfaces 161. Note that the DU 195 may also contain its own memory/memories and processor(s), and/or other hardware, but these are not shown.
The RAN node 170 includes a module 150, comprising one of or both parts 150-1 and/or 150-2, which may be implemented in a number of ways. The module 150 may be implemented in hardware as module 150-1, such as being implemented as part of the one or more processors 152. The module 150-1 may be implemented also as an integrated circuit or through other hardware such as a programmable gate array. In another example, module 150 may be implemented as module 150-2, which is implemented as computer program code 153 executed by the one or more processors 152. For instance, the one or more memories 155 and the computer program code 153 are configured, with the one or more processors 152, to cause the RAN node 170 to perform one or more of the operations as described herein. Note that the functionality of the module 150 may be distributed, such as being distributed between the DU 195 and the CU 196, or be implemented solely in the DU 195.
The one or more network interfaces 161 communicate over a network such as via the links 176 and 131. Two or more gNBs 170 may communicate using, e.g., link 176. The link 176 may be wired or wireless or both and may implement, for example, an Xn interface for 5G, an X2 interface for LTE, or other suitable interface for other standards.
The one or more buses 157 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 160 may be implemented as a remote radio head (RRH) 195 for LTE or a distributed unit (DU) 195 for gNB implementation for 5G, with the other elements of the RAN node 170 possibly being physically in a different location from the RRH/DU, and the one or more buses 157 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 170 to the RRH/DU 195. Reference 198 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 360° 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 120° cells per carrier and two carriers, then the base station has a total of 6 cells.
The wireless network 100 may include a network element or elements 190 that may include core network functionality, and which provides connectivity via a link or links 181 with a further network, such as a telephone network and/or a data communications network (e.g., the Internet). Such core network functionality for 5G 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) 190, and note that both 5G and LTE functions might be supported. The RAN node 170 is coupled via a link 131 to a network element 190. The link 131 may be implemented as, for example, an NG interface for 5G, or an S1 interface for LTE, or other suitable interface for other standards. The network element 190 includes one or more processors 175, one or more memories 171, and one or more network interfaces (N/W I/F(s)) 180, interconnected through one or more buses 185. The one or more memories 171 include computer program code 173. The one or more memories 171 and the computer program code 173 are configured, with the one or more processors 175, to cause the network element 190 to perform one or more operations.
The wireless network 100 may implement network virtualization, which is the process of combining hardware and software network resources and network functionality into a single, software-based administrative entity, a virtual network. Network virtualization involves platform virtualization, often combined with resource virtualization. Network virtualization is categorized as either external, combining many networks, or parts of networks, into a virtual unit, or internal, providing network-like functionality to software containers on a single system. Note that the virtualized entities that result from the network virtualization are still implemented, at some level, using hardware such as processors 152 or 175 and memories 155 and 171, and also such virtualized entities create technical effects.
The computer-readable memories 125, 155, and 171 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 125, 155, and 171 may be means for performing storage functions. The processors 120, 152, and 175 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 120, 152, and 175 may be means for performing functions, such as controlling the UE 110, RAN node 170, and other functions as described herein.
In general, the various embodiments of the user equipment 110 can include, but are not limited to, cellular telephones such as smart phones, tablets, personal digital assistants (PDAs) having wireless communication capabilities, portable computers having wireless communication capabilities, image capture devices such as digital cameras having wireless communication capabilities, gaming devices having wireless communication capabilities, music storage and playback appliances having wireless communication capabilities, Internet appliances permitting wireless Internet access and browsing, tablets with wireless communication capabilities, as well as portable units or terminals that incorporate combinations of such functions.
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 38.401 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 38.470 and 3GPP TS 38.473, 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 160 ms.
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 1 (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.
2. Dedicated (RRC) Signaling (that is, Unicast (RRC) Signaling)
The SI delivery via dedicated signaling is currently mainly used for two purposes: to provide SIB1 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
In step 1, 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 2, 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 3, 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 4, 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 3 and 4 are repeated periodically, as represented by steps 3′ and 4′ in
It should be also noted that step 1 in
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 1 of the procedure in
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.
IE Changes:
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:
1. F1 SETUP Procedure, as illustrated in
2. GNB-DU Configuration Update Procedure, as illustrated in
3. GNB-CU CONFIGURATION UPDATE Procedure, as illustrated in
4. (NEW) OTHER-SI REQUEST Procedure:
An example of the new procedure for SI request for SIB9 by a UE in RRC CONNECTED state is presented in
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:
In general, the various exemplary embodiments may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. 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 5G 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:
gNB gNodeB (5G Base Station)
gNB-CU gNB Centralized Unit
gNB-DU gNB Distributed Unit
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a”, “an”, and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising”, when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
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 without departing from the scope and spirit of the invention. 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.
Although described in the context of particular embodiments, it will be apparent to those skilled in the art that a number of modifications and various changes to these teachings may occur. Thus, while the invention has been particularly shown and described with respect to one or more embodiments thereof, it will be understood by those skilled in the art that certain modifications or changes may be made therein without departing from the scope of the invention as set forth above, or from the scope of the claims to follow.
| Number | Date | Country | Kind |
|---|---|---|---|
| 201941032866 | Aug 2019 | IN | national |
