ITS Standards

[HJFischer at fischer-tech.info]

Just a singel comment below

Hans-Joachim

Am 29.07.2010 04:02, schrieb Richard Roy:

[dickroy]

 
 

From: stds-p1609@ieee.org [mailto:stds-p1609@ieee.org] On Behalf Of Dr. Hans-Joachim Fischer
Sent: Wednesday, July 28, 2010 9:38 PM
To: dickroy@alum.mit.edu
Cc: 'Alastair Malarky'; 'John Moring'; '1609'; 'Knut Evensen'
Subject: Re: 1609.3 comment - PSID description

 
Just a singel comment below

Hans-Joachim

Am 29.07.2010 04:02, schrieb Richard Roy:
<![endif]--> <![endif]--> 
 

From: stds-p1609@ieee.org (stds-p1609@ieee.org) [mailto:stds-p1609@ieee.org (stds-p1609@ieee.org)] On Behalf Of Alastair Malarky
Sent: Wednesday, July 28, 2010 5:57 PM
To: dickroy@alum.mit.edu (dickroy@alum.mit.edu); 'John Moring'; '1609'
Cc: 'Dr. Hans-Joachim Fischer'; 'Knut Evensen'; 'Per Furnes'
Subject: RE: 1609.3 comment - PSID description

 
Just to be clear - is the recommendation from task force STF 404 still in effect or does the discrepancy mean that it has to be revisited ?
[RR >] Perhaps a bit of context here.  STF 404 is an ETSI task force whose job is to come up with the “European” standard on how the PSID will be encoded, recommend a registration authority, etc., as Hans explained in his previous email.  Since that STF and the WG in charge of that STF (ETSI TC ITS WG2 Architecture) are very favorably disposed to international harmonization, especially with regard to the PSID, and since the STF has yet to finalize its findings (work is still ongoing), it is very likely that with a few joint discussions a single specification for international use could easily be achieved.   That having been said, I can assure you that the STF will not be recommending the unaligned PER encoding of INTEGER(0..127,…) for the PSID/ITS-AID/SID/ITS-SID or whatever it ends up being called.  As noted below, Hans prepared the info on the ASN.1 CHOICE type encoding in the file I sent previously. 
 
In summary, it’s safe to say that the STF, ETSI TC ITS, TC204WG16, etc., are very open to discussing and deciding on a single specification for the PSID. 
 
If it is still in effect, then I think the 1609 group still needs to see what INTEGER(0..127,…) looks like.   
[RR >] Here’s an example:
 
psid INTEGER(0..127,…)  ::=128
 
Using unaligned PER encodes as
1 | 00000010 | 00000000 | 10000000
 
Pretty neat huh????  This is why no one is considering unaligned PER any longer.
We are still sticking to unaligned PER, but not for an ASN.1 type such as INTEGER(0..127,...). The problem is that the extension functionality "..." takes away all the benefits which are due to unaligned PER (efficient minimum size coding).
[RR >] I should have been more explicit … I meant just for the PSID as INTEGER(0..127,…).  Clearly Unaligned PER is useful in other contexts for other applications, just not for the PSID as we see things going forward.
 
Cheers,
 
RR
 
 
Cheers,
 
RR
 
Alastair Malarky
Chief Engineer & Design Integrity Director
Mark IV Industries,  IVHS Division
amalarky@ivhs.com (amalarky@ivhs.com)
Tel: (l) 905 624 3020 ext. 1203
Fax: (1) 905 624 4572
 
This communication may be privileged and may contain confidential information for the intended recipients. If you are not an intended recipient, please be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you received this electronic message in error, please notify the sender and delete the copy you received.

 
From: stds-p1609@ieee.org (stds-p1609@ieee.org) [mailto:stds-p1609@ieee.org (stds-p1609@ieee.org)] On Behalf Of Richard Roy
Sent: Wednesday, July 28, 2010 6:57 PM
To: 'John Moring'; '1609'
Cc: 'Dr. Hans-Joachim Fischer'; 'Knut Evensen'; 'Per Furnes'
Subject: RE: 1609.3 comment - PSID description


 
The material in “PSID specification 100728.doc” looks fine to me.
 
After an exchange of many emails with ASN experts and a “thorough” reading (and re-reading) of X.691 (esp. clause 13), I believe the encoding that we (TC 204 WG16) originally claimed to be “unaligned PER encoding of INTEGER(0..127,…) is not.  While it is DMK#2 as proposed by Doug and discussed in April, it is NOT unaligned PER encoding of INTEGER(0..127,…).  If this is still an encoding that the WG feels worth considering, I have attached proposed text for clause 8.1.3.  The one advantage discussed in April is that it is immediately extensible without having to change the specifications and use the “reserved 1111 bits” to create an extension mechanism.  As I recall, the drawback was increased decoding complexity, but I could be wrong about this.
 
For consideration, if having a standard ASN.1 type encoding is deemed of value, and having 4 times the number of 4-octet PSIDs is iof interest, one of the encodings we discussed in April (the “Fixed Size Length Code Option) turns out to be an ASN.1 choice type encoding.  The advantages are as given in the presentations from April, and the drawback would seem to be lack of extensibility (do we really need more than 1 billion PSIDs??).  I have attached a doc file that Hans created showing this encoding (for your viewing pleasure:^))).
 
For those interested in what unaligned PER encoding of INTEGER(0..127,…) would really look like, we can discuss over a beer in Annapolis!:^)))
 
Cheers,
 
RR
 
 

From: stds-p1609@ieee.org (stds-p1609@ieee.org) [mailto:stds-p1609@ieee.org (stds-p1609@ieee.org)] On Behalf Of John Moring
Sent: Wednesday, July 28, 2010 11:36 AM
To: '1609'
Subject: RE: 1609.3 comment - PSID description

 
Many thanks to Alastair and John K for hammering out a clear, concise, correct presentation of the PSID format.  The attached file shows the material I will add into the 1609.3 recirculation draft.  Comments welcome.
 
JTM
 

From: Alastair Malarky [mailto:AMalarky@ivhs.com (amalarky@ivhs.com)]
Sent: Monday, July 26, 2010 6:45 PM
To: John Kenney
Cc: John Moring; 1609
Subject: RE: 1609.3 comment - PSID description

 
See inline responses.
 
Alastair Malarky
Chief Engineer & Design Integrity Director
Mark IV Industries,  IVHS Division
amalarky@ivhs.com (amalarky@ivhs.com)
Tel: (l) 905 624 3020 ext. 1203
Fax: (1) 905 624 4572
 
This communication may be privileged and may contain confidential information for the intended recipients. If you are not an intended recipient, please be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you received this electronic message in error, please notify the sender and delete the copy you received.
 
From: John Kenney [mailto:jkenney@us.toyota-itc.com (jkenney@us.toyota-itc.com)]
Sent: Monday, July 26, 2010 4:35 PM
To: Alastair Malarky
Cc: John Moring; 1609
Subject: Re: 1609.3 comment - PSID description

 
Hi Alastair,

These are good clarifications.

 

A few suggestions regarding the text:

1) I would want the annex to be normative since that is the place (now that Figure 1 is gone) where the transmission order of octets is defined.  Alternatively, some clear statement in 8.1.3 could define the octet transmission order.
could change 3rd sentence to be normative:  "shall always be" instead of "are always".  Don't like to make example annex normative
 

2) in the 4th sentence, I find "treating the first octet as a numeric value" a bit unclear.  I realize you are mimicing the 802 language in the footnote.  Would it be accurate to say "The leftmost bits of the first octet specify the length of the PSID, as defined in Table 1."
The problem is leftmost is not as clear as it sounds - since effectively the most significant bits are on the right in the 802.11 definition (see examples), but on the left if we express it as a binary number (0b…..).  By defining most-significant it is unambiguous in either representation.  Suggest alternative wording might be "The most significant bits of the numeric value of  the first octet (Octet 0) specify…"
 
  I've also removed "in octets" after "length of the PSID" because to me that sounded like I should expect to interpret the most significant bits as a numeric value in units of octets, e.g. somehow the number 3 would be in those bits for a 3-octet PSID.
Okay
 

3) I think it could be confusing to use "x" as a "don't care bit value" in the leftmost column of Table 1, and as a "don't care hex digit value" in the rightmost column.  I'm wondering why we need the "x"s in the rightmost column.  I think the original text is better for that column, with a few extra hyphens so there is one after each pair of hex digits, i.e. 1-octet range is 00-7F, 2-octet range is 80-00 to BF-FF, 3-octet range is C0-00-00 to DF-FF-FF, and 4-octet range is E0-00-00-00 to EF-FF-FF-FF.  In the bottom row, the rightmost column could say "leftmost hex digit is F" rather than "Fx-...".
Okay except for F (see above.)
 

4) In the annex the text refers a couple of times to "the first octet," and we show numbered octets in the figures, i.e. Octet 0, Octet 1, etc.  It might be more clear to replace references to "the first octet" with "Octet 0". 
Agreed - but need then to define octet numbering (8.1 doesn't).  Need to add something for that.
 
 Clasue 8.1 discusses bit numbers across a multi-octet field, and the numbering does not restart within each octet.  Given that, we might want to continue the numbering in Octet 1 with B8 through B15, rather than B0 through B7.  Same for Octet 2: B16 through B23.
The problem with numbering it as a sequential set of bits is that it tends to lead to people thinking of it a single numeric value.  I prefer to think of each octet as a sub-field of PSID.  Then the representation makes sense.   Also when transmitting messages the MAC passes single octets to the PLCP (sublayer of PHY) and on-air there aren’t serial bits.  I think the following may be a better way to represent it:
 
[img]cid:image001.gif@01cb2ea6.e4b6b8a0[/img]

 

Hope this helps,

John

 

 

 

 

 

 

 

 

 

On Mon, Jul 26, 2010 at 11:51 AM, Alastair Malarky <AMalarky@ivhs.com (amalarky@ivhs.com)> wrote:
I think part of problem is we keep treating and/or representing the 1609 defined PSID as an integer or an encoded integer (I've been just as bad).  It used to be an integer when it was a fixed length but it isn't any more.  Nor is it an encoded integer any more since it will be assigned as the entire octet sequence, not as an unencoded (numeric) value which is then encoded. 
 
I believe we should consider 1609 defined PSID in the context of: 
 
                The PSID is assigned as an ordered sequence of octets, of variable length, where the sequence is structured so that it has a deterministic length indicated by the first octet.
 
While an octet sequence longer than one octet can be represented  using hex, I don’t think we should express it as a number with hexidecimal digits  (e.g. 0xABCD…  or ABCD16) but use the hexidecimal representation (see IEEE 802) of an octet sequence (AB-CD-….  ).   By using the numeric representation we create the interpretation it can be treated as a single integer (whose octets are then sent least-significant octet first in 802.11 default) or purely as an ordered sequence of octets (in which case octets are transmitted in order from left to right).
 
Applying these, then the text changes as attached and ambiguity disappears.  Note also that we could also get more than 5 octets for PSID if we every had to (hope we never have to).  We do not need to specify the structure extension at this time.
 
 Note this in no way changes the PSID we have agreed to - the issue is one of clarity in the text.
 
Alastair Malarky
Chief Engineer & Design Integrity Director
Mark IV Industries,  IVHS Division
amalarky@ivhs.com (amalarky@ivhs.com)
Tel: (l) 905 624 3020 ext. 1203
Fax: (1) 905 624 4572
 
This communication may be privileged and may contain confidential information for the intended recipients. If you are not an intended recipient, please be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you received this electronic message in error, please notify the sender and delete the copy you received.

 

From: stds-p1609@ieee.org (stds-p1609@ieee.org) [mailto:stds-p1609@ieee.org (stds-p1609@ieee.org)] On Behalf Of John Moring

Sent: Wednesday, July 21, 2010 6:55 PM
To: '1609'
Subject: 1609.3 comment - PSID description



 
I have been working with Alastair (with some help from William) in resolving comments #16 - #18 in the recirculation ballot.  I’ve attached a file to address the issue described below.  It’s taken me a couple days of thought and research to arrive at the conclusion that this is our best solution.  Please post any thoughts to the reflector. If needed we can include discussion of this matter on Friday’s 1609.3 comment resolution call.  Refer to 160-9.3 subclause 8.1.3.
 
The issue is that there is potential ambiguity in the length of a PSID, which for example could cause a receiver of a WSA or WSM to be unable to parse the message.  We have specified the “length bits” (i.e., the bit string from which the octet length of the PSID can be deduced) as the MSBs of the field.  This is desirable because the PSID values for any given octet length are contiguous, as shown in Table 4 in 8.1.3.  In normal 802.11/1609 convention, MSBs are placed LAST within a field, so for example, a 2-octet PSID would have its length code (MSBs) in the second byte.  A 3-octet PSID would have its length code in the third byte.  A receiver would not be able to reliably distinguish among different length PSIDs, because the length code location is not deterministic. 
 
Similar situations have been encountered in the past.  MAC Address in 802 and Organization Identifier in 802.11p are specified to be sent higher-order octet
Thus the PSID will be interpreted just as we’ve described previously, but it will be structured such that the most significant octet is always first.  (There is no effect on 1-octet PSIDs).  The attached document shows how 8.1.3 has been updated to reflect this, and a new annex to illustrate the structure via examples.
 
Comments welcome.
 
JTM
 
 





 

[DC Kelley]

Sorry to be a bit late on this thread but the critical point seems to now turn on the extensibility indication (the "..." that is part of the actual ASN) 

Dick's switch example does NOT seem to have this in it (it probably should be present), do we in fact need to have the ability to add a 5th byte (or more), if so we will need that "..." back into the specification and the final binary form of the PER encoding differs due to it as Dr. Hans-Joachim Fischer correctly notes in the below. 

The "..." marker literally means "wait, I may add more to my ASN right here at some time in the future so do not get too clever when you compress/encode this part" so we might be better off just adding a 5th byte now (if that is the ultimate limit) and solving things that way. [ASN tip:  When you can avoid using the "..." you should always do so, add it when there an unknown point where new content may come to exist in your next edtion]

Also, I remain confused as to if this will be specified as an OCTET or an INTEGER, they are not the same, nor do the same useful ranges fit in the same space (as all INTs are signed).  What is the actual plan?  John's post of early today strongly suggested that this is an OCTET and NOT an INTEGER as Dick used  (which I tend to think is the best use of the bits). Can we confirm that remains the plan.   And note that an OCTET will allow 253 1 byte long PSIDs, not 127 or 63 as other have suggested.  If so then the actual ASN does not need the "..." as in Dicks example,and the 4 could be replaced with a 5 in the below line if we still need it. 

PSID = OCTET (SIZE(1..4))  -- that's all you need to have in "pure" ASN world, encoding does the rest. 

If you feel a need to precede this with an unique/custom "length" encoding, consider defining a further octet with the enumerated byte values for 1,2,3,4,5 bytes to follow (the definition of which comes from John's table).

Just trying to get things perfect and move on...
Regards,
DC Kelley


At 06:37 AM 7/29/2010 +0200, Dr. Hans-Joachim Fischer wrote:

[dickroy]

 
 

From: stds-p1609@ieee.org [mailto:stds-p1609@ieee.org] On Behalf Of David Kelley
Sent: Wednesday, July 28, 2010 11:01 PM
To: '1609'
Cc: 'Alastair Malarky'; 'John Moring'; 'Knut Evensen'; Dr. Hans-Joachim Fischer; dickroy@alum.mit.edu
Subject: Re: 1609.3 comment - PSID description

 

Sorry to be a bit late on this thread but the critical point seems to now turn on the extensibility indication (the "..." that is part of the actual ASN) 
[RR >] Seems that some email filter changed “…” to “&” in my example below … hmmmmmm????
 

Dick's switch example does NOT seem to have this in it (it probably should be present), do we in fact need to have the ability to add a 5th byte (or more), if so we will need that "..." back into the specification and the final binary form of the PER encoding differs due to it as Dr. Hans-Joachim Fischer correctly notes in the below.
[RR >] What Hans was saying below is that unaligned PER encoding of INTEGER(0..127,…) is not being used, but that unaligned PER is being used elsewhere.
 

The "..." marker literally means "wait, I may add more to my ASN right here at some time in the future so do not get too clever when you compress/encode this part" so we might be better off just adding a 5th byte now (if that is the ultimate limit) and solving things that way. [ASN tip:  When you can avoid using the "..." you should always do so, add it when there an unknown point where new content may come to exist in your next edtion]
[RR >] It is very unlikely we would need another octet … currently with 4 octets we have at least 250 million numbers.  If 1000 numbers are assigned every day of the year, it will take around 1000 years to exhaust the numbers!  I’m not going to be around to blame anyway:^)))  That having been said, the current version of 8.1.3 has 1111 as a reserved bit pattern, so in 1000 years or so, someone else can amend the spec to use this reserved bit patter and increase the number space.
 

Also, I remain confused as to if this will be specified as an OCTET or an INTEGER, they are not the same, nor do the same useful ranges fit in the same space (as all INTs are signed). 
[RR >] If by all INTs are signed you mean that ASN.1 does not support non-negative integer encodings, I guess I have to disagree since as I read X.691-2008, non-negative integer encodings are allowed. Did you mean something else?
What is the actual plan?  John's post of early today strongly suggested that this is an OCTET and NOT an INTEGER as Dick used  (which I tend to think is the best use of the bits). Can we confirm that remains the plan.  
[RR >] Do you mean “confirm that we want to encode the PSID as an ASN.1 OCTET type?
And note that an OCTET will allow 253 1 byte long PSIDs, not 127 or 63 as other have suggested. 
[RR >] How is the “size” encoded if all the bits of the first octet can be PSID value bits?  As I read X.691, the OCTET type requires a length determinant encoding the whole number “n” to precede the n-octet bit-field.  If this is true, then even 1-octet PSIDs require two octets in the bit-field to be transmitted.
If so then the actual ASN does not need the "..." as in Dicks example,
[RR >] The example I gave was simply to respond to Alastair’s request to “see what unaligned PER encoding of INTEGER(0..127,…) looks like, and to demonstrate why unaligned PER encoding of INTEGER(0..127,…) would not be something we want to consider for encoding PSIDs.
and the 4 could be replaced with a 5 in the below line if we still need it. 

PSID = OCTET (SIZE(1..4))  -- that's all you need to have in "pure" ASN world, encoding does the rest. 
[RR >] So how would PSID = 1 and PSID = 256 get encoded using OCTET (SIZE(1..4))?  See note above about a length determinant.
 
If you feel a need to precede this with an unique/custom "length" encoding, consider defining a further octet with the enumerated byte values for 1,2,3,4,5 bytes to follow (the definition of which comes from John's table).
[RR >] We are going through this optimization to save a byte or two.  Adding a byte defeats this purpose.  This is not to suggest that a debate about the value of saving a single byte has no merit.  It’s just that if the thought is that a single byte matters, then we should be trying to eliminate bytes, not add them.  I personally don’t see much value in byte-saving when the packets being sent are in the 100’s of bytes anyway, but I also don’t think we should be careless with bytes either.  A byte saved is a byte earned!
 
Cheers,
 
RR

Just trying to get things perfect and move on...
Regards,
DC Kelley


At 06:37 AM 7/29/2010 +0200, Dr. Hans-Joachim Fischer wrote:



Just a singel comment below

Hans-Joachim

Am 29.07.2010 04:02, schrieb Richard Roy:
-cut- header



Just to be clear - is the recommendation from task force STF 404 still in effect or does the discrepancy mean that it has to be revisited ?

[RR >] Perhaps a bit of context here.  STF 404 is an ETSI task force whose job is to come up with the Europeanstandard on how the PSID will be encoded, recommend a registration authority, etc., as Hans explained in his previous email.  Since that STF and the WG in charge of that STF (ETSI TC ITS WG2 Architecture) are very favorably disposed to international harmonization, especially with regard to the PSID, and since the STF has yet to finalize its findings (work is still ongoing), it is very likely that with a few joint discussions a single specification for international use could easily be achieved.   That having been said, I can assure you that the STF will not be recommending the unaligned PER encoding of INTEGER(0..127,&) for the PSID/ITS-AID/SID/ITS-SID or whatever it ends up being called.  As noted below, Hans prepared the info on the ASN.1 CHOICE type encoding in the file I sent previously. 

 

In summary, its safe to say that the STF, ETSI TC ITS, TC204WG16, etc., are very open to discussing and deciding on a single specification for the PSID. 

 

If it is still in effect, then I think the 1609 group still needs to see what INTEGER(0..127,&) looks like.  

[RR >] Heres an example:

 

psid INTEGER(0..127,&)  ::=128

 

Using unaligned PER encodes as

1 | 00000010 | 00000000 | 10000000

 

Pretty neat huh????  This is why no one is considering unaligned PER any longer.
We are still sticking to unaligned PER, but not for an ASN.1 type such as INTEGER(0..127,...). The problem is that the extension functionality "..." takes away all the benefits which are due to unaligned PER (efficient minimum size coding).



 

Cheers,

 

RR

 

Alastair Malarky

Chief Engineer & Design Integrity Director

Mark IV Industries,  IVHS Division

amalarky@ivhs.com (amalarky@ivhs.com)

Tel: (l) 905 624 3020 ext. 1203

Fax: (1) 905 624 4572

 

This communication may be privileged and may contain confidential information for the intended recipients. If you are not an intended recipient, please be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you received this electronic message in error, please notify the sender and delete the copy you received.

 

From: stds-p1609@ieee.org (stds-p1609@ieee.org) [mailto:stds-p1609@ieee.org (stds-p1609@ieee.org)] On Behalf Of Richard Roy
Sent: Wednesday, July 28, 2010 6:57 PM
To: 'John Moring'; '1609'
Cc: 'Dr. Hans-Joachim Fischer'; 'Knut Evensen'; 'Per Furnes'
Subject: RE: 1609.3 comment - PSID description

 

The material in PSID specification 100728.doclooks fine to me.

 

After an exchange of many emails with ASN experts and a thoroughreading (and re-reading) of X.691 (esp. clause 13), I believe the encoding that we (TC 204 WG16) originally claimed to be unaligned PER encoding of INTEGER(0..127,&) is not.  While it is DMK#2 as proposed by Doug and discussed in April, it is NOT unaligned PER encoding of INTEGER(0..127,&).  If this is still an encoding that the WG feels worth considering, I have attached proposed text for clause 8.1.3.  The one advantage discussed in April is that it is immediately extensible without having to change the specifications and use the reserved 1111 bitsto create an extension mechanism.  As I recall, the drawback was increased decoding complexity, but I could be wrong about this.

 

For consideration, if having a standard ASN.1 type encoding is deemed of value, and having 4 times the number of 4-octet PSIDs is iof interest, one of the encodings we discussed in April (the Fixed Size Length Code Option) turns out to be an ASN.1 choice type encoding.  The advantages are as given in the presentations from April, and the drawback would seem to be lack of extensibility (do we really need more than 1 billion PSIDs??).  I have attached a doc file that Hans created showing this encoding (for your viewing pleasure:^))).

 

For those interested in what unaligned PER encoding of INTEGER(0..127,&) would really look like, we can discuss over a beer in Annapolis!:^)))

 

Cheers,

 

RR

 

 
 
From: stds-p1609@ieee.org (stds-p1609@ieee.org) [mailto:stds-p1609@ieee.org (stds-p1609@ieee.org)] On Behalf Of John Moring
Sent: Wednesday, July 28, 2010 11:36 AM
To: '1609'
Subject: RE: 1609.3 comment - PSID description

 

Many thanks to Alastair and John K for hammering out a clear, concise, correct presentation of the PSID format.  The attached file shows the material I will add into the 1609.3 recirculation draft.  Comments welcome.

 

JTM

 

From: Alastair Malarky [mailto:AMalarky@ivhs.com (amalarky@ivhs.com)]
Sent: Monday, July 26, 2010 6:45 PM
To: John Kenney
Cc: John Moring; 1609
Subject: RE: 1609.3 comment - PSID description

 

See inline responses.

 

Alastair Malarky

Chief Engineer & Design Integrity Director

Mark IV Industries,  IVHS Division

amalarky@ivhs.com (amalarky@ivhs.com)

Tel: (l) 905 624 3020 ext. 1203

Fax: (1) 905 624 4572

 

This communication may be privileged and may contain confidential information for the intended recipients. If you are not an intended recipient, please be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you received this electronic message in error, please notify the sender and delete the copy you received.

 

From: John Kenney [mailto:jkenney@us.toyota-itc.com (jkenney@us.toyota-itc.com)]
Sent: Monday, July 26, 2010 4:35 PM
To: Alastair Malarky
Cc: John Moring; 1609
Subject: Re: 1609.3 comment - PSID description

 

Hi Alastair,

These are good clarifications.

 

A few suggestions regarding the text:

1) I would want the annex to be normative since that is the place (now that Figure 1 is gone) where the transmission order of octets is defined.  Alternatively, some clear statement in 8.1.3 could define the octet transmission order.

could change 3rd sentence to be normative:  "shall always be" instead of "are always".  Don't like to make example annex normative

 

2) in the 4th sentence, I find "treating the first octet as a numeric value" a bit unclear.  I realize you are mimicing the 802 language in the footnote.  Would it be accurate to say "The leftmost bits of the first octet specify the length of the PSID, as defined in Table 1."

The problem is leftmost is not as clear as it sounds - since effectively the most significant bits are on the right in the 802.11 definition (see examples), but on the left if we express it as a binary number (0b&..).  By defining most-significant it is unambiguous in either representation.  Suggest alternative wording might be "The most significant bits of the numeric value of  the first octet (Octet 0) specify&"


  I've also removed "in octets" after "length of the PSID" because to me that sounded like I should expect to interpret the most significant bits as a numeric value in units of octets, e.g. somehow the number 3 would be in those bits for a 3-octet PSID.

Okay


3) I think it could be confusing to use "x" as a "don't care bit value" in the leftmost column of Table 1, and as a "don't care hex digit value" in the rightmost column.  I'm wondering why we need the "x"s in the rightmost column.  I think the original text is better for that column, with a few extra hyphens so there is one after each pair of hex digits, i.e. 1-octet range is 00-7F, 2-octet range is 80-00 to BF-FF, 3-octet range is C0-00-00 to DF-FF-FF, and 4-octet range is E0-00-00-00 to EF-FF-FF-FF.  In the bottom row, the rightmost column could say "leftmost hex digit is F" rather than "Fx-...".

Okay except for F (see above.)


4) In the annex the text refers a couple of times to "the first octet," and we show numbered octets in the figures, i.e. Octet 0, Octet 1, etc.  It might be more clear to replace references to "the first octet" with "Octet 0".

Agreed - but need then to define octet numbering (8.1 doesn't).  Need to add something for that.
 - cut as the IEEE server keep rejecting the post with this part (John K image files and other text) -  cut- cut- cut- cut- cut-

This post originally appeared on the committee list server

[AMalarky at IVHS.COM]

I don't agree with the changes. 
 
There is no MSO and LSO.  This would be treating the PSID as a number - instead of as a ordered sequence of octets, each of which is a number.  
 
AB-CD-EF, i.e. a sequence of octets expressed in hexadecimal representation, is really expressing a sequence of numbers [ 0xAB 0xCD 0xEF ]  and not a single number 0xABCDEF.   There is no implied ranking of significance between the individual numbers in the sequence of octets by the representation.
 
The term hexidecimal representation clearly expresses the order : The representation of a sequence of octet values in which the values of the individual octets are displayed in order from left to right
 
The first octet in the ordered sequence is the leftmost octet in the representation, and we are defining this to be Octet 0.
 
Also your change treats transmission as a serial bit stream, which OFDM is not.  The 802.11 MAC passes octets to the PLCP, not bits.  1609 only specifies extensions to the MAC layer and above.
 
Note the bit order representation (LSB to MSB in figures, B0 to Bn) is a convention for figures defined in 802.11, not intended to define bit transmission order, and 1609 has stayed with that convention.
 
Alastair Malarky
Chief Engineer & Design Integrity Director
Mark IV Industries,  IVHS Division
amalarky@ivhs.com (amalarky@ivhs.com)
Tel: (l) 905 624 3020 ext. 1203
Fax: (1) 905 624 4572
 
This communication may be privileged and may contain confidential information for the intended recipients. If you are not an intended recipient, please be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you received this electronic message in error, please notify the sender and delete the copy you received.

 
From: stds-p1609@ieee.org [mailto:stds-p1609@ieee.org] On Behalf Of Richard Roy
Sent: Wednesday, July 28, 2010 11:45 PM
To: 'John Kenney'; 'John Moring'
Cc: '1609'
Subject: RE: 1609.3 comment - PSID description


 
 
 

From: stds-p1609@IEEE.ORG [mailto:stds-p1609@IEEE.ORG] On Behalf Of John Kenney
Sent: Wednesday, July 28, 2010 12:00 PM
To: John Moring
Cc: 1609
Subject: Re: 1609.3 comment - PSID description

 
Hi John,

Thanks as usual for pulling this together.  I think this is more clear than the prior version.


I would feel more comfortable if the definition of hexadecimal representation were in our normative definition section than in a footnote.  I think there may be an IEEE style issue having what is essentially normative text in a footnote.
[RR >] I don’t think footnotes are allowed to contain normative test. 
 
That having been said, I think what’s missing from the text is a clear indication that octet 0 is the MSO (most significant octet)   The example in the Annex indicates this, but it’s not in the text. I am assuming that’s what’s meant anyway.  Also, nowhere does it state which bit is transmitted first, MSB or LSB.  Seems to me, this should be normative, e.g “The order of transmission shall be MSO (Octet 0) first, followed by all other octets in increasing order to the LSO (octet n), and each octet shall be transmitted LSB (B0) to MSB (B7).” Naturally reverse things if it’s meant to be MSB to LSB instead.  I’ve attached a revision to reflect these changes.
 
Cheers,
 
RR

 

The only other comment is that the clause number, 8.1.3, and the title of the clause are not separated by a space.  I assume when you put this in the real document that will be taken care of.

 

Thanks,

John



 

On Wed, Jul 28, 2010 at 11:36 AM, John Moring <john@moring.net (john@moring.net)> wrote:
Many thanks to Alastair and John K for hammering out a clear, concise, correct presentation of the PSID format.  The attached file shows the material I will add into the 1609.3 recirculation draft.  Comments welcome.
 
JTM
 


From: Alastair Malarky [mailto:AMalarky@ivhs.com (amalarky@ivhs.com)]
Sent: Monday, July 26, 2010 6:45 PM
To: John Kenney

Cc: John Moring; 1609
Subject: RE: 1609.3 comment - PSID description

 
See inline responses.
 
Alastair Malarky
Chief Engineer & Design Integrity Director
Mark IV Industries,  IVHS Division
amalarky@ivhs.com (amalarky@ivhs.com)
Tel: (l) 905 624 3020 ext. 1203
Fax: (1) 905 624 4572
 
This communication may be privileged and may contain confidential information for the intended recipients. If you are not an intended recipient, please be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you received this electronic message in error, please notify the sender and delete the copy you received.
 
From: John Kenney [mailto:jkenney@us.toyota-itc.com (jkenney@us.toyota-itc.com)]
Sent: Monday, July 26, 2010 4:35 PM
To: Alastair Malarky
Cc: John Moring; 1609
Subject: Re: 1609.3 comment - PSID description

 
Hi Alastair,

These are good clarifications.

 

A few suggestions regarding the text:

1) I would want the annex to be normative since that is the place (now that Figure 1 is gone) where the transmission order of octets is defined.  Alternatively, some clear statement in 8.1.3 could define the octet transmission order.
could change 3rd sentence to be normative:  "shall always be" instead of "are always".  Don't like to make example annex normative
 

2) in the 4th sentence, I find "treating the first octet as a numeric value" a bit unclear.  I realize you are mimicing the 802 language in the footnote.  Would it be accurate to say "The leftmost bits of the first octet specify the length of the PSID, as defined in Table 1."
The problem is leftmost is not as clear as it sounds - since effectively the most significant bits are on the right in the 802.11 definition (see examples), but on the left if we express it as a binary number (0b…..).  By defining most-significant it is unambiguous in either representation.  Suggest alternative wording might be "The most significant bits of the numeric value of  the first octet (Octet 0) specify…"
 
  I've also removed "in octets" after "length of the PSID" because to me that sounded like I should expect to interpret the most significant bits as a numeric value in units of octets, e.g. somehow the number 3 would be in those bits for a 3-octet PSID.
Okay
 

3) I think it could be confusing to use "x" as a "don't care bit value" in the leftmost column of Table 1, and as a "don't care hex digit value" in the rightmost column.  I'm wondering why we need the "x"s in the rightmost column.  I think the original text is better for that column, with a few extra hyphens so there is one after each pair of hex digits, i.e. 1-octet range is 00-7F, 2-octet range is 80-00 to BF-FF, 3-octet range is C0-00-00 to DF-FF-FF, and 4-octet range is E0-00-00-00 to EF-FF-FF-FF.  In the bottom row, the rightmost column could say "leftmost hex digit is F" rather than "Fx-...".
Okay except for F (see above.)
 

4) In the annex the text refers a couple of times to "the first octet," and we show numbered octets in the figures, i.e. Octet 0, Octet 1, etc.  It might be more clear to replace references to "the first octet" with "Octet 0". 
Agreed - but need then to define octet numbering (8.1 doesn't).  Need to add something for that.
 
 Clasue 8.1 discusses bit numbers across a multi-octet field, and the numbering does not restart within each octet.  Given that, we might want to continue the numbering in Octet 1 with B8 through B15, rather than B0 through B7.  Same for Octet 2: B16 through B23.
The problem with numbering it as a sequential set of bits is that it tends to lead to people thinking of it a single numeric value.  I prefer to think of each octet as a sub-field of PSID.  Then the representation makes sense.   Also when transmitting messages the MAC passes single octets to the PLCP (sublayer of PHY) and on-air there aren’t serial bits.  I think the following may be a better way to represent it:
 
[img]cid:image001.gif@01cb2eaf.f069c850[/img]

 

Hope this helps,

John

 

 

 

 

 

 

 

 

 

On Mon, Jul 26, 2010 at 11:51 AM, Alastair Malarky <AMalarky@ivhs.com (amalarky@ivhs.com)> wrote:
I think part of problem is we keep treating and/or representing the 1609 defined PSID as an integer or an encoded integer (I've been just as bad).  It used to be an integer when it was a fixed length but it isn't any more.  Nor is it an encoded integer any more since it will be assigned as the entire octet sequence, not as an unencoded (numeric) value which is then encoded. 
 
I believe we should consider 1609 defined PSID in the context of: 
 
                The PSID is assigned as an ordered sequence of octets, of variable length, where the sequence is structured so that it has a deterministic length indicated by the first octet.
 
While an octet sequence longer than one octet can be represented  using hex, I don’t think we should express it as a number with hexidecimal digits  (e.g. 0xABCD…  or ABCD16) but use the hexidecimal representation (see IEEE 802) of an octet sequence (AB-CD-….  ).   By using the numeric representation we create the interpretation it can be treated as a single integer (whose octets are then sent least-significant octet first in 802.11 default) or purely as an ordered sequence of octets (in which case octets are transmitted in order from left to right).
 
Applying these, then the text changes as attached and ambiguity disappears.  Note also that we could also get more than 5 octets for PSID if we every had to (hope we never have to).  We do not need to specify the structure extension at this time.
 
 Note this in no way changes the PSID we have agreed to - the issue is one of clarity in the text.
 
Alastair Malarky
Chief Engineer & Design Integrity Director
Mark IV Industries,  IVHS Division
amalarky@ivhs.com (amalarky@ivhs.com)
Tel: (l) 905 624 3020 ext. 1203
Fax: (1) 905 624 4572
 
This communication may be privileged and may contain confidential information for the intended recipients. If you are not an intended recipient, please be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you received this electronic message in error, please notify the sender and delete the copy you received.

 

From: stds-p1609@ieee.org (stds-p1609@ieee.org) [mailto:stds-p1609@ieee.org (stds-p1609@ieee.org)] On Behalf Of John Moring

Sent: Wednesday, July 21, 2010 6:55 PM
To: '1609'
Subject: 1609.3 comment - PSID description



 
I have been working with Alastair (with some help from William) in resolving comments #16 - #18 in the recirculation ballot.  I’ve attached a file to address the issue described below.  It’s taken me a couple days of thought and research to arrive at the conclusion that this is our best solution.  Please post any thoughts to the reflector. If needed we can include discussion of this matter on Friday’s 1609.3 comment resolution call.  Refer to 160-9.3 subclause 8.1.3.
 
The issue is that there is potential ambiguity in the length of a PSID, which for example could cause a receiver of a WSA or WSM to be unable to parse the message.  We have specified the “length bits” (i.e., the bit string from which the octet length of the PSID can be deduced) as the MSBs of the field.  This is desirable because the PSID values for any given octet length are contiguous, as shown in Table 4 in 8.1.3.  In normal 802.11/1609 convention, MSBs are placed LAST within a field, so for example, a 2-octet PSID would have its length code (MSBs) in the second byte.  A 3-octet PSID would have its length code in the third byte.  A receiver would not be able to reliably distinguish among different length PSIDs, because the length code location is not deterministic. 
 
Similar situations have been encountered in the past.  MAC Address in 802 and Organization Identifier in 802.11p are specified to be sent higher-order octet
Thus the PSID will be interpreted just as we’ve described previously, but it will be structured such that the most significant octet is always first.  (There is no effect on 1-octet PSIDs).  The attached document shows how 8.1.3 has been updated to reflect this, and a new annex to illustrate the structure via examples.
 
Comments welcome.
 
JTM
 
 





 





 

This post originally appeared on the committee list server

[DC Kelley]

So just to be clear in ASN (which is always big endian) the OCTETs in something like:  PSID ::= OCTET (SIZE(1...4) are sent over the wire with the first "octet 1" then "octet 2" etc up to "octet  N"  

More on the encoding details, which follow a pattern of <tag> <length> <data>

In the case of BER/DER/CER encoding this is preceded by a tag (which depend on the content of use and tel you if it is  simple (no internal content defined) or a compo8nt (has further internal content). Then comes a length bytes (which on this case would be a "signed" value between one and four  (note that a MSB being set to one in this odd case is used to indicate that another length bytes follows, the last length bytes ALWAYS has a MSB of zero).  The comes the actual sequence of octets, the data itself in the order described above.

In the case of PER (aligned on byes boundaries of unaligned (i.e it starts on the next available bit) I am no an expert.  Bu the tag is often no needed (typical only need if multiple possible elements could follow next) then the length (which in the unaligned case will be two bits I belive, and in the align case will use a while byte) then the octets, form one to four 8 bit items.

Repeating what Alasiar says with a trivial tweak:

[DC Kelley]

When I said signed I meant signed. 

Thus:  The transmission space for any INTEGER requires a bit be used for sign, a first bit of one implies a negative number.   As a result the range one can fit in a single byte is -128 to  +127, and not 0 to 255 as people often mistakenly think.  By contrast, an OCTET allows an unsigned range of values from 0 to 255 in a single byte.  This is rule is true in all forms of ASN encoding.  
 
Dick:  I have no idea why or how you can come to  the apparent conclusion that this mean negative numbers are not supported (this would normally be called UNSIGNED).  Such was not my intent.  Rather, you need to be very cautious when you see a MSB set to a one as ASN also uses this as way to indicate that another byte of data follows.  When length and tags exceed a single bytes you will see this used.  Such use is not "a negative" value but an extension indicator. You can find this discussed in more detail in the SAE DSRC guide sections on ASN encoding, see http://www.sae.org/standardsdev/dsrc/DSRCImplementationGuide.pdf  chapter six.

This "no unsigned rule" is one of the reasons you often see the statement OCTET(SIZE(1)) when you might otherwise expect to see INTEGER(0..255) in an ASN specification.  The author is trying to "cheat" the value range he really wants into the single byte space.   The actual payload space for INTEGER(0..255) with a value above 127 requires TWO bytes.

As I now know we expect to use OCTET (and not INT) I will limit replies to things that bear on that. 

> DCK said: And note that an OCTET will allow 253 1 byte long PSIDs, not 127 or 63 as other have suggested. 
There is typo here, this should read:  And note that an OCTET will allow 255 1 byte long PSIDs, not 127 or 63 as others have suggested. 
'
[RR >] So how would PSID = 1 and PSID = 256 get encoded using OCTET (SIZE(1..4))?  See note above about a length determinant.

[/i][/b]The  patten is always <tag> <length> <value> in all encodings, in PER the tag can at times be dropped due to context.  In unaligned only as many bits as needed are used (extra leading zeros or ones are dropped, but the first is still needed), in aligned and also in BER/DER/CER forms then whole bytes are used.  Sending this with an OCTET value of 0x01 or with 0x0100 (256) would be as follows for any of the unaligned variants (i.e. it lines up on byte boundaries) :

<tag> 0x01  0x01           -- the value one
<tag> 0x02  0x01 0x00      -- the value 256

FYI, I am not an expert in PER forms, I consider myself one in the BER/DER/CER forms.
Note that John's original proposal uses a different form for the length value, a set of bits indicating how many bytes are to follow. 
I can live with either.

Regards,
DC Kelley


At 01:30 AM 7/29/2010 -0700, Richard Roy wrote:

[HJFischer at fischer-tech.info]

Dear all,


just to clarify a bit the approach in ASN.1.

INTEGER(0..255) is an element of one byte size containing an unsigned Integer with possible values in the range from 0 up to 255.
Integer(-128..127) is an element of one byte size containing a signed Integer with possible values in the range from -128 up to 127.
ASN.1 allows to define further Integer data types.

To summarize. In ASN.1 an Integer data element not necessarily contains a signed integer!

Applying PER, then - for the two examples above - only the one byte is transmitted. No sign bits are added.


My two cents.
Hans-Joachim


Am 29.07.2010 17:53, schrieb David Kelley:

[AMalarky at IVHS.COM]

Over the last few days there has been a large volume of correspondence regarding different ASN.1 type definitions, etc,  to try to get something that satisfies the ETSI objectives:
<![if !supportLists]>·         <![endif]>a global identifier structure for ITS,
<![if !supportLists]>·         <![endif]>aligns with the 1609 use of PSID,
<![if !supportLists]>·         <![endif]>satisfies the ETSI requirement for use of unaligned PER.
 
Meanwhile 1609 does not use PER encoding in messages and has developed a PSID that is octet efficient.
 
No matter what way I look at it I keep running into a stumbling block highlighted by the following points. 
 
<![if !supportLists]>1.       <![endif]>It is impossible to come up with a PER encoded output that is the same as the value being encoded except in limited (e.g. single or dual octet non-negative integer range) cases. 
 
I make this statement because, from my read of X.691, (please excuse the simplification - it is too complex otherwise) the generic form of a PER encoded value is <extension flag> <length> <value or value offset in range>
<extension flag> is a single bit if the ASN.1 definition supports extension  (the infamous "…")
<length> is not always present for all subsets of values, but if present is a fixed size (in bits).  It is generally present for larger ranges of values, such as PSID has
<value or value offset in range> is only the the same as value if it is an octet type or if the value is a small integer, and the allowed range starts at 0.
 
Thus the numeric or other representation of the value in applications and in SAPs or APIs as a parameter or in non encoded message structures will not match the octet field that is packed into the message when PER coding (aligned or unaligned) is performed.
 
2.   This is totally different from the PSID of 1609 where the value is always the same everywhere - there is no coding.  Our WSMP and WSA message structures, MIB and SAPs are all in line with this philosophy.
 
3.    It is highly unlikely that an ASN.1 definition type can be found that when PER encoded matches our PSID but has the property that every PSID value has a unique corresponding unencoded value in the ASN.1 type range.
 
I don't have hard proof of this, but because our <length> indication is variable and PER's is fixed I think it highly unlikely. 
 
I think the problem is broader than one that just an ASN.1 type definition change for PSID can solve.     
 
Maybe the first step should be to clearly define the problem and the constraints, then develop a solution, if one is possible.  I for one am unclear on a number of points, e.g.:
<![if !supportLists]>·         <![endif]>the extent of the ETSI requirement for use of unaligned PER.  We have only discussed the PSID at this point.
<![if !supportLists]>·         <![endif]>whether it is acceptable to have a bit field in a  WAVE message to indicate if the rest of the header(or just the PSID)  is encoded in PER or not
<![if !supportLists]>·         <![endif]>where the boundary lies between use of uncoded values and encoded values - are they encoded in certain SAPs?
<![if !supportLists]>·         <![endif]>What are the schedule implications of setting up a global ITS-AID and the impact to WAVE developers.
 
Alastair Malarky
Chief Engineer & Design Integrity Director
Mark IV Industries,  IVHS Division
amalarky@ivhs.com (amalarky@ivhs.com)
Tel: (l) 905 624 3020 ext. 1203
Fax: (1) 905 624 4572
 
This communication may be privileged and may contain confidential information for the intended recipients. If you are not an intended recipient, please be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you received this electronic message in error, please notify the sender and delete the copy you received.

 

This post originally appeared on the committee list server

[HJFischer at fischer-tech.info]

Dear Alastair,


thank you for your contribution.

Basically I share your view, that first we need to identify what is needed, and then we need a solution.
The first step we already did in various SDOs independent from each other: we need a unique identifier for ITS applications.
Then we noticed, that we need a harmonized approach for the numbers (still I am not talking about encoding)
Then we noticed, that due to the very limited bandwidth available, we need to be efficient in the radio link, not wasting channel capacity for non-used bits and bytes. Thus we need to think on the one hand side about an efficient coding, and on the other hand side on a sufficiently large number range. A solution considered was a variable length field.
Then we noticed, that for the purpose of global interoperability, we need the same number presentation (encoding) in the wireless links.

You see, we already did all of these steps.

Now we need to agree on a presentation of the number in a frame exchanged between stations.

For some good reasons, ETSI, CEN and ISO - to the uppermost possible extent - are using a formal approach to present data elements, which is ASN.1 unaligned PER (see also the message from Paul Thorpe to David Kelley on PER).
When it comes to implementation, you are free to use ASN.1 or a hand-coded binary equivalent approach. Essential is the sequence of bits in the radio link - Interoperability!

Note that STF 404 also will provide recommendations on the management of these numbers.


My two cents for successful continuation of EU/US cooperation

Sincerely
Hans-Joachim

Am 30.07.2010 07:20, schrieb Alastair Malarky:

[AMalarky at IVHS.COM]

Thankyou Dr Fischer.

I understand the wish for a global ITS identifier, but I have seen nothing that justifies the statement:
"For the purpose of global interoperability, we need the same number presentation (encoding) in the wireless links."

My concern is this statement has open ended scope, and perhaps that is what need to be clarified.

To understand the implications to WAVE we need to understand the scope of what is being recommended by STF 404.

Within application created data payloads? (NB This is transparent to WAVE but may affects other SDOs in the distribution)
In parameters at the SAP/API interface to WAVE? (NB If the parameter is being passed between the higher layer and WME then I assume it would not be encoded at that point)
Within the WAVE specific protocol created headers on data or management messages? (Why? - these are only used by the WMEs)
Within WAVE management message data fields ? (Why? - these are only used by the WMEs)

Between two instances of devices using different communication protocol standards? (NB Yes to this question far exceeds the scope of just a global identifier since this applies to all fields in the frame of a message).

It seems to me the scope for a global ITS must be clarified with sound justification and properly communicated to the SDOs and agreed before we proceed to the step of choosing a solution.

Can you please provide this scope clarification and justification.


From: Dr. Hans-Joachim Fischer <HJFischer@fischer-tech.info>
To: Alastair Malarky
Cc: dickroy@alum.mit.edu <dickroy@alum.mit.edu>; 'David Kelley' <davidkelley@ITSWARE.NET>; '1609' <stds-p1609@IEEE.ORG>; 'John Moring' <john@MORING.NET>; 'Knut Evensen' <Knut.Evensen@q-free.com>
Sent: Fri Jul 30 01:40:50 2010
Subject: Re: 1609.3 comment - PSID description


Dear Alastair,


thank you for your contribution.

Basically I share your view, that first we need to identify what is needed, and then we need a solution.
The first step we already did in various SDOs independent from each other: we need a unique identifier for ITS applications.
Then we noticed, that we need a harmonized approach for the numbers (still I am not talking about encoding)
Then we noticed, that due to the very limited bandwidth available, we need to be efficient in the radio link, not wasting channel capacity for non-used bits and bytes. Thus we need to think on the one hand side about an efficient coding, and on the other hand side on a sufficiently large number range. A solution considered was a variable length field.
Then we noticed, that for the purpose of global interoperability, we need the same number presentation (encoding) in the wireless links.

You see, we already did all of these steps.

Now we need to agree on a presentation of the number in a frame exchanged between stations.

For some good reasons, ETSI, CEN and ISO - to the uppermost possible extent - are using a formal approach to present data elements, which is ASN.1 unaligned PER (see also the message from Paul Thorpe to David Kelley on PER).
When it comes to implementation, you are free to use ASN.1 or a hand-coded binary equivalent approach. Essential is the sequence of bits in the radio link - Interoperability!

Note that STF 404 also will provide recommendations on the management of these numbers.


My two cents for successful continuation of EU/US cooperation

Sincerely
Hans-Joachim

Am 30.07.2010 07:20, schrieb Alastair Malarky:

[dickroy]

Some comments below …
 

From: stds-p1609@IEEE.ORG [mailto:stds-p1609@IEEE.ORG] On Behalf Of Alastair Malarky
Sent: Friday, July 30, 2010 4:50 AM
To: 'HJFischer@fischer-tech.info'
Cc: 'dickroy@alum.mit.edu'; 'davidkelley@ITSWARE.NET'; 'stds-p1609@IEEE.ORG'; 'john@moring.net'; 'Knut.Evensen@q-free.com'
Subject: Re: 1609.3 comment - PSID description

 
Thankyou Dr Fischer.

I understand the wish for a global ITS identifier, but I have seen nothing that justifies the statement:
"For the purpose of global interoperability, we need the same number presentation (encoding) in the wireless links."
[RR >] The reasoning here is that ultimately it would be of great benefit to ITS going forward if the WAVE/FAST protocol on the 5.9GHz links (where safety of life and property channels and the need for high speed data exchange predominate) were globally harmonized.  OEMs of5.9GHz devices and applications would then only have to program to a single protocol, rather than a larger set of region-dependent protocols.  It’s not that we can’t get around not having a common protocol globally, it’s an efficiency, maintenance, and ultimately good be a liability issue.     
 


My concern is this statement has open ended scope, and perhaps that is what need to be clarified.

To understand the implications to WAVE we need to understand the scope of what is being recommended by STF 404.

Within application created data payloads? (NB This is transparent to WAVE but may affects other SDOs in the distribution)
In parameters at the SAP/API interface to WAVE? (NB If the parameter is being passed between the higher layer and WME then I assume it would not be encoded at that point)
Within the WAVE specific protocol created headers on data or management messages? (Why? - these are only used by the WMEs)
Within WAVE management message data fields ? (Why? - these are only used by the WMEs)

Between two instances of devices using different communication protocol standards? (NB Yes to this question far exceeds the scope of just a global identifier since this applies to all fields in the frame of a message).
[RR >] The idea would be as noted above to come up with a single global fast “network” protocol for 5.9 communications (along side IPv6 for obvious reasons).
 
 

It seems to me the scope for a global ITS must be clarified with sound justification and properly communicated to the SDOs and agreed before we proceed to the step of choosing a solution.

Can you please provide this scope clarification and justification.
[RR >] The scope and justification would be those given above.

 

From: Dr. Hans-Joachim Fischer <HJFischer@fischer-tech.info>
To: Alastair Malarky
Cc: dickroy@alum.mit.edu <dickroy@alum.mit.edu>; 'David Kelley' <davidkelley@ITSWARE.NET>; '1609' <stds-p1609@IEEE.ORG>; 'John Moring' <john@MORING.NET>; 'Knut Evensen' <Knut.Evensen@q-free.com>
Sent: Fri Jul 30 01:40:50 2010
Subject: Re: 1609.3 comment - PSID description

Dear Alastair,


thank you for your contribution.

Basically I share your view, that first we need to identify what is needed, and then we need a solution.
The first step we already did in various SDOs independent from each other: we need a unique identifier for ITS applications.
Then we noticed, that we need a harmonized approach for the numbers (still I am not talking about encoding)
Then we noticed, that due to the very limited bandwidth available, we need to be efficient in the radio link, not wasting channel capacity for non-used bits and bytes. Thus we need to think on the one hand side about an efficient coding, and on the other hand side on a sufficiently large number range. A solution considered was a variable length field.
Then we noticed, that for the purpose of global interoperability, we need the same number presentation (encoding) in the wireless links.

You see, we already did all of these steps.

Now we need to agree on a presentation of the number in a frame exchanged between stations.

For some good reasons, ETSI, CEN and ISO - to the uppermost possible extent - are using a formal approach to present data elements, which is ASN.1 unaligned PER (see also the message from Paul Thorpe to David Kelley on PER).
When it comes to implementation, you are free to use ASN.1 or a hand-coded binary equivalent approach. Essential is the sequence of bits in the radio link - Interoperability!

Note that STF 404 also will provide recommendations on the management of these numbers.


My two cents for successful continuation of EU/US cooperation

Sincerely
Hans-Joachim

Am 30.07.2010 07:20, schrieb Alastair Malarky:
<![endif]--> <![endif]-->Over the last few days there has been a large volume of correspondence regarding different ASN.1 type definitions, etc,  to try to get something that satisfies the ETSI objectives:
a global identifier structure for ITS,
aligns with the 1609 use of PSID,
satisfies the ETSI requirement for use of unaligned PER.
[RR >] Just a reminder, ETSI is not requiring the use of unaligned PER and is essentially considering two possibilities at the moment.  The first is what the 1609 WG called the DMK#2 encoding (very efficient and easily extensible), and the second is essentially ASN.1 unaligned PER encoding of the CHOICE type (gives 1 billion PSIDs but is not easily extensible beyond that 1 billion).  
 
Meanwhile 1609 does not use PER encoding in messages and has developed a PSID that is octet efficient.
[RR >] … and it is not ASN.1 BER octet encoding if I understand the any of the recent versions of clause 8.1.3.
 
No matter what way I look at it I keep running into a stumbling block highlighted by the following points. 
 
It is impossible to come up with a PER encoded output that is the same as the value being encoded except in limited (e.g. single or dual octet non-negative integer range) cases.
[RR >] Not quite true.  ASN.1 PER encoding of the CHOICE type works just fine (see the file I sent previously with the encoding shown).  It’s just that making it extensible beyond 1 billion PSIDs might be a bit messy. 
 
I make this statement because, from my read of X.691, (please excuse the simplification - it is too complex otherwise) the generic form of a PER encoded value is <extension flag> <length> <value or value offset in range>
<extension flag> is a single bit if the ASN.1 definition supports extension  (the infamous "…")
<length> is not always present for all subsets of values, but if present is a fixed size (in bits).  It is generally present for larger ranges of values, such as PSID has
<value or value offset in range> is only the the same as value if it is an octet type or if the value is a small integer, and the allowed range starts at 0.
 
Thus the numeric or other representation of the value in applications and in SAPs or APIs as a parameter or in non encoded message structures will not match the octet field that is packed into the message when PER coding (aligned or unaligned) is performed.
 
2.   This is totally different from the PSID of 1609 where the value is always the same everywhere - there is no coding.  Our WSMP and WSA message structures, MIB and SAPs are all in line with this philosophy.
 
3.    It is highly unlikely that an ASN.1 definition type can be found that when PER encoded matches our PSID but has the property that every PSID value has a unique corresponding unencoded value in the ASN.1 type range.
 
I don't have hard proof of this, but because our <length> indication is variable and PER's is fixed I think it highly unlikely.
[RR >] For the variable length-indicator version, I believe you are correct that there currently is no ASN.1 encoding that matches it.  An ASN.1 type would have to be defined using ECN ( and not being an ECN expert I couldn’t say how to do it:^))   
 
 
I think the problem is broader than one that just an ASN.1 type definition change for PSID can solve. 
[RR >] There would seem to be two possible ways in which an ASN type could be used.  We could use the CHOICE type or we could create a new type using ECN. That having been said, I think a more interesting discussion would be one concerning the relative value of ASN encoding for only some of the information contained in a given PDU.  Neither WAVE nor FAST as they are currently specified have ASN encodings for all the elements of their service advertisement PDUs.  I am still wondering why ASN encoding of the ITS-AID/PSID value is of importance.  If there happens to be an encoding that could fit our needs (like CHOICE encoding), well that’s interesting and may be of some value in describing the encoding, but other than that, I don’t see the point.  If anyone has a good argument why ASN encoding is important for our WAVE/FAST PDUs. I for one would be interested in hearing it.
    
 
Maybe the first step should be to clearly define the problem and the constraints, then develop a solution, if one is possible.  I for one am unclear on a number of points, e.g.:
the extent of the ETSI requirement for use of unaligned PER.  We have only discussed the PSID at this point.
whether it is acceptable to have a bit field in a  WAVE message to indicate if the rest of the header(or just the PSID)  is encoded in PER or not
[RR >] Interestingly, the general issue you raise here is within the purview of the “presentation layer”, a layer we have largely ignored to date.  I think this is a good topic for further discussion, i.e. is there a need for a service at the presentation layer level to address various data presentations (ASN / PER / aligned / unaligned / WAVE1 / FAST1 / etc…).   
where the boundary lies between use of uncoded values and encoded values - are they encoded in certain SAPs?
What are the schedule implications of setting up a global ITS-AID and the impact to WAVE developers.
[RR >] I would suggest that there are numerous ways in which a global ITS-AID registration procedure can be arrived at, including setting up a single registration authority (UN-ECE WP29 is a possible candidate), that would have little if any impact on scheduling.  It may be that we start with the IEEE RAC that we have now and transition to some other at a later date if necessary.   Perhaps the biggest issue to be decided would be how much to charge for the numbers, and where the funds actually end up.  As long as we all agree on the basic principles of how the numbers are to be assigned, and that a single global registration scheme is worth pursuing, then the rest should just be attention to the details.
 
Cheers,
 
RR   
 
Alastair Malarky
Chief Engineer & Design Integrity Director
Mark IV Industries,  IVHS Division
amalarky@ivhs.com (amalarky@ivhs.com)
Tel: (l) 905 624 3020 ext. 1203
Fax: (1) 905 624 4572
 
This communication may be privileged and may contain confidential information for the intended recipients. If you are not an intended recipient, please be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you received this electronic message in error, please notify the sender and delete the copy you received.

 

[dickroy]

See comments below … and if I am correct, Dave Kelley’s email filter is replacing all occurrences of ellipses (three dots) with ampersands, so you’ll have to watch out for that.
 

From: stds-p1609@ieee.org [mailto:stds-p1609@ieee.org] On Behalf Of Dr. Hans-Joachim Fischer
Sent: Thursday, July 29, 2010 9:07 AM
To: David Kelley
Cc: dickroy@alum.mit.edu; '1609'; 'Alastair Malarky'; 'John Moring'; 'Knut Evensen'
Subject: Re: 1609.3 comment - PSID description

 
Dear all,


just to clarify a bit the approach in ASN.1.

INTEGER(0..255) is an element of one byte size containing an unsigned Integer with possible values in the range from 0 up to 255.
Integer(-128..127) is an element of one byte size containing a signed Integer with possible values in the range from -128 up to 127.
ASN.1 allows to define further Integer data types.

To summarize. In ASN.1 an Integer data element not necessarily contains a signed integer!

Applying PER, then - for the two examples above - only the one byte is transmitted. No sign bits are added.


My two cents.
Hans-Joachim
[RR >] This is what I was trying to say below.  I believe Hans’ description above is correct.



Am 29.07.2010 17:53, schrieb David Kelley:


When I said signed I meant signed. 

Thus:  The transmission space for any INTEGER requires a bit be used for sign, a first bit of one implies a negative number.   As a result the range one can fit in a single byte is -128 to  +127, and not 0 to 255 as people often mistakenly think.  By contrast, an OCTET allows an unsigned range of values from 0 to 255 in a single byte.  This is rule is true in all forms of ASN encoding.  
 
Dick:  I have no idea why or how you can come to  the apparent conclusion that this mean negative numbers are not supported (this would normally be called UNSIGNED).  Such was not my intent.  Rather, you need to be very cautious when you see a MSB set to a one as ASN also uses this as way to indicate that another byte of data follows.  When length and tags exceed a single bytes you will see this used.  Such use is not "a negative" value but an extension indicator. You can find this discussed in more detail in the SAE DSRC guide sections on ASN encoding, see http://www.sae.org/standardsdev/dsrc/DSRCImplementationGuide.pdf  chapter six.
[RR >] I’m not the expert, however I believe what you say is true for tags and lengths, just not for integer types … see Hans’ discussion above.


This "no unsigned rule" is one of the reasons you often see the statement OCTET(SIZE(1)) when you might otherwise expect to see INTEGER(0..255) in an ASN specification.  The author is trying to "cheat" the value range he really wants into the single byte space.   The actual payload space for INTEGER(0..255) with a value above 127 requires TWO bytes.
[RR >] Don’t think so. See above.
 

As I now know we expect to use OCTET (and not INT) I will limit replies to things that bear on that. 
[RR >] Well, not so fast.  I’m thinking that based on Alastair’s cool observations, we may be using CHOICE and INTEGER types!


> DCK said: And note that an OCTET will allow 253 1 byte long PSIDs, not 127 or 63 as other have suggested. 
There is typo here, this should read:  And note that an OCTET will allow 255 1 byte long PSIDs, not 127 or 63 as others have suggested. 
'
[RR >] So how would PSID = 1 and PSID = 256 get encoded using OCTET (SIZE(1..4))?  See note above about a length determinant.

The  patten is always <tag> <length> <value> in all encodings, in PER the tag can at times be dropped due to context.  In unaligned only as many bits as needed are used (extra leading zeros or ones are dropped, but the first is still needed), in aligned and also in BER/DER/CER forms then whole bytes are used.  Sending this with an OCTET value of 0x01 or with 0x0100 (256) would be as follows for any of the unaligned variants (i.e. it lines up on byte boundaries) :

<tag> 0x01  0x01           -- the value one
<tag> 0x02  0x01 0x00      -- the value 256
[RR >] Agreed … and this is why we wouldn’t use the OCTET type.  It adds at least two extra bytes to ALL PSID encodings when compared to the alternatives we are considering.

FYI, I am not an expert in PER forms, I consider myself one in the BER/DER/CER forms.
Note that John's original proposal uses a different form for the length value, a set of bits indicating how many bytes are to follow. 
I can live with either.
[RR >] I’m no expert on any of the encodings:^)).  I’d like to get your thoughts on Alastair’s revised CHOICE implementation. It sure looks interesting to me!
 
Cheers,
 
RR


Regards,
DC Kelley


At 01:30 AM 7/29/2010 -0700, Richard Roy wrote:


 
From: stds-p1609@ieee.org (stds-p1609@ieee.org) [mailto:stds-p1609@ieee.org (stds-p1609@ieee.org)] On Behalf Of David Kelley
Sent: Wednesday, July 28, 2010 11:01 PM
To: '1609'
Cc: 'Alastair Malarky'; 'John Moring'; 'Knut Evensen'; Dr. Hans-Joachim Fischer; dickroy@alum.mit.edu (dickroy@alum.mit.edu)
Subject: Re: 1609.3 comment - PSID description

 


Sorry to be a bit late on this thread but the critical point seems to now turn on the extensibility indication (the "..." that is part of the actual ASN)

[RR >] Seems that some email filter changed &to &in my example below & hmmmmmm????

 

Dick's switch example does NOT seem to have this in it (it probably should be present), do we in fact need to have the ability to add a 5th byte (or more), if so we will need that "..." back into the specification and the final binary form of the PER encoding differs due to it as Dr. Hans-Joachim Fischer correctly notes in the below.

[RR >] What Hans was saying below is that unaligned PER encoding of INTEGER(0..127,&) is not being used, but that unaligned PER is being used elsewhere.

 

The "..." marker literally means "wait, I may add more to my ASN right here at some time in the future so do not get too clever when you compress/encode this part" so we might be better off just adding a 5th byte now (if that is the ultimate limit) and solving things that way. [ASN tip:  When you can avoid using the "..." you should always do so, add it when there an unknown point where new content may come to exist in your next edtion]

[RR >] It is very unlikely we would need another octet & currently with 4 octets we have at least 250 million numbers.  If 1000 numbers are assigned every day of the year, it will take around 1000 years to exhaust the numbers!  Im not going to be around to blame anyway:^)))  That having been said, the current version of 8.1.3 has 1111 as a reserved bit pattern, so in 1000 years or so, someone else can amend the spec to use this reserved bit patter and increase the number space.

 

Also, I remain confused as to if this will be specified as an OCTET or an INTEGER, they are not the same, nor do the same useful ranges fit in the same space (as all INTs are signed). 

[RR >] If by all INTs are signed you mean that ASN.1 does not support non-negative integer encodings, I guess I have to disagree since as I read X.691-2008, non-negative integer encodings are allowed. Did you mean something else?

What is the actual plan?  John's post of early today strongly suggested that this is an OCTET and NOT an INTEGER as Dick used  (which I tend to think is the best use of the bits). Can we confirm that remains the plan.  

[RR >] Do you mean confirm that we want to encode the PSID as an ASN.1 OCTET type?

And note that an OCTET will allow 253 1 byte long PSIDs, not 127 or 63 as other have suggested. 

[RR >] How is the sizeencoded if all the bits of the first octet can be PSID value bits?  As I read X.691, the OCTET type requires a length determinant encoding the whole number nto precede the n-octet bit-field.  If this is true, then even 1-octet PSIDs require two octets in the bit-field to be transmitted.

If so then the actual ASN does not need the "..." as in Dicks example,

[RR >] The example I gave was simply to respond to Alastairs request to see what unaligned PER encoding of INTEGER(0..127,&) looks like, and to demonstrate why unaligned PER encoding of INTEGER(0..127,&) would not be something we want to consider for encoding PSIDs.

and the 4 could be replaced with a 5 in the below line if we still need it. 

PSID = OCTET (SIZE(1..4))  -- that's all you need to have in "pure" ASN world, encoding does the rest.

[RR >] So how would PSID = 1 and PSID = 256 get encoded using OCTET (SIZE(1..4))?  See note above about a length determinant.

 
If you feel a need to precede this with an unique/custom "length" encoding, consider defining a further octet with the enumerated byte values for 1,2,3,4,5 bytes to follow (the definition of which comes from John's table).

[RR >] We are going through this optimization to save a byte or two.  Adding a byte defeats this purpose.  This is not to suggest that a debate about the value of saving a single byte has no merit.  Its just that if the thought is that a single byte matters, then we should be trying to eliminate bytes, not add them.  I personally dont see much value in byte-saving when the packets being sent are in the 100s of bytes anyway, but I also dont think we should be careless with bytes either.  A byte saved is a byte earned!

 

Cheers,

 

RR

Just trying to get things perfect and move on...
Regards,
DC Kelley


At 06:37 AM 7/29/2010 +0200, Dr. Hans-Joachim Fischer wrote:


Just a singel comment below

Hans-Joachim

Am 29.07.2010 04:02, schrieb Richard Roy:
-cut- header


Just to be clear - is the recommendation from task force STF 404 still in effect or does the discrepancy mean that it has to be revisited ?

[RR >] Perhaps a bit of context here.  STF 404 is an ETSI task force whose job is to come up with the Europeanstandard on how the PSID will be encoded, recommend a registration authority, etc., as Hans explained in his previous email.  Since that STF and the WG in charge of that STF (ETSI TC ITS WG2 Architecture) are very favorably disposed to international harmonization, especially with regard to the PSID, and since the STF has yet to finalize its findings (work is still ongoing), it is very likely that with a few joint discussions a single specification for international use could easily be achieved.   That having been said, I can assure you that the STF will not be recommending the unaligned PER encoding of INTEGER(0..127,&) for the PSID/ITS-AID/SID/ITS-SID or whatever it ends up being called.  As noted below, Hans prepared the info on the ASN.1 CHOICE type encoding in the file I sent previously. 

 

In summary, its safe to say that the STF, ETSI TC ITS, TC204WG16, etc., are very open to discussing and deciding on a single specification for the PSID. 

 

If it is still in effect, then I think the 1609 group still needs to see what INTEGER(0..127,&) looks like.  

[RR >] Heres an example:

 

psid INTEGER(0..127,&)  ::=128

 

Using unaligned PER encodes as

1 | 00000010 | 00000000 | 10000000

 

Pretty neat huh????  This is why no one is considering unaligned PER any longer.

We are still sticking to unaligned PER, but not for an ASN.1 type such as INTEGER(0..127,...). The problem is that the extension functionality "..." takes away all the benefits which are due to unaligned PER (efficient minimum size coding).


 

Cheers,

 

RR

 

Alastair Malarky

Chief Engineer & Design Integrity Director

Mark IV Industries,  IVHS Division

amalarky@ivhs.com (amalarky@ivhs.com)

Tel: (l) 905 624 3020 ext. 1203

Fax: (1) 905 624 4572

 

This communication may be privileged and may contain confidential information for the intended recipients. If you are not an intended recipient, please be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you received this electronic message in error, please notify the sender and delete the copy you received.

 

From: stds-p1609@ieee.org (stds-p1609@ieee.org) [mailto:stds-p1609@ieee.org (stds-p1609@ieee.org)] On Behalf Of Richard Roy
Sent: Wednesday, July 28, 2010 6:57 PM
To: 'John Moring'; '1609'
Cc: 'Dr. Hans-Joachim Fischer'; 'Knut Evensen'; 'Per Furnes'
Subject: RE: 1609.3 comment - PSID description

 

The material in PSID specification 100728.doclooks fine to me.

 

After an exchange of many emails with ASN experts and a thoroughreading (and re-reading) of X.691 (esp. clause 13), I believe the encoding that we (TC 204 WG16) originally claimed to be unaligned PER encoding of INTEGER(0..127,&) is not.  While it is DMK#2 as proposed by Doug and discussed in April, it is NOT unaligned PER encoding of INTEGER(0..127,&).  If this is still an encoding that the WG feels worth considering, I have attached proposed text for clause 8.1.3.  The one advantage discussed in April is that it is immediately extensible without having to change the specifications and use the reserved 1111 bitsto create an extension mechanism.  As I recall, the drawback was increased decoding complexity, but I could be wrong about this.

 

For consideration, if having a standard ASN.1 type encoding is deemed of value, and having 4 times the number of 4-octet PSIDs is iof interest, one of the encodings we discussed in April (the Fixed Size Length Code Option) turns out to be an ASN.1 choice type encoding.  The advantages are as given in the presentations from April, and the drawback would seem to be lack of extensibility (do we really need more than 1 billion PSIDs??).  I have attached a doc file that Hans created showing this encoding (for your viewing pleasure:^))).

 

For those interested in what unaligned PER encoding of INTEGER(0..127,&) would really look like, we can discuss over a beer in Annapolis!:^)))

 

Cheers,

 

RR

 

 
 

From: stds-p1609@ieee.org (stds-p1609@ieee.org) [mailto:stds-p1609@ieee.org (stds-p1609@ieee.org)] On Behalf Of John Moring
Sent: Wednesday, July 28, 2010 11:36 AM
To: '1609'
Subject: RE: 1609.3 comment - PSID description

 

Many thanks to Alastair and John K for hammering out a clear, concise, correct presentation of the PSID format.  The attached file shows the material I will add into the 1609.3 recirculation draft.  Comments welcome.

 

JTM

 
 
From: Alastair Malarky [mailto:AMalarky@ivhs.com (amalarky@ivhs.com)]
Sent: Monday, July 26, 2010 6:45 PM
To: John Kenney
Cc: John Moring; 1609
Subject: RE: 1609.3 comment - PSID description

 

See inline responses.

 

Alastair Malarky

Chief Engineer & Design Integrity Director

Mark IV Industries,  IVHS Division

amalarky@ivhs.com (amalarky@ivhs.com)

Tel: (l) 905 624 3020 ext. 1203

Fax: (1) 905 624 4572

 

This communication may be privileged and may contain confidential information for the intended recipients. If you are not an intended recipient, please be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you received this electronic message in error, please notify the sender and delete the copy you received.

 

From: John Kenney [mailto:jkenney@us.toyota-itc.com (jkenney@us.toyota-itc.com)]
Sent: Monday, July 26, 2010 4:35 PM
To: Alastair Malarky
Cc: John Moring; 1609
Subject: Re: 1609.3 comment - PSID description

 

Hi Alastair,

These are good clarifications.

 

A few suggestions regarding the text:

1) I would want the annex to be normative since that is the place (now that Figure 1 is gone) where the transmission order of octets is defined.  Alternatively, some clear statement in 8.1.3 could define the octet transmission order.

could change 3rd sentence to be normative:  "shall always be" instead of "are always".  Don't like to make example annex normative

 

2) in the 4th sentence, I find "treating the first octet as a numeric value" a bit unclear.  I realize you are mimicing the 802 language in the footnote.  Would it be accurate to say "The leftmost bits of the first octet specify the length of the PSID, as defined in Table 1."

The problem is leftmost is not as clear as it sounds - since effectively the most significant bits are on the right in the 802.11 definition (see examples), but on the left if we express it as a binary number (0b&..).  By defining most-significant it is unambiguous in either representation.  Suggest alternative wording might be "The most significant bits of the numeric value of  the first octet (Octet 0) specify&"


  I've also removed "in octets" after "length of the PSID" because to me that sounded like I should expect to interpret the most significant bits as a numeric value in units of octets, e.g. somehow the number 3 would be in those bits for a 3-octet PSID.

Okay


3) I think it could be confusing to use "x" as a "don't care bit value" in the leftmost column of Table 1, and as a "don't care hex digit value" in the rightmost column.  I'm wondering why we need the "x"s in the rightmost column.  I think the original text is better for that column, with a few extra hyphens so there is one after each pair of hex digits, i.e. 1-octet range is 00-7F, 2-octet range is 80-00 to BF-FF, 3-octet range is C0-00-00 to DF-FF-FF, and 4-octet range is E0-00-00-00 to EF-FF-FF-FF.  In the bottom row, the rightmost column could say "leftmost hex digit is F" rather than "Fx-...".

Okay except for F (see above.)


4) In the annex the text refers a couple of times to "the first octet," and we show numbered octets in the figures, i.e. Octet 0, Octet 1, etc.  It might be more clear to replace references to "the first octet" with "Octet 0".

Agreed - but need then to define octet numbering (8.1 doesn't).  Need to add something for that.

 - cut as the IEEE server keep rejecting the post with this part (John K image files and other text) -  cut- cut- cut- cut- cut-

[dickroy]

 
 

From: stds-p1609@ieee.org [mailto:stds-p1609@ieee.org] On Behalf Of Alastair Malarky
Sent: Thursday, July 29, 2010 5:34 AM
To: dickroy@alum.mit.edu; 'John Kenney'; 'John Moring'
Cc: '1609'
Subject: RE: 1609.3 comment - PSID description

 
I don't agree with the changes. 
 
There is no MSO and LSO.  This would be treating the PSID as a number - instead of as a ordered sequence of octets, each of which is a number.  
[RR >] In my thinking, the PSID is a number/integer assigned by a registration authority from a set of numbers/integers that they are told they can assign.  We can change this if we think there is a better way, e.g. assigning a sequence of octets expressed in hexadecimal representation, or a string of bits if that appears to be a better choice. Not sure it matters much except to the guy doing the assignment and the guy buying the number(s).  In the end, the lowest common denominator is that the PSID ultimately is a unique (hopefully:^)) string of bits to be stored and transmitted over the air. How those bits are transmitted is something all of our standards must specify.  More below …
 
AB-CD-EF, i.e. a sequence of octets expressed in hexadecimal representation, is really expressing a sequence of numbers [ 0xAB 0xCD 0xEF ]  and not a single number 0xABCDEF.   There is no implied ranking of significance between the individual numbers in the sequence of octets by the representation.
 
The term hexidecimal representation clearly expresses the order : The representation of a sequence of octet values in which the values of the individual octets are displayed in order from left to right
 
The first octet in the ordered sequence is the leftmost octet in the representation, and we are defining this to be Octet 0.
 
Also your change treats transmission as a serial bit stream, which OFDM is not.  The 802.11 MAC passes octets to the PLCP, not bits.  1609 only specifies extensions to the MAC layer and above.
Note the bit order representation (LSB to MSB in figures, B0 to Bn) is a convention for figures defined in 802.11, not intended to define bit transmission order, and 1609 has stayed with that convention.
[RR >] Agreed.  I wasn’t comfortable with specifying bit transmission order for just this reason.  Thanks for the reminder.  This also clearly points out all we need to concern ourselves with at the “networking layer” (which is what 1609 is supposed to be about) is the ordering of the octets in the NPDU.  The lower layers are tasked with ensuring the NPDUs arrive at their destination with octet-ordering preserved. So once we specify how the PSID value (integer or octet) is encoded in the octet stream that becomes the contents of the NPDU, the networking layer job is complete.
 
Cheers,
 
RR 
 
Alastair Malarky
Chief Engineer & Design Integrity Director
Mark IV Industries,  IVHS Division
amalarky@ivhs.com (amalarky@ivhs.com)
Tel: (l) 905 624 3020 ext. 1203
Fax: (1) 905 624 4572
 
This communication may be privileged and may contain confidential information for the intended recipients. If you are not an intended recipient, please be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you received this electronic message in error, please notify the sender and delete the copy you received.

 
From: stds-p1609@ieee.org [mailto:stds-p1609@ieee.org] On Behalf Of Richard Roy
Sent: Wednesday, July 28, 2010 11:45 PM
To: 'John Kenney'; 'John Moring'
Cc: '1609'
Subject: RE: 1609.3 comment - PSID description


 
 
 

From: stds-p1609@IEEE.ORG [mailto:stds-p1609@IEEE.ORG] On Behalf Of John Kenney
Sent: Wednesday, July 28, 2010 12:00 PM
To: John Moring
Cc: 1609
Subject: Re: 1609.3 comment - PSID description

 
Hi John,

Thanks as usual for pulling this together.  I think this is more clear than the prior version.


I would feel more comfortable if the definition of hexadecimal representation were in our normative definition section than in a footnote.  I think there may be an IEEE style issue having what is essentially normative text in a footnote.
[RR >] I don’t think footnotes are allowed to contain normative test. 
 
That having been said, I think what’s missing from the text is a clear indication that octet 0 is the MSO (most significant octet)   The example in the Annex indicates this, but it’s not in the text. I am assuming that’s what’s meant anyway.  Also, nowhere does it state which bit is transmitted first, MSB or LSB.  Seems to me, this should be normative, e.g “The order of transmission shall be MSO (Octet 0) first, followed by all other octets in increasing order to the LSO (octet n), and each octet shall be transmitted LSB (B0) to MSB (B7).” Naturally reverse things if it’s meant to be MSB to LSB instead.  I’ve attached a revision to reflect these changes.
 
Cheers,
 
RR

 

The only other comment is that the clause number, 8.1.3, and the title of the clause are not separated by a space.  I assume when you put this in the real document that will be taken care of.

 

Thanks,

John



 

On Wed, Jul 28, 2010 at 11:36 AM, John Moring <john@moring.net (john@moring.net)> wrote:
Many thanks to Alastair and John K for hammering out a clear, concise, correct presentation of the PSID format.  The attached file shows the material I will add into the 1609.3 recirculation draft.  Comments welcome.
 
JTM
 


From: Alastair Malarky [mailto:AMalarky@ivhs.com (amalarky@ivhs.com)]
Sent: Monday, July 26, 2010 6:45 PM
To: John Kenney

Cc: John Moring; 1609
Subject: RE: 1609.3 comment - PSID description

 
See inline responses.
 
Alastair Malarky
Chief Engineer & Design Integrity Director
Mark IV Industries,  IVHS Division
amalarky@ivhs.com (amalarky@ivhs.com)
Tel: (l) 905 624 3020 ext. 1203
Fax: (1) 905 624 4572
 
This communication may be privileged and may contain confidential information for the intended recipients. If you are not an intended recipient, please be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you received this electronic message in error, please notify the sender and delete the copy you received.
 
From: John Kenney [mailto:jkenney@us.toyota-itc.com (jkenney@us.toyota-itc.com)]
Sent: Monday, July 26, 2010 4:35 PM
To: Alastair Malarky
Cc: John Moring; 1609
Subject: Re: 1609.3 comment - PSID description

 
Hi Alastair,

These are good clarifications.

 

A few suggestions regarding the text:

1) I would want the annex to be normative since that is the place (now that Figure 1 is gone) where the transmission order of octets is defined.  Alternatively, some clear statement in 8.1.3 could define the octet transmission order.
could change 3rd sentence to be normative:  "shall always be" instead of "are always".  Don't like to make example annex normative
 

2) in the 4th sentence, I find "treating the first octet as a numeric value" a bit unclear.  I realize you are mimicing the 802 language in the footnote.  Would it be accurate to say "The leftmost bits of the first octet specify the length of the PSID, as defined in Table 1."
The problem is leftmost is not as clear as it sounds - since effectively the most significant bits are on the right in the 802.11 definition (see examples), but on the left if we express it as a binary number (0b…..).  By defining most-significant it is unambiguous in either representation.  Suggest alternative wording might be "The most significant bits of the numeric value of  the first octet (Octet 0) specify…"
 
  I've also removed "in octets" after "length of the PSID" because to me that sounded like I should expect to interpret the most significant bits as a numeric value in units of octets, e.g. somehow the number 3 would be in those bits for a 3-octet PSID.
Okay
 

3) I think it could be confusing to use "x" as a "don't care bit value" in the leftmost column of Table 1, and as a "don't care hex digit value" in the rightmost column.  I'm wondering why we need the "x"s in the rightmost column.  I think the original text is better for that column, with a few extra hyphens so there is one after each pair of hex digits, i.e. 1-octet range is 00-7F, 2-octet range is 80-00 to BF-FF, 3-octet range is C0-00-00 to DF-FF-FF, and 4-octet range is E0-00-00-00 to EF-FF-FF-FF.  In the bottom row, the rightmost column could say "leftmost hex digit is F" rather than "Fx-...".
Okay except for F (see above.)
 

4) In the annex the text refers a couple of times to "the first octet," and we show numbered octets in the figures, i.e. Octet 0, Octet 1, etc.  It might be more clear to replace references to "the first octet" with "Octet 0". 
Agreed - but need then to define octet numbering (8.1 doesn't).  Need to add something for that.
 
 Clasue 8.1 discusses bit numbers across a multi-octet field, and the numbering does not restart within each octet.  Given that, we might want to continue the numbering in Octet 1 with B8 through B15, rather than B0 through B7.  Same for Octet 2: B16 through B23.
The problem with numbering it as a sequential set of bits is that it tends to lead to people thinking of it a single numeric value.  I prefer to think of each octet as a sub-field of PSID.  Then the representation makes sense.   Also when transmitting messages the MAC passes single octets to the PLCP (sublayer of PHY) and on-air there aren’t serial bits.  I think the following may be a better way to represent it:
 
[img]cid:image001.gif@01cb304f.42d424a0[/img]

 

Hope this helps,

John

 

 

 

 

 

 

 

 

 

On Mon, Jul 26, 2010 at 11:51 AM, Alastair Malarky <AMalarky@ivhs.com (amalarky@ivhs.com)> wrote:
I think part of problem is we keep treating and/or representing the 1609 defined PSID as an integer or an encoded integer (I've been just as bad).  It used to be an integer when it was a fixed length but it isn't any more.  Nor is it an encoded integer any more since it will be assigned as the entire octet sequence, not as an unencoded (numeric) value which is then encoded. 
 
I believe we should consider 1609 defined PSID in the context of: 
 
                The PSID is assigned as an ordered sequence of octets, of variable length, where the sequence is structured so that it has a deterministic length indicated by the first octet.
 
While an octet sequence longer than one octet can be represented  using hex, I don’t think we should express it as a number with hexidecimal digits  (e.g. 0xABCD…  or ABCD16) but use the hexidecimal representation (see IEEE 802) of an octet sequence (AB-CD-….  ).   By using the numeric representation we create the interpretation it can be treated as a single integer (whose octets are then sent least-significant octet first in 802.11 default) or purely as an ordered sequence of octets (in which case octets are transmitted in order from left to right).
 
Applying these, then the text changes as attached and ambiguity disappears.  Note also that we could also get more than 5 octets for PSID if we every had to (hope we never have to).  We do not need to specify the structure extension at this time.
 
 Note this in no way changes the PSID we have agreed to - the issue is one of clarity in the text.
 
Alastair Malarky
Chief Engineer & Design Integrity Director
Mark IV Industries,  IVHS Division
amalarky@ivhs.com (amalarky@ivhs.com)
Tel: (l) 905 624 3020 ext. 1203
Fax: (1) 905 624 4572
 
This communication may be privileged and may contain confidential information for the intended recipients. If you are not an intended recipient, please be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you received this electronic message in error, please notify the sender and delete the copy you received.

 

From: stds-p1609@ieee.org (stds-p1609@ieee.org) [mailto:stds-p1609@ieee.org (stds-p1609@ieee.org)] On Behalf Of John Moring

Sent: Wednesday, July 21, 2010 6:55 PM
To: '1609'
Subject: 1609.3 comment - PSID description



 
I have been working with Alastair (with some help from William) in resolving comments #16 - #18 in the recirculation ballot.  I’ve attached a file to address the issue described below.  It’s taken me a couple days of thought and research to arrive at the conclusion that this is our best solution.  Please post any thoughts to the reflector. If needed we can include discussion of this matter on Friday’s 1609.3 comment resolution call.  Refer to 160-9.3 subclause 8.1.3.
 
The issue is that there is potential ambiguity in the length of a PSID, which for example could cause a receiver of a WSA or WSM to be unable to parse the message.  We have specified the “length bits” (i.e., the bit string from which the octet length of the PSID can be deduced) as the MSBs of the field.  This is desirable because the PSID values for any given octet length are contiguous, as shown in Table 4 in 8.1.3.  In normal 802.11/1609 convention, MSBs are placed LAST within a field, so for example, a 2-octet PSID would have its length code (MSBs) in the second byte.  A 3-octet PSID would have its length code in the third byte.  A receiver would not be able to reliably distinguish among different length PSIDs, because the length code location is not deterministic. 
 
Similar situations have been encountered in the past.  MAC Address in 802 and Organization Identifier in 802.11p are specified to be sent higher-order octet
Thus the PSID will be interpreted just as we’ve described previously, but it will be structured such that the most significant octet is always first.  (There is no effect on 1-octet PSIDs).  The attached document shows how 8.1.3 has been updated to reflect this, and a new annex to illustrate the structure via examples.
 
Comments welcome.
 
JTM
 
 





 





 

This post originally appeared on the committee list server

[AMalarky at IVHS.COM]

[RR >] In my thinking, the PSID is a number/integer assigned by a registration authority from a set of numbers/integers that they are told they can assign.  We can change this if we think there is a better way, e.g. assigning a sequence of octets expressed in hexadecimal representation, or a string of bits if that appears to be a better choice. Not sure it matters much except to the guy doing the assignment and the guy buying the number(s).  In the end, the lowest common denominator is that the PSID ultimately is a unique (hopefully:^)) string of bits to be stored and transmitted over the air. How those bits are transmitted is something all of our standards must specify.
 
The real issue is that what the registration authority gives out must be interpretable by anyone - little endian people, big endian people, frame relay people (they bit-reverse the octets), ASN.1 people ...   An octet represention in hexidecimal notation is unambiguous.  That’s why they use it for OUI.  These are created as 24 (+..) bit numbers by the registration authority but the are given out as octets. 
 
Not a unique string of bits - a unique string of octets! 
 
Alastair Malarky
Chief Engineer & Design Integrity Director
Mark IV Industries,  IVHS Division
amalarky@ivhs.com
Tel: (l) 905 624 3020 ext. 1203
Fax: (1) 905 624 4572
 
This communication may be privileged and may contain confidential information for the intended recipients. If you are not an intended recipient, please be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you received this electronic message in error, please notify the sender and delete the copy you received.

 

This post originally appeared on the committee list server