In some cases, governmental authorities can disable communication systems for national security purposes. To the extent possible, METR user systems should always maintain relevant, up-to-date, expected rules for areas that the METR user system is expected to travel.

METR users need to be aware before they leave areas with reliable connectivity to their current wide area wireless communication service so that they can download any additional rules for downstream locations, as they might deem appropriate. Locations that are known to have poor connectivity for major wide area wireless communication services should provide all unexpected rules through localized broadcast. 

A METR user travels into zone without wide area wireless connectivity and encounters a temporary lane closure. Such a lane closure needs to be publicized via localized broadcast to ensure all users properly informed of the condition. In addition, user systems might alter their normal communications cycle with the disseminator if they are aware that wide area wireless connectivity will not be available. 

METR users need to be aware of the geographic areas for which its current distribution system is able to provide rules so that it can identify where it needs to contact a different disseminator.

As a METR user travels towards a national border that denotes the limit of the user's current distribution system, the METR user system will query the disseminator discovery service to determine the appropriate distribution system for the next downstream area. 

It is expected that METR will organize rules into a set of categories. It is further expected that different categories of rules will be supported by each sub-area, especially during the prolonged deployment phase of METR. Distribution systems will need to indicate the extent to which rule categories supported for each defined sub-area. Possible states for a rule category are likely to include: 

1. all electronic rules available 
2. electronic rules exist, but are not currently available (e.g., validity period has been exceeded for at least one source for the sub-area) or do not provide complete coverage (e.g., electronic stop sign information has not been fully entered) 
3. electronic rules exist, but electronic version does not define all exceptions, 
4. rules exist but not in electronic form (e.g., electronic transformation not implemented yet) 
5. rules do not exist (i.e., the category contents is null and all associated jurisdictional entities agree to notify METR if rules are created) 
6. rules are not known to exist (e.g., at least one jurisdictional entity does not participate in METR).

NOTE: The METR distribution system is typically only responsible for providing expected rule categories; unexpected rules and supplemental data are typically provided by jurisdictional entities. Nonetheless, the METR distribution system needs to convey which unexpected rule and supplemental data categories will be provided by those other providers.

METR user systems might depend upon certain METR data to make safety-critical decisions. To ensure safe operations, a METR user system needs to be aware of what rule information is available electronically and to what extent it can rely upon the electronic information. ADS-equipped vehicles might limit their operational design domain (ODD) based on the availability of rules from certain rule categories. To facilitate quick identification of the rules supported by a jurisdiction, this document proposes that the categories of rules should be standardized, such as indicated in Annex D.

An ADS-equipped automobile might have an ODD that requires electronic speed limits. This ODD constraint would be met for any stretch of road where: 

1. expected speed limits are known, for example, because: 
   1. all electronic automobile speed limits are available for the jurisdictional area; 
   2. electronic automobile speed limits are available for the stretch of road, even if they are not available for the entire area; or 
   3. automobile speed limits are known to not be locally defined for the stretch of road (e.g., assuming that the default speed limit for the type of road is known) and 
2. variable and unexpected speed limits are electronically provided to the extent that the jurisdiction allows their use.

It is expected that METR will organize supplemental data into a set of categories. It is further expected that different categories of supplemental data will be supported by each sub-area, especially during the prolonged deployment phase of METR. Distribution systems will need to indicate the extent to which externally-provided supplemental data categories supported for each defined sub-area. Possible states for a supplemental data category are likely to include: 

1. all required externally-provided supplemental data electronically available 
2. required externally-provided supplemental data exist, but are not currently electronically available (e.g., transmitter offline) or do not provide complete coverage (e.g., only some emergency vehicles are equipped) 
3. required externally-provided supplemental data exist, but electronic version does not define all exceptions, 
4. required externally-provided supplemental data exists but not in electronic form (e.g., traffic signals that only provide visual indications) 
5. required externally-provided supplemental data is not required by any rules within the area and all associated jurisdictional entities agree to notify METR if this changes

NOTE: Externally-provided supplemental data are typically provided by jurisdictional entities. Nonetheless, the METR distribution system needs to convey which supplemental data categories will be provided by those other providers.

METR user systems might depend upon certain METR data to make safety-critical decisions. To ensure safe operations, a METR user system needs to be aware of what externally-provided supplemental data is available electronically and to what extent it can rely upon the electronic information. ADS-equipped vehicles might limit their operational design domain (ODD) based on the availability of supplemental data from certain categories. To facilitate quick identification of the data supported by a jurisdiction, this document proposes that the categories of supplemental data should be standardized, such as indicated in Annex D.

An ADS-equipped automobile might have an ODD that requires electronic notification of current traffic signal status. This ODD constraint would be met for any stretch of road where: 

1. all traffic signal supplemental data are available for the area; 
2. all traffic signal supplemental data are available for the stretch of road, even if they are not available for the entire area; or 
3. no traffic signals exist.

The user needs to be aware when data is missing; knowing the locations where it should be receiving supplemental data will facilitate the identification of missing data.

METR users might rely on data from the METR environment to make safety critical decisions. Such users must be aware of when the provision of any of this data might be degraded or unavailable.

1. The distribution system is unable to obtain rule updates for one or more jurisdictions before the previous rule set for the jurisdiction expires. The METR distribution system will need to alert users requesting these rules that they are out of date.
2. If a traffic signal looses power, its associated RSU, might not be able to transmit its variable signal timing data, which might be required by an ADS. In this case, the ADS is adequately informed of degraded operations if its previously obtained pre-announced rules indicate that there should be an RSU broadcasting variable signal timing data. When the ADS approaches the signalized intersection and does not receive the expected broadcasts, it should realize that operations are degraded and take appropriate action.   

The data provided by METR will be used by a variety of METR user systems, each with their own applications. The data provided by METR must be sufficiently unambiguous to allow for its use by different users for the varied expected purposes. 

1. For a road section that has different speed limits for automobiles and heavy goods vehicles, METR must ensure that the data provided is sufficiently unambiguous to prevent misinterpretation. For example, METR could provide both speed limits or it could provide one while making it clear that the rule does not apply to the other classification of vehicles. 
2. A condition-based rule might be defined such that it is in effect between midnight (0:00) and 06:00 when snow is present. For an ADS to comply with this regulation, there must be an agreement on:
   1. the meaning of midnight (e.g., local time or UTC), 
   2. identifying which entity (e.g., METR disseminator or ADS) is responsible for determining when the snow present condition is met, 
   3. whether the regulation applies to the ADS (e.g., does the regulation apply to police vehicles when responding to an emergency). 
3. If a user is notified of a condition-based rule for a lower speed limit "when workers are present", it should be aware of what supplemental data source (e.g., METR distribution system, RSU, on-board sensors) it should use to determine if the "workers are present" condition is met and whether it can legally rely upon that data source.

A METR user needs to know If the METR rule category is normative (e.g., enforceable, and to what extent) or informative (e.g., a supplemental to the normative traffic control device in case it is obstructed). If METR rules are enforceable, the facility might need to have signs posted to warn human drivers of the need to support METR. It is expected that most rules within a rule category will have the same enforceability; however, there can be exceptions (e.g., a new speed limit might be associated with a lower rating for some period of time). 

Users need to be aware if the electronic rules can be legally relied upon to perform the dynamic driving task or if they should be treated as supplementary (informative) or if they are only intended for testing purposes.

The confidence level might be reflected in attributes such as:

1. when the data was last updated/verified 
2. an assessment of the processes of the organization (e.g., something similar to an ISO 9000 certified business), 
3. an indication of the authority of the rule-maker and translator (e.g., there might be more confidence with a governmental source than a private source), and
4. crowd-source information that identifies any discrepancies.

Rules and supplemental data might be transmitted in operational systems prior to formal certification or might contain data provided by authorities that are not regularly verified (e.g., rules on a small campus). The user needs to be able to understand to what extent the information being received should be used to affect operational decisions.

OEMs and/or jurisdictions might require certain levels of data quality for specific categories of data to operate in ADS-equipped mode.

1. A city might have rigorous procedures for updating and maintaining its METR information to ensure it is always consistent with posted traffic control devices.
2. An owner of a small parking lot campus might enter the rules for the parking lot, including space-specific rules (e.g., marking some spaces as reserved for people with disabilities). The owner might later install electric vehicle charging stations with signs that reserve the spaces for that use. As the operator of a small campus, the owner might forget to update the information within METR.

Organizations responsible for components of the METR distribution system and/or supplemental data provider components must plan for, adapt to, resist, and quickly recover from all failures related to safety critical information. 

NOTE: METR user systems need to be designed to provide safe operations even if the other METR components and/or supplemental data providers become unavailable for some period.

METR information is used for safety-critical decisions; users should be alerted to any failure and failures should be corrected as soon as possible to minimize the period with reduced safety margins. 

1. If a traffic signal stops transmitting signal timing data, a METR user system needs to be able to recognize that the data is missing and take appropriate action. 
2. If an emergency crew deploys safety-critical, unexpected rules, they should ensure that every approach to the site is covered by redundant communications in case one source fails.
3. An out-of-area ADS-equipped emergency response vehicle needs reliable rule information when responding to a natural disaster.

The need covers:

1. unposted and posted rules;
2. persistent and temporary rules
3. ad-hoc and anticipated rules;
4. rules that override other rules;
5. supplemental data that can impact the active state of a rule;
6. expected, active, and withdrawn rules;
7. rules that are applicable in areas where there is unreliable wide area wireless connectivity.

Expected rules need to indicate when they will expire and users need to be able to obtain updates prior to their expiration.

Activation/deactivation of a rule might be due to any number of reasons, including: 

1. a defined schedule, 
2. external events (e.g., rain), 
3. installation of a sign 

NOTE: Details for some rules can be difficult to codify (e.g., a person directing traffic at the scene of a crash). In such a scenario, the METR environment can advise users that the expected rules are currently being overridden even though it may not be feasible to provide details electronically. By notifying users that there is a change in the expected rules, ADS-equipped vehicles will be able to determine if the section of road still remains within its ODD.

There are many rules that have been defined by rule-makers. While many of these rules are relatively static others can change with little notice. User systems need an accurate representation of rules at every point in time (e.g., on the scale of 0.1 second resolution) to make appropriate dynamic driving task (DDT) decisions. Since the bulk of rules are relatively static, it would be very inefficient to download all defined rules 10 times a second; instead, the METR ConOps divides rules into two basic types: rules that are relatively static are defined as "expected" and rules that can change with little notice are defined as "unexpected". The distinction between these two categories is based on whether the changed rule becomes active prior to the expiration of its relevant rule set.

1. A user returns to his vehicle after a long hiatus. The vehicle system needs to determine if its previously downloaded rule set is still valid prior to engaging its ADS or presenting information through its driver support system. 
2. A parking restriction might be planned to go into effect two weeks from now and then be active from 06:00 to 17:00 Monday through Friday. The user needs to be aware of the expected rule prior to the rule first becoming active and relevant.
3. A parking restriction might be implemented with short notice (e.g., due to an incident). The user needs to be aware of the unexpected rule prior to the rule first becoming active and relevant.
4. A new stop sign is installed. The user needs to be aware that a new expected rule is planned and must also be informed of the supplemental data that indicates when the rule becomes active (i.e., a field crew installs the sign).
5. Evacuation plans might be publicized well in advance as expected rules that are inactive; the activation of these rules would be achieved through supplemental data.

For a METR user to obey the rules currently in effect, it must be aware of the supplemental data that relevant rules depend upon. 

1. A parking restriction might be active when a snow emergency event is active. To understand what rules are active, the METR user must be aware of when a snow emergency event has been declared and what supplemental data provider could be used to obtain this information. 
2. The traffic management centre changes the speed limit on a stretch of roadway controlled with a variable speed limit system. A METR user needs to be aware that the stretch of roadway is controlled by a variable speed limit and must be aware of the supplemental data provider from which the user can obtain the current speed limit.

METR user systems might make safety-critical operational decisions based on the data received. If a collision or other liability situation occurs, forensics will likely need to be performed to ensure what data was available at what point in time. The system design needs to ensure that the data received by each user system is sufficiently captured to reliably recreate a meaningful picture of conditions immediately prior to, during, and immediately after the incident.

A collision occurs on a road section that has a variable speed limit where the vehicle is believed to have been exceeding the speed limit. To determine liability, investigators will need to determine 

1. the speed limit in effect at the time (e.g., as posted on physical infrastructure),
2. the speed limit that the vehicle system was aware of (e.g., as received via METR), and
3.  the speed of the vehicle.

The METR distribution system and supplemental data providers will need to provide all data for the data categories that the METR user requests. The METR user (or METR user system) is responsible for determining what data might be needed, given the standardized data categories and locally defined sub-areas. The user will also need to be aware of the foundational data that other data depends upon (e.g., to understand a "truck speed limit", the user must understand what is meant by "truck").

Rules can override other rules; therefore, a transport user system must have a complete set of rules to ensure that it understands any exceptional conditions.

Normally, a vehicle might not be allowed to use a hard shoulder, but it might be required to when a responding emergency vehicle is approaching.

Rules should be displayed to the driver in the driver's native language; in order to ensure proper translation, rules should be distributed in a language-neutral format to the extent possible to minimize potential for translation errors among human languages. 

NOTE: It is likely that some details might have to remain in native language of the rule-maker within the initial release of METR; the goal is to eventually eliminate such issues.

A METR user system might depend upon certain optional capabilities of a METR distribution system. To safely engage certain features, the user system needs to be able to determine if the distribution system supports selected optional features.

Except when explicitly stated otherwise, all rules are considered public information.

Information conveyed by METR is assumed to be publicly available and as such, confidentiality of the information is not important; however, information about what information a specific transport user is accessing could potentially be used to determine information about the user, as such the information requested and obtained by a user should be kept confidential.

A METR user needs to be able to access data and services for which they are authorized and need assurance that data and services are not provided to unauthorized parties.

While most rule information will be defined to be publicly available, the ability to add, modify, or delete rules as well as other services must be restricted.

Translators will need to have permissions to create electronic rules.

This is important for all rules but especially critical for regulatory rules. METR components must record not only the rules that were sent but also demonstrate that all of the system's responsibilities have been fulfilled at each point in time. Accountability information needs to be retained for a period sufficient to meet local jurisdictional requirements. 

When receiving rules, users should be able to directly determine the translator and the disseminator associated with the rule. The user should be able to determine the level of liability borne by the source for any misinformation or missing information.

An authorized third party needs to be able to verify the history of rule availability for any jurisdictional area or sub-area. Access to the history would likely be performed remotely (e.g., using an Internet connection).

An authorized third party needs to be able to verify whether a vehicle has a valid permit for enforcement, opening gates, etc.

Because the transport user system might make or assist in making safety-of-life decisions, it is critical that the system supports non-repudiation so that forensics are able to demonstrate what information was known when.

Accountability information needs to be available to: 

1. lawyers, 
2. insurance companies, 
3. enforcement organizations
4. transport access points (e.g., automated gates)
   
   

The electronic rules should be presented in a manner that mirrors the written rules as closely as possible to minimize the addition of any ambiguity. The rules also need to be accurate in the sense of providing an accurate description of the rule and accuracy as far as location (e.g., the start and end points for a stretch of roadway with a parking restriction). The rules should also be unambiguous; for example, they should be able to distinguish between a planned change to a rule (e.g., changing the speed limit next week) and a plan for a new rule (e.g., implementation of a new parking restriction next week).

The information received by METR is used to make operational, and often safety-critical, decisions and enforcement actions can be taken against transport user systems that violate posted regulations. As a result, the information provided by METR must be accurate.

The user needs to ensure that the rules were created by an authorized translator and are received from an authorized disseminator. The user also needs to ensure that supplemental data is received from an authorized supplemental data provider.

METR user systems rely upon the accuracy of METR information and need to ensure that it is from an authentic source. 

Rules that require supplemental data should indicate what supplemental data is required, the authorized sources of this data in prioritized order, and how METR users should respond if the supplemental data is not available.

The meaning of some rules is dependent on supplemental data. In these cases, it is critical that METR user systems are aware of the intended data source(s) of the supplemental data so that all systems agree on the status of the rule.

1. A METR user approaches a traffic signal that has been identified as a location where supplemental data (i.e., traffic signal status) should be provided. The rule should indicate that if no supplemental data is provided (e.g., the RSU is not operational), the vehicle must rely on visual indications or achieve a minimal risk condition (i.e., safely come to a stop in a safe area).
2. A METR user encounters an emergency vehicle responding to an incident but is not broadcasting the supplemental data that the METR distribution system claims will be provided. The METR user's ADS proceeds as normal since it does not receive the supplemental data. The driver of the vehicle might become responsible for observing the emergency vehicle and giving way to it.

A distribution system could potentially keep track of the requests made by a METR user system and thereby deduce personal information about its users. Users should be aware of the policies of the distribution system with an opt-in for any external data use and there needs to be mechanisms to enforce the privacy policies adopted by the distribution system.

NOTE: Some jurisdictions might require each distribution point (e.g., disseminator) to be certified. NOTE: The provision of this service will likely rely upon an ITS service external to METR.

METR user systems (e.g., ADS-equipped vehicle, smartphone) need to be able to identify where rules can be obtained. This need can occur due to 

1. an initialization of a transport user system, 
2. a user entering, or planning to enter, a new jurisdiction, 
3. a distribution system going offline, or 
4. a user entering into a new distribution system agreement.

The different disseminators might specialize in different rule categories (e.g., general motor vehicles, commercial vehicles, micromobility) and/or have different geographic domains (e.g., supporting regulations from specific jurisdictions). In some cases (e.g., a typical passenger car), a single disseminator might provide all relevant regulations for a large geographic area; in other cases, multiple disseminators might be required to obtain all relevant regulations (e.g., a commercial vehicle might collect generic motor vehicle regulations from one disseminator, and supplemental commercial vehicle regulations from multiple different regional disseminators).

As a METR user system approaches a jurisdictional boundary, it might discover that its current disseminator does not support the next jurisdictional area and it will need to discover alternative disseminators for the upcoming jurisdictional area.

METR users have certain rights, including being informed of the contractural agreements related to obtaining data from a disseminator. In particular, the terms of service should clearly explain the liability aspects related to the data provided by the disseminator.

METR user systems typically support multiple radios for wireless communication. For example, a passenger car might support

1. an ISO/IEC/IEEE 8802.11 radio (i.e., WiFi)
2. a 3GPP radio (e.g., 3G, 4G, 5G)
3. a short-range communications radio (e.g., DSRC or LTE-V2X)

Use of each radio will involve different restrictions and implications (e.g., costs). Users need to be able to identify their preferences so that their interaction with the METR distribution system can be achieved in an efficient manner.

A METR user might wish to take a journey spanning 5,000 km. Such a journey would entail crossing many jurisdictional areas, each with its own rules (both location-specific rules, such as stop sign information, as well as general rules, such as rules on the use of headlights). Some jurisdictional boundaries might be in areas with poor wide area wireless connectivity preventing the METR user system from accessing rules en route. Further, even if connectivity is available using a 3GPP radio connection might be more expensive than if the rules were obtained in advance via a WiFi link. 

Classification schemes are used to classify entities based on their characteristics and can vary by jurisdiction. Characteristics that need to be considered are listed in Annex E.2 through E.8. The characteristics in E.1 should follow standardized classification schemes.

Many rules apply to certain classification of facilities, vehicles, users, etc. To properly understand the rules that are currently relevant for a road section, the METR user needs to be aware of the facility classification.

A jurisdiction might set different default speed limits based on whether a road is:

1. an urban residential street
2. a rural residential street
3. a urban carriageway
4. a rural carriageway
5. a urban motorway
6. a rural motorway

The METR user needs to be aware of the classification of the facility it is using to properly understand the default speed limit that applies.

Rule characteristics that need to be considered are listed in Annex E.2 through E.8.

Many rules apply to certain classification of vehicles. To properly understand the rules that are currently relevant for the user's vehicle, the METR user needs to be aware of the vehicle classifications within the jurisdiction. 

A jurisdiction might prohibit mopeds on motorways; however, the exact definition of a "moped" can also vary among jurisdictions. To understand whether the user's vehicle can access a motorway within the jurisdiction, a METR user needs to know if the jurisdiction consider's the user's vehicle to be a moped.

The physical world changes over time, both geologically (e.g., earthquakes) as well as within the transport network (e.g., new/revised roads). In addition, there are well-known challenges in precisely mapping locations on an irregular spheroid, such as the Earth, as well as user systems being able to accurately locate themselves on the spheroid. Users need up-to-date maps to provide sufficient resolution and detail to accurately associate the map information to its immediate physical world.

Different rules and user scenarios are likely to have different needs for mapping resolutions.

METR users need to be able to precisely associate relevant electronic rules with their intended geographic locations.

1. A user in a motor vehicle needs to be aware of the location of a crosswalk so that it does not infringe upon the walking space.
2. A user needs to be aware of the location of a stop sign so that it stops in the right location.
3. A user needs to be aware of the exact location of a no parking zone so that the vehicle does not overhang and receive a citation.
4. A pedestrian user with disabilities needs high resolution maps to properly understand the exact location of an access ramp.

Many rules are location specific. To accurately determine the relevance of rules and the relative location of the vehicle to the applicable rule area, a METR user system needs to be able to locate itself.

Such discrepancies should be rectified quickly, but might require some time. Some METR deployments might choose not to provide this information.

When faced with conflicting information, METR users need to be able to understand which information is considered to be more reliable. Being aware that there is a known discrepancy and knowing the precedence will allow better conformance to the intended rule.

Different rules might apply to similar transport facilities depending on its jurisdiction.

A city road might cross a private campus (e.g., a university). The city might ban certain classifications of vehicles from using their roads (e.g., mopeds and golf carts) while the campus allows these vehicles. The METR user needs to be aware that the city has jurisdiction over the city road so that it does not violate relevant rules.

A sub-area might consist of multiple non-contiguous areas. A rule-maker needs to be able to indicate if a sub-area is subjected to its rules. Jurisdictional sub-areas might overlap.

In practice, most locations are subjected to multiple levels of hierarchical jurisdictions. 

A location might be within a private campus, which is located within a city, which is located within a national subdivision (e.g., a province, state, prefecture), which is located within a country. At such a location, many rules of the higher levels typically apply. However, if the private campus happens to be an embassy, the higher-level rules would not apply.

The definition of a rule might refer to a specific supplemental data provider to determine the state of the rule (e.g., a rule might indicate that an intersection is controlled by a traffic signal and provide a reference to the SPaT data source for the state of the traffic signal). METR needs to be able to support the rule categories defined in in Annex D, as a minimum.

METR users need to be aware of relevant rules to properly comply with them. It is the responsibility of the METR user (and METR user system) to determine what rule categories might be needed.

Rule categories need to be standardized so that users can have confidence that they are requesting all rules that are needed. For example, disseminators should allow a user to indicate a request for all rules for a standard profile, such as a passenger car.

A METR user is typically only interested in rules relevant to its own vehicle classification and general vicinity and expected route, but a METR user might also be interested in knowing about crossings of other modes of transport.

The conditions might include combination of conditions, such as those defined under Rule Characteristics.

While many traffic control devices are consistent across broad regions of the world, the legal definition of the underlying rules that these devices represent vary based on local laws. METR users, especially ADS, need to be aware of the legal meaning of each rule in order to ensure that they are properly obeyed. 

While stop signs are standardized around the world, the legal meaning of coming to a complete stop varies (e.g., rolling stop allowed, complete stop for a minimum number of seconds required). Users need to be aware of any local variances from the norm to the extent that they have practical implications to the operation of a vehicle.

The precedence is used to determine if the rule has a higher or lower priority than another rule (whether physically posted or electronic).

A jurisdiction might allow replacement of a general rule; might only allow more stringent rules; or might prohibit modification of the rules.

Multiple conflicting rules may apply to a single road section (e.g., a normal speed limit, a speed limit when raining, and a speed limit for road works) and METR users need to know the rules for unambiguously resolving the apparent conflicts.

Example 1

A road might be assigned the following speed limits simultaneously:

1. A default speed limit (perhaps set by a parent jurisdiction) that applies to the particular road class unless there is a posted speed limit
2. A maximum speed limit (designated by a parent jurisdiction) that local jurisdictions are allowed to set for any road class
3. A normal posted speed limit
4. A secondary posted speed limit that applies under certain conditions (e.g., when raining or at night)
5. A temporary work zone speed limit

Speed limits 3-5 might be posted with observable traffic control devices while all five might be distributed by METR (with potential discrepancies between electronic rules and the corresponding traffic control devices). A METR user needs to be able to determine which speed limit is active according to defined precedence.

Example 2

A local authority might impose limits on emissions followed by a regional authority imposing stricter emission requirements.

The distribution system should be designed to improve the probability that each METR user system will receive the highest priority rules early in case there is any instability in communications. In many cases, priority should be decided by the METR receiver and reflected in the requests made (e.g., based on location and required rule categories). However, some rules might be designated as high priority by the translator, in which case the disseminator needs to distribute the information as widely and quickly as possible.

A METR user might deviate from a planned route, whereupon it realizes a need for rules within its immediate vicinity as soon as possible. Further, a METR users might need rules from multiple categories but might place different priority levels on the different categories. 

Alternatively, a major event (e.g., natural disaster) might result in critical rules being activated or deployed (e.g., a ban on the use of ADS). Given the potential for such rules to have broad operational implications, the distribution system needs to be able to prioritize the transmission of these rules.

To enhance the system efficiency, users should be able to subset rules based on: 

1. the classification of the vehicle within the target jurisdiction (i.e., passenger vehicles do not need rules for commercial vehicles or pathway robots), 
2. location and intent (e.g., a vehicle might wish to store all rules related to its home location but only to retrieve rules along a narrow corridor for a long trip), 
3. category of rule (e.g., some vehicles might not use parking rules in any way so it would be pointless to download them), 
4. temporal constraints (lawyers and insurance companies might wish to discover rules that were in effect on a past date), 
5. other characteristics that might relate to special rules (e.g., emergency response, delivery, dangerous goods, permitted, heavy, and other vehicles might be subject to special regulations of which only they need to be aware). 

User systems rely upon wireless communication media that often have limited bandwidth. Processing and storing data increases hardware requirements. Preventing unnecessary the downloads allows a more efficient system; however, the need to obtain complete rule sets with proper accountability remains. 

A distribution system might package rules according to rule category, sub-area, and block, where a block is a subdivision of a sub-area. Each block might be of a different size and shape (e.g., speed limit blocks might be along roads whereas parking rule blocks might form a grid).

User systems could then request the rule categories they deem most important given their current circumstances along with a specific area of interest. They would then receive the highest priority rules in an efficient manner while still allowing the distribution system to maintain a store of standardized blocks that it can send to any user.

Permits might be granted to a METR user (e.g., being assigned an accessible parking permit) or a METR user system (e.g., being designated to be an emergency vehicle). Permits might grant authority to use a transport facility, radio frequency usage, transport modes, etc.

Many rules are based on granted permits, which might be self-certified in some cases. The METR user system needs to be aware of the current permits so that it can apply the rules properly.

1. A user with disabilities might be permitted to use accessible parking spaces through the use of a government-issued permit. The user's vehicle needs to be aware of the permissions when determining where to park the vehicle.
2. A user that is pregnant might be permitted to use accessible parking spaces through the use of a self-issued permit (i.e., enforcement might be lax but the spaced are designated for a user category as a courtesy). The user's vehicle needs to be aware of the user's declaration when determining where to park the vehicle.

A METR user might decide to take a long road journey and will need the relevant rules for the journey. The rules needed for such a journey would tend to be concentrated on a specific route but the user is likely to stop at locations for and other reasons. To the extent possible, the user needs to be able to download the rules related to the trip in advance both to minimize data communication costs as well as to ensure that the rules do not impact navigation, parking, and other decisions (e.g., the most direct route might include restrictions on certain vehicle classifications).

This might be achieved by:

1. providing for manual operation of an ADS-equipped vehicle (with no or degraded driver support), 
2. providing for a remote update capability, or 
3. local rules allowing for a degraded ADS operation on roadways (e.g., driving with flashers on).

For the foreseeable future, it is likely that there will be areas that do not have wireless Internet coverage. As a result, there is a real possibility that ADS-equipped vehicles will be stored in areas where their rule set becomes out of date. Users should be able to make these vehicles operational again without requiring a towing service. 

Some rules relate to details that might be difficult to automatically detect. If the METR user system is to automate compliance with rules, it needs to be aware of the status of these details, e.g., with manual user entry of the data.

1. A rule might require snow chains, which are manually attached by a person. The METR user system aboard the vehicle needs to be aware whether snow chains are currently on the tires so that it can ensure compliance to the rule. 
2. A rule might restrict parking to vehicles with certain types of permits. The METR user system aboard the vehicle needs to be aware of what permits currently apply to the vehicle.

Environmental conditions (e.g., rain, dusk) can be referenced as a part of condition-based rules. For a METR user system to automate compliance, it needs to be aware of any environmental condition referenced by valid rules. 

1. The speed limit might change when it is raining.
2. Parking restrictions might be active when there is snow on the ground.
3. Headlights might be required between dusk and dawn.

Many vehicles will have a design life of 10 years or more and the fleet of all vehicles has a fairly even distribution such that there is no good time to migrate versions of the standard. While the standards should be designed to be backwards compatible, it is likely that METR user systems will be legally required to upgrade after some point so that the METR distributor systems do not have to support very old versions of the METR standards to support a niche user base.

Jurisdictional entities can include private entities (e.g., shopping centers, universities, hospitals, corner stores). This includes the ability to change a previously assigned jurisdictional entity (e.g., for a private campus that is sold).

Every jurisdictional area should have a designated jurisdictional entity responsible for defining rules. METR users need to be aware of who the jurisdictional entity is so that they can ensure the authenticity and applicability of rules that it receives.

Large jurisdictional entities are likely to have multiple rule-makers; small jurisdictional entities (e.g., a private campus) might only have one rule-maker, which is the jurisdictional entity itself.

Rules are issued by regulators and METR users will need to verify that the rules received are properly authorized by the jurisdictional entity.

1. For a private campus, the owner (e.g., a person) of the campus might also serve as the only rule-maker.
2. A city might have the following rule-makers:
   1. city council (e.g., for parking regulations)
   2. transportation engineering department (e.g., for speed limits and stop signs)
   3. transportation operations department (e.g., for variable speed limits)
   4. maintenance department (e.g., for road work rules)

A translator agent is the person responsible for entering the electronic version of rules. The agent might be an employee of the jurisdiction or might be a third party.

While the authority to impose rules is granted to rule-makers; the actual work of translating the rules into electronic format is performed by individuals. While a rule-maker might be an individual, in larger organizations, rule-makers are often represented by some administrative division and each authorized person within the division who is allowed to enter rules in an electronic format needs to be explicitly authorized to perform this work. The information of who entered each rule is needed to ensure proper accountability within the system.

The activation of some rules (e.g., road closures) can have significant effect on the transport network and rule-makers might wish to minimize demand for those routes in order to provide a more safe, sustainable, and efficient transport network.

A rule-maker might close a mountain pass during a snow storm. The rule-maker would likely want to ensure that travellers are aware of this closure to minimize the number of travellers attempting to travel on the roads leading to the mountain pass during inclement weather.

Rule-makers should be aware that implementing non-electronic rules can adversely impact the ability of ADS-equipped vehicles to operate (at all) or to operate at peak efficiency. In the worse-case scenario, an ADS-equipped vehicle without built-in input devices might stop and wait for a remote operator to assist in its navigation of the area. Such a scenario would likely degrade the efficiency of traffic operations in the area due to the temporarily stopped vehicle and restrictions imposed on remotely operated vehicles. As such, disseminators should only announce areas with non-electronic rules when non-electronic rules are known to exist and the announcement should be associated with a tightly defined geofence.

Ad-hoc rules are often determined on-scene with little time to safely implement electronic equivalences.

A police officer might manually provide directions at an intersection.

To maintain user's trust with the system, inconsistencies within the electronic data must be minimized and quickly corrected when discovered. By requiring each METR component to report any discrepancy, the system should be able to identify inconsistencies quickly so that a resolution process can begin.

User systems should report discrepancies between physical and electronic rules when they are discovered; it is up to the user system to determine how to respond to the discrepancy in real-time. Some jurisdictions might require reporting while others allow it as an option. The observations might include images to assist in resolution of the conflict, but this might not always be provided due to vehicle and/or bandwidth limitations. Users might be allowed to report conflicts in rules to a trusted source of its choice, who can then forward to the appropriate rule handler. For example, it may report to an OEM, who provides data to the rule handler.

This is especially important after major incidents.

To maintain user's trust with the system, inconsistencies between the electronic data and posted rules must be minimized and quickly corrected when discovered. By requiring each METR user systems to report any discrepancy, the system should be able to identify inconsistencies quickly so that a resolution process can begin.

This is especially important after major incidents.

In some cases, rules might be affected or deployed in the field before they are entered by the translator. When this occurs, it would simplify and speed the process to enter the rules into METR if the data has already been reported by vehicles so that the translator only needs to verify the data without having to perform the data entry step.

A major earthquake might damage a roadway and cause it to close.

The verification can take place locally (i.e., using the same distribution mechanisms as might be used by a transport user) or remotely (e.g., using an Internet connection).

Rules need to be verified for legal purposes.

1. An enforcement organization might want to verify that the METR rules are consistent with posted information before issuing a ticket.
2. A lawyer defending his client might need to verify that the rules distributed were consistent with posted rules on a certain date.
3. An insurance company might want to ensure that the METR information was consistent with posted rules prior to issuing payments on an insurance claim.