product feature: group messagingfiles.ctia.org/pdf/em_group_messaging_uc__cf_inter... ·...

EM Group Messaging Feature 1

CTIA’s Wireless Internet Caucus Enhanced Messaging Action Team

(EM Team)

Enhanced Messaging Product

Product Feature:Group Messaging

Use Cases & Call Flows

See also documentation for EM Product; Product Feature: Presence.

Documentation FinalOctober 17, 2008


Base Assumptions for Technical Support

• The inter-carrier messaging protocol will be based on OMA SIMPLE IM specs (see below)

• Both MSISDN/MDN and SIP URI could be used to address a group participant in a group conversation

• Use of aggregator (IWP/A) to interconnect carriers is optional but needs to be supported

Standards will be followed for all Use Cases

• Reference to OMA SIMPLE IM V10: :http://www.openmobilealliance.org/Technical/release_program/srm_v1_0.aspx

• main page: http://www.openmobilealliance.org/Technical/released_enablers.aspx

http://www.openmobilealliance.org/Technical/release_program/srm_v1_0.aspx

http://www.openmobilealliance.org/Technical/released_enablers.aspx


Base Assumptions for Customer Experience

Ad Hoc groups are made extemporaneously, and are valid as long as they meet the criteria for starting and ending groups in this set of Use Cases. (04-01, and 05-01A, B, &C)

Permanent groups are groups which have group ID and group members stored for use and reference at later dates, and can be communicated with outside of the timing parameters defined in this set of Use Cases.

All UC & CF were created presuming only support for Ad Hoc groups at this time.

A Polite Rejection/Block is one in which the User being blocked does not receive notification that they are blocked from joining the group.

A Rude Rejection/Block is one in which the User being blocked does receive notification that they are being blocked from joining the group.


Documentation Outline• The following Use Cases and Call

Flows represent the output of a Team effort to determine the minimal requirements needed to support a cross-carrier Enhanced Messaging Product with Product Feature of Group Messaging.

• Documentation for each Use Case include: Scenarios, Action Steps, and (CF) Call Flow. Presented in the following order:

04-01a Create a Group- manual Opt-In

04-01b Create a Group - automatic Opt-in

04-02 User Declines a GM Invite

04-03a Sending MultiMedia - Content Embedded

04-03bSending MultiMedia - Content referenced via

link

04-04 Joining an Active Group

04-05 Removed

04-06 Attempting to Join an Ended Group

04-07 User Decides to Exit an Active Group

04-08User Re-Joins and Active Group after Exiting

or Declining

04-09 Receiving a List of Active Group Members

04-10 Support of Display Name

05-01 A Group Initiator Ends a Group Conversation

05-01b Rules to end a Group Conversation

05-01c Message sent after Group Ends

05-02A Group Initiator Blocks a Specific Group

Member

06-01 Legacy - EM carrier not EM device

06-02 Legacy - non-EM carrier


Background for UC & CF

Use Case Functional Areas:• FA-04 Group Messaging Initiation and Sessions• FA-05 Group Messaging Group Management• FA-06 Group Messaging Legacy Support

Enhanced Messaging Use Cases• For each Use Case, the subscribers (a.k.a. actors or system users), the mobile carrier

with which they have a relationship, and the Interoperability Use Cases that describe the system are defined. In this section, the main users and operators are described, and in the following section, their interaction via Use Cases.

• Note that these use cases are meant to cover the intercarrier aspects of enhanced messaging services only. In order to add context and understanding to the use cases, some actions are specified that would be undertaken by the use case actors, or their operator/service provider. In all cases, these user-specific (or operator-specific) actions are for example only, and do not indicate any specific implementation by a specific carrier. Such actions are identified by italicized, blue text.


Mobile Carrier G Messenger User Property Name Brief Description

Name UserG

Brief Description A Mobile Carrier G customer (user) who has registered for Mobile Carrier G Enhanced Messenger.

Responsibilities The lifecycle of the subscriber UserG begins with registration on the system. Once registered, UserG uses the Mobile Carrier G messaging functionality to communicate

Relationships • Has a billing relationship with Mobile Carrier G• Has an account with Mobile Carrier G Messenger system• Has Contacts on his Contact List• Is on the Contact List of other users

Operations The user uses the following operations within the system:• Add/Delete/Block Contacts• Exchange Messages with Contacts• Watch Presence Status information of Contacts• Participate in Private Group discussions

Attributes Mobile Carrier G, Mobile Carrier D, and Mobile Carrier Z all have relationships through an Interworking Partner/Aggregator (IWP/A) or direct connection to exchange certain attributes and message types.

Characteristics The Mobile Carrier G Messenger User is assumed to be a member of the general public who has a mobile phone (with Mobile Carrier G as Mobile Carrier)

Competence Requirements

The Mobile Carrier G Messenger User is assumed to be able to write SMS messages. He is assumed to be familiar with at least one of the Mobile Carrier G Messenger clients (i.e. WAP, SMS. )

Diagrams N/a


Mobile Carrier D Messenger User Property Name Brief Description

Name UserD

Brief Description A Mobile Carrier D customer (user) who has registered for Mobile Carrier D Enhanced Messenger.

Responsibilities The lifecycle of the subscriber UserD begins with registration on the system. Once registered, UserD uses the Mobile Carrier D messaging functionality to communicate

Relationships • Has a billing relationship with Mobile Carrier D • Has an account with Mobile Carrier D Messenger system• Has Contacts on his Contact Lists• Is on the Contact List and/or special List of other users

Operations The user uses the following operations within the system: • Add/Delete/Block Contacts• Exchange Messages with Contacts• Watch Presence Status information of Contacts• Participate in Private Group discussions

Attributes Mobile Carrier G, Mobile Carrier D, and Mobile Carrier Z all have relationships through an Interworking Partner/Aggregator (IWP/A) or direct connection to exchange certain attributes and message types.

Characteristics The Mobile Carrier G Messenger User is assumed to be a member of the general public who has a mobile phone (with Mobile Carrier G as Mobile Carrier)


The Mobile Carrier G Messenger User is assumed to be able to write SMS messages. He is assumed to be familiar with at least one of the Mobile Carrier G Messenger clients (i.e. WAP, SMS.)

Diagrams N/a


Mobile Carrier Z Customer (Non-Messenger)

Property Name Brief Description

Name UserZ (ie Legacy)

Brief Description A Mobile Carrier Z customer (user) who is not an enhanced messaging customer because Mobile Carrier Z does not support the service from an intercarrier perspective.

Responsibilities None

Relationships • Has a billing relationship with Mobile Carrier Z• Has friends who use the Mobile Carrier Z or Enhanced Messaging services through Mobile Carriers D or G

Operations The customer uses the following operations within the system:•Receive Invitations•Registration •Receives/sends messages from/to friends UserG and UserD

Attributes Mobile Carrier G, Mobile Carrier D, and Mobile Carrier Z all have relationships through an Interworking Partner/Aggregator or direct connection to exchange certain attributes and message types.

Characteristics The Mobile Carrier Z Mobile Customer is assumed to be a member of the general public who has a mobile phone (with Mobile Carrier Z as Mobile Carrier)


The Mobile Carrier Z Messenger User is assumed to be able to write SMS messages.

Diagrams N/a


Use Case 04-01

Create a Group

Scenario 04-01A = Manual Opt-InScenario 04-01B = Automatic Opt-In


Primary User UserD1, D2, G1, G2

Precondition User D1, D2, G1 and G2 are subscribers with Mobile Carriers D and G respectively. Each are enhanced messaging customers.

Alternate Scenarios Or Extensions

If either UserG1 or UserG2 decline the request from UserD1, UC-04-02 applies. As long as the group session is still open, UserG1 or G2 could accept or decline

(i.e. – the invitation to the group does not expire as long as the group is still active).

EM Server should support deferred messages.

Message Content

UC-04-01: <Invitation>: "You have been invited by User D1 to join Group XYZ. Would you like to join the Group?"

UC-04-01: <Acceptance>: "User G1 has joined Group XYZ"

UC 04-01 Create a Group; Scenarios


Action Step Response

UserD1 is the initiator of the group conversation; D1 sends a message to UserD2, UserG1 and UserG2. Format could look like <Invitation> system message

Mobile Carrier D is responsible for creating and managing the group messaging session. Mobile Carrier D must send requests to UserG1and UserG2 to join the group conversation. This is done through the IWP/A.

Since UserD2 is a Mobile Carrier D subscriber, that carrier has responsibility for how UserD2 will be added to the conversation. This is not an intercarrier issue.

User G1 and User G2 receive prompts to opt-in and accepts the invitation.

Mobile Carrier G sends an <Acceptance> message for UserG1 and UserG2 through the IWP/A back to the group messaging system at Mobile Carrier D.

The group messaging system at Mobile Carrier D sends out System <Acceptance> messages to all group participants as it receives the acceptance messages. The messages indicate that specific users have joined the conversation.

The IWP/A passes the <acceptance> messages to Mobile Carrier G.

Mobile Carrier D sends the UserGen message created by UserD1 to each recipient as it receives opt-in responses from each destination.

The IWP/A passes the UserGen messages to Mobile Carrier G.

UserG1 and UserG2 receive the UserGen message

UserG1 replies to the UserGen message Mobile Carrier G passes the UserGen message to the IWP/A who must forward the group message to the group messaging function at Mobile Carrier D.

The Group Messaging system at Mobile Carrier D sends the UserGen message to UserD1, UserD2, and UserG2.

UserD1, UserD2, and UserG2 receive the UserGen reply message

UC 04-01 Create a Group; Action Steps


CF 04-01A Create a Group – Scenario A - Manual Opt-In


Number / Title UC-04-01B Automatic Opt-In – Invite Scenario B


Precondition User D1, D2, G1 and G2 are subscribers with Mobile Carriers D and G respectively. Each are enhanced messaging customers.

<Auto Opt-in> You have been added to [groupXYZ]. Optional information on opt out procedure or List the Following Members are in group <GroupXYZ> <UserG1, User, G2, User G3>

Users who are opted-in in order of auto-acceptance: <Acceptance>: "User G1 has joined Group XYZ"

Message Content

If any User opts out, UC-04-02 applies. As long as the group session is still active, any User can opt out.

EM Server should support deferred messages.


UC 04-01B Scenario B = Automatic Opt – In; Scenarios



UserD1 is the initiator of the group conversation; D1 creates and sends a system <Auto Opt In> message to UserD2, UserG1 and UserG2.

Mobile Carrier D is responsible for creating and managing the group messaging session. Mobile Carrier D sends system <Auto Opt In> notification messages to UserG1 and UserG2 to join the group conversation. This is done through the IWP/A.


User G1, User G2, and User D2 are automatically opted into the group session.

Mobile Carrier G sends a signaling acceptance back to the group messaging system at Mobile Carrier D.

Mobile Carrier D acknowledges automatic acceptance by User D2. This is not an intercarrier issue.

The group messaging system at Mobile Carrier D sends out system <Auto Opt In> messages to all group participants. The messages indicate that specific users have joined the conversation.

The IWP/A passes the acceptance messages to Mobile Carrier G.

Mobile Carrier D sends the UserGen messages created by UserD1 to each recipient as it receives opt-in responses from each destination.

The IWP/A passes the UserGen group messages to Mobile Carrier G.

UserG1 and UserG2 receive the User Gen message

UserG1 replies to the Use Gen message Mobile Carrier G passes the UserGen message to the IWP/A who must forward the group message to the group messaging function at Mobile Carrier D.

The Group Messaging system at Mobile Carrier D sends the UserGen message to UserD1, UserD2, and UserG2.

UserD1, UserD2, and UserG2 receive the UserGen reply message

UC 04-01B Scenario B = Automatic Opt – In; Action Steps


CF 04-01B Create a Group – Scenario B – Automatic Opt-in


Use Case 04-02

User Declines a GM Invite



Precondition UserD1 has set up a Group Conversation among UserD2 and UserG1 and UserG2 (UC-04-01)

Scope This Use Case is relevant to 04-01A – Manual Opt In.

Message Content

<Decline >: <User G1> has declined your invitation to join group <GroupName>.

UC 04-02 User Declines a Group Messaging invitation; Scenarios



UserG1 declines the invitation to the group. Mobile Carrier G sends the system <decline> message to the IWP/A, who routes the system message back to the group messaging system at Mobile Carrier D.

Mobile Carrier D removes UserG1 from the group messaging session. Since UserG1 declines the initial group request, a <decline> message is only sent back to the initiator of the group, UserD1.

UserG1 no longer receives messages for this group (but could still participate in other groups).

UC 04-02 User Declines a Group Messaging invitation; Action Steps


User D1 User G2

G1 Declines invite conversation

EM Server D (Host) EM Server GUser D2 User G1

IWP/A

A message is sent to the group originator indicating that UserG1 has declined the group invitiation.

UserG1 declines the invitation to the group session

Host Server receives decline and removes G1

from sessioin

“G1 has declined the conversation”

G1 Server forwards Decline message

CF 04-02 User Declines a GM invite


Use Case 04-03

Sending Multi Media during Conversation

Scenario 04-03A = Content Embedded in MessageScenario 04-03B = Content referenced with Link


Scenario UserD1, UserD2, UserG1 and UserG2 are in a group messaging session. UserD1 decides to send Multimedia content to the others in the group.

Primary User UserD1

Other Users UserD2, UserG1, UserG2

Precondition All group members are engaged in a group conversation as specified in UC-04-01.


04-03B = UserD1 sends an enhanced UserGen message with a url type link to Multimedia content to the group

Scope Multimedia may include video, pictures, music, audio or other new file types.

Size of content Support of sizes by file type will be negotiated between carriers and can be expected to be adjusted over time. Note that embedded content sizes should- at a minimum-follow current standards specifications.

UC-04-03 A & B Sending Multimedia Content during a Group ConversationScenario A = Content Embedded; Scenario B = url Link



UserD1 sends Multimedia content embedded in a UserGen message to the group

Mobile Carrier D passes the UserGen message to Mobile Carrier G.

All participants (excluding UserD1) receive the UserGen message on their devices through their respective mobile carriers. They are able to display or playback the multimedia content upon reading the message.

UC 04-03A Sending Multimedia Content Scenario A = Content Embedded; Action Step



UserD1 sends an enhanced UserGen message with a url type link to Multimedia content to the group

Mobile Carrier D passes the UserGen message to Mobile Carrier G.

All participants (excluding UserD1) receive the message on their devices through their respective mobile carriers. They are able to access the Multimedia content in the enhanced message by clicking the url link.

UC 04-03B Sending Multimedia Content Scenario B = Content Referenced as url link; Action Steps


UC-04-03 A & B: Sending Multi Media

IPA/A

User D2User D1

EM Server D (Host)

User G2User G1

EM Server G

Option A: User D1 sends multimedia content in a message to the group

Message w/multimedia

Server forwards message



Server forwardsmessage Server forwards message

Option B: User D1 sends multimedia content to the group which is distributed as a link to the content

Message w/multimedia

Server forwards message w/URL

Server forwards message w/URLServer forwards message

w/URL Server forwardsmessage w/URL






Stores Multimedia Content

G2 does not fetch multimedia content

D2 uses URL to fetch multimedia content D2 uses URL to fetch

multimedia content

Embedded

As url link


Use Case 04-04

Joining an Active Group


Scenario UserD1 has started a group conversation (as per 04-01), which has been on going for a period of time when UserG2 decides to join.


Precondition User D1, D2, G1 and G2 are subscribers with Mobile Carriers D and G respectively. Each are enhanced messaging customers. The group conversation must be active.

Scope Pre- Condition Note: if all group members are opted in automatically, then there would be no need for this Use Case.

Receiving no past messages upon joining was discussed as the customer experience desired, and for storage reasons.

Message Content

<Acceptance>: "User G1 has joined Group XYZ"

UC 04-04 Joining an Active Group; Scenario



UserD1 is the initiator of the group conversation; UserD1 creates and sends a UserGen message to UserD2, UserG1 and UserG2.

Mobile Carrier D is responsible for creating and managing the group messaging session. Mobile Carrier D must send requests (response can be either manual or Automatic as specified in 04-01A,B) to UserG1 and UserG2 to join the group conversation. This is done through the IWP/A.

Since UserD2 is a Mobile Carrier D subscriber, each carrier has responsibility for how UserD2 will be added to the conversation. This is not an intercarrier issue.

As per 04-01 scenarios, Mobile Carrier G could implement a service where all of its subscribers are automatically opted-in to a group messaging session. Or could require each subscriber manually approve theirparticipation in the group. Nevertheless, the intercarrier use case requires that a positive response be sent back to Mobile Carrier D for the group session. For this case only UserG1 immediately joins the group.

Mobile Carrier G sends a system <acceptance> message for UserG1 through the IWP/A back to the group messaging system at Mobile Carrier D.

Group messages are created and sent between the current, active members of the group.

The IWP/A passes the group messages to Mobile Carrier G for UserG1.

After some period of time, UserG2 decides to accept the group invitation and sends their manual opt-in message as per 04-01A.

Mobile Carrier G sends a a system <acceptance> for UserG2 through the IWP/A back to the group messaging system at Mobile Carrier D.

The group messaging system at Mobile Carrier D sends out a system <acceptance> message to all group participants as it receives the positive response messages from UserG2.

The IWP/A passes the <acceptance> messages to Mobile Carrier G.

Accepting the invitation will result in UserG2 automatically receiving all future messages, but none from the past.

UC 04-04 Joining an Active Group; Action Step


CF 04-04 Joining an Active Group


Use Case 04-05 Removed

Removed –Receiving Conversation History


Use Case 04-06

Joining an Ended Conversation


Scenario UserD1 has started a group conversation, which has been on going for a period of time and then ends per UC-05-01. At that point, UserG2 decides to join.


Precondition User D1, D2, G1 and G2 are subscribers with Mobile Carriers D and G respectively. Each are enhanced messaging customers. The group conversation must be inactive.


Opt In scenarios of Manual or Automatic will affect this Use Case.If a Group Name is no longer stored and is not recognized, then an error system message response of <Group Name does not Exist> will be sent.

Scope Given the Ad-Hoc group status, the above GroupXYZ may not be relevant. A permanent group would have a permanent Group name.

Message Content <Acceptance>: "User G1 has joined Group XYZ"<Ended Message>: The group you are attempting to join, <Group Name>, has ended.<Group Name does not Exist>: The group you are attempting to join, <Group Name>, is not found in our records.

UC 04-06 Attempting to Join an Ended Group; Scenario



UserD1 is the initiator of the group conversation; D1 creates and sends a message to UserD2, UserG1 and UserG2.

All participants except UserG2 join the group, as per 04-01.

Group conversation takes place between active members of the group.

At some point, the group is ended per UC-05-01.

After some period of time, UserG2 decides to accept the group invitation and sends their opt-in message, as per 04-01A.

Mobile Carrier G sends a system <acceptance> message for UserG2 through the IWP/A back to the group messaging system at Mobile Carrier D.

The group messaging system at Mobile Carrier D recognizes that the group UserG2 is trying to join is ended. Mobile Carrier D will send an error system <Ended Group> message back to Carrier G’s group messaging system.

Mobile Carrier G receives the error system “<Ended group> message. Further action by Mobile Carrier G is not an intercarrier issue.

UC 04-06 Attempting to Join an Ended Group; Action Steps


UC 04-06 Joining an Ended Conversation (Based on 04-01A scenario)


Use Case 04-07

User Exits Active Group



Precondition UserD1 has set up a Group Conversation among UserD2 and UserG1 and UserG2 (UC-04-01)

Message Content < Exit >: User G1 has left Group XYZ"

UC 04-07 User Decides to Exit an Active Group; Scenario



UserG1 decides to exit the group conversation after already accepting.

Mobile Carrier G sends the signaling <Exit> message to the IWP/A, who routes the message back to the group messaging system at Mobile Carrier D.

Mobile Carrier D removes UserG1 from the group messaging session. In addition, a system <exit> notification message is sent to all of the remaining group participants indicating that UserG1 has left the conversation.

The IWP/A takes the <exit> notification message from Mobile Carrier D and forwards it to Mobile Carrier G for delivery to UserG2 (who is still participating in the conversation).

UserG1 no longer receives messages for this group (but could still participate in other groups).

UC 04-07 User Decides to Exit an Active Group; Action Steps


User D1 User G2

G1 decides to exit conversation


IWP/A

A message is sent to all of the remaining group participants indicating that UserG1 has left the conversation.

UserG1 decides to exit the group conversation after already accepting

Host Server receives exit message and removes

G1 from sessioin

“G1 has left the conversation”



Mobile Carrier G receives “G1 has left the

conversation” message

Mobile Carrier G sends “G1 has left the conversation” to users still participating in

session

G1 Server forwards exit message

CF 04-07 User Decides to Exit an Active Group


Use Case 04-08

Re-Join an Active Group after exiting or declining



Precondition UserD1 has set up a Group Conversation among UserD2 and UserG1 and UserG2 (UC-04-01A, B). UserG1 has left the group either by declining the original invitation (UC 04-02) or by exiting the group after joining (UC04-07).

Alternate Scenario #1

Attempting to re-join an inactive group after leaving or declining is identical to UC-04-06.

Message Content <Acceptance>: "User G1 has joined Group XYZ"<Rejoin >: At this time, this will be supported on a carrier by carrier decision.

UC 04-08 User Re-Joins an Active Group after Exiting or Declining; Scenario



UserG1 uses their messaging inbox to select a group conversation they previously left or declined. UserG1 exercises the command to <Re-join> the group (or accept the group invitation they previously declined).

Mobile Carrier G sends the system <Acceptance> message to the IWP/A, who routes the message back to the group messaging system at Mobile Carrier D.

Mobile Carrier D adds UserG1 to the group messaging session. The group messaging system at Mobile Carrier D sends out a system <Acceptance> message to all group participants that UserG1 has joined the conversation.

Joining the conversation will result in UserG1 automatically receiving all future messages, but none from the past.

UC 04-08 User Re-Joins an Active Group after Exiting or Declining; Action Steps


CF 04-08 User rejoins an active group after exiting or declining


Use Case 04-09

Receiving a List of Active Group Members


Scenario UserD1 has started a group conversation which has been on-going for a period of time when UserG2 decides to obtain a list of the current, active members of the group.


Precondition User D1, D2, G1 and G2 are subscribers with Mobile Carriers D and G respectively. Each are enhanced messaging customers. The group conversation must be active. UserD1 has already started a group conversation and UserG2 has accepted the group invitation.

UC 04-09 Receiving a List of Active Group Members; Scenario

Message Content <Get Active Members Query>: exact command code not determined technically across carrier. <Member List>: Format is yet to be finalized across carrier. Minimal across carrier support will be phone number and Display Name (See 04-10); or phone number only in the case of no available Display Name.



Mobile Carrier G supports the intercarrier command <Get Active Members Query>. UserG2 exercises that command from his device.

Mobile Carrier G passes the command <Get Active Members Query> to the IWP/A who must forward the message to the group messaging function at Mobile Carrier D.

The Group Messaging system at Mobile Carrier D sends a system <Member List> message of the current, active members of the group conversation to UserG2.

UserG2 receives the entire active member list on their device. The format of its display is dependent on Mobile Carrier G requirements and is not an intercarrier issue.

UC 04-09 Receiving a List of Active Group Members; Action Steps


CF 04-09 Receiving a List of Active Group MembersUser D1 User G2

G2 requests list of active members


IWP/A

Host Server Generates List of Active Members and sends to UserG2

UserG2 Requests List of Active Group Members

Host Server receives request for list of active

members

Host server sends list of active members

Mobile Carrier G receives list of active members

G2 Server forwards request

UserG2 receives entire list of active members

Note: "<Get Active Memparticipants regardless ofgroup). The host EM server thenreceive th

bers Query>" is always sent to the host EM Server since it maintains the list of active each participants carrier (i.e., the non-host EM servers do not know who is involved in the

sends the list to the user who requested it. Therefore, the user who requested it should e list as one message.


Use Case 04-10

Support of Display Name


Scenario UserD1 has been invited to a group conversation. A Display Name is communicated during the active session, and will show when <Member List> is requested.


Precondition User D1, D2, G1 and G2 are subscribers with Mobile Carriers D and G respectively. Each is enhanced messaging customers. Per UC-04-01, UserG2 has either manually opted in, or has been automatically opted-in to a group messaging session.


Carrier D also uses Display name in admin messages to group members.

Scope In order to comply with intercarrier messaging requirements the display name shall only consist of ASCII characters and be limited to 12 characters.

MessageContent <Member List>: Format is yet to be finalized across carrier. The supported format of the <Member List> message will include at least Display Name, and Group Name. MSISDN/MDN would be displayed if no Display name is provided.

Note The use of Display names will conform to OMA SIMPLE IM. The main OMA specification page http://www.openmobilealliance.org/Technical/released_enablers.aspx

This Use Case description is retained, the Team notes there is no associated Call Flow since the solution will be according to standards. The solution may encompass Presence Attributes and are outside the scope of the application server. Solutions will be decided on a carrier by carrier basis.

UC 04-10 Support of Display Name; Scenario

http://www.openmobilealliance.org/Technical/released_enablers.aspx



Mobile Carrier G could provide many different ways to capture a display name for its enhanced messaging customers. Mobile Carrier G can manage these name assignments however they choose.

Mobile Carrier G passes the Display Name in finalized format within the “opt-in” message identified in UC-04-01 to the IWP/A who must forward the message to the group messaging function at Mobile Carrier D.

The Group Messaging system at Mobile Carrier D upon <Get Active Member Query> command sends a list of the current, active members of the group conversation to any user who requests the list via UC-04-09.

The supported format of the <Member List> message will include at least Display Name, and Group Name. MSISDN/MDN would be displayed if no Display name is provided.

UserG2 receives the entire active member list on their device.

UC 04-10 Support of Display Name; Action Steps


Use Case 05-01

Group Initiator Ends a Group Conversation



Precondition UserD1 has set up a Group Conversation among UserD2 and UserG1 and UserG2 (UC-04-01). Each participant in the group has accepted the invitation to join the group.


Group conversation could also end if: 05-01B : all active members of the group exit the group or 05-01 C: if no UserGen messaging traffic is passed among the group members for a period of 72

hours.

Message Content <Group Ended>: The <groupXYZ> is now closed by the initiator.<Group Closed>: Your message to <GroupXYZ> cannot be sent because it was closed by the

initiator.

UC 05-01A Group Initiator Ends a Group Conversation; Scenario


EM ServerHOST

EM Server

EM Server

Carrier D

Carrier G

Carrier U

D1

G1D2

G2

X1

X2

1 End Conversation

2 Conversation ends

2 Conversation ends

3 Conversation ends

3 Conversation ends

UC 05-01A Group Initiator Ends a Group Conversation



UserD1 decides to end the group conversation with UserD2, G1 and G2.

The group messaging system at Mobile Carrier D is responsible for sending out a signaling message to active group participants that the group session has ended.

The IWP/A will route a system <group ended> messages to Mobile Carrier G for delivery to G1 and G2.

UserG1 replies to a group conversation that ended

The IWP/A routes the group message from Mobile Carrier G to Mobile Carrier D’s group messaging system.

Mobile Carrier D’s group messaging system must recognize that the group session has ended and return a system <Group Closed> message to Mobile Carrier G through the IWP/A.

UC 05-01A Group Initiator Ends a Group Conversation; Action Steps


CF 05-01A Group Initiator Ends a Group Conversation


CF 05-01B All Participants Leave the Conversation

D1 D2 G1 G2

EM Server D EM Server G

IWP/A

D1 has started the group conversation with D2, G1 and G2

Leave conversation

G1 Left conversation

Leave conversation

Leave conversation

OK D2

OK G1

G2 OK

OK G2

Group Conversation ends


OK G1

OK G1



OK G2

Group conversation ends (all left)

D1 OK


CF 05-01C No Activities for 72 Hours

D1 D2 G1 G2

EM Server D EM Server G

IWP/A

D1 has started the group conversation with D2, G1 and G2

Group conversation ends (G1)

Group conversation ends



D2 OK

G1 OK

G1 OK

G1 OK

G2 OKG2 OK

G2 OK

Group Conversation ends

No Activities for 72 hours


Group conversation ends (no activities)

D1 OK




CF 05-01 G1 Sends Message after End of Group Conversation


Use Case 05-02

Group Creator Blocks a Specific Group Member


Scope Block message could be configurable on a carrier by carrier choice.

Message Content <remove UserG2 command>: format TBD<Block Rude UserG2> DisplayName has been removed from the conversation at request of the

initiator.<Block Polite UserG2> GroupXYZ is closed<Block Rude Members> UserG2 has been removed from GroupXYZ<Block Polite Members> UserG2 has left GroupXYZ


Precondition UserD1 has set up a Group Conversation among UserD2 and UserG1 and UserG2 (UC-04-01). Each participant in the group has accepted the invitation to join the group.

UC 05-02 A Group Initiator Blocks a Specific Group Member; Scenario



UserD1 decides to end the group conversation with one member, UserG2. In other words, UserG2 is removed from the conversation by the initiators request <Remove UserG2> command.

The group messaging system at Mobile Carrier D is responsible for managing the group conversation and will remove UserG2 from the active group, upon receiving the command message <remove UserG2 command>. The group messaging system will also send two messages as follows:

1) UserG2 will be sent a “blocked” signaling message2) All other remaining members of the group shall be sent a system

message (UC-04-02) indicating that UserG2 has left the conversation.

UC 05-02 A Group Initiator Blocks a Specific Group Member; Action Steps


CF 05-02 Group Creator Blocks a Specific Group Member


Legacy Section

UC 06-01: Legacy- EM carrier, non-EM deviceUC 06-02: Legacy- Non-EM carrier


Primary User UserD1, D2, G1, G2, G3

Precondition UserD1 has set up a Group Conversation among UserD2 and UserG1 and UserG2 (UC-04-01). In this use case, UserD1 has included UserG3 who is not an enhanced messaging subscriber.


UserG3 could also decline the group messaging request (if Mobile Carrier G offers its subscribers that option).

UserG3 should also be able to reply to any of the group messages to exit the group conversation.

Mobile Carrier D should allow a reply of “STOP” to any message and remove UserG3 from the group conversation (US-04-02).

Scope Note the determination of multiple messages or truncating has not been finalized, see RFI Section 6, Questions

Message Content <Invitation>: "You have been invited by User D1 to join Group XYZ. Would you like to join the Group?"

UC 06-01 Legacy- EM Carrier, non-EM Device; Scenario



UserD1 is the initiator of the group conversation; D1 creates and sends a message to UserD2, UserG1, UserG2 and UserG3.

Mobile Carrier D is responsible for creating and managing the group messaging session. Mobile Carrier D must send system <invitation> messages to UserG1 and UserG2 and UserG3 to join the group conversation. (04-01) This is done through the IWP/A.


As per 04-01A,B, Mobile Carrier G could implement where all of its subscribers are automatically opted-in to a group session. Or could require each subscriber to approve their participation in the group. The intercarrier UC requires that a positive response be sent back to Mobile Carrier D. For this case assumed positive.

Mobile Carrier G sends a system <acceptance> for UserG1 and UserG2 and UserG3 through the IWP/A back to the group messaging system at Mobile Carrier D.

The group messaging system at Mobile Carrier D sends out system <acceptance> messages, as per 04-01.

The IWP/A passes the <acceptance> messages to Mobile Carrier G for UserG1, UserG2 and UserG3. Mobile Carrier G is responsible for routing all messages to UserG3 through legacy systems (SMS & MMS).

Whether carriers choose the above method or another method, below the IWP/A layer, is not an intercarrier issue.

Mobile Carrier D sends the UserGen message created by UserD1 to each recipient as it receives opt-in responses from each destination. (04-01)

The IWP/A passes the group messages to Mobile Carrier G for UserG1, UserG2 and UserG3. Mobile Carrier G is responsible for routing all messages to UserG3 through legacy systems (SMS & MMS)

Whether carriers choose the above method or another method, below the IWP/A layer, is not an intercarrier issue.

UserG3 should be able to reply to the messages and such replies should be passed back to Mobile Carrier D for distribution to all other members of the group. The interface back to Mobile Carrier D in this case must always be through the EM systems.

UC 06-01 Legacy- EM Carrier, non-EM Device; Action Steps


UC 06-01 Legacy- EM Carrier, non-EM device


Primary User UserD1, D2, G1, G2,

Other Users CustomerZ

Precondition UserD1 has set up a Group Conversation among UserD2 and UserG1 and UserG2 (UC-04-01). In this use case, UserD1 has included CustomerZ who is not an enhanced messaging subscriber and whose carrier does NOT support enhanced messaging. This use case concentrates on the interaction with CustomerZ, all steps related to UserG1 and UserG2 and Mobile Carrier G are unchanged from UC-04-01.


CustomerZ could also decline the group messaging request. CustomerZ should also be able to reply to any of the group messages to exit the group

conversation. Mobile Carrier D should allow a reply of “STOP” to any message and remove CustomerZ

from the group conversation (UC-04-02).

Scope UserD1 could send messages including Multimedia content.Ad Hoc groups will have a different user experience than Permanent groups, note RFI

Section 6, General Questions.*1 Note the determination of multiple messages or truncating has not been finalized, see RFI

Section 6, Questions

Message Content <Invitation>: "You have been invited by User D1 to join Group XYZ. Would you like to join the Group?"

UC 06-02 Legacy – non-EM Carrier; Scenario



UserD1 is the initiator of the group conversation; D1 creates and sends a message to UserD2, UserG1, UserG2 and CustomerZ.

Mobile Carrier D is responsible for creating and managing the group messaging session. Mobile Carrier D must send a system <Invitation> message to CustomerZ. This is done through whatever existing messaging interface is in place between Mobile Carrier D and Mobile Carrier Z (assumed legacy SMS/MMS).

Positive and negative responses should be possible.

CustomerZ must approve their participation in the group. This requires that a positive response be sent back to Mobile Carrier D for the group session. For this case assumed positive.

Mobile Carrier Z routes the acceptance for CustomerZ through whatever existing messaging interface is in place between Mobile Carrier D and Mobile Carrier Z (assumed legacy SMS/MMS).

The group messaging system at Mobile Carrier D is not required to send out messages to CustomerZ as it receives the acceptance messages from other group participants. Nor should CustomerZ receive individual messages as group members exit the group.

Mobile Carrier D sends the UserGen message created by UserD1 to each enhanced messaging recipient (per UC-04-01) as it receives opt-in responses from each destination.

CustomerZ receives the message from UserD1. Within the body of the message, Mobile Carrier D has included up to 60 characters of information to inform CustomerZ of other participants within the group.

Message bodies longer than 100 characters are truncated. Group participant info in the message could be mobile number, email address, or Display Name. Participant info is truncated after 60 characters. *1

CustomerZ should be able to reply to the messages and such replies should be passed back to Mobile Carrier D for distribution to all other members of the group. Reply messages pass through whatever existing messaging interface is in place between Mobile Carrier D and Mobile Carrier Z (assumed legacy SMS/MMS).

UC 06-02 Legacy – non-EM Carrier; Action Steps


EM Server D

Start group conversationD2 (DN)G1 (DN)G2 (DN)Z1 (DN)

Start conversation ()

Invite

Accept

Group Conversation startsWhen anyone accepts

Invitations to G1/G2

D1 D2Z1IWG D

Invite

Legacy Messaging D Legacy Messaging Z

Message (Invite)

Message (Invite)

Message (Invite)

Message (Accept)

Message (Accept)

Message (Accept)

Accept

CF 06-02 Legacy – Non-EM carrier

product feature: group messagingfiles.ctia.org/pdf/em_group_messaging_uc__cf_inter... ·...

Documents