7 ENVELOPE Commands
31.1113GPPRelease 18TSUniversal Subscriber Identity Module (USIM) Application Toolkit (USAT)
7.1 Data download to UICC
7.1.1 SMS-PP data download
7.1.1.1 Procedure
If the service "data download via SMS Point-to-point" is allocated and activated in the USIM Service Table (see TS 31.102 [14]), then the ME shall follow the procedure below:
– when the ME receives a Short Message with:
protocol identifier = SIM data download; and
data coding scheme = class 2 message; or
– when the ME receives a Short Message with:
protocol identifier=ANSI-136 R-DATA (see TS 23.040 [5]); and
data coding scheme = class 2 message, and the ME chooses not to handle the message (e.g. MEs not supporting EGPRS over TIA/EIA-136 do not need to handle the message).
– then the ME shall pass the message transparently to the UICC using the ENVELOPE (SMS-PP DOWNLOAD) command as defined in clause 7.1.1.2;
– the ME shall not display the message, or alert the user of a short message waiting;
– the ME shall wait for an acknowledgement from the UICC;
– When receiving a secured Command Packet (as specified in TS 31.115 [41]) requesting a Proof of Receipt (PoR), the UICC shall verify the authenticity of the sender. If the authentication of the sender fails, no further processing related to the Proof of Receipt shall take place.
– if the UICC responds with ’90 00′ or ‘6F XX’ or ’62 XX’ or ’63 XX’, the ME shall acknowledge the receipt of the short message to the network using an RP-ACK message. The response data from the UICC will be supplied by the ME in the TP-User-Data element of the RP-ACK message it will send back to the network (see TS 23.040 [5] and TS 24.011 [10]). The values of protocol identifier and data coding scheme in RP-ACK shall be as in the original message;
– if the UICC responds with ’93 00′, the ME shall either retry the command or send back an RP-ERROR message to the network with the TP-FCS value indicating ‘SIM Application Toolkit Busy’ (see TS 23.040 [5]).
If the service "data download via SMS-PP" is not available in the USIM Service Table, and the ME receives a Short Message with the protocol identifier = SIM data download and data coding scheme = class 2 message, then the ME shall store the message in EFSMS in accordance with TS 31.102 [14].
7.1.1.1a Procedure for SMS-PP data download via REGISTRATION ACCEPT or DL NAS TRANSPORT messages
If the service "data download via SMS Point-to-point" is allocated and activated in the USIM Service Table (see 3GPP TS 31.102 [14]), then the ME shall follow the procedure below:
– when the ME receives a:
– REGISTRATION ACCEPT message or a DL NAS TRANSPORT message that includes an SOR transparent container information element with list type with value "0"= secured packet; or
– DL NAS TRANSPORT message that includes a UE parameters update transparent container containing a UE parameters update data set with UE parameters update data set type with value "1"=Routing Indicator update data
– containing a secured packet constructed as a single SMS-Deliver TPDU or concatenation of several SMS-Deliver TPDUs (as specified in 3GPP TS 23.040 [5]) with:
protocol identifier = SIM data download; and
data coding scheme = class 2 message;
– and the integrity check of the message was successful.
– then the ME shall pass the message(s) transparently to the UICC using the ENVELOPE (SMS-PP DOWNLOAD) command as defined in clause 7.1.1.2;
– the ME shall not display or alert the user;
– the secured packet is coded as a Command Packet formatted as Short Message Point to Point (as specified in 3GPP TS 31.115 [41]).
NOTE: The command packet should not request a Proof of Receipt (PoR).
7.1.1.2 Structure of ENVELOPE (SMS-PP DOWNLOAD)
Direction: ME to UICC.
The command header is specified in TS 31.101 [13].
Command parameters/data:
|
Description |
Clause |
M/O/C |
Min |
Length |
|
SMS-PP download tag |
9.1 |
M |
Y |
1 |
|
Length (A+B+C+D+E) |
– |
M |
Y |
1 or 2 |
|
Device identities |
8.7 |
M |
Y |
A |
|
Address |
8.1 or 8.108 |
C(see note2) |
N(see note1) |
B |
|
URI truncated |
8.135 |
C |
N |
C |
|
SMS TPDU (SMS-DELIVER) |
8.13 |
M |
Y |
D |
|
Originating Address |
8.108 |
C |
N (see note1) |
E |
|
NOTE1: The UICC shall be able to manage the situation when the address field is not present, in order to ensure backwards compatibility with previous releases of this specification. NOTE2: The address data object shall not be present when SMS-PP data download is transporting SOR transparent container information element received from REGISTRATION ACCEPT or DL NAS TRANSPORT message as such message does not contain the address of a service center. |
||||
– Device identities: the ME shall set the device identities to:
– source: Network;
– destination: UICC.
– Address: The address data object holds the RP_Originating_Address of the Service Centre (TS‑Service-Centre-Address), as defined in 3GPP TS 24.011 [10]. If the USIM or the ISIM Service Table indicates URI support for SMS-PP DOWNLOAD, then this address data object may contain the Public Service Identity of the Service Center. If the URI is longer than the maximum length that can be transmitted to the UICC, then the URI shall be truncated to the maximum length that can be transmitted to the UICC and the request shall contain a URI truncated tag.
– Originating Address: If the USIM or the ISIM Service Table indicates URI support for SMS-PP DOWNLOAD, then the Originating Address data object may be present and contain the Public Identity (IMPU) of the sender of the short message. If the URI is longer than the maximum length that can be transmitted to the UICC, then the Originating Address data object shall not be sent.
Response parameters/data.
It is permissible for the UICC not to provide response data. If the UICC provides response data, the following data is returned.
|
Byte(s) |
Description |
Length |
|
1‑X (X128) |
UICC Acknowledgement |
X |
7.1.2 Cell Broadcast data download
7.1.2.1 Procedure
If the service "data download via SMS-CB" is available in the USIM Service Table (see TS 31.102 [14]), then the ME shall follow the procedure below:
– when the ME receives a new Cell Broadcast message, the ME shall compare the message identifier of the Cell Broadcast message with the message identifiers contained in EFCBMID;
– In the case of a GSM Cell Broadcast message, if the message identifier is found in EFCBMID, the cell broadcast page is passed to the UICC using the ENVELOPE (CELL BROADCAST DOWNLOAD) command, defined below. The ME shall not display the message;
– In the case of a UMTS Cell Broadcast message, if the message identifier is found in EFCBMID, the ME shall deconstruct the UMTS Cell Broadcast message Parameter into its Cell Broadcast pages, and reconstruct each page in the format of the GSM Cell Broadcast Message Parameter, as described below, and according to the definition of the Cell Broadcast message structure in TS 23.041[6]:
1) From the Number-of-Pages byte of the UMTS message, the ME shall obtain the number of Cell Broadcast pages to be constructed.
2) For each page the ME shall reconstruct GSM Cell Broadcast Page header as follows:
– The 2-byte Serial Number of the UMTS message shall be mapped to the reconstructed GSM message Serial Number.
– The 2-byte Message ID of the UMTS message shall be mapped to the reconstructed GSM message Message ID.
– The 1-byte Data Coding Scheme of the UMTS message shall be mapped to the reconstructed GSM message Data Coding Scheme.
– The 1-byte Number-Of-Pages of the UMTS message in combination with the current page’s sequence number (based on the order of the pages in the UMTS message) shall be formatted into the reconstructed GSM message Page Parameter byte, as described in TS 23.041[6].
– The respective 82 byte CBS-Message-Information-Page shall be mapped to the reconstructed GSM message content.
Table: Cell Broadcast Message Parameter Element mapping
|
Network – ME (UMTS Cell Broadcast Message) |
ME-USAT interface (GSM Cell Broadcast Message Format) |
|
Message ID |
Message ID |
|
Serial Number |
Serial Number |
|
Data Coding Scheme |
Data Coding Scheme |
|
Number-Of –Pages |
Page Parameter (Note) |
|
CBS-Message-Information-Page |
Content of Message |
NOTE: The Page Parameter byte is constructed from the total number of pages as indicated in the UMTS CB message, in combination with the current page’s sequence number (based on the order of the pages in the UMTS message).
– Each of the resulting pages shall then be passed to the UICC using the ENVELOPE (CELL BROADCAST DOWNLOAD) command, defined below. The ME shall not display the message;
– if the message identifier of the incoming cell broadcast message is not found in EFCBMID, then the ME shall determine if the message should be displayed, by following the procedures in TS 23.041 [6] and TS 31.102 [14].
– if the UICC responds with ’93 00′, the ME shall consider that the Cell Broadcast page has not been delivered successfully. The ME may retry to deliver the same Cell Broadcast page.
The ME shall identify new cell broadcast pages by their message identifier, serial number and page values.
7.1.2.2 Structure of ENVELOPE (CELL BROADCAST DOWNLOAD)
Direction: ME to UICC.
The command header is specified in TS 31.101 [13].
Command parameters/data.
|
Description |
Clause |
M/O/C |
Min |
Length |
|
Cell Broadcast Download tag |
9.1 |
M |
Y |
1 |
|
Length (A+B) |
– |
M |
Y |
1 or 2 |
|
Device identities |
8.7 |
M |
Y |
A |
|
Cell Broadcast page |
8.5 |
M |
Y |
B |
– Device identities: the ME shall set the device identities to:
– source: Network;
– destination: UICC.
Response parameters/data: None for this type of ENVELOPE command.
7.2 Menu Selection
See ETSI TS 102 223 [32] clause 7.2.
If the UICC responds with ’93 00′, the ME shall not re‑issue this particular envelope.
7.3 Call Control and MO SMS control by USIM
7.3.1 Call Control by USIM
7.3.1.1 Procedure for mobile originated calls
If the service "call control" is available in the USIM Service Table (see TS 31.102 [14]), then the ME shall follow the procedure described in ETSI TS 102 223 [32] clause 7.3.1.1 with the additional rules listed here:
– when the user is dialling "112" or an emergency call code stored in EFECC, the ME shall set up an emergency call instead of passing the call set-up details to the UICC;
– if the UICC provides response data, then in addition to the response data listed by ETSI TS 102 223 [32] clause 7.3.1.6, the response data from the UICC may indicate to the ME to send instead a supplementary service or USSD operation using the data supplied by the UICC. It is then mandatory for the ME to perform the supplementary service or USSD operation in accordance with the data from the UICC, if it is within the ME’s capabilities to do so. If the UICC requires a supplementary service or USSD operation that is beyond the ME’s capabilities, then the ME shall not perform the supplementary service or USSD operation at all.
– If, as a result of the procedure, the UICC supplies a number stored in EFECC, this shall not result in an emergency call.
This procedure is applicable also in the case where the call is originated over IMS and the service "communication control for IMS by USIM" is not available in the USIM Service Table (see TS 31.102 [14]). If the call is originated over IMS and the service "communication control for IMS by USIM" is available in the USIM Service Table, only the procedure for IMS communications establishment (clause 7.3.1.9) shall be used.
In the case where the initial call set-up request results from a proactive command SET UP CALL:
– if the call control result is "not allowed", the ME shall inform the UICC using TERMINAL RESPONSE "interaction with call control by USIM or MO short message control by USIM, permanent problem; action not allowed";
– if the call set-up request is changed by call control in a supplementary service or USSD operation, and if the supplementary service or USSD operation is within the ME’s capabilities, then the ME shall send this request to the network. The ME shall then send back a TERMINAL RESPONSE to the SET UP CALL command at the same time it would have done for the proactive command equivalent to the action requested by call control (i.e. SEND SS or SEND USSD). However, in that case, the TERMINAL RESPONSE shall contain the response data given in the response to ENVELOPE (CALL CONTROL) and a second Result TLV identical to the one given in response to the proactive command equivalent to the action requested by call control (i.e. SEND SS or SEND USSD). The mapping between the general result in the first Result TLV and the general result in the second Result TLV is given below:
the general result "command performed, but modified by call control by USIM" shall be given in the first Result TLV if the general result of the second Result TLV is ‘0X’ or ‘1X’;
the general result "interaction with call control by USIM, temporary problem" shall be given in the first Result TLV if the general result of the second Result TLV is ‘2X’;
the general result "interaction with call control by USIM or MO short message control by USIM, permanent problem" shall be given in the first Result TLV if the general result of the second Result TLV is ‘3X’;
– if the call set-up request is changed by call control into a supplementary service or USSD operation, and if the supplementary service or USSD operation is beyond the ME’s capabilities, then the ME shall send back a TERMINAL RESPONSE to the SET UP CALL command, without performing the supplementary service or USSD operation at all. In that case, the TERMINAL RESPONSE shall contain the response data given in the response to ENVELOPE (CALL CONTROL) and a second Result TLV identical to the one given in response to the proactive command equivalent to the action requested by call control (i.e. SEND SS or SEND USSD). The mapping between the general result in the first Result TLV and the general result in the second Result TLV is given below:
the general result "interaction with call control by USIM or MO short message control by USIM, permanent problem" shall be given in the first Result TLV, and the general result "command beyond ME’s capabilities" shall be given in the second Result TLV.
The ME shall then follow the call set-up procedure defined in TS 24.008 [9] or the supplementary service or USSD operation procedure defined in TS 24.080 [11].
7.3.1.2 Procedure for Supplementary Services and USSD
If the service "call control" is available in the USIM Service Table (see TS 31.102 [14]), then for all supplementary service and USSD operations (including those resulting from a SEND SS or SEND USSD proactive UICC command), the ME shall first pass the supplementary service or USSD control string (corresponding to the supplementary service or USSD operation and coded as defined in TS 22.030 [2], even if this SS or USSD operation has been performed via a specific menu of the ME) to the UICC, using the ENVELOPE (CALL CONTROL) command defined below. The ME shall also pass to the UICC in the ENVELOPE (CALL CONTROL) command the current serving cell.
The UICC shall respond in the same way as for mobile originated calls. The ME shall interpret the response as follows:
– if the UICC responds with ’90 00′, the ME shall send the supplementary service or USSD operation with the information as sent to the UICC;
– if the UICC responds with any status code indicating an error, the ME shall not send the supplementary service or USSD;
– if the UICC responds with ’93 00′, the ME shall not send the supplementary service or USSD operation and may retry the command;
– if the UICC provides response data, then the response data from the UICC shall indicate to the ME whether to send the supplementary service or USSD operation as proposed, not send the SS or USSD operation, send the SS or USSD operation using the data supplied by the UICC, or instead set up a call using the data supplied by the UICC. It is mandatory for the ME to perform the supplementary service or USSD operation or the call set-up request in accordance with the data from the UICC, if it is within the ME’s capabilities to do so. If the UICC requires a call set-up or supplementary service or USSD operation that is beyond the ME’s capabilities (e.g. the UICC maps a USSD operation to a data call, and the ME does not support data calls), then the ME shall not the perform the call set-up request or supplementary service or USSD operation at all.
In the case where the initial SS or USSD request results from a proactive command SEND SS or SEND USSD:
– if the call control result is "not allowed", the ME shall inform the UICC using TERMINAL RESPONSE ("interaction with call control by USIM or MO short message control by USIM, permanent problem; action not allowed");
– if the SS or USSD request is changed by call control in a call set-up request, then the ME shall set up the call using the data given by the UICC, if it is within the ME’s capabilities to do so. If the UICC requires a call set-up that is beyond the ME’s capabilities (e.g. the UICC maps a USSD operation to a data call, and the ME does not support data calls), then the ME shall not set up the call at all. The ME shall send back a TERMINAL RESPONSE to the initial proactive command at the same time it would have done for the proactive command equivalent to the action requested by call control (i.e. SET UP CALL). However, in that case, the TERMINAL RESPONSE shall contain the response data given in the response to ENVELOPE (CALL CONTROL) and a second Result TLV identical to the one given in response to the proactive command equivalent to the action requested by call control (i.e. SET UP CALL). The mapping between the general result in the first Result TLV and the general result in the second Result TLV is the same as the one described in clause 7.3.1.1.
If the ME supports the Outgoing Call Information service, the ME shall update EFOCI with the supplementary service or USSD control string corresponding to the initial user request.
The ME shall then follow the supplementary service or USSD operation procedure defined in TS 24.080 [11] or the call set-up procedure defined in TS 24.008 [9].
7.3.1.3 Indication to be given to the user
The UICC may optionally include an alpha-identifier in the response data to the ENVELOPE (CALL CONTROL) message, in order to inform the user at the time the response is received by the ME. The use of this alpha identifier by the ME is described below:
– if the UICC responds with "allowed, no modification", then:
if the alpha identifier is provided by the UICC and is not a null data object, the ME shall use it to inform the user during the PDP/PDN context activation, PDU session establishment or call set-up;
if the alpha identifier is provided by the UICC and is a null data object (i.e. length = ’00’ and no value part), this is an indication that the ME should not modify the display corresponding to the initial user request;
if the alpha identifier is not provided by the UICC, the ME may give information to the user concerning what is happening;
– if the UICC responds with "not allowed", then:
if the alpha identifier is provided by the UICC and is not a null data object, the ME shall use it to inform the user. This is also an indication that the ME should not give any other information to the user on the reason of the barring;
if the alpha identifier is provided by the UICC and is a null data object (i.e. length = ’00’ and no value part), the ME may give information to the user concerning what is happening;
if the alpha identifier is not provided by the UICC, the ME may give information to the user concerning what is happening.
– if the UICC responds with "allowed, with modifications", and the modified request is within the ME’s capabilities, then:
if the alpha identifier is provided by the UICC and is not a null data object, the ME shall use it to inform the user. The ME shall then not display the destination address or SS string given by the UICC. This is also an indication that the ME should not give any other information to the user on the changes made by the UICC to the initial user request;
if the alpha identifier is provided by the UICC and is a null data object (i.e. length = ’00’ and no value part), this is an indication that the ME should not give any information to the user on the changes made by the UICC to the initial user request. The ME shall not display the destination address or SS string given by the UICC. The ME should not modify the display corresponding to the initial user request;
if the alpha identifier is not provided by the UICC, the ME may indicate to the user that the initial user request has been changed.
– if the UICC responds with "allowed, with modifications" to a user-initiated request (i.e. a request not initiated by a proactive command), and the modified user request is beyond the ME’s capabilities, then the ME may give information to the user on the modified request and the fact that the modified request is beyond the ME’s capabilities, optionally using the alpha identifier, if one is provided by the UICC;
– if the UICC responds with "allowed, with modifications" to a request by a proactive command SET UP CALL, SEND SS, SEND USSD or OPEN CHANNEL where GPRS is selected, and the modified request is beyond the ME’s capabilities, then the ME shall not give any information to the user on the fact that the modified request is beyond the ME’s capabilities, and shall give a TERMINAL RESPONSE to the proactive command (i.e. SET UP CALL, SEND SS, SEND USSD or OPEN CHANNEL) as detailed in clauses 7.3.1.1, 7.3.1.2 and 7.3.1.3. The responsibility to inform the user in this case lies with the UICC application which sent the proactive command.
A terminal of type ND shall ignore any alpha identifier provided together with the response data to the ENVELOPE (CALL CONTROL) message.
7.3.1.4 Interaction with Fixed Dialling Number
The procedure defined in ETSI TS 102 223 [32] clause 7.3.1.4 for calls applies. In addition, it shall apply in the same way for supplementary service operations, the supplementary service control string being checked as if it was a called number.
The ME shall check the number (or the supplementary service control string) in accordance with TS 22.101 [34].
When the called address is an IMS URI, the ME shall check the destination address using the FDN stored in EFFDNURI, in addition to the EFFDN entries, following the same principle as defined in the Fixed Dialling Number description in TS 22.101 [34] applied to URIs, and as described in TS 31.102[14] clause 4.2.97.
7.3.1.5 Support of Barred Dialling Number (BDN) service
The procedure defined in ETSI TS 102 223 [32] clause 7.3.1.5 for calls applies. In addition, it shall apply in the same way for supplementary service operations, the supplementary service control string being checked as if it was a called number.
The ME shall check the number (or the supplementary service control string) in accordance with TS 22.101 [34].
When the called address is an IMS URI, the ME shall check the destination address using the BDN stored in EFBDNURI, in addition to the EFBDN entries, following the same principle as defined in the Barring Dialling Number description in TS 22.101 [34] applied to URIs, and as described in TS 31.102[14] clause 4.2.98.
7.3.1.6 Structure of ENVELOPE (CALL CONTROL)
Direction: ME to UICC.
The command header is specified in TS 31.101 [13].
Command parameters/data.
|
Description |
Clause |
M/O/C |
Min |
Length |
|
Call control tag |
9.1 |
M |
Y |
1 |
|
Length (A+B+C+D+E+F+G+H) |
– |
M |
Y |
1 or 2 |
|
Device identities |
8.7 |
M |
Y |
A |
|
Address or SS string or USSD string or PDP context activation parameters or EPS PDN connection activation parameters or IMS URI or PDU session establishment parameters |
8.1, 8.14 or 8.17 or 8.72 or 8.98 or 8.108 or 8.143 |
M |
Y |
B |
|
Capability configuration parameters 1 |
8.4 |
O |
N |
C |
|
Subaddress |
8.3 |
O |
N |
D |
|
Location information |
8.19 |
C |
N |
E |
|
Capability configuration parameters 2 |
8.4 |
O |
N |
F |
|
Media Type |
8.132 |
C |
N |
G |
|
URI truncated |
8.135 |
C |
N |
H |
– Device identities: the ME shall set the device identities to:
source: ME;
destination: UICC.
– Address or SS string or USSD string or PDP context activation parameters or EPS PDN connection activation parameters or IMS URI or PDU session establishment parameters: only one data object shall be sent to the UICC:
for a call set-up, the address data object is used and holds the Called Party Number, as defined in TS 24.008 [9], to which the ME is proposing setting up the call;
for a supplementary service, the SS string data object is used and holds the corresponding supplementary service;
for a USSD operation, the USSD string data object is used and holds the corresponding USSD control string;
USIM Applications and MEs should take into account that early implementations of USAT use the SS string data object for coding of USSD control strings (instead of the USSD string data object). This behaviour is only possible for USSD control strings consisting of digits (0-9,*,#). The UICC can identify MEs having this early implementation by evaluating the indication "USSD string data object supported in Call Control" in the TERMINAL PROFILE. The ME can identify USIMs having this early implementation by evaluating the indication "USSD string data object supported in Call Control" in the USIM Service Table.
For a PDP context activation, the Activate PDP context request parameters are used, as defined in TS 24.008 [9]. Except for the following parameters:
– Requested QoS;
– Access Point Name; and
– Protocol configuration options,
the UICC should not modify any other parameters included in the ACTIVATE PDP CONTEXT REQUEST message as defined in TS 24.008 [9] to avoid that the UE sends a value of any of these parameters that is not compliant to TS 24.008 [9];
for an EPS PDN connection activation, the PDN Connectivity Request parameters are used, as defined in TS 24.301 [46]. Except for the following parameters:
– Access Point Name; and
– Protocol configuration options,
the UICC should not modify any other parameters included in the PDN CONNECTIVITY REQUEST message as defined in TS 24.301 [46] to avoid that the UE sends a value of any of these parameters that is not compliant to TS 24.301 [46];
for an IMS communication establishment, the IMS Request-URI field is used and the IMS URI data object holds the SIP URI or tel URI, as defined in TS 24.229[52], to which the ME is proposing setting up the communication. If the URI is longer than the maximum length that can be transmitted to the UICC, then the URI shall be truncated to the maximum length that can be transmitted to the UICC and the request shall contain a URI truncated tag.
for a PDU session establishment, the PDU Session Establishment Request parameters are used, as defined in TS 24.501 [70]. Except for the following parameters:
– SM PDU DN request container; and
– operator specific parameters in Extended Protocol configuration options,
the UICC should not modify any other parameters included in the PDU SESSION ESTABLISHMENT REQUEST message as defined in TS 24.501 [70] to avoid that the UE sends a value of any of these parameters that is not compliant to TS 24.501 [70].
– Capability configuration parameters: Only used for a call set-up, this contains the Bearer capabilities that the ME is proposing to send to the network. The first capability configuration parameters corresponds to the bearer capability 1 information element of a mobile originating SETUP message, as defined in TS 24.008 [9]. The second capability configuration parameters correspond to the bearer capability 2 information element of a mobile originating SETUP message, as defined in TS 24.008 [9]. If no capability configuration parameters are present, this shall indicate a speech call.
– Subaddress: Only used for a call set-up, this contains the called party subaddress that the ME is proposing to send to the network. If one is not present, this shall indicate that the ME is proposing not to send this information element to the network.
– Location information: This data object contains the identification (MCC, MNC, LAC/TAC, Cell Identity) of the current serving cell of the UE. The comprehension required flag of this data object in this command shall be set to ‘0’. This data object shall be present if the call is performed over GERAN, UTRAN, E-UTRAN, Satellite E-UTRAN, NG-RAN or Satellite NG-RAN.
– Media Type: This data object indicates the type of media the ME is proposing using to set up the communication. If the type of media to be used by the ME is one of those listed in the Terminal Profile and if the "Media Type support" service is allocated and activated in the USIM or ISIM Service Table, the Media Type data object shall be present.
– URI truncated: This data object indicates that the URI in the request was truncated because too long to be transmitted to the UICC.
Response parameters/data.
It is permissible for the UICC to provide no response data, by responding with SW1/SW2 = ’90 00′. If the UICC does not provide any response data, then this shall have the same meaning as "allowed, no modification".
|
Description |
Clause |
M/O/C |
Min |
Length |
|
Call control result |
– |
M |
Y |
1 |
|
Length (A+B+C+D+E+F+G) |
– |
M |
Y |
1 or 2 |
|
Address or SS string or USSD string or PDP context activation parameters or EPS PDN connection activation parameters or IMS URI or PDU session establishment parameters |
8.1, 8.14 or 8.17 or 8.72 or 8.98 or 8.108 or 8.143 |
O |
N |
A |
|
Capability configuration parameters 1 |
8.4 |
O |
N |
B |
|
Subaddress |
8.3 |
O |
N |
C |
|
Alpha identifier |
8.2 |
O |
N |
D |
|
BC repeat indicator |
8.42 |
C |
N |
E |
|
Capability configuration parameters 2 |
8.4 |
O |
N |
F |
|
Media Type |
8.132 |
O |
N |
G |
– Call control result:
Contents:
– The command that the UICC gives to the ME concerning whether to allow, bar or modify the proposed call (or supplementary service operation);
Coding:
– ’00’ = Allowed, no modification;
– ’01’ = Not allowed;
– ’02’ = Allowed with modifications.
– Address or SS string or USSD string or PDP context/EPS PDN connection activation parameters or IMS URI or PDU session establishment parameters: Only one data object may be included if the UICC requests the call (or supplementary service or USSD operation or PDP context/EPS PDN connection activation or IMS communication establishment or PDU session establishment parameters) details to be modified:
for a call set-up, if the address data object is not present, then the ME shall assume the Dialling number is not to be modified;
if the SS string data object or address data object is present and the ME receives wild values according to TS 31.102 [14], then the ME shall not process the command.
For a supplementary service, if the SS string data object is not present, then the ME shall assume that SS is not to be modified;
for a USSD operation, if the USSD string data object is not present, then the ME shall assume that the USSD operation is not to be modified;
for a PDP context activation, if the PDP context activation parameters object is not present, then the ME shall assume that the PDP context activation is not to be modified;
for an EPS PDN connection activation, if the EPS PDN connection activation parameters object is not present, then the ME shall assume that the EPS PDN connection activation is not to be modified;
for an IMS communication establishment, if the IMS URI data object is not present, then the ME shall assume that neither the SIP URI nor the tel URI are to be modified.
for a PDU session establishment, if the PDU session establishment parameters object is not present, then the ME shall assume that the PDU session establishment is not to be modified.
– Capability configuration parameters: Only used for a call set-up, this data object is only required if the USIM application requests the call details to be modified. The first capability configuration parameters corresponds to the bearer capability 1 information element of a mobile originating SETUP message, as defined in TS 24.008 [9]. The second capability configuration parameters corresponds to the bearer capability 2 information element of a mobile originating SETUP message, as defined in TS 24.008 [9]. If the capability configuration parameters are not present, then the ME shall assume the parameters are not to be modified.
– Subaddress: Only used for a call set-up, this data object is only required if the USIM application requests the call details to be modified. If the subaddress is not present, then the ME shall assume the called party subaddress is not to be modified. If the subaddress supplied by the USIM application is a null data object, then the ME shall not provide a called party subaddress to the network. A null data object shall have length = ’00’ and no value part.
– Alpha identifier: this data object is only required if the UICC requests a particular indication to be given to the user. The handling of this data object by the ME is described in clause 7.3.1.3. The comprehension required flag of this data object shall be set to ‘0’.
– BC repeat indicator: indicates how the associated bearers shall be interpreted. The change of bearer occurs on a network event. This BC repeat indicator is conditioned to the presence of the second capability configuration parameters and is coded as defined in TS 24.008 [9].
– Media Type: this data object is only required if the UICC requests the media type of the call to be modified. If the Media Type is not present then the ME shall assume the media type of the call is not to be modified.
It is mandatory for the UICC to provide at least one of the optional data objects if it has set the Call control result to "allowed with modifications".
7.3.1.7 Procedure for PDP Context Activation
If the service "call control on GPRS by USIM" is available in the USIM Service Table (see TS 31.102 [14]), then for all PDP Context activation (including those resulting from a OPEN CHANNEL proactive UICC command where GPRS is selected), the ME shall first pass the corresponding Activate PDP Context message (see TS 24.008 [9]) to the UICC, using the ENVELOPE (CALL CONTROL) command defined below. The ME shall also pass to the UICC in the ENVELOPE (CALL CONTROL) command the current serving cell.
When the ME performs an emergency PDP context activation, the ME shall not send the ENVELOPE (CALL CONTROL) command to the UICC.
The UICC shall respond in the same way as for mobile originated calls. The ME shall interpret the response as follows:
– if the UICC responds with ’90 00′, the ME shall send the Activate PDP Context message with the information as sent to the UICC;
– if the UICC responds with ’93 00′, the ME shall not the Activate PDP Context message and may retry the command;
– if the UICC provides response data, then the response data from the UICC shall indicate to the ME whether to send the Activate PDP Context message as proposed, not send the Activate PDP Context message or send the Activate PDP Context message using the data supplied by the UICC. It is mandatory for the ME to perform the PDP Context Activation in accordance with the data from the UICC, if it is within the ME’s capabilities to do so. If the UICC requires PDP Context Activation that is beyond the ME’s capabilities, then the ME shall not perform PDP Context Activation at all.
In the case where the initial PDP Context Activation request results from a proactive command OPEN CHANNEL where GPRS is selected:
– if the call control result is "not allowed", the ME shall inform the UICC using TERMINAL RESPONSE ("interaction with call control by USIM or MO short message control by USIM, permanent problem; action not allowed");
– if the PDP Context Activation data is changed by call control, then the ME shall activate the PDP context using the data given by the UICC, if it is within the ME’s capabilities to do so. If the UICC requires a PDP Context Activation that is beyond the ME’s capabilities (e.g. the UICC requests a QoS that the ME cannot handle ), then the ME shall not activate the PDP context at all.
7.3.1.8 Procedure for EPS PDN connection Activation
If the service "call control on EPS PDN connection by USIM" is available in the USIM Service Table (see TS 31.102 [14]), then for all EPS PDN connection activation (including those resulting from a OPEN CHANNEL proactive UICC command where E-UTRAN/Satellite E-UTRAN is selected), the ME shall first pass the corresponding PDN Connectivity Request message (see TS 24.301 [46]) to the UICC, using the ENVELOPE (CALL CONTROL) command defined above. The ME shall also pass to the UICC in the ENVELOPE (CALL CONTROL) command the current serving cell.
When the ME performs an emergency EPS PDN connection activation, the ME shall not send the ENVELOPE (CALL CONTROL) command to the UICC.
The UICC shall respond in the same way as for mobile originated calls. The ME shall interpret the response as follows:
– if the UICC responds with ’90 00′, the ME shall send the PDN Connectivity Request message with the information as sent to the UICC;
– if the UICC responds with ’93 00′, the ME shall not send the PDN Connectivity Request message and may retry the command;
– if the UICC provides response data, then the response data from the UICC shall indicate to the ME whether to send the PDN Connectivity Request message as proposed, not send the PDN Connectivity Request message or send the PDN Connectivity Request message using the data supplied by the UICC. It is mandatory for the ME to perform the EPS PDN Connection Activation in accordance with the data from the UICC, if it is within the ME’s capabilities to do so. If the UICC requires EPS PDN Connection Activation that is beyond the ME’s capabilities, then the ME shall not perform EPS PDN Connection Activation at all.
In the case where the initial PDN Connectivity Request results from a proactive command OPEN CHANNEL where E-UTRAN/Satellite E-UTRAN is selected:
– if the call control result is "not allowed", the ME shall inform the UICC using TERMINAL RESPONSE ("interaction with call control by USIM or MO short message control by USIM, permanent problem; action not allowed");
– if the EPS PDN Connection Activation data is changed by call control, then the ME shall activate the EPS PDN Connection using the data given by the UICC, if it is within the ME’s capabilities to do so. If the UICC requires a EPS PDN Connection Activation that is beyond the ME’s capabilities, then the ME shall not activate the EPS PDN Connection at all.
7.3.1.9 Procedure for IMS communications establishment
If the service "communication control for IMS by USIM" is available in the USIM Service Table (see TS 31.102 [14]), then for all IMS communication establishment, the ME shall first pass the corresponding IMS Request-URI contained in SIP INVITE message (see TS24.229 [52]) to the UICC, using the ENVELOPE (CALL CONTROL) command defined above. The ME shall also pass to the UICC in the ENVELOPE (CALL CONTROL) command the current serving cell if the IMS communication is established over GERAN, UTRAN, E-UTRAN, Satellite E-UTRAN, NG-RAN or Satellite NG-RAN. If the type of media to be used by the ME is one of those listed in the Terminal Profile and if the "Media Type support" service is allocated and activated in the USIM or ISIM Service Table, the ME shall pass to the UICC in the ENVELOPE (CALL CONTROL) command the media type of the SIP communication session it is setting up.
This procedure replaces the call control by USIM using the Address TLV (clause 8.1) when the call is originated over IMS and the service "communication control for IMS by USIM" is available in the USIM Service Table (see TS 31.102 [14]).
When the ME detects that an IMS emergency call is being initiated, the ME shall set up an emergency call without sending the ENVELOPE (CALL CONTROL) command to the UICC.
The UICC shall respond in the same way as for mobile originated communications. The ME shall interpret the response as follows:
– if the UICC responds with ’90 00′, the ME shall send the SIP INVITE message with the information as sent to the UICC;
– if the UICC responds with ’93 00′, the ME shall not send SIP INVITE message and may retry the command;
– if the UICC provides response data, then the response data from the UICC shall indicate to the ME whether to send the SIP INVITE message as proposed, not send the SIP INVITE message or send the SIP INVITE message using the IMS-Request URI supplied by the UICC. It is mandatory for the ME to perform the SIP INVITE request in accordance with the data from the UICC, if it is within the ME’s capabilities to do so. If the UICC requires SIP INVITE request that is beyond the ME’s capabilities, then the ME shall not send SIP INVITE request at all.
7.3.1.10 Procedure for PDU session establishment
If the service "call control on PDU session by USIM" is available in the USIM Service Table (see TS 31.102 [14]), then for all PDU session establishment (including those resulting from a OPEN CHANNEL proactive UICC command where NG-RAN or Satellite NG-RAN is selected), the ME shall first pass the corresponding PDU Session Establishment Request message (see TS 24.501 [70]) to the UICC, using the ENVELOPE (CALL CONTROL) command defined above. The ME shall also pass to the UICC in the ENVELOPE (CALL CONTROL) command the current serving cell.
When the ME performs an emergency PDU session establishment, the ME shall not send the ENVELOPE (CALL CONTROL) command to the UICC.
The UICC shall respond in the same way as for mobile originated calls. The ME shall interpret the response as follows:
– if the UICC responds with ’90 00′, the ME shall send the PDU Session Establishment Request message with the information as sent to the UICC;
– if the UICC responds with ’93 00′, the ME shall not send the PDU Session Establishment Request message and may retry the command;
– if the UICC provides response data, then the response data from the UICC shall indicate to the ME whether to send the PDU Session Establishment Request message as proposed, not send the PDU Session Establishment Request message or send the PDU Session Establishment Request message using the data supplied by the UICC. It is mandatory for the ME to perform the PDU session establishment in accordance with the data from the UICC, if it is within the ME’s capabilities to do so. If the UICC requires PDU session establishment that is beyond the ME’s capabilities, then the ME shall not perform PDU session establishment at all.
In the case where the initial PDU Session Establishment Request results from a proactive command OPEN CHANNEL where NG-RAN or Satellite NG-RAN is selected:
– if the call control result is "not allowed", the ME shall inform the UICC using TERMINAL RESPONSE ("interaction with call control by USIM or MO short message control by USIM, permanent problem; action not allowed");
– if the PDU session establishment data is changed by call control, then the ME shall establish the PDU session using the data given by the UICC, if it is within the ME’s capabilities to do so. If the UICC requires a PDU session establishment that is beyond the ME’s capabilities, then the ME shall not establish the PDU session at all.
7.3.2 MO Short Message Control by USIM
7.3.2.1 Description
If the service "MO Short Message Control" is available in the USIM Service Table (see TS 31.102 [14]), then the ME shall follow the procedure below:
– for all MO short message attempts (even those resulting from a SEND SM proactive UICC command), the ME shall first pass the RP_destination_address of the service centre and the TP_Destination_Address to the UICC, using the ENVELOPE (MO SHORT MESSAGE CONTROL) command defined below. The ME shall also pass to the UICC in the ENVELOPE (MO SHORT MESSAGE CONTROL) command the current serving cell;
– if the UICC responds with ’90 00′, the ME shall send the short message with the addresses unchanged;
– if the UICC responds with any other status code indicating an error, the ME shall not send the short message;
– if the UICC responds with ’93 00′, the ME shall not send the short message and may retry the command;
– if the UICC provides response data, then the response data from the UICC shall indicate to the ME whether to send the short message as proposed, not send the short message or send a short message using the data supplied by the UICC. It is mandatory for the ME to perform the MO short message request in accordance with the data from the UICC.
The ME shall then follow the MO Short Message procedure defined in TS 24.011 [10].
In the case where the initial MO short message request results from a proactive command SEND SHORT MESSAGE, if the MO short message control result is "not allowed", the ME shall inform the UICC using TERMINAL RESPONSE, "interaction with call control by USIM or MO short message control by USIM, permanent problem; action not allowed".
7.3.2.2 Structure of ENVELOPE (MO SHORT MESSAGE CONTROL)
Direction: ME to UICC.
The command header is specified in TS 31.101 [13].
Command parameters/data.
|
Description |
Clause |
M/O/C |
Min |
Length |
|
MO Short Message control tag |
9.1 |
M |
Y |
1 |
|
Length (A+B+C+D) |
– |
M |
Y |
1 or 2 |
|
Device identities |
8.7 |
M |
Y |
A |
|
Address data object 1 |
8.1 or 8.108 |
M |
Y |
B |
|
Address data object 2 |
8.1 or 8.108 |
M |
Y |
C |
|
Location information |
8.19 |
C |
Y |
D |
– Device identities: the ME shall set the device identities to:
source: ME;
destination: UICC.
– Address data object 1: this address data object 1 contains the RP_Destination_Address of the Service Centre to which the ME is proposing to send the short message. If the USIM or the ISIM Service Table indicates URI support for MO SHORT MESSAGE CONTROL, then the address data object 1 may contain the Public Service Identity of the SM-SC to which the ME is proposing to send the short message. The type of address data object shall not be modified.
– Address data object 2: this address data object 2 contains the TP_Destination_Address to which the ME is proposing to send the short message. If the USIM or the ISIM Service Table indicates URI support for MO SHORT MESSAGE CONTROL, then the address data object 2 may contain the Public Identity (IMPU) of the receiver to which the ME is proposing to send the short message. The type of address data object shall not be modified.
– Location information: this data object contains the identification (MCC, MNC, LAC/TAC, Cell Identity) of the current serving cell of the UE. This data object shall be present if the short message is sent over GERAN, UTRAN, E-UTRAN, Satellite E-UTRAN, NG-RAN or Satellite NG-RAN.
Response parameters/data.
It is permissible for the UICC to provide no response data, by responding with SW1/SW2 = ’90 00′. If the UICC does not provide any response data, then this shall have the same meaning as "allowed, no modification".
|
Description |
Clause |
M/O/C |
Min |
Length |
|
MO short message control result |
– |
M |
Y |
1 |
|
Length (A+B+C) |
– |
M |
Y |
1 or 2 |
|
Address data object 1 |
8.1 or 8.108 |
O (see note) |
N |
A |
|
Address data object 2 |
8.1 or 8.108 |
O (see note) |
N |
B |
|
Alpha identifier |
8.2 |
O |
N |
C |
|
NOTE: The UICC shall provide the two optional address data objects if it has set the MO Short Message control result to "allowed with modifications". |
||||
– MO Short Message control result:
Contents:
– The command that the UICC gives to the ME concerning whether to allow, bar or modify the proposed short message;
Coding:
– ’00’ = Allowed, no modification;
– ’01’ = Not allowed;
– ’02’ = Allowed with modifications.
– if the ME receives wild values according to TS 31.102 [14] in either the Address data object 1 or Address data object 2, then the ME shall not process the command.
– Alpha identifier: this data object is only required if the UICC requests a particular indication to be given to the user. The handling of this data object by the ME is described in clause 7.3.2.3.
7.3.2.3 Indication to be given to the user
The UICC may optionally include an alpha-identifier in the response data to the ENVELOPE (MO SHORT MESSAGE CONTROL) message, in order to inform the user at the time the response is received by the ME. The use of this alpha identifier by the ME is identical to the one described in clause 7.3.1.3 relative to call control by USIM.
7.3.2.4 Interaction with Fixed Dialling Number
It is permissible for the Fixed Dialling Number service to be enabled (see TS 31.102 [14]) at the same time as MO Short Message Control is available (in the USIM Service Table). If FDN is enabled, the ME shall follow the procedure for Call Control (see clause 7.3.1.4), where the number or called address (i.e. IMS URI) in the procedure refers to both the SMS destination address and the SMSC address.
7.4 Timer Expiration
See ETSI TS 102 223 [32] clause 7.4.
7.5 Event download
See ETSI TS 102 223 [32] clause 7.5.
Regarding all the call events, the following equivalences shall apply:
– the "call setup message" is the SETUP message as defined in TS 24.008 [09];
– the "call connect message" is the CONNECT message as defined in TS 24.008 [09];
– the "disconnect messages" are the DISCONNECT, RELEASE, RELEASE COMPLETE messages as defined in TS 24.008 [09];
– the "NULL state" is the CC-U0 state as defined in TS 24.008 [09].
Regarding the location status event, the following equivalence shall apply:
– the "idle" state is the MM-IDLE state as defined in TS 24.008 [09] for GERAN/UTRAN, the EMM-IDLE state as defined in TS 24.301 [46] for E-UTRAN/Satellite E-UTRAN and 5GMM-IDLE state as defined in TS 24.501 [70] for NG-RAN.
Where events occur and the UICC responds with ’93 00′, the ME shall retry to deliver the event download messages to the UICC.
7.5.1 (I-)WLAN Access status event
7.5.1.1 Procedure
If the (I-)WLAN Access Status event is part of the current event list (as set up by the last SET UP EVENT LIST command, see clause 6.4.16), then, when the terminal detects a change in its current I-WLAN access or WLAN access respectively the terminal shall inform the UICC that this has occurred, by using the ENVELOPE (EVENT DOWNLOAD – (I-)WLAN Access Status) command as defined in clause 7.5.1.2.
7.5.1.2 Structure of ENVELOPE (EVENT DOWNLOAD – (I-)WLAN Access Status)
Direction: terminal to UICC.
The command header is specified in TS 31.101 [13].
Command parameters/data.
|
Description |
Clause |
M/O |
Min |
Length |
|
Event download tag |
9.1 |
M |
Y |
1 |
|
Length (A+B+C) |
– |
M |
Y |
1 or 2 |
|
Event list |
8.25 |
M |
Y |
A |
|
Device identities |
8.7 |
M |
Y |
B |
|
(I-)WLAN Access Status |
8.84 |
M |
Y |
C |
Event list: the Event list data object shall contain only one event (value part of length 1 byte), and terminal shall set the event to:
(I-)WLAN Access Status.
Device identities: the terminal shall set the device identities to:
source: terminal;
destination: UICC.
(I-)WLAN Access Status: this data object shall contain the (I-)WLAN Access status of the terminal.
Response parameters/data: None for this type of ENVELOPE command.
7.5.1A MT Call event
7.5.1A.1 Procedure
If the MT call event is part of the current event list (as set up by the last SET UP EVENT LIST command, see clause 6.4.16), then when the ME receives an incoming call setup message, the ME shall inform the UICC that this has occurred, by using the ENVELOPE (EVENT DOWNLOAD – MT call) command as defined in clause 7.5.1A.2.
7.5.1A.2 Structure of ENVELOPE (EVENT DOWNLOAD – MT call)
Direction: ME to UICC.
The command header is specified in TS 31.101 [13].
Command parameters/data.
|
Description |
Clause |
M/O/C |
Min |
Length |
|
Event download tag |
9.1 |
M |
Y |
1 |
|
Length (A+B+C+D+E+F+G+H) |
– |
M |
Y |
1 or 2 |
|
Event list |
8.25 |
M |
Y |
A |
|
Device identities |
8.7 |
M |
Y |
B |
|
Transaction identifier |
8.28 |
M |
N |
C |
|
Address |
8.1 |
C |
N |
D |
|
Subaddress |
8.3 |
C |
N |
E |
|
IMS URI |
8.108 |
C |
N |
F |
|
Media Type |
8.132 |
C |
N |
G |
|
URI truncated |
8.135 |
C |
N |
H |
Event list: the event list object shall contain only one event (value part of length 1 byte), and ME shall set the event to:
– MT call.
Device identities: the ME shall set the device identities to:
– source: network;
– destination: UICC.
Transaction identifier: the transaction identifier data object shall contain one transaction identifier, and this shall be the Transaction Identifier as defined in clause 8.28.
Address: the address data object holds the Calling Party number received by the ME in the call setup message. If the Calling Party number is included in the call setup message, the ME shall include the Address object. Otherwise the ME shall not include the Address object.
Subaddress: The Subaddress data object holds the Calling Party Subaddress as received by the ME in the call setup message. If the Calling Party Subaddress is included in the call setup message, the ME shall include the Subaddress object, otherwise the terminal shall not include the Subaddress object.
IMS URI: The IMS URI data object is a SIP or TEL URI of the Calling Party received by the ME in the call setup message. This data object will be present only if the "URI support by UICC" Service is present in the USIM or the ISIM Service Table. The IMS URI data object shall contain the SIP URI or tel URI indicated in the P-Asserted-Identity field as defined in TS 24.229 [52]. In case the P-Asserted-Identity field is missing the SIP URI or tel URI indicated in the From header field shall be used. If the URI is longer than the maximum length that can be transmitted to the UICC, then the URI shall be truncated to the maximum length that can be transmitted to the UICC and the request shall contain a URI truncated tag.
Media Type: The Media Type indicates the type of media of the incoming call session and shall be coded as defined in clause 8.132. The Media Type data object shall be present, if the "Media Type support" service is allocated and activated in the USIM or ISIM Service Table.
Response parameters/data:
– none.
7.5.2 Network Rejection event
7.5.2.1 Procedure
If the Network Rejection event is part of the current event list (as set up by the last SET UP EVENT LIST command, see ETSI TS 102 223 [32] clause 6.4.16), then, in the case of GERAN/UTRAN if the terminal receives a LOCATION UPDATING REJECT message or a GPRS ATTACH REJECT message or a ROUTING AREA UPDATE REJECT message (as defined in TS 24.008 [9]) or in the case of E-UTRAN and Satellite E-UTRAN if the terminal receives an EMM ATTACH REJECT message or TRACKING AREA UPDATE REJECT message (as defined in TS 24.301 [46]), or in the case of NG-RAN and Satellite NG-RAN if the terminal receives a REGISTRATION REJECT message (as defined in TS 24.501 [70]), the terminal shall inform the UICC that this has occurred, by using the ENVELOPE (EVENT DOWNLOAD – Network Rejection Event) command as defined below.
7.5.2.2 Structure of ENVELOPE (EVENT DOWNLOAD – Network Rejection)
Direction: ME to UICC.
The command header is specified in TS 31.101 [13].
Command parameters/data.
|
Description |
Clause |
M/O |
Min |
Length |
|
Event download tag |
9.1 |
M |
Y |
1 |
|
Length (A+B+C+D+E+F+G+H+I) |
– |
M |
Y |
1 |
|
Event list |
8.25 |
M |
Y |
A |
|
Device identities |
8.7 |
M |
Y |
B |
|
Location Information |
8.19 |
C |
N |
C |
|
Routing Area Identification |
8.91 |
C |
N |
D |
|
Tracking Area Identification |
8.99 |
C |
N |
E |
|
Access Technology |
8.62 |
M |
Y |
F |
|
Update/Attach/Registration Type |
8.92 |
M |
Y |
G |
|
Rejection Cause Code |
8.93 |
M |
Y |
H |
|
Extended Rejection Cause Code |
8.136 |
C |
N |
I |
– Event list: the Event list data object shall contain only one event (value part of length 1 byte), and terminal shall set the event to:
– Network Rejection Event.
– Device identities: the terminal shall set the device identities to:
– source: Network;
– destination: UICC.
– Location information: This data object shall only be present when the ME receives a Location Updating Reject message, and shall contain the identification (MCC, MNC, and LAC) of the rejecting network.
– Routing Area Identification: This data object shall only be present when the ME receives a GPRS ATTACH REJECT message or a ROUTING AREA UPDATE REJECT message and shall contain the identification (MCC, MNC, LAC and RAC) of the rejecting network.
– Tracking Area Identification: This data object shall only be present when the ME receives an EMM ATTACH REJECT or a TRACKING AREA UPDATE REJECT or a REGISTRATION REJECT message and shall contain the identification (MCC, MNC and TAC) of the rejecting network.
– Access Technology: This data object shall contain the access technology of the rejecting network.
– Update/Attach/Registration Type: This data object contains the location updating or attach or update or EPS attach or EPS update or 5GS registration type that was used in the LOCATION UPDATING REQUEST or GPRS ATTACH REQUEST or ROUTING AREA UPDATE REQUEST or EMM ATTACH REQUEST or TRACKING AREA UPDATE REQUEST or REGISTRATION REQUEST message.
– Rejection Cause Code: This data object contains the cause code value that was received in the LOCATION UPDATING REJECT or GPRS ATTACH REJECT or ROUTING AREA UPDATE REJECT or EMM ATTACH REJECT or TRACKING AREA UPDATE REJECT or REGISTRATION REJECT message.
– Extended Rejection Cause Code: This data object contains the extended cause code value that was received in the EMM ATTACH REJECT or TRACKING AREA UPDATE REJECT message.
Response parameters/data: None for this type of ENVELOPE command.
7.5.2A Call connected event
7.5.2A.1 Procedure
See ETSI TS 102 223 [32] clause 7.5.2.1.
7.5.2A.2 Structure of ENVELOPE (EVENT DOWNLOAD – call connected)
Direction: ME to UICC.
The command header is specified in TS 31.101 [13].
Command parameters/data.
|
Description |
Clause |
M/O/C |
Min |
Length |
|
Event download tag |
9.1 |
M |
Y |
1 |
|
Length (A+B+C+D) |
– |
M |
Y |
1 or 2 |
|
Event list |
8.25 |
M |
Y |
A |
|
Device identities |
8.7 |
M |
Y |
B |
|
Transaction identifier |
8.28 |
M |
Y |
C |
|
Media Type |
8.132 |
O |
N |
D |
Event list: the event list object shall contain only one event (value part of length 1 byte), and the ME shall set the event to:
– call connected.
Device identities:
– in the case of connecting at the near end (an MT call), the ME shall set the device identities to:
– source: ME;
– destination: UICC.
– in the case of connecting at the far end (an MO call), the ME shall set the device identities to:
– source: network;
– destination: UICC.
Transaction identifier: the Transaction identifier data object shall contain one transaction identifier.
Media Type: The Media Type indicates the type of media of the call session and shall be coded as defined in clause 8.132. The Media Type data object shall be present, if the "Media Type support" service is allocated and activated in the USIM or ISIM Service Table.
Response parameters/data:
– none.
7.5.3 CSG Cell Selection event
The following clause applies if class "q" is supported
7.5.3.1 Procedure
If the CSG Cell Selection event is part of the current event list (as set up by the last SET UP EVENT LIST command, see ETSI TS 102.223 [32]), then, when the ME detects a change in its current CSG or Hybrid cell selection status, the ME shall inform the UICC that it has occurred, using ENVELOPE (EVENT DOWNLOAD – CSG Cell Selection) as defined below.
7.5.3.2 Structure of ENVELOPE (EVENT DOWNLOAD – CSG Cell Selection)
Direction : ME to UICC
The command header is specified in TS 31.101 [13]
Command parameters/data
|
Description |
Clause |
M/O |
Min |
Length |
|
Event download tag |
9.1 |
M |
Y |
1 |
|
Length (A+B+C+D+E+F+G) |
– |
M |
Y |
1 |
|
Event list |
8.25 |
M |
Y |
A |
|
Device identities |
8.7 |
M |
Y |
B |
|
Access Technology |
8.62 |
C |
Y |
C |
|
CSG cell selection status |
8.101 |
M |
Y |
D |
|
CSG ID |
8.102 |
C |
N |
E |
|
HNB name |
8.103 |
C |
N |
F |
|
PLMN ID |
8.118 |
O |
N |
G |
– Event list: the Event list data object shall contain only one event (value part of length 1 byte), and terminal shall set the event to:
– CSG Cell Selection.
– Device identities: the terminal shall set the device identities to:
– source: Network;
– destination: UICC.
– Access Technology: This data object shall contain the access technology of the current serving cell. If the device is not camping on any cell, this data object shall not be present.
– CSG cell selection status: this data object shall contain CSG or Hybrid cell selection status. The ME should send the event indicating that it is not camped on a CSG or Hybrid cell only after a previous event that indicated that UE was camped on a CSG or Hybrid cell.
– CSG ID: If the UE is camping on a CSG or Hybrid cell in the Allowed CSG list or the Operator CSG list, this data object shall be present, and shall contain CSG id of the current serving CSG or Hybrid cell. In all other cases this data object shall not be present.
– HNB name: If the UE is camping on a CSG or Hybrid cell in the Allowed CSG list or the Operator CSG list and the HNB name of the cell is available in the broadcasted information to the ME, this data object shall be present, and shall contain the broadcasted HNB name of the current serving CSG or Hybrid cell. In all other cases this data object shall not be present.
– PLMN ID: If the UE is camping on a CSG or Hybrid cell that is listed in the Allowed CSG list or the Operator CSG list, this data object may be present, and, if present, shall contain the PLMN identity of the current serving CSG or Hybrid cell.
Response parameters/data: None for this type of ENVELOPE command.
7.5.3A Call disconnected event
7.5.3A.1 Procedure
See ETSI TS 102 223 [32] clause 7.5.3.1.
7.5.3A.2 Structure of ENVELOPE (EVENT DOWNLOAD – call disconnected)
Direction: ME to UICC.
The command header is specified in TS 31.101 [13].
Command parameters/data.
|
Description |
Clause |
M/O/C |
Min |
Length |
|
Event download tag |
9.1 |
M |
Y |
1 |
|
Length (A+B+C+D+E+F) |
– |
M |
Y |
1 or 2 |
|
Event list |
8.25 |
M |
Y |
A |
|
Device identities |
8.7 |
M |
Y |
B |
|
Transaction identifier |
8.28 |
M |
Y |
C |
|
Cause |
8.26 |
O |
N |
D |
|
Media Type |
8.132 |
C |
N |
E |
|
IMS call disconnection cause |
8.133 |
O |
N |
F |
Event list: the event list object shall contain only one event (value part of length 1 byte), and the ME shall set the event to:
– call disconnected.
Device identities:
– in the case of "near end" disconnection, the ME shall set the device identities to:
– source: ME;
– destination: UICC.
– in the case of "far end" disconnection, the ME shall set the device identities to:
– source: network;
– destination: UICC.
Transaction identifier: the transaction identifier data object shall contain a list of the transaction identifiers for each of the calls being disconnected.
Cause: the cause shall reflect the cause information element sent or received in the disconnect message triggering the ENVELOPE command. If the cause information element was not present in the message, or the cause data object shall not be included. In the case of a radio link timeout, the cause data object shall be included, with a value part of zero length.
Media Type: The Media Type indicates the type of media of the call session and shall be coded as defined in clause 8.132. The Media Type data object shall be present if the "Media Type support" service is allocated and activated in the USIM or ISIM Service Table.
IMS call disconnection cause: The IMS call disconnection cause shall reflect the Reason header field in the SIP message triggering the ENVELOPE command. If the Reason header field is not present in the SIP message, the IMS call disconnection cause data object shall not be included. The cause and corresponding protocol shall not be present in the ENVELOPE command within a corresponding IMS call disconnection cause data object if the "IMS call disconnection cause" service is neither allocated and activated in the USIM nor ISIM Service Table.
Response parameters/data:
– none.
7.5.4 Location status event
See ETSI TS 102 223 [32] clause 7.5.4.
If a location status is already available in the UE when the UICC supplies an event list with location status event (by using the SET UP EVENT LIST command), the ME shall immediately send the ENVELOPE (EVENT DOWNLOAD – location status) command (after the TERMINAL RESPONSE), providing the Location status and the Location information.
7.5.5 User activity event
See ETSI TS 102 223 [32] clause 7.5.5.
7.5.6 Idle screen available event
See ETSI TS 102 223 [32] clause 7.5.6.
7.5.7 Card reader status event
See ETSI TS 102 223 [32] clause 7.5.7.
7.5.8 Language selection event
See ETSI TS 102 223 [32] clause 7.5.8.
7.5.9 Browser termination event
See ETSI TS 102 223 [32] clause 7.5.9.
7.5.10 Data available event
See ETSI TS 102 223 [32] clause 7.5.10.
7.5.11 Channel status event
See ETSI TS 102 223 [32] clause 7.5.11.
7.5.12 Access Technology Change Event
See ETSI TS 102 223 [32] clause 7.5.12.
If a access technology is already available in the UE when the UICC supplies an event list with Access Technology Change event (by using the SET UP EVENT LIST command), the ME shall immediately send the ENVELOPE (EVENT DOWNLOAD – Access Technology Change) command (after the TERMINAL RESPONSE), providing the Access Technology.
7.5.13 Display parameters changed event
See ETSI TS 102 223 [32] clause 7.5.13.
7.5.14 Local Connection event
See ETSI TS 102 223 [32] clause 7.5.14.
7.5.15 Network Search Mode Change Event
See ETSI TS 102 223 [32] clause 7.5.15.
7.5.16 Browsing status event
See ETSI TS 102 223 [32] clause 7.5.16.
7.5.17 Frames Information changed event
See ETSI TS 102 223 [32] clause 7.5.17.
7.5.18 HCI connectivity event
Not required by 3GPP.
7.5.19 Contactless state request
Not required by 3GPP.
7.5.20 Incoming IMS Data event
The following clauses apply if classes "e" and "t" are supported.
7.5.20.1 Procedure
If the Incoming IMS data event is part of the current event list (as set up by the last SET UP EVENT LIST command, see ETSI TS 102 223 [32]), then, in the case of an incoming IMS message to an IARI (see TS 24.229 [52]) associated to an application installed on the UICC and no open channel is available for IMS communication, see 3GPP TS 31.102 [14], the terminal shall inform the UICC that this has occurred, by using the ENVELOPE (EVENT DOWNLOAD – Incoming IMS data) command as defined below.
7.5.20.2 Structure of ENVELOPE (EVENT DOWNLOAD – Incoming IMS Data)
Direction : ME to UICC
The command header is specified in TS 31.101 [13]
Command parameters/data
|
Description |
Clause |
M/O |
Min |
Length |
|
Event download tag |
9.1 |
M |
Y |
1 |
|
Length (A+B+C) |
– |
M |
Y |
1 or 2 |
|
Event list |
8.25 |
M |
Y |
A |
|
Device identities |
8.7 |
M |
Y |
B |
|
IARI |
8.110 |
M |
Y |
C |
– Event list: the Event list data object shall contain only one event (value part of length 1 byte), and terminal shall set the event to:
– Incoming IMS Data event.
– Device identities: the terminal shall set the device identities to:
– source: Network;
– destination: UICC.
– IARI: This data object contains the IARI included in the Accept-Contact (see TS 24.229 [52]) header field of the incoming SIP INVITE IMS message destined for the UICC.
Response parameters/data: None for this type of ENVELOPE command.
7.5.21 IMS Registration Event
The following clauses apply if classes "e" and "t" are supported.
7.5.21.1 Procedure
If the IMS Registration event is part of the current event list (as set up by the last SET UP EVENT LIST command, see ETSI TS 102 223 [32]) and the SIP REGISTER message contains the IARIs defined in EF-UICCIARI, then, upon receiving the 200 OK (see 3GPP TS 24.229 [52]) message in response to the SIP REGISTER message (see 3GPP TS 24.229 [52]) or upon receiving any status code (see 3GPP TS 24.229 [52]) indicating a failure in response to the SIP REGISTER message, the terminal shall inform the UICC that this event has occurred, by using the ENVELOPE (EVENT DOWNLOAD – IMS Registration) command as defined below.
7.5.21.2 Structure of ENVELOPE (EVENT DOWNLOAD – IMS Registration)
Direction : ME to UICC
The command header is specified in TS 31.101 [13]
Command parameters/data
|
Description |
Clause |
M/O/C |
Min |
Length |
|
Event download tag |
9.1 |
M |
Y |
1 |
|
Length (A+B+C+D) |
– |
M |
Y |
1 or 2 |
|
Event list |
8.25 |
M |
Y |
A |
|
Device identities |
8.7 |
M |
Y |
B |
|
IMPU list |
8.111 |
C |
Y |
C |
|
IMS status code |
8.112 |
C |
Y |
D |
– Event list: the Event list data object shall contain only one event (value part of length 1 byte), and terminal shall set the event to:
– IMS Registration Event.
– Device identities: the terminal shall set the device identities to:
– source: Network;
– destination: UICC.
– IMPU list: This data object shall contain the list of IMPUs built from the URIs from the aor (address of record) attributes for which within the same registration element at least one of the ME’s contact URIs has the status "active" (see RFC 3680 [55]) received in the registration event package (see 3GPP TS 24.229 [52]) of the SIP NOTIFY request. This data object shall only be present in the case of a successful registration. If the network indicates, using the SIP NOTIFY request containing the registration event package, that there are no aor attributes that for which within the same registration element at least one of the ME’s contact URIs has the status "active" then the ME shall send an empty list of IMPUs to the UICC.
– Status Code: This data object shall contain the Status-code (see 3GPP TS 24.229 [52]) received from the IMS network in response to a SIP REGISTER message. This data object shall only be present to indicate that a failure occurred during an IMS registration.
Response parameters/data: None for this type of ENVELOPE command.
7.5.22 Profile Container
Not required by 3GPP.
7.5.23 Envelope Container
Not required by 3GPP.
7.5.24 Poll Interval Negotiation
See ETSI TS 102 223 [32] clause 7.5.22.
7.5.25 Data Connection Status Change Event
7.5.25.1 Procedure
This and the following clauses apply if class "e" is supported.
If the Data Connection Status Change event is part of the current event list (as set up by the last SET UP EVENT LIST command, see clause 8.25 of this document), then, upon detection by the ME of a change in the data connection status, the terminal shall inform the UICC that this event has occurred, by using the ENVELOPE (EVENT DOWNLOAD – Data Connection Status Change) command as defined below.
7.5.25.2 Structure of ENVELOPE (EVENT DOWNLOAD – Data Connection Status Change)
Direction: ME to UICC
The command header is specified in TS 31.101 [13].
Command parameters/data
|
Description |
Clause |
M/O/C |
Min |
Length |
|
Event download tag |
9.1 |
M |
Y |
1 |
|
Length (A+B+C+D+E+F+G+H+I+J+K+L) |
– |
M |
Y |
1 or 2 |
|
Event list |
8.25 |
M |
Y |
A |
|
Device identities |
8.7 |
M |
Y |
B |
|
Data connection status |
8.137 |
M |
Y |
C |
|
Data connection type |
8.138 |
M |
Y |
D |
|
(E/5G)SM cause |
8.139 |
C |
Y |
E |
|
Transaction identifier |
8.28 |
M |
Y |
F |
|
Date-Time and Time zone |
8.39 |
C |
Y |
G |
|
Location Information |
8.19 |
C |
Y |
H |
|
Access Technology |
8.62 |
C |
Y |
I |
|
Location status |
8.27 |
M |
Y |
J |
|
Network Access Name |
8.61 |
C |
Y |
K |
|
PDP/PDN/PDU type |
8.142 |
C |
Y |
L |
– Event list: the Event list data object shall contain only one event (value part of length 1 byte), and the ME shall set the event to:
– Data Connection Status Change.
– Device identities: the terminal shall set the device identities to:
– source: Network for network originated messages. ME for ME originated messages;
– destination: UICC.
– Data connection status: This data object shall contain the status of the data connection.
– Data connection type: This data object shall contain the type of data connection.
– (E/5G)SM cause: If an (E/5G)SM cause is available, this data object shall contain either the SM cause as defined in 3GPP TS 24.008 [9] or the ESM cause as defined in 3GPP TS 24.301 [46], or the 5GSM cause as defined in 3GPP TS 24.501 [70].
– Transaction identifier: The Transaction identifier data object shall contain one transaction identifier as defined in clause 8.28.
– Date-Time and Time zone: If the date-time and time zone information is available in the ME, this data object is mandatory and shall contain the Date-Time and Time zone at the ME detected moment of occurrence of the event.
– Location Information: This data object contains the identification (MCC, MNC, LAC/TAC, Cell Identity) of the current serving cell of the UE. The comprehension required flag of this data object in this command shall be set to ‘0’. This data object shall be present if the data connection is performed over GERAN, UTRAN, E-UTRAN, Satellite E-UTRAN, NG-RAN or Satellite NG-RAN.
– Access Technology: This data object shall contain the access technology of the rejecting or accepting network.
– Location Status: This data object indicates the current service state of the terminal.
– Network Access Name: This data object shall contain the Access Point Name value present in the Activate PDP context request (for a PDP context activation, as defined in TS 24.008 [9]) or the PDN connectivity request (for an EPS PDN connection activation, as defined in TS 24.301 [46]), or it shall contain the Data Network Name value present in the UL NAS TRANSPORT message for PDU Session Establishment request, as defined TS 24.501 [70]. It is present only when Data connection status is either successful or rejected.
– PDP/PDN/PDU type: This data object shall contain the PDP/PDN/PDU type requested in the Activate PDP context request (for a PDP context activation, as defined in TS 24.008 [9]) or the PDN connectivity request (for an EPS PDN connection activation, as defined in TS 24.301 [46]), or the PDU Session Establishment request (as defined in TS 24.501 [70]). It is present only when Data connection status is either successful or rejected.
Response parameters/data: None for this type of ENVELOPE command.
7.5.26 CAG Cell Selection event
The following clause applies if class "ag" is supported
7.5.26.1 Procedure
If the CAG Cell Selection event is part of the current event list (as set up by the last SET UP EVENT LIST command, see ETSI TS 102.223 [32]), then, when the ME detects a change in its current CAG cell selection status or in its CAG information list or the corresponding human-readable network name per CAG ID (if available in the broadcasted information to the ME), the ME shall inform the UICC that it has occurred, using ENVELOPE (EVENT DOWNLOAD – CAG Cell Selection) as defined below.
7.5.26.2 Structure of ENVELOPE (EVENT DOWNLOAD – CAG Cell Selection)
Direction : ME to UICC
The command header is specified in TS 31.101 [13]
Command parameters/data
|
Description |
Clause |
M/O |
Min |
Length |
|
Event download tag |
9.1 |
M |
Y |
1 |
|
Length (A+B+C+D+E+F+G) |
– |
M |
Y |
1 |
|
Event list |
8.25 |
M |
Y |
A |
|
Device identities |
8.7 |
M |
Y |
B |
|
Access Technology |
8.62 |
C |
Y |
C |
|
CAG cell selection status |
8.147 |
M |
Y |
D |
|
CAG information list |
8.148 |
C |
N |
E |
|
CAG ID human-readable network name per CAG ID list |
8.149 |
C |
N |
E |
– Event list: the Event list data object shall contain only one event (value part of length 1 byte), and terminal shall set the event to:
– CAG Cell Selection.
– Device identities: the terminal shall set the device identities to:
– source: Network;
– destination: UICC.
– Access Technology: This data object shall contain the access technology of the current serving cell. If the device is not camping on any cell, this data object shall not be present.
– CAG cell selection status: this data object shall contain CAG cell selection status. The ME should send the event indicating that it is not camped on a CAG cell only after a previous event that indicated that UE was camped on a CAG cell.
– CAG information list: If the UE is camping on a CAG cell, this data object shall be present, and shall contain CAG information list of the current serving CAG cell. In all other cases this data object shall not be present.
– CAG ID human-readable network name per CAG ID list: If the UE is camping on a CAG cell, this data object shall be present, and shall contain CAG ID human-readable network name per CAG ID list (if available in the broadcasted information to the ME). In all other cases this data object shall not be present.
Response parameters/data: None for this type of ENVELOPE command.
7.5.27 Slices Status Change event
The following clause applies if class "ah" is supported
7.5.27.1 Procedure
If the Slice Status Change event is part of the current event list (as set up by the last SET UP EVENT LIST command, see ETSI TS 102.223 [32]), then, when the ME detects a change in any S-NSSAI status (S-NSSAI included to or removed from Rejected S-NSSAI, Allowed NSSAI or Served S-NSSAI list), the ME shall inform the UICC that it has occurred, using ENVELOPE (EVENT DOWNLOAD – Slices status) as defined below.
7.5.27.2 Structure of ENVELOPE (EVENT DOWNLOAD – Slices status)
Direction : ME to UICC
The command header is specified in TS 31.101 [13]
Command parameters/data
|
Description |
Clause |
M/O/C |
Min |
Length |
|
Event download tag |
9.1 |
M |
Y |
1 |
|
Length (A+B+C+D+E+F+G) |
– |
M |
Y |
1 |
|
Event list |
8.25 |
M |
Y |
A |
|
Device identities |
8.7 |
M |
Y |
B |
|
Access Technology |
8.62 |
C |
Y |
C |
|
Slices status |
8.xxx |
M |
Y |
D |
|
Slices information |
8.145 |
C (see Note 1) |
Y |
D |
|
Rejected slices information |
8.yyy |
C (see Note 2) |
Y |
D |
|
NOTE 1: Slice information data object shall be present if Slice Status is Allowed and shall not be present if Slice Status is Rejected. NOTE 2: Rejected Slice information data object shall be present if Slice Status is Rejected and shall not be present if Slice Status is Allowed. |
||||
– Event list: the Event list data object shall contain only one event (value part of length 1 byte), and terminal shall set the event to:
– Slice Status Change.
– Device identities: the terminal shall set the device identities to:
– source: Network;
– destination: UICC.
– Access Technology: This data object shall contain the access technology of the associated Slices information data object or Rejected slices information data object. If the device is not camping on any cell, this data object shall not be present.
– Slice status: this data object shall contain slice status.
– Slices information: this data object shall contain slice information of Allowed NSSAI.
– Rejected Slices information: this data object shall contain slice information and rejection cause of Rejected NSSAI.
If multiple change occures at the same time on Rejected or Allowed S-NSSAI list(s), one event envelop for each slice status change shall be send by the ME.
Response parameters/data: None for this type of ENVELOPE command.
7.6 USSD Data Download
This clause applies if class "p" is supported.
7.6.1 Procedure
If the service "data download via USSD and USSD application mode" is allocated and activated in the USIM Service Table (see TS 31.102 [14]), then the ME shall follow the procedure below:
– When the ME receives a USSD packet it shall pass the message transparently to the USIM using the ENVELOPE (USSD DOWNLOAD) if the Data Coding Scheme of the USSD message (as defined for the CBS Data Coding Scheme in TS 23.038 [4]) indicate the USIM as the target (Bit 0 set to 0 and Bit 1 set to 1):
– The ME shall wait for an acknowledgement from the USIM:
– if the UICC responds with ’90 00′, the ME shall acknowledge the receipt of USSD message to the network using a FACILITY message. The ME will supply the response data from the UICC in the USSD String of the return result component of the FACILITY message it will send back to the network (see TS 24.090 [37]). The alphabet and language indicators shall be those used in the original message.
– if the USIM responds with ’93 00′, the ME shall either retry the command or send back a FACILITY message to the network. The ME will supply the status word followed by the response data from the UICC in the USSD String of the return result component of the FACILITY message it will send back to the network (see TS 24.090 [37]). The alphabet and language indicators shall be those used in the original message.
– if the UICC responds with ’62 XX’ or ’63 XX’, the ME shall acknowledge the receipt of the USSD message to the network using a FACILITY message. The ME will supply the status word followed by the response data from the UICC in the USSD String of the return result component of the FACILITY message it will send back to the network (see TS 24.090 [37]). The alphabet and language indicators shall be those used in the original message.
If the service "data download via USSD and USSD application mode " is not allocated and activated in the USIM Service Table, and the ME receives a USSD message with a Data Coding Scheme indicating that the destination is the card (as defined above), the ME shall return a FACILITY message to the network. The ME will supply the status word ‘6D 00’ (i.e. Instruction code not supported or invalid) in the USSD String of the return result component of the FACILITY message it will send back to the network (see TS 24.090 [37]). The alphabet and language indicators shall be those used in the original message.
7.6.2 Structure of ENVELOPE (USSD Data Download)
Direction: ME to UICC
The command header is specified in TS 31.101 [13].
Command parameters/data:
|
Description |
Clause |
M/O |
Min |
Length |
|
USSD Download tag |
9.1 |
M |
Y |
1 |
|
Length (A+B) |
– |
M |
Y |
1 or 2 |
|
Device identities |
8.7 |
M |
Y |
A |
|
USSD string |
8.17 |
M |
Y |
B |
– Device identities: the ME shall set the device identities to:
Source: Network
Destination: UICC
Response parameters/data:
It is permissible for the UICC not to provide response data. If the UICC provides response data, the following data is returned.
|
Byte(s) |
Description |
Length |
|
1‑X (X182) |
UICC response |
X |
7.7 MMS Transfer Status
See ETSI TS 102 223 [32] clause 7.6.
7.8 MMS notification download
See ETSI TS 102 223 [32].
Considering the addressing mechanism to the UICC indicated in ETSI TS 102 223 [32] clause 7.7, the UICC shall be targeted using the following application identifier: "uicc.3gpp.org".
7.9 Terminal Applications
See ETSI TS 102 223 [32] clause 7.8.
7.10 Geographical Location Reporting
7.10.1 Procedure
This clause applies if class "n" is supported.
If the ME has processed the proactive command "Geographical Location Request" successfully, then the ME shall send the ENVELOPE (Geographical Location Reporting).
It is acceptable for the ME to send the envelope even if the requested accuracy has not been achieved.
Note: some GAD Shapes contain the actual accuracy.
If positioning data cannot be provided, the envelope command shall neither include the GAD shape TLV nor the NMEA-sentence TLV.
If positioning data can be provided, the envelope command shall include either a GAD shape TLV or a NMEA-sentence TLV. The information sent by the ME is deemed fresh.
7.10.2 Structure of ENVELOPE (Geographical Location Reporting)
Direction: ME to UICC.
The command header is specified in TS 31.101 [13].
Command parameters/data.
|
Description |
Clause |
M/O/C |
Min |
Length |
|
Geographical Location Reporting tag |
9.1 |
M |
Y |
1 |
|
Length (A+B+C) |
– |
M |
Y |
1 or 2 |
|
Device identities |
8.7 |
M |
Y |
A |
|
GAD shape |
8.95 |
C |
N |
B |
|
NMEA sentence |
8.96 |
C |
N |
C |
– Device identities: the ME shall set the device identities to:
– source: ME;
– destination: UICC.
– GAD shape: This data object contains the location information.
– NMEA sentence: This data object contains the location information.
Response parameters/data: None for this type of ENVELOPE command.
7.11 Void
7.12 ProSe usage information reporting
7.12.1 Procedure
If the service "ProSe Usage Information Reporting configuration" and service "UICC ProSe Direct Communication usage information reporting" are allocated and activated in the ProSe Service Table (see TS 31.102 [14]), then a ProSe-enabled Public Safety ME that supports "ProSe usage information reporting" shall store the ProSe usage information to be sent over the PC3ch interface (see 3GPP TS 24.334 [61]) in the UICC. This is performed using the ENVELOPE (ProSe Report).
A UICC supporting the "ProSe usage information reporting" shall also support BIP. The UICC is responsible to transmit the collected reports to the ProSe Function CTF (ADF) using BIP mechanism, following the same procedure described in TS 24.334 [61] clause 10.3.1 and using the communication security described in TS 24.334 [61] clause 4.1. The address of the ProSe Function CTF (ADF) is available in the EFPROSE_UIRC (see TS 31.102 [14]).
The UICC shall store the received ProSe usage information until a USAGE_INFORMATION_REPORT_LIST_RESPONSE is received with transaction ID set to the value of the transaction ID included in the USAGE_INFORMATION_REPORT_LIST message.
If one envelope is not enough to transmit all the information (i.e. the ProSe usage information is more than 243 bytes), the information shall be split into several ENVELOPE (ProSe Report). The final envelope is indicated by containing a Last Envelope TLV. Intermediate envelopes shall not contain this TLV.
If one envelope is enough to transmit the information, this envelope shall contain a Last Envelope TLV.
NOTE: If the usage information report list sending procedure is unsuccessfully completed, the USIM behaviour is according to what is specified for the UE in 3GPP TS 24.334 [61], clause 10.3.2.1.6.
7.12.2 Structure of ENVELOPE (ProSe Report)
Direction: ME to UICC.
The command header is specified in TS 31.101 [13].
Command parameters/data.
|
Description |
Clause |
M/O/C |
Min |
Length |
|
ProSe Report tag |
9.1 |
M |
Y |
1 |
|
Length (A+B+C) |
– |
M |
Y |
1 or 2 |
|
Device identities |
8.7 |
M |
Y |
A |
|
ProSe Report |
8.128 |
M |
Y |
B |
|
Last Envelope |
8.79 |
C |
N |
C |
– Device identities: the ME shall set the device identities to:
– source: ME;
– destination: UICC.
– ProSe Report Data: This data object contains the ProSe Report.
– Last Envelope: Indicates that the last information concerning the ProSe Report has been sent.
Response parameters/data: None for this type of ENVELOPE command.
The UICC may respond with status word ’69 82′ if the PIN verification has not been performed successfully.
NOTE: The handling of the case where the USIM cannot process the ENVELOPE command (e.g. when there is not enough memory for storing a ProSe Report) is implementation-specific.