Logo etsi

ETSI's Bug Tracker
Main | My View | View Issues | Change Log | Roadmap | Monitor project
  
Notice: information submitted on the ETSI issue Tracker may be incorporated in ETSI publication(s) and therefore subject to the ETSI IPR policy.

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007296CDD ASN.1 (TS 102 894-2)Bug Reportpublic08-01-2016 16:1224-01-2018 09:30
Reporterlinla 
Assigned ToLan LIN 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusconfirmedResolutionreopened 
PlatformOSOS Version
Product VersionTS 102 894-2 V1.2.1 
Target VersionTS 102 894-2 V1.2.1Fixed in Version 
Summary0007296: [DE_DrinvingLaneStatus]: make it unnamed list
DescriptionMotivation:
Quote from CDD TS 102 894-2, page 28:

ASN.1 representation DrivingLaneStatus ::= BIT STRING { outermostLaneClosed(1),
secondLaneFromOutsideClosed(2) } (SIZE (1..14))

Definition DE that indicates whether a driving lane is open to traffic.

A lane is counted from outside boarder of the road. The numbering is matched to
LanePosition DE as defined in clause A.40. If a lane is closed to traffic, the
corresponding bit shall be set to 1. Otherwise, it shall be set to 0.

The DrivingLaneStatus is a BIT STRING with ‘NamedBitList’ and shall be encoded following rule 16.3 of X.691. As a consequence, the original length (2 bits) and trailing zeros are not encoded (see example 1).

Problem:
A receiving ITS-S cannot reconstruct the trailing zeros and unambiguously distinguish between an open lane (value 0) and non-existing lane.

Proposed Change:
Move the bit names of DE DrivingLaneStatus (outermostLaneClosed, secondLaneFromOutsideClosed) from the ASN.1 definition to the description:

DrivingLaneStatus ::= BIT STRING (SIZE (1..14))

As a result, rule 16.3 of X691 does not apply and the DrivingLaneStatus will be UPER encoded following rule 16.11 of X.691 (trailing zeros + original length are encoded).

Consequence
This solution removes ambiguity at a receiving ITS-S by explicit encoding of all bits at the cost of changed encoding and larger messages.

Example 1 : Encoding of Name Bit String
Bit-Schema DEFINITIONS AUTOMATIC TAGS ::=
BEGIN
  Example ::= SEQUENCE {
     drivingLaneStatus BIT STRING { outermostBit(1), secondBitFromOutside(2) } (SIZE (1..14))
  }
END

value Example ::=
{
  drivingLaneStatus '10'B
}

‘value’ is UPER encoded as ‘08H’:
- 4 bit length = 0 (decoded as 1)
- 1 bit content = ‘1B’
- 3 bit padding

Example 2 : Encoding of an unname bit string
Bit-Schema DEFINITIONS AUTOMATIC TAGS ::=
BEGIN
  Example ::= SEQUENCE {
     drivingLaneStatus BIT STRING (SIZE (1..14))
  }
END

value Example ::=
{
  drivingLaneStatus '10'B
}

‘value’ is UPER encoded as 18H :
- 4 bit length = 1 (decoded as 2)
- 2 bit content = ‘10B’
- 2 bit padding

TagsNo tags attached.
Attached Fileszip file icon Named vs Plain bitstring output examples.zip [^] (745,842 bytes) 20-01-2016 04:37
jpg file icon Example_Laurens.jpg [^] (66,995 bytes) 02-02-2016 08:15

- Relationships
has duplicate 0007354closedSebastian Muellers [DE_DrivingLaneStatus] 

-  Notes
(0013682)
linla (manager)
12-01-2016 13:13

 make it unnamed list will break the backward compatibility. alternatively, the unmodified version will only indicate the closing lanes, instead of indicating the complete road lane layout.

please verirify other data elements with the same type.
(0013736)
Andras Kovacs (reporter)
20-01-2016 04:41

 I tested the difference, and the encoding with Objective Systems' asn.1 encoder has been exactly the same with named bitstring vs. plain bitstring. See the screenshots in the attached file.
Apparently, it is following rule 16.11 of X.691 even for named bitstrings. Is this a bug in the asn.1 tool, or is the above interpretation of these rule differences incorrect? Can you show a counterexample, where the encoding is really different?
(0013797)
Sebastian Muellers (administrator)
02-02-2016 08:14

 Dear Sebastian,

The value ‘0101’B is not a good example because the last bit is a ‘1’. Therefore, also a named list will encode the full value.

The value ‘10’B makes more sense. If I use the online tool from OSS Nokalva (http://asn1-playground.oss.com/ [^]), I get the following result:

You can see that the UPER encoding is 0x08 (00001000B: 4 bit length, 1 bit value, 3 bit padding). It is different though from the screenshot of Andras. I can check with Marben ASN.1 but it takes me some more time.

Best regards,
Laurens
(0013798)
Sebastian Muellers (administrator)
02-02-2016 08:15

 Dear Laurens,
 Thank you for the good example! The ‘10’B encoding output is indeed different with the OSS and OBJ-SYS tools when using named bit string.

 Let me check with OBJ-SYS to confirm whether they agree that this is indeed a bug in their implementation (or if they think that the OSS interpretation of the standard is wrong). I will come back on this issue, as I receive the answer from them. Then we can decide if/how to correct the LaneStatus data element.

Best regards,

Andras
(0013799)
Sebastian Muellers (administrator)
02-02-2016 08:16

 Dear all,
 I received the confirmation from OBJ-SYS that their implementation has a bug, and the OSS implementation is correct. This OBJ-SYS bug will be fixed in the next revision.
 So it is indeed the case that the presence/absence of named bits can make a difference with PER encoding. I think this is counterintuitive, but that's how it is.
 Therefore I agree to the proposed resolution of the issue 7296, i.e. to remove named bits from the LaneStatus data element.

Best regards,

Andras
(0013912)
Sebastian Muellers (administrator)
04-04-2016 16:06

 please approve at ITSWG1#35 the change

from
DrivingLaneStatus ::= BIT STRING { outermostLaneClosed(1),
secondLaneFromOutsideClosed(2) } (SIZE (1..14))

to
DrivingLaneStatus ::= BIT STRING (SIZE (1..14))
(0013914)
Sebastian Muellers (administrator)
04-04-2016 16:22

 This problem only effects variable size bit string types, and DrivingLaneStatus is the only one
(0013933)
linla (manager)
12-04-2016 13:46

 approved in ITS WG1#35 meeting.
(0013949)
Yann Garcia (developer)
22-04-2016 08:31

 Implemented as: DrivingLaneStatus ::= BIT STRING (SIZE (1..15))
(0014201)
Yann Garcia (developer)
07-09-2016 06:27

 Re-typing DrivingLaneStatus - Mantis 0007296
U /branches/STF517/asn1/ITS-Container/ITS-Container.asn [^]
(0014202)
Yann Garcia (developer)
07-09-2016 11:34

 Re-typing DrivingLaneStatus - Mantis 0007296
U /trunk/cam/ITS-Container.asn [^]
U /trunk/denm/ITS-Container.asn [^]
U /trunk/itsis/ITS-Container.asn [^]
(0014203)
Yann Garcia (developer)
07-09-2016 13:02

 Re-typing DrivingLaneStatus - Mantis 0007296
U /releases/wireshark-2.0.x/Linux/64bits/cam.so [^]
U /releases/wireshark-2.0.x/Linux/64bits/denm.so [^]
U /releases/wireshark-2.0.x/Linux/64bits/itsis.so [^]
U /releases/wireshark-2.0.x/Windows/32bits/cam.dll [^]
U /releases/wireshark-2.0.x/Windows/32bits/denm.dll [^]
U /releases/wireshark-2.0.x/Windows/32bits/itsis.dll [^]
U /releases/wireshark-2.0.x/Windows/64bits/cam.dll [^]
U /releases/wireshark-2.0.x/Windows/64bits/denm.dll [^]
U /releases/wireshark-2.0.x/Windows/64bits/itsis.dll [^]
(0014481)
linla (manager)
10-01-2017 15:19
edited on: 10-01-2017 16:13

 implemented in CDD V1.2.3 on Jan 2017
(0014504)
linla (manager)
18-01-2017 11:00

 open again, to change the counting way and the hardshould status case
(0014506)
linla (manager)
18-01-2017 11:09
edited on: 20-01-2017 14:11

 modifications implemented in V1.2.4 in WG1#38. counting from innerborder, and does not include hardshoulder status.
(0014547)
linla (manager)
05-04-2017 14:31
edited on: 05-04-2017 14:33

 email from Jasja Kapsch:
Hi Sebastian,
 
thank you for your answer. Some issues I see:
 
1. So you decided to “spoil” up to two bits in order to align the numbering. I am not against that, the only question is if it is the best solution. See next points.
2. What is missing in DrivingLaneStatus is that it “shall indicate the status of all drivable lanes on the carriageway”, and not just up to some lanes (e.g. up to last closed one, as with the current published CDD version). This is currently not excluded. So to really address the issue that trailing (i.e. open lanes) were previously not transmitted, we need to enforce the length of the DrivingLaneStatus BIT STRING to be equal to the number of drivable lanes on that particular road segment, not less and not more. In fact the receiving device derives the number of lanes present from the size of the BIT STRING, so the size need to be correct at all times.
3. Now if you decide to go for using bits 0 and 14 as padding, bit 0 shall always be included (that’s clear), but it is not clear when bit 14 is to be included. It can only be included if we have 13 drivable lanes. Otherwise we can’t include it. So what is the value of Bit 14 in LanePosition? Seems confusing to me. I do not want to imply that one need always to use the full length in order to use bit 14 (see previous point). Let’s get rid of Bit 14, and why not get rid of Bit 0 as well. After all the fact that Bit 0 is called “0” is human convention, and this is not send over the air. As the name says, the data element indicates the DrivingLaneStatus.
4. Where did the comment to count lanes from inside to outside come from? I have strong indications that Asfinag disagrees with this since lane counting in Datex II is from outside to inside.
ASN.1 representation DrivingLaneStatus ::= BIT STRING (SIZE (1..13))

Definition DE that indicates whether a driving lane is present and open to traffic.
 
A lane is counted from inside border of the road excluding the hardshoulder. The bit 0 is used to indicate the innermostLane, bit 1 is used to indicate the second lane from the inside border. The size of the bit string shall correspond to the number of drivable lanes of the carriageway.
Note: Hard shoulder status is not provided by this DE but in HardShoulderStatus as defined in A.29.
If a lane is present and closed to traffic, the corresponding bit shall be set to 1.
If a lane is present and open to traffic, the corresponding bit shall be set to 0.
 
 
The DE is used in ClosedLanes DF as defined in clause A.106.
(0014549)
buburuzan (developer)
06-04-2017 15:26

 Approved in WG1#39 with the following agreement:
1. For more than 13 lanes the DE shall not be transmitted. This will apply to the DF_LaneStatus.
2. The HardShoulder will not be included in the DrivingLaneStatus.
(0015034)
buburuzan (developer)
24-01-2018 09:28

 Reopened @ITS1#42 and agreed to implement the ASN.1 representation of DrivingLaneStatus ::= BIT STRING (SIZE (1..13)) as suggested and agreed by Jasja.
(0015035)
buburuzan (developer)
24-01-2018 09:28

 Decided to implement it in WG1#42.
(0015036)
buburuzan (developer)
24-01-2018 09:30

 WG1#42: we also agree with the extended definition: The size of the bit string shall correspond to the number of drivable lanes of the carriageway.

- Issue History
Date Modified Username Field Change
08-01-2016 16:12 linla New Issue
08-01-2016 16:12 linla Status new => assigned
08-01-2016 16:12 linla Assigned To => Sebastian Muellers
09-01-2016 16:39 linla Description Updated View Revisions
12-01-2016 13:13 linla Note Added: 0013682
20-01-2016 04:37 Andras Kovacs File Added: Named vs Plain bitstring output examples.zip
20-01-2016 04:41 Andras Kovacs Note Added: 0013736
02-02-2016 08:14 Sebastian Muellers Note Added: 0013797
02-02-2016 08:15 Sebastian Muellers File Added: Example_Laurens.jpg
02-02-2016 08:15 Sebastian Muellers Note Added: 0013798
02-02-2016 08:16 Sebastian Muellers Note Added: 0013799
04-04-2016 16:05 Sebastian Muellers Assigned To Sebastian Muellers => Lan LIN
04-04-2016 16:06 Sebastian Muellers Note Added: 0013912
04-04-2016 16:22 Sebastian Muellers Note Added: 0013914
12-04-2016 13:46 linla Note Added: 0013933
12-04-2016 13:46 linla Status assigned => confirmed
18-04-2016 14:19 Sebastian Muellers Assigned To Lan LIN => Yann Garcia
18-04-2016 14:19 Sebastian Muellers Status confirmed => assigned
22-04-2016 08:31 Yann Garcia Note Added: 0013949
22-04-2016 08:31 Yann Garcia Status assigned => resolved
22-04-2016 08:31 Yann Garcia Resolution open => fixed
04-05-2016 09:03 Sebastian Muellers Relationship added has duplicate 0007354
07-09-2016 06:27 Yann Garcia Checkin
07-09-2016 06:27 Yann Garcia Note Added: 0014201
07-09-2016 11:34 Yann Garcia Checkin
07-09-2016 11:34 Yann Garcia Note Added: 0014202
07-09-2016 13:02 Yann Garcia Checkin
07-09-2016 13:02 Yann Garcia Note Added: 0014203
10-01-2017 15:19 linla Note Added: 0014481
10-01-2017 16:13 linla Note Edited: 0014481 View Revisions
18-01-2017 11:00 linla Note Added: 0014504
18-01-2017 11:09 linla Note Added: 0014506
20-01-2017 14:11 linla Note Edited: 0014506 View Revisions
05-04-2017 14:31 linla Note Added: 0014547
05-04-2017 14:31 linla Assigned To Yann Garcia => Alexandre Berge
05-04-2017 14:31 linla Status resolved => assigned
05-04-2017 14:32 linla Note Edited: 0014547 View Revisions
05-04-2017 14:33 linla Note Edited: 0014547 View Revisions
06-04-2017 15:26 buburuzan Note Added: 0014549
06-04-2017 15:26 buburuzan Status assigned => resolved
24-01-2018 09:28 buburuzan Assigned To Alexandre Berge => Lan LIN
24-01-2018 09:28 buburuzan Note Added: 0015034
24-01-2018 09:28 buburuzan Status resolved => feedback
24-01-2018 09:28 buburuzan Resolution fixed => reopened
24-01-2018 09:28 buburuzan Note Added: 0015035
24-01-2018 09:28 buburuzan Status feedback => confirmed
24-01-2018 09:30 buburuzan Note Added: 0015036

MantisBT 1.2.14 [^]
Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker