Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 23.282  Word version:  19.0.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…   7.17…   7.17.3…   7.17.3.2…   7.17.4…   7.17.6…   A…   B… 
7 Procedures and information flows  7.1 MCData service configuration  7.2 Affiliation and de-affiliation to/from MCData group(s)  7.3 Use of MBMS transmission (on-network)  7.3.1 Information flows for MBMS Transmission  7.3.2 Use of pre-established MBMS bearers  7.3.3 Use of dynamic MBMS bearer establishment  7.3.4 Switching from MBMS bearer to unicast bearer  7.3.5 Use of MBMS user services for file distribution  7.3.6 Group communication connect and disconnect over MBMS bearer procedures 
...

 

7  Procedures and information flows  p. 44

7.1  MCData service configuration  p. 44

The MCData service shall support the procedures and related information flows as specified in subclause 10.1 of TS 23.280 and Annex A of TS 23.280 with the following clarifications:
  • The MC service client is the MCData client;
  • The MC service server is the MCData server;
  • The MC service ID is the MCData ID; and
  • The MC service user profile index is the MCData user profile index.
Up

7.2  Affiliation and de-affiliation to/from MCData group(s)  p. 44

The MCData service shall support the procedures and related information flows as specified in subclause 10.8 of TS 23.280 with the following clarifications:
  • The MC service client is the MCData client;
  • The MC service server is the MCData server;
  • The MC service group is the MCData group;
  • The MC service ID is the MCData ID; and
  • The MC service group ID is the MCData group ID.
When an MCData user has affiliated to an MCData group then the MCData user can send and receive MCData related media for that MCData group. When an MCData user has de affiliated from an MCData group then the MCData user cannot send and receive MCData related media to and from that MCData group.
Up

7.3  Use of MBMS transmission (on-network)  p. 45

7.3.1  Information flows for MBMS Transmission  p. 45

Information flows for generic MBMS procedures are defined in TS 23.280.

7.3.2  Use of pre-established MBMS bearers  p. 45

The MCData service shall support the procedure for using pre-established MBMS bearers as specified in TS 23.280 with the following clarifications:
  • The MC service client is the MCData client;
  • The MC service server is the MCData server; and
  • The MC service ID is the MCData ID.
The MCData service shall use the MCData-6, MCData-SDS-1, MCData-SDS-2, MCData-SDS-3, MCData-FD-1, MCData-FD-3, MCdata-DS-1 and MCData-DS-3 reference points for this procedure.
MCData may use pre-established MBMS bearer for the MCData features short data service, file distribution and data streaming. The MBMS bearer can be used by any group. Depending on the capacity of the MBMS bearer, the bearer can be used to broadcast one or more services in parallel.
Both the media packets as well as application level control signalling (e.g. transmission control) to the receiving users may be sent on the MBMS bearer. Optionally, a separate MBMS bearer could be used for the application level control signalling (e.g. transmission control), due to different bearer characteristic requirements.
Up

7.3.3  Use of dynamic MBMS bearer establishment  p. 45

The MCData service shall support the procedure for using dynamic MBMS bearers as specified TS 23.280 with the following clarifications:
  • The MC service client is the MCData client;
  • The MC service server is the MCData server; and
  • The MC service ID is the MCData ID.
The MCData service shall use the MCData-6, MCData-SDS-1, MCData-SDS-3, MCData-FD-1, MCData-FD-3, MCData-DS-1 and MCData-DS-3 reference points for this procedure.
MCData may use dynamic MBMS bearer for the MCData features short data service, file distribution and data streaming. The MBMS bearer can be used by any group. Depending on the capacity of the MBMS bearer, the bearer can be used to broadcast one or more services in parallel.
Both the media packets as well as application level control signalling (e.g. transmission control) to the receiving users may be sent on the MBMS bearer. Optionally, a separate MBMS bearer could be used for the application level control signalling (e.g. transmission control), due to different bearer characteristic requirements.
Up

7.3.4  Switching from MBMS bearer to unicast bearer  p. 45

The MCData service shall support the procedure for switching from MBMS bearer to unicast bearer as specified TS 23.280 with the following clarifications:
  • The MC service client is the MCData client;
  • The MC service server is the MCData server; and
  • The MC service ID is the MCData ID.
The MCData service shall use the MCData-SDS-1, MCData-SDS-2, MCData-FD-1, MCData-FD-3, MCData-DS-1 and MCData-DS-3 reference points for this procedure.

7.3.5  Use of MBMS user services for file distribution |R16|  p. 46

7.3.5.1  General  p. 46

This subclause defines information flows and procedures for usage of MBMS user services that applies to MCData file distribution. MBMS user services can be used for any MC service group.
The MBMS user service architecture is described in TS 26.346.

7.3.5.2  Information flows for MBMS user service usage  p. 46

7.3.5.2.1  MBMS user service announcement  p. 46
Table 7.3.5.2.1-1 describes the information flow MBMS bearer announcement from the MCData server to the MCData client.
Information Element Status Description
MBMS user service idMId of the MBMS user service
SA fileM The service announcement file as returned in the create/update session response (subclause 5.4 in TS 26.348) (see NOTE)
Monitoring stateOThe monitoring state is used to control if the client is actively monitoring the reception quality or the MBMS bearer used by the MBMS user service.
Unicast statusOAn indication that the listening status of the unicast bearer is requested.
NOTE:
The SA file provides the TMGI, the list of MBMS service area identifiers, the frequency and the delivery parameters.
Up

7.3.5.3  Procedures for MBMS user service usage  p. 46

7.3.5.3.1  Use of pre-established MBMS user services  p. 46
7.3.5.3.1.1  General  p. 46
In this scenario, the MCData server pre-establishes MBMS user service(s) in certain pre-configured areas before the initiation of a group file distribution. When a user originates a request for a file distribution in one of these areas, the MCData server can use the pre-established MBMS user service(s) for the DL media transmission.
The MBMS user service can be announced prior to the file distribution or within the signalling message for the file distribution.
The MBMS user service does not transmit application level control signalling. An MBMS bearer could be used for the application level control messages according to the generic MBMS procedures defined in TS 23.280.
Up
7.3.5.3.1.2  Procedure  p. 46
The procedure in Figure 7.3.5.3.1.2-1 shows only one of the receiving MCData clients using an MBMS user service.
Pre-conditions:
  • The participating users are already affiliated.
Copy of original 3GPP image for 3GPP TS 23.282, Fig. 7.3.5.3.1.2-1: Use of pre-established MBMS user service
Figure 7.3.5.3.1.2-1: Use of pre-established MBMS user service
(⇒ copy of original 3GPP image)
Up
Step 1.
The MCData server determines to create an MBMS user service with a given MBMS user service id. If the MCData server makes use of the xMB interface, the MCData server creates an MBMS user service over xMB-C (subclause 5.3 from TS 26.348).
Step 2.
If the MCData server makes use of the xMB interface, the MCData server creates an MBMS session over xMB-C for the MBMS user service (subclause 5.4 from TS 26.348), with the type set to "Files" to use the MBMS download delivery method. Additionally, the MCData server defines the ingest mode, pull or push, to provide the file into the BM-SC via xMB-U. This MBMS session will be used for file distribution. In response, the MCData server gets the TMGI of the MBMS bearer used for the MBMS session, and the SA file containing the metadata of the MBMS user service. When the push ingest mode is used, as part of the response from the BM-SC the MCData server also obtains the URL to be used to push the file.
Step 3a.
Else, the MCData server activates an MBMS bearer over MB2-C for the MBMS user service.
Step 3b.
The MCData server, if not already in the possession of the SA file, generates the SA file containing the metadata of the MBMS user service.
Step 4.
The MCData server passes using control plane signalling the MBMS user service info for the service description associated with the pre-established MBMS user service to the MCData client. The MCData client obtains the TMGI, identifying the MBMS bearer, from the SA file included in the MBMS user service description.
Step 5.
The MCData client stores the information associated with the MBMS user service. The MCData client uses the TMGI and other MBMS user service related information to activate the monitoring of the MBMS bearer.
Step 6.
The MCData client that enters or is in the service area of at least one announced TMGI indicates to the MCData server that the MCData client is able to receive file distributed over MBMS, whereby the MCData server may decide to use this MBMS user service instead of unicast bearer for MC communication sessions.
Step 7.
If the MCData server makes use of the xMB interface and wants to deliver a file to a group, the MCData server updates the MBMS session to provide the file list when the pull ingest mode is defined. As described in TS 26.348, the file list includes, among other information, the file URL to be used by the BM-SC to fetch the file and the earliest fetch time.
Step 8.
The MCData server signals the file transmission over the MBMS user service to the targeted MCData clients.
Step 9.
The file, transmitted with the MBMS download delivery method, is received by the MCData clients. If the MCData server does not make use of the xMB interface, the MCData server fragments the file to be sent, applies error correction according to the MBMS download delivery method (TS 26.346) and sent the FLUTE packets over MB2-U.
Up
7.3.5.3.2  Use of dynamic MBMS user service establishment  p. 48
In this scenario depicted in Figure 7.3.5.3.2-1, the MCData server decides to establish an MBMS user service for the distribution of a given file. The MBMS user service is announced to the MCData client, together with the file information to be received.
Copy of original 3GPP image for 3GPP TS 23.282, Fig. 7.3.5.3.2-1: Use of dynamic MBMS user service establishment
Figure 7.3.5.3.2-1: Use of dynamic MBMS user service establishment
(⇒ copy of original 3GPP image)
Up
Step 1.
The MCData server determines to create a MBMS user service with a given an MBMS user service id for the group communication session. If the MCData server makes use of the xMB interface, the MCData server creates an MBMS user service over xMB-C (subclause 5.3 of TS 26.348).
Step 2.
If the MCData server makes use of the xMB interface, the MCData server creates a MBMS session for the MBMS user service (subclause 5.4 from TS 26.348), with the type set to "Files" to use the MBMS download delivery method. Additionally, the MCData server defines the ingest mode, pull or push, to provide the file into the BM-SC via xMB-U. When the pull ingest mode is defined, the MCData server provides the file list. The file list includes, among other information, the file URL to be used by the BM-SC to fetch the file and the earliest fetch time. In response, the MCData server gets the TMGI of the MBMS bearer used for the MBMS session and the SA file containing the metadata of the MBMS user service. When the pull ingest mode is defined, the MCData server also obtains the scheduling parameter for the file delivery. When the push ingest mode is used, as part of the response from the BM-SC the MCData server obtains the URL to be used to push the file.
Step 3a.
Else, the MCData server activates an MBMS bearer over MB2-C for the MBMS user service.
Step 3b.
The MCData server, if not already in the possession of the SA file, generates the SA file containing the metadata of the MBMS user service.
Step 4.
The MCData server passes using control plane signalling the SA file to the MCData client. The MCData client obtains the TMGI, identifying the MBMS bearer, from the SA file included in the MBMS user service description.
Step 5.
The MCData client stores the information associated with the MBMS user service. The MCData client uses the TMGI and other MBMS user service related information to activate the monitoring of the MBMS bearer.
Step 6.
The MCData client that enters or is in the service area of at least one announced TMGI indicates to the MCData server that the MCData client is able to receive file distributed over MBMS, whereby the MCData server may decide to use this MBMS user service instead of unicast bearer for MC communication sessions.
Step 7.
The MCData server signals the file transmission over the MBMS user service to the targeted MCData clients.
Step 8.
The file, transmitted with the MBMS download delivery method, is received by the MCData clients. If the MCData server does not make use of the xMB interface, the MCData server fragments the file to be sent, applies error correction according to the MBMS download delivery method (TS 26.346) and sent the FLUTE packets over MB2-U.
Up
7.3.5.3.3  Providing stored files in the MCData content server for distribution over MBMS |R17|  p. 49
7.3.5.3.3.1  General  p. 49
As described in clause 6.6.3.1.5, the MCData content server provides a repository area where authorized MCData users temporarily store files that are intended to be shared with other MCData users. The distribution of such files targeting a group of MCData users can be performed over MBMS.
For the case that the MBMS user service architecture is used over the xMB interface (specified in TS 26.348), two ingest modes, push and pull, can be defined by the MCData server to ingest the file into the BM-SC for distribution over the MBMS sessions.
Up
7.3.5.3.3.2  File fetching by the MCData server  p. 49
A file can be fetched by the MCData server from the MCData content server over the MCData-FD-5 reference point using the file URL provided by MCData users. The MCData server, thus, enables via the xMB-U interface that the file is ingested, either by pull or push, into the BM-SC for distribution over MBMS.
When the MCData server defines a pull ingest mode, the MCData server provides via the xMB-C interface the resource location from which the BM-SC will fetch the file as well as other session properties (e.g. file earliest fetch time), as described in TS 26.348.
When the MCData server defines a push ingest mode, the MCData server directly ingests into the BM-SC via the xMB-U interface the file obtained from the MCData content server. The BM-SC provides to the MCData server the URL to be used to push the file(s).
The procedure in Figure 7.3.5.3.3.2-1 describes the case where the file to be distributed over MBMS is fetched by the MCData server from the MCData content server.
Pre-conditions:
  • The MCData users on the MCData client 1 to n belong to the same MCData group and are already registered and affiliated for receiving MCData service.
  • The file to be distributed is uploaded to the MCData content server.
  • The BM-SC has the necessary permissions to fetch a file from the MCData system.
Copy of original 3GPP image for 3GPP TS 23.282, Fig. 7.3.5.3.3.2-1: File fetching by the MCData server for file distribution over MBMS
Figure 7.3.5.3.3.2-1: File fetching by the MCData server for file distribution over MBMS
(⇒ copy of original 3GPP image)
Up
Step 1.
The MCData server receives a request from the MCData client 1 to distribute a file to a target MCData group. The MCData file distribution request contains the resource location (i.e. the file URL) in the MCData content server.
Step 2.
The MCData server decides to fetch the file from the MCData content server via the MCData-FD-5 reference point.
Step 3.
The MCData server creates an MBMS service and session for file delivery using xMB procedures via the xMB-C interface, as described in TS 26.348. The MCData server indicates, among other session properties, the ingest mode. For the case of pull ingest mode, the MCData server provides the file URL from which the BM-SC will fetch the file. For the case of push ingest mode, the BM-SC provides to the MCData server the URL to be used to push the file into the MBMS session.
Step 4.
The MCData server provides to the MCData users from the target MCData group the application signalling related to the MBMS session and the file distribution.
Step 5a.
For the case that the file is ingested into the BM-SC based on the push ingest mode, the MCData server pushes the file to the URL indicated by the BM-SC.
Step 5b.
For the case that the file is ingested into the BM-SC based on the pull ingest mode, the BM-SC pulls the file from the provided file URL.
Step 6.
The BM-SC distributes the file over the established MBMS session. When the target MCData clients have activated the reception for that service and are located within the MBMS area coverage, the MCData clients receive the file.
Up
7.3.5.3.3.3  File fetching by the BM-SC  p. 51
When the MCData server defines a pull ingest mode, the MCData server can alternatively provide to the BM-SC the resource location in the MCData content server (i.e. the file URL contained within the received file distribution request). The BM-SC, thus, will directly fetch the file from the MCData content server.
The procedure in Figure 7.3.5.3.3.3-1 describes the case where the file to be distributed over MBMS is fetched by the BM-SC from the MCData content server.
Pre-conditions:
  • The MCData users on the MCData client 1 to n belong to the same MCData group and are already registered and affiliated for receiving MCData service.
  • The file to be distributed is uploaded to the MCData content server.
  • The BM-SC has the necessary permissions to fetch a file from the MCData system.
Copy of original 3GPP image for 3GPP TS 23.282, Fig. 7.3.5.3.3.3-1: File fetching by the BM-SC for file distribution over MBMS
Figure 7.3.5.3.3.3-1: File fetching by the BM-SC for file distribution over MBMS
(⇒ copy of original 3GPP image)
Up
Step 1.
The MCData server receives a request from the MCData client 1 to distribute a file to a target MCData group. The MCData file distribution request contains the resource location (i.e. the file URL) in the MCData content server.
Step 2.
The MCData server creates an MBMS service and session for file delivery using xMB procedures via the xMB-C interface, as described in TS 26.348. The MCData server defines, among other session properties, the ingest mode to pull. The MCData server provides the file URL from which the BM-SC will fetch the file from the MCData content server.
Step 3.
The MCData server provides to the MCData users from the target MCData group the application signalling related to the MBMS session and the file distribution.
Step 4.
The BM-SC fetches the file from the MCData content server via the xMB-U interface.
Step 5.
The BM-SC distributes the file over the established MBMS session. When the target MCData clients have activated the reception for that service and are located within the MBMS area coverage, the MCData clients receive the file.
Up

7.3.6  Group communication connect and disconnect over MBMS bearer procedures |R18|  p. 52

7.3.6.1  General  p. 52

MBMS bearer can be used for MCData group communication. One MBMS bearer is not permanently associated to one specific group or group communication. Before sending data packets of a group communication over MBMS bearer, the MCData server shall send the association information between group communication and the MBMS bearer. The group session setup procedure indicates the media stream within one MBMS bearer that is used for the specific group communication. When the group communication over the MBMS bearer is finished, this temporary association information of an MCPTT group communication to specific resources on a MBMS bearer is undone.The procedure in clause 7.3.6 requires that the group session is setup before the data transmission starts. This eliminates the need for the receiving clients to continuously use a unicast bearer. Prior to group session setup, the MBMS bearer is activated and announced to the MCData clients.
Up

7.3.6.2  Procedure  p. 53

The procedure in this clause uses an establishment of group communication as described in clause 7.4.2.7. Similary, the procedure defined in this clause is also applicable for the group communication established as described in clause 7.4.2.6.
7.3.6.2.1  Group communication connect over MBMS bearer  p. 53
Pre-conditions:
  • The MCData clients 1 to n are registered and affiliated to the same MCData group X.
  • The MCData server has decided to use an MBMS bearer for the MCData service group communication associated with to the MCData group X.
Copy of original 3GPP image for 3GPP TS 23.282, Fig. 7.3.6.2.1-1: Group communication connect on MBMS bearer
Figure 7.3.6.2.1-1: Group communication connect on MBMS bearer
(⇒ copy of original 3GPP image)
Up
Step 1.
Activation and announcement of MBMS bearer availability.
Step 2.
The MCData client 1 initiates a group communication by sending a MCData group data request over a unicast PDN connection towards the MCData server.
Step 3.
MCData server initiates the MCData group data request towards each MCData clients 2 to n.
Step 4.
The receiving MCData clients 2 to n optionally notify the user about the incoming MCData session data request.
Step 5.
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 6.
The MCData server will send a MapGroupToBearer message over a previously activated MBMS bearer to all users that will receive the communication over an MBMS bearer. The MapGroupToBearer message includes association information between the group communication and MBMS bearer. The MapGroupToBearer message includes MCData group ID and information about the media stream identifier of the activated MBMS bearer and may include the identifier (i.e. the TMGI) of the MBMS bearer broadcasting the communication.
Step 7.
The MCData clients 2 to n process the MapGroupToBearer information and may send a MapGroupToBearer Ack back to the MCData server if required.
Step 8.
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 9.
MCData client 1 sends the MC data over uplink unicast PDN connection towards the MCData server.
Step 10.
The MCData server sends the MC data over the indicated stream within the associated MBMS bearer to the MCData clients 2 to n.
Up
7.3.6.2.2  Group communication disconnect from MBMS bearer  p. 54
Figure 7.3.6.2.2-1 shows the high level procedure where an UnmapGroupFromBearer message is sent by the MCData server to the MCData clients to indicate that the MCData group communication is being dissociated from the MBMS bearer.
Copy of original 3GPP image for 3GPP TS 23.282, Fig. 7.3.6.2.2-1: Group communication disconnect on MBMS bearer
Figure 7.3.6.2.2-1: Group communication disconnect on MBMS bearer
(⇒ copy of original 3GPP image)
Up
Step 1.
The MC group communication is taking place over MBMS bearer. MCData client 1 is sending the MC data over a unicast PDN connection to the MCData server.
Step 2.
The MCData server sends the MC data over the MBMS bearer to MCData clients 2 to n.
Step 3.
After the MC data transmission is over, i.e., no further data to be sent over the group communication, the MCData server sends an UnMapGroupFromBearer to de-associate the group communication from the MBMS bearer.

Up   Top   ToC