Patent Description:
<FIG> illustrates network nodes <NUM>, <NUM>, and <NUM> in a radio access network. Network nodes <NUM> and <NUM> are each a next Generation Node B (gNB). Network node <NUM> is an Evolved Node B (eNB). Network nodes <NUM> and <NUM> each have an exemplary split deployment. In the split deployment, gNB <NUM>, <NUM> are each divided into two units, a gNB central unit (gNB-CU) and a gNB distributed unit (gNB-DU). Each gNB-CU and gNB-DU are connected via an F1 Application Protocol (F1AP). gNB102 and gNB <NUM> are connected via an Xn Application Protocol (XnAP) interface. gNB <NUM> and eNB <NUM> are connected via an X2 Application Protocol (X2AP) interface.

In new radio (NR), the synchronization signal (SSB) has a variable periodicity of <NUM>, <NUM>, <NUM>, <NUM>, <NUM> or <NUM>. <FIG> shows the measurement gaps for user equipment (UE) are defined in 3GPP TS <NUM> v15. <NUM> (<NUM>-<NUM>), Requirements for Support of Radio Resource Management. Referring to <FIG>, no gap can be longer than <NUM>. Any periodicity longer than <NUM>, may require configuration of UE with the synchronization signal/physical broadcast channel block measurement time configuration (SMTC (SSB-MTC)) defined in 3GPP TS <NUM> v15. <NUM> (<NUM>-<NUM>), Radio Resource Control (RRC) protocol. <FIG> shows a synchronization signal block (SSB)-measurement time configuration (MTC) (SSB-MTC) information element from 3GPP TS <NUM> v. <NUM> (<NUM>-<NUM>) for configuring measurement timing configurations, e.g., timing occasions at which a UE measures SSBs. <FIG> shows exemplary SSB-MTC field descriptions from 3GPP TS <NUM> v15. <NUM> (<NUM>-<NUM>) for the SSB-MTC information element shown in <FIG>.

The SSB-MTC information element indicates to a UE where in time to find the SSB. The SSB-MTC is configured both for inter-frequency NR measurements (where the UE measures from NR to NR and needs gaps), and for Bx measurements from Long Term Evolution (LTE) to NR (e.g., to set up EUtra NR Dual Connectivity (EN-DC) or to perform mobility from LTE to NR).

As neighboring nodes require this information to configure UEs properly, this same information is sent from a gNB-DU (e.g., gNB-DU 102b) to a gNB-CU (e.g., gNB-CU 102a) over the F1AP interface; and between a gNB (e.g., gNB <NUM>) and an eNB (e.g., eNB <NUM>) over an X2/Xn interface (if EN-DC/New Radio-EUtra Dual Connectivity (NE-DC), the X2 interface is used when the eNB (e.g., eNB <NUM>) is the master and the Evolved Packet Core (EPC) is used when the gNB (e.g., gNB <NUM>) is the master and <NUM> Core Network (5GC) is used) or between a gNB (e.g., gNB <NUM>) and a gNB (e.g., gNB <NUM>) over Xn.

<FIG> illustrates an excerpt from 3GPP TS <NUM> v15. <NUM>, Section <NUM>. <NUM> for a F1 Setup Request over a F1AP interface. This message is sent by a gNB-DU (e.g., gNB-DU 102b) to transfer information for a transport network layer (TNL) association. The direction of the message is from a gNB-DU toward a gNB-CU. As shown in <FIG>, both the system information and the served cell information is passed to the gNB-CU (e.g., gNB-CU 102a).

<FIG> illustrates a gNB-DU System Information from 3GPP TS <NUM> v15. <NUM>, Section <NUM>. Referring to <FIG>, the gNB-DU System information element contains system information generated by a gNB-CU (e.g., gNB-CU 102a). A Served Cell information element from 3GPP TS <NUM> v15. <NUM>, Section <NUM>. <NUM>, is shown in <FIG>. Referring to <FIG>, the Served Cell information element contains cell configuration information of a cell in the gNB-DU (e.g., gNB-DU 102b).

A Measurement Timing Configuration message is used to convey assistance information for measurement timing. The direction of a Measurement Timing Configuration message may be from en-gNB toward a eNB, from an eNB toward a en-gNB, from a gNB toward a gNB, from a gNB-DU toward a gNB-CU, and from a gNB-CU toward a gNB-DU. <FIG> shows an excerpt of a Measurement Timing Configuration message, and Measurement Timing field descriptions, from 3GPP TS <NUM>, v15.

3GPP TS <NUM> v. <NUM> (<NUM>-<NUM>), Architecture description, describes gNB synchronization and states that a configurable LTE time division duplex (TDD) offset of start frame is supported by gNBs in synchronized TDD-unicast areas in order to achieve interoperability in coexistence scenarios.

Thus, a configurable SFN offset may also be applicable to NR Cells.

<FIG> illustrates a successful operation of a procedure for an Xn setup from 3GPP TS <NUM>, Section <NUM>. <FIG> shows a successful operation of a procedure for an Xn configuration update from 3GPP TS <NUM>, Section <NUM>.

In EN-DC, as part of a cg-ConfigInfo RRC container sent from eNB to gNB as part of a Secondary gNB (SgNB) Addition Request or Reconfiguration (either from eNB or responses to reconfiguration from gNB), the eNB sends information regarding the master cell group discontinuous reception (DRX) and measurement gap configuration.

<FIG> illustrate an exemplary cg-ConfigInfo message from 3GPP TS <NUM>. This message may be used by a master eNB or gNB to request a SgNB to perform certain actions, e.g. to establish, modify or release a secondary cell group (SCG). The message may include additional information, e.g. to assist the SgNB to set a SCG configuration. It can also be used by a CU to request a DU to perform certain actions, e.g. to establish, modify or release a master cell group (MCG) or SCG. The direction of a cg-ConfigInfo message may be from a master eNB or a gNB toward a secondary gNB, or alternatively a CU toward a DU.

<FIG> illustrates a MeasGapConfig information element from 3GPP TS <NUM>. The MeasGapConfig information element specifies the measurement gap configuration and controls setup/release of measurement gaps. The gapOffset shown in <FIG> is an offset which references a LTE Cell system frame number (SFN).

Additionally, in LTE, a sync signal is broadcast in subframe <NUM> and <NUM> for frequency division duplex (FDD), and subframe <NUM> and <NUM> for TDD, all in slot <NUM>.

In release14, a capability is introduced in LTE referred to as shortMeasurementGap-r14. The shortMeasurmentGap-r14 capability indicates whether a UE is capable of performing <NUM> gaps, instead of the <NUM> gaps. See 3GPP TS <NUM> v15. <NUM> (<NUM>-<NUM>), Evolved Universal Terrestrial Radio Access (E-Utra), Requirements for Support of Radio Resource Management. <FIG> illustrates Gap Pattern Configurations supported by a UE from 3GPP TS <NUM> v15. <NUM> (<NUM>-<NUM>), Table <NUM>. <NUM>-<NUM>. This gap pattern can be configured for E-UTRA measurement when a UE supports shortMeasurementGap-r14 or can be configured for inter-RAT NR measurement only.

In current NR systems, a problem may exist where SFN offset information is not available in an Application Protocol interface setup, configuration, and/or update procedure.

Document <CIT> discloses sending a message by a core network device to a network node for configuring a time difference.

The accompanying drawings, which are included to provide a further understanding of the disclosure and are incorporated in a constitute a part of this application, illustrate certain non-limiting embodiments of inventive concepts. In the drawings:.

Other embodiments, however, are contained within the scope of the subject matter disclosed herein, and the disclosed subject matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

<FIG> is a diagram illustrating network time reference, Node B Frame Number Counter (BFN), SFN, SSB, timings and offsets. In current messages, a gNB-CU or neighboring eNB or gNBs are only informed of the offset between the cell SFN and the SSB in the periodicityAndOffset information element (IE) as part of the MeasurementTiminingConfiguration of the cell.

The offset between the SFN and the BFN of the node, or the offset between the BFN and an absolute time reference are not known.

Thus, the neighboring nodes may have a reference to a relative time reference (per cell), but they may not know the offset between the relative time and the absolute time reference.

In that case, every node may have to request UE to perform a measurement on each neighboring frequency for a first time until the time difference is found. If a measurement gap is required, the node may have to guess the offset, configure the UE to perform measurements, and repeat with a different offset in case the UE fails to find the SSB.

Additionally, the cell relations configuration in a gNB-CU or eNB may be difficult to manage if all the timing configurations refer to the relative SFN of each cell, as multiple cells in multiple frequencies will share the same configuration. For example, NRCellCU=<NUM> (with the SFN aligned with Global Positioning System (GPS)) and NRCellCU=<NUM> (with SFN <NUM> ahead of GPS) may want to have a frequency relation to a certain SSB frequency and timing configuration.

If an operator were to configure this relation:.

In the case of a cg-ConfigInfo RRC, there may be a similar issue. A gNB may not have a reference for the LTE Cell SFN unless System Frame Number and Frame Timing Difference (SFTD) measurements have been performed and the gNB is informed of the result.

Such information is not available in the X2 EN-DC Setup procedure for eNBs.

In the case of shortMeasurementGaps between two LTE frequencies, a eNB must be aware of the neighboring cell SFN offset and duplexing type (TDD/FDD), so it can schedule the gap so it overlaps with the synchronization signal occasion.

Such SFN offset information is not available in X2 Setup procedure.

Certain aspects of the present disclosure and their embodiments provide solutions to these and/or other challenges. According to certain embodiments, the time difference between the absolute time reference in the node, if present, and the SFN for the cell is provided.

Certain embodiments provide one or more of the following technical advantages. Some embodiments allow for there to be no need to implement logic on the nodes to guess the ssbOffset error, or SFTD measurements (which measure SFN offset between LTE and NR Cell) if there is a Network Synchronization available. Some embodiments also provide for UEs to be configured with measurement(s) containing the right timing from the start, with no need for a training period for the network. Some embodiments also provide for the configuration of a radio base station (RBS) to refer to the absolute time. This is relevant for the frequency relations. There may be a time reference for the target cell SSB configuration, and the time reference can be referred then to the absolute time, if present. Some embodiments also provide for two eNBs with different SFN offsets in their cells to use short measurement gaps without the need for additional configuration. Other technical advantages are also provided.

According to certain embodiments, the time difference between the absolute time reference in the node, if present, and the SFN for the cell is provided. In the various embodiments, other nodes with an absolute time reference can understand the absolute time referred in the MeasurementTimingConfiguration in F1/X2 messages, without needing to implement functionality to guess the offset between them if they have an absolute time reference.

In various embodiments, for F1AP/X2AP/XnAP interfaces, the time difference between the absolute time reference in the node, if present, and the SFN for the cell may be implemented with proprietary and/or standardized messages.

In the case of using standardized messages, the time difference between the absolute time reference in the node, if present, and the SFN for the cell may be implemented in various messages as described further below.

In one embodiment, referring to <FIG>, a served cell Information message may include a SFN offset information element (IE). The SFN offset IE may be implemented over an F1AP interface. The SFN offset IE may be optional, as indicated by "Presence" "O. " The SFN offset IE may provide a SFN offset for the cell relative to a network time reference.

Alternatively, in some embodiments, the SFN offset IE may be implemented as part of the messages sent in a F1 Setup Request and/or a F1 Configuration Update as shown in <FIG>, respectively.

In one embodiment, <FIG> illustrates a F1 setup procedure from 3GPP TS <NUM> in which a SFN offset IE may be implemented as part of a F1 Setup Request message sent from a gNB-DU (e.g., gNB-DU 102a) to a gNB-CU (e.g., gNB-CU 102b). This message may be sent by the gNB-DU to transfer information for a TNL association. <FIG> illustrates IE/Group Names in a F1 Setup Request message, including the SFN offset IE. Referring to <FIG>, the SFN offset IE may be optional, as indicated by "Presence" "O. " The SFN offset IE may provide a SFN offset for the cell relative to a network time reference.

In another embodiment, <FIG> illustrates a gNB-DU configuration update procedure from 3GPP TS <NUM> in which a SFN offset IE may be implemented as part of the F1 Configuration Update message sent from a gNB-Du to a gNB-CU. This message may be sent by the gNB-DU to transfer information for a TNL association. <FIG> illustrates IE/Group Names in a gNB-DU Configuration Update message for a new cell, including the SFN offset IE. Referring to <FIG>, the SFN offset IE may be optional, as indicated by "Presence" "O. " The SFN offset IE may provide a SFN offset for the cell relative to a network time reference. <FIG> illustrates IE/Group Names in a gNB-DU Configuration Update message for modifying an existing cell, including the SFN offset IE. Referring to <FIG>, the SFN offset IE may be optional, as indicated by "Presence" "O. " The SFN offset IE may provide a SFN offset for the cell relative to a network time reference.

In a further embodiment, the SFN offset IE may be implemented as part of a Served NR Cell Information message over an X2AP interface. This message may contain cell configuration information of an NR cell that a neighbour eNB may need for the X2 AP interface. <FIG> illustrates IE/Group Names in a Served NR Cell Information message, including the SFN offset IE. Referring to <FIG>, the SFN offset IE may be optional, as indicated by "Presence" "O. " The SFN offset IE may provide a SFN offset for the cell relative to a network time reference.

In another embodiment, the SFN offset IE may be implemented as part of a NR Neighbour Information message over an X2AP interface. This message may contain cell configuration information of NR cells that a neighbour node may need for the X2 AP interface. <FIG> illustrates IE/Group Names in a NR Neighbour Information message, including the SFN offset IE. Referring to <FIG>, the SFN offset IE may be optional, as indicated by "Presence" "O. " The SFN offset IE may provide a SFN offset for the cell relative to a network time reference.

In another embodiment, <FIG> illustrates an EN-DC X2 setup from 3GPP TS <NUM> in which the SFN offset IE may be implemented as part of an EN-DC X2 Setup Request message sent from a MeNB to an en-gNB, per served cell and neighbour information. The SFN offset IE may be optional. The SFN offset IE may provide a SFN offset for the cell relative to a network time reference.

In a further embodiment, <FIG> illustrates an eNB initiated EN-DC Configuration Update from 3GPP TS <NUM> in which the SFN offset IE may be implemented as part of an EN-DC Configuration Update message sent from a MeNB to an en-gNB, per served cell and neighbour information. The SFN offset IE may be optional. The SFN offset IE may provide a SFN offset for the cell relative to a network time reference.

In one embodiment, the SFN offset IE may be implemented as part of a Served NR Cell Information message over an XnAP interface. This message may contain cell configuration information of an NR cell that a neighbour eNB may need for the XnAP interface. The Served NR Cell Information message may include the SFN offset IE. The SFN offset IE may be optional. The SFN offset IE may provide a SFN offset for the cell relative to a network time reference.

In another embodiment, the SFN offset IE may be implemented as part of a NR Neighbour Information message over an XnAP interface. This message may contain cell configuration information of NR cells that a neighbour node may need for the XnAP interface. The NR Neighbour Information message may include the SFN offset IE. The SFN offset IE may be optional. The SFN offset IE may provide a SFN offset for the cell relative to a network time reference.

In a further embodiment, the SFN offset IE may be implemented as part of an EN-DC Xn Setup Request message sent from a MeNB to an en-gNB, per served cell and neighbour information. The SFN offset IE may be optional. The SFN offset IE may provide a SFN offset for the cell relative to a network time reference.

In another embodiment, the SFN offset IE may be implemented as part of an EN-DC Configuration Update message over an XnAP interface sent from a MeNB to an en-gNB, per served cell and neighbour information. The SFN offset IE may be optional. The SFN offset IE may provide a SFN offset for the cell relative to a network time reference.

In another embodiment, for eNBs, the SFN offset IE may be added to the Served Cell Information IE described in 3GPP TS <NUM> v <NUM>. <NUM> (<NUM>-<NUM>), X2 Application Protocol (X2AP). The Served Cell Information IE may contain cell configuration information of a cell that a neighbour eNB may need for the X2 AP interface. <FIG> illustrates IE/Group Names in a Served Cell Information IE, including the SFN offset IE. Referring to <FIG>, the SFN offset IE may be optional, as indicated by "Presence" "O. " The SFN offset IE may provide a SFN offset for the cell relative to a network time reference. The same SFN offset IE may be added to the neighbour information.

It will be appreciated that the SFN offset IE shown in <FIG>, <FIG>, and <FIG> is for purposes of example, and other embodiments may modify the message for configuring the time difference without deviating from the scope of inventive concepts.

Network nodes <NUM>, <NUM>, and <NUM> include various components described in more detail below. These components work together in order to provide network node and/or wireless device functionality, such as providing wireless connections in a radio access network. In different embodiments, the radio access network may include any number of wired or wireless networks, network nodes, base stations, controllers, wireless devices, relay stations, and/or any other components or systems that may facilitate or participate in the communication of data and/or signals whether via wired or wireless connections.

As used herein, network node refers to equipment capable, configured, arranged and/or operable to communicate directly or indirectly with a UE, wireless device and/or with other network nodes or equipment in the radio access network to enable and/or provide wireless access to the wireless device and/or to perform other functions (e.g., administration) in the radio access network. Examples of network nodes include, but are not limited to, Node Bs, evolved Node Bs (eNBs), and next generation Node Bs (gNBs), access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations), etc.). As another example, a network node may be a virtual network node. More generally, however, network nodes may represent any suitable device (or group of devices) capable, configured, arranged, and/or operable to enable and/or provide a wireless device with access to the radio access network or to provide some service to a wireless device that has accessed the radio access network.

Operations of network node <NUM>, <NUM>, <NUM> (e.g., a base station, eNB, gNB, etc.) of a radio access network will now be discussed with reference to the flow charts of <FIG>. For example, network node <NUM>, <NUM>, <NUM> may be implemented using the structure of network node <NUM> from <FIG>. Network node <NUM> includes a processor circuit <NUM> (also referred to as a processor), a memory circuit <NUM> (also referred to as memory), and a network interface <NUM> (e.g., wired network interface and/or wireless network interface) configured to communicate with other network nodes. The network node <NUM> may be configured as a radio network node containing a RF front end with one or more power amplifiers <NUM> that transmit and receive through antennas of an antenna array <NUM>. The memory <NUM> stores computer readable program code that when executed by the processor <NUM> causes the processor <NUM> to perform operations according to embodiments disclosed herein.

Referring initially to <FIG>, operations are performed by a network node (e.g., <NUM> in <FIG>) for configuring a time difference in the network node between an absolute time reference in the network node and system frame offset for a served cell of the network node in the radio access network. The operations include sending <NUM> a message from a first portion of the network node (e.g., 102b) to a second portion of the network node (e.g., 102a) for configuring the time difference. The message includes an indicator in the message defining the time difference between the system frame offset for the served cell and the absolute time reference. The operations further include receiving <NUM> an acknowledgement message from the second portion of the network node acknowledging that the second portion of the network node included the time difference in cell configuration data for the served cell.

In at least some embodiments, the system frame offset for the served cell relative to the absolute time reference is a specified amount of time.

The operation of sending <NUM> the message and receiving <NUM> the acknowledgement message may be communicated over an F1 application protocol interface.

The first portion of the network node (e.g., 102b) is a distributed unit of the network node. The second portion of the network node (e.g., 102a) is a central unit of the network node. The message may include a message requesting an F1 setup with a central unit of the network node. The acknowledgement message may include an F1 setup response message from the central unit of the network node.

In another embodiment, the message may include a message sending a configuration update for a distributed unit of the network node. The acknowledgement message may include a configuration update acknowledgement message from the central unit of the network node.

In a further embodiment, the message may include a message to transfer a transport network layer association to a central unit of the network node. The acknowledgement message may include a transport layer association acknowledgement message from the central unit of the network node.

In another embodiment, the message may include a message to transfer updated information for a transport layer association to a central unit of the network node. The acknowledgement message may include a transport layer association updated acknowledgement message from the central unit of the network node.

With reference to <FIG>, operations are performed by a network node (e.g., <NUM> in <FIG>) for providing to a neighboring network node (e.g., <NUM> in <FIG>) in a radio access network a time difference between a network time reference and a system frame offset for a cell in a radio access network. The operations include sending <NUM> a message from the network node to the neighboring network node providing the time difference. The message includes an indicator in the message defining the time difference between the system frame offset for the cell and the absolute time reference. The operations further include receiving <NUM> an acknowledgement message from the neighboring network node acknowledging that the neighboring network node included the time difference in cell configuration data for the cell.

In at least some embodiments, the system frame offset for the neighboring cell relative to the network time reference is a specified amount of time.

In one embodiment, the operation of sending <NUM> the message and receiving <NUM> the acknowledgement message may be communicated over an X2 application protocol interface. The message may include a message requesting an X2 setup with the neighboring network node. The acknowledgement message may include an X2 setup response message from the neighboring network node.

In another embodiment, the operation of sending <NUM> the message and receiving <NUM> the acknowledgement message may be communicated over an Xn application protocol interface. The message may include a message requesting an Xn setup with the neighboring network node. The acknowledgement message may include an Xn setup response message with the neighboring network node.

In a further embodiment, the message may include a message sending a configuration update for the neighboring network node. The acknowledgement message may include a configuration update acknowledgement message from the neighboring network node.

In another embodiment, the message may include a message requesting a evolved universal terrestrial radio access new radio dual connectivity (EN-DC) setup with the neighboring node. The acknowledgement message may include an EN-DC acknowledgement message from the neighboring network node.

In a further embodiment, the message may include a message sending an evolved universal terrestrial radio access new radio dual connectivity (EN-DC) configuration update for the neighboring node. The acknowledgement message may include an EN-DC configuration update acknowledgement message from the neighboring network node.

Although the subject matter described herein may be implemented in any appropriate type of system using any suitable components, the embodiments disclosed herein are described in relation to a radio access network that includes example network nodes, such as illustrated in <FIG>. For simplicity, the network nodes of <FIG> depicts only two gNBs <NUM> and <NUM>, each having a split deployment where the gNB is divided into two units (gNB-CU and gNB-DU), and one eNB <NUM>. In practice, a radio access network may further include any additional elements suitable to support communication between wireless devices or between a wireless device and another communication device, such as a landline telephone, a service provider, or any other network node or end device.

The radio access network may comprise and/or interface with any type of communication, telecommunication, data, cellular, and/or radio network or other similar type of system. In some embodiments, the radio access network may be configured to operate according to specific standards or other types of predefined rules or procedures.

The radio access network may include one or more backhaul networks, core networks, IP networks, public switched telephone networks (PSTNs), packet data networks, optical networks, wide-area networks (WANs), local area networks (LANs), wireless local area networks (WLANs), wired networks, wireless networks, metropolitan area networks, and other networks to enable communication between devices.

In certain embodiments, some or all of the functionality described herein as being provided by a network node, base station, eNB or other such network device may be performed by processing circuitry <NUM> executing instructions stored on non-transitory device readable medium <NUM> or memory within processing circuitry <NUM>.

Interface <NUM> is used in the wired or wireless communication of signalling and/or data between network node <NUM>, the radio access network, and/or UEs. Interface <NUM> comprises port(s)/terminal(s) to send and receive data, for example to and from the radio access network over a wired connection. Interface <NUM> also may include radio front end circuitry <NUM> that may be coupled to, or in certain embodiments a part of, antenna <NUM>. Radio front end circuitry <NUM> may include filters and amplifiers. Radio front end circuitry <NUM> may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters and/or amplifiers.

Similarly, in some embodiments, all or some of RF transceiver circuitry may be considered a part of interface <NUM>. In still other embodiments, interface <NUM> may include one or more ports or terminals <NUM>, radio front end circuitry <NUM>, and RF transceiver circuitry, as part of a radio unit (not shown), and interface <NUM> may communicate with baseband processing circuitry, which is part of a digital unit (not shown).

Power circuitry (not shown) may comprise, or be coupled to, power management circuitry and is configured to supply the components of network node <NUM> with power for performing the functionality described herein. Power circuitry may receive power from power source. Power source and/or power circuitry may be configured to provide power to the various components of network node <NUM> in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). Power source (not shown) may either be included in, or external to, power circuitry and/or network node <NUM>. For example, network node <NUM> may be connectable to an external power source (e.g., an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry. As a further example, power source <NUM> may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry.

Alternative embodiments of network node <NUM> may include additional components beyond those shown in <FIG> that may be responsible for providing certain aspects of the network node's functionality, including any of the functionality described herein and/or any functionality useful/necessary to support the subject matter described herein.

Claim 1:
A method performed by a network node (<NUM>, <NUM>) in a radio access network, the method comprising:
sending (<NUM>) a message from a first portion of the network node (102b) to a second portion of the network node (102a) for configuring a time difference, wherein the message includes an indicator in the message defining the time difference in the network node between an absolute time reference in the network node and a system frame offset for a served cell of the network node, wherein the first portion of the network node is a distributed unit of the network node; and wherein the second portion of the network node is a central unit of the network node; and
receiving (<NUM>) an acknowledgement message from the second portion of the network node acknowledging that the second portion of the network node included the time difference in cell configuration data for the served cell.