ISO IEC 29161:2016 download free.Information technology-Data structure – Unigue identification for the Internet of Things.
In applications of the Internet of Things (loT), one Nthing can communicate with other things” via the Internet. For that “thing” to communicate, it should possess an identifier of “which it is.
The ISO/IEC 15459- series does a good job identifying how groups that have been assigned an issuing agency code can create a character-based system of unique identification.
There is no shortage of claimants to provide that identifier. Each is understandable due to its origins and the perspective from which it comes. The Internet is a network and groups such as the International Telecommunications Union (ITU) and the Internet Engineering Task Force (IETF) view this identifier as amechanismtofacilitatenetworkrouting. ITU-TX.6681 ISO/1EC9834.9and ITU-TX.660 I lSO/1EC9834- 1 attempt to fill this need from a network perspective. From a network perspective, it is accepted that the identification of an entity must resolve to an lP address for contacting it, whether its domain name hangs” from an OlD root using an OlD resolver, or from a more general DNS node (which may end up as the same thing).
However, not everything is viewed from the perspective of the network, nor necessarily should it so be viewed. The network is a transport mechanism and the entities themselves have historic identifiers, which have their genesis from supply chain applications and identification.
Ultimately, the various forms of unique identification identified within ISO IEC 29161 need to be combined in a single message in an unambiguous form. ISO IEC 29161 provides a method enabling this combination in an unambiguous form.
1 Scope
ISO IEC 29161 establishes a unique identification scheme for the Internet of Things (loT), based on existing and evolving data Structures. ISO IEC 29161 specifies the common rules applicable for unique identification that are required to ensure lull compatibility across different Identities. The unique identification is a universal construct for any physical object, virtual obfrct, or person. Ills used in loT information systems that need to track or otherwise refer to entities. It is intended for use with any loT media.
2 Normative references
The following documents, In whole or In part, are normatively referenced In this document and are Indispensable for its application. For dated references, only the edition cited applies. For undated references, the Latest edition of the referenced document (induding any amendments) applies.
There are no normative references in this document,
3 Terms and definitions
For the purposes of this document, the terms and definitions given In ISO/IEC 19762 and the Following apply
coap
constrained application protocol
ISOURCE: RFC 72521
3.2
entity
any concrete or abstract thing of interest. including associations among things
ISOURCE: ISO/PAS 16917J
Plate I to entry: Information also provided lnAn1fD.
3.3
rest
representational state transfer
4 Abbreviated terms
2D 2 DImensional
ALDC Automatic Identification and Data Capture
IC Integrated Circuit
loT Internet of Things
6.22 Listing of existing URN schemes referenced by ISO IEC 29161 The following listing shows some of those URN schemes already defined.
— Unique Identifiers called out In ISO standards using the Object Identifiers as listed In the ISO/IEC 15961.2 Data Constructs Register. For example, Table 3 of the lSO/IEC 15961.2 Data Construct Register, includes the unique identifier starting with the character string 25S” that is part nithe Data Identifier system (see ISO/IEC 15418). The Data Constructs Register shows that this corresponds to the URN urn:oid:1.0.15961.13.l’ because 15961 assigns a Data Format number ‘13” for Data Identifiers, and the associated Relative OlD Table assigns .1, for “25S”
— Unique identifiers called out in ISO standards using the Object Identifiers as listed in the
ISO/IEC 15459-1, ISO/IEC 15459-4, ISO/IEC 15459-S and ISO/IEC 15459-6. URN for lSO/IEC 15459- 1 is “urn:1.0.15459.1
— IPV4: see RFC 3291. The inctAddrrssMlH Is 1.3.6.1.2.1.76 and the type ipv4 (1).
— IPV6: see RFC 3291. The lnetAddressMlH is 1.3.6.1.2.1.76 and the type lpv6 (2).
— Jabber ID: RFC 3920, 5.1.1 defines this OlD: urn:oid:1.36.1.5.5.7.8.5.
— MIt: urn:oid:2.271, per ISO/IEC 29174 and the Data Constructs Register.
6.3 URI usage in loT systems
In some existing appilcatlons, a specific data carrier only encodes one type of identifier, and the choke ola specilic URI as an unambiguous wrapper is predetermined. In other cases, however, a data carrier may encode a wide variety of different unique identIfiers, and the appropriate “wrapper cannot be unambiguously distinguished from context. Therefore, it will often be the case that the appropriate URI wrapper must be determined (from some sort of encoded signal in the data carrier) in order to include that encoded identifier in a mixed-format loT message.
It is important to note that the URI always provides an unambiguous name for the identifier and In some cases provides the value of that Identifier as welL For example, tJRLs always provide a value (the destination web address) along with the name of the identifier (“http). The same Is true for some forms of URN, such as the ‘urn;epc” form. For example, urri:epc:id:sgtin:0614141.033254.1 not only names the identifier (as a pure SGLN) but also provides the specific unique value of that instance.
In other cases, such as the “urn:oid:1.0.15961.n.n’ form used to encode item-attendant data in ISO/IEC 18000-63 tags, the URI sppIies only the name of the identifier. In this case, the name is efficiently encoded on the tag as a “relative oid,’ and the complete Identifier Is both encoded and transmitted as a <name, value> paIr. This <name, value> format can be easily represented in many relevant protocols, such as those based on XML
For example, In a hypothetical XML-based protocol, a <name.value> Identifier could be represented as follows:
cwidgetlD lDname&”urn:oid:I .0 15961 13.I”>25S123456789ABC123c/widgetlD>
Continuing the same hypothetical example, an identifier whose urn conveys both name and value could be represented as an empty-element tag, such as:
<widgetiD IDname=” urn:epc:ld:sgtin:0614141.33254.1”></widgetlD>
cwidgetlD>urn:epc:id:sgtin:0614141.33254.1”> </widgettD>
Auneih details how “unambiguous wrapper URIs could be encoded or otherwise signalled in relevant SC 31 data carriers, and how they could be conveyed in relevant data protocols. Therefore, AniietA
provides multiple use cases for handling a specific scenario. Anni provides an example of URI usage in a protocol suitable for data carriers including sensor networks,
In many of the protocols that are ilkely to convey loT identifiers, such as those based on XML pure binary data cannot be directly supported. That Is to say that although the data carrier may encode such identifiers as a series of 8’bit binary values, when transmitted each such byte value shall be represented as two ASCII characters, eadi in the range ‘O’.,’9’ or
7 Use of unique Identification
7.1 Ulconcept
The Unique Identification (Ill) concept employs a qualifier and string component which shall be unambiguous within its qualifier, in the sense that no issuer re-issues the string within the qualifier over the entire life cycle for the identified entity or until a sufficient period of rime has passed so that the identity has ceased to be of significance to any user.
7.2 Ulencodlng
Depending upon existing schemes Unique identification (UI) can be either numeric, binary or alphanumeric.
When the URN Is encoded In a data carrier, It should comply with the encoding rules of that carrier technology.