Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 38.401  Word version:  16.3.0

Top   Top   Up   Prev   None
1…   5…   6…   6.2…   7…   8…   8.2…   8.2.2   8.2.3   8.2.4…   8.3   8.4…   8.5…   8.9…   8.10…   9…

 

9  SynchronizationWord‑p. 72

9.1  gNB Synchronization

The gNB shall support a logical synchronization port for phase-, time- and/or frequency synchronization.
Logical synchronization port for phase- and time-synchronization shall provide:
  1. accuracy that allows to meet the gNB requirements on maximum relative phase difference for all gNBs in synchronized TDD-unicast area;
  2. continuous time without leap seconds traceable to common time reference for all gNBs in synchronized TDD-unicast area. In the case the TDD-unicast area is not isolated, the common time reference shall be traceable to the Coordinated Universal Time (UTC).
A logical synchronization port for phase- and time-synchronization may also be provided for e.g., all gNBs in FDD time domain inter-cell interference coordination synchronization area.
Furthermore common SFN initialization time shall be provided for all gNBs in synchronized TDD-unicast area.
In case of non isolated networks, the start of the radio frame on the output shall be synchronous with the input time reference, i.e., when an UTC traceable reference is required, the start of the radio frame shall be aligned with the start time of the UTC second.
Unless otherwise mutually agreed by the operators of the cells in non isolated networks and/or unless different SFN initialization offsettings do not affect operators' networks in the same area, the common SFN initialization time should be 1980-01-06T00:00:19 International Atomic Time (TAI).
Based on this information, the gNB may derive the SFN according to the following formula:
SFN = {time}mod{period(SFN)},
where:
time
time adjusted by the common SFN initialization time, in units of 10 ms to match the length of radio frame and accuracy accordingly;
period(SFN)
SFN period.
In case gNB is connected via TDM interface, it may be used to frequency synchronize the gNB. The characteristics of the clock in the gNB shall be designed taking into account that the jitter and wander performance requirements on the interface are in accordance with network limits for output wander at traffic interfaces of either ITU-T Recommendation G.823 [8], ITU-T Recommendation G.824 [9] or network limits for the maximum output jitter and wander at any hierarchical interface of ITU-T Recommendation G.825 [10], whichever is applicable.
In case gNB is connected via Ethernet interface and the network supports Synchronous Ethernet, the gNB may use this interface to get frequency synchronization. In this case the design of the gNB clock should be done considering the jitter and wander performance requirements on the interface are as specified for output jitter and wander at EEC interfaces of ITU-T Recommendation G.8261/Y.1361 [11], defined in clause 9.2.1. Further considerations on Synchronous Ethernet recommendations and architectural aspects are defined in clause 12.2.1 and Annex A of ITU-T Recommendation G.8261/Y.1361 [11].
A configurable LTE TDD-offset of start frame shall be supported by all gNBs in synchronized TDD-unicast areas in order to achieve interoperability in coexistence scenarios.
Up

10  NG-RAN interfacesWord‑p. 73

10.1  NG interface

TS 38.410 specifies NG interface general aspects and principles.

10.2  Xn interface

TS 38.420 specifies Xn interface general aspects and principles.

10.3  F1 interface

TS 38.470 specifies F1 interface general aspects and principles.

10.4  E1 interface

TS 38.460 specifies E1 interface general aspects and principles.

10.5  Antenna interface - general principles

The Iuant interface for the control of RET antennas or TMAs is a logical part of the NG-RAN.
The support of any standardised antenna interface technique shall not be prevented; e.g. AISG (Antenna interface standards group) specifications may be used.

11  Overall procedures in NG-RAN ArchitecureWord‑p. 74

11.1  Multiple TNLAs for Xn-C

In the following, the procedure for managing multiple TNLAs for Xn-C is described.
[not reproduced yet]
Figure 11.1-1: Managing multiple TNLAs for Xn-C.
Up
Step 1.
The NG-RAN node1 establishes the first TNLA with the NG-RAN node2 using a configured TNL address.
Step 2-3.
Once the TNLA has been established, the NG-RAN node1 initiates the Xn Setup procedure to exchange application level configuration data
Step 4-6.
The NG-RAN node2 may add additional TNL Endpoint(s) to be used for Xn-C signalling between the NG-RAN node1 and the NG-RAN node2 pair using the NG-RAN node Configuration Update procedure. NG-RAN node Configuration Update procedure also allows the NG-RAN node2 to request the NG-RAN node1 to modify or release TNLA(s).
Step 7-9.
The NG-RAN node1 may add additional TNL Endpoint(s) to be used for Xn-C signalling between the NG-RAN node1 and the NG-RAN node2 pair using the NG-RAN node Configuration Update procedure. NG-RAN node Configuration Update procedure also allows the NG-RAN node1 to request the NG-RAN node2 to modify or release TNLA(s).
The XnAP UE TNLA binding is a binding between a XnAP UE association and a specific TNL association for a given UE. After the XnAP UE TNLA binding is created, the NG-RAN node1 or the NG-RAN node2 can update the UE TNLA binding by sending the first available XnAP message for the UE to the peer NG-RAN node via a different TNLA. The peer NG-RAN node shall update the XnAP UE TNLA binding with the new TNLA.
Up

A  Deployment scenarios of gNB/en-gNBWord‑p. 76
Figure A-1 shows logical nodes (CU-C, CU-U and DU), internal to a logical gNB/en-gNB. Protocol terminations of the NG and Xn interfaces are depicted as ellipses in Figure A-1. The terms "Central Entity" and "Distributed Entity" shown in Figure A-1 refer to physical network nodes.
[not reproduced yet]
Figure A-1: Example deployment of an Logical gNB/en-gNB
Up

B  NG-RAN Architecture for Radio Access Network Sharing with multiple cell ID broadcast (informative)Word‑p. 77
Each gNB-DU serving a cell identified by a Cell Identity associated with a subset of PLMNs is connected to a gNB-CU via a single F1-C interface instance.
Each F1-C interface instance is setup individually.
F1-C interface instances terminating at gNB-DUs which share the same physical radio resources may share the same F1-C signalling transport resources. If this option is applied,
  • non-UE associated signalling is associated to an F1-C interface instance by allocating the corresponding Transaction ID from a value range associated to that F1-C interface instance.
  • node related, non-UE associated F1-C interface signalling may provide information destined for multiple logical nodes in a single F1AP procedure instance once the F1-C interface instance is setup.
  • a UE associated signalling connection is associated to an F1-C interface instance by allocating values for the corresponding gNB-DU UE F1AP ID and gNB-CU UE F1AP ID so that they can be mapped to that interface instance.
Interpreting the content of RRC MSG3 and other unciphered RRC message by the gNB-DU is supported.
Content for System Information Broadcast is assumed to be coordinated among the sharing PLMNs. PLMN specific SIB1 content is controlled by the respective PLMN owner. Non PLMN specific content needs coordination to avoid contradicting indication by PLMN specific gNB-CUs. For Warning messages (SIB6, SIB7 and SIB8), if provided by more than one gNB-CU, warning message duplicates are identified by provision of the Message Number and the Serial Number by the gNB-CU and don't trigger new broadcast or replace existing broadcast. Other coordination between gNB-CUs is ensured by appropriate implementation.
Up

$  Change HistoryWord‑p. 78

Up   Top