5.19 RACS information provisioning procedures

23.6823GPPArchitecture enhancements to facilitate communications with packet data networks and applicationsRelease 17TS

5.19.1 General

This clause specifies procedures for provisioning of UCMF with RACS related information from SCS/AS, either via SCEF or directly. Specification of these procedures does not preclude other methods of UCMF provisioning being used, e.g. O&M.

5.19.2 RACS information provisioning procedures via SCEF

This procedure is used by SCS/AS to add, update or delete UE radio access capability entries in the UCMF using the protocol specified in TS 29.122 [44] for the SCEF northbound API and the protocol defined in TS 29.675 [49] for the UCMF northbound API. Figure 5.19.2-1 illustrates the procedure.

Figure 5.19.2-1: RACS information provisioning procedure via SCEF

1. The SCS/AS sends a Radio Capability Entry Request ((list of) UE Radio Capability ID(s), UE radio access capability(s) set with its coding format(s) for each UE radio Capability ID, one (list of) IMEI/TAC values(s) for each UE Radio Capability ID, action) message to the SCEF. The action indicates add/modify/delete operation for the UE Radio Capability ID and UE radio access capability.

NOTE: The UE radio access capability for each UE radio Capability ID can be in one coding format or both the coding formats as defined in TS 36.331 [50] or TS 38.331 [51].

2. The SCEF may check whether the UE Radio Capability ID is within the allowed list of manufacturers according to local policy. If the checking fails, step 6 is executed with error response.

3. The SCEF sends a Radio Capability Entry Request ((list of) UE Radio Capability ID(s), UE radio access capability(s) set with its coding format(s) for each UE radio Capability ID, one (list of) IMEI/TAC values(s) for each UE Radio Capability ID, action) message to the UCMF.

4. The UCMF creates, updates or deletes the UE radio access capability entry (or entries) for the indicated UE Radio Capability ID(s). The UCMF shall ensure that for the same UE Radio Capability ID, only one UE radio access capability entry in one or both the coding formats exists.

5. The UCMF sends a Radio Capability Entry Response (Cause) message to the SCEF.

6. The SCEF sends a Radio Capability Entry Response (Cause) message to the SCS/AS.

5.19.3 RACS information provisioning procedures via T9a

This procedure is used by SCS/AS to add, update or delete UE radio access capability entries in the UCMF using the protocol defined in TS 29.675 [49]. Figure 5.19.3-1 illustrates the procedure.

Figure 5.19.3-1: RACS information provisioning procedure via T9a

1. The SCS/AS sends a Radio Capability Entry Request ((list of) UE Radio Capability ID(s), UE radio access capability(s) set with its coding format(s) for each UE radio Capability ID, one (list of) IMEI/TAC values(s) for each UE Radio Capability ID, action) message to the UCMF. The action indicates add/modify/delete operation for the UE Radio Capability ID and UE radio access capability.

NOTE: The UE radio access capability for each UE radio Capability ID can be in one coding format or both the coding formats as defined in TS 36.331 [50] or TS 38.331 [51].

2. The UCMF creates, updates or deletes the UE radio access capability entry (or entries) for the indicated UE Radio Capability ID(s). The UCMF shall ensure that for the same UE Radio Capability ID, only one UE radio access capability entry in one or both the coding formats exists.

3. The UCMF sends a Radio Capability Entry Response (Cause) message to the SCS/AS.

Annex A (informative):
MTC Deployment Scenarios

In the indirect and hybrid models, the deployment of a SCS may be inside or outside the operator domain as illustrated in figures A-1 and A-2. When the SCS is part of the operator domain (figure A-1 C and figure A-2), the SCS is considered a mobile operator internal network function, is operator controlled, and may provide operator value-added services. In this case, security and privacy protection for communication between the MTC-IWF and SCS is optional. When the SCS is deployed outside the operator domain (figure A-1 B and A-2), the SCS is MTC Service Provider controlled. In this case, security and privacy protection for communication between the MTC-IWF and SCS is needed. In the direct model (figure A-1 A), there may not be an external or internal SCS in the communication path.

Figure A-1: Deployment scenarios for direct and indirect model

Figure A-2: Deployment scenarios for hybrid model

An operator may deploy the hybrid model with a combination of no internal and external SCS (as in the Direct Model) and internal and/or external SCS (as in the Indirect Model). As shown in Figure A-2, a UE may be in communications with multiple SCSs in an HPLMN which can be made up of a combination of operator controlled and MTC service provider controlled SCSs. In that scenario, the MTC Service provider controlled SCS, and the 3GPP operator controlled SCS may offer different capabilities to the MTC Applications.

Though not illustrated, it is also possible that the deployment of an AS may be inside the operator domain and under operator control.

Annex B (informative):
Void

Annex C (informative):
Triggering with OMA Push