TR 22.906
Study on IMS based Peer-to-Peer Content Distribution Services
V18.0.1 (PDF)
2024/03 17 p.
V17.0.0
2022/03 17 p.
V16.0.0
2020/06 17 p.
V15.0.0
2018/09 17 p.
V14.0.0
2017/03 17 p.
V13.0.0
2016/01 17 p.
V12.0.0
2014/10 17 p.
V11.0.0
2010/06 17 p.
- Rapporteur:
- Mr. Li, Frank, gang
China Mobile Com. Corporation
Content for TR 22.906 Word version: 18.0.1
0 Introduction
1 Scope
2 References
3 Definitions and abbreviations
4 General Description
5 Use Cases
6 P2P Content Distribution Service Considerations in Fixed and Mobile Network
7 Potential Service Requirements
8 Potential Charging Requirements
9 Potential Security Requirements
10 Copy rights Issues
11 Conclusion
$ Change history
0 Introduction p. 4
The development of fixed and mobile broadband technologies (e.g. G/E-PON allows about 100Mbps downlink and 100Mbps uplink, LTE allows the possibility of the speed up to 100Mbps downlink and 50 Mbps uplink) and more and more powerful mobile handsets have boosted popular usage of content distribution services (e.g. Live streaming and Content on Demand) on mobile handsets.
With the explosive growth of media content consumption, the number of media servers to provide streaming services is required to be increased almost linearly with the number of users. In addition, centralized streaming media servers require considerable demands towards the bandwidth of the backbone IP network. So it's required to deploy more and more edge servers close to UEs to guarantee service quality with the increasing number of users.
Peer-to-peer technology can be used between edge servers and UEs to relieve the above problem. Not only the edge servers handle the requests from its locally served UEs, but also they can handle the requests transferred from the neighbouring edge servers. Similarly, if the UE's capabilities permit, the UE can offer spare uplink bandwidth and storage space while obtaining data, and uploads data to other requested destinations. Content is transmitted in a segmented manner, and most of the traffic can be spread across the edge of the network, which helps reduce the storage and bandwidth demands of centralized servers. So the system capability is improved along with the increasing number of edge servers and UEs.
IMS, proposed by 3GPP, is viewed as a fixed and mobile convergence core network to provide multimedia services, and defines an infrastructure for user authentication, registration, service discovery, and multimedia session control and etc. So this Technical Report is aimed to study content distribution services in a Peer-to-Peer manner based on IMS from SA1's perspective and it is expected to identify the use cases and potential service requirements.
1 Scope p. 5
This Technical Report presents the overview, use cases and other aspects (e.g. Mobility, Charging, Security and etc.) of IMS based Peer-to-Peer Content Distribution Services. And the potential service requirements will be identified. The objectives are to study IMS based content distribution services with the following aspects:
- Identifying the user cases to describe how users, operators and service providers will may benefit by using/deploying IMS based content distribution services in fixed and mobile convergence networks with Peer-to-Peer technology;
- Identifying service aspects where IMS network improvements are needed to cater for content distributed services for above accesses;
- Identifying mobility, charging and security related requirements in the case of content distribution services on IMS;
- Identifying potential copyright issues;
2 References p. 5
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.101: "Service Aspects; Service Principles".
[3]
TS 22.105: "Services and Service Capabilities".
[4]
TS 22.233: "Transparent end-to-end packet-switched streaming service; Stage 1".
[5]
TS 22.246: "Multimedia Broadcast/Multicast Service (MBMS) user services; Stage 1".
[6]
TS 22.115: "Service aspects; Charging and billing".
[7]
TS 22.220: "Service requirements for Home NodeBs and Home eNodeBs".
[8]
TS 21.201: "Technical Specifications and Technical Reports relating to an Evolved Packet System (EPS) based 3GPP system".
[9]
Open IPTV Forum release 2: "Functional Architecture". http://www.openiptvforum.org/docs/OIPF-Functional_Architecture_v2_0-2009-09-08.pdf
[10]
ETSI TS 182 019 release 3: "TISPAN - Content Delivery Network (CDN) architecture".
[11]
Draft ETSI RTS 182 027 release 3: "TISPAN - IPTV Architecture, IPTV functions supported by the IMS subsystem".
[12]
Draft ETSI TR 182 010:" Peer-to-peer for content delivery for IPTV services, analysis of mechanisms and NGN impacts".
3 Definitions and abbreviations p. 6
3.1 Definitions p. 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.
Peer-to-Peer:
A concept related to A distributed network architecture composed of participants that make a portion of their resources (such as processing power, disk/cache storage or network bandwidth) directly available to other network participants.
Peers:
The entities (e.g. UE, network entity) of both suppliers and consumers of resources, in contrast to the traditional client-server model where only servers supply, and clients consume.
User Peer:
The UE type of participants in the Peer-to-Peer network both providing services to other participants and requesting services from other participants, e.g. PC terminals.
Network Peer:
The participants in the Peer-to-Peer network deployed and controlled by operators/service providers both providing services to other participants (e.g. User Peer or Network Peer) and requesting services from other participants, e.g. the cache server deployed by operators/service providers.
Content Source Server:
An entity, which stores the source content, and provisions interface for other entities to fetch content.
Content Cache Server:
An entity, which caches partial/entire source content to be distributed to end users. The data on Content Cache Server is obtained from the Content Source Server or other Content Cache Servers via pre-distribution of the source content or upon users' request. The Content Cache Servers usually are deployed at the edge of the network to accelerate content distribution.
Content Control Server:
An entity, which performs the management of content indexing and control content distribution (e.g. how the source content is distributed from the Content Source Server to the Content Cache Servers).
3.2 Abbreviations p. 6
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.
P2P
Peer-to-Peer
CDS
Content Distribution Service
CoD
Content on Demand
CDN
Content Delivery Network
G-PON
Gigabit Passive Optical Network
E-PON
Ethernet Passive Optical Network
WLAN
Wireless Local Area Network
H(e)NB
Home NodeB and Home eNodeB
4 General Description p. 6
4.1 Overview p. 6
The following Figure explains the network elements involved in IMS based Peer-to-Peer Content Distribution service and how they interact with each other.
IMS UEs initiate the content distribution service via fixed or mobile access network to IMS CN Subsystem. IMS UE will be redirected to the portal, which offers content indexing, browsing and searching functionalities. The content is usually stored on content source servers (e.g. Network entities or UEs) and content cache servers are deployed close to the users to accelerate content distribution.
User profile is stored in IMS and the terminal capabilities (e.g. processing capabilities, screen size) are stored in Peer-to-Peer application service, when available. After IMS UEs request content distribution services, User Profile will provide the P2P application service with the user's preferences and terminal capabilities will be used to decide whether or not the client is capable of receiving the requested content. Content control is used to control how the content is distributed in the network and where IMS UEs can get the requested content.
Figure 4.1: Overview of IMS based Peer-to-Peer Content Distribution System
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
5 Use Cases p. 8
5.1 Content-on-Demand Service for Large numbers of Online Users p. 8
5.1.1 Service Description p. 8
Jessica is an IMS subscriber of operator A, and she wants to view the popular movie "Transformer", but for some reason she doesn't want to watch it in cinema. She notices from a pushed advertisement on her IMS client that IMS online movie theatre can provide "Transformer" on demand with a discounted price. So she decides to watch it from online movie theatre.
(1)
Jessica starts her IMS P2P application client and begins IMS registration process. After Jessica finishes her registration, the IMS P2P application (e.g. a Portal) delivers the program information to the P2P client. Jessica searches and selects the "Transformer" in the program list of the Portal to tell the P2P application that "I want to watch Transformer";
(2)
After receiving Jessica's request, the P2P application queries the locations of film storage resources of "Transformer", and then sends back the list of resource locations to Jessica. At the beginning the content cache server 2 has some initial parts of "Transformer" (e.g. Part 1 and 2) and the content source server has all parts of it. So the P2P application tells Jessica "the content cache server 2 has "Transformer", you may download from it";
(3)
Jessica's UE asks the content cache server 2 "Which parts of "Transformer" do you have? Can I download them?";
(4)
Upon receiving "yes", Jessica's UE downloads the first two parts of "Transformer" from the content cache server 2 and begins to watch "Transformer" and the rest of parts of "Transformer" will be retrieved from the content source server.
(5)
Jessica's UE updates the information (e.g. which parts Jessica currently have) to the P2P application service and retrieves the latest information of where the "Transformer" parts are distributed from the P2P application service periodically, e.g. every 2 minutes;
(6)-(8)
As time goes by, more and more users around Jessica (in domain 2) join the watching queue of "Transformer" and are served by content cache server 2. More and more users tend to watch the parts that the cache server 2 doesn't have, so those parts will be retrieved from the source server. As a consequence, the content source server becomes congested and the Quality of Experience for the end users deteriorates. Fortunately, from step (5), the users in domain 2 know that the content cache server 1 has cached the rest parts of "Transformer" and can serve some of the users. As a result, the workload of the content source server is relieved to some extent and can serve more users.
(9)-(10)
As time goes by, a lot more and more users in domain 1 and 2 join the watching queue of "Transformer", and as a consequence the content cache server 1 and 2 are getting overloaded. Fortunately, from step (5), Jessica's UE knows from the P2P application service that Jason, Alice and Bob's UEs around her have some parts of "Transformer", so Jessica's UE tries to download some parts of "Transformer" from her three neighbours via the most appropriate access technology; As a result, the workload of the content cache servers is relieved to some extent and can serve more users.
5.1.2 Service Benefit p. 9
- IMS users' registration, authentication and service discovery can be reused to support the CoD service.
- It helps reduce backbone bandwidth consumption and content source server workload if Peer-to-Peer CoD is used because the content can be obtained from multiple sources rather than the central source server.
- If the content is segmented and distributed in the network, it helps reduce the time-to-market of CoD since the segments of video content are smaller and can be downloaded to the cache servers more quickly.
5.2 Live Streaming Service for Large numbers of Online Users p. 9
5.2.1 Service Description p. 9
It is Olympic Games time, and the live final basketball game starts at 8:00 pm tonight. Jessica can't go to the stadium to watch it live due to the limited number of available tickets Jessica is an IMS subscriber of operator A and she notices from a pushed advertisementon her IMS streaming client that IMS Live Channel can broadcast the final basketball game live. So she decides to watch the final basketball game from IMS Live Channel.
(1)
Around 8:00 pm, Jessica starts her IMS streaming client and begins IMS registration process. After Jessica finishes her registration, the IMS streaming service (e.g. a Portal) delivers the information of live channels to the client. Jessica searches and selects the basketball game live channel in the broadcast channel list to tell the IMS streaming client that "I want to watch basketball game now";
(2)
After receiving Jessica's request, the IMS streaming service can't provide access to IP multicast services due to some reason (e.g. capacity bottleneck or the access router doesn't support IP multicast functionality), so it turns to application level mulitcast based on Peer-to-Peer model, and the multicast Peer-to-Peer service offers the basketball game with a small delay; it queries the locations of the channel resources of "basketball game", and then sends back the list of resource locations to Jessica. At the beginning only the content cache server has cached the basketball game. So the IMS streaming service tells Jessica "the content cache server has the basketball game, you may stream from it";
(3)
Jessica's UE downloads the parts of basketball game from the content cache server and begins to watch the basketball game;
(4)
Jessica's UE updates the information (e.g. which parts Jessica currently have in her cached memory) to the IMS P2P application service and retrieves the latest information of where the basketball game parts are distributed from the IMS periodically, e.g. every 10 seconds;
(5)
As time goes by, more and more users in domain 1 join the watching queue of the basketball game and the content cache server is getting overloaded. Fortunately, from step (4), Jessica's UE knows that Jason, Alice and Bob's UEs around her have some cached parts of the basketball game, so Jessica's UE tries to download some parts of the basketball game from her three neighbours; As a result, the workload of the content cache servers is relieved to some extent and the content cache servers can serve more users.
5.2.2 Service Benefit p. 10
Application level multicast based on Peer-to-Peer is a good alternative to IP multicast to achieve nearly live streaming for large number of online users. However, this service may cause some latency, but still provides nearly real-time experience to users.
5.3 Efficient Software Distribution to large numbers of Users p. 10
5.3.1 Service Description p. 10
Operator A runs an IMS network with a large number of subscribers (e.g. more than 10 million) and a critical software bug in IMS client software has just been identified and the software patch needs to be distributed to every user as quickly as possible, otherwise, this software defect might bring potential serious security issues.
Since the end users are geographically distributed in the network, the whole network is divided into different domains and some cache servers close to the end users in each domain have been deployed in order to reduce download time and lower cross-network traffic.
(1)
If some users (e.g. Alice and Bob in Area 1) request to upgrade their IMS client software or the network might request to upgrade end users' IMS client software by force. And then the software patch from the software source server is distributed into the cache servers in that domain.
(2)
The software patch is delivered to Alice and Bob from the cache servers close to them.
(3)
As more and more cache servers request to cache the software patch from the software source server, the software source server might get congested, and instead the cache server might choose to download (parts of) the software patch from the domains that already cache the software patch.
(4)
As more and more users (e.g. Jerry and Michael) in Area 1 request to download the software patch, the cache servers in Area 1 might get congested. Since Alice has already cached (parts of) the software patch, she can provide (parts of) the software patch to Jerry and Michael.
(5)
Before Bob collects all parts of the software patch, some unusual event (e.g. network congestion or software crash) happens, and as a consequence, Bob's IMS P2P application client loses the connection to the P2P application service. Therefore, Bob's IMS P2P application client has to re-establish the connection with the P2P application service. Bob's IMS P2P application client doesn't have to start downloading the software patch from scratch and then it interacts with the Software Source Server to continue downloading the remaining parts that have not been finished before such unusual event happens.
Figure 5.3: Efficient software distribution to large numbers of users
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
5.3.2 Service Benefit p. 11
With the introduction of Peer-to-Peer the software update can be distributed to large numbers of users in a short period of time with a proliferated way.
6 P2P Content Distribution Service Considerations in Fixed and Mobile Network p. 11
6.1 Considerations on Types of User Equipment p. 11
There are several criteria for consideration on whether different types of UE are capable of playing the role of User Peers.
- Battery consumption;
- Available upload/download bandwidth;
- Available computing capability;
- Available storage space (including disk storage and cache storage);
- Availability of UEs;
6.2 Considerations on Types of Access Network p. 12
6.2.1 Comparison of Different Access Networks p. 12
Available bandwidth and mobility are major factors to be considered to select User Peers.
Fixed-line networks (e.g. xDSL, LAN) tend to have high bandwidth. Furthermore, UEs attached to fixed-line are more likely to have stable connections for a longer time. So, it is preferable to select UEs attached to fixed-line network (e.g. xDSL, LAN) as User Peers.
WLAN have relatively high bandwidth. Therefore it is also preferable to select UEs attached to WLAN as User Peers.
3G macro cells and LTE macro cells have more limited bandwidth and the bandwidth is always shared among many users and services. Thus, UEs attached to 3G macro are normally not suitable to play the role of User Peer. UEs attached to LTE macro network may be considered to enable the functionality of User Peers only if there is spare bandwidth for use given the fact that voice traffic has higher priority over other data traffic.
H(e)NB have a relatively high bandwidth, which is shared among a small number of users. UEs attached to H(e)NB could play the role of User Peer.
Different access networks have different mobility patterns and bandwidth. UEs attached to the fixed-line (e.g. xDSL) are less likely to move and may be attached to the same access point for a longer time. UEs attached to WLAN or H(e)NB also tend to move less frequently compared to those attached to macro cells.
So, in conclusion, it can be seen that it is more preferable to select UEs attached to fixed-line, WLAN or H(e)NB as User Peers.
6.2.2 Network Peer Deployment Based on Types of Access Network p. 12
Depending on the content popularity, the content cache server with the enhancement of Network Peer could be deployed with macro cell controllers, H(e)NB or WLAN Access Point, which is close to the edge of the access network.
When Network Peers are deployed on the macro cell controllers, network operators have more control over the cache and each Network Peer could serve a large number of users. Network Peers deployed on H(e)NB or WLAN have lower bandwidth to the core network and could be powered off by users, but a larger amount of such cache servers could be deployed. Thus, it is more preferable to cache niche conents (contents only interested by a small number of users) on cache servers in H(e)NB or WLAN. While for popular contents, it is more desirable to be cached in macro cell controllers which have higher bandwidth to the core network.
6.3 Interworking with the CDN p. 12
Content Delivery Networks (CDNs) are widely deployed to accelerate content distribution over a large area network. It improves network performance by maximizing bandwidth, and improves content accessibility as well as maintaining correctness through content replication. In a CDN, content is replicated from the origin server to cache servers, and scattered over the globe, in order to deliver content to end-users in a reliable and timely manner from nearby optimal surrogates.
IMS Peer-to Peer Content Distribution System can benefit from the CDN through the following two ways:
- To take advantage of the content stored/cached in the existing CDNs, the CDN can simply be viewed as the Content Source Server with the minimum changes on the CDN system.
- In order to better leverage the infrastructure of the existing CDNs, it's beneficial to enhance the edge servers in the existing CDNs to perform the functionalities of Network Peers since a large number of edge servers usually are deployed in the existing CDNs.
7 Potential Service Requirements p. 13
Based on the use cases in clause 5 and considerations in clause 6 following possible requirements can be identified:
7.1 Requirements to the IMS CN subsystem p. 13
- IMS shall be able to provide Peer-to-Peer content distribution services for users, i.e. IMS UE is capable of obtaining content from multiple User/Network Peers.
- IMS shall be able to select qualified User Peers among available UEs according to the policies preconfigred in the network.
- The UEs attached to access networks which can provide upload/download bandwidth higher than the predefined limit by the operator are preferred.
- The UEs which maintain stable network connections are preferred.
- IMS shall be able to provide the UE with the appropriate server to obtain the addresses of Peers, from which the UE can retrieve the requested content.
7.2 Requirements to the IMS P2P application service p. 13
- IMS P2P application service shall support segmentation and segments indexing of the distributed content (e.g. Content on Demand, Live streaming, and File downloading).
- IMS P2P application service shall notify the users of the appropriate Peers to retrieve the requested content segments.
- IMS P2P application service shall be able to provide the UE with the appropriate server to obtain the addresses of Peers, from which the UE can retrieve the requested content.
- IMS P2P application service shall be able to resume Peer-to-Peer file downloading after interruption without starting from the beginning.
- IMS P2P application service shall be able to select qualified Network Peers according to the policies preconfigured in the network.
- Those entities, which are deployed at the edge of the network and have stable connections and sufficient cache and storage space, are preferred.
- The popular content shall be able to be cached across the stable Network Peers, which are controlled and owned by operators.
- The existing CDN shall be able to support the Network Peer functionality of IMS based Peer-to-Peer Content Distribution System.
- IMS based Peer-to-Peer Content Distribution System shall be able to obtain the source content from the CDN.
8 Potential Charging Requirements p. 13
Charging models that shall be supported by the IMS P2P Content Distribution Service include (non-exhaustive list):
- The network shall be able to charge based on content
- The network shall be able to charge based on the types of services, such as live streaming service, CoD service or downloading service
- The network shall be able to charge based on the duration that user uses the service
- The network shall be able to charge based on the traffic that users receive
- The network shall be able to support alternate party charging
- The network shall be able to charge based on the amount of resources UEs contribute
9 Potential Security Requirements p. 14
Since the User Peers might contribute resources to other users and to some extent are out of control of operators/service providers, the users might cheat the system and tamper with the content uploaded for other users. The following requirements to the P2P application service need to be considered:
- The network shall be able to identify whether the User Peers honestly report the information of their contributed resources (e.g. cached or stored content);
- The network shall be able to identify whether the User Peers tamper with the content uploaded for other users;
- The network shall be able to protect the content exchanged among users against unauthorized access (e.g. undesirable leakage of and/or modification on possibly copyright-protected content).
- The network shall be able to prevent the User Peers against distributing any illegal content to other users.
10 Copy rights Issues p. 14
Since IMS based Peer-to-Peer Content Distribution Service might allow the User Peers to exchange (parts of) the content, it might bring about potential copy right issues even if the source of the content originates from the content server rather than User Peers themselves.
Therefore the following requirements to the P2P application service should be considered:
- The network shall be able to prevent the unauthorized re-distribution of copyrighted content stored or cached in the User Peers;
- The network shall be able to identify and prevent the distribution of copyrighted content uploaded by the users;
11 Conclusion p. 14
This TR has identified the following use cases: Content on Demand, Live Streaming, and File Downloading. The related service requirements, charging requirements and security requirements are also identified. Also, considerations on UE types, 3GPP access networks and non-3GPP access networks have been discussed.
In order to support Peer-to-Peer Content Distribution Services, it is concluded that IMS needs to be enhanced, and for this, cooperation with other SDOs dealing with content distribution may be needed.
$ Change history p. 15
