time_adv_nsamples: is static TA value for the ue once this parameter is set in the ue.conf file?

[mnagle2150]

Issue Description

I have a question more than an issue. When setting the timing_adv_nsamples value am I setting a static time length in number of radio samples that the ue will always use for timing advance or am I defining one timing advance unit time duration in number of radio samples?

Setup Details

USRP B210 as UE. So, when the ue receives the TA command inside of the DL RAR message, is the ue using multiples of the 100 samples default setting to advance future UL traffic (ie if TA is commanded by the eNB to 2, does the UE use 200 samples as its timing advance)? Or, does the ue always use the 100 samples time length as its timing advance regardless of the TA commanded in the DL RAR?

Expected Behavior

Unknown

Actual Behaviour

Unknown

Steps to reproduce the problem

[Tell us how to reproduce this issue e.g. RF setup, application config files]

Additional Information

[Any additional information, configuration or data that might be necessary to reproduce the issue]

[pgawlowicz]

Hi, timing_adv_nsamples is a TX/RX offset in number of samples. However, it seems that there is a bug that makes the RAR TA to be cleared. Could you try to apply the following patch? fix_prach.patch.txt

I think it should be possible to keep timing_adv_nsamples=auto once the patch is applied.

[pgawlowicz]

@mnagle2150 any update on this issue? did you apply the patch?

[mnagle2150]

Sorry for the delay -- yes, the patch worked well. Utilizing small LNA's on the RF front ends and inducing some multi-path, I was able to simulate cell's edge conditions and obtain/maintain a stable ue attach at TA values of 9. Previously, beyond TA values of 3 or4, I experienced many failed RAR exchanges for the ue/eNb. Thanks for the assistance!

[mnagle2150]

Piotr,

I noticed that the patch only includes changes for the NR ue code. Is this not a problem for the LTE ue code as well?

Thanks

Mike

On Mon, Oct 7, 2024 at 5:43 AM Piotr @.***> wrote:

@mnagle2150 https://github.com/mnagle2150 any update on this issue? did you apply the patch?

— Reply to this email directly, view it on GitHub https://github.com/srsran/srsRAN_Project/issues/826#issuecomment-2396564892, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASLJJFFQDRXMSWVKPMMOWATZ2JQVDAVCNFSM6AAAAABOU6YUOKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJWGU3DIOBZGI . You are receiving this because you were mentioned.Message ID: @.***>

[mnagle2150]

Piotr,

I noticed that his patch only makes changes to the NR portion of the UE code. Does there need to be changes to the LTE UE portion of the code as well?

On Mon, Oct 7, 2024 at 5:43 AM Piotr @.***> wrote:

@mnagle2150 https://github.com/mnagle2150 any update on this issue? did you apply the patch?

— Reply to this email directly, view it on GitHub https://github.com/srsran/srsRAN_Project/issues/826#issuecomment-2396564892, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASLJJFFQDRXMSWVKPMMOWATZ2JQVDAVCNFSM6AAAAABOU6YUOKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJWGU3DIOBZGI . You are receiving this because you were mentioned.Message ID: @.***>

[womper25]

Hello @mnagle2150 , are you also using ZMQ-enabled srsUEs? If yes, may I ask how your UE configuration file looks like? I am trying to simulate channel conditions using GNU Radio Channel Block (using filter taps to emulate multipath effects), but the UE cannot connect to the gNB in the downlink direction. Do you have any recommendations to solve this issue?

Note: I already tried applying the patch but it still did not work.