First of all, we need to be very aware the scope of RUS advanced feature. Possible scopes inculde:
1. As core features, the advanced ones of RUS should concentrate on the service interface definitions (therefore, the data replication and 
hierarichial deployment is out of scope).
1.1 Aggregation/Summarisation service interface only.
2. Advanced feature could possibly cover possible features relating to deployment environment.
2.1 Data replication among multiple usage data storage but only for certain deployment scenarios. For example, UNICORE RUS service does not provide 
persistent usage storage but contacting to LoadLever APIs to get realtime resource usage information of running or queuing jobs. Even for persistent 
usage stroages like SGAS and DGAS, there are many possible replication usages. Things can be more complex with introduction to aggregation or 
summarisation. For example, a site with RUS deployment might maintain job and summary usage repositories at same time. When a new job usage record 
inserted, the corresponding usage information can be replicated into summary usage record by adding usage infoset into a particular summary usage 
record.
2.2 Hierachical deployment mainly targeted at interoperability. There are several possible recommendations as well. 
2.2.1. As with DGAS deployment scenario, the DGAS RUS might maintain job and summary usage storage at same time (same as HLR server deployed). Then a 
top-level RUS service can directly contact one or more DGAS RUS instances on receiving quests. 
2.2.2. Alternatively, A singleton RUS instance can be deployed at VO level with multiple usage data storages maintain at sites without RUS deployed. 
Then in this circumstance, the RUS requires recommendation on distributed usage storage management. 
2.2.3. To be generic enough, the RUS is recommended to be able to contact multiple distribute usage providers (usage meters, RUS instances, usage data
 storage)
[NOTE: RUS hierarchical deployment is main concerned about interoperability. The initial interoperability test plan in OMII-EU is intended to be 
target at SGAS and DGAS, each of with have independent RUS client development. The interoperability tests wether one client can talk to the RUS 
instance of the other. Besides, SGAS is based on WS-RF without full compatibility to WS-I servce interface definitions. How about DGAS RUS?]
I recommended as an initial step we'd better concentrate on one point at one step. The most reasonable starting point could be aggregation/
summarisation with collaboration to OGF-UR working group efforts, summary usage record schema in particular.