ndwidth against standards dictated by the BTO. - Bandwidth Pooling Architecture. Initially most players in this market pursue PPD strategies. PPDs generate revenue through transaction fees, port connections and non-recurring charges, e.g. set-up charges. Buyers and sellers base contracts on the cities which the network segment supplying the bandwidth connects, and on terms such as capacity commitment, term, quality of service parameters and price. IICs that have bandwidth units available to sell will interconnect their bandwidth units with a PPD's pooling points. Buyers, or parties who desire to purchase bandwidth units, will connect their network facilities to the PPDs'. Once a buyer has completed trading and negotiated a contract for bandwidth unit, the pooling point will cross-connect the seller's bandwidth unit with the buyer's network connection contained within the buyer's facilities. The buyer will then have an end-to-end connection that consists of the traded bandwidth unit the seller supplies, and two facilities that connect the buyer's premises with each PP to which the bandwidth units connect or "terminate." For the Pooling Point Developer, the OSS requirements include: - A robust Web portal - Gateways to sellers - A billing system that is subscription-oriented - Provisioning and inventory management applications - Network activation (switches) - Network management systems that can provide performance monitoring and QoS management functions Sample Architecture In our example, the PPD deploys the OSS in three phases, relying on manual processes or outsourcers for interim capabilities during the deployment period. The application architecture example provided here includes: The Ultimate Guide to Building and Delivering OSS/BSS - A custom Web portal - MetaSolv for order management, inventory and trouble management - Portal for billing - Concord for QoS/SLA management - Micromuse for network management - Lucent for switch activation - Oracle for financial applications Integration in this example is point-t