Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 33.127  Word version:  18.2.0

Top   Top   Up   Prev   Next
0…   5…   5.4…   5.6…   5.7…   6…   6.2.2…   6.2.3…   6.2.5…   6.3…   6.3.3…   6.3.4…   6.4…   7…   7.3…   7.4…   7.4.7…   7.5…   7.6…   7.7…   7.8…   7.9…   7.10…   7.11…   7.12…   7.13…   7.14…   7.15…   7.16…   8…   A…   A.2…   A.3…   A.4…   B…   D…   E… 
7.13 RCS  7.13.1 Background  7.13.2 Architecture  7.13.2.1 Overview  7.13.2.2 Deployment options  7.13.2.2.1 Implementations without a third party registration to the RCS Server  7.13.2.2.2 Implementations that have a Localisation Function  7.13.3 Target identities  7.13.4 IRI events  7.13.4.1 General RCS IRI events  7.13.4.2 RCS events for topologies without a third party registration to the RCS Server  7.13.4.3 RCS events for topologies utilising a Localisation Function 
...

 

7.13  RCS |R17|  p. 120

7.13.1  Background  p. 120

Rich Communication Suite (RCS) is the platform that enables the delivery of communication experiences beyond voice and SMS, providing consumers with a number of services related to:
  • Capability discovery for enhanced contacts information.
  • Standalone messaging:
    • Pager mode.
    • Large message mode.
  • Chat:
    • 1-to-1.
    • Group chat.
  • File URL transfer for enhanced messaging.
  • Upload and download of files through HTTP Content Server.
RCS also covers additional services related to enriched calls. LI for these additional services is not defined in the present document.
As RCS requires the IMS to enable communication between RCS clients, the LI capabilities, requirements and architecture build on those defined for IMS in clause 7.4.
For additional details on LI for specific RCS services, see Annex D.
Up

7.13.2  Architecture  p. 121

7.13.2.1  Overview  p. 121

The capabilities defined in this clause and the following subclauses apply to the LI for RCS. The LI architecture and functionality for RCS builds on the LI capabilities defined for IMS (see clause 7.4). When LI for RCS is required, the LI functions in IMS are provisioned as described in clause 7.4.
The network functions involved in providing the interception of RCS events are determined based on the deployment option, the network configuration, LI service scope and the RCS communication type. In general, the LI functions involved in the interception of RCS events are located either in the IMS core or in RCS specific network functions.
Additional topology options for RCS are described in clause 7.13.2.2.
The present document refers to any server that provides support, services or functions for RCS as an RCS Server. In general, RCS Servers are IMS Application Servers. The HTTP Content Server supports file upload, URI generation, and file download to allow for the transfer of files over RCS.
The following sub-clauses contain general stage 2 details for LI for RCS.
The RCS Servers shall have LI capabilities to generate xIRI records and xCC when RCS events related to the target UE are handled. The HTTP Content Server shall have LI capabilities to generate xIRI records and xCC when the target UE uploads or downloads a file and when any user downloads a file previously uploaded by a target. If an IRI-TF or CC-TF is required, the relevant RCS Server shall have the CC-TF. The Figure 7.13.2-1 gives a reference point representation of the LI architecture for RCS interception.
Copy of original 3GPP image for 3GPP TS 33.127, Fig. 7.13.2-1: LI architecture for RCS services
Figure 7.13.2-1: LI architecture for RCS services
(⇒ copy of original 3GPP image)
Up
The LICF present in the ADMF receives the warrant from an LEA, derives the intercept information from the warrant and provides it to the LIPF.
The LIPF present in the ADMF provisions the IRI-POI present in each RCS Server, the IRI-TF in the relevant RCS Servers, the MDF2 and the MDF3 over the LI_X1 interfaces.
If the authentication method used to authenticate at the HTTP Content Server uses a permanent identifier, the LIPF present in the ADMF also provisions the IRI-POI in the HTTP Content Server.
To enable the interception of the target's message contents (e.g. when the warrant requires the interception of communication contents), the CC-POI in each RCS Server and the CC-TF present in the relevant RCS Servers are also provisioned with the intercept data.
If the authentication method used to authenticate at the HTTP Content Server uses a permanent identifier and the interception of the target's communication contents is required, the LIPF present in the ADMF also provisions the CC-POI in the HTTP Content Server.
The IRI-POI present in the relevant RCS Server detects RCS registration and deregistration; session establishment, modification, and deletion; and message related events, generates and delivers the related xIRI to the MDF2 over LI_X2. The MDF2 delivers the IRI messages to the LEMF over LI_HI2.
When the IRI-TF present in the RCS Server detects a URI for file transfer, the IRI-TF present in the RCS Server sends a trigger to the IRI-POI in the HTTP Content Server over the LI_T2 interface.
The IRI-POI present in the HTTP Content Server detects file uploads or downloads, generates and delivers the related xIRI to the MDF2 over LI_X2. The MDF2 delivers the IRI messages to the LEMF over LI_HI2.
When interception of communication contents is required, the CC-POI present in the relevant RCS Server generates the xCC from RCS messages and delivers the xCC (that includes the correlation number and the target identity) to the MDF3. The MDF3 delivers the CC to the LEMF over LI_HI3.
When interception of communication contents is required, the CC-TF present in the RCS Servers sends a trigger to the CC-POI present in the HTTP Content Server over the LI_T3 interface.
The trigger sent from the IRI-TF to the IRI-POI or the CC-TF to the CC-POI includes the following information:
  • File detection rules.
  • Target identity.
  • Correlation information.
  • MDF3 address.
The CC-POI present in the HTTP Content Server generates the xCC from the uploaded file and delivers the xCC (that includes the correlation number and the target identity) to the MDF3. The MDF3 delivers the CC to the LEMF over LI_HI3.
Up

7.13.2.2  Deployment options  p. 122

7.13.2.2.1  Implementations without a third party registration to the RCS Server  p. 122
As a deployment option, the S-CSCF may not perform a third party registration with the RCS Server. In this case, in addition to the architecture information in clause 7.13.2.1, the IRI-POI present in the IMS Signalling Function detects RCS registration and deregistration, generates and delivers the related xIRI to the MDF2 over LI_X2.
Up
7.13.2.2.2  Implementations that have a Localisation Function  p. 123
As a deployment option, the terminating CSP may utilize a Localisation Function which retrieves objects from the originating HTTP Content Server and makes the same available to the terminating user.
If the CSP implements a Localisation Function, in addition to the architecture information in clause 7.13.2.1, the following requirements apply.
The LI architectue for the Localisation Function is the same as the LI architecture for the HTTP Content Server depicted in Figure 7.13.2-1. In other words, the Localisation Function also has:
  • An IRI-POI with:
    • An LI_T2 interface to the IRI-TF in the RCS Server.
    • An LI_X1 interface to the LIPF.
    • An LI_X2 interface to the MDF2.
  • A CC-POI with:
    • An LI_T3 interface to the CC-TF in the RCS Server.
    • An LI_X1 interface to the LIPF.
    • An LI_X3 interface to the MDF3.
When the IRI-TF present in the RCS Server detects a URI for an incoming file transfer, the IRI-TF present in the RCS Server sends a trigger to the IRI-POI in the Localisation Function over the LI_T2 interface. When interception of communication contents is required, the CC-TF present in the RCS Servers sends a trigger to the CC-POI present in the Localisation Function over the LI_T3 interface. The trigger sent from the TF to the POI includes the following information:
  • File detection rules.
  • Target identity.
  • Correlation information.
  • MDF2 (for xIRI) or MDF3 (for xCC) address.
If the authentication method used to authenticate at the Localisation Function uses a permanent identifier (see clause 7.13.3), the LIPF present in the ADMF also provisions the IRI-POI in the Localisation Function.
In both cases, the IRI-POI present in the Localisation Function detects file uploads or downloads, generates and delivers the related xIRI to the MDF2 over LI_X2. The MDF2 delivers the IRI messages to the LEMF over LI_HI2.
If the authentication method used to authenticate at the file localisation sever uses a permanent identifier and the interception of the target's communication contents is required, the LIPF present in the ADMF also provisions the CC-POI in the Localisation Function.
If the interception of communications content is required, the CC-POI present in the Localisation Function generates the xCC from the uploaded file and delivers the xCC (that includes the correlation number and the target identity) to the MDF3. The MDF3 delivers the CC to the LEMF over LI_HI3.
Up

7.13.3  Target identities  p. 123

The LIPF present in the ADMF provisions the intercept information associated with the following target identities to the IRI-POI, IRI-TF, CC-POI and CC-TF present in the RCS Server:
  • IMPU.
  • IMPI.
  • IMEI.
In addition to the target identifiers listed above, the LIPF present in the ADMF provisions the intercept information associated with the following target identities to the IRI-POI and CC-POI present in the HTTP Content Server and the IRI-POI and CC-POI present in the Localisation Function:
  • IMSI.
  • SUPI.
  • GPSI.
  • Email Address.
The interception performed on identities above are mutually independent, even though an xIRI may contain the information about the other identities when available. The IRI-POI and CC-POI present in the RCS Servers and HTTP Content Servers shall also support interception of non-local identities in any of the IMPU formats (SIP URI, TEL URI as well as the E.164 number in a SIP URI or TEL URI), GPSI formats (E.164 number, external identifier) and email address.
Up

7.13.4  IRI events  p. 124

7.13.4.1  General RCS IRI events  p. 124

As described in clause 7.13.2, the term RCS Server in the present document refers to any server performing support, services or functions for RCS. In most deployments there will be more than one RCS Server, and the events listed below shall be intercepted in the server responsible for performing the functions described by the event.
The IRI-POI present in the RCS Servers shall generate xIRI when it detects the following specific events or information:
  • Registration.
  • Deregistration.
  • Capability discovery.
  • RCS message.
  • RCS message report.
  • Session establishment.
  • Session modification.
  • Session release.
  • Group chat establishment.
  • Group chat modification.
  • Group chat release.
  • Start of interception with already registered UE.
  • Start of interception with already established session.
  • Unsuccessful procedure.
The IRI-POI present in the HTTP Content Server shall generate xIRI when it detects the following specific events or information:
  • File upload.
  • File download.
  • Unsuccessful procedure.
The registration xIRI is generated when the IRI-POI present in an RCS Server detects that a target UE has been registered for RCS services.
The deregistration xIRI is generated when the IRI-POI present in an RCS Server detects that a target UE has been deregistered from RCS services.
The capability discovery xIRI is generated when the IRI-POI present in the RCS Server detects that a target UE has updated the target UE's RCS capabilities. This xIRI is also generated when a target UE gets information about the capabilities and state of another RCS user.
The RCS message xIRI is generated when the IRI-POI present in an RCS Server detects that a target UE sends or receives an RCS message.
The RCS message report xIRI is generated when the IRI-POI present in an RCS Server detects that a target UE sends or receives a response to an RCS message.
The session establishment xIRI is generated when the IRI-POI present in an RCS Server detects that an RCS session has been created for a target UE.
The session modification xIRI is generated when the IRI-POI present in an RCS Server detects that an RCS session has been modified for a target UE.
The session release xIRI is generated when the IRI-POI present in an RCS Server detects that an RCS session has been released for a target UE.
The group chat establishment xIRI is generated when the IRI-POI present in an RCS Server detects that the target UE has joined an RCS group chat session.
The group chat modification xIRI is generated when the IRI-POI present in an RCS Server detects that a group chat session the target UE is participating in is modified.
The group chat release xIRI is generated when the IRI-POI present in an RCS Server detects that the target UE leaves a group chat session.
The start of interception with already registered UE xIRI is generated when the IRI-POI present in an RCS Server detects that interception is activated on the target UE that is already registered for RCS services.
The start of interception with an established RCS session xIRI is generated when the IRI-POI present in an RCS Server detects that interception is activated on a target UE that has an already established RCS session. When a target UE has multiple RCS sessions, this xIRI shall be sent for each RCS session with a different value of correlation information.
When additional warrants are activated on a target UE, MDF2 shall be able to generate and deliver the start of interception with already registered UE and start of interception with already established RCS session related IRI messages to the LEMF associated with the warrants without receiving the corresponding xIRI.
The file upload xIRI shall be generated when the IRI-POI in the HTTP Content Server detects that a target UE has uploaded a file or when any UE has uploaded a file destined for the target UE.
The file download xIRI shall be generated when the IRI-POI in the HTTP Content Server detects that a target UE has downloaded a file or when any UE has downloaded a file previously uploaded by a target UE.
The unsuccessful procedure xIRI is generated when the IRI-POI present in an RCS Server or HTTP Content Server detects that a target UE initiated communication procedure (e.g. session establishment, RCS Message) is rejected or not accepted by the RCS Server before the proper NF handling the procedure itself is involved. The unsuccessful procedure xIRI is also generated when the IRI-POI present in the RCS Server or HTTP Content Server detects that any request from the target UE is not accepted by the RCS Server or HTTP Content Server.
Up

7.13.4.2  RCS events for topologies without a third party registration to the RCS Server  p. 125

The events specified in clause 7.13.4.1 apply with the following changes:
Rather than the IRI-POI present in the RCS Servers, the IRI-POI present in the IMS Signalling Function shall generate xIRI when it detects the following specific events or information:
  • Registration.
  • Deregistration.
The registration xIRI is generated when the IRI-POI present in the IMS Signalling Function detects that a target UE has been registered for RCS services.
The deregistration xIRI is generated when the IRI-POI present in the IMS Signalling Function detects that a target UE has been deregistered from RCS services.
Up

7.13.4.3  RCS events for topologies utilising a Localisation Function  p. 126

The events specified in clause 7.13.4.1 apply with the following changes:
In addition to the IRI-POI present in the HTTP Content Server (as described in clause 7.13.4.1), the IRI-POI present in the Localisation Function shall generate xIRI when it detects the following specific events or information:
  • File upload.
  • File download.
  • Unsuccessful procedure.
The file upload xIRI shall be generated when the IRI-POI in Localisation Function detects that a target UE has uploaded a file or when any UE has uploaded a file destined for the target UE.
The file download xIRI shall be generated when the IRI-POI in the Localisation Function detects that a target UE has downloaded a file or when any UE has downloaded a file previously uploaded by a target UE.
The unsuccessful procedure xIRI is generated when thi IRI-POI present in the Localisation Function detects that any request from the target UE is not accepted by the Localisation Function.
Up

Up   Top   ToC