Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MCPTT access time values in private calls #19

Open
SAAFISalwa opened this issue Jan 22, 2021 · 2 comments
Open

MCPTT access time values in private calls #19

SAAFISalwa opened this issue Jan 22, 2021 · 2 comments

Comments

@SAAFISalwa
Copy link

SAAFISalwa commented Jan 22, 2021

Hello,

I wanted to compare the average MCPTT access time values in private calls in three different coverage and sidelink mode scenarios (i.e., in-coverage UEs with sidelink mode-1, in-coverage UEs with sidelink mode-2, and out-of-coverage UEs with sidelink mode-2).

I found that in in-coverage UEs with sidelink mode-1 and out-of-coverage UEs with sidelink mode-2 scenarios, the average access time values are around 80 ms (for a sidelink period of 40 ms). However in the in-coverage UEs with sidelink mode-2 scenario, the average values are around 500 ms for the same sidelink period.

Is there an explanation for this gap that can be related to sidelink configurations?

Thanks in advance for your thoughts.

PS: for in-coverage UEs with sidelink mode-2 and out-of-coverage UEs with sidelink mode-2, I used the "Fixed" scheduling method with the same KTRP, MCS, and RB size values.

@wdgj
Copy link
Collaborator

wdgj commented Jan 22, 2021

Hi,

It sounds like for the in-coverage/mode-1 and out-of-coverage/mode-2 scenarios the 80 ms is as expected for simple request-response.

However, for in-coverage/mode-2 a 500 ms access time is possible when there is a considerable amount of loss. So the first thing you could check and compare are the "mcptt-msg-trace.txt" trace files to see if this is true. Also, for both mode-2 scenarios, what is the difference that makes your UEs either in-coverage or out-of-coverage with your scenario definition?

@SAAFISalwa
Copy link
Author

Hi,

Ok, thanks. I will check the trace files.

Well, in terms of scenario definition, the main difference between the two scenarios you mentioned is that since there is no eNB in the out-of-coverage situation then channel setup (freq and PLM mainly) and initialization should be performed explicitly in the scenario.

Before running the simulations, I thought that the two scenarios with sidelink mode-2 will have approximately the same results but after I got different ones that's when I started questioning about the possible impact of the network coverage presence (i.e., eNB definition).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants