22 Ct Studies

22.1 Study on as-mrfc media server control protocol uid_7048

Resources: C1

References

Document	Title/Contents
WID(s)
CP-060180	SID on AS, MRFC media server control protocol definition
Impacted Specifications
-	-
New Dedicated Specifications/Reports
TR 24.880	Media server control using the IP Multimedia (IM) Core Network (CN) subsystem; Stage 3

Supporting Individual Members: Hewlett-Packard, BT, Comverse, IAEI, Intel, Vodafone, Huawei.

SIP signalling over the S-CSCF – MRFC interface (Mr-interface) and the AS – S-CSCF interface (ISC) are specified but not the format of the media commands/instructions and results/events carried over this interface.

CT1 studied the definition of a media server control protocol in parallel with CT4's work on Mp interface definition (using H.248 protocol and packages are defined for the required media commands/instructions and results/events). CT1 considered supporting more advanced services (e.g. dialled in conferences, digit collection) and whether 3GPP should specify such a protocol. The study has identified Stage 2/3 work on the media server control protocol to be used over the Mr/ISC interfaces.

TR 24.880 describes the implementation options and requirements for a media server control protocol to be used with the Mr and ISC interfaces giving several recommendations for media server control:

• both the delegation and protocol models described should be supported. This study recommend the creation of a Cr reference point that can be used for both models;

• RFC 4240 should be supported with the clarifications to VoiceXML invocation defined in the draft-ietf-mediactrl-vxml specification;

• VoiceXML should be used to specify all user dialogs;

• a dedicated control channel should be supported;

• mid-call media processing should be supported;

• the AS/MRFC functional split should be supported with a top-level focus, notification server and conference policy on the AS and with media conference policy handling and low-level conference focus on the MRFC;

• the media server control methods should support organization, registration and extension of capabilities;

• RTSP URLs should be used for services which require the sourcing of streamed media.

TR 24.880 defines requirements for a media server control protocol as follows:

• multimedia services' media control requirements;

• response time requirements;

• packaging, registration and extensibility requirements;

• charging requirements;

• resource Management requirements;

• High Availability requirements;

• QoS control requirements;

• security requirements;

• lawful intercept requirements;

• priority requirements.

Spin-off new implementation Feature UID_380035 (MRFC_TS)

22.2 Study on ims Restoration Procedures uid_350018

Resources: C4

References

Document	Title/Contents
WID(s)
CP-070031	SID on IMS Restoration Procedures
Impacted Specifications
-	-
New Dedicated Specifications/Reports
TR 23.820	Study of IMS restoration procedures

Supporting Individual Members: Ericsson, Nortel Networks, Huawei, Vodafone, Orange.

Although network nodes in the IMS Core Network should have a very high availability, some maintenance stops and occasional failures are unavoidable. Communication links although designed with robust protocols between the Network Elements (NEs) are also subject to failures. There is currently no defined procedure in 3GPP specifications to restore a consistent state in the IMS Core Network after or during a planned or unplanned stop of a NE. Protocol details and procedures to detect this kind of failures in NEs and communication links are also not specified. This leads to vendor-specific implementations that might not interoperate. A set of standardized procedures for automatic restoration after loss or corruption of data could reduce the impact of these problems resulting in the improved service to the users. The intention is to have for the IMS domain similar Restoration procedures as for the CS and PS domains in TS 23.007.

CT4 studied behaviour of IMS Core Network upon restart of its NEs or failure of communication links between them, and analyzed alternatives ensuring minimum impact on service to the end-user (the availability of the UE to make and receive IMS sessions). The study also covers procedures triggered by external events indicating problems in IP-CAN.

The study proposes necessary operational protocol recovery mechanisms in the IMS Core Network in order to:

• Limit the time an end-user is affected by restart and downtime of the NEs in the IMS Core Network or the communication links between them.

• Improve the behaviour of the IMS Core Network with indications of network unavailability in the IP-CAN.

• Reduce the operating cost of the IMS Core Network by making as much as possible of the recovery procedures from a restart automatic.

• Ensure that critical services, such as security and charging are not affected in an unacceptable way.

The results of the study may also be used in other interfaces, not part of the IMS Core Network, but with similar protocol implementations, e.g.: I-WLAN, GAA. UE changes should be avoided if possible.

TR 23.820 identified changes required in 3GPP IMS specifications so that a consistent state is restored in the IMS Core Network, after or during a planned or unplanned stop of an NE. The study went through the following steps:

• Establish the requirements that should be covered with these procedures. I.e. after a network failure which impacts to the end-user service are acceptable and which not.

• List the service interruption scenarios that need to be studied.

• Provide solutions, so that in all the service interruption scenarios listed, the impacts to the end-user service comply with the requirements. These solutions provide procedures for the automatic restoration to a consistent state in the network and indicate how to trigger these procedures.

• Analyze the impacts of the solutions in the current specifications.

• Conclusion and recommended way forward.

These operational procedures for restoration must avoid overlap with OA&M procedures, which could cause clashes.

TR 23.820 made recommendations on:

• S-CSCF Re-Selection during Re-Registration

• S-CSCF, SIP-AS, HSS and P-CSCF service interruptions

Further improvements might be needed in future releases (see TR 23.820 clause 6.3) and are for further study.

Spin-off new implementation Feature UID_400012 (IMS_RP).