Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 23.282  Word version:  18.2.0

Top   Top   Up   Prev   Next
1…   5…   6…   6.6…   7…   7.4…   7.4.2.1.10…   7.4.2.2…   7.4.2.5…   7.4.2.8…   7.4.3…   7.5…   7.5.2.1.12…   7.5.2.2…   7.5.2.4…   7.5.2.6…   7.5.2.8…   7.5.2.11…   7.5.2.14…   7.5.3…   7.6   7.7…   7.7.2.3…   7.8…   7.9…   7.13…   7.13.3.1.19…   7.13.3.2…   7.13.3.8…   7.13.3.16…   7.13.4…   7.14…   7.14.2.2…   A…   B…

 

7.4.2.5  Group standalone short data service using signalling control planep. 74

7.4.2.5.1  Generalp. 74
The initiation of a group standalone SDS to a selected group results in affiliated group members receiving the SDS data. The SDS payload data size is assumed to be below the configured maximum payload data size for SDS over signalling control plane.
7.4.2.5.2  Procedurep. 74
The procedure in Figure 7.4.2.5.2-1 describes the case where an MCData user is initiating group standalone MCData data communication with or without disposition request, to a group.
Pre-conditions:
  1. MCData users on MCData clients 1 to n belong to the same group and are already registered for receiving MCData service and affiliated.
  2. Optionally, the MCData client may have activated functional alias to be used.
  3. The MCData server may have subscribed to the MCData functional alias controlling server within the MC system for functional alias activation/de-activation updates.
Copy of original 3GPP image for 3GPP TS 23.282, Fig. 7.4.2.5.2-1: Group standalone SDS using signalling control plane
Up
Step 1.
The user at MCData client 1 initiates an SDS data transfer to multiple MCData users selecting a pre-configured group (identified by MCData group ID) and optionally particular members from that group.
Step 2.
MCData client 1 sends a MCData group standalone data request towards the MCData server. The MCData group data request contains MCData group ID as selected by the user at MCData client 1. The MCData group standalone data request contains conversation identifier for message thread indication. The MCData session 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. MCData user at MCData client 1 may include a functional alias within the SDS data transfer.
If the MCData user at MCData client 1 initiates an MCData emergency short data service communication or the MCData emergency state is already set for the MCData client 1 (due to a previously triggered MCData emergency alert):
  1. the MCData group standalone data request shall contain an emergency indicator;
  2. the MCData group standalone data request shall set an alert indicator if configured to send an MCData emergency alert while initiating an MCData standalone data request for the emergency short data service communication;
  3. if the MCData emergency state is not set already, MCData client 1 sets its MCData emergency state. The MCPTT emergency state is retained until explicitly cancelled; and
  4. once an MCData emergency communication has been initiated, the MCData group is considered to be in an in-progress emergency state until cancelled.
If the MCData user at MCData client 1 initiates an MCData imminent peril short data service communication:
  1. the MCData group standalone data request shall contain imminent peril indicator; and
  2. once an MCData imminent peril communication has been initiated, the MCData group is considered to be in an in-progress imminent peril state until cancelled.
Step 2a.
If either emergency indicator or imminent peril indicator is present in the received MCData group standalone data request, the MCData server implicitly affiliates MCData client 1 to the MCData group if the client is not already affiliated.
Step 3.
MCData server checks whether the MCData user at MCData client 1 is authorized to send MCData group standalone data request. The MCData server resolves the MCData group ID to determine the members of that group and their affiliation status, based on the information from the group management server. The MCData server also 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 or affiliation. MCData server also verifies whether the provided functional alias, if present, can be used and has been activated for the user.
  1. If an emergency indicator is present in the received MCData group standalone data request and if the MCData group is not in the in-progress emergency state, the MCData group is considered to be in the in-progress emergency state until cancelled; and
  2. If an imminent peril indicator is present in the received MCData group standalone data request and if the MCData group is not in the in-progress imminent peril state, the MCData group is considered to be in the in-progress imminent peril state until cancelled.
Step 4.
MCData server initiates the MCData group standalone data request towards each MCData client determined in Step 3. The MCData ID list shall not be included in a unicast downlink delivery to an individual MCData client. The Disposition Type IE shall not be included in a unicast downlink delivery to MCData clients who are not in the MCData ID list in step 2. The MCData group standalone data request towards each MCData client contains:
  1. an emergency indicator, if it is present in the received MCData group standalone data request from the MCData client 1;
  2. an imminent peril indicator, if it is present in the received MCData group standalone data request from the MCData client 1; and
  3. an alert indicator, if requested to initiate an emergency alert in the received MCData group standalone data request from the MCData client 1.
Step 5.
If the payload is for MCData user consumption (e.g. is not application data, is not command instructions, etc.) then the MCData user of MCData clients 2 to n may be notified. Otherwise if the payload is not for MCData user consumption, then the MCData user of MCData clients 2 to n 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 6.
If the MCData data disposition for delivery was requested by the user at MCData client 1, then the receiving MCData client(s) initiates a MCData data disposition notification for delivery report.
Step 7.
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.
Step 8.
The MCData data disposition notification(s) from MCData client may be stored by the MCData server for disposition history interrogation from authorized MCData users. The MCData data disposition notification(s) from each MCData user may be aggregated.
Step 9.
Aggregated or individual MCData data disposition notification(s) is sent to the disposition requesting user at MCData client 1.
Up

7.4.2.6  Group standalone short data service using media planep. 77

7.4.2.6.1  Generalp. 77
The initiation of a group standalone SDS to a selected group results in affiliated group members receiving the SDS data. The SDS payload data size is assumed to be above the configured maximum payload data size for SDS over signalling control plane.
7.4.2.6.2  Procedurep. 77
The procedure in Figure 7.4.2.6.2-1 describes the case where an MCData user is initiating group standalone MCData data communication with or without disposition request to a group.
Pre-conditions:
  1. MCData users on MCData client 1 to n belong to the same group and are already registered for receiving MCData service and affiliated.
  2. Optionally, the MCData client may have activated functional alias to be used.
  3. The MCData server may have subscribed to the MCData functional alias controlling server within the MC system for functional alias activation/de-activation updates.
Copy of original 3GPP image for 3GPP TS 23.282, Fig. 7.4.2.6.2-1: Group standalone SDS using media plane
Up
Step 1.
User at MCData client 1 would like to initiate a SDS data transfer request to multiple MCData users selecting a pre-configured group (identified by MCData group ID) and optionally particular members from that group.
Step 2.
MCData client 1 sends a MCData group session standalone data request towards the MCData server. The MCData group session standalone data request contains target recipient(s) as selected by the user at MCData client 1. The MCData session group standalone data request contains conversation identifier for message thread indication. The MCData session group standalone data request may include additional implementation specific information in the application metadata container. The MCData session group standalone data request may contain disposition request if indicated by the user at MCData client 1. MCData user at MCData client 1 may include a functional alias within the SDS data transfer.
If the MCData user at MCData client 1 initiates an MCData emergency short data service communication or the MCData emergency state is already set for MCData client 1 (due to a previously triggered MCData emergency alert):
  1. the MCData group session standalone data request shall contain an emergency indicator;
  2. the MCData group session standalone data request shall set the alert indicator if configured to send an MCData emergency alert while initiating an MCData standalone data request for the emergency short data service communication;
  3. if the MCData emergency state is not set already, MCData client 1 sets its MCData emergency state. The MCPTT emergency state is retained until explicitly cancelled; and
  4. once an MCData emergency communication has been initiated, the MCData group is considered to be in an in-progress emergency state until cancelled.
If the MCData user at MCData client 1 initiates an MCData imminent peril short data service communication:
  1. the MCData group session standalone data request shall contain an imminent peril indicator; and
  2. once an MCData imminent peril communication has been initiated, the MCData group is considered to be in an in-progress imminent peril state until cancelled.
Step 2a.
If either an emergency indicator or an imminent peril indicator is present in received MCData group session standalone data request, the MCData server implicitly affiliates MCData client 1 to the MCData group if the client is not already affiliated.
Step 3.
MCData server checks whether the MCData user at MCData client 1 is authorized to send MCData session group standalone data request. The MCData server resolves the MCData group ID to determine the members of that group and their affiliation status, based on the information from the group management server. The MCData server also 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. MCData server also verifies whether the provided functional alias, if present, can be used and has been activated for the user.
  1. if an emergency indicator is present in the received MCData group session standalone data request and if the MCData group is not in the in-progress emergency state, the MCData group is considered to be in the in-progress emergency state until cancelled; and
  2. if an imminent peril indicator is present in the received MCData group session standalone data request and if the MCData group is not in the in-progress imminent peril state, the MCData group is considered to be in the in-progress imminent peril state until cancelled.
Step 3a.
The MCData server configures the priority of the underlying bearers for all participants in the MCData group.
Step 4.
MCData server initiates the MCData group session standalone data request towards each MCData user determined in Step 3. The MCData ID list shall not be included in a unicast downlink delivery to an individual MCData client. The Disposition Type IE shall not be included in a unicast downlink delivery to MCData clients who are not in the MCData ID list in step 2. The MCData group session standalone data request towards each MCData client contains:
  1. an emergency indicator, if it is present in the received MCData group session standalone data request from the MCData client 1;
  2. an imminent peril indicator, if it is present in the received MCData group session standalone data request from the MCData client 1; and
  3. an alert indicator, if requested to initiate an emergency alert in the received MCData group session standalone data request from MCData client 1.
Step 5.
The receiving MCData clients 2 to n automatically accepts the MCData group session standalone data request and responds with MCData group standalone data response towards MCData server.
Step 6.
MCData server forwards the MCData clients 2 to n accepted response to the MCData user initiating the MCData group session standalone data request.
Step 7.
MCData client 1 and MCData server have successfully established media plane for data communication and the MCData client 1 transmits the SDS data.
Step 8.
MCData server distributes the data received from MCData client 1 to MCData clients 2 to n over the established media plane. After completion of the MCData transfer from MCData client 1, media plane resources associated to the data communication are released.
Step 9.
If 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 to n may be notified. Otherwise if the payload is not for MCData user consumption, then the MCData user of MCData client 2 to n 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 10.
If the MCData data disposition for delivery was requested by the user at MCData client 1, then the receiving MCData client(s) initiates a MCData data disposition notification for delivery report.
Step 11.
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.
Step 12.
The MCData data disposition notification(s) from MCData client may be stored by the MCData server for disposition history interrogation from authorized MCData users. The MCData data disposition notification(s) from each MCData user may be aggregated.
Step 13.
Aggregated or individual MCData data disposition notification(s) is sent to the disposition requesting user at MCData client 1.
Up

7.4.2.7  Group short data service sessionp. 80

7.4.2.7.1  Generalp. 80
The initiation of a group SDS to a selected group results in affiliated group members exchanging SDS data.
7.4.2.7.2  Procedurep. 80
The procedure in Figure 7.4.2.7.2-1 describes the case where an MCData user is initiating SDS data communication session with an MCData group for exchanging SDS data transactions between the group participants, with or without disposition request, using MCData-SDS-1 and MCData-SDS-2 reference points.
Pre-conditions:
  1. MCData users on MCData client 1 to n belong to the same group and are already registered for receiving MCData service and affiliated.
  2. Optionally, the MCData client may have activated functional alias to be used.
  3. The MCData server may have subscribed to the MCData functional alias controlling server within the MC system for functional alias activation/de-activation updates.
Copy of original 3GPP image for 3GPP TS 23.282, Fig. 7.4.2.7.2-1: Group SDS session
Figure 7.4.2.7.2-1: Group SDS session
(⇒ copy of original 3GPP image)
Up
Step 1.
User at MCData client 1 would like to initiate a SDS group data transfer request to multiple MCData users selecting a pre-configured group (identified by MCData group ID) and optionally particular members from that group.
Step 2.
MCData client 1 sends a MCData group data request towards the MCData server. The MCData group data request contains MCData group ID as selected by the user at MCData client 1. The MCData session data request contains conversation identifier for message thread indication. The MCData group data request may include additional implementation specific information in the application metadata container. MCData user at MCData client 1 may include a functional alias within the SDS data transfer.
If the MCData user at MCData client 1 initiates an MCData emergency short data service communication or the MCData emergency state is already set for the MCData client 1 (due to a previously triggered MCData emergency alert):
  1. the MCData group data request shall contain an emergency indicator;
  2. the MCData group data request shall set an alert indicator if configured to send an MCData emergency alert while initiating an MCData standalone data request for the emergency short data service communication; and
  3. if MCData emergency state is not set already, MCData client 1 sets its MCData emergency state. The MCPTT emergency state of MCData client 1 is retained until explicitly cancelled by the user of MCData client 1.
If the MCData user at MCData client 1 initiates an MCData imminent peril short data service communication:
  1. the MCData group data request shall contain an imminent peril indicator.
Step 2a.
If either emergency indicator or imminent peril indicator is present in received MCData group data request, the MCData server implicitly affiliates MCData client 1 to the MCData group if the client is not already affiliated.
Step 3.
MCData server checks whether the MCData user at MCData client 1 is authorized to send MCData group data request. The MCData server resolves the MCData group ID to determine the members of that group and their affiliation status, based on the information from the group management server. The MCData server also 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. MCData server also verifies whether the provided functional alias, if present, can be used and has been activated for the user.
  1. if an emergency indicator is present in the received MCData group data request and if MCData group is not in in-progress emergency state, the MCData group is considered to be in the in-progress emergency state until cancelled;
  2. if an imminent peril indicator is present in the received MCData group data request and if the MCData group is not in the in-progress imminent peril, the MCData group is considered to be in the in-progress imminent peril state until cancelled;
Step 3a.
The MCData server configures the priority of the underlying bearers for all participants in the MCData group.
Step 4.
MCData server initiates the MCData group data request towards each MCData user determined in Step 3. The MCData group data request towards each MCData client contains:
  1. an emergency indicator if it is present in the received MCData group data request from the MCData client 1;
  2. an imminent peril indicator if it is present in the received MCData group data request from the MCData client 1; and
  3. an alert indicator if requested to initiate an emergency alert in the received MCData group data request from MCData client 1;
Step 5.
The receiving MCData clients 2 to n optionally notify the user about the incoming MCData session data request.
Step 6.
The receiving MCData client 2 to n accept or reject the MCData group data request and the corresponding result is in the MCData group data response towards MCData server.
Step 7.
MCData server forwards the MCData group data response received from MCData client 2 to n to the MCData user initiating the MCData session data request.
Step 8.
MCData client 1 and the MCData group data request accepted clients have successfully established media plane for data communication and either MCData client can transmit SDS data. The MCData data request may contain disposition request if indicated by the client sending data. If the payload is for MCData user consumption (e.g. is not application data, is not command instructions, etc.) then the SDS data receiving MCData users may be notified, otherwise those MCData users shall not be notified.
Step 9.
If MCData data disposition was requested by the user, then the SDS data receiving MCData client initiates a MCData data disposition notification for delivery, read reports to the disposition requesting user. The MCData data disposition notification from the receiving MCData clients may be stored by the MCData server for disposition history interrogation from authorized users.
Step 10.
Based on the MCData user action or conditions to release, the established media plane for SDS data exchange is released.
Up

Up   Top   ToC