Doc changes for F release O1 enhancements
[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, 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 - Thread 7: EGTP Handler
42
43 - Thread 8: O1
44
45 O-DU High Modules
46 --------------------------
47
48 DU APP 
49 ^^^^^^^^^^^^^^^^^^
50 This module configures and manages all the operations of O-DU.
51 It interfaces with external entities as follows:
52
53 - OAM:  DU APP interacts with OAM on the O1 interface for configuration, alarms and performance management.
54
55 - 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.
56
57 - RIC: DU APP interacts with RIC on E2 interface over SCTP.
58
59
60 DU App submodules are as follows:
61
62 - Config Handler manages the configurations received on O1 interfaces and stores them within DU APP context.
63
64 - DU Manager handles all cell operations at the DU APP.
65
66 - UE Manager handles UE contexts at the DU APP.
67
68 - SCTP handler is responsible for establishing SCTP connections with O-CU, RIC on the F1AP and E2AP interfaces
69   respectively.
70
71 - EGTP handler is responsible for establishing EGTP connection with O-CU for data message exchange on the F1-U
72   interface.
73
74 - ASN.1 Codecs contain ASN.1 encode/decode functions which are used for System information, F1AP and E2AP messages.
75
76 5G NR RLC
77 ^^^^^^^^^^^^^^^^^^
78 This module provides services for transferring the control and data messages
79 between MAC layer and O-CU (via DU App).
80
81 5G NR RLC UL and 5G NR RLC DL are the sub modules of this module that implement
82 uplink and downlink functionality respectively. 
83
84 5G NR MAC
85 ^^^^^^^^^^^^^^^^^^
86 This module uses the services of the NR physical layer to send and receive data
87 on the various logical channels.
88 Functions of the 5G NR MAC module are as follows:
89
90 - 5G NR MAC is responsible for multiplexing and de-multiplexing of the data on various logical channels.
91
92 - 5G NR SCH schedules resources in UL and DL for cell and UE based procedures.
93   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.
94
95 - Lower MAC interfaces between the MAC and the O-DU Low. It implements all the messages of FAPI
96   specification. It has a receiver thread to handle messages from L1.
97
98
99 O-DU Utility and Common Functions
100 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
101 These modules contain platform specific files and support O-DU High functionality and message exchanges.
102
103
104 O1 Module
105 ^^^^^^^^^^
106
107 .. figure:: ODU-O1-Arch.jpg
108   :width: 554
109   :alt: Figure 2 O1 Architecture
110
111   Figure 2 - O1 Architecture 
112
113 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. 
114
115 O1 architecture has following components:
116
117 - Netconf Session Handler: Subscribe to Netconf YANG modules and events. Register callback handler methods.
118
119 - VES Agent : Sends the VES events to SMO
120
121 - Alarm Manager: Stores and manages(add/updated/delete) alarms.
122
123 - Alarm Interface : Provides an interface to O-DU High threads for sending the alarm messages to O1 module over Unix socket.
124
125 - Config Interface : Interface to handle the configurations sent from SMO to the stack
126
127 - Netopeer server: Serves the northbound SMO/OAM Netconf requests.
128
129
130 O-DU-High Interfaces
131 ======================
132
133
134 This section describes the other modules that O-DU High interfaces with, as shown in below diagram.
135
136 .. figure:: O-DUHighInterfaces.jpg
137   :width: 600
138   :alt: O-DU High Interfaces
139
140   Figure 3 - O-DU High Interfaces
141
142
143 As shown in Figure 3, O-DU High interfaces with the following modules:
144
145 - O-CU: O-DU High communicates with O-CU on the F1AP interface. The control message exchanges are on F1-C while
146   data message exchanges are on F1-U interfaces. The below F1AP messages on F1-C are implemented, as per
147   3GPP 38.473-f60 v15.3:
148
149   - Interface Management
150
151     - F1 Setup
152
153     - gNB-DU Configuration Update
154
155     - F1 Reset
156
157     - PAGING
158
159   - UE Context Management 
160
161     - UE Context Setup
162
163     - UE Context Modification
164
165     - UE Context Release
166
167   - RRC Message Transfer
168                 
169     - Initial UL RRC Message Transfer
170
171     - DL RRC Message Transfer
172
173     - UL RRC Message Transfer
174
175     - RRC Delivery Report
176
177 - Near RT RIC: O-DU High communicates with Near RT RIC on the E2 interface. The below E2AP messages are
178   implemented, as per ORAN WG3.E2AP v02.00:
179
180   - Global Procedures
181
182     - E2 Setup
183
184     - E2 Node Configuration Update 
185
186   - Near RT RIC Functional Procedures
187                 
188     - RIC Subscription
189
190     - RIC Indication
191
192 - O-DU Low: O-DU High communicates with O-DU Low on the FAPI interface. The below FAPI messages are supported, 
193   as per FAPI interface files shared by Intel:
194
195   - P5 messages - PHY mode control interface
196         
197     - PARAM.request/PARAM.response
198
199     - CONFIG.request/CONFIG.response
200
201     - START.request
202
203     - STOP.request
204
205     - STOP.indication
206
207   - P7 messages - Main data path interface
208
209     - DL_TTI.request
210
211     - UL_TTI.request
212
213     - SLOT.indication
214
215     - UL_DCI.request
216
217     - TX_Data.request
218
219     - RX_Data.indication
220
221     - CRC.indication
222
223     - UCI.indication
224
225     - RACH.indication
226
227 - OAM: O-DU High communicates with OAM on the O1 interface.
228
229
230
231 O-DU High functionality
232 ========================
233
234
235 Cell Up and Broadcast Procedure
236 --------------------------------
237
238 This section describes the cell-up procedure within O-DU High.
239
240 .. figure:: CellUpAndBroadcast.png
241   :width: 720
242   :alt: Cell Up and Broadcast Procedure
243
244   Figure 4 - O-DU High Cell Up and Broadcast Procedure
245
246
247 As seen in the Figure 4,
248 - If O1 interface is enabled, SMO sends cell configuration to DU APP. DU APP stores the configurations in its local database.
249
250 - If O1 interface is disabled, DU APP module uses static configuration.
251
252 - 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.
253
254 - The O-CU responds with F1 Setup Response. This message contains a list of cells which must be activated.
255
256 - The O-DU High scans the list of cells received and sends corresponding cell configurations to 5G NR MAC.
257
258 - 5G NR MAC, in-turn configures the 5G NR SCH. It also configures the O-DU Low via the Lower MAC module.
259
260 - On receiving the cell config response, DU APP sends a gNB DU Config Update towards the O-CU. The O-CU responds with
261   gNB DU Config Update ACK towards the O-DU High.
262
263 - The DU APP now exchanges F1 Reset message with the O-CU to initialize the UE contexts.
264
265 - 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
266   Low.
267
268 - On receiving START.request, O-DU Low begins to send slot indications towards 5G NR MAC via the lower MAC.
269   The frequency of these slot indications is determined by the numerology(Mu) supported.
270   5G NR MAC forwards these slot indications to the 5G NR SCH and DU APP modules.
271
272 - When the first slot indication reaches the DU APP, cell is marked as up. If O1 is enabled, DU APP triggers an alarm to SMO to indicate the CELL is UP.
273
274 - The 5G NR SCH, keeps tracking the SSB and SIB1 ocassions on receiving regular slot indications. 
275   On detecting the relevant ocassion, 5G NR SCH schedules SSB/SIB1 and forwards the DL Scheduling Information to 5G NR MAC.
276
277 - The 5G NR MAC mutiplexes the PDU and sends SSB/SIB1 packets towards the O-DU Low through the Lower MAC.
278
279
280
281 UE Related Procedure
282 -----------------------
283
284
285 The O-DU High supports 
286
287 - All physical channels - PBCH, PRACH, PDCCH, PDSCH, PUSCH, PUCCH
288
289 - All control logical channels - UL CCCH, DL CCCH, UL DCCH, DL DCCH
290
291 - All control transport channels - BCH, UL-SCH, DL-SCH, RACH
292
293 The above channels are used to achieve the below messages:
294
295 - Cell broadcast of System Information which includes SSB and SIB1.
296
297 - RACH Procedure
298
299   - RACH Indication
300
301   - Random Access Response
302
303   - RRC Setup Request
304
305   - RRC Setup
306
307 - UE attach signalling flow
308
309   - RRC Setup Complete
310
311   - Registraton Request
312
313   - Security Mode Command
314
315   - Security Mode Complete
316
317   - Registraton Accept
318
319   - Registraton Complete
320
321   - Several NAS Message Exchanges
322
323   - RRC Reconfiguration
324
325   - RRC Reconfiguration Complete
326
327 Figure 5 below depicts the above call flow, inclusive of all interfaces:
328
329 .. figure:: UeAttach.png
330   :width: 800
331   :alt: O-DU High UE Attach Flow
332
333   Figure 5 - UE Attach Flow
334
335 - UE Release Signalling flow
336
337   - RRC Release
338
339 Closed Loop Automation Procedure
340 -----------------------------------
341
342 This section describes the closed loop automation procedure within O-DU High.
343
344 .. figure:: CLA_call_flow.png
345   :width: 720
346   :alt: Closed Loop Automation Procedure
347
348   Figure 6 - O-DU High Closed Loop Automation Procedure
349
350
351 1. SMO commands ODU-High to bring the cell down via O1 interface.
352
353 2. DU-APP module of ODU-High sends GNB-DU configuration update message to O-CU. It contains the details of cell to be deleted. O-CU acknowledges this message by sending GNB-DU configuration update acknowledgment.
354
355 3. For each UE, DU APP sends UE Context Release Request to O-CU with information about the to be released. O-CU responds with UE Context Release request. It contains the RRC release message. O-DU high sends this RRC Release message to UE.
356    
357 4. DU APP then sends UE delete request to MAC and RLC. Once a confirmation is received from both MAC and RLC, DU APP deletes UE from its own database as well.
358
359 5. Once all UEs are released, O-DU High sends STOP.Request to L1. L1 responds with stop indication.
360
361 6. Once cell has stopped, DU APP sends cell delete request to MAC. On receiving confimation from MAC, DU APP deletes cell information from its own database as well and sends UE Context Release Complete.
362
363 7. On receiving cell bring up command from SMO, the complete Cell bring up and UE attach procedure will be repeated (as explained in above sections)
364
365
366 O1 Netconf get-alarm list procedure
367 -----------------------------------
368
369 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.
370
371
372 .. figure:: ODU-O1-GetAlarmListFlow.jpg
373   :width: 869
374   :alt: Figure 6 O1 get alarm-list flow  
375
376   Figure 7 - O1 get alarm-list flow
377
378 As seen in the Figure 7,
379
380 - 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.
381
382 - 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.
383
384 - Alarm Manager stores the alarm data in a list.
385
386 - 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.
387
388 - The callback function fetches the alarm list from Alarm Manager and sends it back to the client (SMO/OAM) via  Netconf interface. 
389
390
391 Network Slicing procedure
392 --------------------------
393
394 This section describes the Network Slicing feature within O-DU High.
395
396
397 .. figure:: Network_Slicing.png 
398   :width: 869
399   :alt: Network Slicing flow
400
401   Figure 8 -  Network Slicing flow
402
403 As seen in the Figure 8,
404
405 - Once the Cell is UP, Slice Configuration received from O1 to O-DU is processed. DU APP forwards the Slice Configuration Request towards MAC which is further forwarded to Scheduler.
406
407 - Scheduler stores the Slice Configuration in DB and sends the Slice Configuration Response for each Slice to MAC and further towards DU APP. Slice Configuration Procedure completes.
408
409 - Once a UE attaches and PDU session is established then RLC will periodically calculate the Slice Performance Metrics(UL and DL Throughput) for slices configured during UE Context Setup/Modification procedure.
410
411 - RLC sends the Consolidated Slice Metrics to DU APP at every 60 sec duration. This is further forwarded towards SMO/Non-RT RIC.
412
413 - SMO/Non-RT RIC analyses these metrics and may optimize the slice configuration(RRM Policies) for dedicated slice. This is received at MAC and Scheduler as Slice Reconfiguration Request from DU APP.
414
415 - Scheduler updates the received Slice Configuration in its DB and sends back the Slice Reconfiguration Response to MAC and further MAC forwards it to DU APP. Scheduler applies the optimized RRM policies for the dedicated slice.
416
417
418 Idle Mode Paging procedure
419 ---------------------------
420
421
422 This section describes the Idle Mode Paging procedure within O-DU High.
423
424
425 .. figure:: IDLE_mode_Paging.jpg
426   :width: 869
427   :alt: Idle Mode Paging flow
428
429   Figure 9 -  Idle Mode Paging flow
430
431 As seen in the Figure 9,
432
433 - When a Paging is received from CU and the Cell to be Paged is UP then DU APP will calculate Paging Frame(PF) and i_s(Index of Paging Ocassion/Slot) and groups the Paging of UEs falling on same PF/SFN together and stores in its Cell's Databse.
434
435 - When a Slot Indication for SFN is received then DU APP extracts the Paging of all UEs whose PF is ahead by PAGING_DELTA and builds Paging RRC PDU. DU APP sends the same via DL PCCH Indication to MAC.
436
437 - MAC forwards to SCH as PAGING INDICATION.
438
439 - SCH stores the Page Message in its DB and when the SLOT_INDICATION for that SFN arrives, SCH performs scheduling and resource allocation for PDCCH (alongwith DCI 1_0 format) and PDSCH channels and sends to MAC through DL PAGING ALLOCATION message.
440
441 - MAC forwards the PAGE to PHY in TX_Data.Request.
442
443 OSC Testcases Supported
444 =========================
445
446 The O-DU High partially supports below use-cases:
447
448 - Traffic Steering
449
450 - Health Check
451
452