The long netaccess session span over boundary of rate effectivity: the price changes, the peak switches to off peak. To do the billing correctly we need to split the usage to be billed differently for each effective period. Withe traditionaly NASes it means we need to granulate the updates of accounting or CCR-U interrogations, sometimes it even requires disconnecting the sessions. But in either case this situation is suboptimal since it dramatically intensify the load of the system (either continuously when higher granularity is required or at the peak period changes - which is even worse).

The Gy/DCCA (RFC4006) defines a support for Tariff-Time-Change, allowing the reporting entity to split the usage between periods without necessity to perform separate interrogation. A similar support is also described in some radius standards. In this project we are targeting two goals:

  1. enhance rating Api and BE to recognize change of rating coming soon and associate it with the authorized quota  
  2. report the change in Gy communication to verify it working in real LTE environment (interop)

Rating API logic and limitations

The PortaBilling is realtime billing system and the rate can be changed with immediate effect - this means that it only makes sense for billing to look ahead for some short foreseeable interval where any unexpected change shouldn't happen. For netaccess sessions it is usually aligned with maximum session allocation time (MaxSessionTimeout) - the same timeout when billing requires the next update to session to happen in order to not to loose control. In general the shorter this parameter becomes, the more granular and detailed billing we obtain.

It is important to understand that rating only looks up changes within this limited interval, any changes coming later are not considered or are ignored when providing authorizations. 

Gy specific considerations

 

The specific limitation of the basic Gy tariff-time-change is that the nas actually doesn't report back the time when the change occured, it only marks the usage before and after the split. BE is using the trick assigning the billing time with last remembered usage for usage before the change and using the current even time to bill the usage after the change. 

References

  1. RFC4006

Definitions, acronyms and abbreviation 

 

 

Ticket NumberTT#272960
Target BuildMR54
AreaPortaBilling

 

 

 Business Requirements

Implementation

Testing