rk resources and capa- bilities [21], at the cost of increasing their implementation complexity. The SDP framework may use Parlay X Web service APIs, rather than SCF and SCS APIs, to offer access to service functions. As a result, we may collapse lower-layer GSOAs (intermediate and complex) into a single higher-layer GSOA (simple). Alternatively, we may completely remove Parlay X Web services and use Parlay SCFs to expose network abstractions to external enterprises via their APIs. Hence, we may extend a lower-layer GSOA (intermediate) to replace higher-layer GSOAs (simple). Similar to manipulating GSOA layers, we may alter SDP framework domains. For instance, the service subscriber domain may be removed if end-users are within his/her home IMS network. So, the P-CSCF and resources are removed and not accessed from the customer domain. Also, a telco may assume the access provider role for end-users, provide OSS/BSS capabilities to charge end-users and provide converged network functions and resources. As a result, the connectivity provider, OSS/BSS, and converged network domains may merge into a single telco domain. Therefore, mapping standardized technologies to the SDP framework may require manipulation of layered GSOAs and distributed domains. As a result, specific SDP architectures are created. Though incorporating technologies, these derived architectures inherit the generic concepts, principles, structure, and abstrac- tions of the SDP framework. Service Delivery Platforms 2.6.3 Simulating an Application To determine the appropriateness of the implemented SDP framework, we create, deploy, and simulate the execution of an application. The chosen application is Internet Protocol Television (IPTV). With this application, end-users are able to view real-time and on-demand television content. In addition, end-users may use other telco services while viewing their content. These services include voice calling and messaging with presence. The proposed SDP architecture that is derived from the SDP framework to impl