Regional data extensions in a generic lane object

In this article we discuss the topic of how to add regional data extensions to a map’s generic lane object.  The process steps are the same for adding content to any data concept with a regional extension. Extending MAP-SPaT with regional content is a fairly simple process.

This need occurs when a deployment decides that the current standard lacks some content they feel is wanted.  It is generally anticipated that new concepts being added to existing data concepts in the J2735 work will be proven as regional data extensions before standardization is considered.  As long as the resulting extension(s) is not used to circumvent the standard, this sort of use is to be encouraged.

This article was developed in response to a question regarding using regional extensions posted by Vitho on the ASN1c forum that said in part:

But the last and probably most important step is still somewhat unclear. I found the regions listed in the ASN file as noRegion, USA, Japan and EU. However I haven’t been able to figure out how to “activate” the EU region. In other words I haven’t been able to compile the file using the addGrpC extensions instead of the stubs (The empty RegionalExtensions).

Useful resources in the SAE J2735 document are:

  • The actual standard itself, available here.
  • Section 11.2.3 Regional Extension(s) in the ASN Specification which outlines many of the same concepts with a simple worked example.
  • The core message frame:  Section 5.1 Message: MSG_MessageFrame (FRAME) where this defined.

Guidance: When in doubt, read the standard!  If still in doubt,
please ask either here on to the SAE DSRC TC committee.

Problem Statement

How do I add my own content to the generic Lane object?   Starting with the ‘stock’ J2735 ASN and the group region extensions that were published with it….

Presuming we want to add something to the generic lane structure for our needs.   The “raw” region in the generic lane follows a common format and is….

   regional  SEQUENCE (SIZE(1..4)) OF 
              RegionalExtension {{REGION.Reg-GenericLane}} OPTIONAL,
   ...
   }

If you follow the definition of “Reg-GenericLane” you will find it on page 224:

   Reg-GenericLane           DSRC.REG-EXT-ID-AND-TYPE ::= { ...  }

And it is an empty stub in the DSRC space, used as a placeholder.  You will add a stub in your own namespace/ module name with the content you require.

Considering these two ASN.1 code fragments further… The first of these lives in a module called “DSRC” which is developed and maintained by the SAE.  And the goal of the SAE DSRC TC is that end deployments should never need to edit that file.  The second lives in a module called “REGION” which is intended be edited by end developers when there is a need.

To use the terminology of the original question, you “active it” by editing the empty frame to include the new content.  You will edit this to include your content (and any others you need) and to look more like:

Reg-GenericLane           DSRC.REG-EXT-ID-AND-TYPE ::= {
   { YOURREGION.YourContent  IDENTIFIED BY 128} |
   { FRITZK.OtherGoodContent IDENTIFIED BY 129} |
   { SCSC.MyContent          IDENTIFIED BY 130} ,
   ...
   }

In the above the identifier values 128,129,130 serve to tell the “main” DSRC ASN to link to the three provided content definitions, which need to exist somewhere (they can in fact be in any module/name and it is common to use the DSRC data concepts as building blocks).

Aside:  A few such regional definitions exist in the std today, reflecting regional content that was known to the committee when the document was published.  For example, a few older formats to express LLH used in the MAPs that today are deployed throughout Japan and Europe caused this extension:

Reg-Position3D            DSRC.REG-EXT-ID-AND-TYPE ::= {
   { AddGrpB.Position3D-addGrpB IDENTIFIED BY DSRC.addGrpB} |
   { AddGrpC.Position3D-addGrpC IDENTIFIED BY DSRC.addGrpC} ,
   ...
   }

Let’s take a moment and look again at the definition of RegionalExtension here, as it is a bit tricky.  Like other bits of the current DSRC work, parameterization is used.  [See 5.1 Message: MSG_MessageFrame (FRAME) on page 30 for the full listing]

-- Regional extensions support
REG-EXT-ID-AND-TYPE ::= CLASS {
   &id     RegionId UNIQUE,
   &Type
   } WITH SYNTAX {&Type IDENTIFIED BY &id}

RegionalExtension {REG-EXT-ID-AND-TYPE : Set} ::= SEQUENCE {
   regionId     REG-EXT-ID-AND-TYPE.&id( {Set} ),
   regExtValue  REG-EXT-ID-AND-TYPE.&Type( {Set}{@regionId} )
   }

[While you could just edit the structure and remove one level of indirection here, the resulting ASN is not conformant to the standard, and it will fail any certification testing.]

How To:

To create and use a new regional extension you will need a regionId  number for your deployment region.  Right now SAE does not have a formal registry to do this, but the values 128~254 are allowed to be used by ad hoc deployments are (by definition) not coordinated.  [The std states 128~255 but please do not use 255 at this time]  So pick one of these and let SAE know about it so it can be tracked.  FYI, Page 252 of the current std has similar instructions to those here.

Aside: If all you wish to do is use another existing regional extension in a specific place,
all you need to do is step #2 below.

Step #1

Pick a region ID to use: So what you will want to do is pick a region’s number, here at SCSC we happened to use #130 defined as follows:

   scscTestRegion      RegionId ::= 130  -- MAP-SPaT deployment testing

Step #2

Define and add your own unique line in the regional definition (in the REGION module) to allow your content as a choice.  Use the above as a template or look at the ones defined using Groups  A, B, C in the standard.  The simplest entry would be similar to:

Reg-XXX           DSRC.REG-EXT-ID-AND-TYPE ::= {
   { YOURREGION.XXX  IDENTIFIED BY 128} ,
   ...
   }

Step #3

Define your own unique content for each data concept.  You may want to define your own module namespace.  It is common to use content taken from the DSRC and DSRC SSP namespaces in here as well.   [TODO: add link to SSP issues that will arise here]

XXX ::= SEQUENCE {
   -- my stuff here
   -- my stuff here
   ...
   }

Step #4

Compile all this and you are on your way.

Step #5 – Very Important

Please send a copy of the definitions you have created to the SAE DSRC TC so it can be tracked and coordinated with other work.

Was this article helpful?

Related Articles

Leave A Comment?

You must be logged in to post a comment.