Connectivity Enhancements #526
Conversation
| datatype: string[] | ||
| type: sensor | ||
| allowed: [ | ||
| '2G', |
There was a problem hiding this comment.
I think this datapoint is useful, but too generic, like 2G might be EDGE or even only GPRS, 3G could be HSUPA or HSDPA, 5G might be -SA or -NSA etc.
Maybe it might make sense to align to Android, not sure how to get a good List, but basically something like the getdatanetworktype() returns in TelephonyManager https://developer.android.com/reference/kotlin/android/telephony/TelephonyManager#getdatanetworktype
There was a problem hiding this comment.
Those might not always be represented to the user in a UI, but if you imagine some services deciding what to services can run, what to traffic shape etc. this information among others might be relevant. Toy example: If you do trickle downloads of software over cellular, maybe cellular, maybe with HSDPA (3G) and good signal strength you would do it, but with UMTS (3G) definitely not, or your user might have issues using connected navigation or off-board speech recognition.
There was a problem hiding this comment.
I actually agree, and that was the intended purpose of Cellular.NetworkSubtype on line 68 (I can't figure out how to link it, sorry). I didn't love having two of these, so maybe it does make sense to combine them. It was simply a daunting task to figure out a list for everything. I'll do a little further research and revisit this
spec/Vehicle/Connectivity.vspec
Outdated
| WiFi.NetworkType: | ||
| datatype: string[] | ||
| type: sensor | ||
| allowed: [ | ||
| '0', | ||
| '1', | ||
| '2', | ||
| '3', | ||
| '4', | ||
| '5', | ||
| '6', | ||
| '6e', | ||
| '7' | ||
| ] | ||
| description: Type of WiFi network that is currently in-use. |
There was a problem hiding this comment.
Sort of a similar situation with WiFi as well. WiFi version 5 could run over both 2.4Ghz or 5Ghz. Sometimes it really matters, so how could we incorporate that data? I simply chose not to for now, but happy to get feedback
There was a problem hiding this comment.
Here it would be good to include information on how types are defined, in description or a comment.
If the types are defined in a standard (ISO/SAE/...) we could mention that.
If not some other hopefully stable source, like wikipedia.
The important part is to show if we have invented the types or just using types that already have been defined by someone else.
spec/Vehicle/Connectivity.vspec
Outdated
| Cellular.DataUsage.CycleReset: | ||
| type: attribute | ||
| unit: day | ||
| datatype: uint16 | ||
| min: 0 | ||
| description: Time until the next data cycle starts. |
There was a problem hiding this comment.
I don't love this implementation, but I can't think of a simple alternative other than something like NextCycle, represented by a Unix timestamp.
There was a problem hiding this comment.
One could alternatively have "CycleStart" (as unix timestamp or ISO 8601 string). Together with CycleLength you then now when next reset should happen.
There was a problem hiding this comment.
I like that solution much better, and will implement it.
| Cellular.SignalStrength: | ||
| type: sensor | ||
| datatype: int8 | ||
| unit: dBm | ||
| description: Cellular connectivity signal strength. |
There was a problem hiding this comment.
This is defined as int8 (-128 to 127) for both WiFi and cellular. Given that dBm is a logarithmic scale, I didn't see a scenario where the signal strength could stray outside of this range, but it is a bit tight. Alternatively, would this be better as a percentage (0-100%)?
There was a problem hiding this comment.
We also have float as an option. Historically in VSS when selecting datatype we typically consider expected range and if decimal notation is required. If we see it unlikely that someone needs decimals for the given unit we select an int-type that fits what we see as a reasonable range. (What datatype that then is used in a real deployment could differ).
Concerning using percentage - In user interfaces you rarely see the absolute value but rather a relative value like number of "bars" where 4 bars may indicate excellent signal strength and 1 bar bad signal strength. But I do not know if there is any industry standard or convention converting between dBM and percentage/bars or if that is only in relationship to what the device expects. I.e. X dBM might mean 40% for one device but 20% for another device?
In the long run maybe we need both an absolute signal (dBM) and a relative signal (starts/bars/percent) as they might serve different purposes. Maybe the OEM want to collect absolute dBM values, but the HMI wants to show the relative value. If we start with absolute, if that fits your use case, we could always add relative later.
There was a problem hiding this comment.
I can see value to both absolute and relative, for sure. I think absolute could be useful for things like vehicle diagnostics and troubleshooting.
There isn't really a standard conversion between dBm and percentage, but I think most implementations are at least similar. Because actual connectivity drops off much faster at low connections, many companies actually choose to drop percentage faster as they get to the lower range, so it isn't always linear either. I think I'll revise this part to include both.
Also, I've never seen dBm measured in floats when working with real-world modems, so I'm not sure that is needed but can be changed if you guys think so.
| CurrentDownload: | ||
| datatype: float | ||
| type: sensor | ||
| unit: MiB/s | ||
| description: Download bandwidth currently in-use. | ||
|
|
||
| CurrentUpload: | ||
| datatype: float | ||
| type: sensor | ||
| unit: MiB/s | ||
| description: Upload bandwidth currently in-use. |
There was a problem hiding this comment.
There is an overall CurrentDownload and CurrentUpload, with the understanding that this would simply correspond to whatever ConnectivityType is in-use. This may not work if for some reason cellular and WiFi were blended, but this scenario is relatively complex so I wasn't sure if it was worth considering over a more simplistic model.
|
Hi @CorvetteCole - concerning way forward. If time permits I will briefly mention your work at the next VSS weekly (Tuesday 24th 16.00 CET, 10.00 AM EST, 1 hour). We do however have a quite big backlog for that meeting, but possibly we could have a somewhat longer discussion on connectivity at the meeting on the 31st. Feel free to join if you like, see details at https://github.com/COVESA/vehicle_signal_specification/wiki/Weekly-meeting#meeting |
|
I have it on my calendar already, I will tune in on the 24th, but no worries if it has to wait until the 31st as well |
|
Later we could add extension for multiple SIM cards. |
|
I could not make it to the meeting today but I can still join on the 31st. Dual-SIM support is interesting, although I've never seen that in a car |
|
Meeting notes: Please review, discussion planned for next week |
e.g. you have vehicle + personal in this case |
|
very interesting, thanks for the link. I wonder if that would be better as an overlay to add instances by the manufacturer. Or maybe we should set it up to be instanced. Doesn't seem like a common use-case, but I am not the most familiar with how VSS likes to handle these kinds of things. |
If we are doing this description it would be a lot easier to have perosonal-esim setup covered as well. But we can discuss this in one of the VSS calls. |
|
Meeting notes: Cole not present, discussion postponed to next week |
I was there at 9am EST which Google told me was equivalent to the 16:00 CEST listed in the wiki. Looking at the calendar (https://wiki.covesa.global/display/WIK4/COVESA+Common+Meeting+Schedule) it appears the time in EST is actually 10am. Again, my apologies for not being present due to the mix-up, I will be on next week. |
|
No problem, we will discuss it next week. The meeting is at 16.00 ( 4 PM) CET (UTC+1, Berlin, Copenhagen, ...). For US eastern standard time (UTC -5) that should if I calculate correct correspond to 10 AM. (7 AM is for pacific, UTC-8) (Then it gets even more complicated when we shift to/from summer time, as US and Europe shift at different dates, but that is a later problem) |
|
Meeting notes:
|
|
My apologies for the lack of communication... very busy lately. I will still be making the relevant changes hopefully within the next two weeks and we can bring it back up for discussion |
|
Per the meeting last week (7th March), I've dug out a reference to how the standards body who deal with cellular identify Radio Access Types (RATs). The specification where this is defined is 3GPP TS 29.274, specifically in subclause 8.17 ("RAT Type"). All versions of that spec are available here: https://www.3gpp.org/ftp/Specs/archive/29_series/29.274. I would suggest downloading the latest version so that you can see all of the latest radio access types that are supported (note: the latest ones support satellite access). The table of RATs in the latest version reads as follows:
Note that there is a difference in access names used in marketing, which you are likely familiar with, and the technical names used in the standard (which you are unlikely to be familiar with). Herewith a general mapping to help you understand these:
Depending on your use case, you might therefore just want to have simple access types of Cellular.2G, Cellular.3G, Cellular.4G, Cellular.5G, WLAN, Satellite. Also, if the vehicle is connected to the Internet via a vehicle user's phone, you might also want an access type of something like Tethered. In this case, it might not be possible to determine the access type that the tethered phone is connected to though. |
|
Meeting notes:
|
|
Hello, just wanted to update that I have not forgotten about this, and will be revising it soon. Simply very busy lately! |
|
Hi, @CorvetteCole any updates regarding the PR? Cheers |
|
update: I have been reworking this lately and will be pushing changes shortly. Will be taking a look around the repo to see what has changed since I started this. My apologies for my extended absence! |
erikbosch
added
the
Status:NoProgress
|
Alright, I've finally updated this. The part I'm a little unclear on, is how exactly @nickrbb thinks that these network types would be laid out in the spec. I totally support that, but I'm a little unclear the actual implementation behind having a Vehicle.Connectivity.Cellular.3G. Does each type have its own data usage, cycles, signal strength, carrier, etc? Maybe this should just be massively simplified? My use-case basically just requires the type of network, data usage and cycle, and signal strength. Everything else is largely irrelevant for us. Also, I think a valid question is what about a network that is connected but has no internet access? Especially for WiFi. I think the way I have laid this out probably need a major overhaul, and I'd like to reduce the scope to focus on an extremely reduced minimal use-case. |
|
@erikbosch I would be happy to join a meeting to discuss this! |
erikbosch
removed
the
Status:NoProgress
| @@ -78,3 +78,6 @@ relation: | |||
| resistance: | |||
| definition: Property of a resistive element, equal to the scalar | |||
| quantity given by the quotient of voltage u and electric current i (IEC 80000-6:2022) | |||
| data: | |||
| definition: TBD | |||
| data-per-time: | |||
There was a problem hiding this comment.
A definition needed here as well, and most likely a new line as well to make CI happy
There was a problem hiding this comment.
yes absolutely agree, I'm still getting this PR up to "merge-able" status, I'll fix this when I next have a chance
|
Hi! I will not join the VSS meeting tomorrow (Dec 12th 16.00 CET) but @adobekan will host it. If you have the possibility to join that could be a good chance to give a short recap on your ideas behind this PR. After the meeting tomorrow we will likely have a long break until mid January due to Christmas, New Year and CES. |
A network carrier (or mobile operator, as we call them in Europe) has one or more radio access network types (e.g. 2G, 3G, 4G, 5G). Each radio access network type has its own signal strength and also signal quality (the two are different, and you need decent amounts of both to get any throughput). Carriers/operators typically bill their customers by the overall data the customer uses across all of the carrier's/operator's radio access networks, consequently the megabytes consumed and the billing cycle are common amongst all radio types. However, I say "typical" in the above because it is possible (according to the 3GPP standards) to bill customers for data used on a per radio access network basis, and I have seen some do this in the past. Ultimately, it all depends on the contract the customer has.
Right. My point above was to have a common understanding of what each "type" actually means for someone trying to implement your signal, hence my referencing of the mobile standards and my attempt to simplify it in the second table. |
unfortunately I was not able to attend, but I will mid-January when meetings resume. That will be better since I should have some time to further flesh things out beforehand (been very busy, should ease up). |
Interesting insights. I think I need to review how to actually write the VSS spec a little closer to ensure I can add this in the way you describe it easily. Will come back to this soon |
erikbosch
added
the
Status:DoNotMerge
erikbosch
added
the
Status:NoProgress
Connectivity Enhancements
This is my first draft for enhancements to the rather barebones connectivity spec.
Important note: This spec uses units defined in COVESA/vss-tools#207.
Design
Fundamentally, I decided to start out with two "types" of connectivity - cellular and WiFi. Of course this can be expanded over time. The current connectivity type is defined, along with an overall current download and upload. The cellular and WiFi branches contain independent signals for signal strength along with network type (e.g. 2G 3G 4G). Outside of that, a few specific signals are defined for cellular and WiFi that are only applicable to them.
This should be relatively easy to extend over time, and provide a good base over the current spec.
Requests for Feedback
I have a few specific things I'd like feedback on or would like to point out:
1. CurrentDownload and CurrentUpload placement
There is an overall CurrentDownload and CurrentUpload, with the understanding that this would simply correspond to whatever ConnectivityType is in-use. This may not work if for some reason cellular and WiFi were blended, but this scenario is relatively complex so I wasn't sure if it was worth considering over a more simplistic model.
2. SignalStrength unit and data type
This is defined as int8 (-128 to 127) for both WiFi and cellular. Given that dBm is a logarithmic scale, I didn't see a scenario where the signal strength could stray outside of this range, but it is a bit tight. Alternatively, would this be better as a percentage (0-100%)?
3. Cellular.DataUsage.CycleReset
I don't love this implementation, but I can't think of a simple alternative other than something like NextCycle, represented by a Unix timestamp.
4. General naming, descriptions, commenting
I tried my best to adhere to what I saw in the rest of the spec, but this is my first time contributing and I am very new to this repo. I am unsure in places about signal names, descriptions, and comments. Please be very critical so that I can make sure this is up to standards. Thank you so much!
I expect there will be a fair few things to change here, which is why I am making this a draft PR for the time being.