gsm association official document se.41

GSM Association Official Document SE.41 UNRESTRICTED

Video Share Service Definition 2.0

27 March 2007

This is a non-binding permanent reference document of the GSM Association.

Security Classification Category (see next page) Not Restricted


Security Classification - UNRESTRICTED Access to and distribution of this document is restricted to the persons listed under the heading Security Classification Category. This document is confidential to the Association and is subject to copyright protection. This document is to be used only for the purposes for which it has been supplied and information contained in it must not be disclosed or in any other way made available, in whole or in part, to persons other than those listed under Security Classification Category without the prior written approval of the Association. The GSM Association (“Association”) makes no representation, warranty or undertaking (express or implied) with respect to and does not accept any responsibility for, and hereby disclaims liability for the accuracy or completeness or timeliness of the information contained in this document. The information contained in this document may be subject to change without prior notice. Copyright Notice Copyright © 2007 GSM Association GSM™ and the GSM Logo™ are registered and the property of the GSM Association. Document History

Version

Date Brief Description

0.3 31 July 2006 Completed drafting phase – signoff by PM 0.9 1 August 2006 Prepared for submission to SRG, DAG and EMC 0.95-1 17 August2006 Including SRG comments from Seattle Meeting 1.0 21 August 2006 DAG Comments now included 1.1 22 November 2006 Re-draft to synchronise between the SIP Trial

Video Share Specification 2.3 (IREG DOC) 1.11 27 November 2006 Final cosmetic changes 2.0 27 March 2007 Changes in accordance to CR001 Changes Since Last Version

Other Information

Type Description Document Owner SRG Revision Control Annual Document editor/company M. Hogan/GSMA

Feedback This document is intended for use by the members of GSMA. It is our intention to provide a quality product for your use. If you find any errors or omissions, please contact us with your comments. You may notify us at mailto:[email protected]. Your comments or suggestions are always welcome.

UNRESTRICTED Version 2.0 of 28

mailto:[email protected]


Table of Contents 1 FOREWORD....................................................................................................... 5

2 BACKGROUND ................................................................................................. 5

3 OVERVIEW OF THE SERVICE ...................................................................... 6 3.1 Introduction .........................................................................................................................6 3.2 Project Information ............................................................................................................7 3.3 Service Scope and Assumptions made .........................................................................7 3.4 High-level Service Concept..............................................................................................8

4 SERVICE DESCRIPTION ................................................................................ 9 4.1 Technical Service Description .........................................................................................9

4.1.1 Call Setup ............................................................................................................ 9 4.1.2 Capability Query............................................................................................... 10 4.1.3 Session Setup/Invitation Procedure .............................................................. 10 4.1.4 Video Transmission ......................................................................................... 11 4.1.5 Teardown of Video Session ........................................................................... 12 4.1.6 Teardown of CS Call ....................................................................................... 13 4.2 Functional Service Description / Use Cases ...............................................................14

4.2.1 Use Case 1: Basic Video Share .................................................................... 15 4.2.2 Use Case 2: Sharing Recorded Video.......................................................... 16 4.2.3 Use Case 3: Record Received Video ........................................................... 17 4.2.4 Use Case 4: Multiple Video Share Sessions within a Single CS Call ..... 18 4.2.5 Use Case 5: Recipient Roaming ................................................................... 18 4.2.6 Use Case 6: Sender and Recipient Roaming.............................................. 20 4.3 Service Interworking........................................................................................................20

4.3.1 Scope ................................................................................................................. 20 4.3.2 Interworking Scenarios.................................................................................... 20

4.3.2.1 Interworking Scenario 1: User A shares video with User B on different networks. .....................................................................................................21 4.3.2.2 Interworking Scenario 2: Record and share on different networks. ..21 4.3.2.3 Interworking Scenario 3: Multiple Video-Share sessions on different networks......................................................................................................................22

4.3.3 Roaming ............................................................................................................ 23 4.3.4 Interworking Transactions and Charging Principles ................................... 23

4.3.4.1 General Commercial Principles ..............................................................23 4.3.5 Interworking Charging Principles Recommendations ................................ 24 4.4 Usability Studies ..............................................................................................................24

5 SERVICE REQUIREMENTS AND ENABLERS......................................... 24 5.1 Goals/Requirements .......................................................................................................24 5.2 Enablers ............................................................................................................................25 5.3 Service and Application Inter-dependencies ...............................................................25

6 DEVICE REQUIREMENTS ............................................................................ 25 6.1 Recommendations for Functional Requirements .......................................................26



6.1.1 Usability ............................................................................................................. 26 6.1.2 Codecs............................................................................................................... 26

7 SYSTEM REQUIREMENTS SPECIFICATIONS ........................................ 26

8 OTHER CONSIDERATIONS ......................................................................... 27 8.1 International Lawful Interception and Privacy .............................................................27 8.2 Security Review of Service Requirements ..................................................................27 8.3 Fraud Considerations and requirements .....................................................................27

9 GAP ANALYSIS TO EXISTING STANDARDS.......................................... 27



1 FOREWORD This document outlines the Service Definition for Video Share .It focuses on commercial and functional interworking aspects only. It is to be to be read in conjunction with the Video Share Interoperability Specification, (IR. 74) which provides technical information regarding terminal implementation and interoperability. The intended audience of this document is the GSMA Working Groups and mobile operators intending to deploy Video Share.

2 BACKGROUND Video Share is a peer-to-peer service using the IMS infrastructure to allow subscribers to stream real time video to one another while engaged in a circuit switched (CS) voice call. This service builds upon existing, non-standard Video Share implementations and trial implementations done for testing SIP interoperability. The goal of the service is to provide a common framework for a service that is interoperable among mobile operators. This Service Definition document in conjunction with the Video Share Interoperability Specification IR.74 describes the Video Share service concept in sufficient detail to enable the various GSMA expert groups to provide necessary support to the project. This Service Definition document will be reviewed and approved by SRG to ensure the Video Service is in line with the Services Review Group 8 Principles:

• Common solution across operators • Clear operator role to provide added value • Inter-operator charging principles • Appropriate customer charging model • End-2-End service • Third party management • Open access option • Secure and trustworthy services

The Service Definition document will be reviewed by the Working Groups responsible for Interoperability and Interworking, to identify what if any changes are to be made to their PRDs to ensure commercial interoperability (BARG- BA.27 & 12, AA.12-14; IWG- BA.27; IREG- IR.21; TADIG- TD.57) The Service Definition will be reviewed by Working Groups responsible for Fraud and Security to identify any possible security and fraud issues and resolve them. The Service Definition will be reviewed by Working Groups responsible for Devices (DG, SCaG) to identify and estimate any impact on devices or SIM cards.



3 OVERVIEW OF THE SERVICE 3.1 Introduction Video Share allows an enrichment of an already established voice call by allowing a user to capture and stream video (either live or pre-recorded) to another user in near real time. Video Share is distinct from Video Telephony in that it does not incorporate synchronized audio and is therefore less technically complex to implement. It can, however, be considered a stepping stone to future deployment of full-duplex video telephony. Alone, it allows users to extend their communication experience into the visual domain and provides mobile network operators an opportunity to create new revenue-generating services. Video Share has the potential to increase Average Revenue per Unit (ARPU) in two ways. First, the Video Share service can be chargeable; and second, adds the ability to share near real time video on top of a voice call creates an incentive for users to place voice/video calls where they might otherwise not. A measure of the perceived value of Video Share is that several handset vendors currently have developmental products that do Video Share, and some operators are planning proprietary deployments of Video Share working within their networks. Other operators have already launched commercial Video Share services. Presently, at least three specifications for Video Share exist. To realise its full revenue-generating potential, however, it is imperative that proprietary methods be made to interoperate. Subscribers typically will not adopt a new service if they have to concern themselves with whether or not the called party will be able to receive the service. Providing a level of standardization sufficient to ensure interworking between GSM operators and interoperability with different handsets makes the service available to more subscribers and makes it easy to use. The required standardization involves SIP and video protocols, codecs, and functional partitioning. The latter refers to the distribution of functions within the SIP/Video Share architecture (whether it is handled by the device or by proxy entities in the network), such as trans-coding, addressing, capability query, and others. The Video Share service will use the standardized IMS Core infrastructure to transmit the signalling and media traffic. IP Packet Exchange (IPX) proxies may be part of this infrastructure to allow interconnection between operators and to provide a collection point for session accounting records used for inter-operator traffic charging. The Video Share project builds on the technical work done within the GSMA SIP Trials, where a basic interoperable peer-to-peer Video Share capability was successfully defined, implemented and demonstrated during 1Q/06 in a multi-vendor, multi-operator environment composed of seven terminal vendors, 13 3GSM operators and eight GRX carriers. Roaming between GSM operators was not addressed in the SIP trials and is an essential element to providing a truly valuable service. By standardising the service to the extent that subscribers have a common expectation of how to call up and use Video Share, the likelihood increases that subscribers will remember to use the service.



Video Share is a new and evolving service so its capabilities and impact on networks are not yet fully defined. This Service Definition focuses on Video Share as opposed to other Share services such as Image Share and File Share. The project will take a two-phased approach, with the first phase concerned with establishing a common service framework for the basic form of video share that was demonstrated in the SIP trials and which is technically feasible today. The next phase addresses the more advanced features which current implementations do not support, such as:

• incorporation of presence awareness • video share in the absence of a circuit switched call • point-to-multipoint video share • and other enhancements yet to be determined

This service will likely be targeted at all market segments and include various charging models, such as pay-per-use, pre-pay, and subscription-based. Operators may deploy this service to enhance 3G sign-up rates, to drive voice-call revenue or to add to bottom line revenue figures as a service in its own right.

3.2 Project Information Reference: Project 127, Toll Gate 1 V1.0, approved May 19 2006 Project Sponsor: Tom Keathley Cingular Wireless Project Leader: David Smith, Cingular Wireless Project Manager: Adam Collier GSM Association Supporting Companies: Orange France, TIM, Cingular Wireless, TMN,

TeliaSonera, Rogers Wireless, Hong Kong CSL, 3 UK

3.3 Service Scope and Assumptions made As stated in the Introduction, the Video Share project will be accomplished in two phases to decrease time to market and improve the chances for success. The Phase 1 service is uni-directional, allowing one user to stream either real-time or pre-recorded video to another user while on a voice call. Mobile devices can either be traditional handheld devices or PC-based clients in 3G-enabled laptops. Video Share does not allow video calling, meaning that neither bidirectional video streaming nor synchronized audio/video will be supported. The Video Share service in Phase 1 requires an underlying circuit-switched voice call and the Video Share session can only be opened between the two parties to the voice call. During a single voice call multiple (sequential) Video Share sessions can be established, initiated by either party. Advanced circuit-switched call features, such as call forwarding, conferencing, call hold, and others., will not apply to Video Share (such as, Video Share will not be supported on a forwarded CS call for example). Packetised audio will not be supported for Phase 1. Video Share service capabilities will be expanded for Phase 2. Definition of the scope for Phase 2 is one of the deliverables of the Phase 1 work, but under consideration are the following:



• Incorporation of presence so that Users will be presented with

something like a ‘buddy list’ showing which of their contacts is available to receive video

• Point-to-multipoint video share such that one User can stream video to multiple recipients

• The ability for the Video Share to be paused and resumed • Standalone PS video share which does not rely on an underlying CS

voice call • Use of EDGE (unless SIP trials show EDGE to be not viable) • Incorporation of QoS • Non-mobile terminals (example: PC clients in ADSL or WLAN

networks) • Streaming of DRM protected content

3.4 High-level Service Concept Video Share is a peer-to-peer service using a 3GPP-compliant IMS core system to transmit packetised video. The Video Share session is set up using SIP and video is transferred using RTP. The service is intended to be interoperable between GSM operators worldwide having different IMS core systems and between users with different 3G devices. The following diagram shows the high level concept:

Figure 1: High-Level Figure of Video Share Connection (IPX Optional) To create a service Users will feel compelled to use, a Video Share service has to function with a minimum of set-up or provisioning activity on the User’s part and must support roaming-in and roaming-out. Video share is initiated from within a voice call. After a voice call is established, either party (calling or called) can start a Video share (VS) session. The sending User is then able to stream one-way live or recorded video. If available, the receiving handset has to automatically go to speakerphone mode when video is received, unless the headset is in place. The sender will be able to see what is being streamed on their handset, along with the receiving User. In this scenario, the sender can “narrate” over the CS audio connection while both parties view the video.



Both users will have the ability initiate a video share session, and either the sender or recipient in a video share session can terminate the session at any time. As part of the VS invitation, the recipient can choose to reject the streamed video. It is intended that both sender and receiver will receive feedback when the other party terminates a session or the link drops due to lack of coverage. By providing this feedback to users it is hoped they will be more tolerant of service malfunctions and will be less likely to become discouraged when the service fails, which will happen in the early days of deployment. Network-based servers are not required in Phase 1 Video Share, as this is a peer-to-peer service. However, in Phase 2 the possible additions of one-to-many sessions and Presence could require some kind of server side support. For further technical details of vendor independent Video Share service as specified and tested in SIP Trial activities, please see GSMA SIP Trial document “Video Share Definition”.

4 SERVICE DESCRIPTION 4.1 Technical Service Description The basic steps involved in setting up and tearing down a Video Share session are as follows:

• CS Call Setup • Capability Query • Invitation Procedure • Video Transmission • Teardown of Video Session • Teardown of CS Call

These steps are illustrated in more detail in this section which shows the general process flow used for Video Share. Note that figures are simplified for clarity reasons; for instance, network elements between User Equipment (UE) are not shown. Because Video Share uses the IMS infrastructure, both users must be registered with an active PDP context before sharing can occur. There are two options for handling the SIP Registration: "Always On" and "On Demand". The “Always On” mode means that a user establishes SIP registration at device ‘power on’ and remains registered all the time. “On Demand” implies the user establishes a PDP context only when engaging in an IMS-based service. The “Always On” mode ensures that users are registered with the SIP Registrar when they are in network coverage and ready for VS service at any time. If an operator chooses to implement “On Demand” registration it must be done in such a way that both parties have an active PDP context and are ready for a VS service during a circuit switch call. This implies that SIP registration creation before the Video Share Session formation.

4.1.1 Call Setup



The Video Share session begins with Circuit Switch call between User A and User B.

4.1.2 Capability Query

At any time during the Circuit Switched call either party can initiate a VS session; it’s recommended that the next step is the Capability Query in which the other terminal is queried to determine if the recipient is capable of supporting a Video Share session. This is performed with the SIP OPTIONS method. Both UEs can perform this query, Important: As defined in the Videa Share Interoperability Specification (IR.74) replying to a capability query is mandatory.

Call S

etupC

apability Query

Figure 2: Capability Query in Video Share The results of the capability query are indicated to the sending terminal using icons showing if the intended recipient’s device is VS capable. To minimise network traffic, capability caching may be deployed so that UEs can forego capability query if not needed. The caching of the capability query is optional and is handset dependant.

4.1.3 Session Setup/Invitation Procedure

SIP session setup for Video Share is performed following the Capability Query, using either the IETF mode or IMS mode of SIP signalling. Signal flow for each is shown in the following figures:



UE-A UE-B

CS-Voice

Capability Query Procedure

INVITE (request-uri: TEL-URI or SIP-URI)

100 Trying

200 OK

ACK

180 Ringing

Figure 3: Session setup in IETF mode

Figure 4: Session Setup in 3GPP mode

4.1.4 Video Transmission



After the Video Share session has been set up, transmission of the actual video can begin. Video is sent between Video Share clients using RTP (Real-Time Transport Protocol), which is widely used in internet and mobile communities for video streaming. The video transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery using RTCP RR (Receiver Report) and RTCP SR (Sender Report) packets.

Call Setup

Capability Q

ueryInvitation

ProcedureV

ideo Transm

ission

Figure 5: Video Transmission

4.1.5 Teardown of Video Session

When either party decides to stop the Video Share session, the session will be torn down (using RTCP BYE) and the SIP session stopped (using SIP BYE). After these steps the CS voice call session still exists.



Figure 6: Teardown Video Session

4.1.6 Teardown of CS Call

If users also want to terminate the CS voice call, normal procedures for CS call disconnect apply. After CS call has been torn down, we assume here for Phase 1 that the PDP context will be deactivated if terminal is using PDP Per Call mode. In Phase 2 we may consider the case where the PS session remains after termination of the CS call. In case Always-on is used, PDP context will remain after CS call has been terminated



Call S

etupC

apability Q

ueryInvitation

Procedure

Video

Transmis

sion

Teardown

Video

Session

UE-A UE-B

CS-Voice


Invitation Procedure

Video Transmission

Teardown Video Transmission

Teardown

of CS

Call

24.008 DISCONNECT

24.008 RELEASE

24.008 RELEASE COMPLETE

Figure 7: Teardown voice (CS) session

4.2 Functional Service Description / Use Cases Use cases for the Phase 1 Video Share service are shown in the tables below. Some general comments are noted as follows: Roaming: Video Share is intended to function in conventional roaming scenarios, and be charged accordingly. Conventional roaming scenarios include calling or called party roaming, or both. In these cases:

• The CS call should be charged as per normal operator roaming agreements.

• The PS service should be charged per normal operator roaming agreements..

• The CS and PS sessions should be treated separately Graceful Failure: The Video Share service is nominally available to subscribers within a 3G RAN only, which means a process for handling failures associated with one party transitioning into a 2G RAN must be addressed. A particular issue that needs to be addressed is how a session is terminated if both users move into no-coverage areas during a video session (such as, if the session cannot be properly terminated there may be problems with correctly charging for the service) Quality of Service:



This is not addressed for Phase 1

4.2.1 Use Case 1: Basic Video Share Use Case Name User A shares video with User B on same/different networks I want to Share real time video with User B on the same/different networks

ID Number VS1

Preconditions

Both devices are provisioned with Video Share clients (the provisioning can be done before the launch of the handset by the operator, without requiring any interaction by the user) Both users have VS service subscriptions & access credentials (example: ISIM) Operator has 3G network deployed and both users are within 3G RAN Note: Video Share within EDGE RAN is currently out of scope for Phase 1 Operator has IMS core infrastructure

Use Case Narrative

User A and User B are engaged in a CS voice call, initiated by either one. User A wishes to share video with User B and activates the VS client in his/her handset. A Capability Query is then performed between the two devices User A’s handset shows User B is capable of receiving video. User A selects “share video” on his/her device User B receives an invitation that User A wishes to transmit video. User B selects “accept video share”. User A receives an indication that User B has accepted the video share invitation. User A then captures video with his/her device camera which is streamed in real time to User B. Note: In this Use Case it is assumed audio is not streamed via PS link. User A’s device screen shows the video being sent to User B. The CS voice call is still active. Either User A or User B can terminate the video stream and both devices then indicate that the streaming session has been terminated.



Use Case Name User A shares video with User B on same/different networks

Exceptions

User B rejects video stream invitation from User A: User A receives an indication that VS invitation not accepted User B ignores video stream invitation from User A: User A receives an indication that VS invitation not accepted User A moves out of 3G coverage during streaming: User A’s device displays an indication that video streaming has been interrupted due to coverage loss. User B receives an indication that streaming was interrupted at the source. User B moves out of 3G coverage during streaming: User A receives an indication that video streaming has been terminated at the receiving end. User B’s device indicates that video streaming has been terminated due to coverage loss. User A’s handset fails (or battery dies): User B receives an indication that video streaming terminated at source OR loss of CS call serves as indication to User B that source has failed. User B’s handset fails (or battery dies): User A receives indication that video streaming terminated at receiving end OR loss of CS call serves as indication to User A that reception has failed. User B’s handset is not capable of receiving User A’s video stream: Prior to streaming video, User A’s handset will indicate (example: via greyed-out icon) that User B cannot receive video.

KPIs Video Share setup time is < 2 sec (setup time is a guideline only) Setup time is time from User A INVITE to SIP 200 OK and User A ACK CS vs. PS differential latency is < 2 sec

Constraints

User A’s device must have a camera capable of capturing video. User A’s and User B’s devices must use same video codecs, or network must employ transcoding Network must collect “call” records such that video session may be charged appropriately Both tel URI and SIP URI addressing schemes can be used. (note: tel URI addressing assumes ENUM capability)

Technical Comments

Audio is sent only via CS link and not via PS. If differential latency between CS and PS is sufficiently low synchronization between the CS audio and PS video may provide an acceptable subjective user experience, although this is beyond the scope of the VS project. Call records and charging infrastructure must be able to accommodate correct charging in the event video link is lost prior to proper termination.

4.2.2 Use Case 2: Sharing Recorded Video Use Case Name Record and Share on same/different network I want to Record video and stream at a later time to User B



Use Case Name Record and Share on same/different network

ID Number VS2

Preconditions Same as Use Case VS1, and additionally: User A’s device has capability to store ‘n’ seconds of captured video

Use Case Narrative

User A wishes to capture video to share with User B and cannot wait for User B to accept the stream before starting the video capture. User A records the video to his/her device for later streaming to User B. At a later time, User A sets up a Video Share session as in Use Case VS1, except that rather than sending real-time video, the pre-recorded video is streamed to User B.

Exceptions Same as Use Case VS1 KPIs Same as Use Case VS1 Constraints Same as Use Case VS1

Technical Comments

This Use Case could increase the cost of User A’s handset due to the memory required to store captured video. The ability to record and share video is therefore recommended to be an optional feature. The sharing of recorded video is a handset implementation option, and is not included in the Video Share Interoperability Specification, (IR.74).

4.2.3 Use Case 3: Record Received Video

Use Case Name User B Records received video stream on same/different network.

I want to Send real time video to User B, which User B then records.

ID Number VS3

Preconditions Same as VS1 and additionally: User B’s handset has memory capacity to record streamed video

Use Case Narrative

User A wishes to stream real time video to User B. User A would like to have the video recorded but lacks the capability (example: memory) to record the captured video. User A sets up a VS session with User B as per Use Case VS1 and verbally



Use Case Name User B Records received video stream on same/different network. requests (via the CS audio link) User B to record the received video. User B’s device has the capability and sufficient memory to store the video streamed from User A. User B selects “record video” and as the video is streamed from User A to User B, User B’s device displays the streamed video and simultaneously records it. When/if User B’s handset memory becomes full; an indication of such is presented to User B. The session ends as per Use Case VS1.

Exceptions Same as VS1 KPIs Same as VS1

Constraints Same as VS1 and additionally: Video stream must be generated by User A’s camera and not be subject to Digital Rights Management restrictions.

Technical Comments The recording of shared video is a handset implementation option, and is not included in the Video Share Interoperability Specification, (IR.74).

4.2.4 Use Case 4: Multiple Video Share Sessions within a Single CS Call

Use Case Name Multiple Video Share Sessions on same/different network

I want to Start and stop multiple sequential video share sessions with User B during a single CS voice call

ID Number VS4 Preconditions Same as Use Case VS1

Use Case Narrative User A invokes multiple video share sessions during one CS call by terminating and restarting the VS session.

Exceptions Same as Use Case VS1 KPIs Same as Use Case VS1 Constraints Same as Use Case VS1

Technical Comments

Every effort should be made to ensure that the time required to setup multiple VS sessions is kept to a minimum. Example: A user friendly handset with options to send additional streams after the initial stream has been terminated. IMS Infrastructure needs to be able to discern and account for the multiple video streaming sessions during the CS call.

4.2.5 Use Case 5: Recipient Roaming Use Case Name User B on roamed network. I want to Share video with User B who is roaming.



Use Case Name User B on roamed network. ID Number VS5

Preconditions

Both devices are provisioned with Video Share clients Both users have VS service subscriptions & access credentials (Example: ISIM) Operator has 3G network deployed and both users are within 3G RAN Both operators have IMS core infrastructures

Use Case Narrative Same as Use Case VS1 except that User B is roaming. If roamers incur terminating charges, User B should be informed during the INVITE procedure that charges may apply.

Exceptions Same as VS1 KPIs Same as VS1 Constraints Same as VS1 Technical Comments



4.2.6 Use Case 6: Sender and Recipient Roaming Use Case Name Users A and B on roamed networks

I want to Share video with User B who is roaming while I am roaming.

ID Number VS6

Preconditions

Both devices are provisioned with Video Share clients Both users have VS service subscriptions & access credentials (Example: ISIM) Operator has 3G network deployed and both users are within 3G RAN All operators have IMS core infrastructures

Use Case Narrative Same as Use Case VS1 except both Users A and B are roaming. If roamers incur terminating charges, User B should be informed during the INVITE procedure that charges may apply.

Exceptions Same as VS1

KPIs Same as VS1

Constraints Same as VS1

Technical Comments

4.3 Service Interworking 4.3.1 Scope Interoperability is a critical factor to the success of Video Share as it will drive adoption by subscribers. As this service will involve more than one operator, this section will describe the associated scenarios which clarify the interworking relationships, and in particular we will recommend control points and charging principles.

4.3.2 Interworking Scenarios In the following table we highlight which of the use cases from the previous section require interworking between operators: Case Number Description Requires interworking

Use Case 1 User A shares video with User B on same/different networks Yes, when on different networks

Use Case 2 Record and Share on same/different Network Yes, when on different networks

Use Case 3 User B Records Received Video Stream on same/different Network.

Yes but this scenario is identical to use case 1 in terms of interworking.

Use Case 4 Multiple Video Share Sessions on same/different Network Yes, when on different networks



Case Number Description Requires interworking

Use Case 5 User B on Roamed Network. No, see 3.3.3

Use Case 6 Users A and B on Roamed Networks No, see 3.3.3.

Therefore, we must analyze three use cases for interworking purposes. The following diagrams show the process flow when two operators are involved in a direct (bi-lateral) agreement. The elements of the data session that will generate periodic events are illustrated in bold and red. If an IPX model is used, the same events will be generated by the operator’s IMS infrastructure but will be passed to the IPX rather than directly to the receiving operator. The IPX will then have to settle with MNO-A and MNO-B. 4.3.2.1 Interworking Scenario 1: User A shares video with User B on different networks.

4.3.2.2 Interworking Scenario 2: Record and share on different networks. This scenario is similar to the previous scenario, the only difference being that the video has been pre-recorded and is therefore not streamed in real-time from User A’s camera.



4.3.2.3 Interworking Scenario 3: Multiple Video-Share sessions on different networks



UE-A UE-B

Invitation to Share Video

“Accept” Video Share

MNO-A MNO-B

CS-Voice

IMS Infrastructure IMS Infrastructure


User B appears as “VS capable”

User A begins capturing video through camera

Stop video share

CS-Voice session continues

...


“Accept” Video Share“Accept” Video Share

Stop video shareStop video share

Stop video share

CS-Voice session continues

Stop video shareStop video share

User A can see that VS is being sent



“Accept” Video Share


“Accept” Video Share“Accept” Video Share


Real-time stream of video Real-time

stream of video Real-timestream of videoEDR

EDREDR

Interworking events generated by MNO-A’s IMS infrastructure at regular intervals

Real-time stream of video Real-time

stream of video Real-timestream of videoEDR

EDREDR

4.3.3 Roaming Recommendations for roaming are as follows:

• Users should not incur SIP signalling charges when roaming • Roamed VS session will generate an additional data charge to the

roaming party (be they the sending or receiving party). 4.3.4 Interworking Transactions and Charging Principles Note: All recommendations do reflect the charging principles and do not reflect any recommendation with regard to the price-level on inter-working. Despite the recommendations given below, Operators can decide in bi-lateral agreements to, as an example, not apply charges for certain service enablers on inter-working. 4.3.4.1 General Commercial Principles

• Inter-working is not free; this aligns with IP Inter-working strategic initiative

• Initiating Party Pays (IPP) • Calling Party Pays (CPP), for the CS call • Signalling and SIP Setup will not be charged • For the enablers (presence & contact list management) – Phase 2



These transactions may be free of charge as far as viable to promote service and drive traffic All events with inter-working impact are defined and charging principles are proposed to every single event to allow inter-working charging if it is required by Operators after first service take off. It is recommended by the project to monitor the traffic caused by service enablers and to react accordingly, as an example in the case of un-balanced traffic 4.3.5 Interworking Charging Principles Recommendations Interworking charging bases for Packet Switched, Video Share may include:

• Time based (per minute) • Event Based (such as, per session) • Volume

No additional charges specific to Video Share except the ones linked to the volume exchanged should apply Video Share charging will be separate from CS voice call charging. The assumed model for VS charging is initiating party pays (note that we mean the party that initiates the VS session, which may not be the party initiating the CS call). Note: Charging will not be incurred if a VS session is rejected by the recipient or by some network profile for the recipient that causes VS to be automatically rejected. Advice of Charge is not considered for Phase 1.

4.4 Usability Studies No Video Share usability studies have been executed by the GSM Association.

5 SERVICE REQUIREMENTS AND ENABLERS 5.1 Goals/Requirements Note: QoS is not a requirement for Phase 1. We recommend the following performance goals and requirements for Video Share:

• Latency: Near-real-time (latency < 2 seconds) • Session set-up time: Less than approx 2 seconds (depends on

whether the user’s IMS registration is in “Always On” or in “On Demand” mode)

Please refer to the Video Share Interoperability Specification, (IR.74) for further information.



5.2 Enablers The Video Share service is envisaged to work in Wideband CDMA networks with IMS core infrastructure IMS authentication will be assumed, using either the early IMS Security, IMS AKA using ISIM or USIM, or HTTP Digest. (3GPP has defined only the Early IMS Solution and the preferred full IMS solution where the authentication uses Digest-AKA, a combination of AKA and HTTP-Digest. 3GPP did not allow the use of HTTP-Digest method (without AKA) because this poses a security problem insofar as the HTTP-Digest password needs to be provisioned by other insecure methods if AKA is not used to provision it. It can also be argued that allowing HTTP-Digest seems to contradict the requirement in section 5 to bind the "user subscription ... to their smart card".) Both PDP Always-On and PDP On Demand modes can be used. If PDP Per-Call mode is used, SIP registration and PDP activation are performed upon the CS call. Always-on method decreases the set-up time of Video Share. The shorter the session set-up time, the better the end-users rate the service. The GPRS Exchange (GRX) architecture will be used as the interconnect network. The service is envisaged to be deployed via bilateral interconnect until such time as IPX becomes available. This service definition and supporting documents are written with transfer to IPX in mind For “see-what-I see” functionality the service does not require DRM. Sharing of DRM-protected video clips may be addressed in Phase 2. DRM is not supported in Phase 1. The service is based on current billing methods and does not create any additional requirements for mobile payment methods. There are no Trust Model or Location Awareness requirements for the Video Share service.

5.3 Service and Application Inter-dependencies Video Share currently does not depend on other services. Note that interdependencies will be addressed in Phase 2. IMS is seen as Infrastructure and not as service interdependency.

6 DEVICE REQUIREMENTS Authentication and authorization for the Video Share service is implicit in IMS authentication. Thus it is assumed that VS-compliant devices contain an ISIM/USIM properly provisioned with public and private identities and access credentials. A user’s subscription has to be bound to their smart card (ISIM/USIM) such that the Video Share service is portable in the sense that the user may be able to send and receive video share on any capable handset The device needs to be 3G or EDGE compliant, and in the case of EDGE the device needs to support DTM. When a Video Share session is established, the receiving handset has to automatically go to speakerphone mode (if available) when the video received, unless the recipient’s headset is in place. When placing a CS call, Video Share will be an option via the phone book just like



SMS and a soft key can indicate the Video Share capability of potential recipients. The Video share client should be easy to configure whether by the MNO before launching the handset, or using OTA solutions. If capability information is already available, the Video share Icon should be activated. If this information is not to hand, and depending on the capability query procedure chosen, after the circuit switch call has been established and the capability determined, the video share Icon should be activated. Conversely, if the capability information is available, and one party is not compliant, the Video Share Icon should be hidden from mobile phone menus. Note: This could be due to network or handset limitations.

6.1 Recommendations for Functional Requirements No device support for streaming QoS or secondary PDP context associated with QoS is required for Phase 1 Video Share

6.1.1 Usability • Devices shall support privacy policies that allow users to block other

users from performing a Capability Exchange with their device and/or streaming video to their device.

• Either a transmitting or receiving device shall be able to terminate a VS session at any point during the session.

• A Video Share session shall be terminated upon termination of the underlying CS call

• The device shall not present an option to initiate Video Share when it is on 2G.

• The device shall drop a VS session when the device transitions from UMTS to GSM during the session and provide the user with a user-friendly indication of the drop. The CS voice call shall remain connected.

• Receiving device should provide audio indication of an incoming VS request, in addition to a visual indication

• Device should go to speakerphone mode upon receipt of video stream unless a headset is in use

• Transmitting device should display the video that is being streamed 6.1.2 Codecs Refer to Video Share Interoperability Specification, (IR.74)

7 SYSTEM REQUIREMENTS SPECIFICATIONS No special SIM/USIM provisioning (Assumes ISIM or derivation of public identity from IMSI).



From a User perspective when the video share application is available on the device, there should be no provisioning operation done by the customer. The service should be available without any specific action. Infrastructure assumptions are:

• IMS core • Envisaged to work via bilateral interconnect, bilateral IPX interconnect

and/or multi-lateral IPX interconnect. • 3G network • SIP stack/client in phone

8 OTHER CONSIDERATIONS 8.1 International Lawful Interception and Privacy Lawful interception is already covered as this service uses existing bearer network connections As Video Share will operate as though it is a P2P service the network will merely be a carrier and will not have visibility of the content. It is recommended that Terms and Conditions must absolve the operator of any liability for any illegal content that is transmitted.

8.2 Security Review of Service Requirements A/B Number spoofing has been exploited on IMS & SIP based services; implementations of such services need keep this in mind. SIP is exposed to call setup packets being used for transmission of additional textual information such as a simple free SMS style text exchange could be establishes using call setup packets. However, this is not an issue if the Video Share service will only operate during a rated voice call.

8.3 Fraud Considerations and requirements When considering further enhancements to Video Share, the streaming of non-video data needs to be aware of possible arbitrage issues with other data services.

9 GAP ANALYSIS TO EXISTING STANDARDS There are currently no existing standards for Video Share as a service by itself. Several (at least three) known proprietary specifications exist, however. It is the goal of this project to consolidate these existing specifications toward a common service framework. The Video Share service will rely on enabling specifications that exist today to provide signalling and bearer functions, authentication, and others. It is recognized that interaction with SDOs will be necessary to ensure Video Share devices and infrastructure elements interoperate. Liaisons with the OMA may, for example, be



needed to develop application layer specifications to standardize signalling interfaces and user experience. And since 3GPP ‘owns’ the IMS infrastructure, liaisons with that group may be necessary if changes to their specifications are indicated by the work performed within this project.

End of Document


gsm association official document se.41

Documents