IEEE Registration Authority

The 48-bit Extended Unique Identifier (EUI-48) and 64-bit Extended Unique Identifier (EUI-64) are globally unique identifiers used for identification of objects. Objects may be a hardware device (e.g., a network interface), a function (e.g., to identify a clock function) and similar applications. EUI-48 and EUI-64 are most commonly used for IEEE 802 universally unique MAC addresses.

EUI-48 and EUI-64 identifiers are assigned in various block sizes (MA-L, MA-M, and MA-S).

For more information, please see the tutorials on use of EUI-48 and EUI-64.

Blocks of universally unique MAC addresses/Ethernet addresses are assigned by the IEEE Registration Authority (RA). The RA makes these assignments to customers in three (3) block sizes: (MA-L = ~16 Million addresses, MA-M = ~1 Million addresses, MA-S = 4,096 addresses). Individual (i.e. single) addresses are not available from the IEEE. A 48-bit universally unique MAC address is formally referred to as an EUI-48.A 64-bit universally unique MAC address is formally referred to as an EUI-64.There is a monetary charge made by the IEEE RA for an address block.

Once you have checked against the appropriate public listing to verify your company does not already have an assignment, you may log in or create an account to request one. If the company already has an assignment, send an e-mail to the IEEE Registration Authority requesting the contact information for the existing assignment, and then make arrangements within your company to use your existing assignment.

Once the application is completed successfully, the applicant will receive an e-mail with a tracking number and payment information. The application will be processed within 7 (US) business days after receipt of payment as long as there are no problems with the information on the application or the payment. The applicant will receive an e-mail with the assignment information once the application is processed.

Consider if an existing registry is applicable. For many needs, the OUI/CID, EUI-48 or EUI-64 may meet your requirements. If different numbers are required, the IEEE Registration Authority should be consulted before balloting.

The prices for the various assignments available from the IEEE Registration Authority may be found on the IEEE RA web site for each registry.

Select assignments may be kept confidential for an annual fee.

IEEE accepts checks (payable to IEEE Registration Authority), wire transfers, as well as major credit cards and purchase orders with approved credit applications.

The difference between a public and private assignment is the format of the listing in our public listings. A public assignment lists the assignment with the company name and address. A private assignment lists the assignment with “PRIVATE” next to the number. Applicants of privately registered assignments are sent a renewal invoice annually.

The Registration Authority requires that you use 95% of an existing MA-L or MA-M assignment before an additional number can be issued to you. You must still fully exhaust your assignment before you may use the new assignment issued to you. Assignments should not be used on a per product basis or by manufacturing location. Parent and subsidiary companies can and are heavily encouraged to share assignments. Please include a Usage Percentage in section 3 of the application. Exceptions are rarely granted.

Please log in and update your company information. If there is a company name change due to purchase or sale please also email a press release or some details of the company name change to [email protected]. The company name change will not be uploaded to the public listing unless the press release or details are received.

Please see the public listings available on our web site to view public directories for each active registry.

The IEEE Registration Authority requests that any organization that intends to utilize the Organizationally Unique Identifier in the standardization of a technical area that has not previously been reviewed and approved by the IEEE RAC, please contact the IEEE Registration Authority.

IEEE standards that include OUIs and other unique numbers are subject to review by the IEEE Registration Authority Committee during ballot (Mandatory Coordination).Previously reviewed and approved standards might include new applications of OUIs and identifiers derived from OUIs. Such new applications should also be reviewed by the IEEE RAC. When revised, standards should be reviewed for consistent use of current terminology.

No. A parent company and a subsidiary company should share an assignment and if a company is sold, the assignment may be transferred to the new company. However, the assignment cannot be sold or distributed by anyone other than IEEE.

An assignment of extended unique identifiers can be used with Bluetooth. Please refer to the Bluetooth website for more information.

For further information, contact the IEEE Registration Authority.

There are currently 3 different size blocks of MAC Addresses available. They are MA-L (MAC Address Block Large), MA-M (MAC Address Block Medium) and MA-S (MAC Address Block Small).

The Registration Authority encourages organizations/companies to apply for the smallest block that will meet their needs. Example: If your organization plans to only create or distribute 500,000 devices, a MA-M assignment would suit your needs more appropriately than a MA-S assignment.

A CID, like the OUI, is a unique 24-bit identifier. A CID though, cannot be used to generate universally unique MAC addresses. Therefore, the CID is especially applicable in applications where unique MAC addresses are not required. A CID should be applicable in most other cases where an OUI is specified. The CID has been created to reduce the consumption of OUI values. A CID assignment may not be used for Bluetooth or other similar applications.

For more information, please see the tutorial “Guidelines for Use of Organizationally Unique Identifiers (OUI) and Company ID (CID).”

The Standard Group MAC Address assignment is for Standards Developers, or a Standards Development group, working to develop a new Standard. This assignment is not for companies that require MAC addresses for their products.

An OUI is a 24-bit globally unique assigned number referenced by various standards. (An OUI is assigned with a MA-L identifier block.) It can be used to identify an organization/company where a globally unique identifier is needed. The OUI is usually concatenated with other bits that are assigned by that organization in order to make a globally unique EUI-48 or EUI-64. EUI-48 and EUI-64 may be used as universally unique MAC addresses as used in the family of IEEE 802™ standards. For example, the Ethernet MAC Address is an EUI-48, unique to one particular Ethernet interface. There are other uses of the OUI however, such as its use as a company identifier in the SNAP protocol.

For more information please refer to the OUI tutorial

No. While waiting to obtain the value, a placeholder of nn-nn-nn or similar may be used. If there is already an OUI value associated with the standard, it should be used. If no such value is available then an OUI value should be obtained from the Registration Authority.

Until January 1 2014, the term “company_id” and OUI were considered equivalent to some, but the term company_id has been deprecated in favor of OUI for years. Beginning on January 1, 2014, Company ID (CID) was established as a unique registry. Either an OUI or CID may be used as a globally-unique 24-bit identifier of an organization, company, entity, manufacturer, vendor, etc.

The Individual Address Block is an inactive registry activity, which has been replaced by the MA-S registry product as of January 1,2014. The owner of an already assigned IAB may continue to use the assignment until its exhaustion. The IAB was used by organizations/companies that required less than 4097 unique 48-bit numbers (EUI-48) and thus found it hard to justify buying their own OUI. The IAB uses a MA-L (and OUI) belonging to the IEEE Registration Authority, concatenated with 12 additional IEEE-provided bits (for a total of 36 bits), leaving only 12 bits for the IAB owner to assign to their (up to 4096) individual devices. Unlike an OUI, which allows the assignee to assign values in various different number spaces (for example, EUI-48, EUI-64, and the various CDI number spaces), the Individual Address Block could only be used to assign EUI-48 identifiers. All other potential uses based on the OUI from which the IABs are allocated are reserved, and remain the property of the IEEE Registration Authority. It should also be noted that, between 2007 and September 2012, the OUI value 00:50:C2 was used for IAB assignments. After September 2012, the value 40:D8:55 was used. Applications making use of EUI-48 values assigned under an IAB should have made no assumptions about the bit pattern present in the (24-bit most-significant) OUI portion of the assigned numbers.

The OUI-36 is a deprecated registry activity name, which has been replaced by the MA-S registry product name as of January 1, 2014. This registry activity includes both a 36-bit unique number used in some standards and the assignment of a block of EUI-48 and EUI-64 identifiers by the IEEE Registration Authority. The owner of an already assigned OUI-36 registry product may continue to use the assignment.

Currently, the OUI-36 only refers to a 36-bit unique number used in some standards The OUI-36 of the MA-S assignment may be appended with 12 organization-supplied bits to form an EUI-48, or with 28 organization-supplied bits to form an EUI-64 (the identifier blocks assigned with an MA-S). .Applications making use of an MA-S should make no assumptions about the bit pattern that is present in the (24-bit most-significant) OUI portion of the assigned OUI-36.

Listing all the standards using these identifiers would be very difficult, and new uses continue to emerge; but a general listing includes:

• IEEE Std 802® provides general descriptions on use of EUI-48 and EUI-64 for universally unique MAC addresses, and use in protocol identifiers. The various IEEE 802.1 standards provide specifications for bridging among networks using EUI-48 identifiers as MAC addresses.
• The various active IEEE 802 network types (Ethernet, Wireless Local Area Networks, Wireless Personal Area Networks, Broadband Wireless Access, and Wireless Regional Area networks)include greater detail on use of EUI-48 or EUI-64 MAC addresses for those protocols.
• Many emerging network types including IEEE 1901 Broadband over Power Line use addressing according to IEEE Std 802™.
• Uses of OUIs (or the historical term “company_id”) are included in many IEEE, IETF, ITU, ISO, IEC and national standards. These standards either specifically call out use of the OUI as a 24-bit company identifier, manufacturer identifier or similar term; or define such a field and point to the IEEE RA as the source for such identifiers. It is intended that either a CID or OUI can be used in these fields. Many of these standards will be revised to also include reference to CID for these uses.
• Many standards define other extensions of the OUI for unique identifiers. These identifiers are referred to as context dependent identifiers. In these context dependent identifiers, the OUI/CID are concatenated with other fields defined in the standard (e.g., to identify a design model/version, to identify software entities, to identify company specific protocols, to identify company specific management attributes, etc.)

The Length/Type Field of an Ethernet/802.3 data frame provides a context for interpretation of the Information Field that follows (i.e., protocol identification). Some values of this field are used to specify a length, the remainders are EtherType™ values. EtherTypes™ are also used with other network types and may be found encapsulated within other protocols. Refer to IEEE Std 802.3, clause 3 and especially sub-clauses 3.1.1 and 3.2.6 for use of EtherTypes™ in a Length/Type Field. See also IEEE Std 802 for a more general specification of usage.

You do not need an EtherType™ assignment to do protocol development. Because the number of EtherType™ values is limited, and not all protocol developments are successful, two EtherType™ values have been reserved for protocol development. These are formally called Local Experimental EtherTypes™, though they are also known as Playpen EtherTypes™. Use of Local Experimental EtherTypes™ is specified in IEEE Std 802a (upon revision of IEEE Std 802-2001, IEEE Std 802a will be merged into the new revision).

The requested new EtherType™ must be sufficiently well defined (e.g., a protocol defined in a standard must have progressed sufficiently for ballot). The use of the EtherType™ must also be properly defined to minimize exhaustion of available EtherTypes™ by the use of subtypes. Subtyping provides a path for enhancement without the need for the assignment of a further EtherType™ in the future. Early use of Local Experimental EtherTypes™ (Playpen EtherTypes™) helps protocol developers meet the requirements for proper design.

Subtyping most often refers to the format described in IEEE Std 802a. Here, subtyping is defined for the two specific Local Experimental EtherTypes™. The same format for subtyping is encouraged for simplicity, though not required to meet the subtyping criteria for getting an EtherType™ assignment.

Vendor Specific Protocols are protocols that an organization or company has developed for broad deployment. These protocols may use the OUI Extended EtherType™ rather than applying for a unique EtherType™ value. The OUI Extended EtherType™ is described in IEEE Std 802a. Though not currently specified in IEEE Std 802a, it is expected that either an OUI or CID can be used with the specified two-octet extension to create a globally unique protocol identifier.

Visit the EtherType™ webpage for information.

IEEE Std 1451.4 is a member of the IEEE 1451 family of smart transducer standards. Distinguishing features of IEEE 1451.4 are:

• A mixed-mode communication interface (MMI), which allows digital data and analog waveforms to alternately occupy a single connection, with analog bandwidth not limited by sampling. Also defined are separate data and analog connections for transducer applications not adapted to the shared connection.
• A transducer electronic data sheet (TEDS) definition, adapted to very small memories through the use of templates and containing identification and calibration data.
• A template description language (TDL) allowing ongoing development of templates for diverse transducer types.
• A rich template collection adapting 1451.4 to large family of transducers.
• A transducer block definition allowing 1451.4 to adapt to the 1451.1 Object Model.

IEEE Std 1451.4 allows self-identification of transducers via the internal TEDS, easing bookkeeping in large measurement arrays. Stored sensitivity data allows data acquisition systems to standardize automatically to the installed transducers and track the transducers. A user field may be used to identify the transducer location in human readable format. The mixed-mode interface allows the analog waveform to be utilized in pristine form, without limitations of bandwidth introduced by sampling.

See a detailed description on IEEE Std 1451.4 operation. (PDF)

The IEEE 1451 family provides a set of common interfaces between sensors or actuators, instruments and networks. With these standard interfaces, interoperability and interchangeability of sensors or actuators across different transducer networks are thus established. These standards reduce the effort needed to develop networked smart transducers. The use of IEEE 1451.4 based transducers offers the potential for simple plug and play operation, simplifying transducer installation and system upgrade. For transducer (sensor or actuator) manufacturers, the need for major redesign of their product for compatibility with a specific instrument or network is eliminated. They can deliver products for multiple instruments and networks based on one set of standard interfaces.

For control network vendors, the availability of a large pool of network-compatible sensors and actuators will likely increase the utilization of control networks, thus creating a push-pull effort.

For system integrators, the standard interfaces will provide a significant reduction in implementation effort.

For end users, IEEE Standard 1451.4-2004 has the potential to significantly reduce the total life-cycle costs of the sensor system or network, which include installation, maintenance, and upgrade.

Within a 64-bit section of the 1451.4 TEDS, called basic TEDS, the manufacturer of the transducer is defined with a 14-bit code called the manufacturer ID, along with manufacturer-assigned transducer model number, model letter, model version number and serial number. (See IEEE Std 1451.4.2004 subclause 5.1.1, Table 2) The IEEE Registration Authority issues the manufacturer ID, to guarantee that it is unique to a manufacturer, and publishes the list of existing IEEE 1451.4 manufacturer ID’s. Data acquisition systems may make use of the basic TEDS, including manufacturer ID, and model number data in determining the transducer type and the proper template to be used in unpacking TEDS data, particularly in the case of a transducer manufacturer choosing to use a non-IEEE, or manufacturer, template. Do not confuse manufacturer ID and basic TEDS with URN, as they are two separate and distinct entities.

More details on the 1451.4 manufacturer ID and Basic TEDS. (PDF)
View the IEEE listing of 1451.4 manufacturer ID codes.

Apply for an IEEE 1451.4 manufacturer ID code.

The unique registration number is a 64-bit unique identifier contained in the memory devices, or nodes, in which IEEE 1451.4 TEDS data is stored. Because multiple nodes may be arrayed in a multi-drop network format, to allow memory capacity to be increased, or other functions to be added, the URN allows a number of nodes to be individually accessed by the system. (See IEEE Std 1451.4.2004 sub clause 5.4, figure 2) See more details on the use of the URN in node devices . (PDF)
Do not confuse the URN with manufacturer ID and basic TEDS, as they are two separate and distinct entities.

IEEE 1451.4 transducer manufacturers using commercially available nodes obtain a URN automatically in each node they purchase. Manufacturers wishing to emulate the IEEE 1451.4 node function with an ASIC or micro-controller, for example, must purchase a URN for each node function produced, for this purpose, the IEEE Registration Authority issues blocks of 4096 URN codes. If you are producing nodes for use with IEEE 1451.4, and wish to purchase a block of URN codes from IEEE-RA fill out our application.

Each of the standards in the IEEE 1451 family defines a storage format for data pertinent to a transducer, to be stored in the transducer. This data is called the transducer electronic data sheet, or TEDS. In general, transducer identification and calibration data are contained in the TEDS. In the case of IEEE 1451.4, the memory is large enough to contain only packed numerical data, without any units, which account for substantial memory usage in the TEDS definitions of the other standards. A template therefore defines the significance of the stored data in a 1451.4 transducer. The template is resident in the system, which reads the TEDS and unpacks the data.

View additional details on IEEE TEDS and templates (PDF)

A template is a documented definition of the placement and significance of each piece of data stored within the TEDS memory. (see IEEE Std 1451.4-2004 sub clause 5.3) The template is not contained within the TEDS data, but the TEDS data identifies which template is to be referenced in interpreting the TEDS data. Templates must be accessible to the program code, which is used to write and read the TEDS data, allowing that data to be properly packed for writing and unpacked subsequent to reading. Templates are written in the template description language (TDL) and contained in template description files. The template description file is an ASCII text file, written in TDL, and having a file name extension of .tdl. (see IEEE Std 1451.4-2004 sub clause 6.1) IEEE Standard 1451.4-2004 annex A contains several examples of the template description file. Typically the template description file is read by an application program which, at the same time, reads and interprets (or generates and writes) the bits from (to) TEDS.

Templates, or more precisely template description files, may be written by those having a transducer application not adapted to an IEEE published template. It is advisable that the library of IEEE templates be exhaustively investigated prior to undertaking writing a custom template, since it contains templates adapted to most transducer types. Using a standard template will save considerable effort by the user. The IEEE template description files can be found here.

Should writing a custom template be found necessary, please read and understand Clause 7, Template Description Language, contained in IEEE Std 1451.4-2004. Templates must be written in this language and the rules of the standard followed. More details on using TDL. (PDF)
As described in the standard, a company or user can create templates for use by all to whom the template description files are distributed. A template description file may be submitted to IEEE for consideration as IEEE template by the manufacturer who developed the template of significant use, under the following condition:

• The submitted template must have been in use for a sufficiently long period and by a sufficient number of users to demonstrate its effectiveness and freedom from defects.

All new templates must conform to the TDL syntax rules and pass the syntax check program located in the TDL programmer’s start-up kit described below.

Submit a new template to the IEEE-RA for consideration.

The application form and the template description file must be sent to the IEEE as indicated at the end of the form, for listing as an IEEE template. Manufacturers may elect to use non-IEEE templates for their own 1451.4 compliant products. Manufacturers choosing to use unpublished, manufacturer templates are solely responsible for the distribution and effective usage of these templates. All manufacturer templates must conform to the TDL syntax and template format guide. The format guide and TDL syntax check program are located in the TDL start-up kit.

NOTICE: The attached software is currently undergoing BETA testing. The software has not been verified for any particular purpose. USE AT YOUR OWN RISK. The software is intended solely as a tool of convenience. The software does NOT guarantee that a given product is or will be compliant with IEEE SA Standards and is NOT intended to be used, explicitly or implicitly, to certify or assure such compliance, and you shall NOT represent or imply to others that IEEE SA has tested, certified or otherwise approved of any product developed through use of this software.Download (ZIP) the programmer’s start-up kit for writing templates.

A major driving force behind the development of the IEEE 1451.4 standard was the need to minimize the amount of memory required to store a TEDS; with a stated objective of only needing 256 bits, although more are allowed. This requires a method of mapping the bits in a precise fashion. This bit mapping is accomplished through templates which are text based files written in the template description language (TDL). The TDL is a formal language similar to programming languages, but with considerably less looping and conditional control. This is because the entire purpose of the language is to map bits and not to implement general processing or mathematical capabilities.

Additional details on the functionality and syntax of the TDL. (PDF)

The IEEE Registration Authority issues IEEE 1451.4 manufacturer ID numbers on a fee basis. Apply for an IEEE 1451.4 manufacturer ID.

The IEEE Registration Authority issues IEEE 1451.4 URNs on a fee basis, in blocks of 4,096 numbers. Apply for IEEE 1451.4 URN blocks. Note: There is a maximum of 10 assignments that can be issued at one time.

The IEEE Registration Authority oversees the issuance of IEEE 1451.4 manufacturer ID numbers and URN blocks and keeps a current listing of the IEEE 1451.4 template files. To cover administrative costs, fees are charged for manufacturer ID numbers and URN blocks and to publish new templates. Payment terms are listed with the fees for each of these services.

Determine the fee or to obtain a manufacturer ID number.

Determine the fee or to obtain a URN block.

Determine the fee or to publish a new template.

The listings of existing IEEE 1451.4 manufacturer ID numbers and URN blocks are available for no charge, from the IEEE Registration Authority.

View existing manufacturer ID numbers.

There are no URN blocks assigned by the IEEE Registration Authority at this time.

The IEEE Registration Authority distributes URNs in blocks of 4,096, which is considered to be the smallest practical volume for administration purposes, at a reasonable fee for small volume users. IEEE-RA does not sanction the re-sale of partial URN blocks, due to the danger of loss of uniqueness. Several divisions within a company may share a block of URNs, however.

Manufacturers may obtain an additional manufacturer ID number only when the original has become exhausted. A statement must be furnished to the IEEE Registration Authority, verifying that 95% of the capacity of the original number has been used. The manufacturer ID occupies 14 bits of a 64-bit transducer identifier called the basic TEDS. The pool of individual transducer model numbers available to each holder of a single manufacturer ID, using the remaining 50 bits of the Basic TEDS as defined in IEEE Standard 1451.4-2004, is therefore in excess of 54.5 million model numbers. Each model may be produced up to a total in excess of 16.7 million serialized copies. By changing the version number or version letter, as defined in the Standard, a larger total of serialized copies of a given model may be supported. The total number of individual units identifiable using the IEEE Standard 1451.4-2004 basic TEDS, under a single manufacturer ID, is slightly in excess of 9 x 1014.

PSID stands for Provider Service Identifier. It is a globally unique integer value that is associated with a service being provided using a communications system such as 5.9 GHz DSRC WAVE.

The allocation of PSIDs is maintained and administered by the IEEE Registration Authority (IEEE-RA).

The Provider Service Identifier (PSID) has three uses specified in WAVE standards (see the tutorial for more detailed information). In general terms, the PSID is used to identify advertised provider services that are available; to route messages to the appropriate higher layer processes that can correctly process those messages; and to identify the permissions of participants in a service exchange.

If you or your organization are planning to develop an ITS service, then you might need a PSID.

If your service will utilize the WAVE Short Message protocol, then that service will need to be associated with a PSID. If your service utilizes IPv6 as the networking protocol, then you do not necessarily need a PSID to be allocated.

If your service will be advertised via the WAVE Service Advertisement mechanism, then your service will need a PSID.

If your service will utilize 1609.2 certificates then you will need a PSID allocated to your service.

Many PSIDs have already been allocated. If your service is based on an existing specification that uses an already allocated PSID, then you may be able to utilize that PSID.

You do not need to request both. PSIDs and ITS-AIDs share a number space, however are administered by multiple entities (e.g., IEEE Registration Authority). Applicants are encouraged to apply to a single registration entity for their service or application.

The PSID registry is maintained and administered by the IEEE Registration Authority. You may view the list of allocated PSIDs by visiting the IEEE-RA website.

Testing PSIDs have been pre-allocated for use in research and development projects. These can be used by any organization in development of their application.

You do not need to request to use a PSID allocated to testing, just start using it. For the list of allocated testing PSIDs, see public listing on the IEEE-RA website.

In the WAVE standards, a PSID is encoded into an octet string which can be from one to four octets in length. The number of octets requested depends on a number of factors which should be considered by the requester.

One and two octet PSIDs have limited availability and will be allocated on a limited basis. If your application is safety critical, and is expected to generate a large number of over-the-air messages, then your application may qualify for one of these PSIDs.

Four octet PSIDs will be suitable for most applications. If you request a PSID with fewer than four octets, then you must justify the need. The final determination regarding the PSID size that is allocated will be made by the IEEE-RA.

When PSIDs are formatted into over-the-air messages in a WAVE system, they are converted to a compact encoding known as p-encoding. See IEEE Std 1609.12 for details, and for a way to convert between the integer form and the p-encoded form.

In most cases you must complete a separate PSID request form for each PSID you are requesting.

No. If your allocation request is approved, the IEEE-RA will inform you of the value or values allocated.

If you have determined that you need to request a PSID allocation, take the following steps:

• Complete and submit the PSID Request Form found on the IEEE-RA website.
• You will be notified by IEEE-RA of the result of your request. This may take 90 days or more. This is a new process, and the IEEE-RA strives to respond in a timely manner.
• You can appeal the decision if you don’t agree with it.
• If you have questions regarding the process, see the IEEE-RA website for additional details and contact information.

The “Service/Application Name” entered on the application form should have the following characteristics:

• The name should be concise.
• The name should be unambiguous.
  • The name should not be identical or easily confused with an existing name in the public listing of PSIDs.
• The name should convey the nature of the service being provided by the application.
• Other considerations:
  • Include the name of, or reference to a project, e.g., in the case of limited or temporary deployments.
  • If the service/application is private, the name should include the name of the service provider, e.g., “(company name) Private Service 1″.

Examples of good names include “Electronic Fee Collection”, “Traveler information and roadside signage”, “CV Pilot Traffic Signal Priority”, “Peer-to-peer distribution of Security Management Information”, and “Vehicle initiated distress notification”.

The assignee of the PSID is expected to specify what the use of the PSID means to the level of specificity necessary to enable interoperability between implementations of the service or application identified by that PSID:

• If the PSID is used in a WAVE Service Advertisement (WSA), to specify what protocol is run when a response to the WSA is triggered on a User device;
• If the PSID is used in a WAVE Short Message (WSM), to specify what processing is applied to the WSM payload;
• If the PSID is used in an IEEE 1609.2 certificate, to specify what activities are permitted on the part of the certificate holder.

The specification may be public or private. The assignee has the authority to specify the Provider Service Context (PSC) and the Service Specific Permissions (SSP) associated with the PSID.

If your application is using 1609.2 certificates it will be necessary to identify a certificate authority that will issue certificates with your PSID. Certification of an implementation developed to a specification may be required in order to receive certificates.

For detailed information and specifications related to WAVE systems, please see IEEE Std 1609.0, IEEE Std 1609.2, IEEE Std 1609.3, IEEE Std 1609.4, IEEE Std 1609.12, and IEEE Std 802.11. See also the WAVE and PSID Tutorial.

An OpID is a 24-bit number that, per IEEE Std 802.16, is broadcast by each base station as part of its Base Station ID. An 802.16 network consists of one or more base stations operating as a coordinated system, with each base station in the coordinated network broadcasting the same OpID. The IEEE Registration Authority assigns the IEEE 802.16 Operator ID to be used as the Operator ID. See the Operator ID tutorial. (PDF)

No. Typical commercial systems providing public service require a globally unique OpID. This can be obtained from the IEEE Registration Authority. Alternately, a globally unique OpID can be derived from an operator’s E.212 MCC-MNC assignment. For networks providing service to a limited group of users where a globally unique OpID is not required by the operator, the OpID may be selected from the Public OpID pool. In this deployment scenario, the OpID may be selected from the pool to avoid having different networks in the same geographical area using the same OpID or so that a single operator can operate base stations with a single public OpID.

See the Operator ID tutorial. (PDF)

No. These are separate identifiers. They must be obtained separately and are not interchangeable.

The Base Station ID is a 48-bit number defined by IEEE Std 802.16 to be broadcast by each base station. The OpID defines the most significant 24-bits of the Base Station ID. An 802.16 network consists of one or more base stations operating as a coordinated system, with each base station in the coordinated network broadcasting the same OpID. By programming unique values in the least significant 24-bits of the Base Station ID for each base station, the Base Station ID then uniquely identifies each and every base station in the coordinated 802.16 network.

The latest available version of the OpID assignments can be found on the IEEE Registration Authority website.

No. If a company is sold, the OpID may be transferred to the new company. However, the OpID cannot be sold by anyone other than IEEE Registration Authority. See above.

Check the public listing to determine whether your company already has an assignment. If not, then complete the OpID application.

Once the application is completed successfully, the Applicant will receive an e-mail with a tracking number and payment information. The application will be processed within seven days after receipt of payment as long as there are no problems with the information on the application or the payment. The Applicant will receive an e-mail with the assignment information once the application is processed.

Yes. The IEEE Registration Authority will accept an application for an allocation of up to 100 OpIDs. If additional OpIDs are needed, you may complete an additional application. However, users of 802.16 OpIDs are encouraged to make most efficient use of this limited numbering resource. In typical deployment scenarios, the network operator will need only a single OpID, keeping in mind that a single OpID will support over 16 million Base Station IDs.

The MCC + MNC combination is a valid, globally unique 802.16 OpID. Specific coding of the MCC + MNC is required in order to be used in an 802.16 network. Coding instructions are included in the Operator ID tutorial. (PDF)

No. The formula for conversion of an E.212 MCC-MNC pair to an 802.16 OpID is only provided for those organizations that wish to use their E.212 network ID with 802.16, or may be required by regulation to do so. Organizations should check with their regulatory authorities as to whether they are required to use their current E.212 MCC-MNC pair to identify their networks using 802.16 standards. Any organization may obtain 802.16-specific OpID(s) from the IEEE Registration Authority, subject to the general terms & conditions covering application.

The OpID is assigned for worldwide use.

An OpID allocated by the IEEE Registration Authority is assigned to a single applicant. The assignee is guaranteed that the same number is not assigned to any other entity. Furthermore, the set of OpIDs that are assigned is disjoint from the set of OpIDs that may be derived from an E.212 MCC-MNC. The IEEE Registration Authority does not guarantee the MCC-MNC pair is unique. However, if all operators respect the rules for generating OpIDs and make use of unique MCC-MNC pairs, the OpID will be unique, since an OpID cannot be derived from two different E.212 MCC-MNC assignments. Any OpID selected from the Public OpID Pool is not guaranteed to be unique, as two operators may coincidently choose the same OpID. An operator choosing an OpID from the Public Pool must assess the consequences of another operator choosing the same OpID. For operators of a home or small enterprise network, the consequences may be insignificant, and choosing an operator ID from the public pool is a viable option.

The 802.16 standard requires the use of the OpID, as allocated by the IEEE Registration Authority. Failure to populate the a BS with an appropriate OpID will result in non-standard deployment and non-standard results. The value of the OpID field in new equipment is manufacturer-specific and should be verified by the operator.

A network OpID may be selected from the Public OpID Pool. Although such an OpID is not guaranteed to be globally unique, it will not cause mis-operation of any 802.16 SS/MS within its coverage or interference zones. Base stations in networks offering public service must use a globally unique OpID. Operators of base stations or networks using the Public OpID Pool should utilize appropriate access security techniques.

Although the total range of values is large, calculations of the probability of duplication in making a selection of truly random values from the full range yield the following results:

• Within 10 random selections, there is a probability of duplication of 0.18%
• With 23 random selections, there is a probability of duplication of 1%.
• There is a 10% probability of duplication within a selection of 72 numbers;
• There is a 50% probability of duplication within a selection of 185 numbers;
• There is a 99% probability of duplication within a selection of 476 numbers.

From this it may be concluded that there is, for example, a 10% chance that mis-operation due to OpID duplication may occur if there are 72 (otherwise identical) base stations closely located such that their associated MSs may see signals from all the other BSs.