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.2  One-to-one standalone short data service using signalling control planep. 67

7.4.2.2.1  Generalp. 67
A MCData user initiates a standalone SDS data transfer with another MCData user. For the SDS data transfer signalling plane is used. The target MCData user may be addressed using the functional alias that can be shared with other MCData users.
7.4.2.2.2  Procedurep. 67
The procedure in Figure 7.4.2.2.2-1 describes the case where an MCData user is initiating one-to-one MCData data communication for sending standalone SDS data to other MCData user, with or without disposition request. Standalone refers to sending unidirectional data in one transaction.
Pre-conditions:
  1. The SDS payload data size is below the configured maximum payload data size for SDS over signalling control plane.
  2. MCData users on MCData client 1 and MCData client 2 are already registered for receiving MCData service.
  3. MCData client 1 and MCData client 2 belong to the same MCData system.
  4. Optionally, the MCData client may have activated functional alias to be used.
  5. 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.2.2-1: One-to-one standalone short data service using signalling control plane
Up
Step 1.
The user at MCData client 1 initiates an SDS data transfer for the chosen MCData user.
Step 2.
MCData client 1 sends a MCData standalone data request towards the MCData server. 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. MCData user at MCData client 1 may include a functional alias within the SDS data transfer and addresses the target MCData client 2 using a functional alias.
  1. If the MCData user at the MCData client 1 initiates an MCData emergency short data service communication or MCData emergency state is already set for the MCData client 1 (due to previously triggered MCData emergency alert):
    1. The MCData standalone data request shall contain emergency indicator; and
    2. If MCData emergency state is not set already, MCData client 1 sets its MCData emergency state. The MCData emergency state of MCData client 1 is retained until explicitly cancelled by the user of MCData client 1.
Step 3.
MCData server checks whether the MCData user at MCData client 1 is authorized to send MCData standalone data request. MCData server verifies whether the provided functional alias of MCData client 1, if present, can be used and has been activated for the user. 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. If functional alias is used to address that target MCData user, the MCData server resolves the functional alias to the corresponding MCData ID(s) for which the functional alias is active and proceed with step 4 otherwise proceed with step 6. The MCData server allows only two participating MCData clients for a standalone short data service.
Step 4.
The MCData server responds back to MCData client 1 with a functional alias resolution response message that contains the resolved MCData ID.
Step 5.
If the MCData server replies with a MCData functional alias resolution response message, the MCData client 1 assumes the MCData standalone data request in step 2 is rejected and sends a new MCData standalone data request towards the resolved MCData ID.
Step 6.
MCData server initiates the MCData standalone data request towards the MCData user that is determined based on step 3. The MCData standalone data request towards the MCData user contains the emergency indicator if it is present in the received MCData standalone data request from MCData client 1.
Step 7.
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 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 8.
If the MCData data disposition for delivery was requested by the user at MCData client 1, then the receiving MCData client initiates a MCData data disposition notification for delivery report. The MCData data disposition notification from MCData client may be stored by the MCData server for disposition history interrogation from authorized MCData users.
Step 9.
MCData data disposition notification is sent to the disposition requesting user at MCData client 1.
Step 10.
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. The MCData data disposition notification from MCData client 2 may be stored by the MCData server for disposition history interrogation from authorized MCData users.
Step 11.
MCData data disposition notification is sent to the disposition requesting user at MCData client 1.
Up

7.4.2.3  One-to-one standalone short data service using media planep. 69

7.4.2.3.1  Generalp. 69
A MCData user initiates a standalone SDS data transfer with another MCData user. For the SDS data transfer media plane is used. The target MCData user may be addressed using the functional alias that can be shared with other MCData users.
7.4.2.3.2  Procedurep. 70
The procedure in Figure 7.4.2.3.2-1 describes the case where an MCData user is initiating one-to-one MCData data communication for sending standalone SDS data to other MCData user, with or without disposition request. Standalone refers to sending unidirectional data in one transaction. The SDS payload data size is assumed to be above the configured maximum payload data size for SDS over signalling control plane.
Pre-conditions:
  1. MCData users on MCData client 1 and MCData client 2 are already registered for receiving MCData service.
  2. MCData client 1 and MCData client 2 belong to the same MCData system.
  3. Optionally, the MCData client may have an activated functional alias to be used.
  4. 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.3.2-1: One-to-one standalone short data service using media plane
Up
Step 1.
User at MCData client 1 would like to initiate an SDS data transfer request for the chosen MCData user.
Step 2.
MCData client 1 sends a MCData standalone session data request towards the MCData server. The MCData standalone session data request contains one MCData user for one-to-one data communication as selected by the user at MCData client 1. The MCData standalone session data request contains conversation identifier for message thread indication. The MCData standalone session data request may include additional implementation specific information in the application metadata container. The MCData 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 and addresses the target MCData client 2 using a functional alias.
  1. If the MCData user at the MCData client 1 initiates an MCData emergency short data service communication or MCData emergency state is already set for the MCData client 1 (due to previously triggered MCData emergency alert):
    1. The MCData standalone session data request shall contain emergency indicator; and
    2. If MCData emergency state is not set already, MCData client 1 sets its MCData emergency state. The MCData emergency state of MCData client 1 is retained until explicitly cancelled by the user of MCData client 1.
Step 3.
MCData server checks whether the MCData user at MCData client 1 is authorized to send MCData standalone session data request. MCData server verifies whether the provided functional alias of MCData client 1, if present, can be used and has been activated for the user. 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 determines the eligible MCData user(s) after policy assertion for sending the MCData standalone session data request. If functional alias is used to address that target MCData user, the MCData server resolves the functional alias to the corresponding MCData ID(s) for which the functional alias is active and proceed with step 4 otherwise proceed with step 6. The resulting list contains all associated MCData IDs/MCData users that share this functional alias. The MCData server allows only two participating MCData clients for a standalone short data service.
Step 4.
The MCData server responds back to MCData client 1 with a functional alias resolution response message that contains the resolved MCData ID.
Step 5.
If the MCData server replies with a MCData functional alias resolution response message, the MCData client 1 abandons the MCData standalone session data request in step 2 and sends a new MCData standalone session data request towards the resolved MCData ID.
Step 6.
MCData server initiates the MCData standalone session data request towards the MCData users determined. The MCData standalone session data request towards the MCData user contains an emergency indicator if it is present in the received MCData standalone session data request from MCData client 1.
Step 7.
The receiving MCData client 2 automatically accepts the MCData standalone session data request and responds with MCData standalone session data response towards MCData server.
Step 8.
MCData server forwards the MCData client 2 accepted response to the MCData Client 1 initiating the MCData standalone session data request.
Step 9.
MCData client 1 and MCData client 2 have successfully established media plane for data communication and the MCData client 1 transmits the SDS data.
Step 10.
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 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 11.
If the MCData data disposition for delivery was requested by the user at MCData client 1, then the receiving MCData client initiates a MCData data disposition notification for delivery report. The MCData data disposition notification from MCData client 2 may be stored by the MCData server for disposition history interrogation from authorized MCData users.
Step 12.
MCData data disposition notification is sent to the disposition requesting user at MCData client 1.
Step 13.
If the MCData 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 disposition notification for read report. The MCData data disposition notification from MCData client 2 may be stored by the MCData server for disposition history interrogation from authorized MCData users.
Step 14.
MCData data disposition notification is sent to the disposition requesting user at MCData client 1.
Up

7.4.2.4  One-to-one short data service sessionp. 72

7.4.2.4.1  Generalp. 72
A MCData user triggers an establishment of a MCData session with another MCData user for the exchange of SDS data. The target MCData user may be addressed using the functional alias that can be shared with other MCData users.
7.4.2.4.2  Procedurep. 72
The procedure in Figure 7.4.2.4.2-1 describes the case where an MCData user is initiating data communication session with another MCData user for exchanging at least one SDS data transaction between them, with or without disposition request using MCData-SDS-1 and MCData-SDS-2 or MCData-SDS-3 reference points.
Pre-conditions:
  1. MCData users on MCData client 1 and MCData client 2 are already registered for receiving MCData service.
  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.4.2-1: One-to-one short data service session
Up
Step 1.
User at MCData client 1 would like to initiate an SDS data communication session request for the chosen MCData user.
Step 2.
MCData client 1 sends a MCData session data request towards the MCData server. The MCData session data request contains one MCData user for one-to-one data communication as selected by the user at MCData client 1. The MCData session 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. MCData user at MCData client 1 may include a functional alias within the SDS data transfer and addresses the target MCData client 2 using a functional alias.
  1. If the MCData user at the MCData client 1 initiates an MCData emergency short data service communication or MCData emergency state is already set for the MCData client 1 (due to previously triggered MCData emergency alert):
    1. The MCData session data request shall contain emergency indicator; and
    2. If MCData emergency state is not set already, MCData client 1 sets its MCData emergency state. The MCData emergency state of MCData client is retained until explicitly cancelled by the user of MCData client 1.
Step 3.
MCData server checks whether the MCData user at MCData client 1 is authorized to send MCData session data request. 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 determines the eligible MCData user(s) after policy assertion for sending the MCData session data request. MCData server also verifies whether the provided functional alias of MCData client 1, if present, can be used and has been activated for the user. If functional alias is used to address that target MCData user, the MCData server resolves the functional alias to the corresponding MCData ID(s) for which the functional alias is active and proceed with step 4 otherwise proceed with step 6. The MCData server allows only two participating MCData clients for a standalone short data service.
Step 4.
The MCData server responds back to MCData client 1 with a functional alias resolution response message that contains the resolved MCData ID.
Step 5.
If the MCData server replies with a MCData functional alias resolution response message, the MCData client 1 abandons the MCData session data request in step 2 and sends a new MCData session data request towards the resolved MCData ID.
Step 6.
MCData server initiates the MCData session data request towards the MCData users determined. The MCData session data request towards the MCData user contains the emergency indicator if it is present in the received MCData session data request from MCData client 1.
Step 7.
If the emergency indicator is present, the receiving MCData client 2 notifies the user about the incoming MCData session data request.
Step 8.
The receiving MCData client 2 accepts the MCData session data request and responds with MCData session data response towards MCData server.
Step 9.
MCData server forwards the MCData client 2 accepted response to the MCData user initiating the MCData session data request.
Step 10 and 11.
MCData client 1 and MCData client 2 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 MCData data disposition was requested by the user, then the receiving MCData client initiates a MCData data disposition notification for delivery, read reports to the disposition requesting user. The MCData data disposition notification from MCData user may be stored by the MCData server for disposition history interrogation from authorized users.
Step 12 and 13.
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 may be notified, otherwise the MCData user of MCData client 2 shall not be notified.
Step 14.
After SDS data transaction is complete, the established media plane is released.
Up

Up   Top   ToC