13 Media resource broker (MRB)

23.2183GPPIM call modelIP Multimedia (IM) session handlingRelease 17Stage 2TS

13.0 General

The Media Resource Broker (MRB) is a functional entity that is responsible for both collection of appropriate published MRF information and supplying of appropriate MRF information to consuming entities such as the AS. Therefore, the MRB is responsible for supporting the identification and selection of appropriate MRF resources.

The MRB supports the sharing of a pool of heterogeneous MRF resources by multiple heterogeneous applications. MRB assigns (and later releases) specific suitable MRF resources to calls as requested by the consuming applications, based on MRF attributes specified by the applications as well as other criteria.

The MRB may take the following kinds of information into account when assigning MRF resources to an application:

– the specific characteristics of the media resources required for the call or calls;

– the identity of the application;

– rules for allocating MRF resources across different applications;

– per-application or per-subscriber SLA or QoS criteria;

– capacity models of particular MRF resources; and

– if it can use the services of another (visited network) MRB.

There are two modes in which MRB can be utilized – Query and In-Line, as explained below. An instance of an MRB may simultaneously operate in both modes. Likewise, a given AS/application could employ Query mode on some calls and In-Line mode on others.

Query and In-Line modes of MRB have the following in common:

– the role of MRB is the same – assignment of MRF resources to calls as requested by applications;

– an application server provides the same kind of information to MRB on MRF attributes needed for a given call; and

– the way MRB acquires knowledge of MRF resources and other information needed to perform its role is the same (see subclause 13.3).

Query mode allows the application to:

– be the entity that determines when an MRF resource can be released;

– request and be assigned MRF resources for multiple calls in advance; and do that in a single request/response; and

– incrementally request more MRF resources or release resources that it determines aren’t in fact needed.

An MRB can use the services of another MRB, either in In-Line mode or in Query mode, using the Mr, Mr’ and Rc interfaces appropriately.

13.1 MRB Query Mode

Figure 13.1.1: Query Mode

With Query mode, the AS queries the MRB with a request for media resources with certain attributes using the Rc interface. The MRB selects suitable MRF Resources, assigns them to that AS/application, and responds to the AS with the addresses of the selected MRF resources.

Once the AS receives the response from MRB, it sets up the call or calls to the MRFC either through the S-CSCF (ISC and Mr interface) or directly to the MRFC (Mr’ interface), using the MRF address information supplied by MRB. Control packages are supported over the Cr interface.

When the AS/application is done using a MRF resource, it sends another message to MRB indicating so, and MRB returns that resource to the idle pool and acknowledges to the AS/application.

13.2 MRB In-Line Mode

Figure 13.2.1: In-Line Mode

With In-Line mode, the MRB is between the AS and the MRFC. The AS sends a request to establish a dialog to the MRB (using the Mr’ interface, or via the S-CSCF using the ISC and Mr interface). The request can contain information relating to the kind of MRF required to handle that particular call. The MRB selects an appropriate MRF resource and sends the request along to the MRF (using the Mr’ interface, or via the S-CSCF using the ISC and Mr interface). Subsequent messages in the same dialog between the AS and MRFC traverse the MRB (as well as the S-CSCF if that was in the path between the AS and the MRB, or between the MRB and the MRFC).

Control packages are supported over the Cr interface directly between AS and MRFC.

The MRB infers that the media resource is no longer needed when it sees a session release request from either the AS or MRFC.

13.3 MRB knowledge of MRF resources and other information

In order to perform its function, MRB may need the following kinds of information (this is not necessarily an exhaustive list):

– available MRF resources and their attributes; current and future. This may take into account planned and unplanned downtime and the scheduled addition/deletion or availability of MRF resources;

– rules for fair-share allocation across applications;

– capacity models for particular MRF resources; and

– reservations for future use of media resources (for example, for conferencing, or for anticipated traffic spikes for other applications such as a FreePhone application).

The above information can all acquired by MRB through operations interfaces. However, it the MRB can also learn of available MRF resources and their characteristics via a direct MRB-MRF interface.

Annex A (informative):
Scalability and deployment considerations for IP multimedia service provision

This Annex is intended to guide the reader in deployment and real life issues.

This specification has provided a set of tools for the application developer and the application integrator to utilize in order to develop and deploy applications and provide services for the IP multimedia core network subsystem. However, practical deployments will need to consider certain scalability issues with the use or misuse of some of the tools specified in this specification.

The architecture allows for any number of Application Servers to be connected to any number of S-CSCFs and Transit Functions, and any number of Application Servers to be involved in the initiation of a multimedia session. A scalability issue may arise if there are a large number of S-CSCF, Transit Functions and AS in a network.

Consideration should be given to the signalling propagation delays introduced when many Application Servers add themselves to the route to provide originating and terminating services for the calling and called parties.

A SIP Application Server may act as gateway function by forwarding an incoming request to external ASs beyond the IM CN subsytem. An external ASs will also send responses to IM CN subsytem via a SIP AS gateway. These other Application Servers can be located externally to the home network, and use the SIP Application Server as a gateway to the ISC interface. The interface between the SIP Application Server acting as a gateway, and other Application Servers is outside the scope of the present document.

There is another case where the external AS is connected with S-CSCF (or I-CSCF) via public ISP networks depending on the operators desire for network configuration hiding. S-CSCF or entities outside the S-CSCF may perform the interworking function.

Care must also be taken to the priority and order of contact of multiple Application Servers during a session in order to account for feature interaction issues.

Figure A.1: Example hierarchical architecture for Application Servers

Figure A.1 depicts a possible solution that shows how a S-CSCF (S-CSCF1 S-CSCF3) could be connected to a single AS (SIP AS1), while another (S-CSCF2) could be connected to more than one, in this case it is two (SIP AS1, SIP AS2). All S-CSCF will be connected to the HSS via Cx. A SIP AS may be connected to the HSS via Sh. SIP ASs may be connected to the IP network, which could allow them to contact Application Servers (e.g., either SIP ASs, or Other ASs).

Care should be taken to the transaction delays resulting of a high number of S-CSCF, Transit Functions and ASs on the session signalling path.

A possible application of this architecture is described below (see figure A.2).

While some applications need to discover the registration of a user on an event driven basis, many applications do not. For many applications an access to the HSS or other database to obtain the address of the S-CSCF that serves a user is sufficient to contact and initiate a session to that user, and others (such as basic call feature servers) do not require to be informed of the registration state or necessarily even need to know the identity of the user. It is therefore possible that the filter criteria are set in such a way that S-CSCF3 does not forward or notify SIP AS 3 of REGISTER requests. SIP AS3 would then need to determine registration status via other means (i.e. via IP network) not specified.

The number of Application Servers receiving REGISTER requests (i.e., SIP AS3) from an individual S-CSCF should be minimized.

Figure A.2: Use of a hierarchy in a practical architecture for Application Servers

Annex B (informative):
Information flows for example services

This annex contains some informative example information flows that show the possible flow of information for some example services. These examples are intended only to help aid the understanding of the behaviour of the S-CSCF, MRFC and Application Servers for service provision for the IM CN subsystem and are not intended to recommend or specify how to create such services, (indeed the examples given may not even be a good idea for a practical implementation).

The following modes of operation are shown in these examples:

– Third Party Registration to Application Server subclause B.3.2;

– Application Server in Originating UA mode subclause B.3.2;

– Application Server in Redirect mode subclause B.1.3;

– Application Server in Terminating UA mode subclause B.3.1;

– Application Server in Proxy mode subclause B.1.4;

– Application Server in Third Party Call Control/B2BUA mode subclauses B.2.1, B.2.2,and B.2.3;

– Application Server with no involvement subclause B.1.4.