20 Network PVR

26.2373GPPIP Multimedia Subsystem (IMS) based Packet Switch Streaming (PSS) and Multimedia Broadcast/Multicast Service (MBMS) User ServiceProtocolsRelease 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

20.1 NPVR Recording procedure

20.1.1 General Description

Network-PVR (NPVR) is a function for a user to record program(s) in the network side for future accessing and consuming.

Figure 45: NPVR

The following is a description of the interactions in the flow:

1. The UE, on behalf of the user, issues a request to record a live program. The program can be either currently broadcasting program (instant recording) or a future program (scheduled recording). The record request includes the relevant information like program identifier, timing information, etc

2-3. Receiving the record request, the SCF first checks whether the program is recordable and whether the user has the right to record it. If fine, the SCF further checks whether the user has enough storage space. Following that, the SCF creates a context for the record request, and update the user’s profile with the record status "record request captured".

4-5. The SCF responses to the user, notifying the acceptance of the record request.

6-7. For instant recording, the SCF starts the recording by selecting a proper PSS Adapter, and directing it to set up a delivery channel with a content source to receive content. The PSS service initialization procedure as defined in section 8.2.3 shall be used.

For scheduled recording, the SCF creates a timer for the request. When the start time comes, the SCF directs and controls the Recording server for recording as the case for instant recording.

Notes: Upon reception of more than one NPVR request for the same program, the SCF, based on local policy, may issue only one record request to Recording server. In this case, the SCF will update each of the requestor’s user profile when recording status changes.

8. Once the NPVR request is started, the SCF will then update all the requestors’ user profile with the recording status "recording started".

9-12. The PSS Adapter for NPVR setup and starts the recording according NPVR request; The Recording server retrieves the streamed content for live streaming service and records the content properly.

13-14. When recording completed, the Recording server send RTSP ANNOUNCE message to the PSS Adapter;

Note: the Recording server may deliver the recorded content to a PSS Server for serving any NPVR retrieve, or store the content in itself and acting as PSS Server later. How to deliver the recorded content to another PSS server is out of scope of the present document.

15-16. The PSS Adapter send SIP UPDATE to SCF to indicate the ending of NPVR recording;

17-20. The SCF teardown the SIP session and the PSS Adapter teardowns the RTSP session for NPVR recording.

21. Once the NPVR request is completed, the SCF will then update all the requestors’ user profile with the recording status "recording completed".

20.1.2 Procedures at UE

When UE initiates the request for NPVR Request, the UE shall issue a SIP MESSAGE according to TS 24.229 [7] with the following additions:

– The Request-URI shall be composed of a user and domain part as defined as follows:

– The user part shall be "PSS_PVR_<content-id>" wherein content-id shall be globalContentID of the content to be recorded.

– The domain part is the Service Provider domain name, obtained from SSF.

– The Content-Type of the message body shall be set to "application/3gpp-ims-pss-mbms-npvr+xml"

– The message body shall include XML document as defined in Annex N.

– The NPVRRequest shall be present;

– ProgramID : if present, identifies the content to be recorded; when occurs, shall be globalContentID retrieved from User Service Description

– ServiceID: identifies live channel to be recorded; it shall be globalServiceID retrieved from User Service Description

– RecordStartTime: indicates the time to start recording, where "0" or time before now implies instant recording, while other time implies scheduled recording;

– RecordDuration: indicates the time duration of the recording;

Upon receiving a SIP MESSAGE, the UE shall identify it as a NPVR response by comparing the content type of the message body with "application/3gpp-ims-pss-mbms-npvr+xml". Following that, the UE shall response with 200 OK response.

20.1.3 Procedures at SCF

The SCF shall support the procedures specified in [TS124503] as applicable to an AS acting as a terminating SIP UA.

When receiving any NPVR request, the SCF shall first response with 200 OK, and then examine the request to see:

– If the user subscribed to the PVR service.

– If the program is allowed to recorded.

– If it is compatible with the user’s profile (e.g. parental control level).

– If the new item to be recorded doesn’t exceed the user’s storage quota, by checking the user’s profile.

The SCF shall then construct a SIP MESSAGE request towards the UE with the NPVR response. The content of the message shall be as follows:

– The Request-URI shall be set to the IMPU of the user.

– The Content-Type of the message body shall be set to "application/3gpp-ims-pss-mbms-npvr+xml"

– The message body shall include XML document as defined in Annex N.

– The NPVRResponse shall be present;

– Result: indicate the status of the NPVR request, i.e. Error or request accepted.

Following that, the SCF shall create a context for the request, register relevant information and update the user profile for that user, with the status for PVR changing to "Recording Captured", meaning that a NPVR request is pending execution.

For instant recording, the SCF starts the recording immediately by selecting a proper Recording Server, and sending a SIP INVITE message to the PSS Adapter to initialize a Recording Session.

For scheduled recording, the SCF creates a timer for the request. When the start time comes, the SCF starts the recording immediately by selecting a proper Recording Server, and sending a SIP INVITE message to the PSS Adapter to initialize a Recording Session.

Based on the local policy, the following should apply to avoid duplicated recording:

– Upon receiving a scheduled recording request, the SCF check whether the same program (identified by ServiceID and ProgramID) has been requested to record. If yes, the SCF shall not issue another NPVR request for the same content.

– Upon receiving an instant recording request, the SCF examines the status of the program. If the same program (identified by ServiceID and ProgramID) is already under recording, the SCF shall not issue another NPVR request for the same content.

When starting the recording, the SCF shall build the SIP INVITE message as follows:

– The Request-URI in the INVITE request shall be the IMPU of the selected Recording server

– The To header shall contain the same URI as in the Request-URI.

– The From header shall be set to "PSS_PVR_<content-id>@domain name", wherein content-id shall be globalContentID of the content to be recorded;

A NPVR request XML document and an SDP offer shall be included in the request body. The SDP offer shall be done in accordance with the parameters signalled in service selected information. The SDP offer at media level shall include the following elements:

– The m-line(s) shall be set to the media parameters retrieved via service selection procedures for the requested service.

– The c-line(s) shall be set according to the IP address retrieved via service selection procedures for the requested service.

Upon receiving the SIP UPDATE message from the PSS Adapter for NPVR, the SCF shall extract the NPVR recording result from the message and update the user profile of all the users who requested to record the content. Following that the SCF shall teardown the session by initiating a SIP BYE to the PSS Adapter.

20.1.4 Procedures at PSS Adapter

The PSS Adapter for NPVR shall support the following RTSP methods for NPVR session establishment and teardown control:

– SETUP (PSS Adapter to Recording server).

– RECORD (PSS Adapter to Recording server).

– ANNOUNCE (Recording server to PSS Adapter).

– TEARDOWN (PSS Adapter to Recording server).

Upon receipt of a SIP INVITE message, the PSS Adapter shall identify it as a NPVR request by the From header, and then performs the following actions:

– It shall resolve the RTSP URI based on the Request-URI, the SDP parameters and the selected Recording server.

– It shall construct and send the RTSP SETUP message(s) to setup the relevant media streams.

– Return the answer SDP to the SCF in the SIP 200 OK.

The PSS Adapter shall construct the RTSP SETUP message according to the SIP INVITE as follows:

The Request-Line shall be present of format: Request-Line = Method SP Request-URI SP RTSP-Version CRLF:

– Method field is set to SETUP;

– RTSP-Version field to be set of RTSP/1.0.

The CSeq header field is set to a value allocated by PSS Adapter according to RFC 2326 [25]

The transport header field:

– the protocol and profile sub-fields together are set to a value of the protocol sub-field of the corresponding "m=" line in the SDP offer,

– the unicast | multicast parameter is set according to the "c=" line.

– The destination parameter is set to a value of the "c=" line in the SDP offer,

– The RTP port value is set to the value of the port sub-field of the corresponding "m=" line in the SDP offer, and the RTCP port value is set to a value of the RTP port value plus 1.

The PSS Adapter may send multiple RTSP SETUP messages if multiple media delivery channels are carried within the SDP offer. In this case, the pipeline of multiple RTSP SETUP messages may be supported.

When receiving a RTSP 200 OK response from the Recording server, the PSS Adapter parses the response, constructs a SIP 200 OK response with the final SDP, and sends the SIP 200 OK response to the SCF.

Following that, the PSS Adapter shall further send RTSP RECORD message to the Recording server to start the recording. In the message the range header shall be set according to the time duration of the NPVR request.

Upon receiving the RTSP ANNOUNCE with NPVR result, the PSS Adapter shall initiate a SIP UPDATE message to the SCF. The content of the SIP UPDATE message shall be as following:

– The Request-Line shall be set to "PSS_PVR_<content-id>@domain name", wherein content-id shall be globalContentID of the content to be recorded

– The To header shall contain the same URI as in the Request-URI.

– The From header shall be set to the IMPU of the selected Recording server;

– The body shall contain the XML document received from the Recording server, with necessary information (i.e. ProgramID, ServiceID, etc.) added;

Upon receiving SIP BYE message from the SCF, the PSS Adapter shall respond with a 200 OK and send a RTSP TEARDOWN message to the Recording server.

20.1.5 Procedures at Recording server

The Recording server shall conform toRFC 2326 [25].

Upon receiving a RTSP SETUP request, the Recording server shall validate the request and setup content delivery channel(s) according to the SDP.

Upon receiving the RTSP RECORD request, the Recording server shall start to record the media properly according to the time in range header.

When finishing the recording, the Recording server shall issue a RTSP ANNOUNCE message to the PSS Adapter to report the record result. Within the message body, the Recording server shall include a XML body associated with the appid "urn:3gpp:npvr:2010:IMS-PSS-MBMS". In the XML document, the NPVRResponse shall be present and the parameters shall be set:

– Result: the result of the recording (i.e. Completed, Error).

– AccessURL: the identifier reference to the recorded content, for UE to request later.

Upon receiving the RTSP TEARDOWN message, the Recording server shall teardown the PSS Recording Session according to RFC 2326.

20.2 NPVR Retrieving

20.2.1 Procedures at UE

After the recording is finished, the UE can get the AccessURL as identifier of the recorded content by checking the user profile.

To consume the recorded content, the UE shall perform PSS session initialization procedure as defined in sub-clause 8.2.3.2, with the following additions:

– The Request-URI shall be "PSS_COD_<content-id>", where the content-id shall be set to the AccessURL.

20.2.2 Procedures at SCF

The SCF shall perform the procedure as defined in sub-clause 8.2.3.3.

20.2.3 Procedures at PSS Adapter

The PSS adapter shall perform the procedure as defined in sub-clause 8.2.3.4.

20.2.4 Procedures at PSS server

The PSS server shall perform the procedure as defined in sub-clause 8.2.3.5.