tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

Top          in Index          Prev          Next

TR 23.812 (SA2)
Feasibility study on
IMS evolution

|   ToC   |   3GPP‑Page   |   Help   |

(W-zip) V11.0.0    2011/12    64 p.


Rapporteur:  Mr. Li, Gang
See also:  IMS-related TS/TR    


The scope of this TR is to capture the results of a study into the feasibility of enhancing IMS network architecture. This report intends to study the feasibility of enhancing IMS network architecture as follows:
  • Investigating architectural improvements to reduce the complexity of signalling procedures by reducing the signalling hops, or the number of options and combinations (by looking at different groupings of combining existing entities);
  • Investigating means to improve system-level load balancing and reliability;
  • Investigating possibilities for reducing configuration workload to save OPEX.
  • Investigating the introduction of IMS Overload Control mechanisms.
Backward compatibility with current IMS specifications shall be ensured.

NOTE:  overlap with SA5 and CT4 work need to be monitored.

This report is intended to explore potential architecture improvements and also provide conclusions on the above aspects with respect to potential future normative specification work.

There are a number of functions involved in call session setup in IMS network. Interfaces and interactions between network elements may be a little complicated and not that efficient. It is deemed beneficial to review the current IMS architecture including aspects such as the possible optimization of interfaces/reference points (by looking at different groupings of combining existing entities), reducing options of solutions for the same issues, relevancy of certain functions etc.

IMS network service availability largely relies on the reliability of network entities. If some network elements implementing critical functions (e.g. S-CSCF, HSS) fail, service availability may be impacted. Moreover network elements may not be fully utilized because network load may not be well distributed, e.g. some nodes may be overloaded due to sudden traffic increase, while others may be under loaded to some extent. Though there are some element level approaches to solve these problems, some system level solutions should be studied, for example, the method to distribute load between network elements in different geographical locations especially when a disaster happens, such as earthquake.

Network expansion may require significant manual configurations, and the network maintenance and upgrade may be time-consuming and also may be costly for operators. Introducing self-organization features may improve the network intelligence and reduce the efforts of manual configuration.

The objectives of the study for investigating the introduction of IMS Overload Control mechanisms are to:
  • Determine the parts of IMS architecture for which overload control mechanisms are needed;
  • Evaluate the applicability of candidate solutions for Overload Control to the SIP entities of the IP multimedia core network architecture, including:
    • mechanisms having already been specified or studied within 3GPP and their possible enhancements,
    • mechanisms specified or studied by other bodies (e.g. ETSI TISPAN, IETF) and their possible enhancements,
    • other mechanisms, if proposed within this work item;
  • Provide recommendations based on analysis.


 

Here          Top

 

 

1   Scope   Word-p. 7
2   References   Word-p. 8
3   Definitions and abbreviations
4   Analysis of IMS architecture
5   Applicability of Overload Control and Load Balancing
6   Architecture alternatives
6.1   Architecture alternatives for Load Balancing      Up
6.1.1   Load Balancing based on Load Detection Function
6.1.2   S-CSCF Load Balancing at Initial Registration based on HSS   Word-p. 24
6.1.3   Load balancing using IETF SOC Overload Control      Up
6.1.4   Load Balancing based on dynamic DNS   Word-p. 25
6.1.5   Registration independent Serving Node Load Balancing based on HSS   Word-p. 28
6.2   Architecture alternatives for Overload Control   Word-p. 30
6.3   S-CSCF re-selection   Word-p. 41
7   Assessment      Up
8   Conclusion   Word-p. 59
A   DNS UPDATE Mechanism   Word-p. 60      Up
B   IMS Deployment Scenarios   Word-p. 61
C   Example Load Information Required collected by LDF   Word-p. 63
D   Change history   Word-p. 64

Up          Top