Introduction to the IMS Network

Rogier Noldus , ... Mats Stille , in IMS Application Developer's Handbook, 2011

8.8.4 SIP-AS as proxy, B2BUA, UAC, or UAS

We have shown in previous sections how a SIP-AS may be linked into the SIP signaling chain by an S-CSCF. The SIP-AS may then remain in the SIP chain, as regular SIP proxy. The SIP-AS may, however, assume different roles. Different roles for the SIP-AS give the SIP-AS different capability, but also have an effect on the core network, on the way in which the S-CSCF will continue the SIP session establishment. The four roles that a SIP-AS may take are: proxy, back-to-back user agent (B2BUA), user agent client (UAC), and user agent server (UAS). We will describe each of these briefly. It will become clear that the ISC reference point has some distinctively different characteristics than the Mw reference point (between CSCFs)!

8.8.4.1 Proxy

The SIP-AS forwards the INVITE request message (or other request message) back to the S-CSCF. The dialog that is established from the S-CSCF to the SIP-AS is the same as the dialog that is established from the SIP-AS to the S-CSCF (see Figure 8.42).

Figure 8.42. SIP-AS acting as SIP proxy.

There may be multiple SIP dialogs established through the SIP-AS. This may result from SIP forking by the S-CSCF, for example. These multiple dialogs traverse the SIP-AS transparently.

The capability for the SIP-AS, when acting as a SIP proxy, is limited. It may modify the R-URI and it may modify non-system SIP headers. When the establishment of the SIP session results in an unsuccessful final response, it may retarget ("forwarding proxy"), by sending a new INVITE request to a different destination than the previous one (unsuccessful INVITE).

When the SIP-AS applies retargeting the following will be considered:

•

When retargeting is applied during termination of call handling and SIP-AS has not yet responded to S-CSCF, the S-CSCF will stop terminating call handling when it receives the retargeted INVITE request. The S-CSCF will create a diverted (retargeted) call, directed to the modified R-URI.

•

When retargeting is applied for an originating call by the SIP-AS in response to receiving an unsuccessful final response, the S-CSCF will not evaluate the remaining IFC again. This is because the remaining IFC was already evaluated when the S-CSCF had received the first INVITE back from SIP-AS.

A SIP-AS acting as SIP proxy can be further subdivided into the following categories:

1.

Non-record routing proxy. The SIP-AS will be part of the INVITE transaction. Subsequent SIP signaling will not pass the SIP-AS. This method may be applied when the SIP-AS needs the capability to influence session establishment, e.g. number translation, but has no interest in further controlling the call.

2.

Record routing proxy. The SIP-AS will be in the entire SIP session signaling flow. This gives the SIP-AS the ability to modify SIP headers, as deemed necessary, for the entire call. One example is as follows. If the SIP-AS wants to modify the URI contained in the From header or in the To header, that modification should be done consistently throughout the call, i.e. in all SIP messages. The reason for this is that SIP entities that were designed in accordance with RFC 2543 may use the From URI or To URI for dialog recognition. Hence, modifying the From URI in the INVITE request message only may lead to a dialog problem for a later SIP message.

8.8.4.2 Back-to-back user agent

By acting as a Back-to-Back User Agent (B2BUA), the SIP-AS gains more control over the call (see Figure 8.43). The INVITE request message arriving at the SIP-AS is terminated in a user agent server (UAS) process. For the INVITE that the SIP-AS sends back to the S-CSCF, the SIP-AS starts a UAC process. An application in the SIP-AS correlates these two processes and conveys SIP messages between the UAC process and the UAS process. There are now separate SIP dialogs upstream of the SIP-AS and downstream of the SIP-AS. Acting as B2BUA is more complex for the SIP-AS (and, hence, more costly to implement and test). This is because the SIP-AS has to map various system headers (e.g. Call-ID, Contact, Record-Route) and has to map the dialog tags (From tag, To tag). However, acting as a B2BUA gives the SIP-AS more capability. Specifically, the SIP-AS has independent control over the call legs. This gives the SIP-AS the following capabilities (not exhaustive):

Figure 8.43. SIP-AS acting as back-to-back user agent.
•

AS-controlling parallel alerting. Instead of letting the S-CSCF fork the INVITE to multiple registered contact addresses, the AS sends multiple INVITE messages to S-CSCF, one for each device to which the call shall be offered. This method requires that the respective devices have registered with IMPUs that do not reside in the same IRS.

•

Termination of a call at any moment. For example, due to charging restrictions (credit depletion).

•

Creation of follow-on calls. When the remote party ends the active call, the SIP-AS can create a new INVITE request message to a new destination.

•

Generation of mid-call announcements. This requires connecting the calling or called party to an announcement device during the established SIP session.

•

Creation of conference calls. This requires the establishment of one or more additional outgoing SIP sessions, as well as connecting the user plane of the participants of the call to a conference bridge.

One very prominent use of the SIP-AS acting as B2BUA is the "SIP gateway model" (see Figure 8.44). The left SIP-AS in Figure 8.44 illustrates a scenario where the SIP-AS maps each dialog that is created downstream to a corresponding dialog upstream. The multiple downstream dialogs may also have resulted from the SIP-AS itself creating multiple SIP sessions, i.e. SIP-AS sending multiple INVITE messages (AS-controlled forking). For each of these dialogs, there may be independent SDP offer–answer sequences; the SIP-AS conveys the SIP messages transparently, whilst acting as a B2BUA. The calling party, which may be a SIP terminal, a media gateway controller or other entity, will in this case be capable of receiving multiple SIP dialogs.

Figure 8.44. SIP-AS applying the gateway model.

The right SIP-AS in Figure 8.44 applies the gateway model. There are multiple dialogs downstream. However, the SIP-AS maps these multiple downstream dialogs to a single upstream dialog. The SIP-AS may be compelled to apply this method when the calling SIP entity, e.g. a gateway, does not support multiple early dialogs.

The gateway model is more complex than the transparent B2BUA. For the gateway model, SIP-AS may have to map the SDP answer received through one dialog on to an UPDATE request message to the calling party. This is specifically required when SIP-AS had already forwarded one SDP answer to the calling party. A second SDP answer received by SIP-AS would have to be mapped to a new "SDP offer" by the SIP-AS, conveyed in an UPDATE transaction! Not all use-cases can be supported through the gateway model, including for example preconditions for the mobile IMS.

8.8.4.3 User Agent Server

When a SIP-AS receives a SIP INVITE request (or other request), it may act as UAS in the strict sense of the word. That is, the SIP-AS starts a UAS process and responds to the calling party through this UAS process, without creating a corresponding UAC process (see Figure 8.45).

Figure 8.45. SIP-AS acting as UAS.

The UAS provides a final response to the initiating party, which then closes the INVITE transaction. Typically, the final response will be an unsuccessful final response, since there is no SIP session to be established. A SIP-AS may apply the UAS model when it is applying incoming call barring, for example. The SIP-AS is being invoked from the S-CSCF for a terminating call and SIP-AS determines that the call may not be established. The SIP-AS may in that case return a 486 Busy Here response:

SIP/2.0 486 Busy here

Retry-after: 1200 (Out of office)

The 486 Busy Here response is followed by an ACK from the calling entity up to the SIP-AS. The Retry-After header provides additional information to the calling party. Service logic in the SIP-AS may determine (calculate) that, from this moment, the call will be available in 1200   s (20 minutes). The "(Out of office)" text string is free-format text that may be compiled by the service logic. This example may apply for a personal-assistant service with coupling with a person's Outlook agenda.

The fact that a SIP-AS is acting as a UAS, as opposed to a proxy or B2BUA, is not explicitly known or detected by the S-CSCF. The S-CSCF sends the INVITE request up to the SIP-AS, over the ISC reference point, and is prepared to receive an INVITE back containing the original dialog identifier. Instead, S-CSCF receives a 486 Busy Here response, without having received an INVITE back. This terminates the INVITE transaction for the S-CSCF, after the ACK is processed.

8.8.4.4 User Agent Client

A SIP-AS acting as user agent client (UAC), finally, implies that the SIP-AS is generating a call not related to ongoing call handling. When SIP-AS is acting as a B2BUA, it already includes a UAC instance.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780123821928000081

Applications in the IP Multimedia Subsystem

Rogier Noldus , ... Mats Stille , in IMS Application Developer's Handbook, 2011

4.4.1.2 Application Routing on JSR289

A Java EE AS provides the network services over which SIP requests and responses are sent and received. The SIP container then implements an application selection and chaining mechanism much like the one used by IMS on the level of the S-CSCF and on a higher level by the SCIM (Service Capability Interaction Manager). This mechanism is the application router (AR) standardized in the SIP servlet API JSR289.

When the S-CSCF passes on an initial SIP request (i.e. a request that is not part of an existing SIP dialog or call) to the AS, the SIP servlet container uses the application router (AR) interface to consult an external composition logic with respect to what services to execute in order to establish a SIP chain that corresponds to the needs of the particular session and subscriber. Given that the service being executed passes on the initial request to continue the call, the container queries the AR again to select the next service to invoke. In this way, a chain of services is formed until all the desired services are invoked. Any subsequent requests and responses within established SIP dialogs are routed along the SIP chain. The AR is not triggered by such subsequent requests.

Each invoked SIP application on the container operates as an independent SIP entity. It can send and receive SIP requests and responses to both external and internal entities. In the context of chaining within the container, such messages are passed between adjacent applications (upstream and downstream) in the chain executing in the same container.

It is important to realize that to be able to take part in a SIP session and manipulate the call state, a SIP servlet needs to be on the communication path between the caller and the original callee right from the session establishment phase and may not be easily added to the chain later on.

This peculiarity of one-dimensional application logic introduces many problems when designing more complex applications that may only be successfully managed through the enforcement of a clear separation between the time when the SIP component is put on the communication path (SIP chain in SIP jargon) corresponding to a SIP session, and the time when this component may act at the SIP level. It should be pointed out that this mechanism bears great similarity to the way IMS AS are chained by the S-CSCF based on the initial filter criteria as described in previous sections of this chapter.

With a few rare exceptions, SIP components can be put on the SIP chain only during SIP session establishment. Once the session is established, its SIP chain can be modified only with difficulty. Therefore, any SIP component that may be needed at a later stage should be put on the SIP chain during its establishment (e.g. during initial SIP INVITE processing), even if later due to some dynamic conditions it turns out that this component is not going to be used after all.

It should be noted that in theory the application chain may also branch and merge, and can change dynamically at any point in the lifetime of a communication session. However, this not only increases the complexity of managing the SIP chain; it also introduces additional complexity related to handling the internal application state.

We have now clarified when to put SIP components on SIP chains. But when do these components start acting? Sometimes, SIP components (usually SIP proxies) act directly on the initial SIP signaling when they are put on the SIP chain. In other situations, SIP components may also act when they received certain subsequent signaling, e.g. specific SIP responses. Sometimes, components do not act at all, e.g. because none of the required conditions was met, and just let SIP signaling flow through them transparently.

Application routing in the SIP servlet standard is loosely based on the concepts defined by the Distributed Feature Composition (DFC) architecture. Figure 4.7 illustrates service composition in a SIP servlet container. The container orchestrates a linear sequence of services for a given originating or terminating subscriber. The services party A subscribes to are executed prior to services party B subscribes to.

Figure 4.7. Service composition inside the SIP container.

The following section provides a detailed introduction to the development of an application router and the possibilities offered to developers interested in creating a flexible router able to create composite IMS services.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780123821928000044

Web-Based Tools for Exploring the Potential of Quantitative Imaging Biomarkers in Radiology

Roger Schaer , ... Adrien Depeursinge , in Biomedical Texture Analysis, 2017

13.2.6.3 Java EE for plugin development

The Java EE application server is used for multiple purposes. It serves as the main resource for heavy computations required by certain plugins. The physical machine hosting the server has the following performance characteristics:

•

2 x Intel(R) Xeon(R) Central Processing Unit (CPU) E7-4820 @ 2.00 GigaHertz (GHz) processors (64 cores in total),

•

128 GigaByte (GB) main memory,

•

Gigabit Ethernet network connection,

•

550 GB Solid State Drive storage.

The Java EE server architecture allows persisting all processed images, annotations, patients, along with computed features and generated results in a relational database for further analysis, reuse for training machine learning algorithms, extraction of statistics, etc. Fig. 13.10 shows a model of the various business objects involved in the persistence of image annotations and all linked metadata. It consists of the following main classes:

Figure 13.10

Figure 13.10. Business objects of the Java EE plugin platform.
•

Person – abstract class defining the basic properties of a person, i.e., an identifier (for the database) and a name.

•

User & Patient – implementations of Person with additional fields (user ID and role for User, and personal information such as the birth date and sex for Patient).

•

ImageReferenceEntity – description and content of a DICOM image.

•

ImageAnnotation – properties and coordinates of ROIs.

•

QuantitativeImagingFeatures – representation of the computed visual features extracted by a quantitative image analysis plugin.

•

SVMClassifier – instances of SVM models built from one or more computed feature vectors stored in QuantitativeImagingFeatures.

The persistence of business objects is fully managed through the Java Persistence API (JPA). Java EE contains several security mechanisms, allowing to ensure data privacy and security in all layers of the system (applicative, network transmission, storage). All components of the application (web services, business objects, image processing classes) are easily managed through the use of EJBs. Their execution environment (i.e., EJB containers) handles the role, scope and lifecycle of every component. Web Services and business classes used for short-lived operations are defined as stateless session beans. JPA entities are used to annotate business object classes for persistence. A singleton bean is used for managing the MATLAB factory, which initializes a unique reference to the heavy objects used for executing the MATLAB routines. Its lifecycle is as long as the application. The persistence bean contains a persistence context, which allows establishing a connection to the MySQL server and executing queries through the EntityManager interface. Fig. 13.11 shows the various EJBs and their links to other managed components of the system.

Figure 13.11

Figure 13.11. Java EE EJBs. The stateless Web Service Resource (top) is used by the ePAD plugins using a web service client class. It holds references to the three main EJBs (MATLAB Bean, Persistence Bean and SVM Classifier Bean), which are obtained through dependency injection. The MATLAB Bean handles the call to the MATLAB routines using a singleton factory object. The Persistence Bean handles saving and reading the business objects described in Fig. 13.10 to the MySQL database. The SVM ClassifierBean handles the creation and reuse of SVM models using WEKA.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780128121337000132

Evolved IP Multimedia Architecture and Services

Rogier Noldus , ... Mats Stille , in IMS Application Developer's Handbook, 2011

13.5.1.1 Main Nodes with SRVCC Functionality

The Service Centralization and Continuity application server (SCC AS) is a new logical IMS application server that for SRVCC is used primarily as a call signaling anchor when switching between the access legs. It acts as a SIP back-to-back user agent (B2BUA), maintaining service continuity by sitting in the signaling paths and executing the transfer between the access legs. The SCC AS is located on the ISC reference point.

The MSC needs to support SRVCC and the Sv reference point. SRVCC handover of a single active call can be done without support of the new SIP-based MSC interface for SRVCC and ICS I2, i.e. by using an MGCF for CS/IMS interworking. However, the I2 interface is required to support SRVCC handover of calls in alerting state, held calls, and calls in conference state.

The Mobility Management Entity (MME) in the Evolved Packet Core architecture needs to support SRVCC by indication of SRVCC capability, receiving SRVCC indication from eNodeB, supporting the handover via the new reference point Sv, and should include a bearer splitting function.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780123821928000135

Voice and Emergency Services

Magnus Olsson , ... Catherine Mulligan , in EPC and 4G Packet Networks (Second Edition), 2013

11.7.1 Service Centralization and Continuity Application Server (SCC-AS)

The IMS Service Centralization and Continuity Application Server (SCC-AS) is a key component in the IMS Centralized Services (ICS) solution. This is a logical node and co-located inside the TAS but it can also be provided as a standalone AS.

ICS enables the support of the VoLTE service engine (TAS) over legacy CS access from a VoLTE device.

One important function of the SCC-AS is terminating access domain selection (T-ADS), described in Section 11.5.

The details of SRVCC and related procedures reach beyond the EPS into the IMS and the CS core network. This chapter will outline the SRVCC procedure and the impact on the EPC network at a high level without going too far into the details of other parts of the system. The 3GPP TS 23.216 elaborates more on the SRVCC procedure and impacts the EPC while the 3GPP TS 23.237 details how the IMS handles service continuity. It is beyond the scope of this book to describe the IMS in detail; refer to Camarillo (2008) for more information.

The solutions for SRVCC towards GERAN/UTRAN and SRVCC to CDMA are not exactly the same due to the differences in the interworking of EPS with CDMA and GERAN/UTRAN respectively.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780123945952000116

Hotspot and Hotzone Access

Richard Watson , in Fixed/Mobile Convergence and Beyond, 2009

10.1 Wireless Internet Service Provider (WISP) Access Considerations

Corporate campuswide wireless connectivity to databases or application servers has become commonplace. The mobile enterprise worker is no longer tied to a desk but can now be productive in those long management meetings by responding to email (we all do it) while fulfilling corporate commitments in the lunch room, conference room, and engineering lab. Deployment of WiFi within the enterprise has extended the reach of the network to virtually every corner in the corporate facility and has had a positive impact on the overall productivity of people in the enterprise.

Telecommuting is also a trend that has leveraged wireless freedom in the home or remote office. Just as wireless mobility has been provided to on-campus associates, remote workers can enjoy wireless freedom in their personal work locale. Though deployment is not as straightforward as on-campus wireless, remote wireless access can be installed with the cooperation of the corporate IT team and typically requires imposing supplementary security measures in the form of a VPN. The remote user's experience of wireless freedom can be almost identical to that of the on-campus associate.

As WiFi is embraced by our society, the phenomenon of public hotspots has emerged and is increasingly prevalent in urban areas. Major cities such as Philadelphia, San Jose, New Orleans, Mountain View, Santa Clara, San Francisco, and others are in the process of investigating public hotspot services under the sponsorship of the municipal authority. For the highly mobile worker (executive, field service, transportation, public safety, and others),these trends open up new potential for extending UMC connectivity. With the availability of this expanded wireless network service, what is the upside for leveraging these network services, and what are the hurdles to overcome so that we are able to use them?

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780750687591000100

Efficient data deduplication scheme for scale-out distributed storage

Myat Pwint Phyu , G.R. Sinha , in Data Deduplication Approaches, 2021

9.4.1 A framework of reliability-guaranteed capacity optimization for scale-out distributed storage

Organizations in every market segment require their storage utilization to optimize and cost-effectively align with the changing storage capacity needs of their business. Scale-out distributed storage is becoming an important environment for the storage and the exchange of information as the data-intensive workloads are rapidly growing in the last decades.

In this chapter, reliability-guaranteed storage capacity optimization for scale-out distributed environment is proposed since the optimized data storage is essential with today's explosive growth of data. As the data deduplication methods play a vital role in controlling storage capacity, the efficient data deduplication framework called DSCapOpt is presented to optimize the scale-out distributed storage capacity. Moreover, data reliability is achieved by balancing the deduplication and replication.

A system to optimize the capacity in scale-out distributed storage environment is developed for space efficiency and reliability guarantee because of the unreliable storage nodes in scale-out distribute storage environment. The proposed DSCapOpt framework has three primary components: clients, an agent server, and the storage pool. The framework of reliability-guaranteed capacity optimization for scale-out distributed storage is depicted in Fig. 9–3.

Figure 9–3. Framework of reliability-guaranteed capacity optimization. BFA, Bloom filter array.

9.4.1.1 Clients

In the proposed framework, clients act as application servers in the real environment such as email servers and web servers. Multiple clients can access the storage system simultaneously. To submit data to the storage system, each client implements file chunking and fingerprint making before transferring to the storage pool.

9.4.1.2 Agent server

The agent server is the intermediate node before storing data to the storage pool. It contains BFA supporting good duplicate detection and the replication manager that is responsible for packing the chunks to a container and distributing it to the storage pool by erasure coding. Since distributed systems have a demand to share available data, Bloom filters have a great influence on the distributed protocols. In the proposed framework, the array of Bloom filter is used to overcome the network traffic without the hops.

The replication manager is a representative for distributing the deduplicated data to the storage pool. Before distributing, the replication manager calculates the chunks to store in the storage pool as erasure codes because of the benefit of erasure-coded redundancy scheme (Wu & Dimakis, 2009) where the packet loss in the transmission phase can be reassembled at the receiver. Erasure-coded redundancy enables the following:

1.

Breaking the data into multiple packets,

2.

Encoding with additional bits of information,

3.

Sending to a receiver, and

4.

Decoding and reassembling into the original data on the receiving side.

9.4.1.3 Storage pool

The storage pool is a collection of storage servers on the environment of consistent hashing. The storage pool grows on as-needed basis. Blocks of data chunks can be placed into the appropriate place in the pool depending on the key-value pairs. Metadata information and fingerprint information are also kept in the storage pool for permanence.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780128233955000045

Principles of Operation

Arun Handa , in System Engineering For IMS Networks, 2009

5.8 Service Orchestration and the SCIM

Implementing a solution drawn from standards-based specifications often exposes some gaps that are left to the creativity of the implementers. This classic gap is often perceived as a consequence of difference in thinking between researchers and practitioners. The reality, however, is that there are three factors contributing to this. In the long-drawn standardization process, it is always a challenge to put on paper a 100-percent solution. The other two factors are advances in technology and changes in market needs by the time the standard comes to see the light of implementation.

The Service Capability Interface Manager (SCIM) is one such example of this classical chasm. This becomes more prominent as we move from proof-of-concept solitary IMS applications toward deployments that rely on multiple service interaction. This does not come as a surprise. The context is new, but the problem is still the unsolved feature interaction reminiscent from the early IN days.

The IMS reference architecture based on best-of-breed telecom solutions continues the similar paradigm, to separate the service plane from the control plane. This offers the extensibility for new service logic, without impacting the CSCF functions. There are two options for the service environment: services that are being built fresh, and traditional or legacy services. We see a new generation of services, which are purely SIP-based or co-exist with legacy services, where the service providers have a significant investment.

As shown in Figure 5.14 , IMS clearly outlined the invocation of services from the application servers from the Serving CSCF for next-generation services and for Legacy—an interworking functionality of an IM-SSF for IN services and OSA for Parlay.

Figure 5.14. The original view of the SCIM.

The initial standards created the concept where "The application server may contain 'service capability interaction manager (SCIM)' functionality and other application servers. The SCIM functionality is an application that performs the role of interaction management. The internal components are represented by the 'dotted boxes' inside the SIP application server. The internal structure of the application server is outside the standards." Since then, however, the SCIM never received any attention from the standards and still is not a bullet item for Release 7. The following drivers have led to an increased interest this interaction management and filling this gap. These are:

•

The emergence of blended services

•

Limitations of the service triggers (Initial Filter Criteria)

•

Inter-working with legacy services

•

Converged services with the Internet

Figure 5.15. The enhanced SCIM view.

Blended Services. One of the benefits IMS promises to offer is a new and unique "User Experience." The reference architecture is intended to provide a rich set of multimedia services. As service providers get a better grasp of monetizing multimedia, the excitement is growing about how to blend services together as opposed to simply bundling them. This paradigm was fairly limited with traditional voice-based telecommunications. The consumers are now expecting Internet-like services on mobile devices. Consider an analogy to a mashup on a google map, which extends the value of a plain satellite image and a street address lookup. Augment that with a push-to-talk to invoke a session to a pizzeria that gives the consumer a new experience for replacing yellow pages. Continuing on the same line to illustrate, blending the potential of IPTV, with location, messaging, and presence services, creates a potential for services beyond Text-based Televoting. What this pushes for is a more intelligent entity to control a set of disparate services. This takes us to the next point, which is to understand better why the current scheme has its own limitations.

Figure 5.16. The security architecture.

Session Control and the iFC. Service Invocation in the IMS is done by a trigger mechanism. The serving S-CSCF obtains the initial filter criteria from the HSS for a registered subscriber. When the subscriber sends a SIP command, INVITE for instance, for the multimedia session one is requesting, the S-CSCF cascades through the iFC and sends the invocation to the necessary application servers based on priority. While the S-CSCF has been enabled to invoke multiple sessions in a sequence, even fork them, it is assumed that once the control is handed over to an application server, it will be the responsibility of the AS to coordinate with other services. This becomes a problem. To implement a service that requires combinational services, such as starting a push-talk session from a google-mashup as described, will require to shift the control between two applications dynamically upon user-control. This also exposes an issue that the iFC can cascade through services, but does not allow interleaving on a dynamic nature.

Legacy Interworking. For the service providers, IMS is a great vehicle for lowered Capital Expenditure (CAPEX) and Operational Expenditure (OPEX), and building differentiated services for future communication networks. However, the challenge for them is that there still exists substantial revenue-generating service infrastructure both within their network and externally (e.g., Messaging, VoiceMail, and Location), that can be effectively harnessed. Adding to it, the initial IMS vision for only CAMEL services (or OSA) to represent a vast legacy infrastructure falls short as well. The CDMA networks are not CAMEL-based but use WIN instead. Apart from roaming and prepaid, few CAMEL services are deployed. So, how would a service provider leverage an investment in, say, a Ringback tone platform or network-based location infrastructure? And orchestration between the new generations of services requires both. For instance, sending an SMS while watching American Idol on IPTV can be done by the click of a remote, but will require the application server to understand that an SMS gateway needs to be used to send the message. So, should IMS push the burden of network technology awareness to Application server platforms, or instead provide a platform to invoke the services in a more agnostic manner?

Internet Services. Given the wide base of a billion Internet users, the expectation of this vast population is to access Internet services on the mobile devices. This again calls for the capability to orchestrate between Internet access and other services. Do IMS Application Servers have centralized access mechanisms to Internet services, or does each have its interface? In other words, does all the presence access get centralized, or do specialized services access these interfaces with their own interfaces?

Given the following discussion, the nature of the problems to be solved now requires the following. This is not truly the SCIM that was conceived of five years ago, but seems to be what is now lacking. In order not to offend the purists, let's call this functional element the Enhanced SCIM, or the ESCIM.

The ESCIM can be perceived as an Application Server (AS) platform that has the capability to route, broker, and deliver to specialized application servers.

To the SCSF it simplifies the execution logic of the iFC by interacting with a single entity, and follows the design tenet laid out of pushing control to the application server, which is the ESCIM in this case.

The broad functions of the ESCIM are therefore to provide the following:

•

Registration of services

•

Invocation of services

•

Brokering between services

•

Cascading through services by static rules

•

Cascading through services through dynamic user interaction

•

Routing and load balancing between homogenous application servers

•

Providing a user identity for AS-invoked services.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780750683883000058

Implementing IMS Functional Elements

Arun Handa , in System Engineering For IMS Networks, 2009

9.4.2 SCIM

The nature of the SCIM to support service interaction between SIP application servers, lends itself well to the servlet model. The servlets can be invoked through a rule-based engine, which defines the logic for service interaction. This can be made effective by cascaded execution of the servlets. JSR 289, which is still in a draft stage at the time of writing, extends the JSR116 model to support this feature.

The more challenging part is to gauge the interfaces to various application servers. The natural choice is to extend the IMS Service Control (ISC) interface towards the application servers as well, which provides a homogenous view to both SIP and legacy servers. However, an alternate model is to realize the value of the SCIM by providing service mediation between existing revenue-generating services and next-generation services. Figure 9.12 shows the layered model. The SCIM needs to be able to support the necessary interfaces and adapters to Legacy service elements (e.g., an IN SCP). The next layer comprises the middleware to support message handling, routing, and transaction management. The Execution layer based on either the servlet model or implemented as a set of cooperating agents directed by a rule engine, provides the support for creating a composite service between the various interfaces.

Figure 9.12. The SCIM in a converged environment.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780750683883000095

Putting It All Together

Arun Handa , in System Engineering For IMS Networks, 2009

6.3.4 UE Service Invocation

We now examine our next example of how a UE invokes a service from an application server as illustrated in Figure 6.8. We continue with our case where the UE is in a visited network and initiates an INVITE session to a PSI hosted on an application server.

Figure 6.8. UE service invocation.

The UE begins with an INVITE with the Request-URI containing the address of the PSI the UE wants to establish a session with. It forwards the message to the P-CSCF, which then sends it to the I-CSCF in the home network.

When the I-CSCF receives the INVITE message, it checks the Request-URI. If it contains a pres: or an im: URI, it will translate that to a public user identity. It removes the Route-Header. If the domain name in the Request-URI matches the known Public Service Identity (PSI) sub-domains in the I-CSCF, then it resolves the Request-URI by a DNS lookup to determine the address of the AS hosting the PSI. Otherwise, the I-CSCF will send a Diameter Location Information Request (LIR) to the HSS for the PSI derived from the Request-URI. If the Location Information Answer (LIA) returned from the HSS contains the address of an application server, it will then forward the request to the AS directly, which is hosting the PSI. If the LIA returns the address of the S-SCSF assigned to handle the request, will forward the INVITE to the S-SCSF. In either case, it will retain the value of the ICID in the P-Charging-Vector.

If the UE is trying to establish a call-related session, the message flow thereafter is similar to the session establishment as we followed earlier.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B978075068388300006X