4 Structure and content of configuration data XML files

32.6153GPPBulk CM Integration Reference Point (IRP): eXtensible Markup Language (XML) file format definitionConfiguration Management (CM)Release 9Telecommunication managementTS

The present clause defines the file format of configuration data XML files exchanged between an IRPManager and an IRPAgent as part of upload and download operations of the Bulk CM IRP IS (see [1]).

Upload and download configuration data XML files share a common file format defined by the XML schema in Annex A and by the following clauses.

Additionally, vendor-specific XML schemas shall be provided to enable configuration data XML files to carry vendor-specific data (see clause 4.5).

The use of XML schemas enables to ensure configuration data XML files have the proper structure and to some extent the proper content, and in particular to ensure:

– for a given NRM instance, it is properly named/positioned with regard to the global NRM naming tree;

– for a given NRM instance, only attributes of the corresponding NRM class are present;

– for a given NRM attribute, its value is of the proper type.

Location of the XML schemas used for configuration data XML files is outside the scope of this document.

4.1 Global structure

The content of a configuration data XML file is the succession of:

– the standard XML declaration with specification of the version of XML and of the character encoding being used (see [2]);

– a bulkCmConfigDataFile XML element; this is the root XML element of configuration data XML files.

The definition of the allowed character encoding(s) is outside the scope of this document.

As defined by the following extract of XML schema configData.xsd (see Annex A):

<element name="bulkCmConfigDataFile">
<complexType>
<sequence>
<element name="fileHeader">
[…]
</element>
<element name="configData" maxOccurs="unbounded">
[…]
</element>
<element name="fileFooter">
[…]
</element>
</sequence>
</complexType>
</element>

the XML content of a bulkCmConfigDataFile XML element is the succession of:

– a fileHeader XML element (see clause 4.2);

– one or several configData XML elements (see clause 4.3);

– a fileFooter XML element (see clause 4.2).

XML elements fileHeader and fileFooter are empty XML elements (see clause 4.2).

The bulkCmConfigDataFile XML element shall also have all the XML attribute specifications that declare the XML namespaces (see [6]) used in the XML file.

The following XML namespaces are potentially used in configuration data XML files:

– the default XML namespace is associated with the configuration data files base XML schema configData.xsd (see Annex A);

– for each NRM-specific XML schema, a specific XML namespace prefix is defined for the associated XML namespace (see clause 4.3A.1);

– XML namespaces prefixes starting with vs, e.g. vsRHO11, are reserved for the XML namespaces associated with the vendor-specific XML schemas (see clause 4.5).

Each configData XML element (see clause 4.3) carries:

– NRM instances with or without their NRM attribute values in a NRM naming tree organized structure together with modifier XML attribute specification (see clause 4.4);

– possibly vendor-specific data (see clause 4.5).

A configData XML element can carry an entire tree of NRM instances with their NRM attribute values and the related vendor-specific data or any subset of it.

The following is an example of a configuration data XML file, without presentation of the XML attribute specifications and XML content of fileHeader, configData and fileFooter XML elements (replaced by […]; see clauses 4.2, 4.3, 4.4 and 4.5):

<?xml version="1.0" encoding="UTF-8"?>
<bulkCmConfigDataFile
xmlns=
"http://www.3gpp.org/ftp/specs/archive/32_series/32.615#configData"
[…]
>
<fileHeader […]/>
<configData […]>
[…]
</configData>
<configData […]>
[…]
</configData>
<fileFooter […]/>
</bulkCmConfigDataFile>

4.2 XML elements fileHeader and fileFooter

4.2.1 XML element fileHeader

As defined by the following extract of XML schema configData.xsd (see Annex A):

<element name="fileHeader">
<complexType>
<attribute name="fileFormatVersion" type="string" use="required"/>
<attribute name="senderName" type="string" use="optional"/>
<attribute name="vendorName" type="string" use="optional"/>
</complexType>
</element>

a fileHeader XML element:

– has the following XML attribute specifications:

– a fileFormatVersion XML attribute specification; this attribute specification carries the abridged number and version of this 3GPP document (see below); this identifies the version of the file format used for assembling the XML file;

– a conditional senderName XML attribute specification; this attribute specification shall be present only in XML files generated by the IRPAgent; it carries the DN of the IRPAgent that assembled the XML file, i.e. the value of the systemDN NRM attribute of the IRPAgent NRM instance (see [8]);

– a conditional vendorName XML attribute specification; this attribute specification shall be present only in XML files generated by the IRPAgent; it carries the name of the vendor of the IRPAgent that assembled the XML file;

– and has an empty XML content.

The abridged number and version of a 3GPP document is constructed from its version specific full reference "3GPP […] (yyyy-mm)" by:

– removing the leading "3GPP TS";

– removing everything including and after the version third digit, representing editorial only changes, together with its preceding dot character;

– from the resulting string, removing leading and trailing white space, replacing every multi character white space by a single space character and changing the case of all characters to uppercase.

The following is an example of a fileHeader XML element:

<fileHeader
fileFormatVersion="32.615 V4.0"
senderName="DC=a1.companyNN.com,SubNetwork=1,IRPAgent=1"
vendorName="Company NN"
/>

4.2.2 XML element fileFooter

As defined by the following extract of XML schema configData.xsd (see Annex A):

<element name="fileFooter">
<complexType>
<attribute name="dateTime" type="dateTime" use="required"/>
</complexType>
</element>

a fileFooter XML element:

– has a dateTime XML attribute specification; this attribute specification carries the date and time the XML file was assembled;

– and has an empty XML content.

The following is an example of a fileFooter XML element:

<fileFooter dateTime="2001-05-07T12:00:00+02:00"/>

4.3 XML element configData

As defined by the following extract of XML schema configData.xsd (see Annex A):

<element name="configData" maxOccurs="unbounded">
<complexType>
<choice>
<element ref="xn:SubNetwork"/>
<element ref="xn:MeContext"/>
<element ref="xn:ManagedElement"/>
</choice>
<attribute name="dnPrefix" type="string" use="optional"/>
</complexType>
</element>

a configData XML element:

– has an optional dnPrefix XML attribute specification; this attribute specification carries the DN Prefix information as defined in Annex C of 3GPP TS 32.300 [7];

– and its XML content is an instance of the specific type of XML element (see below) corresponding to one of the NRM classes SubNetwork, MeContext or ManagedElement (see [8]); depending on the System Context of the IRP (see [1]) the used NRM class shall be:

– in case of System Context A, only SubNetwork NRM class, or;

– in case of System Context B, only MeContext or ManagedElement NRM class.

This instance of SubNetwork/MeContext/ManagedElement NRM class corresponding specific XML element type is the starting point for a configData XML element to possibly contain several NRM instances in a NRM naming tree organized structure (see clause 4.3A.2).

The following is an example of a configData XML element:

<configData dnPrefix="DC=a1.companyNN.com">
<xn:SubNetwork […]>
[…]
</xn:SubNetwork>
</configData>

4.3A NRM-specific XML elements

NRM-specific XML element types are generically defined under the mapping rules defined in clause 4.3A.2.

NRM-specific XML element types are explicitly declared by NRM-specific XML schemas as defined in clause 4.3A.1.

4.3A.1 NRM-specific XML schemas

NRM-specific XML schemas are defined in the NRM-specific parts (see clause 1) of the XML file format definition for the Bulk Configuration Management IRP IS [1].

NRM-specific XML schemas with definition of corresponding XML namespace prefixes (see clause 4.1) are listed by the following table:

Table 2: NRM-specific XML schemas, corresponding 3GPP TSs and XML namespace prefixes

NRM

XML schema

3GPP TS no.

XML namespace prefix

Core Network Resources

coreNrm.xsd

32.635 [12]

cn

Generic Network Resources

genericNrm.xsd

32.625 [11]

xn

GERAN Network Resources

geranNrm.xsd

32.655 [14]

gn

IM Network Resources

inventoryNrm.xsd

32.695 [16]

in

IMS NRM

imsNrm.xsd

32.735 [18]

im

STN Network Resources

stnNrm.xsd

32.745 [15]

stn

TN Network Resources

transportNrm.xsd

32.715 [17]

tn

UTRAN Network Resources

utranNrm.xsd

32.645 [13]

un

E-UTRAN Network Resources

eutranNrm.xsd

32.765 [19]

en

EPC Network Resources

epcNrm.xsd

32.755 [20]

epc

SON Policy Network Resources

sonPolicyNrm.xsd

32.525 [21]

sp

Subscription Management Network Resources

sumNrm.xsd

32.175 [22]

sn

Repeater Network Resources

RepeaterNrm.xsd

32.725 [23]

rn

HNS Network Resources

hnsNrm.xsd

32.775 [24]

hn

HeNS Network Resources

hensNrm.xsd

32.785 [25]

hen

Each NRM-specific XML schema explicitly declares NRM-specific XML element types for the related NRM.

Additionally, XML schema genericNrm.xsd (see [11]) also provides global XML declarations and definitions for the support of:

– NRM-specific XML element type declaration;

– vendor-specific XML element type declaration (see clause 4.5).

4.3A.2 Generic mapping rules

NRM-specific XML element types are generically defined under the following mapping rules:

– to each NRM class corresponds a specific type of XML element having the following characteristics:

– its name is the name of the NRM class;

– it derives by extension (see [3], [4] and [5]) the NrmClass XML complex type defined in the XML schema genericNrm.xsd (see [11]);

– it has the following XML attribute specifications, inherited from NrmClass XML complex type:

– an id XML attribute specification; this attribute specification carries the attribute value part of the RDN of the NRM instance carried by the XML element, i.e. the value of the naming attribute of this NRM instance;

– an optional modifier XML attribute specification (see clause 4.4);

– and its XML content is the succession of:

– an optional attributes XML element whose XML content is the succession of:

– zero or more specific XML elements (see below) corresponding to attributes of the NRM class, each occurring not more than once;

– zero or more similar specific XML elements corresponding to direct subordinate NRM classes of the NRM class to which the current XML element corresponds;

– to each NRM attribute of each NRM class, except for the following NRM attributes:

– the naming NRM attribute of each NRM class, whose value is already carried by the id XML attribute specification of the specific XML element corresponding to the NRM class;

– the conditional dnPrefix NRM attribute of SubNetwork, MeContext and ManagedElement NRM classes (see [8]), whose value is already carried by the dnPrefix XML attribute specification of the configData XML element;

corresponds a specific type of XML element having the following characteristics:

– its name is constructed from the name of the NRM attribute by removing any contained dash character;

– and it has an XML content; this XML content carries the value of the NRM attribute.

For example for the SubNetwork NRM class (see [8]), the corresponding extract of XML schema genericNrm.xsd (see [11]) is the following:

<element name="SubNetwork">
<complexType>
<complexContent>
<extension base="xn:NrmClass">
<sequence>
<element name="attributes" minOccurs="0">
<complexType>
<all>
<element name="userLabel" minOccurs="0"/>
<element name="userDefinedNetworkType" minOccurs="0"/>
</all>
</complexType>
</element>
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="xn:SubNetwork"/>
<element ref="xn:ManagedElement"/>
<element ref="xn:MeContext"/>
<element ref="xn:ManagementNode"/>
<element ref="xn:IRPAgent"/>
<element ref="xn:SubNetworkOptionallyContainedNrmClass"/>
</choice>
</sequence>
</extension>
</complexContent>
</complexType>
</element>

supported by the following extract of XML schema genericNrm.xsd (see [11]):

<complexType name="NrmClass">
<attribute name="id" type="string" use="required"/>
<attribute name="modifier" use="optional">
[…]
</attribute>
</complexType>

Exceptions to the generic mapping rules for the definition of NRM-specific XML element types are listed by the following table:

Table 3: Generic mapping rule exceptions

NRM classes / attributes

NRM 3GPP TS no.

Exception description references

vsData attribute of VsDataContainer class

32.622 [8]

clause 4.5 of the present document and

annex A of 3GPP TS 32.625 [11]

The following is an example of a configData XML element with regard to NRM-specific XML elements (in bold) in a configuration data XML file:

<?xml version="1.0" encoding="UTF-8"?>
<bulkCmConfigDataFile
xmlns=
"http://www.3gpp.org/ftp/specs/archive/32_series/32.615#configData"
xmlns:xn=
"http://www.3gpp.org/ftp/specs/archive/32_series/32.625#genericNrm"
[…]
>
[…]
<configData dnPrefix="DC=a1.companyNN.com">
<xn:SubNetwork id="1">
<xn:attributes>
<xn:userLabel>Paris SN1</xn:userLabel>
<xn:userDefinedNetworkType>UMTS</xn:userDefinedNetworkType>
</xn:attributes>
<xn:ManagementNode id="1">
<xn:attributes>
<xn:userLabel>Paris MN1</xn:userLabel>
<xn:vendorName>Company NN</xn:vendorName>
<xn:userDefinedState>commercial</xn:userDefinedState>
<xn:locationName>Montparnasse</xn:locationName>
</xn:attributes>
</xn:ManagementNode>
<xn:ManagedElement id="1">
<xn:attributes>
<xn:managedElementType>RNC</xn:managedElementType>
<xn:userLabel>Paris RN1</xn:userLabel>
<xn:vendorName>Company NN</xn:vendorName>
<xn:userDefinedState>commercial</xn:userDefinedState>
<xn:locationName>Champ de Mars</xn:locationName>
</xn:attributes>
</xn:ManagedElement>
<xn:ManagedElement id="2">
<xn:attributes>
<xn:managedElementType>RNC</xn:managedElementType>
<xn:userLabel>Paris RN2</xn:userLabel>
<xn:vendorName>Company NN</xn:vendorName>
<xn:userDefinedState>commercial</xn:userDefinedState>
<xn:locationName>Concorde</xn:locationName>
</xn:attributes>
</xn:ManagedElement>
</xn:SubNetwork>
</configData>
[…]
</bulkCmConfigDataFile>

4.4 XML attribute specification modifier

As defined by the following extract of XML schema genericNrm.xsd (see [11]):

<attribute name="modifier" use="optional">
<simpleType>
<restriction base="string">
<enumeration value="create"/>
<enumeration value="delete"/>
<enumeration value="update"/>
</restriction>
</simpleType>
</attribute>

the value of the optional modifier XML attribute specification of the specific XML elements corresponding to the classes of the NRM is one of the following: create, delete, or update.

The semantic carried by a modifier XML attribute specification applies only to the NRM instance corresponding to the containing XML element and not to any explicit or implicit subordinate NRM instances of this NRM instance.

The following rules apply for the modifier XML attribute specification:

– in upload XML configuration files, no modifier XML attribute specification should be present; on the contrary those are to be considered as meaningless and shall be ignored;

– in download XML configuration files:

– if an XML element carrying an NRM instance has a modifier XML attribute specification of value create, then all directly or indirectly contained XML element carrying NRM instances, if any, shall also have a modifier XML attribute specification of value create;

– if an XML element carrying an NRM instance has a modifier XML attribute specification of value delete, then all directly or indirectly contained XML element carrying NRM instances, if any, shall also have a modifier XML attribute specification of value delete;

– if an XML element carrying an NRM instance has a modifier XML attribute specification of value update, then all directly contained XML element carrying NRM instances, if any, may also have a modifier XML attribute specification, this one being of either value create, delete, or update;

– if an XML element carrying an NRM instance has no modifier XML attribute specification or a modifier XML attribute specification of value delete, then it shall not directly contain an attributes XML element.

A tree of XML elements corresponding to a tree of NRM instances with all XML elements having a modifier XML attribute specification of value create is considered to be in accordance with the following rule from Bulk CM IRP IS 3GPP TS 32.612 [1]:

"When part or a whole NRM subtree is to be created, in the configuration data file the IRPManager shall first action the create action of parents MO instances before actioning the create of any child MO instances contained in the NRM subtree i.e. create actions on MO instances shall be specified in recursive manner following the NRM hierarchy subtree from the highest MO instances to the lowest MO instances the IRPManager requires to be created."

In such a tree of NRM instances, the XML element carrying a given NRM instance does not accurately appear before XML elements carrying subordinate NRM instances. The latter XML elements rather appear as the last part of the XML content of the former XML element.

Nevertheless, XML parsing of such a tree of NRM instances can still enable the above Bulk CM IRP IS rule to be fully respected. Example of an XML parsing enabling such compliance is one effectively actioning the creation of each NRM instance when having parsed the XML start-tag of the XML element carrying the NRM instance and, if any, the contained attributes XML element.

A tree of XML elements corresponding to a tree of NRM instances with all XML elements having a modifier XML attribute specification of value delete is considered to be in accordance with the following rule from Bulk CM IRP IS 3GPP TS 32.612 [1]:

"When part or whole NRM subtree is to be deleted, in the configuration data file the IRPManager shall first action delete of all associated child instances contained in the NRM subtree before actioning delete of MO parents instances i.e. delete actions on MO instances shall be specified in a recursive manner following the NRM hierarchy subtree from the lowest MO instances to the highest MO instances the IRPManager requires to be deleted."

In such a tree of NRM instances, the XML elements carrying subordinate NRM instances do not appear before the XML element carrying the parent NRM instance. The former XML elements rather appear as the XML content of the latter XML element.

Nevertheless, XML parsing of such a tree of NRM instances can still enable the above Bulk CM IRP IS rule to be fully respected. Example of an XML parsing enabling such compliance is one effectively actioning the delete of each NRM instance when parsing the XML end-tag of the XML element carrying the NRM instance.

The following are examples of legal configData XML element with regard to modifier XML attribute specification (in bold) in configuration data XML files:

– example 1:

<?xml version="1.0" encoding="UTF-8"?>
<bulkCmConfigDataFile
xmlns=
"http://www.3gpp.org/ftp/specs/archive/32_series/32.615#configData"
xmlns:xn=
"http://www.3gpp.org/ftp/specs/archive/32_series/32.625#genericNrm"
[…]
>
[…]
<configData dnPrefix="DC=a1.companyNN.com">
<xn:SubNetwork id="1" modifier="create">
<xn:attributes>
<xn:userLabel>Paris SN1</xn:userLabel>
<xn:userDefinedNetworkType>UMTS</xn:userDefinedNetworkType>
</xn:attributes>
<xn:ManagementNode id="1" modifier="create">
<xn:attributes>
<xn:userLabel>Paris MN1</xn:userLabel>
[…]
<xn:locationName>Montparnasse</xn:locationName>
</xn:attributes>
</xn:ManagementNode>
<xn:ManagedElement id="1" modifier="create">
<xn:attributes>
<xn:managedElementType>RNC</xn:managedElementType>
[…]
<xn:locationName>Champ de Mars</xn:locationName>
</xn:attributes>
</xn:ManagedElement>
<xn:ManagedElement id="2" modifier="create">
<xn:attributes>
<xn:managedElementType>RNC</xn:managedElementType>
[…]
<xn:locationName>Concorde</xn:locationName>
</xn:attributes>
</xn:ManagedElement>
</xn:SubNetwork>
</configData>
[…]
</bulkCmConfigDataFile>

– example 2:

<?xml version="1.0" encoding="UTF-8"?>
<bulkCmConfigDataFile
xmlns=
"http://www.3gpp.org/ftp/specs/archive/32_series/32.615#configData"
xmlns:xn=
"http://www.3gpp.org/ftp/specs/archive/32_series/32.625#genericNrm"
[…]
>
[…]
<configData dnPrefix="DC=a1.companyNN.com">
<xn:SubNetwork id="1">
<xn:ManagedElement id="1" modifier="create">
<xn:attributes>
<xn:managedElementType>RNC</xn:managedElementType>
[…]
<xn:locationName>Champ de Mars</xn:locationName>
</xn:attributes>
</xn:ManagedElement>
<xn:ManagedElement id="2" modifier="create">
<xn:attributes>
<xn:managedElementType>RNC</xn:managedElementType>
[…]
<xn:locationName>Concorde</xn:locationName>
</xn:attributes>
</xn:ManagedElement>
</xn:SubNetwork>
</configData>
[…]
</bulkCmConfigDataFile>

– example 3:

<?xml version="1.0" encoding="UTF-8"?>
<bulkCmConfigDataFile
xmlns=
"http://www.3gpp.org/ftp/specs/archive/32_series/32.615#configData"
xmlns:xn=
"http://www.3gpp.org/ftp/specs/archive/32_series/32.625#genericNrm"
[…]
>
[…]
<configData dnPrefix="DC=a1.companyNN.com">
<xn:SubNetwork id="1" modifier="delete">
<xn:ManagementNode id="1" modifier="delete">
</xn:ManagementNode>
<xn:ManagedElement id="1" modifier="delete">
</xn:ManagedElement>
<xn:ManagedElement id="2" modifier="delete">
</xn:ManagedElement>
</xn:SubNetwork>
</configData>
[…]
</bulkCmConfigDataFile>

– example 4:

<?xml version="1.0" encoding="UTF-8"?>
<bulkCmConfigDataFile
xmlns=
"http://www.3gpp.org/ftp/specs/archive/32_series/32.615#configData"
xmlns:xn=
"http://www.3gpp.org/ftp/specs/archive/32_series/32.625#genericNrm"
[…]
>
[…]
<configData dnPrefix="DC=a1.companyNN.com">
<xn:SubNetwork id="1">
<xn:ManagedElement id="1" modifier="delete">
</xn:ManagedElement>
<xn:ManagedElement id="2" modifier="delete">
</xn:ManagedElement>
</xn:SubNetwork>
</configData>
[…]
</bulkCmConfigDataFile>

– example 5:

<?xml version="1.0" encoding="UTF-8"?>
<bulkCmConfigDataFile
xmlns=
"http://www.3gpp.org/ftp/specs/archive/32_series/32.615#configData"
xmlns:xn=
"http://www.3gpp.org/ftp/specs/archive/32_series/32.625#genericNrm"
xmlns:un=
"http://www.3gpp.org/ftp/specs/archive/32_series/32.645#utranNrm"
[…]
>
[…]
<configData dnPrefix="DC=a1.companyNN.com">
<xn:SubNetwork id="1" modifier="update">
<xn:attributes>
<xn:userLabel>Paris SN1</xn:userLabel>
</xn:attributes>
<xn:ManagementNode id="1" modifier="update">
<xn:attributes>
<xn:userLabel>Paris MN1</xn:userLabel>
</xn:attributes>
</xn:ManagementNode>
<xn:ManagedElement id="1" modifier="delete">
<un:RncFunction id="1" modifier="delete">
</un:RncFunction>
</xn:ManagedElement>
<xn:ManagedElement id="2" modifier="create">
<xn:attributes>
<xn:managedElementType>RNC</xn:managedElementType>
[…]
<xn:locationName>Concorde</xn:locationName>
</xn:attributes>
<un:RncFunction id="2" modifier="create">
<un:attributes>
<un:userLabel>Paris RF2</un:userLabel>
[…]
<un:rncId>2</un:rncId>
</un:attributes>
</un:RncFunction>
</xn:ManagedElement>
<xn:ManagedElement id="3">
<un:RncFunction id="3" modifier="update">
<un:attributes>
<un:userLabel>Paris RF3</un:userLabel>
</un:attributes>
</un:RncFunction>
</xn:ManagedElement>
</xn:SubNetwork>
</configData>
[…]
</bulkCmConfigDataFile>

4.5 XML elements VsDataContainer, vsData and vsDataFormatVersion

As all XML element types corresponding to NRM classes (see clause 4.3A.2), the VsDataContainer XML element type, explicitly declared in 3GPP TS 32.625 [11], corresponds to the VsDataContainer NRM class defined in 3GPP TS 32.622 [8].

Contained in an attributes XML element type, itself contained in a VsDataContainer XML element, as all XML element types corresponding to NRM attributes (see clause 4.3A.2), the vsData and vsDataFormatVersion XML element types, explicitly declared in 3GPP TS 32.625 [11], correspond to the vsData and vsDataFormatVersion NRM attributes defined in 3GPP TS 32.622 [8].

As an exception to the generic mapping rules for the definition of NRM-specific XML element types (see clause 4.3A.2), the vsData XML element type has an empty XML content.

Each vendor-specific XML schema shall declare one ore more vendor-specific XML element types that:

– have a name starting with vsData, e.g. vsDataRHO;

– derive by extension (see [3], [4] and [5]) the vsData XML element type declared by the XML schema genericNrm.xsd (see [11]);

– are designated as members of the substitution group (see [3], [4] and [5]) headed by the vsData XML element type.

Beyond the above statement, the definition of vendor-specific XML schemas is outside the scope of this document.

The XML content of those vendor-specific XML elements carry vendor-specific data.

The XML content of the vsDataFormatVersion XML element shall be the filename, without the ".xsd" file extension and without any path specification, of the vendor-specific XML schema used for the related VsDataContainer XML element.

See Annex C for an example of a vendor-specific XML schema.

The following is an example of a vendor-specific XML element (in bold) deriving and extending the vsData XML element in a configuration data XML file:

<?xml version="1.0" encoding="UTF-8"?>
<bulkCmConfigDataFile
xmlns=
"http://www.3gpp.org/ftp/specs/archive/32_series/32.615#configData"
xmlns:xn=
"http://www.3gpp.org/ftp/specs/archive/32_series/32.625#genericNrm"
xmlns:un=
"http://www.3gpp.org/ftp/specs/archive/32_series/32.645#utranNrm"
xmlns:vsRHO11="http://www.companyNN.com/xmlschemas/NNRncHandOver.1.1"
[…]
>
[…]
<configData dnPrefix="DC=a1.companyNN.com">
<xn:SubNetwork id="1">
<xn:ManagedElement id="1">
<un:RncFunction id="1">
<xn:VsDataContainer id="1">
<xn:attributes>
<xn:vsDataType>RncHandOver</xn:vsDataType>
<xn:vsDataFormatVersion>NNRncHandOver.1.1</xn:vsDataFormatVersion>
<vsRHO11:vsDataRHO>
<vsRHO11:abcMin>12</vsRHO11:abcMin>
<vsRHO11:abcMax>34</vsRHO11:abcMax>
</vsRHO11:vsDataRHO>
</xn:attributes>
</xn:VsDataContainer>
</un:RncFunction>
</xn:ManagedElement>
</xn:SubNetwork>
</configData>
[…]
</bulkCmConfigDataFile>