Content for TR 22.944 Word version: 18.0.1
B Scenarios for possible functionality split for the Circuit domain
B.1 Telephony
B.2 Circuit Bearer Services
B.4 Packet-Based Data Scenarios
$ Change history
B Scenarios for possible functionality split for the Circuit domain p. 13
This annex identifies scenarios for possible functionality split for the Circuit domain. It is expected that these scenarios will aid in deciding the functionality splits to be supported. Note that the scenarios enumerated here may not be exhaustive yet and others may be added.
B.1 Telephony p. 13
This clause deals with circuit-switched voice Telephony.
B.1.1 Functional Elements
The following functional elements are identified as being applicable to the Telephony service:
B.1.1.1 Call Control and Mobility Management (CC&MM) p. 13
The Call Control and Mobility Management entity is a C-plane function which supports the signalling for call control and mobility management. The actions of the CC&MM may be initiated directly by the user using a local HMI, or by a Call Control Client on a remote device.
B.1.1.2 Call Control Client (CCC) p. 13
The Call Control Client is a client that interfaces to the CC&MM to provide service. The protocol between the CCC and the CC&MM is an intermediate protocol that allows the CCC to signal its call setup and release requirements.
B.1.1.3 Codec p. 13
The codec is a U-plane entity responsible for applying the radio-interface voice coding to a PCM or analogue signal.
B.1.1.4 Transducer p. 13
The transducer a U-plane entity responsible for converting between physical sound waves and electrical signals.
B.1.1.5 Radio Resource Layers (RR) p. 13
The Radio Resource Layers cover the C-plane and the U-plane. They are responsible for all low-level protocols on the radio interface - including the MAC and physical layers.
B.1.2 Telephony Scenarios p. 14
B.1.2.1 Telephony Scenario 1 - Headsets p. 14
Telephony scenario 1 corresponds to the use of a headset to access the telephony service. Though a headset is not normally considered to be a TE, from a formal point of view it is an external device connected to the MT and therefore should strictly be included in the discussion. As the question of support for wireless headsets has frequently been mentioned in conjunction with UE-split it is felt necessary to include this scenario for completeness. The model presented is applicable to both wired and wireless headsets.
In Telephony Scenario 1 the TE only contains the transducer. All other functions are included in the MT.
B.1.2.2 Telephony Scenario 2 - Telephony Control Application in TE p. 14
This scenario corresponds to the use of a TE (a PC or a PDA) which contains a function to control telephony calls on behalf of the user. This might be a telephone dialler application linked to a contacts database. APIs like "TAPI" are typically used to provide this interface to applications. On the R-interface the AT-command set provides some of the required functionality. In this scenario the user's voice is still handled only in the MT.
B.1.2.3 Telephony Scenario 3 - Telephony Supported in TE p. 14
In this scenario the HMI for the Telephony teleservice is supported in the TE. This may correspond to a user who uses their PC or PDA to initiate calls (the above scenario), but also wants to multiplex the audio component of their calls on to their PCs sound-channel so they can also use the PC's MP3 or CD player via the same transducer.
The U-plane interface between the TE and the MT is assumed to be PCM or a similar light-weight encoding.
B.2 Circuit Bearer Services p. 16
This clause deals with the circuit-mode data bearer services
B.2.1 Functional Elements p. 16
The following functional elements are identified as being applicable to the Circuit Bearer Services:
B.2.1.1 Call Control and Mobility Management (CC&MM) p. 16
As for telephony.
B.2.1.2 Call Control Client (CCC) p. 16
As for Telephony
B.2.1.3 Terminal Adaptation Function (TAF) p. 16
The TAF maps the data format on the R-interface in to the format needed for the bearer.
B.2.1.4 Data Termination (DT) p. 16
The data termination is the end-point in the user-equipment for the bearer service. The DT is outside the scope of the 3GPP standard.
B.2.1.5 Radio Resource Layers (RR) p. 16
As for Telephony
B.2.2 Circuit Bearer Scenarios p. 16
B.2.2.1 Circuit Bearer Scenario 1 - PC or PDA Access p. 16
This scenario corresponds to a PC or PDA that uses the circuit bearer service. This scenario is supported by the existing R-interface standards.
B.4 Packet-Based Data Scenarios p. 17
B.4.1 Functional Elements p. 17
B.4.1.1 Session Management and Mobility Management (SM &MM) p. 17
The Session Management and Mobility Management entity is a C-plane function which supports the signalling for session management and mobility management. Session management includes the establishment, management and release of PDP contexts. The actions of the SM&MM may be initiated directly by the user using a local HMI, or by a Session Management Client on a remote device. This function does not include the SIP client.
B.4.1.2 Session Management Client (SMC) p. 17
The Session Management Client is a client that interfaces to the SM&MM to provide service. The protocol between the SMC and the SM&MM is an intermediate protocol that allows the SMC to signal its session setup and release requirements. This is a peer to the SM&MM and does not include SIP
B.4.1.3 SIP Client (SC) p. 17
The SIP-client terminates IMS signalling in the user equipment. It is responsible for all the control signalling between the user equipment and the elements of the IMS domain in the network.
B.4.1.4 IP Adaptation Function (IPAF) p. 17
The IPAF is a U-plane function that does the high-level mapping of IP data in to the UMTS bearer.
B.4.1.5 IP Data Termination (IPDT) p. 17
The IP Data Termination is the end-point in the user-equipment for the IP bearer service provided by the PS-domain. Note that the IPDT is not intended to be part of the IMS. Rather it represents other IP applications that may exist.
B.4.1.6 IMS Media Coding (IMC) p. 17
The IMS media coding is similar to the codec in the Telephony service. It converts media formats to those used for IMS. The IMC may support many types of media including speech and video.
B.4.1.7 Multimedia Transducers p. 17
The multimedia transducers convert between the physical works and electronic representation of multimedia content. They include microphones, speakers, displays etc.
B.4.1.8 Radio Resource Layers (RR) p. 17
As for telephony.
B.4.2 Packet-Based Data Scenarios p. 17
B.4.2.1 Packed-Based Data Scenario 1 - PC or PDA Access p. 17
This scenario corresponds to a PC or PDA that uses the packet bearer service. This scenario is partially supported by the existing R-interface standards.
B.4.3 IMS Scenarios p. 18
B.4.3.1 IMS Scenario 1 - Headsets p. 1818
This scenario supports simple headsets by locating the IMS client in the MT and simply using the MT as a transducer. The diagram shows a simple headset plugged in to the MT. The headset may be wired or wireless. It is assumed that the headset only supports audio media. Therefore the transducers are in fact split between the MT and the TE.
Support for PCs and PDAs with limited multimedia capabilities may also conform to this model. This is for further study.
Note that on these diagrams the connections show the flow of content (for C-plane entitles "content" is the signalling they use to interact towards the network). Therefore all the internal control relationships are not fully shown. For example the SM&MM obviously interacts with the IPAF and the SIP Client, but this is not shown.
In operational terms this scenario is very similar to an integrated TE/MT. Therefore it does not introduce many new requirements or problems. One item that should be considered though is the security and access control on the TE->MT interface. It is required that:
- Only headsets the user intends to access his or her MT should be able to connect to the MT. A form of access control is required on this interface.
- It should not be possible to record conversations by monitoring the TE-MT interface. Therefore some form of encryption is required if the TE-MT interface is wireless.
B.4.3.2 IMS Scenario 2 - Multimedia TE
This scenario shows a multimedia SIP client and the media coding located in the TE. In this scenario the functions in the MT are essentially the same as those required in the MT for normal packet-data access (clause B.4.2.1). This scenario emphasises the requirement for the MT to effectively support QoS management and efficient mapping of data on to the radio interface.
In order to emphasise the similarity to other data access scenarios the TE has been shown to include a generic IP Data Termination (IPDT) which is outside the scope of IMS. The IPDT has been shown as dotted to indicate it is not part of the IMS components. The IPDT may represent another IP application such as a web browser.
In this scenario important UMTS functions are located outside the MT. This means that the system aspects need to be understood. The most important of these are discussed in the following clauses.
B.4.3.3 IMS Scenario 3 - Multimedia TE without Codecs p. 19
This scenario is intermediate between the other two. It recognises the fact that in the short-term the implementation of media codecs presents special problems for TE hardware. Also the location of codecs outside the MT may complicate the efficient management of the radio interface. Therefore in this model the codecs are located in the MT while the SIP client is contained in the TE.
In this model the requirements and issues are similar to the case above. However some of the complexity in the areas of delay and radio efficiency are avoided. The cost of this simplification is less flexibility in terms of support of new media formats and a system design which is less compatible with other access types.
Figure B.4.3.3-1: IMS Scenario 3 - Support for Multimedia TEs without codecs
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
B.4.4 IMS Security and system integrity p. 19
The TE - MT link needs to include both confidentiality and access control. These security requirements are similar in any UE-split scenario including the IMS-headset scenario described above.
Locating UMTS functions such as the SIP client outside the MT may be seen as introducing other security risks that arise because of malicious or poorly implemented SIP clients, however these security risks exist for non-split UEs as well. The network must therefore be secure against attacks which may result from maliciously modified SIP clients.
It is possible that the client may attempt to attack nodes in the IMS directly. In order to control this the IMS must include adequate firewalling and IP-based security procedures. These functions should be placed in the network rather than the user equipment so that they cannot be tampered with, and so they can be adapted to meet new threats. Because of the IP-based nature of IMS the security of this network from IP-based attacks needs to be considered whether or not IMS clients are implemented in the TE according to the standard.
B.4.5 End to end delay p. 20
End to end delay in IMS scenario 2 is a function of many factors. These includes the hardware on the TE, the codecs in the TE, the mapping of data over the TE-MT interface and the UMTS radio interface. In order to ensure that system-wide delay is managed it is important that:
This scenario is not necessarily less radio efficient than other IMS scenarios provided that:
- The total maximum end-to-end delay limits are defined in 3GPP
- A delay budget is created showing the maximum contribution to the delay at each point in the network
- The technical design of the standard takes in to account delay aspects, and that the interfaces are created in a way where both the theoretical and practical delay consequences are compatible with the delay budget.
- Approved implementations are tested to ensure they meet delay requirements.
- The MT has sufficient information about the different IP streams it is transporting to map then on to the correct radio access bearer, and
- The IP header compression mechanism on the radio interface supports header stripping and reassembly to support the transparency of the service.
$ Change history p. 21
