work, such as Internet, where it is difficult to
locate when a flow is finished, the metering pol-
icy can also be used to define the flow duration.The collecting layeraccesses data provided by
metering entities as well as collecting charging
related events and forwarding them for further
processing to the accounting layer. This layer
can collect information from multiple meters, as
for multicast, and distribute to home domains, as
for user roaming. For this reason, the efforts in
standardising data exchange format and protocol
at this layer will be beneficial. The meters from
where to collect the data, the type of data and
the frequency in collecting them are defined in
the accounting policy.The accounting layerconsolidates the collected
information from the collecting layer either
within the same provider domain or from other
provider domains and creates accounting datasetsor recordswhich are passed further to the
charging layer. For supporting multicast charg-
ing, the multicast topology including splitting
points can be reconstructed by entities of this
layer.The charging layerderives charges from the
accounting records based on service specific
charging and pricing schemes, which are speci-
fied by the charging policy. This layer basically
translates technical values (i.e. measured re-
source reservation and consumption) into mone-
tary units using a charging formula. As a result
of this process, a charging record is created.The billing layercollects the charging informa-
tion (given in charging record) for a customer
over a time period, e.g. one month, and includes
subscription charges and possible discounts into
a bill. Billing policy can be used to specify the
bill details.Naturally, when building a particular charging
and accounting system, not all components have
to be included. For example, a service provider
who provides only one service and charges the
customers on the flat-rate basis can implement
only the functionality of the billing layer. On the
other hand, a service provider offering multiple
services may implement the policy-based archi-
tecture to allow different charging schemes to be
used for different services or customers without
having to hard-code the charging formula into
the billing system.The accounting architecture is based on the
charging and accounting reference model. It
consists of different processes that take over the
functions for the different layers of the reference
model. The processes are controlled by policies
which provide configuration information in
accordance with the needed accounting task. The
policies describe the flows or traffic aggregates
that should be measured, the attributes that have
to be stored, the collection intervals, data aggre-
gation instructions, etc. With this flexibility with
regard to charging schemes, used QoS provi-
sioning technique, traffic mix and user profiles
can be achieved. With the usage of standardized
policies it is also possible to instruct different
types of the accounting components (e.g. differ-
ent meter processes) in a consistent manner.
With this, different infrastructures that might be
used in different administrative domains can be
supported.Two different architectural approaches built on
this model have implemented the QUASI-model,
one centralised approach (developed by
Deutsche Telekom T-Nova in collaboration with
GMD Fokus) and the other distributed approach
(developed by BT Labs in collaboration withNotation used for charging schemes
Charging scheme parameters:
Access_charge: Part of the total charge for network services that can contain
a one-time site connection fee and monthly rental.
Usage_charge: Part of the total charge for network services that is associated
with resource reservation and consumption.
xi: In the case of transport services, includes the Network Perfor-
mance Level (NPL) and traffic profile contained in the Quality
Class Specification (QCS) for service i. In the case of end
services, includes the service (application) and quality class.
pT(xi): Charge per unit of time (e.g. per minutes).
pV(xi): Charge per unit of volume (e.g. per Mbyte).
pc(xi): Per connection charge (applies only to connection oriented
services).
Ti: Duration of service or connection i.
Vi: Transferred volume during service or connection i.
Compensation scheme parameters:
pT,reduced: Reduced per unit of time charge, when corresponding NPL is
violated.
pV,reduced: Reduced per unit of volume charge, when corresponding NPL
is violated.
Vnci: Volume of non-conforming traffic for service i.
Tvgi: Duration of period in which NPL is violated for service i.
Vvgi: Volume transferred during period in which NPL is violated for
service i. This variable can either be measured directly by the
QoS monitoring system, or estimated from other measure-
ments.
Vvg: Volume (of all flows corresponding to a given NPL) transferred
during period in which NPL is violated.