Tech-invite3GPPspaceIETF RFCsSIP

Content for  TS 38.401  Word version:  17.1.1

Top   Top   Up   Prev   None
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…


A  Deployment scenarios of gNB/en-gNBp. 118

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.
Reproduction of 3GPP TS 38.401, Fig. A-1: Example deployment of an Logical gNB/en-gNB

B  NG-RAN Architecture for Radio Access Network Sharing with multiple cell ID broadcast (informative)p. 119

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.

$  Change Historyp. 120

Up   Top