Content for TR 23.849 Word version: 11.0.0
0 Introduction
1 Scope
2 References
3 Definitions and abbreviations
3.1 Definitions
3.2 Abbreviations
4 Assumptions, architectural requirements, and use cases
4.1 Assumptions
4.2 Architectural Requirements
...
...
0 Introduction p. 4
The capability to allow media to be routed in an optimal manner between IMS operators when the subscriber is roaming was introduced in Rel-10. However, certain features may require that the media is controlled by the home network. These features include conferencing, transcoding, tones insertion and announcement insertion.
In these cases, the media plane is typically re-directed back to the home network to perform these functions. For transcoding, the media would have to stay routed through the home network for the duration of the call. However, for tone and announcement insertion, there is the possibility to temporarily re-direct the media plane though the home network only for the duration of the tone/announcement. Unfortunately, neither of these solutions is ideal from a subscriber's perspective as it potentially introduces delay between the call parties. In addition, the subscriber will also experience a cut-out of media whilst the re-direction is performed (if redirected mid-call e.g. for tone/announcement insertion). This increases the risk of the call being cut-off (e.g. if the redirect fails for some reason).
1 Scope p. 5
The present document provides a study into the new (Rel-11) requirements identified by SA WG1 to allow a home network to control a visited network to perform the following IMS functions for its subscribers:
- conferencing (network hosted);
- transcoding;
- tone insertion; and
- announcement insertion.
2 References p. 5
The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
- References are either specific (identified by date of publication, edition number, version number, etc.) or non specific.
- For a specific reference, subsequent revisions do not apply.
- For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[1]
TR 21.905: "Vocabulary for 3GPP Specifications".
[2]
TR 21.801: "Specification drafting rules".
[3]
TS 23.218: "IP Multimedia (IM) Session Handling; IM call model; Stage 2".
[4]
TS 23.228: "IP multimedia subsystem; Stage 2".
[5]
TS 24.229: "IP multimedia call control protocol based on SIP and SDP; stage 3".
[6]
TR 23.850: "Study on Roaming Architecture for Voice over IMS with Local Breakout".
3 Definitions and abbreviations p. 5
3.1 Definitions p. 5
For the purposes of the present document, the terms and definitions given in TR 21.905 apply.
3.2 Abbreviations p. 5
For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.
AS
Application Server
B2BUA
Back to back user agent
CS
Circuit Switched
CSCF
Call Session Control Function
HPLMN
Home Public Land Mobile Network
IBCF
Interconnection Border Control Function
MGCF
Media Gateway Control Function
MRB
Media Resource Broker
MRF
Media Resource Function
MRFC
Media Resource Function Controller
MRFP
Media Resource Function Processor
I-CSCF
Interrogating CSCF
P-CSCF
Proxy CSCF
S-CSCF
Serving CSCF
SDP
Session Description Protocol
SIP
Session Initiation Protocol
TCP
Transmission Control Protocol
TrGW
Translation Gateway
UDP
User Datagram Protocol
UE
User Equipment
VPLMN
Visited Public Land Mobile Network
4 Assumptions, architectural requirements, and use cases p. 6
4.1 Assumptions p. 6
The following assumptions need to be borne in mind for the chosen solution, and add clarity to the architectural requirements that follow in the next sub-clause:
- The subscribers involved in the solution are assumed to be inbound roaming subscribers from another PLMN operator. However, there should be nothing preventing a PLMN using it for its own subscribers, if it so wishes.
- Any Private and Public Identity selection that is preconfigured in the VPLMN is statically configured and agreed by the HPLMN through usual inter-PLMN commercial roaming agreements.
4.2 Architectural Requirements p. 6
The chosen solution shall fulfil the following architectural requirements:
- Can avoid the need to route the IMS media plane via the HPLMN for the IMS functions as listed in the Scope section of the present document.
- Shall have minimal impact on the existing IMS architecture and shall reuse or enhance existing interfaces/reference points wherever possible.
-
Can be invoked selectively by the VPLMN as follows:
-
On a per subscriber basis such as:
- static configuration in the VPLMN; and
- subscriber profile flag conveyed by the HPLMN.
-
On a per IMS function (as listed in the Scope section of the present document) such as:
- static configuration in the VPLMN; and
- subscriber profile flag conveyed by the HPLMN.
-
On a per subscriber basis such as:
- The VPLMN can deny all or a sub-set of the IMS functions (as listed in the Scope section of the present document) to all or a defined sub-set of subscribers at any session establishment (e.g. due to a lack of capacity/availability).
- Architecture alternatives shall avoid disclosing the hierarchy of operator's resources network and the operator's selected deployments of AS/MRF, MRFC/MRFP and/or MRB/MRFC.
