Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x
Top   in Index   Prev   Next

TR 22.947
Study on Personal Broadcast Service (PBS)

V17.0.0 (PDF)  2022/03  20 p.
V16.0.0  2020/06  20 p.
V15.0.0  2018/09  20 p.
V14.0.0  2017/03  20 p.
V13.0.0  2016/01  20 p.
V12.0.0  2014/10  20 p.
V11.0.0  2012/09  20 p.
V10.0.0  2010/04  20 p.
Rapporteur:
Mr. Sultan, Alain
ETSI

Content for  TR 22.947  Word version:  17.0.0

Here   Top

 

0  Introductionp. 5

As a mobile service network evolves to a versatile packet data network, the service paradigm of mobile operators is gradually shifting from voice oriented communication to multimedia information sharing. A mobile device is no longer a simple tool for person to person communication, but now becomes an indispensable item for receiving essential information distributed for human society. Information for entertainment services such as TV or Radio show, as well as information for public safety, energy saving, environmental conservation, and for searching emergency aid, need to be delivered to the right person at the right time in any location. The multimedia broadcast service, MBMS TS 22.146, and packet switched streaming TS 22.233 TS 26.234 is a widely deployed technique which fulfils the basic service requirements. However provisioning of content is currently allowed for a limited group of content providers, and ordinary users have no way to utilize the service.
The rationale of Personal Broadcast Service is to give an open opportunity for ordinary people to generate content, and broadcast it on air. A variety of broadcast services and a new device market may emerge once users are able to access the content distribution service. Abundant broadcast content will be available to be selected by 3GPP users. The extent of other potential service area is unbounded.
The objective of this document is to present some envisaged use cases of Personal Broadcast Service, for creative engineers and standard developers to pursue further investigation of PBS, and move to the next steps necessary for enhancement of relevant 3GPP standards.
Up

1  Scopep. 6

This Technical Report presents potential use cases of Personal Broadcast Service. It aims to take account of service and system aspect of PBS. The minimum set of service requirements associated with each use case will be identified.

2  Referencesp. 6

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
  • References are either specific (identified by date of publication, edition number, version number, etc.) or non specific.
  • For a specific reference, subsequent revisions do not apply.
  • For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[1]
TR 21.905: "Vocabulary for 3GPP Specifications".
[2]
TS 22.146: "Multimedia Broadcast/Multicast Service; Stage 1".
[3]
TS 22.246: "Multimedia Broadcast/Multicast Service (MBMS) user services".
[4]
TS 23.246: "Multimedia Broadcast/Multicast Service (MBMS); Architecture and functional description".
[5]
ETSI TS 181 016 v.2.0.0, "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Service Layer Requirements to Integrate NGN Services and IPTV," 2007-11
[6]
OMA, "Mobile Broadcast Services Requirements," Approved Version 1.0 - 12 Feb 2009
[7]
TS 22.115: "Service Aspects; Charging and Billing (Release-9)"
[8]
TS 22.233: "Transparent end-to-end packet-switched streaming service; Stage 1".
[9]
TS 26.234: "Transparent end-to-end Packet-switched Streaming Service (PSS); Protocols and codecs".
[10]
TS 26.346: "Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs".
[11]
U.S. Department of Transportation Research and Innovative Technology Administration, "Intelligent Transportation Systems Benefits, Costs, Deployment, and Lessons Learned:2008 Update", September 2008, www.its.dot.gov
[12]
ERTICO - ITS Europe, "Activities 2008", 08 May 2008, www.ertico.com
Up

3  Definitions, symbols and abbreviationsp. 6

3.1  Definitionsp. 6

For the purposes of the present document, the terms and definitions given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.
(void)

3.2  Symbolsp. 7

For the purposes of the present document, the following symbols apply:
(void)

3.3  Abbreviationsp. 7

For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.
BSU
Broadcast Service User
CoD
Contents on Demand
MBNO
Mobile Broadcast/Multicast Network Operator
PBS
Personal Broadcast Service
PBSP
Personal Broadcast Service Provider
PBSF
Personal Broadcast Service Function
PBCP
Personal Broadcast Contents Provider
UGC
User Generated Contents
VoD
Video on Demand
Up

4  General descriptionp. 7

4.1  Service concept and definitionp. 7

Personal Broadcast Service (PBS) is a content distribution service using 3GPP accesses. This enables any Internet user, private company or mobile user to generate content, and broadcast/multicast it to mobile users. Types of User Generated Content (UGC) in this context include not only multimedia files such as video, audio or image, but also variety of digital information distributed for various purposes such as e.g. public safety, energy saving, environment conservation.
The User Generated Content can be distributed in either a time unconstrained Content on-Demand (CoD) method, or in a time constrained, real-time method. In the former case, the contents are uploaded to a server and downloaded at the request of users at a convenient time. Most CoD applications and some MBMS user services may be delivered using unicast bearers as defined in TS 22.246 TS 26.346. However in some application, CoD users may share the content using multicast bearer service. A use case of shared VoD service is presented in this document.
In the case of live broadcast, content is delivered to multiple users simultaneously, as such a broadcast or multicast bearer is necessary for resource saving. A broadcast bearer service [3] is efficient when a large number of receivers are expected and the receivers are spread in many cellular areas. Major TV or Radio services are examples that may utilize such a broadcast bearer. UGC stream may also be transmitted using broadcast bearer if the population of receivers justifies cost for delivering the content. Private show of very popular celebrity or daily episodes of small production company may be a potential example. Another area of use case is localized broadcast in campus, theatre or theme park. Details of the use cases are presented in this document.
In contrast to broadcast bearer service, UGC will be delivered using multicast bearer service in many use cases. Content providers of Personal Broadcast Service may appear and disappear at any time. Content distribution may commence on an ad-hoc basis. Therefore, it will be inefficient to pre-allocate resources for such unpredictable content providers. New interfaces and requirements will be necessary to support such content providers. The communication may occasionally be bi-directional. Interactive data generated by mobile receivers needs to be passed to content providers. Some additional functions, e.g. time-stamping or adding cell ID, may need to be performed on upstream user data. This aspects associated with interactivity will be discussed in detail.
Currently, 3GPP supports an OMA [6] defined interface to be used between mobile operator and broadcast content provider TS 23.246. Therefore, most broadcast applications that require a static allocation of resource may be supported using existing 3GPP and OMA standards. However new set of requirements and standards may be necessary to support distinctive features of PBS use cases as introduced in this document.
Up

4.2  Roles of actors in use casesp. 8

The roles of major actors used in the description of each use case are explained in this clause.

4.2.1  Personal Broadcast Content Provider (PBCP)p. 8

Personal Broadcast Content Provider (PBCP) is an individual or organization that produces electronic content for the purpose of distribution to mobile users. Any Internet user, company, school, government or even major TV or radio broadcasting company can be a Personal Broadcast Content Provider if one uses PBS.
In order to provide PBS service, PBCP needs to make information about the content available to a service provider, and reserve necessary resources via a wired or wireless connection that will be used for content delivery. The connection may be established via Internet or 3GPP radio access. When 3GPP radio access is used, the type of content provider is referred to Mobile PBCP. The Mobile PBCP is a 3GPP user, and the user typically generates contents while it is moving.
PBCP may receive user data via the Internet. For example, interactive data transmitted by service users, or user information provided by mobile operator can be delivered to PBCP.
Up

4.2.2  Personal Broadcast Service Provider (PBSP)p. 8

Personal Broadcast Service Provider (PBSP) is an independent service provider whose major role is brokering content delivery between PBCPs and the mobile operator. While it is always possible for a mobile operator to directly receive contents from PBCPs without the involvement of PBSP, independent service providers may do better business by advertising, collecting good PBCPs and developing convenient User Interface software. Use cases in this document assume the role of PBSP between mobile operator and PBCP.
In some use cases, distinction between PBCP and PBSP is unclear. An example is when a PBSP creates contents using automated content production machine or unmanned device, e.g. game server, surveillance camera. In such case, the role of PBSP and PBCP are combined.
Up

4.2.3  Broadcast Service User (BSU)p. 8

The Broadcast Service User (BSU) is typically a 3GPP UE that consumes PBS content distributed via 3GPP accesses. Some use cases assume a dedicated PBS service terminal integrated with a vehicle (e.g. car audio, GPS navigation) be used rather than a hand held device. The actual transmission method (i.e. unicast, MBMS) is transparent to the BSU.

4.2.4  Mobile Broadcast/Multicast Network Operator (MBNO)p. 9

The Mobile Broadcast Network Operator (MBNO) provides content distribution services to PBSP and PBCP. The service typically includes distribution of content information, session notification and content transmission. MBNO is responsible for protecting content from unauthorized access by users. MBNO may report information of usage statistics (e.g. receiver population, resource consumption, access failure of user) to PBSP and PBCP.
When an interactive service is requested, the MBNO provides reliable bi-direction communication path between BSUs and PBSP (or PBCP). Upon reception of BSU data, MBNO may perform access control, fairness control, DoS prevention and other filtering actions. MBNO may further perform some value added functions on the BSU data, such as e.g. time-stamping, appending cell identity.
Figure 1 below shows an example of service association between the actors.
Copy of original 3GPP image for 3GPP TS 22.947, Fig. 1: MBNO service association with actors
Figure 1: MBNO service association with actors
(⇒ copy of original 3GPP image)
Up
In Figure 1, the PBSF (Personal Broadcast Service Function) box depicts an interconnection point with PBSP, PBCP and Mobile PBCP. The PBSF may be a sub-function of the BM-SC TS 23.246 or an independent network element. Details of the architectural description are beyond the scope of this document.
Figure 1 illustrates that MBNO needs to provide external interfaces to PBSP and PBCP respectively, and an internal interface via network of the Mobile PBCP. The interfaces are used for dynamic resource provisioning , content delivery, information transfer, upstream data delivery, and there may be other uses. The interface between MBNO and broadcast content provider is used for static resource provisioning, and it is shown for completeness.
Up

5  Use casesp. 10

5.1  Receive only personal streaming content servicesp. 10

5.1.1  Service descriptionp. 10

The receive only personal streaming content service is similar to real-time Internet TV or radio service. Any Internet user or 3GPP user may register the service, and distribute contents at their convenient time. The content provider (i.e. PBCP) should be able to negotiate resources and costs for distribution of contents. The negotiation may be performed directly with operator (i.e. MBNO) or indirectly via PBSP. Failure of receiver (i.e. BSU) access to the content due to resource shortage or UE incapability should be reported to PBCP, therefore PBCP may adjust resource demand of the content.
Notification should be given to BSUs prior to PBS session initiation. The BSU may choose categories of broadcast to be notified about, e.g. from an electronic service guide. The service system of this use case must be able to support various size of BSU group, from single user to hundreds of users per cell.
From a user's perspective, the service type is similar to operator provided TV or VoD service [3]. List of available PBS streams may be provided and users may change content streams. Latency for content switching must be within a bearable bound to the user's perception.
BSUs should be able to access PBS service using third party software which is not supplied by MBNO or PBSP.
QoS should be supported. Resource allocation may be triggered by the request of user or by service provider. It should be possible to report the number of users to the service provider, and remove resource when there is no more a user receiving the service.
A number of subscription and charging methods should be supported. For example, the PBS service can be provided based on monthly subscription, pre-paid subscription (e.g. pay-per-service, pay-per-usage), temporary subscription for limited period or without requiring subscription at all. Roaming users should also be able to access the service based on operator policy.
Up

5.1.2  Service benefitp. 10

Any Internet or 3GPP user may have an opportunity to broadcast one's own streaming content on air. 3GPP users may enjoy an abundance of real-time streaming content in addition to MBMS TV service [3]. A dedicated service terminal (e.g. car audio or portable radio capable of receiving PBS) and new service markets may emerge.

5.1.3  Additional remarksp. 10

Broad range of use cases of mobile broadcast are studied in other standard organizations. Interested readers are advised to reference [5] [6] for use cases that are not fully listed in this document.
This use case and the requirements can generally be applied to other use cases.

5.1.4  Service requirementsp. 10

  • PBSP and PBCP (including Mobile PBCP) should be able to negotiate QoS and cost for content distribution.
  • PBSP and PBCP (including Mobile PBCP) should be able to request notification prior to content transmission.
  • Notification may be given to BSUs prior to streaming session initiation.
  • BSUs may be able to choose categories of content to be notified about, e.g. from an electronic service guide.
  • BSUs should be able to access PBS service using third party user interface software.
  • Statistical information (e.g number of BSUs, resource usage) should be collected and make available to PBSP and PBCP.
  • It should be possible that failure of BSU access (e.g. resource shortage or UE incapability) be reported to PBCP.
  • Handover within the same radio access technology should be transparent to BSU.
  • Latency for content switching should be within an acceptable bound to user perception.
  • QoS should be supported.
  • When macro cell and Home (e)NodeB cell are combined, service continuity between the cells should be supported.
Up

5.2  Interactive Personal Broadcast Servicesp. 11

5.2.1  Service descriptionp. 11

Interactive Personal Broadcast Service is a bi-directional content distribution service. In this use case, BSUs may transmit uplink data, and PBCP may use the feedback data for downlink content generation. Interactivity can be supported in two types of services, embedded menu type service and conversation type service.
In embedded menu type service, PBCP integrates sub-menus in streaming content which are displayed on top of a video image. When BSU selects a menu, short uplink message is transmitted, or a dedicated bearer is established for further interaction with an application server. Use cases of this service type are on-line opinion poll, on-line auction, interactive shopping or electronic coupon service [5] [6].
In conversation type service, BSUs may participate in real-time talk show using human readable data, such as text, image, short voice or video clips. PBCP may combine the BSU transmitted data with streaming content. PBCP may control membership for participation in conversation. For example, PBCP may send invitation message to one of BSUs or refuse service to abusive participant. MBNO is required to support necessary functions to perform access control and policy control over BSU transmitted data. Quality and fairness as well as delay constraint must be guaranteed, therefore human interaction between PBCP and BSUs is well supported.
MBNO may also transmit supplemental information when it delivers BSU data. For example in applications like on-line auction, timestamp can be added on BSU transmitted data in order to use the information for determining best bidder. Other information as location of BSU, current cell identity, UE capability may also be appended.
Up

5.2.2  Service benefitp. 11

The interactive service offers users opportunity to participate in broadcasting.
The upstream data generated by service interaction will improve operator revenue. In embedded menu type service, the web link may point to the portal service of PBSP. Multi-party conversation using interactive PBS may be a new revenue creating service.

5.2.3  Additional remarksp. 11

The multi-party conversation type PBS service offers similar user experience as conference call or Push to talk on Cellular (PoC). While these services use multiple unicast connections, conversation type PBS service is based on multicast or broadcast bearer, as a result, resource usage is efficient, in particular when the communicating parties are camping in the same cell.
Another popular use case based on interactive broadcast service is on-line gaming of which detail of service scenario is described in [5] [6].
Up

5.2.4  Service requirementsp. 11

  • Embedded menu type interactive PBS service should be supported.
  • Conversation type interactive PBS service should be supported.
  • It should be possible to configure access control and policy control over BSU data transmission.
  • Supplemental information (e.g timestamp, cell identity) in addition to upstream user data should be made available to PBSP or PBCP.

5.3  Mobile Content Provider Servicep. 12

5.3.1  Service descriptionp. 12

The Mobile Content Provider (i.e. Mobile PBCP) provides personal broadcasting service using mobile device. Typical use cases are outdoor group activities such as guided tour, sport activity, school excursion.
For example in a guided tour, a tourist guide use mobile device for speaking group of tourists instead of using noisy amplifier. Streaming audio [9] [10] as well as multimedia information, electronic tickets for entering tourist sites can be distributed. The location information of the tourist guide is constantly broadcast that the tourists may keep track of the guide when they are spread in large area. Paging capability of the mobile PBCP is an important function to support because the tourist guide needs to reassemble the group and move to another location. Interactive communication between the mobile PBCP and users also need to be supported.
Copy of original 3GPP image for 3GPP TS 22.947, Fig. 2: Use Case for Guided Tour
Figure 2: Use Case for Guided Tour
(⇒ copy of original 3GPP image)
Up
In other service scenario, carpoolers may find suitable car drivers around their location using PBS.
The user who looks for car sharer sends a request message to PBSP (i.e. carpool service provider) with information of current location and destination. The PBSP verifies the identity of the requester, and broadcasts the message in the area the requester is waiting. The PBSP may broadcast additional information of the requester (e.g. image, personal preference, native town) that the car drivers may find interest to the message.
Car drivers who received the message calculate the route, and if it is possible to share the car, the driver sends his offer to PBSP. The PBSP also verifies identity of the drivers, and sends information of drivers to the requester. When there are multiple drivers offering carpool, the requester selects one of the drivers and directly contact to the driver. Courtesy message of refusal may be given to other drivers by PBSP on behalf of the requester.
Up

5.3.2  Service benefitp. 12

Group of users involved in outdoor activity may keep contact using mobile device.
The mobile operator may charge for uplink usage of mobile PBCP or broadcast reception of BSUs.
Carpool has been promoted in many countries for public benefit, such as energy saving, green-house gas reduction, urban traffic reduction. The PBS based carpool service will greatly improve convenience and safety of carpooling because PBSP provides service to those members that identity is proven.

5.3.3  Additional remarksp. 13

None.

5.3.4  Service requirementsp. 13

  • It should be possible for mobile user providing content distribution service using PBS.
  • Interactivity should be supported between mobile content provider and service users.
  • Mobile content provider should be able to page multiple users
  • Mobile content provider should be able to limit the area of content broadcast based on geographical location information

5.4  Public Transport Information Broadcast Servicep. 13

5.4.1  Service descriptionp. 13

This service provides information of public transport (e.g. current bus location, passenger boarding state, estimated arrival time) to mobile users. Similar service has been known in ITS (Intelligent Transport Systems) [11] [12] area, and some pioneering services have already been introduced in some country. A service case is that the location of Bus is monitored using road side wireless sensors, and the information is provided to public using ARS (Automated Response System), SMS or fixed display installed in each bus stop.
This PBS based service further improves convenience of ITS by delivering tracking information of public transportation directly to mobile device. It is assumed all public vehicles periodically report information of location (e.g. GPS coordinates) to PBSP (i.e. ITS server in this context) via 3GPP accesses. A user connects to PBSP using mobile device and plans route, transit stations and vehicles to use, and register the trip. This registration of trip information may not necessarily require reservation of seat or payment of fee. The PBSP periodically broadcast information of selected vehicles in the area of the user. Note that there may be multiple users waiting the same vehicle that sending the information repeatedly to each individual device will be inefficient. The mobile device receives information of all connecting vehicles and shows estimated arrival time, passenger boarding state, etc. If a vehicle is fully boarded or delay is expected, alternative route is suggested. As a vehicle approaches to user location, the mobile device alarms and the user rides one the vehicle. The mobile device alarms again at each transit station and shows guide information for changing vehicle.
Copy of original 3GPP image for 3GPP TS 22.947, Fig. 3: Use Case for Public Transport Information Service
Up

5.4.2  Service benefitp. 14

This service will be helpful to regular commuters as well as travelers who visiting unknown place.
Passengers do not need to wait in outdoor bus stop, but they may wait in nearby comfort place, such as coffee shop, because they know the location of vehicles.
Critical information of vehicles, such as unexpected delay or over-boarding state, can be spread quickly that waiting users may choose alternative transportation. This behavior will also be helpful to alleviate congestion state.

5.4.3  Additional remarksp. 14

This service requires pre-registration of trip plan by users in order to broadcast information of selected vehicle. Using the information, it is possible to estimate number of passengers to ride on each vehicle. The transportation company may use the information to improve service. For example the company may deploy reserve vehicle into busy line if unexpected surge of passengers is forecasted.
Note that public transport system may be different by each city and country. However the information format and user interface of this service need to be consistent. This may require global standard for service.
Charging aspect is an interesting issue if pre or post-payment using mobile device is supported. In particular, considering overseas roaming user, the mobile device can be used as versatile charging device for any type of public transportation in any country.
Up

5.4.4  Service requirementsp. 14

  • It should be possible to broadcast public transport information (e.g. ITS) using PBS.

5.5  Shared VoD Servicep. 14

5.5.1  Service descriptionp. 14

This service offers VoD (Video on Demand) like broadcast service by sharing content streams with multiple users.
Similar to VoD service, users browse list of contents and send their request for content distribution to a service provider. The service provider selects a content that has received the request from the largest number of users. The service provider checks if a multicast stream for the selected content can be allocated in the cells that the users are camping. If there is sufficient resource available, the service provider broadcasts a notification to users. Users may join the multicast session and start receiving the content stream, as a result, it maximizes the opportunity for resource sharing.
When the request of the largest group is satisfied, the service provider selects content request of the next largest group for multicast stream allocation. If there is any cell that necessary resource cannot be reserved, the service provider waits until multicast stream can be allocated in all cells that users of the next largest group are camping.
From the user's perspective, the user may immediately join any on-going Shard VoD session, or send a request for new content distribution. If the requested content is a popular one, it may quickly gather sufficient number of requests and distributed frequently. However, if the content is a rarely viewed one, resource for the content may be allocated only when the network is free. In that case, the user may need to set a function for automatic saving and view the content later.
As the users move in and out of a cell, handover should be performed with minimum service interruption. Resource in a cell may quickly be depleted if users of different content streams coincidentally converge in a cell. In that case, it should be possible to reduce transmission rate of streams, e.g. discarding some packets, with sacrificing video quality. Quality degradation due to packet dropping should be confined in a cell and it should not affect streams in other cells.
Up

5.5.2  Service benefitp. 15

Since the Shared VoD service maximizes opportunity for resource sharing, relatively large number of users can be serviced than the case providing contents using VoD. It also has an effect to reduce the service cost by sharing the expense with large number of users.

5.5.3  Additional remarksp. 15

The key aspect of this service is use of multicast service bearer in providing VoD like service in order to achieve bandwidth saving. However the level of efficiency may also be achieved using broadcast service bearer if the population of users justifies global allocation of resource. In this case, a periodic counting of users should be supported that if the number of users is reduced to certain degree, the service bearer can be switched to unicast or multicast service bearer and the broadcast resource can be reassigned to other contents.
Up

5.5.4  Service requirementsp. 15

  • It should be possible to provide shard VoD service using PBS.
  • It should be possible for PBSP to identify cells of users.
  • It should be possible for PBSP to designate cells to broadcast message.

5.6  Personal Download Content Servicep. 15

5.6.1  Service descriptionp. 15

Users are able to download lucrative contents on a regular basis from a content provider. A typical user behavior is to download the contents and consume it when commuting back and forth between home and working place. The service is getting popular and an increasing number of users use to download Mbytes files when travelling. The content is the same for each user and users are expected to consume the service when it's most appropriate for them.
For an MBNO this gives an opportunity. The service approach, which is based on point-to-point download is resource wasting. As the service subscribers can be reached simultaneously over their respective broadcast area, why not to allocate a few seconds radio resource during the off peak time and download the contents to many users at the same time. Once downloaded, the non time critical content can be consumed whenever the subscribers want. This approach is resource efficient and allows a good business opportunity for MBNO and PBCP. By allocating a slot from broadcast resource it is able to satisfy PBCPs business need without overloading network (see 26.346 for MBMS download).
Up

5.6.2  Service benefitp. 16

This property gives an opportunity to download large files to many users in a resource saving manner compared to point-to-point download approach.
This property enables new business model for MBNOs, PBCP and PBSPs.
This property enables an enjoyable service for BSUs.

5.6.3  Additional remarksp. 16

File download can be performed using pull mode or push mode service.

5.6.4  Service requirementsp. 16

  • PBSP and PBCP (including Mobile PBCP) should be able to register for the content distribution service via the Internet or 3GPPP access.
  • PBSP and PBCP (including Mobile PBCP) should be able to request notification prior to content transmission.
  • It should be possible to give notification to BSUs prior to download session initiation.
  • Statistical information (e.g. number of BSUs, resource usage) should be reported to PBSP and PBCP.
  • Means to accomplish content download in case of failure e.g. due to handover shall be provided
Up

5.7  Localized Broadcast Servicep. 16

5.7.1  Service descriptionp. 16

This service provides free or discounted access of PBS service available only in a designated area, such as campus, shopping mall, stadium or theme park. For example, video lectures or company seminar can be broadcast to students or employees in a campus. Tourist guide or free movie can be provided to visitors of park, shopping mall or other public place. When multiple cameras are installed in concert hall, theatre or sports stadium, live broadcast streams of different view point can be provided to audience, that users may choose their favourite view of player, sound or multi-language speech.
Notification of availability of the service should be given to eligible user when the user enters into the designated area. However the user should be able to disable reception of PBS notification selectively according to pre-configured category. For example, the user may disable any PBS notification activated around shops, but the user may allow notification around tourist sites. The service provider (i.e. PBSP and PBCP in this context) may also transmit message or notification in order to announce important update of session.
The designated service area may consist of macro cell, Home (e)NodeB cell or combination of both. When macro cell and CSG cell are combined to form a designated area, service continuity of localized broadcast should be supported when users move between the macro cell and Home (e)NodeB cell. Subject to operator policy and user subscription type, service continuity should be supported when a user moves out of the designated area. Otherwise, it is acceptable to discontinue the localized broadcast service outside of the designated area.
Up

5.7.2  Service benefitp. 16

Major benefit to customer is free or discounted charging of the service in the designated area. Operator may offer lower service cost in the area where focused use of the service by large population is expected. Companies or organization may pay for the service cost to provide free customer service. Users may enjoy live broadcast information conveniently using mobile device. New concept of electronic marketing using localized broadcast may ultimately replace typical paper leaflets or handouts distributed for advertisement.
Up

5.7.3  Additional remarksp. 17

None.

5.7.4  Service requirementsp. 17

  • Localized broadcast service should be supported in area consisting of one or more macro cells, Home (e)NodeB cells or combination of both cells.
  • When macro cell and Home (e)NodeB cell are combined to constitute a localized broadcast service area, service continuity between the cells should be supported.
  • Notification of availability of the service should be given to eligible user in an event that the user enters into a localized broadcast area.
  • User shall be able to disable or enable reception of notification according to pre-configured service category.
  • QoS should be supported for localized broadcast service.
  • Subject to operator policy and user subscription type, the service provider of the localized broadcast should be able to disable or enable access of users.
Up

6  Chargingp. 17

Various charging and billing methods described in TS 22.115 should be supported.
PBSP or PBCP may pay for the service cost if they want to provide free access service. Use cases of shopping mall or tourist place is the example.
Subject to service contract with PBSP or PBCP, operator may need to share the profit collected from BSUs. Multi-party on-line gaming or music download service is the example.
It should be possible to support variable charging rate by access hour.
Up

7  Securityp. 17

The PBS should be protected against unauthorized access.
The BSU may hide or disclose privacy information to PBCP.

8  Conclusionp. 17

PBS is an enabling technology for any private organization or ordinary user to broadcast one's own contents on air. The service is characterised by one-to-many group mobile communication that the potential benefit has not been sufficiently studied. Use cases and benefits to users, operators as well as device manufacturers are investigated in this document. Some requirements and charging aspects necessary to support PBS are presented.
It is concluded that full range of service interaction between personal content providers and users may not be supported adequately in existing 3GPP specification. Further enhancement in existing 3GPP specification may be necessary..
Up

$  Change historyp. 18


Up   Top