Object repair device and method in multicast-broadcast

Abstract

Disclosed are a terminal supporting an MBS and a method performed by the terminal. According to embodiments of the present invention, the method may comprise the steps of: detecting omission of some or all data of an object on basis of in-session in which an object distribution session is in progress; storing missing data detection time information about the object in which the omission is detected in a queue in correspondence to the object; calculating a repair request time of the object on the basis of one or more pieces of missing data detection time information stored in the queue; and transmitting a repair request of the object to a server at the calculated repair request time of the object.

Description

Device and method for object recovery in multicast-broadcast

[0001] The embodiments relate to an apparatus and method for object recovery in multicast and broadcast in a Multidia Broadcast / Multicast Services (MBS) environment.

[0002] Generally, Multicast-Broadcast User Services (MBS) refer to large-scale simultaneous content delivery services in a mobile communication environment. In other words, MBS is a user service framework that utilizes multicast and broadcast transmission methods to efficiently deliver a single piece of content to multiple terminals.

[0003] In such an MBS environment, an object distribution method can be used to divide and deliver content into objects in the form of files or segments. In this case, the objects are transmitted via multicast or broadcast sessions, and the terminal combines the received objects to play or process the final content.

[0004] However, situations may arise where objects are not properly received by the terminal due to factors such as changes in channel quality of a moving terminal, temporary radio interference or packet loss, cell boundary movement, handover situations, network congestion, or insufficient terminal resources. Furthermore, in object distribution methods, if even a single object is missing, content playback may become impossible or quality may be significantly degraded.

[0005] As such, while multicast or broadcast transmission is advantageous in terms of large-scale transmission efficiency, it has structural limitations in immediately compensating for object reception failures occurring at individual terminals. Therefore, an object repair function is required to selectively recover missing objects for individual terminals.

[0006] The technical problem according to the embodiments is to provide a device and method for efficiently recovering a missing object when object reception fails in an MBS environment in order to solve the aforementioned problems, etc.

[0007] The technical problem according to the embodiments is to provide a device and method for efficiently recovering an object that failed to be received at a terminal when a session is in progress in a multicast / broadcast environment in an MBS environment.

[0008] However, the scope of rights of the embodiments is not limited to the technical problems described above, and may be extended to other technical problems that a person skilled in the art can infer based on the entire content described.

[0009] To achieve the aforementioned purpose and other advantages, a method performed by a terminal in an MBS environment according to the embodiments may include: detecting the omission of part or all data of an object in an in-session basis in which an object distribution session is in progress; storing time information for detecting the omission of the object's data in a queue corresponding to the object; calculating a time for requesting recovery of the object based on one or more times information for detecting the omission of the data stored in the queue; and transmitting a request for recovery of the object to a server at the calculated time for requesting recovery of the object.

[0010] According to the embodiments, the time of the recovery request for the object may be determined based on the time information of the detection of missing data of the previous object of the object.

[0011] According to embodiments, the step of calculating the recovery request time of the object may randomly select random delay time information based on the time information of detecting missing data of the previous object of the object, and calculate the recovery request time of the object by adding preset offset time information to the selected random delay time information.

[0012] According to the embodiments, the offset time information represents a minimum waiting time applied before the object recovery request and is applied equally to all objects distributed within the object distribution session, and the random delay time information is applied differently to each object according to the missing data detection time information of the previous object, thereby controlling the timing of the object recovery request.

[0013] According to the embodiments, the missing data detection time information of the previous object is set as the upper limit of the random delay time information, and the random delay time information can be randomly selected from values ​​equal to or smaller than the value of the missing data detection time information of the previous object of the object.

[0014] According to embodiments, the method may further include the step of creating a table instance that includes a parameter indicating whether the object distribution session supports in-session-based object recovery.

[0015] According to the embodiments, the missing data detection time information of the object is the elapsed time from the time when transmission of the object from the server is initiated until the time when the transmission of the object is terminated, and whether part or all of the data of the object is missing can be identified during the period corresponding to the missing data detection time information of the object.

[0016] According to embodiments, the delivery end time of the object may be determined based on at least one of expiration time information included in the table instance or termination flag information received during the object distribution session.

[0017] According to embodiments, a terminal supporting MBS includes a memory; and at least one processor connected to the memory, wherein the at least one processor is configured to detect the omission of part or all data of an object in an in-session basis in which an object distribution session is in progress, store the omission data detection time information of the object in which the omission was detected in a queue corresponding to the object, calculate the time of a recovery request for the object based on one or more omission data detection time information stored in the queue, and transmit the recovery request for the object to a server at the calculated time of a recovery request for the object.

[0018] According to the embodiments, the time of the recovery request for the object may be determined based on the time information of the detection of missing data of the previous object of the object.

[0019] According to embodiments, the at least one processor may randomly select random delay time information based on the time information of detecting missing data of the previous object of the object, and calculate the time of the object's recovery request by adding preset offset time information to the selected random delay time information.

[0020] According to the embodiments, the offset time information represents a minimum waiting time applied before the object recovery request and is applied equally to all objects distributed within the object distribution session, and the random delay time information is applied differently to each object according to the missing data detection time information of the previous object, thereby controlling the timing of the object recovery request.

[0021] According to the embodiments, the missing data detection time information of the previous object is set as the upper limit of the random delay time information, and the random delay time information can be randomly selected from values ​​equal to or smaller than the value of the missing data detection time information of the previous object of the object.

[0022] According to embodiments, the at least one processor may include a parameter indicating whether the object distribution session supports in-session-based object recovery.

[0023] According to the embodiments, the missing data detection time information of the object is the elapsed time from the time when transmission of the object from the server is initiated until the time when the transmission of the object is terminated, and whether part or all of the data of the object is missing can be identified during the period corresponding to the missing data detection time information of the object.

[0024] According to embodiments, the delivery end time of the object may be determined based on at least one of expiration time information included in the table instance or termination flag information received during the object distribution session.

[0025] According to the embodiments, a computer program stored on a computer-readable recording medium can be combined with a computer, which is hardware, to perform the method described above.

[0026] The device and method according to the embodiments can reduce the load on the server by preventing simultaneous occurrence of object recovery requests during a session (i.e., in session).

[0027] The device and method according to the embodiments can reduce network overload and latency and provide more stable quality in live and low-latency based MBS services by randomizing the timing of object recovery requests during a session (i.e., in session) in consideration of existing failure times.

[0028] Drawings are included to further understand the embodiments, and the drawings illustrate the embodiments along with descriptions related to the embodiments.

[0029] FIG. 1 is a diagram showing an example of an MBS multicast / broadcast network architecture according to embodiments.

[0030] FIG. 2 is a conceptual overview of the overall structure of a user frame for a multicast session according to embodiments.

[0031] FIG. 3 is a diagram illustrating the step-by-step operation flow of an MBS session for providing an MBS according to embodiments.

[0032] FIG. 4 is a diagram showing an example of an MBS user service network architecture according to embodiments.

[0033] FIG. 5 is a table showing the operating modes of the object distribution method according to the embodiments.

[0034] FIG. 6 is a diagram showing an example of an MBS user service announcement channel using a pool-based object acquisition method according to embodiments.

[0035] FIG. 7 is a diagram showing an example of an object distribution method using a push-based object acquisition method according to embodiments.

[0036] FIG. 8 is a diagram showing an example of an MBS user service reference architecture according to embodiments.

[0037] FIG. 9 is a diagram showing an example of an MBS user service network architecture according to embodiments.

[0038] FIG. 10 is a diagram showing an example of the process of recovering an object in an MBS environment to which an object distribution method according to embodiments is applied.

[0039] FIG. 11 is a table showing parameters related to object recovery according to embodiments.

[0040] FIG. 12 is a diagram showing the call flow of post-session object recovery according to embodiments.

[0041] FIG. 13 is a diagram showing an example of a call flow for insession object recovery according to embodiments.

[0042] FIG. 14 is a diagram showing an example of the format of an FDT instance header according to embodiments.

[0043] FIG. 15 is a table showing parameters related to object recovery according to embodiments.

[0044]

[0045] FIG. 16 is a diagram showing another example of an MBS user service reference architecture according to embodiments.

[0046] FIGS. 17a and 17b are drawings illustrating different examples of call flows for insession object recovery according to embodiments.

[0047] Preferred embodiments of the embodiments are described in detail, and examples thereof are shown in the accompanying drawings. The following detailed description, with reference to the accompanying drawings, is intended to describe preferred embodiments of the embodiments rather than merely embodiments that may be implemented according to the embodiments. The following detailed description includes details to provide a thorough understanding of the embodiments. However, it is obvious to those skilled in the art that the embodiments may be practiced without these details.

[0048] Most terms used in the embodiments are selected from those commonly used in the field, but some terms are chosen at the applicant's discretion, and their meanings are described in detail in the following description as necessary. Accordingly, the embodiments should be understood based on the intended meaning of the terms, rather than their mere names or meanings.

[0049] The present disclosure provides an apparatus and method for recovering an object when a terminal fails to receive an object provided by a server in a multicast / broadcast environment in an MBS environment. In the present disclosure, "multicast" is used interchangeably with "multicasting" and "broadcast" is used interchangeably with "broadcasting."

[0050] The mobile communication or wireless communication according to the embodiments may include 5G, etc. However, the mobile communication network is not limited to 5G only and may be interpreted as a term including LTE, LTE-Advanced, 5G-Advanced, or any mobile communication network standard to be defined thereafter. Furthermore, the mobile communication or wireless communication described in this document may include wireless LAN (WLAN), Wi-Fi, or broadcast and multicast-based wireless communication environments, and may also include forms in which these networks are interconnected as necessary. In this document, embodiments are described using 5G as an example for convenience of explanation, but this is not intended to limit the technical scope of the present disclosure.

[0051] In the present disclosure, the terminal (user equipment) may also be referred to as a client and means an entity that receives multicast / broadcast-based user services, determines whether an object has been received or has failed to be received, and requests object recovery.

[0052] Such terminals are not limited to mobile phones (smartphones) and can be various types of electronic devices, such as tablets, smart TVs, set-top boxes, automotive terminals, wearable devices, AR / VR / XR (Augmented Reality / Virtual Reality / Extended Reality) devices, laptops, and IoT (Internet of Things) terminals. Additionally, the terminal may be implemented as a single physical device or in the form of one or more software modules or applications running within the device.

[0053] FIG. 1 is a diagram showing an example of an MBS multicast / broadcast network architecture according to embodiments. That is, FIG. 1 shows an MBS user service architecture (or MBS system) composed of related entities that provide delivery and control of MBS user services. In this architecture, an MBS application provider can perform the functions of an AS / AF (Application Server / Application Function).

[0054] According to embodiments, the AS / AF generates content and service information and transmits it to the MBS Service Transport Function (MBSTF). The MBSTF ingests the content, processes it into a form suitable for multicast or broadcast transmission, and transmits it through the MBS user plane. The 5G Core Network and the Radio Access Network (RAN) transmit MBS traffic to terminals via multicast / broadcast. The terminal, the UE (or referred to as the MBS client), receives an object through an MBS session and can perform object repair in the event of reception failure. Furthermore, in the control plane, MBS service configuration, session control, policy, and QoS management are performed through reference points between the AF, the core network, the RAN, and the UE.

[0055] According to the embodiments, the MBS-related entities are within the 5G Core (5GC), and to support MBS, there are four entities: MB-SMF (Multicast-Broadcast Session Management Function), MB-UPF (Multicast-Broadcast User Plane Function), MBSF (Multicast-Broadcast Service Function), and MBSTF (Multicast-Broadcast Service Transport Function). The above four entities can be functions that operate to provide MBS user services.

[0056] The above MB-SMF serves as a multicast / broadcast session management function that manages MBS sessions to support multicast / broadcast services and interacts with the RAN (Radio Access Network) and MB-UPF for data transmission. More specifically, the general characteristics of the MB-SMF regarding multicast and broadcast MBS sessions are as follows: it supports MBS session management (including QoS control), configures the MB-UPF for multicast and broadcast data transmission based on policy rules for multicast and broadcast services in the PCF or local policies, and allocates and deallocates TMGIs. Furthermore, regarding broadcast MBS sessions, it interacts with the RAN via the AMF to control data transmission using the 5GC shared MBS traffic forwarding method. Additionally, regarding multicast MBS sessions, it interacts with the SMF to provide MBS session context information to the SMF. Moreover, for the 5GC shared MBS traffic forwarding method, it interacts with the RAN (via the AMF) to establish data transmission resources between the MB-UPF and RAN nodes, and 5GC individual MBS Control MB-UPF for multicast data transmission using a traffic forwarding method.

[0057] The above MB-UPF functions as a multicast / broadcast user plane, enhancing Quality of Service (QoS) and delivering multicast and broadcast data to UPF or RAN nodes. More specifically, the MB-UPF processes incoming downlink packets for multicast and broadcast flows and enforces legacy means-based QoS (MFBR). It also interacts with the MB-SMF for receiving multicast and broadcast data. It delivers multicast and broadcast data to RAN nodes for the 5GC Shared MBS traffic delivery method. Additionally, regarding multicast MBS sessions, it delivers multicast data to the UPF for the 5GC Individual MBS traffic delivery method.

[0058] The above MBSF is a multicast / broadcast service function that provides service level functions for MBS by including interaction with the AF (Application Function) and the MB-SMF for MBS sessions. More specifically, the above MBSF performs service level functions for MBS support and LTE MBMS interoperability. It interacts with the AF and MB-SMF for MBS session operations, determination of transmission parameters, and session transmission. It performs MB-SMF selection to provide MBS sessions. Additionally, if MBSTF is used, it controls MBSTF. If an IP multicast address is provided by MBSTF, it determines the target IP multicast address for the MBS session.

[0059] The aforementioned MBSTF serves as a multicast / broadcast service transport function, providing general packet transport capabilities and acting as a media anchor for MBS data traffic. More specifically, the MBSTF performs the media anchor function for MBS data traffic when necessary and performs IP multicast sourcing functions when necessary. Additionally, it performs general packet transport functions that can be used by all IP multicast-supported applications, such as framing, multiple flows, and packet FEC (encoding). Furthermore, it multicasts / broadcasts input files as objects or object flows.

[0060] Additionally, in FIG. 1, the Policy and Charging Function (PCF) can perform the following functions to support multicast / broadcast services. That is, the PCF performs the following functions to support MBS when a dynamic PCC for MBS is required. It supports QoS processing for MBS sessions. It provides MBS session-related policy information to the MB-SMF to authenticate the relevant QoS profile. It interacts with the UDR to retrieve QoS information. Additionally, the PCF can receive MBS information from the AF, Network Exposure Function (NEF), or MBSF.

[0061] The Session Management Function (SMF) can perform the following functions to support multicast / broadcast services: it can discover MB-SMFs for multicast MBS sessions; if necessary, authorize multicast MBS session join operations for the UE receiving the service; interact with MB-SMFs to obtain multicast session context information used as input for modifying PDU sessions associated with MBS sessions; interact with the RAN to provide information about the multicast MBS sessions in which the UE is participating; and interact with the RAN and UPFs for multicast data transmission using 5GC individual MBS traffic forwarding methods. The SMF and MB-SMFs can be deployed together or separately.

[0062] The User Plane Function (UPF) can perform the following functions to support multicast / broadcast services. Specifically, it interacts with the SMF to receive multicast data from the MB-UPF for the 5GC individual MBS traffic delivery method. It delivers multicast data to the UE via the PDU Session for the 5GC individual MBS traffic delivery method. The UPF and MB-UPF can be deployed together or separately.

[0063] The AMF can perform the following functions to support multicast / broadcast services: namely, it transmits signals using NG-RAN and MB-SMF for MBS session management; it selects NG-RAN for multicast session activation notifications toward UEs in the CM-IDLE state; and it selects NG-RAN for broadcast traffic distribution. Additionally, the AMF is aware of the NG-RAN 5G MBS function.

[0064] NG-RAN can perform the following functions to support multicast / broadcast services: it manages MBS QoS flows via N2; it delivers MBS data packets to multiple UEs over the radio using PTM or PTP; it configures UEs at the AS layer to receive MBS QoS flows; it controls the switching between PTM and PTP delivery on a per-UE basis; and it receives MBS data packets from 5GCs via shared MBS traffic delivery.

[0065] NEF can perform the following functions to support multicast / broadcast services: namely, it provides an interface to AF for MBS procedures, including service provisioning, MBS sessions, and QoS management. It interacts with AF and NF in 5GC. It determines the MB-SMF and transport parameters for MBS session operations. It selects the MB-SMF to provide MBS sessions.

[0066] UDM supports subscription management for multicast MBS session authentication.

[0067] According to the embodiments, the functions and reference points Nmb10, Nmb2, and Nmb8 related to providing user services within the MBS system are as follows.

[0068] The above reference point Nmb10 is used by AF / AS to call the Nmbsf service to provision MBS user services in MBSF.

[0069] The above reference point Nmb2 is used by MBSF to call the Nmbstf service to configure and control how MBS user services are distributed in MBSTF. If the MBS User Service Announcement Channel is in use, MBSF may additionally push an object manifest describing a set of User Service Announcement objects to MBSTF.

[0070] The above reference point Nmb8 is used by MBSTF to ingest content from AF / AS.

[0071] That is, reference points Nmb10, Nmb2, Nmb8, and Nmb5 can be used to provide MBS user services.

[0072] Meanwhile, an important consideration when defining the MBS architecture is supporting MBS services on legacy (e.g., Release 15 and 16) 5G nodes. Therefore, two transport methods are defined to support MBS. The first is the 5GC shared MBS traffic transport method, where the 5GC receives a single copy of the MBS data packet and forwards it to an NG-RAN node, which then delivers it to one or more UEs. The second is the 5GC individual MBS traffic transport method, which applies only to multicast. In this case, the single copy of the MBS data packet received by the 5GC is delivered as a separate copy and sent to individual UEs via a pe-UE Packet Data Unit (PDU) session.

[0073] The two transmission methods above can be represented as shown in Fig. 2.

[0074] FIG. 2 is a conceptual overview of the overall structure of a user frame for a multicast session according to embodiments.

[0075] In FIG. 2, the 5G Core Network (CN) receives data packets (or MBS packets) that constitute content for an MBS session and processes them into a single logical user plane transmission flow (i.e., packet flow). Subsequently, depending on the transmission method, for example, if it is Shared MBS Traffic Delivery, the packet flow is delivered to a RAN node (NG-RAN) without duplication and transmitted commonly to multiple UEs, and if it is Individual MBS Traffic Delivery, the packet flow is mapped to a PDU session configured for each UE and delivered individually to each UE.

[0076] A RAN node can deliver received data packets to multiple UEs by applying two wireless transmission methods, such as Point-to-Multipoint (PTM) and Point-to-Point (PTP), either simultaneously or individually. The PTM transmission method delivers the same packet to multiple UEs using a single wireless transmission, which is efficient when multiple UEs exist in the same cell. The PTP transmission method is an individual wireless transmission method for a specific UE and is suitable for UEs where channel conditions are poor or PTM reception is difficult. Here, PTP delivers individual copies of the MBS data packet to each individual UE via a wireless interface, whereas PTM delivers a single copy of the MBS data packet to multiple UEs. In other words, a RAN node can use any combination of the PTP and PTM transmission methods to deliver MBS packets to a group of multiple UEs. That is to say, for a 5G MBS session, a shared PTP or PTM delivery method and an individual delivery method can be used individually or simultaneously.

[0077] As such, Multicast-Broadcast Services (MBS) provide a delivery structure in which shared transmission and individual delivery methods can be used in parallel within the core network and wireless access network to efficiently deliver the same content to multiple UEs, or terminals. However, due to the characteristics of the wireless environment, reception failure (i.e., loss) may occur in some terminals, where at least one of the objects constituting the content is not received properly. This refers to a situation where the object cannot be fully restored due to the loss of all or part of the data constituting the object.

[0078] Accordingly, object repair technology that recovers lost objects by retransmitting them is required, and through such object repair, reception reliability and service quality can be improved while maintaining delivery efficiency for large-scale terminals.

[0079] FIG. 3 is a diagram illustrating the step-by-step operation flow of an MBS session for providing MBS according to embodiments. As shown in FIG. 3, the MBS consists of a common phase and an optional phase depending on the multicast method and the broadcast method, and performs a plurality of phases sequentially to provide the service.

[0080] In other words, to provide multicast / broadcast services, the MBS service is divided into several phases as shown in Figure 3.

[0081] In FIG. 3, the MBS session creation step is a step for creating an MBS session, and AF provides information necessary to create an MBS session toward 5GC. For example, the necessary information may include service identification information, session-related information, information on the receiving method, etc. It is mandatory for broadcast and optional for multicast.

[0082] The service announcement stage is the step of distributing information about the service necessary for receiving the service to the UE; it is mandatory for broadcasts and optional for multicasts.

[0083] The Session Establishment phase is performed only in multicast, and a multicast MBS session is established when the first UE joins. In the case of multicast, UEs can join or leave the session through the UE Session Join / Leave phase.

[0084] The "No data receiving" stage is performed optionally only in multicast mode, and data is not received in 5GC. In other words, during this stage, 5GC temporarily does not receive multicast data. This stage indicates a state where data transmission is suspended.

[0085] In the data transmission phase, multicast / broadcast data is transmitted to the UE. According to embodiments, in the case of multicast, data is delivered to multiple UEs participating in the session using a shared transmission method, and in the case of broadcast, data is transmitted collectively to UEs within the corresponding broadcast area.

[0086] The Session Release phase is performed only in multicast, and the multicast MBS session is released as the last UE leaves. In other words, for multicast, a UE can join or leave a session through the UE Session Join / Leave phase.

[0087] The Session Deletion step is performed only in multicast, and multicast MBS sessions are deleted and all information associated with those sessions is removed from 5GC.

[0088] The Session Release & Deletion step is performed only in broadcast, and at 5GC, resources for the broadcast MBS session are released and the broadcast MBS session is deleted.

[0089] FIG. 4 is a diagram showing an example of an MBS user service network architecture according to embodiments. That is, the user service architecture of FIG. 4 shows MBS-related entities involved in the provision and control of MBS user services.

[0090] The MBS user service according to the embodiments enables high-level applications to utilize low-level features of the MBS system.

[0091] In Fig. 4, MBS AF provides unicast service announcements to MBSF clients and MBSTF in the user plane.

[0092] MBS AS provides unicast services, such as object recovery, to MBSTF clients.

[0093] MBSSF supports security procedures for the user plane and provides user plane authentication services to MBSF clients.

[0094] These functions are combined to provide a complete service to the user through an API that allows the MBS client to activate or deactivate the reception of MBS user services.

[0095] More specifically, the Multiast-Broadcast Service Function (MBSF) is a functional block that performs control functions for MBS user services, and performs user service provisioning and user service announcement compilation. According to the embodiments, the MBSF interacts with the MB-SMF (Nmb1), PCF (Nmb12), and NEF (Nmb5) to manage service configuration, policy control, and service announcements.

[0096] The MBS AF (Multicast-Broadcast Application Function) is a function block that actually serves user service announcements and transmits user service announcement information received from the MBSF to the MBSF client (MBS-5).

[0097] The MBSSF (Multicast-Broadcast Security Function) performs user plane client authentication and provides user plane security services to MBSF clients (MBS-10).

[0098] The MBS AS (Multicast-Broadcast Application Server) is an application server associated with MBS user services that provides object recovery functions. Specifically, it provides a service for recovering objects that fail to be received during the multicast / broadcast delivery process, and interacts with MBSTF clients via the MBS-4-UC interface.

[0099] The MBSTF (Multicast-Broadcast Service Transport Function) is a functional block that performs User Services Distribution Methods. It receives (or accepts) content from the MBS Application Provider (AF / AS) (Nmb8) and delivers it to MBSTF clients via the user plane using a multicast basis (MBS-4-MC). Additionally, it performs user plane delivery through integration with MB-UPF (Nmb9).

[0100] The MBS Application Provider (AF / AS) acts as a higher-level service provider, performing the roles of AF and AS and providing the content and service logic required for MBS user services.

[0101] The following is an explanation of the user service distribution method.

[0102] User Service Distribution Methods defined in the MBS User Service may be performed based on a multicast MBS session or a broadcast MBS session. Such distribution methods may be performed by the MBSTF of FIG. 1, FIG. 4, FIG. 8, FIG. 9, or FIG. 16. In this disclosure, the term "distribution" may be used interchangeably with "distribution."

[0103] Specifically, the MBSTF distributes user service content received from the MBS Application Provider (AF / AS) to the user plane via multicast MBS sessions or broadcast MBS sessions. In this case, multicast MBS sessions are used to deliver content via a shared transmission method to a set of UEs participating in the session, while broadcast MBS sessions are used to deliver content collectively to UEs within a specific broadcast area. Furthermore, the MBSF provides user service control and service announcement functions, while the MBSTF is responsible for the actual distribution and delivery of user services, thereby ensuring that the user service distribution method is performed separately on the control plane and the user plane.

[0104] According to the embodiments, the object distribution method is a distribution method for delivering discrete binary objects through MBS sessions. For example, it is used to support real-time distribution of media segments including low-latency CMAF (Common Media Application Format) segments.

[0105] The object distribution method through an MBS session according to the embodiments is a method used to deliver a discrete binary object received from an MBS application provider via reference point Nmb8 to an MBS client via an MBS session.

[0106] FIG. 5 is a table showing the operating modes of the object distribution method according to the embodiments.

[0107] The object distribution method according to the embodiments may be set to one of the operating modes shown in FIG. 5 depending on the nature of the object and service requirements. In the present disclosure, the operating modes may include a single object delivery mode (OBJECT_SINGLE), an object set delivery mode (OBJECT_COLLECTION), an object carousel mode (OBJECT_CAROUSEL), a real-time object streaming mode (OBJECT_STREAMING), etc.

[0108] The above Single Object Delivery Mode (OBJECT_SINGLE) is an operating mode that delivers a single object to an MBS client. In this mode, the object is collected by the MBSTF and distributed once, and can be provisioned with either a pull-based or push-based object acquisition method. When a pull-based object acquisition method is used, a set of one or more object URLs is quoted in the MBS distribution session parameters, and the object acquisition identifier must not be empty. Conversely, when a push-based object acquisition method is used, the object acquisition identifier must be empty. The above Single Object Delivery Mode may be applied, for example, when delivering a single file, single configuration information, or a single media segment.

[0109] The above Object Collection delivery mode is an operating mode that delivers a root object and a set of one or more objects dependent on that root object together. For example, it can be applied when delivering a set of web pages and all asset files required to render them as a single service unit. In the above Object Collection delivery mode, the object set is defined by a manifest, collected by MBSTF, and distributed once. When a push-based object acquisition method is used, the object manifest is collected by MBSTF, and the objects referenced by the manifest are retrieved together. A single object manifest URL may be cited in the MBS distribution session parameter, and the object acquisition identifier must not be empty.

[0110] The object carousel mode (OBJECT_CAROUSEL) described above is an operational mode in which the MBSTF collects a set of one or more objects described by the manifest and distributes them periodically according to a repetition pattern specified in the manifest. In this mode, the same objects are transmitted repeatedly at regular intervals, and users can receive the objects after waiting for an object carousel cycle. All changes to the objects during the MBS distribution session are reflected in the next available distribution cycle. The object carousel mode can be provisioned with pull-based or push-based object acquisition methods. Additionally, object carousel is suitable for delivering structured data groups from a broadcast server to a user using objects such as directories, files, and streams. In other words, the object carousel mode includes object updates as a carousel function for object delivery. It is a method that transmits the same objects periodically at regular intervals, allowing users to receive the objects after waiting for an object carousel cycle. Object-cycle transmission involves periodically transmitting data modules to enable the receiver to receive objects, and object-cycle transmission uses objects such as directories, files, and streams to transmit structured data groups from a broadcast server to a user.

[0111] The above real-time object streaming mode (OBJECT_STREAMING) is an operating mode that collects object sequences via MBSTF and streams them in real-time according to the definition of program service entry points. This real-time object streaming mode can be used, for example, to support regular-latency or low-latency streaming delivery; in the case of low-latency streaming, the distributed objects may be CMAF segments according to 5G Media Streaming DASH interoperability points. Both pull-based and push-based object acquisition methods can be used with this operating mode, and for each object type, the corresponding application service entry point URL is cited in the MBS distribution session parameter. As a result, the referenced application service entry points belong to the MBS user service notification channel, and all application service entry points provide synchronized streaming for the same or compatible presentation.

[0112] As such, the object distribution method in the present disclosure includes multiple operating modes of single object delivery, object set delivery, object carouseling, and real-time object streaming, and each operating mode may be selectively applied depending on service characteristics and latency requirements.

[0113] The following is a description of the object distribution method using pull-based ingest.

[0114] In the object distribution method using pool-based ingest according to the embodiments, the MBS Application Provider (AF / AS) generates a set of objects that the MBSTF can ingest and distribute using HTTP. The MBSTF converts the payload of the HTTP message provided by the AF / AS into a protocol suitable for IP multicast transmission and performs transmission-related processing required for MBS services, such as the addition of AL-FEC (Application Layer Forward Error Correction). Additionally, the AF / AS delegates the delivery of User Service Announcement metadata to be delivered to MBS clients to the MBSF.

[0115] The following parameters are used when the MBS Application Provider (AF / AS) of reference point Nmb10 or the MBSF User Service Announcement Channel of reference point Nmb2 provides configuration information.

[0116] According to the embodiments, the object acquisition method is set to a pull.

[0117] According to embodiments, the operation mode is set to one of a single object delivery mode (OBJECT_SINGLE), an object set delivery mode (OBJECT_COLLECTION), an object carousel mode (OBJECT_CAROUSEL), or a real-time object streaming mode (OBJECT_STREAMING) depending on the service requirements.

[0118] In the single object delivery mode described above, object acquisition identifiers are retrieved from the MBSTF based on the provisioned object ingest base URL and contain a list of paths for object URLs that are distributed once per MBS distribution session. In other words, the object acquisition identifiers contain a list of paths for object URLs that the MBSTF retrieves. Each object is collected and distributed by the MBSTF once during the MBS distribution session.

[0119] In the above object set delivery mode, the object acquisition identifier includes the URL path of an object manifest describing the set of objects to be deployed at once. The objects listed in the object manifest are pooled by MBSTF according to time constraints specified in the object manifest (e.g., earliest fetch time, latest fetch time) and transmitted through the MBS deployment session.

[0120] In the object carousel mode described above, the object acquisition identifier includes the URL path of an object manifest that describes the object set and the pattern of iterative transfer and update of the objects. Object manifests are pooled by the MBSTF based on the provisioned object collection base URL; if provisioned, the MBSTF periodically checks for updates to the corresponding manifest and re-pools it if necessary. Objects listed in the object manifest are repeatedly transferred through the MBS deployment session according to the iteration patterns and time constraints defined in the manifest.

[0121] In the above real-time object streaming mode, the object acquisition identifier includes a URL path identifying one or more application service entry points, which may be, for example, a DASH (Dynamic Adaptive Streaming over HTTP) MPD (Media Presentation Description). That is, the object acquisition identifier may include a URL path such as one or more DASH MPDs. MBSTF pools the corresponding application service entry point documents and collects objects referencing them (e.g., CMAF segments) according to the presentation timeline and includes them in the MBS distribution session. Additionally, sub-objects collected by MBSTF (e.g., DASH initialization segments) may be added to the user service announcement channel of the reference point Nmb2. If both the object acquisition base URL and the distribution base URL are provided, MBSTF replaces the object acquisition base URL portion of the object acquisition URL with the distribution base URL value containing MBS distribution session metadata, which may be implemented, for example, through an instance of the FDT (File Delivery Table) of FLUTE (File Delivery over Unidirectional Transport).

[0122] In this object distribution method using pool-based ingest, MBSTF collects objects from AF / AS via HTTP and distributes them to clients through multicast or broadcast MBS sessions according to the configured operating mode.

[0123] FIG. 6 is a diagram showing an example of an MBS user service announcement channel using a pool-based object acquisition method according to embodiments. That is, FIG. 6 is a diagram illustrating a configuration in which an MBS application provider (AF / AS) provides a set of objects to be ingested and distributed by MBSTF using HTTP.

[0124] In Figure 6, the MBS application provider (AF / AS) and MBSTF are connected through different transport stacks, and the collection and distribution of objects are performed in a separated hierarchical structure.

[0125] According to embodiments, the MBS application provider (AF / AS) provides objects through IP unicast-based lower layers, IP (unicast), TCP, and HTTP protocol stacks.

[0126] According to the embodiments, MBSTF sends an HTTP GET request to AF / AS via reference point MBS-11 to collect the objects in a pool-based manner. That is, AF / AS responds to the HTTP GET request transmitted from MBSTF and provides the requested objects to MBSTF in the form of an HTTP message payload.

[0127] The aforementioned MBSTF acquires the payloads, or objects, of HTTP messages collected from AF / AS using a pool-based method and converts them into a format suitable for MBS distribution. Specifically, the MBSTF converts the HTTP message payloads into a protocol suitable for IP multicast and performs complex transport-related processing required for MBS service provision, such as adding Application Layer Forward Error Correction (AL-FEC). Subsequently, the converted objects are distributed to MBS sessions via the FLUTE (File Delivery over Unidirectional Transport), UDP, and IP (multicast) protocol stacks. In other words, the MBSTF collects objects via the HTTP / TCP / IP (unicast) stack, converts the collected HTTP payloads into a FLUTE-based format, and then distributes the objects to MBS sessions via the UDP and IP (multicast) stacks. In this way, the MBSTF performs a relay function that connects unicast-based object collection with multicast-based object distribution.

[0128] Meanwhile, AF / AS delegates to the MBSF the delivery of MBS service announcement metadata necessary for the MBS client to receive the corresponding service, separate from the delivery of the object itself. This MBS service announcement metadata may include information related to the IP multicast protocol, service identification information, and session-related information, and the MBSF delivers this to the MBS client via the user service announcement channel.

[0129] In Fig. 6, reference point MBS-11 is an interface between MBS AF and MBSTF, which is used for MBSTF to send HTTP GET requests to MBS AF and collect objects. Reference point Nmb9 is an interface between MBSTF and the lower user plane (MBS transport path), representing the path through which FLUTE-based objects are transmitted via the MBS session.

[0130] As shown in Fig. 6, object collection is performed based on IP unicast, while the distribution of objects to actual user terminals is performed through an IP multicast-based MBS session. Accordingly, object collection and object distribution are logically separated, and various object delivery scenarios can be supported while maintaining the efficiency of object distribution.

[0131] The following describes the object distribution method using push-based ingest. In particular, it explains the configuration where an MBS Application Provider (AF / AS) pushes objects to MBSTF via Nmb8 using HTTP PUT. MBSTF handles all MBS-related complexities, such as converting HTTP message payloads into protocols suitable for IP multicast and adding AL-FEC. AF / AS delegates the delivery of service announcement metadata (e.g., DASH, MPD, IP multicast protocol details) to MBS clients to MBSTF via MBSF.

[0132] In other words, in the special case of the MBS User Service Announcement Channel, an object manifest referencing MBS User Service Announcement documents and their ancillary objects is pushed to the MBSTF by the MBSF via the reference point Nmb2. Unlike in general object distribution, where the MBS Application Provider (AF / AS) pushes objects to the MBSTF, in the case of the User Service Announcement Channel, the MBSF initiates object distribution by creating or receiving the object manifest and forwarding it to the MBSTF.

[0133] At this time, the MBS deployment session provides the following settings to initiate provisioning at the MBS application provider (AF / AS) of reference point Nmb10. Depending on the embodiments, the following parameters (i.e., settings) are configured by the MBS application provider (AF / AS) of reference point Nmb10 in the general case, and by the MBSF of reference point Nmb2 in the case of a user service announcement channel, so that the corresponding object deployment configuration is provisioned.

[0134] According to the embodiments, the object acquisition method is set to push.

[0135] According to the embodiment, the operation mode is set to one of the following based on service characteristics: single object delivery mode (OBJECT_SINGLE), object set delivery mode (OBJECT_COLLECTION), object carousel mode (OBJECT_CAROUSEL), or real-time object streaming mode (OBJECT_STREAMING).

[0136] In the single object delivery mode described above, object acquisition identifiers are ignored. Each object pushed to MBSTF is distributed once through an MBS distribution session.

[0137] In the object set delivery mode described above, the object ingest identifier includes a URL path resolved based on the MBSTF object ingest base URL, and an object manifest describing the object set to be deployed once is posted at that URL path. When the MBSTF receives the object manifest, it ingests the objects listed in the manifest according to the time constraints specified in the manifest (e.g., earliest ingest time, latest ingest time) and deploys them once through an MBS deployment session.

[0138] In the object carousel mode described above, the object acquisition identifier includes a URL path where an object manifest is published, which describes the set of objects and the iterative transmission and update patterns of those objects. When the MBSTF receives the object manifest, it collects the objects according to the time constraints specified in the manifest and iteratively transmits them through the MBS distribution session according to the iteration pattern specified in the object manifest. Additionally, if required by the update pattern defined in the object manifest, the MBSTF periodically checks whether the objects have been updated and, if necessary, re-collects the objects to update the MBS distribution session.

[0139] In the above real-time object streaming mode, the object acquisition identifier includes a non-empty set of URL paths where Application Service Entry Point documents (e.g., DASH MPD) are published. These Application Service Entry Point documents are inserted into the User Service Announcement. When the MBSTF receives one of the declared Application Service Entry Point documents, a streaming session is initiated according to the presentation timeline specified in that document. If an object (e.g., a CMAF segment) that is part of the presentation defined by the Application Service Entry Point document is pushed to the MBSTF, that object is distributed once through the MBS distribution session according to the presentation timeline.

[0140] According to the embodiments, the object ingest base URL is assigned by the MBSF and includes the base URL where the object is published to the MBSTF. That is, the object ingest base URL includes the base URL of the MBSTF where the object is published.

[0141] According to the embodiments, the object distribution base URL is assigned by the MBSF and includes a base URL used when an object is distributed through an MBS distribution session.

[0142] According to embodiments, the MBSTF replaces the part of the object collection URL corresponding to the object collection base URL with the object distribution base URL value, includes this in the MBS distribution session metadata (e.g., a FLUTE FDT (File Delivery Table) instance), and, if applicable, uses it to reference the object in user service announcements.

[0143] In this way, in the special case of the user service announcement channel in the object distribution method using push-based ingest, the object manifest is pushed to the MBSTF by the MBSF, the MBSTF collects and distributes the object according to the configured operating mode, and reflects the object distribution URL in the MBS distribution session metadata and user service announcement.

[0144] FIG. 7 is a diagram showing an example of an object distribution method using a push-based object acquisition method according to embodiments. Specifically, FIG. 7 illustrates an MBS object distribution structure applying a push-based object acquisition method in which an MBS application provider (AF / AS) directly pushes an object to MBSTF using HTTP PUT. In FIG. 7, AF / AS pushes an object to MBSTF using HTTP PUT, and MBSTF converts it into a form suitable for a multicast-based MBS session and distributes it.

[0145] According to embodiments, the MBS application provider (AF / AS) delivers objects to the MBSTF via the reference point Nmb8 through IP unicast-based lower layers, IP (unicast), TCP, and HTTP protocol stacks. At this time, the AF / AS actively publishes the objects to the MBSTF using the HTTP PUT method, and the objects may be a single object, part of a set of objects, a carousel object, or a real-time streaming object (e.g., a CMAF segment).

[0146] According to the embodiments, MBSTF processes the payload of an HTTP message received from AF / AS—that is, an object—and converts it into a form suitable for MBS distribution. Specifically, MBSTF converts the HTTP message payload into a FLUTE-based format and includes the object in an MBS distribution session via the UDP and IP (multicast) protocol stacks. In this process, MBSTF handles the MBS-related transmission complexity required for multicast transmission, such as adding Application Layer Forward Error Correction (AL-FEC).

[0147] And, as shown in Fig. 7, the object converted from MBSTF is transmitted to the MBS user plane (MBS transmission path) through the reference point Nmb9 and distributed to multiple MBS clients through a multicast-based MBS session.

[0148] According to this push-based object distribution structure, object collection is performed via IP unicast, while object distribution is carried out through IP multicast-based MBS sessions. Consequently, AF / AS can immediately push objects to MBSTF when needed, and MBSTF handles complex processing regarding distribution methods and transmission optimization, enabling efficient object distribution to a large number of terminals.

[0149] Meanwhile, as a distribution method for streaming packetized media data through MBS sessions, Service Data Units (SDUs) are delivered to the UE as Protocol Data Units (PDUs) or as part of an IP flow. In this case, an example of a higher-layer SDU is an IP / UDP datagram.

[0150] FIG. 8 is a diagram showing an example of an MBS user service reference architecture according to embodiments. In particular, FIG. 8 is a diagram illustrating a reference architecture for providing MBS user services, showing a plurality of functional blocks and reference points arranged between a terminal (UE), a delivery network (DN), and an MBS application provider (AF / AS).

[0151] In FIG. 8, the UE is a terminal that receives MBS user services and includes an MBS-aware Application and an MBS client.

[0152] The above MBS client may include an MBSF client and an MBSTF client, and performs reception, control, data processing, and object-based content reception of MBS user services.

[0153] The MBS-aware Application within the above UE controls the activation / deactivation of MBS user services and the reception of user data by utilizing APIs exposed by MBSF clients and MBSTF clients through reference points MBS-6 and MBS-7.

[0154] The MBSF (Multicast / Broadcast Service Function) can perform the following functions to support MBS: namely, 'providing service functions for MBS service provision and interoperability with LTE MBMS', 'configuring the MBS AF through the reference point MBS-3 and publishing user service announcements', 'interacting with the AF and MB-SMF for MBS session operations, determining transport parameters, and session transmission', 'selecting the MB-SMF to provide the MBS session', 'controlling the MBSTF if it is used', and / or 'determining the destination IP multicast address for the MBS session if an IP multicast address is provided by the MBSTF'.

[0155] The MBSTF (Multicast / Broadcast Service Transport Function) is a functional block responsible for the transport layer of MBS user services and can perform the following functions to support MBS: namely, acting as a media anchor for MBS data traffic when necessary, providing IP multicast sources when necessary, general packet transport functions provided to IP multicast-supported applications such as framing, multiple flow processing, and packet FEC (encoding), and / or converting input files into object or object flow forms and delivering them via multicast / broadcast. According to embodiments, the MBSTF distributes content to MBS clients via unidirectional multicast through the reference point MBS-4-MC.

[0156] The MBS AF (MBS Application Function) performs application control functions related to MBS user services and can perform the following functions to support MBS: namely, providing service information including QoS requirements to 5GC for multicast or broadcast service requests, directing MBS session operations to 5GC if necessary, and / or interacting with NEF to expose MBS-related services. Additionally, it enables MBSTF to retrieve object manifests and user service announcements listed in object manifests from the MBS AF via the reference point MBS-11.

[0157] The MBS AS (MBS Application Server) is an application server for MBS user services that provides file-based object repair services to MBSTF clients in conjunction with object distribution methods. To support MBS user services, it can perform the following functions: specifically, it can provide byte-range file repair services to MBSTF clients for use with object distribution methods (via the reference point MBS-4-UC). In other words, it can provide byte-range file repair services by performing user plane interactions with MBSTF clients through the reference point MBS-4-UC. Additionally, the MBS AS is configured by the MBSF using the reference point MBS-9 and can retrieve content from MBSTF.

[0158] The MBSSF (MBS Security Function) is a function block that provides security functions for MBS user services. To support MBS security functions, the MBSSF provides security anchors to MBSTF clients via the reference point MBS-10 and authenticates access to secure MBS data according to predefined user plane security procedures.

[0159] The MBS Application Provider (AF / AS) is a high-level service provider that performs the roles of MBS AF and MBS AS. The MBS Application Provider (AF / AS) provides object-based content, service logic, and user service-related information, and can provide user announcements to MBS-aware applications through the reference point MBS-8.

[0160] The following is a description of the reference points in Fig. 8. The reference points illustrated in Fig. 8 define the control plane and user plane interactions of the MBS user service, and are performed in combination with multicast / broadcast-based service delivery and object-based distribution and recovery functions.

[0161] MBS-3 is used by MBSF to configure MBS AF and post user service announcements.

[0162] MBS-4-MC distributes content from MBSTF to MBS clients via unidirectional multicast.

[0163] MBS-4-UC is a reference point that supports user-plane interactions for performing object or file-based recovery between an MBSTF client and an MBS AS. For example, it is a reference point used for user-plane interactions between an MBSTF client and an MBS AS for file-based unicast recovery.

[0164] MBS-5 is a reference point for user plane interaction between the MBSF client and the MBS AF, and is intended for MBS control plane and service processing.

[0165] MBS-6 is an API exposed by MBSF clients that is used by MBS-aware applications to manage and control MBS user services.

[0166] MBS-7 is an API exposed by the MBSTF client, used by MBS-aware applications to receive user data information distributed through the MBS user service.

[0167] MBS-8 is a reference point used by MBS application providers to provide announcement information regarding MBS user services to MBS-aware applications.

[0168] MBS-9 is used to configure MBS AS by MBSF.

[0169] MBS-10 is a user-plane interaction between an MBSF client and an MBSSF, used to authenticate access to securely protected MBS data through user-plane security procedures.

[0170] MBS-11 is used by MBSTF to retrieve object manifests and user service announcements listed in the object manifests from the MBS AF.

[0171] MBS 6′ is an API exposed by the MBSTF client, used by the MBSF client to (dis)enable the reception of MBS sessions. Reception parameters are provided by the MBSF client.

[0172] MBS 7′ is an API exposed by the MSTF client and is used to supply MBS session configuration information received by MBSTF from the MBS 4 MC reference point.

[0173] FIG. 9 is a diagram showing an example of an MBS user service network architecture according to embodiments. That is, the user service architecture of FIG. 9 shows MBS-related entities involved in the provision and control of MBS user services.

[0174] FIG. 9 is an MBS user service network architecture in which a reference point MBS-NEW is added between MBS AS and MBSTF for object recovery (e.g., insession unicast recovery) during session progress to the MBS user service network architecture of FIG. 4. Therefore, the description of the remaining blocks and reference points, excluding the reference point MBS-NEW, refers to FIG. 4, and is omitted here to avoid redundant description.

[0175] That is, in the architecture illustrated in Fig. 4, object distribution is primarily performed via multicast or broadcast through MBSTF, and object repair is performed through user plane interaction between the MBSTF client and the MBS AS via the reference point MBS-4-UC. This structure is mainly applied to object repair after a session (i.e., after the session ends) or at a limited point in time.

[0176] On the other hand, in Fig. 9, a reference point MBS-NEW is added between MBS AS and MBSTF to perform object recovery during session (i.e., in session).

[0177] The above reference point MBS-NEW is defined as an interface between an entity performing functions similar to MBS AS (MBS AS-like entity) and an MBSTF. In other words, the reference point MBS-NEW is used for the MBSTF between the MBS AS-like entity and the MBSTF to ingest (collect or receive) content from AF / AS.

[0178] In other words, MBS-NEW enables MBSTF to directly ingest content or object data necessary for object recovery from AF / AS or AS-like entities, even while a session is in progress. In particular, it supports more flexible and parallel processing of object recovery requests when object loss occurs across multiple terminals. Furthermore, by complementing the existing MBS-4-UC-based recovery structure, it enables real-time or near-real-time object recovery that is not limited to post-session recovery.

[0179] As such, the MBS user service architecture of Fig. 9 can more effectively support in-session object repair by extending the object recovery path compared to the existing MBS user service architecture of Fig. 4.

[0180] The following is an explanation of object recovery.

[0181] In an MBS environment, when an object distribution method is used to divide and deliver content into objects in the form of files or segments, the MBS application provider may provide one or more objects constituting the content or information for obtaining said objects. Additionally, the MBS application provider may provide a URL, object manifest, or application service entry point document for collecting said objects.

[0182] The object recovery function according to the embodiments enables the MBS client to retrieve and receive the missing part of the object from the MBS AS via the reference point MBS-4-UC in the event that an object or a part of the object is not completely received during the process of the MBS client receiving the object via the reference point MBS-4-MC. That is, if data (e.g., object) is lost or damaged while the MBS client is receiving object data via the MBS-4-MC, the object can be fully restored by selectively re-receiving the missing data via the MBS-4-UC using the object recovery function. In other words, if some data is lost or damaged during the process of the MBS client receiving data via the MBS-4-MC, this object recovery function is used to retrieve the missing data from the MBS AS via the MBS-4-UC.

[0183] The object recovery procedure according to the embodiments can be divided into post-session object recovery and in-session object recovery.

[0184] The above post-session object recovery refers to a method in which a terminal (e.g., MBS client) performs recovery for an object or part of an object that was not received from the MBS AS after a multicast-broadcast-based MBS distribution session has ended (or been completed). In this case, the object recovery request is performed after the session ends, and the object to be recovered is identified after the session ends. According to the embodiments, post-session object recovery includes a random backoff period for the MBS client to prevent overloading the MBS AS. That is, to prevent all clients from sending object recovery requests simultaneously when the MBS client recovers missing data from the MBS AS after the MBS distribution session ends, each client is made to wait for a randomly determined period of time before sending the request. This prevents server overload and enables efficient data recovery.

[0185] The above-mentioned in-session object recovery refers to a method in which, while a multicast-broadcast-based MBS distribution session is in progress, a terminal (e.g., an MBS client) identifies a failure to receive an object or a part of an object and performs recovery of the object before the session ends. The above-mentioned in-session object recovery can be performed in parallel for one or more objects and is not limited to a specific delivery method, but can be applied to any delivery environment where object recovery during a session is possible.

[0186] FIG. 10 is a diagram showing an example of a process for recovering an object in an MBS environment where an object distribution method according to embodiments is applied. That is, FIG. 10 is a diagram schematically illustrating an object recovery operation in which, in an MBS environment where an object distribution method is applied, an MBSTF client within a UE interacts with a server (e.g., MBS AS) through a reference point MBS-4-UC to recover missing parts of an object that was not received through MBS-4-MC.

[0187] Referring to FIG. 10, in an MBS environment where an Object Distribution Method is applied, an object recovery operation according to the embodiments can be performed as follows.

[0188] First, the MBSTF client included in the terminal (UE) receives object data from MBSTF via the reference point MBS-4-MC during the MBS distribution session. At this time, there may be cases where all or part of the object is not received normally due to characteristics of the wireless environment, transmission errors, or other factors.

[0189] When such reception failure is detected, the MBSTF client initiates an object recovery procedure. Specifically, the MBSTF client performs user plane interaction with the MBS AS using the reference point MBS-4-UC and requests recovery of missing parts or lost data of the unreceived object via MBS-4-MC.

[0190] In response to the request, the MBS AS provides the requested object or a part of the object to the MBSTF client, and the MBSTF client restores the object to its complete form by combining the received recovery data with the previously received object data.

[0191] In other words, in the case of the object distribution method, the MBSTF client can cooperate with the MBS AS to recover the lost content portion corresponding to the MBS data that the MBSTF client failed to successfully receive from the reference point MBS-4-MC at the reference point MBS-4-UC.

[0192] As illustrated in FIG. 10, this object recovery operation can be performed in the form of MBS Distribution Session Repair, which is carried out in conjunction with the MBS distribution session, thereby efficiently compensating for data loss that occurred during the object distribution process.

[0193] The following is an explanation of post session object recovery.

[0194] According to the embodiments, the post-session object recovery procedure may be performed in the same or corresponding manner as the file repair procedure defined in FLUTE. In the present embodiment, it is assumed that the MBS client possesses MBS distribution session metadata (e.g., instances of FLUTE File Delivery Table (FDT)), and object recovery is performed based on said FDT instances.

[0195] According to the embodiments, FDT@Expires in an FDT instance represents the expiration date of the FDT instance.

[0196] According to the embodiments, for one or more objects transmitted in a FLUTE session, the FDT instance document includes file elements to identify and describe each object. Each file element contains metadata necessary for the transmission and recovery of the object, thereby enabling the receiving side to identify the object, check its size, and verify its integrity. That is, each file element may include the following attributes.

[0197] The File@TOI (Transport object Identifier) ​​attribute is an object identifier used in ALC transport, serving as a value to distinguish each transport object from one another within a FLUTE session.

[0198] The File@Content-Location property is a URI representing the network location of the object corresponding to the transmission object. In other words, it represents the URI of the transmission object.

[0199] The File@Content-Length property indicates the total size of the transmission object in bytes. In other words, it represents the size of the transmission object in bytes.

[0200] The File@File-ETag attribute is an Entity Tag value used to identify the version or integrity of the corresponding transmission object. In other words, it represents the Entity Tag value of the transmission object.

[0201] The following describes the object recovery process using MBS distribution session metadata (e.g., FLUTE FDT instances).

[0202] FIG. 11 is a table showing parameters related to object recovery according to embodiments.

[0203] In FIG. 11, BackOffParameters is a set of parameters for controlling the back-off behavior at the time of the recovery request in the object recovery mechanism of the MBSTF client. That is, it is a parameter for the back-off behavior in the object recovery mechanism of the MBSTF client. If omitted, a back-off delay is not required. The data type of BackOffParameters is BackOffParameters, and it may be provided optionally.

[0204] The data type of offsetTime is DurationSec, and it represents the minimum time that an MBSTF client must wait after completing the download delivery of an MBS distribution session before performing an object recovery request. In other words, it is the minimum time that an MBSTF client must wait after completing the download delivery session before making an object recovery request. If this value is not provided, offsetTime is assumed to be 0.

[0205] The data type of randomTimePeriod is DurationSec, and it represents the maximum range of random delay time used to prevent server load concentration during object recovery requests. In other words, it is the maximum window length for calculating the RandomTime value that the MBSTF client uses as the delay for object recovery requests. The MBSTF client calculates a random time within this range, and the resulting random time (RandomTime value) is added to offsetTime. If no such value is provided, randomTimePeriod is considered to be 0.

[0206] URL attributes related to object recovery and distribution can include objectDistributionBaseLocator and objectRepairBaseLocators.

[0207] The objectDistributionBaseLocator (URI) represents the object distribution base URL used in the MBS distribution session. This URL is specified by the MBS application provider, and MBSTF can configure object distribution metadata by replacing the object ingest base URL used during the object ingest process with this objectDistributionBaseLocator. In other words, it is the URL used to replace the object ingest base URL during the distribution process of objects collected by MBSTF. If omitted, the objectDistributionBaseLocator (i.e., the object distribution URL) is considered to be the same as the object ingest URL.

[0208] objectRepairBaseLocators (array of Absolute URI) represents a list of object repair base URLs for performing object repair in an MBS distribution session. In other words, it is the object repair base URL of the MBS distribution session. These URLs are specified by the MBSF and are used by MBSTF clients when performing object repair. objectRepairBaseLocators is used in place of the object distribution base URL when repairing incompletely received objects in an MBS distribution session. This value must point to an MBS AS and exists only if the object repair function is provided in that MBS distribution session. In other words, it is not directly related to MBSTF.

[0209] Post session object recovery according to the embodiments can be performed according to the following steps.

[0210] 1) Determine end of session based on FDT @Expires or A-flag

[0211] The MBS client determines the termination time of an MBS distribution session using the FDT@Expires value contained in the FDT instance. However, the MBS client can decide to terminate the file transfer early. Additionally, if the termination session (A-Flag) in the ALC / FLUTE header is received in an ongoing object distribution session before the FDT instance expires, the file transfer is terminated early. That is, even before the FDT instance expires, if the A-flag (session termination flag) in the ALC / FLUTE header is received in an ongoing object distribution session, the file transfer may be considered terminated early.

[0212] 2) Identify missing data

[0213] The MBS client identifies whether data is missing for one or more FLUTE transmission objects delivered in the object distribution session. Specifically, the client can identify source symbols that were transmitted but not received. Additionally, by determining the number of received symbols for each source block of each file, the client can calculate the number of symbols required to decode the block. Thus, the MBMS client can obtain information (the number of source and repair symbols and the ESI value) regarding files requiring reconstruction corresponding to source symbols lost during transmission. When MBMS Forward Error Correction (FEC) is used, the MBMS client considers already received symbols when specifying additional symbols to identify the number of symbols r that allow the MBMS FEC decoder to recover the file. In other words, when MBMS Forward Error Correction (FEC) is applied, the MBS client identifies the number of additional symbols r required for file recovery by considering already received symbols.

[0214] 3) Select Object Recovery Server

[0215] The MBS client randomly selects an MBS AS instance Repair URL from the objectRepairBaseLocator list defined in the ObjectRepair object. In other words, it selects an object repair URL corresponding to a single MBS AS instance.

[0216] 4) Determine the URL for object recovery

[0217] For each file element defined in the FDT instance document, the network location URL for object recovery for an incompletely transmitted FLUTE object is determined by combining the following information. That is, for each incompletely transmitted FLUITE object identified by the file element defined in the FDT instance document, the network location URL for object recovery (or referred to as the network location URL for object recovery) can be determined using the attribute values ​​below.

[0218] For example, the MBS client can determine the network location URL for object recovery by combining the repair URL selected in the File@Content-Location property value, 3) (which may not exist) and the objectDistributionBaseLocator value defined in the ObjectRepair object (which may not exist).

[0219] According to embodiments, the MBS client uses the received symbol list and information from the FDT to define an appropriate byte range list Range[M] for a number M of independent ranges in object recovery, where Range[m].start indicates the starting position of the m-th range and Range[m].end indicates the ending position of the m-th range. That is, the MBS client determines the byte range and the time of the recovery request.

[0220] 5) The MBS client determines the actual execution time of the object recovery request using the offsetTime and randomTimePeriod parameters defined in the ObjectRepair object. At this time, for each incompletely transmitted FLUTE object in the FDT instance document, the MBSTF client uses the URL, which is the network location formed in 4), the byte size of the transmitted object, the entity tag value, and the minimum byte range list Range[M] determined in 4) from the corresponding FDT file entry.

[0221] 6) The MBS client recovers missing objects or parts of objects using the determined byte range list and the byte range data received from the MBS object distribution session.

[0222] According to the aforementioned post-session object recovery procedure, object recovery is possible in a FLUTE-based object distribution environment, server load can be mitigated using offsetTime and randomTimePeriod, and network resources can be utilized efficiently through selective recovery in byte range units.

[0223] FIG. 12 is a diagram illustrating the call flow of post-session object recovery according to embodiments. That is, FIG. 12 is a flowchart illustrating the process in which an MBS client receives an object from MBSTF, identifies missing data based on an FDT instance, and performs object recovery in byte range units through interaction with MBS AS.

[0224] First, the MBS client performs Object Delivery Setup to receive an Object Distribution Session. During this process, the MBS client obtains an instance of the File Delivery Table (FDT) used for FLUTE-based object delivery from the MBSTF. The FDT instance contains identification information and metadata for one or more objects to be transmitted via the FLUTE session.

[0225] Subsequently, the MBS client requests one or more objects from the MBSTF via an object distribution session, and the MBSTF delivers one or more objects to the MBS client via the corresponding object distribution session. At this time, object delivery can be performed via the reference point MBS-4-MC, and the MBS client stores or processes the received object data.

[0226] The MBS client determines whether the object distribution session has terminated based on the FDT@Expires value contained in the FDT instance or the A-flag (session termination flag) contained in the FLUTE / ALC header. At this stage, it is determined whether the file transfer terminated normally or if the session was terminated prematurely.

[0227] When it is determined that the session has ended, the MBS client compares the received object data with the object metadata defined in the FDT instance to identify data that was transmitted but not received, i.e., missing object data.

[0228] If missing object data is identified, the MBS client initiates a Repair URL selection procedure to determine the network location of a recovery server for performing object recovery. First, the MBS client sends a request to the MBS AS to identify available object recovery servers. This step is represented as the “Repair URL” step, as illustrated in the figure, and corresponds to the step in which the MBS client notifies the MBS AS that it intends to initiate object recovery. In response, the MBS AS selects an appropriate recovery URL from among the information of one or more recovery servers capable of object recovery and transmits the selected recovery URL to the MBS client. This step corresponds to the “URL Selected” step illustrated in the figure, where the network location to process the recovery request is selected by the MBS AS and provided to the MBS client.

[0229] The MBS client constructs the network location URL to be used for object recovery requests using the selected recovery URL, the File@Content-Location included in the FDT instance, and, if necessary, the objectDistributionBaseLocator information.

[0230] Subsequently, the MBS client sends a recovery request to the MBS AS for a byte range corresponding to the missing object data, using the configured network location URL. In response to the byte range request received from the MBS client, the MBS AS sends the object data corresponding to the requested byte range to the MBS client.

[0231] The MBS client converts byte range data received from the MBS AS into transmission symbols according to the FLUTE / ALC transmission structure.

[0232] Then, the MBS client completes object repair by combining the previously received object data with the recovered symbol data to restore the missing object or part of the object.

[0233] FIG. 13 is a diagram illustrating an example of a call flow for in-session object recovery according to embodiments. In particular, FIG. 13 is a flowchart illustrating an in-session object recovery process in which an MBS client performs object recovery in parallel with the distribution of a second object before the distribution session for a first object is terminated. Taking FIG. 13 as an example, parallel operation of the first object and the second object must be possible. Then, the first object that was received incompletely after the object delivery setup is detected.

[0234] To this end, the MBS client first performs Object Delivery Setup for object distribution in response to the application's request. During this process, the MBS client obtains an instance of the File Delivery Table (FDT) used for FLUTE-based object distribution from the MBSTF.

[0235] Subsequently, the MBS client requests the first object from the MBSTF through the object distribution session for the first object (Object 1). In response to the request, the MBSTF delivers the first object to the MBS client through the object distribution session. At this time, the delivery of the first object can be performed through the reference point MBS-4-MC.

[0236] At this time, the MBS client determines whether the delivery of the first object has ended and checks whether there is any data transmitted but not received for the first object. In this process, missing data for the first object may be identified.

[0237] If missing data for the first object is identified, the MBS client initiates the Object 1 Repair Process while the object distribution session of the first object is not terminated, that is, while in session.

[0238] While the recovery process for the first object is in progress, the MBS client requests the second object from the MBSTF through the Object 2 Distribution Session for the second object, and the MBSTF delivers the second object corresponding to the request to the MBS client through the Object Distribution Session. At this time, the delivery of the first object can be performed through the reference point MBS-4-MC.

[0239] Simultaneously, the MBS client sends a request to the MBS AS to select a repair URL to perform object repair. In response, the MBS AS selects an appropriate repair URL and sends it to the MBS client. The MBS client uses the repair URL received from the MBS AS to form a network location URL to be used for the object repair request. That is, the MBS client uses the selected repair URL, the File@Content-Location contained in the FDT instance, and, if necessary, the objectDistributionBaseLocator information to form a network location URL to be used for the object repair request of the first object.

[0240] In addition, the MBS client determines whether the delivery of the second object has ended and identifies whether there is missing data for the second object as well.

[0241] At the same time, the MBS client uses the configured network location URL to send a recovery request to the MBS AS for a byte range corresponding to the missing first object data. In response to the byte range request received from the MBS client, the MBS AS sends the first object data corresponding to the requested byte range to the MBS client.

[0242] The MBS client converts byte range data received from the MBS AS into transmission symbols according to the FLUTE / ALC transmission structure.

[0243] Then, the MBS client completes object repair by combining the previously received object data with the recovered symbol data to restore the missing first object or a part of the first object.

[0244] When the recovery of the first object is completed, the MBS client terminates the insession object recovery process for the first object by releasing the recovered first object (release object 1) or providing it to the parent application.

[0245] If it is identified in the above step that there is missing data for the second object as well, the missing second object or a part of the second object is restored through the same object recovery process as the first object recovery process described above.

[0246] In this disclosure, in-session object recovery refers to a method in which a terminal identifies a failure to receive an object or a part of an object while an object distribution session is in progress as described above, and performs recovery of the object before the session ends; one such in-session object recovery may be unicast object recovery. That is, in this disclosure, the term unicast object recovery is used to describe one of the exemplary implementation forms of in-session object recovery, and the scope of application of object recovery is not limited by the transmission method.

[0247] The following is a description of the Unicast Object Recovery Protocol (MBS-4-UC).

[0248] Specifically, this describes a unicast object recovery protocol between an MBSTF client and an MBS AS when the delivery of one of several objects fails completely in an MBS download delivery session using an object distribution method. The unicast object recovery protocol is based on HTTP. In this disclosure, unicast object recovery refers to an example of in-session object recovery, meaning a case where missing object data is recovered via individual transmission while an object distribution session is in progress, but the concept of object recovery in this disclosure is not limited thereto.

[0249] The following defines the MBSTF client procedure for the unicast object recovery protocol. It is assumed that at a specific point in time, the MBSTF client initiates the object recovery procedure based on parameters. When recovery begins, the MBSTF client calculates a random back-off time using the offsetTime and randomTimePeriod parameters. The MBSTF client initiates a recovery request based on the calculated random back-off time. The MBSTF client must not send a recovery request message before this calculated back-off time has elapsed.

[0250] According to the embodiments, the parameters available in the MBSTF client for unicast object recovery are as follows.

[0251] . offsetTime parameter and randomTimePeriod parameter

[0252] . For each object with corrupted data, the entity tag value for the corrupted object in the MBS distribution session metadata if available to the MBSTF client

[0253] . Length of the damaged object in bytes

[0254] . Network location referencing the corresponding object hosted in MBS AS

[0255] . A list of minimum byte ranges including the start and end of object recovery

[0256] It is a list of minimum byte ranges containing the start and end of the above object recovery, having the dimension of Range[M], where M represents the number of independent ranges. Each range is denoted by Range[m].start as the starting point and Range[m].end as the ending point.

[0257] In the present disclosure, the offsetTime parameter and the randomTimePeriod parameter are used to calculate the back-off time.

[0258] The following is an explanation of back-off time calculation.

[0259] The MBS client must be implemented by calculating the backoff timing. The backoff time is the sum of OffsetTime and RandomTime.

[0260] OffsetTime refers to the time that must be waited before sending a recovery request. That is, it is the time that an MBMS client must wait to start object recovery after the transmission of MBSMS data is completed. The present disclosure designates the waiting time as a back-off time using the attribute value of “offset-time”.

[0261] Random Time Period refers to the length of the time window in which the MBMS client calculates a random time to initiate the file recovery process. This random time value provides a statistically uniform distribution over a specific period, and the waiting time is specified using the attribute value "random time period". The MBMS client calculates a Random Time that is uniformly distributed in the interval between 0 and Random Time Period.

[0262] The following is a description of the MBSTF client unicast recovery request.

[0263] According to embodiments, an MBSTF client sends one or more requests to an MBS AS instance to request data transfer capable of recovering missing object data. All unicast object recovery requests and responses for a specific MBS distribution session must take place within a single HTTP session.

[0264] According to the embodiments, the MBSTF client must initiate the initial request after the backoff time has elapsed. If there are multiple object recoverys, they are transmitted sequentially without additional delay. The MBSTF client must send a separate HTTP GET request for each damaged object.

[0265] According to the embodiments, the MBSTF client operates based on the parameter of b for each compromised object. In this case, when the requested range is the entire object, i.e., M=1, Range[0].start = 0, and Range[0].end = F (where F is the value of the content length), the HTTP GET method is used.

[0266] If M > 1, the MBSTF client includes multiple byte range requests within a single partial GET request. Specifically, the MBSTF client includes as many byte ranges as possible in a single HTTP request message to ensure that the total length of all request headers does not exceed 2048 bytes. If this length is exceeded, the request is split into as few requests as possible to avoid exceeding the 2048-byte limit. If an entity tag for a corrupted object is provided to the MBSTF client, the conditional byte range file request is used as the entity tag value in the If-Match or If-Range header. The If-Range HTTP request header is conditionally created as a range request. If the condition is met, the range request is processed, and the server sends a 206 Partial Content response with the appropriate body. If this condition is not met, a 200 OK status code is returned with the full resource. The entity tag value for the corrupted object in the MBSTF client is replaced and used as the entity tag in this If-Match or If-Range header.

[0267] The following is an explanation of file delivery.

[0268] FLUTE is a standard protocol defined by the IETF (Internet Engineering Task Force) as a transport protocol designed to reliably deliver files unidirectionally from a single sender to multiple receivers (e.g., terminals). Designed for IP multicast environments, FLUTE can be used to efficiently transmit the same content to a large number of recipients.

[0269] FLUTE uses UDP / IP as its lower transport layer and operates by combining the Asynchronous Layered Coding (ALC) protocol and the File Delivery Table (FDT) to support file-unit delivery.

[0270] The following is a description of the File Delivery Session.

[0271] ALC is a protocol instance of LCT (Layered Coding Transport) and is based on the session concept of LCT. An ALC / LCT session consists of a single sender transmitting ALC / LCT packets to one or more objects and a logically grouped set of ALC / LCT channels.

[0272] FLUTE performs file-unit transmission by utilizing the LCT Extension Header and FDT instances defined in the ALC protocol. In other words, because the ALC protocol alone is insufficient to adequately represent the file characteristic information necessary for the reliable delivery of large files, FLUTE additionally defines a mechanism to signal file attributes, structure, and identification information.

[0273] The following identifiers are used to identify files and data units in FLUTE transfer.

[0274] In other words, TOI (Transport Object Identifier) ​​is an identifier for identifying a single transport object (file or object), SBN (Source Block Number) is an identifier for identifying each source block constituting the transport object, and ESI (Encoding Symbol Identifier) ​​is an identifier for identifying each encoding symbol generated within the source block. That is, TOI is a value for distinguishing each object, SBN is a value for distinguishing each source block, and ESI is a value for distinguishing each encoding symbol.

[0275] The following is an explanation of file transfer using FLUTE.

[0276] A single file that is the target of transmission, that is, a single file to be transmitted, is defined as a Transport Object.

[0277] The transmission object is divided into multiple source blocks.

[0278] Each source block is divided into multiple source symbols.

[0279] When Forward Error Correction (FEC) is applied, an encoding symbol is generated from the source symbol, which includes the source symbol and the parity symbol. In other words, the encoding symbol is created by combining the source symbol and the parity symbol.

[0280] To successfully restore the FLUTE packet, the following information is included in the ALC header and FDT instance and provided to the receiver. Specifically, the type of FEC used to objectify the Flute packet, the length and number of each source block, and the length and number of each encoded symbol are included in the ALC header and FDT instance and provided to the receiver.

[0281] FLUTE transmits an FDT instance when the TOI value is 0. The FDT contains information about the files being transferred through a specific session. In other words, in FLUTE, a transfer object with a TOI value of 0 is reserved as an FDT instance, and that FDT instance provides metadata about the files included in the file transfer session.

[0282] From the receiver's perspective, to determine which files are being transmitted to a specific session, it first receives the FDT (TOI=0) and checks the TOI value for each object to identify which files are being transmitted. In other words, by first receiving the FDT instance (TOI=0), the receiver recognizes which files are being transmitted within that session and identifies the TOI value corresponding to each file.

[0283] The following is an explanation of FDT.

[0284] The FDT is a table that provides metadata about files (objects) transmitted in a single file delivery session. The FDT contains various attribute information for the file delivery session.

[0285] In one embodiment, attribute information for file transmission may include a TOI value identifying the transmission object (i.e., a TOI value representing a file), FEC object transmission information (i.e., an FEC encoding ID and, if relevant, an FEC instance ID), the size of the object transmitting the file, and an aggregate rate for packet transmission through all channels.

[0286] In one embodiment, the attribute information of the file itself may include a filename or file identifier and location information (in URI form), the media type of the file, the size of the file, the encoding type of the file, and a message digest for verifying the integrity of the file.

[0287] According to the embodiments, in FLUTE-based file delivery, some encoded symbols or source symbols may not be received due to the multicast transmission characteristics. Accordingly, the receiver may perform the following based on the file information and transmission object identification information contained in the FDT instance. That is, it identifies missing source symbols or encoded symbols among the transmission objects corresponding to a specific TOI, and if the file is not fully restored as a result of FEC decoding, it determines the transmission object as an incompletely received object. Then, if it is determined to be an incompletely received object, the receiver performs an object repair procedure using FDT information (TOI, Content-Location, Content-Length, File-ETag, etc.) obtained from the FLUTE-based file delivery. In the object repair procedure, the transmission object can be fully restored by requesting a partial data range of the file that was not received via the multicast session through unicast or a separate repair path.

[0288] FIG. 14 is a diagram illustrating an example of the format of an FDT instance header according to embodiments. In FIG. 14, the FDT instance header (EXT_FDT) consists of a new fixed-length LCT header extension dedicated to ALC protocol instances.

[0289] In FIG. 14, V (4 bits) represents the version of FLUTE, and FDT Instance ID (20 bits) is an identifier for identifying the corresponding FDT instance. According to embodiments, for the FDT Instance ID, for each file transfer, the number of the FDT instance starts at 0 and increases by 1, and when it reaches the maximum value of 1048575 (2^20-1), it is reassigned starting from the most recent ID value of the expired FDT instance.

[0290] The following is a description of the syntax of an FDT instance.

[0291] According to the embodiments, an FDT instance includes a file description entry that provides a mapping function. And, the FDT instance is an extensible XML structure having a single root element FDT-Instance.

[0292] In an FDT instance, the Expire property value provides the expiration time of the FDT instance. The Complete property value can be set to TRUE or FALSE. If the Complete property value is TRUE, it indicates that the FDT instance contains the set of files delivered so far and the set of files delivered from the session. No new data will be served within the FDT instance in the future. It provides a list of all files. If the Complete property value is FALSE, the session will not be completed. New data may be served to the FDT instance in the future.

[0293] Additionally, FDT-Instance attribute values ​​provide common parameters for all files within the FDT instance. They are also provided for individual files within the file's elements. If the same attribute exists in both an FDT-Instance attribute value and a file attribute value, the file attribute value takes precedence. File attribute values ​​are represented as child structures of the FDT-Instance. Content Location attribute values ​​are considered as strings that identify the file.

[0294] The following is a description of the XML schema for FDT instances.

[0295] The XML-structured file element represents the attributes assigned to the file. In this case, the XML attribute values ​​correspond to MIME field names. Each file element contains at least two of the following attribute values. Specifically, TOI must be assigned a valid TOI value. Content-Location is a string identifying the file. A valid URI must be assigned. It typically follows the http or file URI format. An attribute value is assigned per file. Content-Type indicates the media type of the file body, or, in the case of HEAD, the media type received via a GET request. Content-Length indicates the size of the file body in decimal octets. Content-Encoding indicates the mechanism for decoding the media type in the Content-Type header field. Content-MD5 is a hash value for verifying the integrity of the entity body, meaning it can confirm whether the received data has not been corrupted or altered during transmission.

[0296] The following is an explanation of FDT FLAG A and FLAG B.

[0297] According to the embodiments, ALC (Asynchronous Layered Coding) and LCT (Layered Coding Transport) are protocols used for data transmission. The header of these protocols contains information about the data packet and serves to verify whether the data is being transmitted correctly. At this time, if the header is tampered with or damaged, problems may occur during data transmission. For example, if a forged ALC packet is transmitted with Flag A of the Close Object set to 1, the receiver (e.g., terminal) may terminate the session prematurely. Similarly, if a forged ALC packet is transmitted with Flag B of the Close Object set to 1, the receiver may be caused to abandon receiving the object prematurely.

[0298] 다음 코드는 FLUTE에서 사용하는 FDT-Instance 문서의 XML 예시이다.

[0299] <?xml version="1.0" encoding="UTF-8"?>

[0300] <FDT-Instance xmlns:xsi="http: / www.w3.org / 2001 / XMLSchema-instance"

[0301] xsi:schemaLocation="urn:ietf:params:xml:ns:fdt

[0302] ietf-flute-fdt.xsd"

[0303] Expires="2890842807">

[0304] <File

[0305] Content-Location="http: / www.example.com / menu / tracklist.html"

[0306] TOI="1"

[0307] Content-Type="text / html" / >

[0308] <File

[0309] Content-Location="http: / www.example.com / tracks / track1.mp3"

[0310] TOI="2"

[0311] Content-Length="6100"

[0312] Content-Type="audio / mp3"

[0313] Content-Encoding="gzip"

[0314] Content-MD5="+VP5IrWploFkZWc11iLDdA=="

[0315] Some-Private-Extension-Tag="abc123" / >

[0316]

[0317] In the code above, the FDT-Instance element is a parent element that defines the set of files transmitted in a FLUTE session and may include an Expires attribute. The Expires attribute indicates the expiration time of the FDT instance; once this time has elapsed, the corresponding file transfer session is considered no longer valid. The terminal can use this value to determine whether to terminate file transfer or to initiate the object recovery procedure.

[0318] An FDT-Instance may contain one or more file elements, and each file element defines a single Transport Object transmitted through a FLUTE session.

[0319] The first File element may include a Content-Location attribute, a TOI attribute, and / or a Content-Type attribute.

[0320] The Content-Location attribute represents the URI where the transmitted object is logically located, and the terminal identifies the object through that URI.

[0321] TOI is a unique identifier used to identify the corresponding transport object within a FLUTE session. In the example, TOI is set to "1" to indicate that it is the first transport object.

[0322] Content-Type indicates the media type of the transmitted object, and in the example, it indicates that it is an HTML document (text / html).

[0323] In other words, the first file element defines a transmission object representing a web document in HTML format.

[0324] The second file element contains more detailed attributes related to the audio file. As an example, the second file element may include the Content-Location attribute, TOI attribute, Content-Length attribute, Content-Type attribute, Content-Encoding attribute, Content-MD5 attribute, and / or Some-Private-Extension-Tag attribute.

[0325] The Content-Location property represents the URI of an MP3 audio file.

[0326] The TOI attribute is the identifier of the corresponding transfer object, and in the example, it is set to TOI="2" to distinguish it from the first object.

[0327] The Content-Length attribute indicates the total size of the transmitted object in bytes, and the terminal can use this to determine the completeness of the object reception.

[0328] Content-Type indicates the media type of the transmission object, and in the example, it is set to audio / mp3.

[0329] The Content-Encoding property indicates the encoding method applied to the transmission object, and in the example, it indicates that gzip compression has been applied.

[0330] The Content-MD5 attribute is a message digest value used to verify the integrity of a transmitted object, and the terminal uses it to verify the integrity of a received object.

[0331] The Some-Private-Extension-Tag attribute is an extension tag that may include additional metadata depending on the service provider or system implementation.

[0332] By utilizing the FDT instance described above, the terminal can perform the following functions. Specifically, it recognizes in advance the list and identifiers (TOI) of transmitted objects delivered via the FLUTE session, performs object processing and storage based on the URI, size, media type, and encoding method of each transmitted object, and determines the end time of the file transfer session using the Expires attribute. Furthermore, it verifies the completeness and integrity of the transmitted objects using Content-Length and Content-MD5 values, and if some data is missing during transmission, it performs an object repair procedure based on the metadata included in the FDT.

[0333] In this way, the FDT instance supports the terminal in performing object delivery, verification, and object recovery procedures by providing identification, location, and integrity information for transmitted objects delivered through the FLUTE session.

[0334] As mentioned above, in live / low-latency services utilizing the MBS object distribution method, there may be instances where specific objects are not fully received during a session. In such cases, while in-session object recovery can improve service quality, if multiple terminals simultaneously send recovery requests, it can cause overload and delays on the MBS AS (i.e., the recovery server). Specifically, since in-session object recovery is performed while a session is in progress, there is a very high probability that numerous terminals will discover lost or damaged data at the same time; if all terminals send recovery requests to the server simultaneously, it results in server overload.

[0335] The following describes a method for reducing server overload and latency by distributing the timing of recovery requests when recovering in-session objects for multiple objects. The present disclosure describes, as an example, a method for reducing server load during unicast recovery in a session for MBS object distribution. That is, the present disclosure reduces server load by distributing object distribution requests when performing unicast recovery in a session for MBS object distribution.

[0336] According to embodiments, the present disclosure enables multiple object recovery by randomizing the time of the object recovery request based on the time of the previous object recovery request when an object to be recovered is detected at a terminal. That is, the present disclosure proposes a method for randomizing the time of the object recovery request by each terminal when the reception of an object at a terminal during a session (i.e., missing data) fails (i.e., missing data), as the server becomes overwhelmed if multiple terminals simultaneously send object recovery requests to the server or if multiple object recovery requests are sent simultaneously (i.e., in parallel) within a specific terminal.

[0337] The purpose of the insession object recovery of the present disclosure is to execute object recovery in parallel.

[0338] To this end, the present disclosure provides, as an example, signaling whether an object distribution session supports insession object recovery using FDT parameters.

[0339] The present disclosure may indicate whether an object distribution session supports in-session object recovery by adding an FDT parameter (e.g., In-session repair support) to an FDT instance as follows, which indicates whether the object distribution session supports in-session object recovery.

[0340] The following code is an XML example of an FDT-Instance document used in the FLUTE of the present disclosure.

[0341] <?xml version="1.0" encoding="UTF-8"?>

[0342] <FDT-Instance xmlns:xsi="http: / www.w3.org / 2001 / XMLSchema-instance"

[0343] xsi:schemaLocation="urn:ietf:params:xml:ns:fdt

[0344] ietf-flute-fdt.xsd"

[0345] Expires="2890842807"

[0346] In-session repair support = "TRUE"

[0347] <File

[0348] Content-Location="http: / www.example.com / menu / tracklist.html"

[0349] TOI="1"

[0350] Content-Type="text / html" / >

[0351] <File

[0352] Content-Location="http: / www.example.com / tracks / track1.mp3"

[0353] TOI="2"

[0354] Content-Length="6100"

[0355] Content-Type="audio / mp3"

[0356] Content-Encoding="gzip"

[0357] Content-MD5="+VP5IrWploFkZWc11iLDdA=="

[0358] Some-Private-Extension-Tag="abc123" / >

[0359]

[0360] In the code above, the FDT-Instance element is a parent element that defines the set of files transmitted in a FLUTE session, and can include the Expires attribute and the In-session repair support attribute.

[0361] The Expires attribute indicates the expiration time of an FDT instance; once this time has elapsed, the corresponding file transfer session is considered no longer valid. The terminal can use this value to determine whether to terminate file transfer or to initiate the object recovery procedure.

[0362] The In-session repair support property indicates whether the object distribution session supports in-session object recovery. For example, you can set the In-session repair support parameter to TRUE if the object distribution session supports in-session object recovery, and to FALSE if it does not.

[0363] An FDT-Instance may contain one or more file elements, and each file element defines a single Transport Object transmitted through a FLUTE session.

[0364] The first File element may include a Content-Location attribute, a TOI attribute, and / or a Content-Type attribute.

[0365] The Content-Location attribute represents the URI where the transmitted object is logically located, and the terminal identifies the object through that URI.

[0366] TOI is a unique identifier used to identify the corresponding transport object within a FLUTE session. In the example, TOI is set to "1" to indicate that it is the first transport object.

[0367] Content-Type indicates the media type of the transmitted object, and in the example, it indicates that it is an HTML document (text / html).

[0368] In other words, the first file element defines a transmission object representing a web document in HTML format.

[0369] The second file element contains more detailed attributes related to the audio file. As an example, the second file element may include the Content-Location attribute, TOI attribute, Content-Length attribute, Content-Type attribute, Content-Encoding attribute, Content-MD5 attribute, and / or Some-Private-Extension-Tag attribute.

[0370] The Content-Location property represents the URI of an MP3 audio file.

[0371] The TOI attribute is the identifier of the corresponding transfer object, and in the example, it is set to TOI="2" to distinguish it from the first object.

[0372] The Content-Length attribute indicates the total size of the transmitted object in bytes, and the terminal can use this to determine the completeness of the object reception.

[0373] Content-Type indicates the media type of the transmission object, and in the example, it is set to audio / mp3.

[0374] The Content-Encoding property indicates the encoding method applied to the transmission object, and in the example, it indicates that gzip compression has been applied.

[0375] The Content-MD5 attribute is a message digest value used to verify the integrity of a transmitted object, and the terminal uses it to verify the integrity of a received object.

[0376] The Some-Private-Extension-Tag attribute is an extension tag that may include additional metadata depending on the service provider or system implementation.

[0377] By utilizing the FDT instance described above, the terminal can perform the following functions. Specifically, it recognizes in advance the list and identifiers (TOI) of transmitted objects delivered via the FLUTE session, performs object processing and storage based on the URI, size, media type, and encoding method of each transmitted object, determines the termination time of the file transfer session using the Expires attribute, and determines whether the object distribution session supports in-session object recovery using the In-session repair support attribute. Furthermore, it verifies the completeness and integrity of the transmitted objects using Content-Length and Content-MD5 values, and if some data is missing during transmission, performs an object repair procedure based on the metadata (or parameters) included in the FDT.

[0378] In this way, the FDT instance supports the terminal in performing object delivery, verification, and object recovery procedures by providing identification information, location information, support for in-session object recovery, and integrity information regarding transmission objects transmitted through the FLUTE session.

[0379] FIG. 15 is a table showing parameters related to object recovery according to embodiments.

[0380] In Fig. 15, BackOffParameters is a set of parameters for controlling the back-off behavior at the time of the recovery request in the object recovery mechanism of the MBSTF client. In other words, it is a parameter for the back-off behavior in the object recovery mechanism of the MBSTF client. That is to say, BackOffParameters is a higher-level parameter containing delay-related parameters applied before the object recovery request to prevent object recovery requests from concentrating on the server. If omitted, a back-off delay is not required. The data type of BackOffParameters is BackOffParameters, and it may be provided optionally.

[0381] offsetTime is a parameter (or attribute) of data type DurationSec that indicates the minimum time an MBSTF client must wait after completing the download delivery of an MBS distribution session before performing an object recovery request. In other words, it is the minimum time an MBSTF client must wait after completing a download delivery session before making an object recovery request. If no value is provided, offsetTime is assumed to be 0.

[0382] randomTimePeriod is a parameter of data type DurationSec that indicates the maximum range of random delay time used to prevent server load concentration during object recovery requests. In other words, it is the maximum window length for calculating the RandomTime value that the MBSTF client uses as the delay for object recovery requests. The MBSTF client calculates a random time within this range, and the resulting random time (RandomTime value) is added to offsetTime. If no value is provided, randomTimePeriod is considered to be 0.

[0383] in-session offsetTime is a parameter of data type DurationSec that indicates the minimum time an MBSTF client must wait before performing an object recovery request while the download forwarding session is still in-session. In other words, in-session offsetTime defines the minimum waiting time applied to in-session object recovery requests and is used as a control measure to prevent object recovery requests from occurring immediately even while a download forwarding session is in progress. That is to say, in-session offsetTime is the minimum time an MBSTF client must wait after completing the download forwarding session before making an in-session object recovery request. If omitted, in-session offsetTime is considered to be 0.

[0384] in-session randomTimePeriod is a parameter of data type DurationSec that defines the maximum range of random delay (RandomTime) applied to in-session object repair requests. The random delay based on in-session randomTimePeriod is determined by the Object Repair Controller, and the determined random delay is added to in-session offsetTime to determine the actual execution time of the in-session object repair request. In other words, it is the maximum range of random delay (RandomTime) that the MBSTF client will use as a delay for object repair requests, and the random delay based on this is determined by the Object Repair Controller. If this value is not provided, in-session randomTimePeriod is considered to be 0.

[0385] In the present disclosure, the in-session randomTimePeriod is set based on the time of detection of missing data of the previous object.

[0386] In the present disclosure, the time taken to detect missing data of a previous object is the time taken until missing data is detected for a previous object, and refers to the time taken until an MBS client recognizes that a reception failure (missing data) has occurred for the object during an object distribution session. That is, the time taken to detect missing data of a previous object is the time from the point when the previous object begins to be transmitted until the point when it is determined that the object has not been fully received.

[0387] In the present disclosure, the MBS client may determine the start time of object transmission as the time when it recognizes, through an FDT instance, that the object is a transmission target of an object distribution session and / or receives the first ALC / FLUTE packet corresponding to the object. Additionally, the client may determine the time when it is determined that the object has not been fully received as one or more of the following: when the number of symbols required for object decoding is not satisfied even though FDT@Expires has elapsed; when the transmission end flag (A-flag) of the ALC / FLUTE header is received; or when it is determined that object recovery is impossible as a result of FEC decoding.

[0388] That is, in the present disclosure, the time for detecting missing data of a previous object refers to the elapsed time from the point in time when object transmission for the previous object is initiated during an object distribution session until the point in time when it is determined by the MBS client that the object has not been fully received. The point in time of determination may be, for example, when the termination of object transmission is determined by the session termination flag (A-flag) of the FDT@Expires or ALC / FLUTE header, or when it is confirmed that the number of symbols required for object decoding is not satisfied.

[0389] According to the embodiments, in-session offsetTime is a fixed value applied equally to all objects during a session as a minimum waiting time applied before an in-session object recovery request, and in-session randomTimePeriod is an upper limit of a random delay time set differently per object, which is dynamically set by the object recovery controller based on the time of detection of missing data of the previous object. That is, in-session offsetTime is a fixed default delay time applied per session, and in-session randomTimePeriod is a variable random delay range that varies according to the characteristics of each object.

[0390] According to embodiments, the in-session randomTimePeriod is set per object based on the time of detection of missing data of the previous object, and the object recovery controller manages the in-session randomTimePeriod corresponding to each object on an object-by-object basis to determine the time of the recovery request.

[0391] URL attributes related to object recovery and distribution can include objectDistributionBaseLocator and objectRepairBaseLocators.

[0392] objectDistributionBaseLocator is a parameter of data type URI that represents the object distribution base URL used in the MBS distribution session. This URL is specified by the MBS application provider, and MBSTF can configure object distribution metadata by replacing the object ingest base URL used during the object ingest process with this objectDistributionBaseLocator. In other words, it is the URL used to replace the object ingest base URL during the distribution process of objects collected by MBSTF. If omitted, objectDistributionBaseLocator (i.e., the object distribution URL) is considered to be the same as the object ingest URL.

[0393] objectRepairBaseLocators is a parameter of data type as an array of Absolute URIs, representing a list of object repair base URLs for performing object repair in an MBS distribution session. In other words, it is the object repair base URL of the MBS distribution session. These URLs are specified by the MBSF and are used by MBSTF clients when performing object repair. objectRepairBaseLocators is used in place of the object distribution base URL when repairing incompletely received objects in an MBS distribution session. This value must point to an MBS AS and exists only if the object repair function is provided in that MBS distribution session. That is, rather than being directly related to the MBSTF parameter itself, this parameter is used for association with external MBS AS entities that provide object repair.

[0394] FIG. 16 is a diagram showing another example of an MBS user service reference architecture according to embodiments. In particular, FIG. 16 is a diagram illustrating a reference architecture for providing MBS user services, wherein an object recovery controller is included in an MBSTF client within a terminal as one embodiment. That is, FIG. 16 is an MBS architecture in which the function of an object recovery controller is added inside an MBSTF client.

[0395] In FIG. 16, the UE is a terminal receiving MBS user services, and the elements of the UE may be implemented in hardware, software, processors connected to memory, and / or combinations thereof. That is, the elements of the UE in FIG. 16 may be implemented in hardware, software, firmware, or a combination thereof, including one or more processors or integrated circuits configured to communicate with one or more memories, although not illustrated in the drawing. One or more processors may perform at least one of the operations and / or functions of the elements of the UE in FIG. 16 described above. Additionally, one or more processors may operate or execute a set of software programs and / or instructions for performing the operations and / or functions of the elements of the UE in FIG. 16.

[0396] According to embodiments, the UE may include an MBS-aware Application and an MBS client.

[0397] The above MBS client may include an MBSF client and an MBSTF client, and performs reception, control, data processing, and reception of object-based content for MBS user services. The above MBSTF client may include a media server and an object recovery controller. The detailed operation of the above object recovery controller will be described later.

[0398] In FIG. 16, the data network (DN) includes a trusted DN and an external DN. The trusted DN may include MBSF, MBSSF, MBSTF, and MBS AF. The external DN may include an MBS application provider (AF / AS), and the MBS application provider (AF / AS) may include MBS AS. The trusted DN is a network domain trusted by the mobile operator and is an area where core network functions such as MBSF, MBSTF, MBS AF, and MBSSF, which perform control, transmission, and security functions for MBS user services, are deployed. The external DN is a data network located outside the mobile core network and is an area where the MBS application provider (AF / AS) creates and manages content and provides said content to the MBS system.

[0399] The MBS-aware Application within the above UE controls the activation / deactivation of MBS user services and the reception of user data using APIs exposed by MBSF clients and MBSTF clients through reference points MBS-6 and MBS-7.

[0400] The MBSF (Multicast / Broadcast Service Function) can perform the following functions to support MBS: namely, 'providing service functions for MBS service provision and interoperability with LTE MBMS', 'configuring the MBS AF through the reference point MBS-3 and publishing user service announcements', 'interacting with the AF and MB-SMF for MBS session operations, determining transport parameters, and session transmission', 'selecting the MB-SMF to provide the MBS session', 'controlling the MBSTF if it is used', and / or 'determining the destination IP multicast address for the MBS session if an IP multicast address is provided by the MBSTF'.

[0401] The MBSTF (Multicast / Broadcast Service Transport Function) is a functional block responsible for the transport layer of MBS user services and can perform the following functions to support MBS: namely, acting as a media anchor for MBS data traffic when necessary, providing IP multicast sources when necessary, general packet transport functions provided to IP multicast-supported applications such as framing, multiple flow processing, and packet FEC (encoding), and / or converting input files into object or object flow forms and delivering them via multicast / broadcast. According to embodiments, the MBSTF distributes content to MBS clients via unidirectional multicast through the reference point MBS-4-MC.

[0402] The MBS AF (MBS Application Function) performs application control functions related to MBS user services and can perform the following functions to support MBS: namely, providing service information including QoS requirements to 5GC for multicast or broadcast service requests, directing MBS session operations to 5GC if necessary, and / or interacting with NEF to expose MBS-related services. Additionally, it enables MBSTF to retrieve object manifests and user service announcements listed in object manifests from the MBS AF via the reference point MBS-11.

[0403] The MBSSF (MBS Security Function) is a function block that provides security functions for MBS user services. To support MBS security functions, the MBSSF provides security anchors to MBSTF clients via the reference point MBS-10 and authenticates access to secure MBS data according to predefined user plane security procedures.

[0404] The MBS Application Provider (AF / AS) is a higher-level service provider that performs the role of the MBS AS. The MBS Application Provider (AF / AS) provides object-based content, service logic, and user service-related information, and can provide user announcements to MBS-aware applications through the reference point MBS-8.

[0405] The MBS AS (MBS Application Server) is an application server for MBS user services that provides file-based object recovery services to MBSTF clients in conjunction with object distribution methods. To support MBS user services, it can perform the following functions: specifically, it can provide byte-range file recovery services to MBSTF clients for use with object distribution methods (via the reference point MBS-4-UC). In other words, it can provide byte-range file recovery services by performing User Plane interactions with MBSTF clients through the reference point MBS-4-UC. Additionally, the MBS AS is configured by the MBSF using the reference point MBS-9 and can retrieve content from MBSTF.

[0406] The reference points illustrated in FIG. 16 define the control plane and user plane interactions of MBS user services separately, and multicast / broadcast-based service delivery and object-based distribution and recovery functions are combined. The description of the reference points illustrated in FIG. 16 will be omitted here to avoid redundancy, as the description of the reference points in FIG. 8 will be referenced.

[0407] In FIG. 16, the object recovery controller within the MBS client detects the time at which missing data occurs for each object, records the time value until the occurrence of missing data for each object, and calculates the time at which an object recovery request is made based on in-session offsetTime and in-session randomTimePeriod. At this time, recovery requests for multiple objects are managed on a queue basis. In the present disclosure, the queue-based method is a method that uses a queue to manage and distribute each object recovery request in order when multiple objects fail to receive (missing).

[0408] For example, in the case of insession object recovery, the object recovery controller independently calculates the time of the recovery request for the second object even when the recovery of the first object is not completed. By doing so, object recovery requests can be distributed even in an environment with multiple objects and multiple terminals for insession object recovery.

[0409] In other words, for POST session object recovery, a simple random back-off method using offset time and Random Time Period is used to distribute object recovery requests and prevent server overload.

[0410] However, this method is difficult to apply to recovery requests for missing data occurring during object distribution sessions (i.e., in-sessions), and there is a problem in that the server load balancing effect is limited in situations where recovery is required for multiple objects continuously or in parallel.

[0411] Accordingly, the object recovery controller of the present disclosure utilizes the trend of the timing of missing data occurrence to distribute object recovery requests for insession object recovery.

[0412] In this case, the object recovery controller may operate in a queue format and stores time values ​​until missing data occurs in the queue for each missing data and / or object. In addition, information regarding the object identifier (or object acquisition identifier), the start time of object distribution, the time when missing data is detected, the time elapsed until missing data detection, and / or the calculated scheduled time for the object recovery request may be additionally stored in the queue for each missing data and / or object.

[0413] In the present disclosure, the time until missing data occurs may be referred to as the missing data detection time of an object. According to embodiments, the in-session randomTimePeriod parameter corresponding to the current object is set based on the missing data detection time of the previous object. If there is no missing data detection time of the previous object, the in-session randomTimePeriod parameter may be set to 0.

[0414] In the present disclosure, the time taken to detect missing data of a previous object is the time taken until missing data is detected for a previous object, and refers to the time taken until an MBS client recognizes that a reception failure (missing data) has occurred for the object during an object distribution session. That is, the time taken to detect missing data of a previous object is the time from the point when the previous object begins to be transmitted until the point when it is determined that the object has not been fully received.

[0415] In the present disclosure, the object recovery controller may determine the start time of object transmission as the time when it recognizes, through an FDT instance, that the object is a transmission target of an object distribution session and / or receives the first ALC / FLUTE packet corresponding to the object. Additionally, the controller may determine the time when the object is not completely received as one or more of the following: when the number of symbols required for object decoding is not satisfied even though FDT@Expires has elapsed; when the transmission end flag (A-flag) of the ALC / FLUTE header is received; or when it is determined that object recovery is impossible as a result of FEC decoding.

[0416] In this disclosure, in-session offsetTime is a parameter representing the minimum waiting time applied before an in-session object recovery request, and is a fixed value applied equally to all objects during the object distribution session. Additionally, in-session randomTimePeriod is a parameter representing the upper limit of a random delay time that is set differently per object, and is dynamically set by the object recovery controller based on the time of detection of missing data from the previous object. That is, in-session offsetTime is a base delay time fixed and applied on a session-by-session basis, while in-session randomTimePeriod is a variable random delay range that varies according to the characteristics of each object. The above parameters are a dataset held and applied by the MBSTF client within the UE, and are configured so that the UE autonomously determines the timing of the object recovery request without direct instruction from the server.

[0417] According to embodiments, the in-session randomTimePeriod is set per object based on the time of detection of missing data of the previous object, and the object recovery controller manages the in-session randomTimePeriod corresponding to each object on an object-by-object basis to determine the time of the recovery request.

[0418] According to embodiments, the in-session randomTimePeriod may be set to the time for detecting missing data of the previous object. The object recovery controller determines a random delay time for an object recovery request with the value of the in-session randomTimePeriod as the upper limit. According to embodiments, the random delay time is randomly selected (or determined) to a value equal to or smaller than the value of the in-session randomTimePeriod. That is, the actual random delay time (RandomTime) is randomly determined by the object recovery controller within the range of the in-session randomTimePeriod.

[0419] In other words, the object recovery controller determines a random delay time (i.e., a random value) based on the in-session offsetTime and in-session randomTimePeriod parameters. More specifically, the object recovery controller sets the timing of the recovery request for the object by adding the selected (or determined) random delay time value to the value of in-session offsetTime.

[0420] Through this structure, the object recovery controller can calculate in advance the timing of the recovery request for a subsequent object (e.g., the second object, or the object in question, or the current object) even before the recovery of the previous object (e.g., the first object) is completed, and can effectively distribute object recovery requests even in multi-fail situations.

[0421] In this way, the object recovery controller can proceed with object recovery sequentially within a range that does not exceed the entire session, taking into account the existing reception failure time (i.e., the time taken to detect missing data of the previous object). Since there is a possibility of simultaneous occurrence of missing data with other UEs, the present disclosure may apply a random value (i.e., random delay time) to the calculation of the object recovery request time. In the present disclosure, the waiting time value before requesting object recovery (i.e., referred to as random delay time) is defined as a random value, and this random value is calculated (or determined) by the object recovery controller and stored. The present disclosure refers to the said random value as Random Time.

[0422] For example, let us assume that the missing data detection time of Object 1 is 10 seconds, that is, the time from when Object 1 begins to be transmitted until when it is determined that the object has not been fully received is 10 seconds. In this case, the missing data detection time of Object 1 is stored to be applied at the time of a subsequent recovery request for the missing object. According to the embodiments, the missing data detection time value of Object 1 is stored in a queue corresponding to Object 1. Furthermore, assuming there is no missing data for an object preceding Object 1, the time of an object recovery request for Object 1 can be determined by adding a randomly selected value of 10 seconds or a value smaller than 10 seconds to the in-session offsetTime. If we assume that the missing data detection time of Object 2 is 5 seconds, that is, the time from when Object 2 begins to be transmitted until when it is determined that the object has not been fully received is 5 seconds. In this case, the missing data detection time of Object 2 is stored to be applied at the time of a subsequent recovery request for the missing object. According to the embodiments, the time value for detecting missing data of the second object is stored in a queue corresponding to the second object. In this case, the in-session randomTimePeriod value for the second object is set to 10. Then, the time of the object recovery request for the second object can be determined by randomly selecting a value of 10 seconds or less than 10 seconds set in the in-session randomTimePeriod value, and then adding the selected value (i.e., random delay time) to the in-session offsetTime. If missing data is detected in the third object, the time of the object recovery request for the third object can be determined by randomly selecting a value of 5 seconds or less than 5 seconds set in the in-session randomTimePeriod value, and then adding the selected value to the in-session offsetTime.When the present disclosure is applied, the timing of recovery requests for the first and second objects can be distributed even when additional missing data is detected for the second object while the recovery of the first object is not yet complete during the session (i.e., in session). That is, recovery requests for the first and second objects are distributed and executed at different times.

[0423] FIGS. 17a and 17b illustrate different examples of call flows for insession object recovery according to embodiments. In particular, FIGS. 17a and 17b are flowcharts illustrating an insession object recovery process in which an object recovery controller within an MBS client performs recovery of a second object before recovery of a first object is completed. Taking FIGS. 17a and 17b as examples, parallel operation of the first object and the second object must be possible. Then, one or more objects that are incompletely received after object delivery setup are detected.

[0424] FIGS. 17a and 17b may include an Object Delivery Setup step, a first Object Distribution Session step, a first Object Delivery Termination Determination step, a first Object Missing Data Identification step, a first Object Recovery Procedure Initiation step, a first Object Recovery Request Time Calculation step, a second Object Distribution Session step, a second Object Delivery Termination and Missing Data Identification step, a second Object Recovery Request Time Calculation step, an Object Recovery Data Reception and Object Restoration step, and an Object Recovery Completion and Queue Update step.

[0425] In the Object Delivery Setup step described above, the MBSTF client included in the MBS client performs Object Delivery Setup for object distribution. During this process, the MBSTF client obtains an instance of the File Delivery Table (FDT) used for FLUTE-based object distribution from MBSTF. Specifically, the MBSTF client receives an instance of the FLUTE-based File Delivery Table (FDT), which includes identification information of the objects to be distributed, the TOI for each object, object location information, and the session expiration time (@Expires).

[0426] In the above first object distribution step (Object 1 Distribution Session), the MBSTF client requests the first object from MBSTF through an object distribution session for the first object (object 1) based on an FDT instance. In response to the request, MBSTF delivers the first object to the MBS client through the object distribution session. That is, MBSTF delivers the first object to the MBS client via a multicast or broadcast transmission method. At this time, the delivery of the first object can be performed through the reference point MBS-4-MC.

[0427] In the first object delivery termination determination step, the MBS client determines whether the delivery of the first object has been terminated. Specifically, the MBS client determines the time at which the delivery of the first object ends based on the expiration time (@Expires) included in the FDT instance or the termination flag (A-flag or B-flag) included in the FLUTE / ALC header.

[0428] In the above step of identifying missing data for the first object, when the MBS client (or object recovery controller) determines that the delivery of the first object has ended, it identifies whether there is missing data for the first object. That is, the MBS client determines whether the delivery of the first object has ended and checks whether there is any data that was transmitted but not received for the first object. During this process, missing data for the first object may be identified. For example, if source symbols are not received during the FLUTE transmission process or if the number of symbols required for decoding is insufficient, it is determined that missing data for the first object exists. If missing data for the first object is identified, the MBS client initiates the Object 1 Repair Process (object 1 repair start) while the object distribution session of the first object has not ended, that is, while in an in-session state.

[0429] In the first object recovery procedure initiation step described above, if missing data for the first object is identified, the MBS client initiates an in-session object recovery procedure for the first object. At this time, the MBS client selects a recovery URL corresponding to the MBS AS to perform the first object recovery from the objectRepairBaseLocator list defined in the ObjectRepair object. That is, the MBS client sends a request to select a recovery URL (Select Repair object 1 URL) to the MBS AS to perform the first object recovery. In response, the MBS AS selects an appropriate Repair object 1 URL and transmits it to the MBS client. The MBS client forms a network location URL to be used for the object recovery request (Form network location URL) using the Repair object 1 URL received from the MBS AS. That is, the MBS client forms a network location URL to be used for the object recovery request of the first object using the selected recovery URL, File@Content-Location included in the FDT instance, and, if necessary, objectDistributionBaseLocator information.

[0430] In the step of calculating the first object recovery request time, the object recovery controller within the MBS client calculates the recovery request time for the first object. Specifically, the object recovery controller performs the following: it calculates the time elapsed until the missing data of the first object is detected, i.e., the first object missing data detection time. Based on the value of the first object missing data detection time, it sets an in-session randomTimePeriod value corresponding to the first object. Using the in-session offsetTime and the in-session randomTimePeriod, it calculates the actual random delay time. It determines the recovery request time for the first object by adding the random delay time to the in-session offsetTime. The information regarding the first object missing data detection time and / or the determined recovery request time is stored in a queue, and recovery requests for multiple objects can be managed sequentially.

[0431] In the above Object 2 Distribution Session, the MBSTF client can perform an object distribution session for the second object (object 2) in parallel, even if the recovery procedure for the first object is in progress. Accordingly, MBSTF delivers the second object to the MBS client. That is, the second object is requested from MBSTF through the Object 2 Distribution Session for the second object (object 2). In response to the request, MBSTF delivers the second object to the MBS client through the object distribution session. At this time, the delivery of the second object can be performed through the reference point MBS-4-MC.

[0432] In the step of terminating second object delivery and identifying missing data, the MBS client determines whether to terminate delivery for the second object as well, based on the FDT expiration time or the FLUTE / ALC termination flag. Simultaneously, the MBS client sends a recovery request to the MBS AS for a byte range corresponding to the missing first object data, using the configured network location URL. In response to the byte range request received from the MBS client, the MBS AS transmits the first object data corresponding to the requested byte range to the MBS client.

[0433] Additionally, in the step of terminating the second object delivery and identifying missing data, if the MBS client determines that the delivery of the second object has ended, it identifies whether there is any missing data regarding the second object. That is, the MBS client determines whether the delivery of the second object has ended and checks whether there is any data that was transmitted but not received regarding the second object. During this process, missing data regarding the second object may be identified. For example, if source symbols are not received during the FLUTE transmission process or if the number of symbols required for decoding is insufficient, it is determined that missing data regarding the second object exists. If missing data regarding the second object is identified, the MBS client initiates an object repair process (Object 2 Repair Process) while the object distribution session of the second object has not ended, i.e., while in an in-session state (object 2 repair start).

[0434] In the step of calculating the second object recovery request time, if missing data is identified for the second object, the object recovery controller calculates the recovery request time for the second object. Specifically, the object recovery controller performs the following: it calculates the time taken until the missing data of the second object is detected, i.e., the second object missing data detection time. Then, based on the first object missing data detection time value already stored in the queue, it sets the in-session randomTimePeriod value corresponding to the second object. Subsequently, based on the in-session randomTimePeriod value—that is, a value equal to or smaller than the in-session randomTimePeriod value—it randomly selects a random delay time, and then determines the recovery request time for the second object by adding the in-session offsetTime value to the selected random delay time. In other words, the random delay time is determined using the in-session randomTimePeriod as an upper limit. Furthermore, the information regarding the second object missing data detection time and / or the determined second object recovery request time is stored in a queue, and recovery requests for multiple objects can be managed sequentially. In this case, the time of the recovery request for the second object can be calculated even before the recovery of the first object is completed, and is managed on a queue basis.

[0435] In the object recovery data reception and object restoration steps described above, the MBS client converts the byte range data received from the MBS AS into transmission symbols in accordance with the FLUTE / ALC transmission structure. Then, the MBS client combines the previously received object data with the recovered symbol data to complete object repair by restoring the missing first object or a part of the first object.

[0436] In the above object recovery completion and queue update step, when the recovery of the first object is completed, the MBS client terminates the insession object recovery process for the first object by releasing the recovered first object (release object 1) or providing it to the parent application. That is, when the recovery of the first object is completed, the object recovery controller records the end of recovery for the object and updates the queue.

[0437] Additionally, the present disclosure restores the missing second object or a part of the second object by undergoing an object recovery process identical to the first object recovery process described above when the recovery request time for the second object calculated in the step of calculating the second object recovery request time arrives. This process may sequentially perform the calculation of the recovery request time or the recovery procedure for the object(s) following the second object.

[0438] As described above, a method for object recovery in multicast-broadcast may include the steps of: detecting the omission of part or all data of an object in an in-session basis where an object distribution session is in progress; storing the time information of the omission detection of the object in a queue corresponding to the object; calculating the time of the object's recovery request based on one or more times information of the omission detection of the object's data stored in the queue; and transmitting the object's recovery request to a server at the calculated time of the object's recovery request. The time of the object's recovery request may be determined based on the time information of the omission detection of the previous object.

[0439] The step of calculating the recovery request time of the object may calculate the recovery request time of the object by randomly selecting random delay time information based on the missing data detection time information of the previous object of the object, and adding pre-set offset time information to the selected random delay time information. The offset time information represents a minimum waiting time applied before the recovery request of the object and is applied equally to all objects distributed within the object distribution session, and the random delay time information may be applied differently to each object according to the missing data detection time information of the previous object to control the recovery request time of the object. At this time, the missing data detection time information of the previous object is set as the upper limit value of the random delay time information, and the random delay time information is randomly selected from values ​​equal to or smaller than the value of the missing data detection time information of the previous object of the object.

[0440] The method for object recovery in the above multicast-broadcast may further include the step of creating a table instance that includes a parameter indicating whether the object distribution session supports in-session-based object recovery.

[0441] In the present disclosure, a computer program may be stored on a computer-readable recording medium and combined with a computer, which is hardware, to perform the object recovery method of the present disclosure.

[0442] The method for object recovery in the multicast-broadcast described so far can be performed by the terminal.

[0443] The above terminal includes a memory and at least one processor connected to the memory, and the at least one processor is configured to detect the omission of part or all of an object's data in an in-session basis in which an object distribution session is in progress, store the omission data detection time information of the object in which the omission was detected in a queue corresponding to the object, calculate the time of a recovery request for the object based on one or more omission data detection time information stored in the queue, and transmit a recovery request for the object to a server at the calculated time of a recovery request for the object, and the time of a recovery request for the object may be determined based on the omission data detection time information of the previous object of the object.

[0444] The above at least one processor can randomly select random delay time information based on the time information of detecting missing data of the previous object of the object, and calculate the time of the object's recovery request by adding the selected random delay time information to the preset offset time information.

[0445] The above at least one processor may create a table instance including a parameter that indicates whether the object distribution session supports in-session-based object recovery.

[0446] Each of the aforementioned parts, modules, or units may be software, processors, or hardware parts that execute successive processes stored in memory (or storage units). Each step described in the aforementioned embodiments may be performed by processors, software, or hardware parts. Each module / block / unit described in the aforementioned embodiments may operate as a processor, software, or hardware. Additionally, the methods presented in the embodiments may be executed as code. This code may be written to a storage medium that is readable by a processor and thus read by a processor provided by the apparatus.

[0447] Furthermore, throughout the specification, when a part is described as “comprising” a certain component, this means that, unless specifically stated otherwise, it does not exclude other components but may include additional components. Also, terms such as “…part” as used in the specification refer to a unit that processes at least one function or operation, and this may be implemented in hardware, software, or a combination of hardware and software.

[0448] Although the drawings have been described separately for convenience of explanation in this specification, it is also possible to design a new embodiment by combining the embodiments described in each drawing. Furthermore, according to the needs of a person skilled in the art, designing a computer-readable recording medium on which a program for executing the previously described embodiments is recorded falls within the scope of the embodiments.

[0449] The apparatus and method according to the embodiments are not limited to the configurations and methods of the embodiments described above; rather, the embodiments may be configured by selectively combining all or part of each embodiment so that various modifications can be made.

[0450] Although preferred embodiments have been illustrated and described, the embodiments are not limited to the specific embodiments described above. Furthermore, various modifications can be made by those skilled in the art without departing from the essence of the embodiments claimed in the claims, and such modifications should not be understood individually from the technical spirit or perspective of the embodiments.

[0451] Various components of the device according to the embodiments may be implemented by hardware, software, firmware, or a combination thereof. Various components of the embodiments may be implemented as a single chip, for example, a single hardware circuit. Components according to the embodiments may each be implemented as separate chips. At least one of the components of the device according to the embodiments may be composed of one or more processors capable of executing one or more programs, and one or more programs may include instructions for performing or executing any one or more of the operations / methods according to the embodiments. Executable instructions for performing the methods / operations of the device according to the embodiments may be stored in non-transient CRMs or other computer program products configured to be executed by one or more processors, or may be stored in transient CRMs or other computer program products configured to be executed by one or more processors. Additionally, memory according to the embodiments may be used as a concept that includes not only volatile memory (e.g., RAM, etc.) but also non-volatile memory, flash memory, PROM, etc. In addition, it may also include implementation in the form of a carrier wave, such as transmission over the Internet. Furthermore, processor-readable recording media may be distributed across networked computer systems, allowing processor-readable code to be stored and executed in a distributed manner.

[0452] In this document, " / " and "," are interpreted as "and / or." For example, "A / B" is interpreted as "A and / or B," and "A, B" is interpreted as "A and / or B." Additionally, "A / B / C" means "at least one of A, B, and / or C." Also, "A, B, C" means "at least one of A, B, and / or C." Additionally, in this document, "or" is interpreted as "and / or." For example, "A or B" may mean 1) "A" only, 2) "B" only, or 3) "A and B." In other words, "or" in this document may mean "additionally or alternatively."

[0453] Various elements of the embodiments may be performed by hardware, software, firmware, or a combination thereof. Various elements of the embodiments may be performed on a single chip, such as a hardware circuit. Depending on the embodiments, the embodiments may optionally be performed on individual chips. Depending on the embodiments, at least one of the elements of the embodiments may be performed within one or more processors that include instructions for performing operations according to the embodiments.

[0454] Additionally, the operation according to the embodiments described herein may be performed by a transceiver device comprising one or more memories and / or one or more processors according to the embodiments. One or more memories may store programs for processing / controlling the operation according to the embodiments, and one or more processors may control the various operations described in this document. One or more processors may be referred to as controllers, etc. The operations of the embodiments may be performed by firmware, software, and / or a combination thereof, and the firmware, software, and / or a combination thereof may be stored in a processor or in memory.

[0455] Terms such as "first," "second," etc., may be used to describe various components of the embodiments. However, the interpretation of the various components according to the embodiments should not be limited by these terms. These terms are merely used to distinguish one component from another. For example, the first user input signal may be referred to as the second user input signal. Similarly, the second user input signal may be referred to as the first user input signal. The use of these terms should be interpreted as not departing from the scope of the various embodiments. Although the first user input signal and the second user input signal are both user input signals, they do not imply the same user input signals unless clearly indicated in the context.

[0456] The terms used to describe the embodiments are intended for the purpose of describing specific embodiments and are not intended to limit the embodiments. As used in the description of the embodiments and in the claims, the singular is intended to include the plural unless explicitly indicated in the context. Expressions of "and / or" are used to mean including all possible combinations between the terms. Expressions of "include" describe the presence of features, numbers, steps, elements, and / or components and do not imply the exclusion of additional features, numbers, steps, elements, and / or components. Conditional expressions such as "if" or "when" used to describe the embodiments are not limited to being optional. It is intended to be interpreted as "when a specific condition is satisfied," "when a related action is performed in response to a specific condition," or "when a related definition is interpreted."

[0457] As described above, the relevant details have been explained in the best mode for carrying out the embodiments.

[0458] As described above, the embodiments may be applied wholly or in part to transmitting / receiving devices and systems for multicast / broadcast services. Those skilled in the art may make various changes or modifications to the embodiments within the scope of the embodiments.

[0459] The embodiments may include modifications / variations, and such modifications / variations do not exceed the scope of the claims and their equivalents.

Claims

1. A method performed by a terminal supporting MBS (Multimedia Broadcast / Multicast Service), A step of detecting the omission of part or all of an object's data in an in-session basis while an object distribution session is in progress; A step of storing the missing data detection time information of the object in which the above-mentioned omission was detected in a queue corresponding to the object; A step of calculating the time of a recovery request for the object based on one or more missing data detection time information stored in the queue; and It includes the step of transmitting a recovery request for the object to a server at the time of the recovery request for the object calculated above, A method in which the timing of the recovery request for the above object is determined based on the time information of the detection of missing data of the previous object of the above object.

2. In claim 1, the step of calculating the time of the object recovery request A method for calculating the recovery request time of the object by randomly selecting random delay time information based on the time information of detecting missing data of the previous object of the object, and adding preset offset time information to the selected random delay time information.

3. In Paragraph 2, A method for controlling the timing of a recovery request for an object, wherein the offset time information represents a minimum waiting time applied before the recovery request of the object and is applied equally to all objects distributed within the object distribution session, and the random delay time information is applied differently to each object according to the missing data detection time information of the previous object.

4. In Paragraph 2, A method in which the missing data detection time information of the previous object is set as the upper limit of the random delay time information, and the random delay time information is randomly selected from values ​​equal to or smaller than the value of the missing data detection time information of the previous object.

5. In Paragraph 1, A method further comprising the step of creating a table instance including a parameter indicating whether the object distribution session supports in-session-based object recovery.

6. In Paragraph 5, The missing data detection time information of the object is the elapsed time from the point in time when transmission of the object from the server is initiated until the point in time when the transmission of the object is terminated, and the method of identifying whether part or all of the data of the object is missing during the period corresponding to the missing data detection time information of the object.

7. In Paragraph 6, A method for determining the delivery end time of the above object based on at least one of expiration time information included in the table instance or termination flag information received during the object distribution session.

8. In a terminal supporting MBS (Multimedia Broadcast / Multicast Service), Memory; and At least one processor connected to the memory; comprising, wherein the at least one processor: Detecting the missing of part or all of an object's data in an in-session based on an ongoing object distribution session; The missing data detection time information of the object in which the above-mentioned omission was detected is stored in a queue corresponding to the object; Calculate the time of the recovery request for the object based on one or more missing data detection time information stored in the above queue; and It is configured to transmit a recovery request for the object to the server at the time of the recovery request for the object calculated above; and A terminal in which the recovery request time of the above object is determined based on the time information of the detection of missing data of the previous object of the above object.

9. In claim 8, the at least one processor A terminal that randomly selects random delay time information based on the time information of detecting missing data of a previous object of the above object, and calculates the time of the object's recovery request by adding preset offset time information to the selected random delay time information.

10. In Paragraph 9, A terminal that controls the timing of the object recovery request, wherein the offset time information indicates a minimum waiting time applied prior to the object recovery request and is applied equally to all objects distributed within the object distribution session, and the random delay time information is applied differently per object according to the missing data detection time information of the previous object.

11. In Paragraph 9, A terminal in which the missing data detection time information of the previous object is set as the upper limit of the random delay time information, and the random delay time information is randomly selected from values ​​equal to or smaller than the value of the missing data detection time information of the previous object.

12. In claim 8, the at least one processor A terminal that creates a table instance including a parameter indicating whether the object distribution session supports in-session-based object recovery.

13. In Paragraph 12, The missing data detection time information of the object is the elapsed time from the point in time when transmission of the object from the server is initiated until the point in time when the delivery of the object is terminated, and the terminal is identified during the period corresponding to the missing data detection time information of the object whether part or all of the data of the object is missing.

14. In Paragraph 13, A terminal in which the delivery termination time of the above object is determined based on at least one of expiration time information included in the table instance or termination flag information received during the object distribution session.

15. A computer program stored on a computer-readable recording medium that is combined with a computer, which is hardware, to perform the method of claim 1.

Images