UsageMeteringDataInfo {joint-iso-itu-t ms(9) function(2) part10(10)
  asn1Modules(2) 2} DEFINITIONS IMPLICIT TAGS ::=
BEGIN

EXPORTS UsageInfo;

IMPORTS
  DMI-TYPE-IDENTIFIER
    FROM Attribute-ASN1Module {joint-iso-itu-t ms(9) smi(3) part2(2)
      asn1Module(2) 1};

UMF-USAGE ::= DMI-TYPE-IDENTIFIER

UsageInfo ::= SEQUENCE {
  serviceType  UMF-USAGE.&id({UsageInfoSet}),
  usageData    UMF-USAGE.&Value({UsageInfoSet}{@serviceType})
}

UsageInfoSet UMF-USAGE ::=
  {...}

-- the following ASN.1 provides the means to include the service-specific information in the usage
-- metering data. The data type XxxUsageData, detailed below, is a prototype of how a
-- specialization shall specify a data type to replace the ANY in the usageData field of the UsageInfo
-- in a way that allows the specifier to include the necessary syntax to fully specify each block. In
-- addition the specialization shall allocate an OBJECT IDENTIFIER value to register the variant of
-- usageData specified by the specialization. A concrete example of a specification, using PSTN as
-- illustration is given in G.1.
--
-- Detail for the contents of each block are given as follows:
-- XxxUsageData ::=	SEQUENCE OF CHOICE {
--	registration			XxxRegistrationType,
-- The registration block is used to identify the requester using the service. An
-- XxxRegistrationType shall be specified by all specializations. The registration component shall
-- appear once and only once in every value of the UsageInfo data type, and shall always
-- appear as the first element in the XxxUsageData.
--
-- The definition of the service-specific syntax to be included in this block, shall include the
-- following information:
--	identification of the requester (directory number, user address, etc.)
--	request				XxxRequestType,
-- The request block identifies the service request made by the requester. The XxxRequestType
-- may be omitted from specializations not requiring it. If an XxxRequestType is specified in a
-- specialization, zero or more request components may appear in a value of the XxxUsageData.
--
-- The definition of the service-specific syntax to be included in this block, shall include the
-- following information:
--	service request information which identifies the type of service requested and also any
--	additional service parameters, note that this information can be very detailed and complex
--	depending on the service type and the types of request that the service supports (e.g.
--	destination addresses, electronic mail message information, directory numbers, feature
--	codes).
-- and the following information may be provided:
--	a usage measurement (time, volume);
--	a time stamp (date and time).
--	accept				XxxAcceptType,
-- The accept block identifies the details of what service was provided and the associated usage.
-- The XxxAcceptType may be omitted from specializations not requiring it. If an XxxAcceptType
-- is specified in a specialization, zero or more accept components may appear in a value of the
-- XxxUsageData.
--
-- The definition of the service-specific syntax to be included in this block, shall include the
-- following information:
--	service information which identifies the type of service provided and also any additional service 
--	parameters;
--	a usage measurement;
--	a time stamp.
--	complete			XxxCompleteType,
-- The complete block identifies the details of the end of some instance of utilization. The
-- XxxCompleteType may be omitted from specializations not requiring it. If an XxxCompleteType
-- is specified in a specialization, zero or more complete components may appear in a value
-- of the XxxUsageData.
--
-- The definition of the service-specific syntax to be included in this block, shall include the
-- following information:
--	a usage measurement;
-- and the following information may be provided:
--	service information which identifies any further details about the provided service
--	(reason for call completion);
--	a time stamp.
--	interrupt				XxxInterruptType,
-- The interrupt block indicates any abnormal occurrence during the transaction
-- for which different charging algorithms may need to be applied by the recipient of the usage
-- metering record. The XxxInterruptType may be omitted from specializations not requiring it.
-- If an XxxInterruptType is specified in a specialization, zero or more interrupt components
-- may appear in a value of the XxxUsageData.
--
-- The definition of the service-specific syntax to be included in this block, shall include the
-- following information:
--	duration of the interruption,
--	reason for the interruption;
-- and the following information may be provided:
--	a usage measurement
--	a time stamp.
--	bulk				XxxBulkType,
-- The bulk block indicates any bulk usage measurements made. The
-- XxxBulkType may be omitted from specializations not requiring it. If an XxxBulkType
-- is specified in a specialization, zero or more bulk components may appear in a
--value of the XxxUsageData.
--
-- The definition of the service-specific syntax to be included in this block, shall include the
-- following information:
--	a usage measurement
-- and the following information may be provided:
--	reason for reporting
--	corresponding		XxxCorrespondingType }
-- The corresponding block includes any specific information to allow many
-- usage metering records to be correlated. The  XxxCorrespondingType may be omitted
-- from specializations not requiring it. If an XxxCorrespondingType is specified in a
-- specialization, at most one corresponding components may appear in a value of the
-- XxxUsageData.
--
-- The definition of the service-specific syntax to be included in this block, shall include the
-- following information:
--	an identifying key which relates many usage metering records to one service transaction record.
-- The above  data type gives the usage metering record structure, where, for a given requester,
-- there are associated a set of the events required to describe the transaction, i.e. the
-- SEQUENCE OF CHOICE construct allows an ordered list of the different event types. The
-- registration and corresponding event types will only appear in the sequence once. The
-- registration block shall always be present. This constraint ensures that a usage metering record
-- only applies to the one requester and that there is only one set of correlation information.
END