vehicle_signal_specification
vehicle_signal_specification copied to clipboard
COVESA
Connectivity Enhancements
Connectivity Enhancements
This is my first draft for enhancements to the rather barebones connectivity spec.
Important note: This spec uses units defined in https://github.com/COVESA/vss-tools/pull/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.
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
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
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
e.g. you have vehicle + personal in this case https://www.press.bmwgroup.com/global/article/detail/T0341435EN/bmw-group-and-vodafone-integrate-5g-and-personal-esim-networking-into-a-vehicle-for-the-first-time?language=en
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.
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:
- Discussion on whether to be considered part of "vehicle" or not, how deep to go
- Please review/discuss within this PR, big change so 2 weeks for review, decision how to proceed Feb 21st
- Also review https://github.com/COVESA/vss-tools/pull/207, could possibly be merged earlier
- (Build error is due to vss-tools PR dependency)
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:
| RAT Types | Values (Decimal) |
|---|---|
| (reserved) | 0 |
| UTRAN | 1 |
| GERAN | 2 |
| WLAN | 3 |
| GAN | 4 |
| HSPA Evolution | 5 |
| EUTRAN (WB-E-UTRAN) | 6 |
| Virtual | 7 |
| EUTRAN-NB-IoT | 8 |
| LTE-M | 9 |
| NR | 10 |
| WB-E-UTRAN(LEO) | 11 |
| WB-E-UTRAN(MEO) | 12 |
| WB-E-UTRAN(GEO) | 13 |
| WB-E-UTRAN(OTHERSAT) | 14 |
| EUTRAN-NB-IoT(LEO) | 15 |
| EUTRAN-NB-IoT(MEO) | 16 |
| EUTRAN-NB-IoT(GEO) | 17 |
| EUTRAN-NB-IoT(OTHERSAT) | 18 |
| LTE-M(LEO) | 19 |
| LTE-M(MEO) | 20 |
| LTE-M(GEO) | 21 |
| LTE-M(OTHERSAT) | 22 |
| (spare) | 23-255 |
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:
| Technical Name | Marketing Name |
|---|---|
| GERAN | 2G (also known as GSM) |
| UTRAN | 3G |
| HSPA Evolution | 3.5G (for want of a better phrase!) - essentially 3G but faster and more power efficient |
| EUTRAN | 4G |
| NR | 5G |
| LTE-M | 4G Machine-to-Machine (M2M) communication (see https://en.wikipedia.org/wiki/LTE-M) |
| NB-IoT | Narrow-band IoT access (see https://en.wikipedia.org/wiki/Narrowband_IoT) |
| LEO/MEO/GEO/OTHERSAT | Satellite (Low Earth Orbit, Medium Earth Orbit, Geo-stationary Earth Orbit) |
| GAN | Generic Access Network - generally not used any more. See WLAN instead. |
| WB | Wide-Band |
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:
- The comment from Nick above is discussed
- Please discuss/comment on how detailed information you need for your organization.
- Nick: Proposal to start on high level, define names like
Cellular.2G,Cellular.3G, and so on then we can add finer ones likeCellular.3G.UTRANas needed
Hello, just wanted to update that I have not forgotten about this, and will be revising it soon. Simply very busy lately!
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!
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.
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.
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?
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.
My use-case basically just requires the type of network, data usage and cycle, and signal strength. Everything else is largely irrelevant for us.
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.
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.
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).
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?
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.
My use-case basically just requires the type of network, data usage and cycle, and signal strength. Everything else is largely irrelevant for us.
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.
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