10.11 Metering Mirror function set
10.11.1 Overview
The Metering Mirror function set provides a mechanism for constrained devices to post metering data to a Metering server in a very efficient manner. Great effort has gone into minimizing the number of transactions needed to create and maintain the mirroring relationship. Therefore, mechanisms and structures of this function set differ from other function sets to attain this efficiency.
10.11.2 List ordering
Table 56 —Metering Mirror list ordering
Resource name | Primary key | Secondary key | Tertiary key |
MirrorUsagePoint | mRID (descending) | N/A | N/A |
10.11.3 Application guidelines/behavior
A Metering Mirror function set server SHALL NOT advertise support for mirroring unless it has the resources available to host at least one additional mirror. The server must have room for at least one instance of each of the resources possible under a Usage Point.
The following rules apply to creating and maintaining Metering Mirrors.
a) To create a new Metering Mirror the client SHALL POST to the server’s MirrorUsagePointList (e.g., /mup) for the mirrored usage point.
1) This POST SHALL contain at least the information through the definition of MirrorMeterReadings and ReadingType including the MirrorUsagePoint mRID and MirrorMeterReading mRIDs.
2) The POST MAY also contain MirrorReadingSets and Readings.
3) If the mRID of the MirrorUsagePoint is unique (does not match a MirrorUsagePoint.mRID of an existing MirrorUsagePoint) the response SHALL be response code 201 (Created), the MirrorUsagePoint URI SHALL be included in the Location header.
4) If the mRID of the MirrorUsagePoint matches an existing MirrorUsagePoint, the new data SHALL be written over the existing MirrorUsagePoint (and associated UsagePoint) and the response code SHALL be 204 (No Content), the MirrorUsagePoint URI SHALL be included in the Location header. If the MirrorUsagePoint contains MirrorMeterReadings, then the guidance of Rule h) and Rule i) are to be applied.
b) When the Metering Mirror function set server receives a POST it SHALL copy the received data, including mRIDs, into the normal metering structure to its Metering UsagePoint structure (e.g.,
/upt), and it SHALL allocate enough resources to manage the mirror and its data.
c) A GET of the resource (MirrorUsagePoint) identified in the response to the initial POST SHALL return a resource with only the first level elements (i.e., sub-elements and collections are not included).
d) To POST new data to an existing MirrorUsagePoint, the Metering client SHALL POST a MirrorMeterReading or MirrorMeterReadingList containing MirrorReadingSets and/or Readings to the resource identified in the Metering server’s response to the POST that created the resource (e.g.,
/mup/3).
e) The Metering Mirror server SHOULD only accept POSTs to a given MirrorUsagePoint from the client that created the mirror.
f) If a POST to the MirrorUsagePoint is of a MirrorMeterReading, then a successful response SHALL contain a Location header indicating the URI of the MeterReading resource under the associated UsagePoint (e.g., /upt/2/mr/3).
g) If a POST to the MirrorUsagePoint is of a MirrorMeterReadingList, then a successful response SHALL contain a Location header indicating the URI of the MeterReadingList under the associated UsagePoint (e.g., /upt/2/mr).
h) In a POST to the MirrorUsagePoint, the mRID attribute of the MirrorMeterReading(s) SHALL be used by the Metering Mirror server to associate the data in a POST with the MeterReading in the associated UsagePoint.
1) In a POST to the MirrorUsagePoint, if the mRID attribute matches a previous MirrorMeterReading, then each of the contained MirrorReadingSets SHALL be handled as required by Rule i) below. The contents of the MirrorMeterReading SHALL overwrite the data in the associated MeterReading.
2) In a POST to the MirrorUsagePoint, if the mRID does not match a previous MirrorMeterReading and it contains a ReadingType, then a new MeterReading SHALL be created under the associated UsagePoint with the new data.
3) In a POST to the MirrorUsagePoint, if the mRID does not match a previous MirrorMeterReading and there is not a ReadingType, then the request SHALL be rejected with a response code 400 (Bad Request).
i) In a POST to the MirrorUsagePoint, where the request is not rejected, the new data SHALL be applied to the related UsagePoint resource structure according to the following:
1) If a MirrorReadingSet is received with a duplicate mRID of an existing ReadingSet, and it is targeted within the same resource hierarchy, then the new data SHALL replace the existing data of the identified ReadingSet.
2) If a MirrorReadingSet is received with a unique mRID, then the new data SHALL be added to the identified ReadingSetList.
j) If a client POSTs more data than the Metering Mirror server is willing to accept, the server SHALL respond with a response code of 413 (Request Entity Too Large).
k) The Metering Mirror server MAY decide when to remove data from the related UsagePoint resource structure.
l) When a MirrorUsagePoint is deleted, the associated UsagePoint SHALL also be deleted.
A Metering Mirror function set server MAY implement a timeout mechanism on a mirror. If a Metering Mirror function set server does not receive any POSTs from a Metering Mirror function set client for more than a specified time, the server MAY remove the MirrorUsagePoint resource and its related UsagePoint resource. The recommended timeout is 72 hours.
10.11.4 LogEvents
Table 57 —Metering mirror LogEvents
LogEvent name | LogEvent code | LogEvent description |
MUP_MIRROR_EXPIRED | 0x00 | SHOULD be generated by a server when a Metering Mirror expires |