An information model is a representation of a system. Typical models do not reflect all facets of the system, but only certain aspects required to solve the management problem the model is designed for. 3GPP follows an object-oriented modelling approach. Models are built from managed object classes. Each object class contains information elements called attributes. Relationships between classes represent the logical connections. Models are specified formally with class diagrams produced using the Unified Modelling Language (UML). The instantiation of a managed object class is called managed object instance, or concisely just managed object or object. All managed object instances together with the relationships between them constitute an object tree. An object tree is also called containment tree.

HTTP uses a different terminology based on the notion of resources, as defined in Section 2 of RFC 7231. Each resource is represented by one or more resource representations as defined in Section 3 of RFC 7231. Valid resource representations are e.g. XML instance documents or JSON instance documents. Besides this primary resource, Section 3.5 of RFC 3986 introduces the concept of secondary resources. Secondary resources are specific portions or subsets of primary resources, that are identifiable.

Resources can be classified according to their structure and behaviour into resource archetypes. This helps specifying clear and understandable interfaces. The following three archetypes are defined:

• Document resource: This is the standard resource containing data in form of name value pairs and links to related resources. This kind of resource typically represents a real-world object or a logical concept.
• Collection resource: A collection resource is grouping resources of the same kind. The resources below the collection resource are called items of the collection. An item of a collection is normally a document resource. Collection resources typically contain links to the items of the collection and information about the collection like the total number of items in the collection. Collection resources can be further distinguished into server-managed and client-managed resources. Collection resources are also known as container resources.
• Operation resource: Operation resources represent executable functions. They may have input and output parameters. Operation resources allow some sort of fall back to an RPC style design in case application specific actions cannot be mapped easily to CRUD style operations.

RESTful SS shall be specified in a way that managed object instances are described by (primary) document resources. Collection resources have no equivalent in an information model unless some dedicated collection class is introduced. Attributes are mapped to secondary resources.

Information models are used for two purposes when specifying interfaces to observe and act upon information models:

• They provide a means to identify information in request messages.
• They provide a format to transfer information in request and response messages.
• They provide constraints on the structure of information on the MnS Producer.
• They provide constraints on the possibilities to update information on the MnS Producer.

Identification of information is necessary when retrieving information from a MnS Producer; the MnS Consumer needs to be able to specify in his retrieveal request the information the MnS Producer shall return. But also when information needs to be updated or deleted the MnS Consumer needs to identify the information to be updated or deleted in his request. When information is added, the location of the new information is specified relative to the location of existing information. Request and response message bodies carrying (some parts of) the information model are also constructed based on the information model supported by the MnS Producer. The message format is either identical to the information model format or identical to some transformation of the information model format.

HTTP uses a subset of the generic Uniform Resource Identifier (URI) scheme (RFC 3986) defined in RFC 7230 for target resource identification. The path component is an absolute path (one that starts with a single slash character) or empty. The origin server is identified by the authority component, which includes a host identifier and an optional TCP port. The hierarchical path component and optional query component serve as an identifier for a potential target resource within that origin server's name space. The optional fragment component allows for indirect identification of a secondary resource.The host identifier is either an IP address or an indirect identifier such as a FQDN to be resolved with DNS. URIs are used by HTTP for routing and addressing of target resources.

URIs are globally unique. For this reason only a globally unique DN with DC is mappable into a URI. The mapping rules are as follow:

• The DN prefix is mapped semantically to the authority component of the URI. The syntax of the DN prefix is modified to match the syntax of the authority component.
• The LDN is mapped semantically to the path component of the URI. The syntax of the LDN is modified to match the syntax of the path component.

When mapping a LDN the equal sign "="shall be used as delineator between the naming attribute name and naming attribute value when constructing a RDN. The URI-LDN is the concatenation of URI-RDNs separated by a slash "/". For example, the LDN maps to and the LDN to When constructing the authority part from the DN prefix, it shall be reformatted according to the name conventions applying to FQDNs. For example, the DN prefix maps to and the DN prefix to The complete URIs for the examples are The constructed URI-DN-prefix is a FQDN that can be registered into a name resolution service such as DNS. The sole presence of a constructed FQDN does not mean it can be resolved to an IP address and there is a server listening at that address. Using the mapping rule, a DN is mapped predictably into the URI authority component and path component. The character set allowed in DNs is much bigger than the character set allowed in the path component and authority component of a URI. Care needs to be taken when selecting the naming attribute names und values that the mapping from a DN to a URI does not become impossible as a consequence of not mappable characters. When no registered name can be used, the IP address shall be specified directly in the host component, for example: This might be required in multiple situations. For example, when a DN prefix is used but the corresponding URI-DN-prefix cannot be resolved, the MnS Consumer needs to specify an IP address in the target URI of HTTP request messages. The same is true when no DN prefix is used at all. Another example is when no DN prefix is configured into MnS Producers and the MnS Producer wants to report events, that occurred related to resources, using notifications sent to MnS Consumers. The MnS Producer has no other option than to put its own IP address into the host component of the URI identifying the resource where the event occurred.

The URI defined in clause 4.2.3 is called canonical URI. It is the main or official URI of a resource. It shall be used whenever the resource as such shall be identified. The URI for sending HTTP requests to a resource may be different as described in clause 4.4. Special kinds of requests may have all their own URI. Therefore, a resource has typically one canonical URI and one or more other URIs. The canonical URI may be looked at as a protocol specific version of the protocol neutral DN. A canonical URI may or may not yield further information if dereferenced. An example usage of a canonical URI is in event notifications such as alarm notifications for identifying the resource where the event occurred.

The format of HTTP request and response message content is indicated with media types consisting of a type, a subtype and optional parameters, as defined in Section 3.1.1.1 of RFC 7231. The "Content-Type" header field of a message contains the media type of the message content (Section 3.1.1.5 of RFC 7231). If not otherwise stated, the media type of request and response message bodies in the REST SS is

• application/json (RFC 7159).

Exceptions are when JSON patch documents are contained in request bodies. They are identified with the media types

• application/merge-patch+json (RFC 7396, and clause 6.3.2 of the present document),
• application/json-patch+json (RFC 6902, and clause 6.3.3 of the present document).

Furthermore, this specification defines four new formats. Their media types are

• application/vnd.3gpp.merge-patch+json (clause 6.4.2 of the present document),
• application/vnd.3gpp.json-patch+json (clause 6.4.3 of the present document),
• application/vnd.3gpp.object-tree-hierarchical+json (clause 6.1.4 of the present document),
• application/vnd.3gpp.object-tree-flat+json (clause 6.1.4 of the present document).

JSON documents shall conform to JSON Schema ([7], [8], [9]).

The MnS Consumer shall engage in proactive content negotiation as defined in Section 3.4.1 of RFC 7231 by including the "Accept" request header field in HTTP requests that expect a message body in the response. The "Accept" header field indicates to the MnS Producer the media types acceptable to the MnS Consumer. If the MnS Producer cannot provide any of the acceptable resource representations, it shall respond either with a "406 Not Acceptable" error code or provide a representation for the resource that is not specified in the "Accept" header field.

MnS producers can be divided into two categories. The first category exposes MnS(s) to manipulate resources representing managed object instances. In this case the URI structure is governed by the mapping rules defined in clause 4.2.3. The second category exposes MnS(s) to manipulate resources not representing managed object instances. In this case the DN concept is not relevant. The URI structure for both categories is different.

URIs identifying resources representing managed object instances shall follow, when being used as a target URI in HTTP requests, the structure given by with: As seen above, to construct the URI from a DN, it is necessary to map the "DNPrefixPlusRDNSeparator" as defined in clause 7.3 of TS 32.300, the "LocalDN" as defined in clause 7.3 of TS 32.300, and to add the additional optional path segments "/{root}/{MnSName}/{MnSVersion}". To allow for a predictive mapping from an URI to the original DN it is necessary to specify "/{MnSName}/{MnSVersion}" in such a way that the beginning of the "LocalDN" can be unambigously identified. or For the sake of brevity, "MnSRoot" is introduced that includes the "{scheme}" part, the colon (":"), the two slash characters ("//"), the "{authority}" part, a single slash character ("/") and the "{root}" part. When using "{MnSRoot}" the abbreviated URI structure is given by or It is recommended to use this abbreviated version of the URI structure when defining Management Services. The path segment "MnSVersion" allows access to resources with different MnS versions, for example: Note that both URIs, though different as to the path segment indicating the version number of the ProvMnS, identify the same resource that is identified by the canonical URI: http://operatorA.com/SubNetwork=south/.../Cell=1 and whose DN is: DC=operatorA.com,SubNetwork=south,...,Cell=1 The optional path component "/{root}" may be used to separate the name space for 3GPP management from the name space for other domains: or to provide dedicated URIs on the same host for different tasks: Note that when different hosts are used for different management tasks, like in then also the resources are different and identifierd by the canonical URIs or the DNs In the example above, it is assumed that both resources represent the same cell in the network. This information cannot be derived from the DN or canonical URI, though.

URIs identifying other resources shall follow, when being used as a target URI in HTTP requests, the structure given by with: For the sake of brevity, {MnSRoot} is introduced that includes the "{scheme}" part, the two slash characters ("//"), the "{authority}" part, a single slash character ("/") and the "{root}" part. When using "{MnSRoot}" the abbreviated URI structure is given by It is recommended to use this abbreviated form of the URI structure when defining Management Services

The resource identified by "../{MnSName}/{MnSVersion}" is called NRM root. It represents the conceptual parent of the top-level managed object instances. It is created by the MnS Producer. A MnS Consumer cannot create or delete this resource. The resource is the target resource for many HTTP requests, such as requests to retrieve all top-level managed object instances in case there are multiple top-level managed object instances, or for requests to create objects in case there are no manged object instances yet and the creation request needs to be directed to the parent of the resource to be created. Attempts to read the NRM root only shall return "204 No Content".