Tech-invite  3GPPspace  IETF RFCs  SIP
index  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:  18.2.0

Top   Top   Up   Prev   None
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… 
B Transmission control for MCData  B.1 Overview of transmission control process  B.2 Transmission control arbitration  D Example of a User Message Storage Area  $ Change history 

 

B  Transmission control for MCData  p. 231

B.1  Overview of transmission control process  p. 231

The MCData server may receive several simultaneous requests for data transmission, which may be associated with different types of communication e.g. group, private, 1-to-many. For each communication, how the requests are processed may be different. The requests that are not authorized shall be rejected by the transmission control function. For message requests over the signalling control plane, the processing should be immediate and is delivered to the recipients either via unicast or broadcast. However, for message requests over the media plane, transmission control arbitration (see Annex B.2) will be necessary. Subsequent to transmission control arbitration, and subject to the policy e.g. store and forward, the data is either delivered directly to the recipient MCData user or stored in the network repository and a corresponding URL is delivered. The end-to-end transmission control process is illustrated in Figure B.1-1.
Copy of original 3GPP image for 3GPP TS 23.282, Fig. B.1-1: Transmission control process
Figure B.1-1: Transmission control process
(⇒ copy of original 3GPP image)
Up

B.2  Transmission control arbitration  p. 231

The transmission control arbitration is a central function of the transmission control process and is implementation specific. In a typical deployment, multiple or simultaneous requests can be received at the transmission control arbitration function. Each of these requests may be categorized into different request types with different queuing priorities, and therefore each request type will be maintained with separate queues. Each request shall not be present in more than one queue at any given time. The queue types and the order of queues may be configured by the MCData administrator, as described below.
  • Transmission control queue: It is the primary queue from which the request is processed for transmission e.g. emergency communication requests may result in this queue and processed at the highest priority.
  • Communication type queue: This queue may be sorted in the order of the communication type associated with the request. For example, the group communication requests may always take precedence over one-to-many or private communication requests.
  • Static attribute queue: This queue may be formed based on the static attributes associated with the request e.g. group priority, user priority, which may be pre-configured by the MCData administrator.
  • Dynamic attribute queue: This queue may be formed based on the dynamic attributes associated with the request e.g. location of the sending user, content size, etc.
Up

C  Void

D  Example of a User Message Storage Area |R16|  p. 233

The Figure in subclause 7.13.1 illustrates the high-level structure of the MCData message store where objects are stored in a flat structure in the user storage area. This flat data structure provides maximum flexibility for UI implementation to present stored objects to the user. However, a folder hierarchy structure provides a better visual presentation of the stored objects to the MCData user.
Copy of original 3GPP image for 3GPP TS 23.282, Fig. D-1: User message storage area example
Figure D-1: User message storage area example
(⇒ copy of original 3GPP image)
Up
In Figure D-1 the MCData user 1 message storage area in the MCData message store is constructed in folder hierarchical way. A system default folder, Inbox, is configured to receive all new objects coming from active communications. The MCData user 1 creates Group 1, Group 2 and Group N folders to store communication history for different group communications that he is a member of. Once the Group 1 folder is created the MCData user 1 can then move all the objects related to Group 1 communication from the Inbox to the Group 1 folder. The MCData user 1 can also create child folders in Group 1 folder to further divide the stored objects into different groupings such as with different subjects, Subject 1 and Subject 2. Similarly, the MCData user 1 creates child folders, Date 1 and Date 2, in Group N folder to store communication history in group N occurred in different dates. With this hierarchical folder structure, the MCData user 1 can browse his user account in the MCData message store interactively and navigate to the information he would like to see. For example, the MCData user 1 can start with the top-level root folder and traverse down the folder hierarchy to reach to Date 2 folder and see the communication history of group N in that particular date.
Up

$  Change history  p. 234

Up   Top