ure is a simplification of common functions offered by various products. The SDP architecture in [2] is found to be incomplete when mapped onto the NGN reference model and reference points. No appropriate customer platform is defined to satisfy the NGN service stratum requirements and implement the RCS reference point. Therefore, communication between the device, SDP, and con- verged networks is not managed. Also, platforms require further decomposition to uncover their architectural structure. The SDP architecture in Figure 2.2 maps standards-based APIs onto the archi- tecture in [2]. However, different APIs are used to implement a single platform. In addition, proprietary Web-based APIs are used to expose OSS/BSS and data store functionality to platforms. Thus, when implementing the general SDP archi- tecture, multiple API standards and resulting technologies span multiple platforms, service enablers, and their interfaces. As a result, SDP implementations become inconsistent and provide limited interworking with each other and various net- works. This limits the implementation of the NGN reference model, especially the Rss and RST reference points. The SDP architecture in Figure 2.2 also incorporates the SDP within a distrib- uted environment that is supported by a distribution plane. This plane supports communication between diverse implementations of platforms, service enablers, and interfaces. However, [2] does not provide detail on the distribution of the SDP, the distribution plane, and the technologies required. This further reduces the flex- ibility of the current SDP architecture. To overcome these limitations, we structure a SDP framework that allows standard-based SDP architectures to be structured and consistently implement NGN reference points. We define this "meta-architecture" by using a generic archi- tectural concept, that is, the GSOA. 2.4 Generic Service-Oriented Architecture The GSOA represents a collection of technology, implementation, and distribu- tion neutral concepts that are at a great