PNF Registration to be sent after odu stack is up
[o-du/l2.git] / docs / overview.rst
1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
2 .. SPDX-License-Identifier: CC-BY-4.0
3
4
5 O-DU High Overview
6 *********************
7
8 O-DU High Architecture
9 ======================
10
11 O-DU implements the functional blocks of L2 layer of a 5G NR protocol stack in SA(StandAlone) mode.
12 These layers primarily include NR MAC, NR Scheduler and NR RLC layers.
13
14 O-DU modules are developed as shown in the below diagram.
15
16 .. figure:: ODUArch.jpg
17   :width: 600
18   :alt: Figure 1 O-DU High Architecture Diagram
19
20   Figure 1 - O-DU High Architecture Diagram
21
22 O-DU High Thread Architecture
23 -------------------------------
24
25 As shown in Figure 1, there are multiple entities within O-DU High. Modules sharing a
26 given color belong to one thread. O-DU architecture can be defined at a thread
27 level as follows:
28
29 - Thread 1: O-DU thread
30
31 - Thread 2: DU APP inclusive of Config Handler, DU Manager, UE Manager, EGTP Handler and ASN.1 Codecs
32
33 - Thread 3: 5G NR RLC DL and MAC (inclusive of 5G NR SCH and Lower MAC)
34
35 - Thread 4: 5G NR RLC UL
36
37 - Thread 5: SCTP Handler
38
39 - Thread 6: Lower MAC Handler
40
41
42 O-DU High Modules
43 --------------------------
44
45 DU APP 
46 ^^^^^^^^^^^^^^^^^^
47 This module configures and manages all the operations of O-DU.
48 It interfaces with external entities as follows:
49
50 - OAM:  DU APP interacts with OAM on the O1 interface for configuration, alarms and performance management.
51
52 - O-CU: DU APP interacts with O-CU for RAN functionalities over the F1 interface which is built on SCTP. Control messages are exchanged on the F1-C interface and data messages on the F1-U interface.
53
54 - RIC: DU APP interacts with RIC on E2 interface over SCTP.
55
56
57 DU App submodules are as follows:
58
59 - Config Handler manages the configurations received on O1 interfaces and stores them within DU APP context.
60
61 - DU Manager handles all cell operations at the DU APP.
62
63 - UE Manager handles UE contexts at the DU APP.
64
65 - SCTP handler is responsible for establishing SCTP connections with O-CU, RIC on the F1AP and E2AP interfaces
66   respectively.
67
68 - EGTP handler is responsible for establishing EGTP connection with O-CU for data message exchange on the F1-U
69   interface.
70
71 - ASN.1 Codecs contain ASN.1 encode/decode functions which are used for System information, F1AP and E2AP messages.
72
73 5G NR RLC
74 ^^^^^^^^^^^^^^^^^^
75 This module provides services for transferring the control and data messages
76 between MAC layer and O-CU (via DU App).
77
78 5G NR RLC UL and 5G NR RLC DL are the sub modules of this module that implement
79 uplink and downlink functionality respectively. 
80
81 5G NR MAC
82 ^^^^^^^^^^^^^^^^^^
83 This module uses the services of the NR physical layer to send and receive data
84 on the various logical channels.
85 Functions of the 5G NR MAC module are as follows:
86
87 - 5G NR MAC is responsible for multiplexing and de-multiplexing of the data on various logical channels.
88
89 - 5G NR SCH schedules resources in UL and DL for cell and UE based procedures.
90   5G NR SCH is completely encapsulated within the 5G NR MAC i.e., all interactions of the 5G NR SCH is via the 5G NR MAC.
91
92 - Lower MAC interfaces between the MAC and the O-DU Low. It implements all the messages of FAPI
93   specification. It has a receiver thread to handle messages from L1.
94
95
96 O-DU Utility and Common Functions
97 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
98 These modules contain platform specific files and support O-DU High functionality and message exchanges.
99
100
101 O1 Module
102 ^^^^^^^^^^
103
104 .. figure:: ODU-O1-Arch.jpg
105   :width: 554
106   :alt: Figure 2 O1 Architecture
107
108   Figure 2 - O1 Architecture 
109
110 As shown in figure 2 the O1 module runs as a thread in O-DU High. Alarm communication happens over a Unix socket between the O1 and O-DU threads. O1 module uses API calls for interacting with the Netconf server(Netopeer) and datastore(sysrepo) for providing the Netconf interface. 
111
112 O1 architecture has following components:
113
114 - Netconf Session Handler: Subscribe to Netconf YANG modules and events. Register callback handler methods.
115
116 - VES Agent : Sends the VES events to SMO
117
118 - Alarm Manager: Stores and manages(add/updated/delete) alarms.
119
120 - Alarm Interface : Provides an interface to O-DU High threads for sending the alarm messages to O1 module over Unix socket.
121
122 - Config Interface : Interface to handle the configurations sent from SMO to the stack
123
124 - Netopeer server: Serves the northbound SMO/OAM Netconf requests.
125
126
127 O-DU-High Interfaces
128 ======================
129
130
131 This section describes the other modules that O-DU High interfaces with, as shown in below diagram.
132
133 .. figure:: O-DUHighInterfaces.jpg
134   :width: 600
135   :alt: O-DU High Interfaces
136
137   Figure 3 - O-DU High Interfaces
138
139
140 As shown in Figure 3, O-DU High interfaces with the following modules:
141
142 - O-CU: O-DU High communicates with O-CU on the F1AP interface. The control message exchanges are on F1-C while
143   data message exchanges are on F1-U interfaces. The below F1AP messages on F1-C are implemented, as per
144   3GPP 38.473-f60 v15.3:
145
146   - Interface Management
147
148     - F1 Setup
149
150     - gNB-DU Configuration Update
151
152     - F1 Reset
153
154   - UE Context Management 
155
156     - UE Context Setup
157
158   - RRC Message Transfer
159                 
160     - Initial UL RRC Message Transfer
161
162     - DL RRC Message Transfer
163
164     - UL RRC Message Transfer
165
166     - RRC Delivery Report
167
168 - Near RT RIC: O-DU High communicates with Near RT RIC on the E2 interface. The below E2AP messages are
169   implemented, as per ORAN WG3.E2AP v01.00:
170
171   - Global Procedures
172
173     - E2 Setup
174
175   - Near RT RIC Functional Procedures
176                 
177     - RIC Subscription
178
179     - RIC Indication
180
181 - O-DU Low: O-DU High communicates with O-DU Low on the FAPI interface. The below FAPI messages are supported, 
182   as per FAPI interface files shared by Intel:
183
184   - P5 messages - PHY mode control interface
185         
186     - PARAM.request/PARAM.response
187
188     - CONFIG.request/CONFIG.response
189
190     - START.request
191
192     - STOP.request
193
194     - STOP.indication
195
196   - P7 messages - Main data path interface
197
198     - DL_TTI.request
199
200     - UL_TTI.request
201
202     - SLOT.indication
203
204     - UL_DCI.request
205
206     - TX_Data.request
207
208     - RX_Data.indication
209
210     - CRC.indication
211
212     - UCI.indication
213
214     - RACH.indication
215
216 - OAM: O-DU High communicates with OAM on the O1 interface.
217
218
219
220 O-DU High functionality
221 ========================
222
223
224 Cell Up and Broadcast Procedure
225 --------------------------------
226
227 This section describes the cell-up procedure within O-DU High.
228
229 .. figure:: CellUpAndBroadcast.png
230   :width: 720
231   :alt: Cell Up and Broadcast Procedure
232
233   Figure 4 - O-DU High Cell Up and Broadcast Procedure
234
235
236 As seen in the Figure 4,
237 - The DU APP module of O-DU High sends F1 Setup Request to O-CU. This message contains a list of cells that the O-DU High has been configured with.
238
239 - The O-CU responds with F1 Setup Response. This message contains a list of cells which must be activated.
240
241 - The O-DU High scans the list of cells received and sends corresponding cell configurations to 5G NR MAC.
242
243 - 5G NR MAC, in-turn configures the 5G NR SCH. It also configures the O-DU Low via the Lower MAC module.
244
245 - On receiving the cell config response, DU APP sends a gNB DU Config Update towards the O-CU. The O-CU responds with
246   gNB DU Config Update ACK towards the O-DU High.
247
248 - The DU APP now exchanges F1 Reset message with the O-CU to initialize the UE contexts.
249
250 - DU APP sends Cell Start Req towards 5G NR MAC. This message is translated by the Lower MAC into the FAPI message START.request towards the O-DU
251   Low.
252
253 - On receiving START.request, O-DU Low begins to send slot indications towards 5G NR MAC via the lower MAC.
254   The frequency of these slot indications is determined by the numerology(Mu) supported.
255   5G NR MAC forwards these slot indications to the 5G NR SCH and DU APP modules.
256
257 - When the first slot indication reaches the DU APP, cell is marked as up.
258
259 - The 5G NR SCH, keeps tracking the SSB and SIB1 ocassions on receiving regular slot indications. 
260   On detecting the relevant ocassion, 5G NR SCH schedules SSB/SIB1 and forwards the DL Scheduling Information to 5G NR MAC.
261
262 - The 5G NR MAC mutiplexes the PDU and sends SSB/SIB1 packets towards the O-DU Low through the Lower MAC.
263
264
265
266 UE Related Procedure
267 -----------------------
268
269
270 The O-DU High supports 
271
272 - All physical channels - PBCH, PRACH, PDCCH, PDSCH, PUSCH, PUCCH
273
274 - All control logical channels - UL CCCH, DL CCCH, UL DCCH, DL DCCH
275
276 - All control transport channels - BCH, UL-SCH, DL-SCH, RACH
277
278 The above channels are used to achieve the below messages:
279
280 - Cell broadcast of System Information which includes SSB and SIB1.
281
282 - RACH Procedure
283
284   - RACH Indication
285
286   - Random Access Response
287
288   - RRC Setup Request
289
290   - RRC Setup
291
292 - UE attach signalling flow
293
294   - RRC Setup Complete
295
296   - Registraton Request
297
298   - Security Mode Command
299
300   - Security Mode Complete
301
302   - Registraton Accept
303
304   - Registraton Complete
305
306   - Several NAS Message Exchanges
307
308   - RRC Reconfiguration
309
310   - RRC Reconfiguration Complete
311
312 Figure 5 below depicts the above call flow, inclusive of all interfaces:
313
314 .. figure:: UeAttach.png
315   :width: 800
316   :alt: O-DU High UE Attach Flow
317
318   Figure 5 - UE Attach Flow
319
320
321 O1 Netconf get-alarm list procedure
322 -----------------------------------
323
324 This section describes the *Health Status Retrieval* scenario of O-DU High health-check. It enables a northbound client(SMO) to retrieve the health of the O-DU High based on the last self-check performed. The alarm-list is provided as the response to the request via O1 Netconf interface.
325
326
327 .. figure:: ODU-O1-GetAlarmListFlow.jpg
328   :width: 869
329   :alt: Figure 6 O1 get alarm-list flow  
330
331   Figure 6 - O1 get alarm-list flow
332
333  
334 As seen in the Figure 6,
335
336 - On the cell state change from de-active to activate, DU APP module raises a cell up alarm message and sends it over the Unix socket using the Alarm Interface API.
337
338 - On other side a Unix socket server, running as a thread, in O1 module receives the cell up alarm message and it passes on the alarm information to the Alarm Manager.
339
340 - Alarm Manager stores the alarm data in a list.
341
342 - Whenever SMO/OAM requires the current alarm list, it sends a Netconf get request. The request is received by the Netopeer Server and a callback method, registered with the Session Handler, is invoked.
343
344 - The callback function fetches the alarm list from Alarm Manager and sends it back to the client (SMO/OAM) via  Netconf interface. 
345
346 OSC Testcases Supported
347 =========================
348
349 The O-DU High partially supports below use-cases:
350
351 - Traffic Steering
352
353 - Health Check
354
355