CDRX optimizations for Monolithic
Closes #452 (closed)
Merge request reports
Activity
added 22 commits
- 5f00b40e - asn1_msg.do_DrxConfig
- b01623f6 - cdrx_configured update
- 8ba41e82 - Status RRC-RECONFIGURED update
- 33d7dedd - rrc_eNB update 10/09
- 189393f6 - message-transfer-update
- f8c25858 - asn1_msg.do_DrxConfig
- 28a4d4f5 - cdrx_configured update
- 73a90bf6 - Status RRC-RECONFIGURED update
- cd6b19fa - rrc_eNB update 10/09
- 7e088701 - message-transfer-update
- 0bc7cf7c - comment cdrx
- ddc336e2 - asn1_msg.do_DrxConfig
- 020f0ef9 - cdrx_configured update
- 1740153f - Status RRC-RECONFIGURED update
- e0b3e4fb - rrc_eNB update 10/09
- 108aa728 - message-transfer-update
- 93abc6d9 - Merge branch 'orange_cdrx' of...
- 2ca45bb3 - [unbuilt] RRC Reconnection Complete for CU/DU done. Not done for monolithique
- 77115590 - [not built] CDRX CU/DU split ok, in case of mono still MAC code in RRC
- c107789e - [to test] CU/DU split supported
- 9c811d22 - Merge branch 'orange_cdrx' of...
- 206f17b2 - [under test] Fix CDRX starts at RRCReconfComplete again; new comments
Toggle commit list
Hello @Invalidname Louis-Adrien,
Thanks for this Merge Request.
I have a question: the F1 CU/DU fixes you made,
- (1) do they apply only to the CDRX context?
- (2) or are they generic F1-fixes?
If (1), do we need to add a test with CDRX and the CU/DU split?
Regards, Raphael
-
OAI RAN-CI-develop build (232): failed (https://open5glab.eurecom.fr:8083/jenkins/job/RAN-CI-develop/232/)
Hello @defosseu Raphaël,
The small "fixes" provided here are only for CDRX, so (1). So now it should work with CU/DU split, but I didn't look at the enb config file: is there anything to provide there (=> I would say it is a DU feature) ? It should work but I didn't test it on our testbench. I was planning to do it but no time at the moment. That is my next task.
Is the CI ok? It seems X2-HO failed.
You can add a test. The test can be the same as in case of monolithic. But there is no need to hurry.
If this works, I'm planning to add support for itti message in MAC. At the moment, RRC direclty calls MAC fonctions in case of monolithic and that is no good.
Thanks and regards! LA
Edited by Louis-Adrien DUFRENE
399 400 LTE_DRB_ToReleaseList_t *DRB_ReleaseList = rrcConnectionReconfiguration_r8->radioResourceConfigDedicated->drb_ToReleaseList; 400 401 LTE_MAC_MainConfig_t *mac_MainConfig = NULL; 402 401 403 for (i = 0; i< 8; i++){ 402 404 DRB2LCHAN[i] = 0; 403 405 } 404 if (rrcConnectionReconfiguration_r8->radioResourceConfigDedicated->mac_MainConfig) 406 407 if (rrcConnectionReconfiguration_r8->radioResourceConfigDedicated->mac_MainConfig) { 405 408 mac_MainConfig = &rrcConnectionReconfiguration_r8->radioResourceConfigDedicated->mac_MainConfig->choice.explicitValue; 409 410 /* CDRX Configuration */ 411 // Need to check if UE is a BR UE 412 int UE_id = find_UE_id(ctxt.module_id, ctxt.rnti); 413 414 if (UE_id != -1) { -
This looks good to me, but wouldn't it be nicer to put this block in a function within the MAC and call it from here? It would then also be possible to call it from the RRC and structure this function better, e.g. instead of doing
if (user) { if (no TDD) { ... } else { error(); } } else { error() }write
if (!user) { error(); return; } if (TDD) { error(); return; } ...which I perceive to be clearer...
Edited by Robert Schmidt changed this line in version 2 of the diff
602 645 603 646 } 604 647 605 int DU_send_UL_RRC_MESSAGE_TRANSFER(instance_t instance, const f1ap_ul_rrc_message_t *msg) { 648 int DU_send_UL_RRC_MESSAGE_TRANSFER(instance_t instance, 649 const f1ap_ul_rrc_message_t *msg) 650 { -
I think this change has been made to respect the style guide, but shouldn't the opening brace
{not on the same line of the closing parenthesis)?Edited by Robert Schmidt changed this line in version 2 of the diff
312 312 if (ue_context_p->ue_context.Status != RRC_RECONFIGURED) { 313 313 LOG_E(RRC,"[eNB %d] Received C-RNTI ,but UE %x status(%d) not RRC_RECONFIGURED\n",module_idP,rntiP,ue_context_p->ue_context.Status); 314 314 return (-1); 315 } else { 316 rrc_eNB_generate_defaultRRCConnectionReconfiguration(&ctxt,ue_context_p,0); 317 ue_context_p->ue_context.Status = RRC_RECONFIGURED; 318 } 315 } 316 rrc_eNB_generate_defaultRRCConnectionReconfiguration(&ctxt,ue_context_p,0); -
@Invalidname @defosseu I had a look and it looks fine to me. Maybe we can have a function to "install" CDRX in the MAC that is called from both the RRC and F1?! Apart from this I only have minor nitpicks...
Edited by Robert Schmidt -
@schmidtr Thanks Robert for the review, I agree with your remarks. Next week I will have some time to work on that, so I will keep you up to date
-
Ok I could test it on our testbench. The CDRX is not configured do to UE capabilities information missing at the DU.
I will work on that this afternoon, I think there are some information that should stay in CU...
Edited by Louis-Adrien DUFRENE -
It seems that the F1 interface handles the CDRX configuration directly through UE Context Management messages.
This is not completely implemented in OAI.
My next steps are:
- improve the code in case of monolithic (ITTI MAC)
- provide these improvements in case of CU/DU split (thanks to the rrc message handling)
- use the F1 ue context management messaging
added 23 commits
-
206f17b2...4f55943b - 17 commits from branch
develop - 34f0bdac - [to build] Monolithic: move RRC features in do_drxconfig
- eddc13d2 - [to build] Check coverage extension through UE capabilities
- d1f54a98 - [to test] Check CE from UECap and TDD from RRC config
- 3187127b - [to test] Improvements added to F1AP interface (no UE management messaging)
- 2306428e - Merge branch 'develop' into orange_cdrx
- 940ce3fe - [tested] comment update
Toggle commit list-
206f17b2...4f55943b - 17 commits from branch
-
In the last commit:
- Merge last develop.
- I improved the IE generation in monolithic and CU/DU split. Current version should be cleaner.
- Now I check if the UE supports coverage extension (CE) based on UE capabilities, since the current CDRX implementation doesn't support UE in CE. I don't know if there is a better way to look deeply into the UE capability structure.
- I tested on my testbed: CDRX configuration is ok in Monolithic and CU/DU. I also checked that the CE in UE capabilities is correctly handled by the new code.
The current code does not use the F1AP UE context management messaging. I have to look at the spec to determine the correct behavior.
As it is I will remove WIP to see if the CI CDRX test passes.
Next step: To configure the CDRX timers in MAC, we use the function eNB_Config_Local_DRX(). This function is called in RRC. It seems that the usual way for RRC to configure MAC is to call rrc_mac_config_req_eNB() directly from MAC (config.c). This function is inconvenient, with 38 input parameters, LTE_RRC_VERSION macro within the parameters and most of the time almost all parameters are set to 0 or NULL...
Also, other configurations are usually done through ITTI, but in the case of RRC it directly calls these configuration functions (pdcp, rlc, mac).
I would like to add an ITTI message that configures at reception only the CDRX timers of a UE.
Maybe there is a reason why ITTI is not used in this case? Maybe other parameters configuration of rrc_mac_config_req_eNB() should be handle thanks to ITTI messaging?
@florian.kaltenberger : Florian, I add you to the conversation, especially for the ITTI question, but others remarks are welcome :)
Edited by Louis-Adrien DUFRENE