Expire tariff - Pyosch/powertac-server GitHub Wiki

up
When a Broker offers a Tariff (by sending a TariffSpecification), it may specify an expiration date. This is the date beyond which no further subscriptions are allowed. Customers are not automatically unsubscribed, however. They may retain their subscriptions as long as they like, unless the Broker wishes to completely withdraw (or "revoke") the Tariff.

A Broker may change the expiration date on an existing Tariff by sending a TariffExpire message. It may revoke a Tariff by sending a TariffRevoke message.

The expiration date on a Tariff may be changed to any date that is not in the past. This has the effect of preventing further subscriptions on or beyond that date, except that it will not prevent new subscriptions during the timeslot when the message arrives at the server.

The new expiration date may be sooner or later than the current expiration date for the Tariff. It may even be used to re-activate an existing, expired Tariff.

When the TariffExpire message arrives at the server, it is routed to the Tariff Market Service, which

• looks up the Tariff specified in the command
• validates the command by ensuring that the Tariff exists and belongs to the Broker who sent the message, and
• passes it to the Tariff's expire() method.

Once a Tariff's expiration date has arrived, it will fail to process further subscription attempts by returning a null from the subscribe() method.

When a customer model is activated in each timeslot, it must handle revoked tariffs before using or producing power. However, the actual subscription changes are not processed immediately; they are processed by the TariffMarket when it is activated. This means that the customer does not see any change in the current timeslot, except that it will be prevented from adding subscriptions to the revoked tariff. The rules for superseding tariffs are:

• If the revoked Tariff has already been superseded by some other Tariff (from the same Broker), then the customer's subscription is switched to the superseding Tariff, with a contract-expiration date on the current day (so the customer may drop the subscription without penalty).
• If the revoked Tariff has not been superseded, then the customer's subscription is switched to the original default Tariff from the default Broker.

The sequence of steps involved in revoking a tariff is shown below, starting when the customer is activated during Phase 2 of the server's processing cycle. Before the customer runs its model to consume and produce power, and before it takes any action to update its subscriptions, it must find out whether any of its subscribed tariffs have been revoked by calling getRevokedSubscriptionList on the Tariff Subscription Repo. This will first ask the Tariff Market Service to process its list of pending revocations and then return a list of its subscriptions to revoked tariffs. The customer must then call handleRevokedTariff() on each revoked subscription. The updated set of subscriptions can be retrieved from the tariffSubscriptionRepository, but the updates will not appear until the following timeslot.

When the Tariff Market Service is activated (in phase 3), it will process the pending tariff revocations, issue the appropriate transactions to charge brokers the revocation fees, and remove the tariff and all its subscriptions from the tariff repo and the tariff subscription repo respectively.