CED WEB EXTRA: SIP and PacketCable(3)

Wed, 01/31/2007 - 7:00pm
David Hancock, Project Director, Signaling Architecture; and Sandeep Sharma, Senior Architect, Signaling Protocols. (Hancock and Sharma are both in the Advanced Network Systems (ANS) department, which manages PacketCable at CableLabs)
Introduction This article is the second in a four part series that explains the PacketCable™ 2.0 network architecture. The first article describes the PacketCable 2.0 project design goals, strategic drivers, and architecture. This current article discusses the PacketCable specification's use of the Session Initiation Protocol (SIP) and how it integrates with the PacketCable Multimedia specification. Subsequent articles will discuss the provisioning, management, and security framework as well as the future of the PacketCable 2.0 project. The PacketCable 2.0 specification is based upon the Third Generation Partnership Project (3GPP) IP Multimedia Subsystem (IMS), which uses SIP for session control. SIP provides the foundation for a service delivery platform that is a key aspect of the IMS and the PacketCable 2.0 network. By using SIP in conjunction with PacketCable Multimedia, the PacketCable 2.0 network architecture allows cable operators to create a holistic service framework on top of their DOCSIS network deployments without precluding other access technologies. Session Initiation Protocol (SIP) SIP is used for creating and managing communication sessions in IP-based networks. The protocol is defined by the Internet Engineering Task Force (IETF), the standards body that has defined most of the foundational protocols for the Internet and World Wide Web. SIP follows the Internet paradigm that favors end-to-end communication and distributed functionality. One of the strong features of SIP is its extensibility - new messages and attributes can be easily defined. Also, SIP provides built-in mechanisms to support interoperability so that end points with disparate capabilities can still communicate with each other. SIP and its extensions provide the following capabilities: Multimedia session establishment - Enables a user to establish a multimedia communications session with another user on the network. The term "multimedia" refers to the multiple types of media that can be carried in a session, such as audio, video, text, etc. Two endpoints can establish or modify a session by exchanging information that describes the attributes of the session, such as what type of media coding to use and where to send the media. User mobility and registration - Allows a user to be contacted using a single identifier, even as the user changes network attachment points (user mobility). Also, a user can have multiple simultaneous network attachment points (e.g., WiFi and Ethernet). User mobility and the ability to support multiple attachment points are enabled by the SIP registration procedure. When a user first appears on the network as a result of logging in or powering up a device, the registration procedure binds the user identity to the user's current physical attachment address on the network. This binding is maintained as long as the user remains at that physical address. Event notification - Provides a framework that allows an entity to subscribe to an event of interest and be notified when that event takes place. In other words, SIP can obtain the status of a given resource and track changes in that status. For example, an application could subscribe to the presence state of a user (see below) to determine when the user is available to accept new calls. Presence - Enables more effective communication by allowing users to advertise their availability and willingness to communicate. Presence can be thought of as dynamic information about a particular user that is made available to applications or other users. A widely used application that leverages presence is Instant Messenger (IM), whose "buddy list" allows a user to see who is available for messaging. Decentralized Application Control One of the chief characteristics that distinguishes the PacketCable 2.0 network architecture from the PacketCable 1.0 and 1.5 (herein referred to as 1.x) network architectures is the nature of application control. As shown in Figure 1, a PacketCable 1.x network is built around a centralized architecture in which the application logic plus the non-application-specific support functions, such as user authentication, service authorization and message routing, are all controlled by the Call Management Server (CMS). This application-centric approach works well for residential telephony, a well-defined service with simple end-point devices. A PacketCable 2.0 network, on the other hand, is required to support multiple applications and to provide a platform on which new, yet-to-be-defined applications can be introduced easily. To meet this requirement, PacketCable 2.0's network architecture decouples application control from the application-independent support functions. As shown in Figure 1, the PacketCable 2.0 base network architecture provides all the support functions, such as authentication, authorization, and routing. The application logic resides in Application Servers and clients that plug into standard interfaces to utilize the support services of the base architecture. PacketCable 2.0's decoupling of application logic from the support functions promises to deliver many benefits for cable operators, such as: Re-use of core network components across multiple applications Favorable scaling and reliability models Reduced time-to-market for new services For consumers, the primary benefit will be a variety of new services that enhance their overall cable experience. SIP and the PacketCable 2.0 network As described earlier, SIP is a protocol that allows the establishment of multimedia sessions. However, it must work in conjunction with a network architecture to provide the wide variety of features and services envisioned by the cable industry. Figure 2 shows the PacketCable 2.0 network architecture components and interfaces. The components are grouped into multiple logical functions. The Local Network provides the IP attachment point for the client device. The Local and Access networks together provide an IP pipe to carry SIP messages between the client and the Proxy Call Session Control Function (P-CSCF). The P-CSCF acts as the client's SIP entry point into the PacketCable 2.0 network, exchanging all SIP messages between the client and the core. The core provides the non-application-specific support functions mentioned earlier, such as authentication, authorization, routing, and basic session establishment. The core also invokes Application Servers (AS), when they are needed, to provide additional features and services to the user. Application control resides in the Application Servers and clients. The Interconnect provides access to other networks such as the Public Switched Telephone Network (PSTN). Calls destined for the PSTN are routed to the Breakout Gateway Control Function (BGCF), which in turn selects the hop-off point through the PSTN Gateway (PSTN GW) to the PSTN. The PSTN GW reuses the PacketCable 1.x Media Gateway Controller (MGC), Media Gateway (MG), and Signaling Gateway (SG) components in order to leverage the infrastructure and capital investment of already-deployed PacketCable 1.x PSTN interconnect facilities. The Interconnect function also supports an interface to the PacketCable 1.x Call Management Server (CMS) in order to enable calls between PacketCable 2.0 and 1.x endpoints. When a user comes online, the client establishes a secure signaling channel with the P-CSCF, and communicates the user's identity, credentials, and location on the network to the core. The core assigns a Serving-CSCF (S-CSCF) to the user, and the selected S-CSCF then authenticates the user through the supplied credentials. Once the user is authenticated, the S-CSCF registers the user's location in order to route subsequent SIP messages to the user. Once registered, the user can invoke features and services supported by the network. For example, the user may initiate an audio-video call to another registered user by sending a SIP INVITE request that describes the audio and video session parameters. As these SIP messages travel from one user to another, they pass through the S-CSCF assigned to each user. The S-CSCF plays two major roles during this message exchange. First, it verifies that the target user is authorized to use the requested service, based on the user's service profile information that is provisioned by the cable operator in the Home Subscriber Server (HSS). Second, the S-CSCF invokes any Application Servers required to provide the service based on rules defined by the cable operator. Depending on the application, the AS may forward the SIP message to another party, may initiate additional new sessions, or may terminate the session. For example, a call-forwarding AS would redirect a session to the forward-to party. Once all Application Servers identified by the S-CSCF's service control platform have been invoked, the S-CSCF routes the SIP message on toward the destination user. For example, calls destined for the PSTN are sent to the BGCF, while calls destined to a PacketCable 2.0 user are routed to the Interrogating-CSCF (I-CSCF) or the P-CSCF. PacketCable Multimedia The PacketCable 2.0 network architecture interfaces with the PacketCable Multimedia network architecture to ensure that the DOCSIS network establishes the proper service flows to meet the bandwidth and latency needs of the multimedia session. Figure 2 shows the PacketCable Multimedia components within the PacketCable 2.0 network architecture. When the P-CSCF receives a SIP message containing session information, it passes the session attributes to the PacketCable Application Manager (PAM). The PAM derives the bandwidth resource requirements for the session based on the session attributes and interacts with the Policy Server to allocate the appropriate resources within the Cable Modem Termination System (CMTS). PacketCable 2.0 specification enhancements to IMS One of the advantages of using IMS as the base for a PacketCable 2.0 network is that it provides an application and access independent architecture that supports many of the cable industry requirements. However, IMS was originally conceived to meet the needs of the mobile/wireless industry, and thus does not support all of the business and operational needs of cable operators. For example, cable operators need support for clients that do not contain an IMS Subscriber Identity Module (ISIM). A Subscriber Identity Module is a small removable chip found in GSM mobile phones that contains subscriber data and authentication information. Since IMS support is currently limited to clients with ISIMs, the PacketCable 2.0 specification defines extensions to allow for other types of clients, such as those more typically found connected to cable systems. The PacketCable 2.0 specification also defines procedures to provide service in a typical home environment where clients are behind off-the-shelf NAT and firewall devices. Additional detail regarding PacketCable 2.0 extensions can be found in the PacketCable 2.0 Architecture Framework Technical Report. CableLabs® is in the process of introducing the PacketCable 2.0 IMS enhancements back into 3GPP, with the goal that IMS will evolve to support all cable requirements. Conclusion A key innovation of the PacketCable 2.0 SIP signaling network architecture is the separation of application control from the application-independent support functions. This is realized by defining an application-agnostic base architecture that supports functions such as user authentication, service authorization, and message routing that are common to all applications. Application logic lives outside of the base architecture in Application Servers that utilize the services of the base architecture over a standardized SIP interface. This architecture is a great benefit to cable operators since it minimizes the cost, complexity, and time-to-market associated with deploying new features and services to their customers.

Share This Story

You may login with either your assigned username or your e-mail address.
The password field is case sensitive.