Content for TS 23.282 Word version: 19.4.0
1…
5…
6…
6.6…
7…
7.4…
7.4.2.7…
7.4.3…
7.5…
7.5.2.5…
7.5.2.10…
7.5.3…
7.6…
7.7…
7.8…
7.9…
7.13…
7.13.3.14…
7.13.4…
7.14…
7.17…
7.17.3.1.4…
7.17.3.2…
7.17.3.2.5…
7.17.4…
7.17.6…
A…
B…
7.4.3 Short data service for off-network
7.4.3.1 General
7.4.3.2 Information flows for short data service
7.4.3.3 One-to-one standalone short data service using signalling control plane
7.4.3.4 Group standalone short data service using signalling control plane
7.4.3.6 Group standalone short data service with MCData message store
...
...
7.4.3 Short data service for off-network p. 91
7.4.3.1 General p. 91
Off-network SDS communications are based on ProSe capabilities as described in clause 7.16.
7.4.3.2 Information flows for short data service p. 91
7.4.3.2.1 MCData standalone data request p. 91
Table 7.4.3.2.1-1 describes the information flow for the MCData standalone data request sent from the MCData client to another MCData client.
| Information Element | Status | Description |
|---|---|---|
| MCData ID | M | The identity of the MCData user sending data |
| MCData ID | M | The identity of the MCData user towards which the data is sent |
| Date and Time | M | Date and time of transmission |
| Conversation Identifier | M | Identifies the conversation |
| Transaction Identifier | M | Identifies the MCData transaction |
| Reply Identifier | O | Identifies the original MCData transaction to which the current transaction is a reply to |
| Disposition Type | O | Indicates the disposition type expected from the receiver (i.e., delivered or read or both) |
| Emergency indicator (see NOTE 1) | O | Indicates that the MCData communication is an MCData emergency communication |
| Payload Destination Type | M | Indicates whether the payload is for application consumption or MCData client consumption |
| Application identifier (see NOTE 2) | O | Identifies the application for which the payload is intended (e.g. text string, port address, URI) |
| Application metadata container | O | Implementation specific information that is communicated to the recipient |
| Payload | M | SDS content |
|
NOTE 1:
This information element shall be included for the MCData emergency communication.
NOTE 2:
The application identifier shall be included only if the payload destination type indicates that the payload is for application consumption.
|
||
7.4.3.2.2 MCData data disposition notification p. 91
Table 7.4.3.2.2-1 describes the information flow for the MCData data disposition notification sent from the MCData client to another MCData client.
| Information Element | Status | Description |
|---|---|---|
| MCData ID | M | The identity of the MCData user towards which the notification is sent |
| MCData ID | M | The identity of the MCData user sending notification |
| Conversation Identifier | M | Identifies the conversation |
| Reply Identifier | M | Identifies the original MCData transaction to which the current transaction is a reply to |
| Disposition | M | Disposition which is delivered or read or both |
| Payload Destination Type | M | Indicates whether the SDS payload is for application consumption or MCData user consumption |
7.4.3.2.3 MCData group standalone data request p. 91
Table 7.4.3.2.3-1 describes the information flow for the MCData group standalone data request sent from the MCData client to another MCData client.
| Information Element | Status | Description |
|---|---|---|
| MCData ID | M | The identity of the MCData user sending data |
| MCData group ID | M | The MCData group ID to which the data is to be sent |
| Date and Time | M | Date and time of transmission |
| Conversation Identifier | M | Identifies the conversation |
| Transaction Identifier | M | Identifies the MCData transaction |
| Reply Identifier | O | Identifies the original MCData transaction to which the current transaction is a reply to |
| Disposition Type | O | Indicates the disposition type expected from the receiver (i.e., delivered or read or both) |
| Emergency indicator (see NOTE 1) | O | Indicates that the MCData communication is an MCData emergency communication |
| Imminent peril indicator (see NOTE 1) | O | Indicates that the MCData communication is an MCData imminent peril communication |
| Payload Destination Type | M | Indicates whether the payload is for application consumption or MCData client consumption |
| Application identifier (see NOTE 2) | O | Identifies the application for which the payload is intended (e.g. text string, port address, URI) |
| Application metadata container | O | Implementation specific information that is communicated to the recipient |
| Payload | M | SDS content |
|
NOTE 1:
If used, only one of these information elements shall be present.
NOTE 2:
The application identifier shall be included only if the payload destination type indicates that the payload is for application consumption.
|
||
7.4.3.3 One-to-one standalone short data service using signalling control plane p. 92
7.4.3.3.1 General p. 92
This subclause describes the detailed procedures for the scenario where SDS data is to be sent to MCData user in off-network.
7.4.3.3.2 Procedure p. 92
Figure 7.4.3.3.2-1 describes procedures for an off-network MCData client 1 initiating one-to-one MCData data communication for sending standalone SDS data to other MCData client, with or without disposition request. Standalone refers to sending unidirectional data in one transaction. The SDS data size is assumed to be pre-configured.
Pre-conditions:
- MCData user 1 has initiated communication for sending standalone SDS data to other MCData user 2.
- MCData client 1 and MCData client 2 are members of the same ProSe Discovery group and are ProSe 1:1 direct communication capable.
- MCData client 1 has discovered MCData client 2 in proximity, associated with MCData user B, using ProSe Discovery procedures.
Step 1.
MCData client 1 checks whether the MCData user 1 is authorized to send MCData standalone data request.
Step 2.
If MCData user 1 is authorised MCData client 1 sends a MCData standalone data request towards the MCData client 2. The MCData standalone data request contains conversation identifier for message thread indication. The MCData standalone data request may include additional implementation specific information in the application metadata container. The MCData standalone data request may contain disposition request if indicated by the user at MCData client 1. If MCData user at the MCData client 1 initiates an MCData emergency communication, then emergency indicator is included in the MCData standalone data request. If an MCData emergency state is not set already when MCData emergency communication is initiated, the MCData client 1 sets its MCData emergency state and is retained until explicitly cancelled. The value of ProSe Per Packet Priority is upgraded according to the state of the MCData communication.
Step 3.
On receiving a MCData standalone data request, the MCData client 2 checks whether any policy is to be asserted to limit certain types of message or content to certain members due, for example, to location or user privilege.
Step 4.
If the policy assertion is positive and the payload is for MCData user consumption (e.g. is not application data, is not command instructions, etc.) then the MCData user of MCData client 2 may be notified. Otherwise if the payload is not for MCData user consumption, then the MCData user of MCData client 2 shall not be notified. The action taken when the payload contains application data or command instructions are specific based on the contents of the payload. Payload content received by MCData client 2 which is addressed to a known local non-MCData application that is not yet running shall cause the MCData client 2 to start the local non-MCData application (i.e., remote start application) and shall pass the payload content to the just started application.
Step 5.
If the MCData data disposition for delivery was requested by the user at MCData client 1, then the receiving MCData client 2 initiates a MCData data disposition notification for delivery report.
Step 6.
If the MCData data disposition for read was requested by the user at MCData client 1, then once the receiving user reads the data, the receiving MCData client 2 initiates a MCData data disposition notification for read report.
7.4.3.4 Group standalone short data service using signalling control plane p. 93
7.4.3.4.1 General p. 93
The initiation of a group standalone SDS to a selected group results in off-network MCData group members receiving the SDS data.
7.4.3.4.2 Procedure p. 94
Figure 7.4.3.4.2-1 describes procedures for an off-network MCData client 1 initiating group MCData data communication for sending SDS data to a MCData group, with or without disposition request. The SDS data size limit is pre-configured.
Pre-conditions:
- MCData user 1 has initiated group communication for sending SDS data to the MCData group.
- Information for ProSe direct communications corresponding to the MCData group and its mapping to ProSe Layer-2 Group ID are pre-configured in MCData client 1.
- MCData client 1 to MCData client N are members of the same MCData group.
Step 1.
MCData client 1 checks whether the MCData user 1 is authorized to send MCData group standalone data request.
Step 2.
If MCData user 1 is authorised MCData client 1 sends a MCData group standalone data request towards the MCData group. The MCData group standalone data request contains conversation identifier for message thread indication. The MCData group standalone data request may include additional implementation specific information in the application metadata container. The MCData group standalone data request may contain disposition request if indicated by the user at MCData client 1. If MCData group standalone data request contains disposition request, MCData group standalone data request shall also contain the IP address of the MCData client 1. If MCData user at the MCData client 1 initiates an MCData emergency communication, then the emergency indicator or the imminent peril indicator is included in the MCData standalone data request. If an MCData emergency state is not set already when MCData emergency communication is initiated, the MCData client 1 sets its MCData emergency state and is retained until explicitly cancelled. The value of ProSe Per Packet Priority is upgraded according to the state of the MCData communication.
Step 3.
On receiving a MCData group standalone data request, the MCData clients check whether any policy is to be asserted to limit certain types of message or content to certain members due, for example, to location or user privilege.
Step 4.
If the policy assertion is positive and the payload is for MCData user consumption (e.g. is not application data, is not command instructions, etc.) then the MCData user may be notified. Otherwise if the payload is not for MCData user consumption, then the MCData user shall not be notified. The action taken when the payload contains application data or command instructions are specific based on the contents of the payload. Payload content received by MCData clients 2 to N which is addressed to a known local non-MCData application that is not yet running shall cause the MCData clients 2 to N to start the local non-MCData application (i.e., remote start application) and shall pass the payload content to the just started application.
Step 5.
If the MCData data disposition for delivery was requested by the user at MCData client 1, then the receiving MCData clients initiate a MCData data disposition notification for delivery report.
Step 6.
If the MCData data disposition for read was requested by the user at MCData client 1, then once the receiving user reads the data, the receiving MCData clients 2 to N initiate a MCData data disposition notification for read report.
7.4.3.5 Void
7.4.3.6 Group standalone short data service with MCData message store |R16| p. 95
7.4.3.6.1 General p. 95
A MCData user's off-network communication needs to be part of his communication history when the MCData user has an account in the MCData message store.
7.4.3.6.2 Procedure p. 95
Figure 7.4.3.6.2-1 describes procedures of a MCData user, MCData user 2, that has an account in MCData message store and how his off-network SDS group communication is stored in his account in the MCData message store. All other MCData clients in the Figure follow the procedures described in subclause 7.4.3.4.
Pre-conditions:
- MCData user 1 to N are in an off-network group communication.
- Information for ProSe direct communications corresponding to the MCData group and its mapping to ProSe Layer-2 Group ID are pre-configured to MCData client 1 to N.
- MCData client 1 to N are members of the same MCData group.
- MCData user 2 has an account in the MCData message store.
Step 1.
The message store client 2 uploads the off-network communication objects from the local message store to the MCData message store.
MCData client 1 to MCData client N are in an off-network group communication according to the procedures in subclause 7.4.3.4, SDS are exchanged among all MCData clients.
Step 2.
If the SDS is for MCData user consumption, the SDS is stored in the local message store on the MCData UE of MCData user 2.
Step 3.
The off-network group communication comes to an end.
Step 4.
The MCData user 2 connects back to the network.
Step 5.
The MCData user 2 decides to keep the off-network communication in his account on the MCData message store.
