Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 38.401  Word version:  17.1.1

Top   Top   Up   Prev   Next
1…   5…   6…   6.1.4   6.1.5…   6.2…   7…   8…   8.2…   8.2.2…   8.2.3…   8.2.4   8.2.5   8.3…   8.4…   8.4.4…   8.5…   8.9…   8.9.4…   8.9.6…   8.9.7…   8.10   8.11…   8.12…   8.13…   8.14…   8.15…   8.16…   8.17…   8.17.3…   8.17.4   8.18…   8.19…   8.19.2   8.19.3   8.19.4…   9…   A…

 

9  Synchronizationp. 115

9.1  gNB Synchronizationp. 115

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 interfacesp. 116

10.1  NG interfacep. 116

TS 38.410 specifies NG interface general aspects and principles.

10.2  Xn interfacep. 116

TS 38.420 specifies Xn interface general aspects and principles.

10.3  F1 interfacep. 116

TS 38.470 specifies F1 interface general aspects and principles.

10.4  E1 interfacep. 116

TS 38.460 specifies E1 interface general aspects and principles.

10.5  Antenna interface - general principlesp. 116

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 Architecurep. 117

11.1  Multiple TNLAs for Xn-Cp. 117

In the following, the procedure for managing multiple TNLAs for Xn-C is described.
Reproduction of 3GPP TS 38.401, Fig. 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

Up   Top   ToC