10.8 Prepayment function set
10.8.1 Overview
The Prepayment function set defines a mechanism for the conditional delivery of services based upon outstanding credit or debt. It provides an interface for appropriately privileged clients to view, update, or act upon account balance information. Accounting in prepayment systems may be measured on a monetary basis (e.g., dollars or euros remaining) or on a commodity basis (e.g., kilowatt-hours or British thermal units [BTUs] remaining). A service-providing device (typically a meter) can use the account balance information from a prepayment server in combination with consumption and price data to determine if service should continue. In some scenarios (“Local” mode), the service-providing device and the prepayment server are the same. Alternatively, the continuation of service may be directed by an external prepayment server, either in response to local calculation (“ESI” mode) or to an out-of-band signal from the service provider (“Central Wallet” mode). Client devices that provide a user interface to the service provider’s customers may use the prepayment function set to display information about remaining balances or to request additional credit (in some scenarios, through the transmission of payment tokens; however, note that IEEE Std 2030.5 only provides a wrapper for this token data, the mechanism by which tokens are produced and consumed is out of scope for this standard).
10.8.2 List ordering
Table 46 —Prepayment list ordering
Resource name | Primary key | Secondary key | Tertiary key |
Prepayment | mRID (descending) | N/A | N/A |
CreditRegister | effectiveTime (descending) | mRID (descending) | N/A |
SupplyInterruptionOverride | interval.start (ascending) | interval.duration (ascending) | N/A |
10.8.3 Application guidelines/behavior
10.8.3.1 General
Servers implementing the Prepayment function set SHALL be capable of internally storing and supporting at least one Prepayment instance. Prepayment servers SHALL support one and only one AccountBalance resource per Prepayment instance.
A server implementing the Prepayment function set SHALL support one and only one PrepayOperationStatus resource per Prepayment instance.
Servers implementing the Prepayment function set in Local or ESI mode SHALL be capable of internally storing and supporting at least one CreditRegister instance per Prepayment instance.
Prepayment clients MAY POST to the CreditRegisterList to transmit a new CreditRegister transaction.
A Prepayment client MAY PUT to PrepayOperationStatus to switch between using regular credit and emergency credit. Typically, this interface is used by service customers to tap a backup credit pool when normal credit is exhausted and cannot be immediately recharged. Prepayment server implementers MAY apply additional vendor-specific rules around when this mode of operation may be changed (e.g.,
emergency credit might only be allowed when availableCredit is less than or equal to the creditExpiryLevel).
10.8.3.2 Prepayment server/Usage Point server communication
In most Prepayment configurations, client behavior is minimally affected by server state. That is, the typical client is an in-premises display that displays the present account and status data, posts new credit transactions, requests the use of emergency credit, or displays historical transaction data. However, in the ESI prepayment mode (and in some configurations of the Central Wallet mode), external meters (or other service-providing devices), which may be Usage Point servers, are also prepayment clients. These clients are significantly affected by server state. These devices SHALL monitor the server’s Operation Status resource and should react appropriately to changes of the serviceStatus and serviceChange elements. This reaction includes connecting or disconnecting service.
10.8.3.3 Mirroring behavior
In most IEEE 2030.5 function sets, mirroring involves behavior similar to the following pattern:
a) Device B issues an OPTIONS method to determine if Server A supports a POST to a given resource list.
b) Device B posts its data to the resource list on Server A. Server A creates a mirrored resource for Device B.
c) Client C reads Device B data from the mirrored resource on Server A.
The Prepayment function set, in some deployments, requires additional mirroring behavior. With Prepayment, mirror instances MAY need to act as mailboxes for the mirrored server, such as in the following scenario:
Device B issues an OPTIONS method to determine if Server A supports a POST to a given resource list.
Device B posts its data to the resource list on Server A. Server A creates a mirrored resource for Device B.
Client C POSTS data to the mirrored resource on Server A.
Device B reads the mirrored resource on Server A to obtain Client C data.
One use case for this mode is when a sleepy meter is implementing a Prepayment server in local prepayment mode. This means that the meter will be expecting CreditRegister transactions to be posted by prepayment clients. However, sleepy devices are unable to receive transmissions while idle, and a sleepy server will typically be interacting with other HAN devices through a mirrored instance. In this scenario, prepayment clients SHALL post the CreditRegister transactions to the mirrored instance. The server hosting the mirrored instance SHOULD maintain the instances of CreditRegister transactions for at least 72 hours, so that the sleepy meter MAY download and act upon the credit transactions. Note that for all intents and purposes (including discovery) that to Prepayment clients on the HAN, the mirrored instance is the prepayment server; the other clients are likely unaware of the sleepy device.
10.8.4 LogEvents
Table 47 —Prepayment LogEvents
LogEvent name | LogEvent code | LogEvent description |
PPY_CREDIT_POST_SUCCESS | 0x00 | SHOULD be issued when a client successfully posts a CreditRegister to the CreditRegisterList |
PPY_CREDIT_POST_FAIL | 0x01 | SHOULD be issued when a client posts an invalid resource to the CreditRegisterList |