Adding Collective Perception Messages (CPM) of ETSI TS 103 324 v2.1.1

[yuasabe]

Hello, thank you very much for the wonderful work of Vanetza.

As you may already know, the ETSI Technical Specification for the Collective Perception Service and its respective Collective Perception Message (CPM) format was released recently in June 2023.

I believe that the current CPM format supported in Vanetza is the TR 103 562 v2.1.1 version. Therefore, I was considering adding the ASN1 files for the newly updated TS-version of CPM as released in the ETSI Gitlab page.

As a dependency, the ETSI ITS Common Data Dictionary (CDD) will also need to be updated to ETSI TS 102 894-2 v2.1.1. I believe that the current version included in Vanetza is for ETSI TS 102 894-2 v1.3.1.

Please let me know if there are any works being done already to incorporate the newer CPMs, and if not, I would like to try opening a PR to add them.

As for the ASN1 compiler, I am currently planning on using https://github.com/mouse07410/asn1c

[riebl]

Hi @yuasabe,

I am not aware of anyone currently updating the CPM-related ASN.1 files in Vanetza. It would be great if you could submit such an update as a pull request. Please note that Vanetza also patches the files generated by asn1c on-the-fly. The asn1c version maintained by @mouse07410 should be fine.

[diogopjesus]

Hi @riebl and @yuasabe,
I also wanted to use the CPM format according to ETSI TS 103 324 v2.1.1.
For that, i removed the old CDD and only used the new one (version two), and replaced the CAM and DENM asn1 files with the recent drafts for version 2 CAMs/DENMs, available in the ETSI gitlab, that will be released this year. I disregarded MAPEM, RTCMEM, SPATEM, etc. for now, since I would also need to update the ISO dependent asn1 files.

I am currently working on integrating the Collective Perception Service in Artery based on the ETSI TS 103 324 v2.1.1, using this pull request as inspiration.

Is it worthy/useful to make a pull request with these contribuitions? Or do you have another idea in mind, for instance having Vanetza working simultaniously with both CDDs?
I have tried this solution. However, generating multiple fields with the same name will break code that is dependent on those fields inside both vanetza and artery.

[diogopjesus]

I have made a pull request with a possible solution to keep both versions of the Common Data Dictionary (CDD) and the Collective Perception Message (CPM).

[yuasabe]

Thank you, @diogopjesus for the update.
I haven't been able to make much progress with this, so it will be of great help for me too.

Have you been able to generate actual CPMs through the socktap application, for example?

Also, I think after a demo CPM app can be built, the CPM packets can be confirmed on Wireshark, but I was having trouble updating Wireshark so that it is compatible with this new CPM standard. Have you been able to look into analyzing the CPM packets with Wireshark?

[riebl]

Because all these ASN.1 specifications need to be aligned carefully to remain compatible with each other, I usually add only released and somewhat "approved" ASN.1 files to Vanetza's master. I know that testing any work-in-progress or lesser-known message formats becomes more tedious this way but it (hopefully) ensures compatibility with any production message type.

I will have a look at your PR @diogopjesus and will accept it if no use cases get broken for others.

[yuasabe]

@riebl Thank you for the feedback.

Using the new CPM standard, I am working on creating a CPM application for Socktap. I usually confirm that the correct packets are generated by looking at the traffic through Wireshark and ensuring that they are being dissected properly. However, since this new CPM standard has only been released recently, Wireshark does not yet support it.

I've also been trying to update Wireshark to support this new CPM standard. Still, the packets generated in Socktap are not properly dissected, and it's difficult to tell if it's a problem with Wireshark or the CPM application in Socktap.

If the CPMs sent on Socktap can be received by another Socktap application and can be decoded properly, there may be no need to explicitly check the packets on Wireshark, but still, it feels nice to be able to confirm the contents of the packets.

Do you usually use Wireshark to confirm the contents of ETSI packets?

[riebl]

Hi @yuasabe,

I have used Wireshark to verify some generated packets in the past, but it is not part of my usual workflow. Ideally, I have a message with known content (or vice versa, known message for given input data) and add these to the unit tests. Thus, the encoding/decoding of new message formats becomes part of the test suite run with every new commit. If these tests do not fail, then I feel even more confident than with Wireshark :-)