KR20180138122A - Peer and operating mehtod of thereof - Google Patents

Abstract

Disclosed is a peer and an operation method of the peer, the method including receiving, from a partner peer, buffermap timetable (BTT) information associated with a buffermap of the partner peer, verifying whether a difference value between a forced delay and time information of the peer corresponds to the BTT information, requesting, when the difference value corresponds to the BTT information, a fragment of a fragment number corresponding to the difference value from the partner peer, and deriving, when the difference value does not correspond to the BTT information, the fragment number based on the BTT information.

Description

[0001] DESCRIPTION [0002] PEER AND OPERATING MEHTOD OF THEREOF [

The following embodiments relate to peers.

Unlike the server-client method, in the case of distributed streaming based on peer-to-peer (P2P), playback synchronization is difficult due to various factors (for example, the buffer maps of the peers are different). A technique for such reproduction synchronization is required.

Korean Patent Registration No. 10-1231208 entitled " Method of providing a list of peering agents, method of forming P2P network, P2P application device, terminal and network device forming P2P network, : Ewha Womans University Industry-Academic Collaboration Foundation). The prior art includes receiving a stream availability message from at least one peer forming a peer-to-peer network, and calculating a stream availability weight for each peer; Receiving a subscription request message for the P2P network from the terminal; Generating a list of peering sugestions for the terminal based on the stream availability weight; And providing a list of the peering agent to the terminal.

A method of operating a peer according to one side comprises receiving buffer map time table (BTT) information associated with a buffer map of a peer from the peer; Confirming whether the difference value between the time information of the peer and the forced delay corresponds to the received buffer map time table information; Requesting, by the peer, a piece of fragment number corresponding to the difference value, if the fragment number matches the fragment number; And deriving the fragment number based on the received buffer map time table information if not.

The received buffer map time table information may include fragmentation time information of each piece corresponding to a time span set by the peer.

The step of deriving the fragment number may include deriving the fragment number using an average of deviations of the fragmentation time information of each of the fragments.

The fragmentation time information of each of the fragments may indicate the generation time of each of the fragments.

And requesting the peer to receive the fragment corresponding to the derived fragment number if the fragment number is derived in the deriving step.

The receiving of the buffer map time table information from the peer may comprise: transmitting a HELLO or GETBTT message to the peer; And receiving a HELLO message including the buffer map time table information or a BTT message including the buffer map time table information from the peer in response to the HELLO message or the GETBTT message.

The HELLO message may correspond to a message used by the peer to form a neighborship with the peer.

The GETBTT message may correspond to a message used by the peer to separately request the buffer map time table information from the peer.

The HELLO message and the GETBTT message of the peer may include information on a time span set by the peer.

The mandatory delay may be selected by the service provider or the peer.

A peer according to one side comprises a communication interface; And a buffer map time table (BTT) information associated with a buffer map of a peer from the peer via the communication interface, and wherein a difference value between the time information of the peer and a forced delay And if it does not match the received buffer map time table information, requests a piece of fragment number corresponding to the difference value to the counterpart peer, and if not, And derives a fragment number corresponding to the difference value based on the buffer map time table information.

The received buffer map time table information may include fragmentation time information of each piece corresponding to a time span set by the peer.

The processor may derive the slice number using an average of deviations of the fragmentation time information of each of the slices.

The fragmentation time information of each of the fragments may indicate the generation time of each of the fragments.

The processor may request the peer through the communication interface to receive a piece corresponding to the derived piece number if the piece number is derived.

Wherein the processor transmits a HELLO message or a GETBTT message to the peer via the communication interface, and transmits, in response to the HELLO message or the GETBTT message, a HELLO message including the buffer map time table information, A BTT message containing buffer map timetable information may be received via the communication interface.

The HELLO message may correspond to a message used by the peer to form a neighborship with the peer.

The GETBTT message may correspond to a message used by the peer to separately request the buffer map time table information from the peer.

The HELLO message and the GETBTT message of the peer may include information on a time span set by the peer.

The mandatory delay may be selected by the service provider or the peer.

Embodiments may achieve transport synchronization or playback synchronization between peers.

1 is a view for explaining a buffer map according to an embodiment.
2 is a flow chart illustrating communication of peers according to one embodiment.
FIG. 3 is a diagram for explaining the determination of a starting point value of a buffer map when a peer according to an exemplary embodiment does not have buffer map time table information of a peer.
FIG. 4 illustrates a HELLO message according to an embodiment of the present invention. Referring to FIG.
5 is a diagram for explaining that a peer according to an embodiment determines a starting point value of a buffer map using buffer map time table information of a peer of a peer.
6 is a diagram for explaining that a peer according to an embodiment requests a piece and receives a piece.
FIG. 7 is a diagram for explaining that a peer according to an embodiment determines a starting point value of a buffer map using buffer map time table information of a peer of a peer.
8 is a view for explaining a GETBTT message and a BTT message according to an embodiment.
9 is a flowchart illustrating a method of operating a peer according to an embodiment.
10 is a block diagram illustrating a peer according to an embodiment.

In the following, embodiments will be described in detail with reference to the accompanying drawings. However, various modifications may be made in the embodiments, and the scope of the patent application is not limited or limited by these embodiments. It is to be understood that all changes, equivalents, and alternatives to the embodiments are included in the scope of the right.

The terms used in the examples are used for descriptive purposes only and are not to be construed as limiting. The singular expressions include plural expressions unless the context clearly dictates otherwise. In this specification, the terms "comprises" or "having" and the like refer to the presence of stated features, integers, steps, operations, elements, components, or combinations thereof, But do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or combinations thereof.

Unless defined otherwise, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art to which this embodiment belongs. Terms such as those defined in commonly used dictionaries are to be interpreted as having a meaning consistent with the contextual meaning of the related art and are to be interpreted as either ideal or overly formal in the sense of the present application Do not.

In the following description of the present invention with reference to the accompanying drawings, the same components are denoted by the same reference numerals regardless of the reference numerals, and redundant explanations thereof will be omitted. In the following description of the embodiments, a detailed description of related arts will be omitted if it is determined that the gist of the embodiments may be unnecessarily blurred.

1 is a view for explaining a buffer map according to an embodiment.

Referring to Figure 1, a buffer map 100 of a peer is shown.

The buffer map 100 consists of a completed section 110, a downloading section 120, and an empty section 130.

The completion section 110 represents a section in which a peer continuously holds pieces.

The downloading section 120 represents a section in which the peer does not continuously retain pieces.

Empty section 130 represents a section (A section that will be used for buffering to prevent overriding SP by DP) to prevent overriding SP by DP.

The buffer map 100 has the following attributes that indicate a particular fragment identifier (buffermap has the following attributes that point specific fragment identifier).

CP (Completed Point): The CP indicates the end of the completion section 130 in the buffer map 100. In other words, the CP corresponds to the end of the completion section 130.

- DP (Downloading Point): DP indicates the end of the downloading section 120 in the buffer map 100. In other words, DP corresponds to the end of the downloading section 120.

- SP (Starting Point): SP indicates the identifier at the beginning of the buffer map 100 (this value points to the beginning of the buffer map). In other words, SP represents the beginning of the buffer map 100.

- PP (Play Point): PP indicates the identifier passed to the player in the buffer map 100 (This value points to the identifier in the buffer map). PP is used for flow control (this value is used for flow control with other peers).

- EP (End Point): EP indicates the end of the empty section 130.

2 is a flow chart illustrating communication of peers according to one embodiment.

Referring to FIG. 2, the communication of peers (or protocols of peers) includes a negotiation phase, a streaming phase, and an end phase.

In the negotiation phase, peer P1 performs negotiation with peer P2 (210). In the negotiation phase, peer P1 can exchange the buffer map with peer P2. Further, in the negotiation phase, the peer P1 can receive at least one of the information about the buffer map of the peer P2 from the peer P2 and the information of the buffer map time table (BTT) of the peer P2. The information on the buffer map of the peer P2 may include, for example, the SP value and the DP value of the buffer map of the peer P2. Similarly, at step 210, peer P2 may receive at least one of information about the buffer map of peer P1 from peer P1 and buffer map timetable information of peer P1. The information on the buffer map of the peer P1 may include, for example, the SP value and the DP value of the buffer map of the peer P1.

In the streaming phase, peer P1 requests 220 a piece to peer P2 and receives 230 a piece from peer P2.

In the termination phase, peer P1 terminates communication with peer P2. At this time, peer P1 sends a termination request to peer P2 to release its resources.

In an embodiment, the peer P1 may just start and there may be no Buffermap Time Table (BTT) information for the peer P2. In this case, the peer P1 can determine the initial SP value of the peer P1 itself based on the SP value of the peer P2 and the DP value of the peer P2 in the negotiation phase. The following description will be made with reference to Fig.

FIG. 3 is a diagram for explaining the determination of a starting point value of a buffer map when a peer according to an exemplary embodiment does not have buffer map time table information of a peer.

Referring to FIG. 3, a buffer map 300 of Peer 2 corresponding to peer 1's peer is shown.

PeerSP in FIG. 3 represents the SP value of the buffer map 300, peerDP represents the DP value of the buffer map 300, and peerEP represents the EP value of the buffer map 300. FIG.

Peer P1 may just start and there may be no buffer map timetable information for peer P2. In this case, the peer P1 can determine the initial SP value of the peer P1 itself based on the SP value of the peer P2 and the DP value of the peer P2, as described above. For example, the peer P1 can determine its initial SP value according to Equation 1 below.

[Equation 1]

SP = peerDP-ROUND [½ × max {(peerDP-peerSP), 1}]

In Equation (1), max denotes an operator for selecting a difference value and a larger one value between peerDP and peerSP, and ROUND denotes a rounding operator.

If the difference value between peerDP and peerSP and 1 out of 1 is greater, then the initial SP value of peer P1 can be determined by the difference value between peerDP and ROUND [½ × 1], ie, peerDP-1.

Returning to FIG. 2, in step 210, peer P1 may send peer P2 a HELLO message to peer P2 to request information about the buffer map and buffer map timetable information. Likewise, at step 210, peer P2 may send a HELLO message to peer P1 to request information about the buffer map and buffer map timetable information to peer P1. Hereinafter, the HELLO message will be described with reference to FIG.

FIG. 4 illustrates a HELLO message according to an embodiment of the present invention. Referring to FIG.

Prior to the description of FIG. 4, the HELLO message will be described. The HELLO message corresponds to a message used by a peer to form a neighborship with its peer. Table 1 below shows an example of the syntax of the HELLO message.

The peer-id indicates the identifier of the peer.

The overlay-id represents the identifier of the overlay network.

The valid-time represents the valid time of the buffer map.

The sp-index represents the starting index number of the fragment represented by the buffer map. The sp-index may correspond to the SP value described above.

cp-length indicates the length of the completed section in the buffer map starting at sp-index (buffermap beginning sp-index).

dp-index represents the starting index number of the downloading section. The dp-index may correspond to the DP value described above.

ds-length indicates the length of the downloading section.

The buffermap represents the possession status of the pieces in the downloading section. If the peer has a particular fragment, the peer sets the buffermap to 1; otherwise, the peer sets the buffermap to zero.

req-btt indicates whether the peer wants to receive the buffer map timetable.

req-btt-span is used when the peer requests a buffer map corresponding to a specific time zone. If the value of req-btt is true but req-btt-span does not exist, then the peer sends a buffer map timetable for its entire buffer map to the peer. If the peer wants to have a buffer map timetable after a certain time, the end parameter is not included in the HELLO message.

When a peer sends its HELLO message upon receipt of a HELLO message with req-btt of "true", btt is used to include the peer's buffer map timetable in the peer's HELLO message. In btt, piece-id represents the identifier of the fragment, and timestamp represents the fragmentation time of the fragment or the creation time of the fragment.

Referring to FIG. 4, Peer 1 transmits a HELLO message to Peer 2 (410). Here, the HELLO message of Peer 1 may be based on the syntax of Table 1. [ The HELLO message of Peer 1 includes, for example, the identifier of Peer 1, the identifier of the overlay network in which Peer 1 is participating, the effective time of the buffer map of Peer 1, the SP value of the buffer map of Peer 1, The DP value of the buffer map of Peer 1, the length of the downloading section in the buffer map of Peer 1, whether Peer 1 holds fragments in the corresponding downloading section, and whether Peer 1 is the buffer of Peer 2 Whether or not the user desires to receive map timetable information, or any combination thereof. If peer 1 wants a buffer map corresponding to a specific time span, the start parameter in req-btt-span can be set to a time value corresponding to the start of a specific time interval, and the end in req-btt-span The parameter can be set to a time value corresponding to the end of a specific time interval. For example, Peer 1 may set req-btt-span as shown in Table 2 below when it wants a buffer map between time value 300022 of NTP time stamp format and time value 350000 of NTP time stamp format. In other words, peer 1 can set req-btt-span as shown in Table 2 below if it wants buffer map timetable information for fragments between time value 300022 and time value 350000.

Peer 2 sends a HELLO message to peer 1 in response to the HELLO message (420). Here, the HELLO message of the peer 2 can be based on the syntax of Table 1. The HELLO message of the peer 2 includes, for example, the identifier of the peer 2, the identifier of the overlay network in which the peer 2 participates, the effective time of the buffer map of the peer 2, the SP value of the buffer map of the peer 2, The DP value of the buffer map of Peer 2, the length of the downloading section in the buffer map of Peer 2, whether Peer 2 holds fragments in the corresponding download section, and whether Peer 2 is the buffer of Peer 1 Whether or not the user desires to receive map timetable information, or any combination thereof.

In an embodiment, if it is desired for Peer 1 to receive Buffer Map time table information of Peer 2, the HELLO message of Peer 2 includes the btt of the syntax described above. For example, if the value of req-btt in the HELLO message of peer 1 is true but req-btt-span does not exist, then peer 2 identifies the identifier of each fragment in its buffer map and the fragmentation time of each fragment as its own It can be included in the HELLO message. In another example, if the value of req-btt in the HELLO message of peer 1 is true and the start parameter in the req-btt-span is 303000, then peer 2 is the identifier of each of the fragments after 303000 among all fragments in its buffer map And the fragmentation time of each of the pieces can be included in the own HELLO message. As another example, if the value of req-btt in the HELLO message of peer 1 is true and the start parameter in req-btt-span is a and the end parameter in req-btt-span is b, The identifier of each of the fragments between a and b (or fragments generated between a and b) and the fragmentation time of each of the fragments may be included in their HELLO message. Table 3 below shows an example of btt, i.e., buffer map time table information.

Peer 1 can determine its own SP value using the buffer map time table information of peer 2. The following description will be made with reference to Fig.

5 is a diagram for explaining that a peer according to an embodiment determines a starting point value of a buffer map using buffer map time table information of a peer of a peer.

Referring to FIG. 5, buffer map time table information including fragment numbers 510 (or fragment identifiers) of pieces corresponding to a time interval set by the peer P1 and fragmentation time information 520 is shown. The piece number 510 may correspond to an index number of the piece or a number that can be derived from the identifier of the piece.

Peer P1 obtains time information. The time information may be, for example, an NTP timestamp format.

The peer P1 searches the buffer map time table information of the peer P2 for the difference value between the time information and the forced delay FD, that is, the slice number (or slice identifier) corresponding to the "time information-forced delay ". Here, the magnitude or value of the forced delay is selected or determined by the service provider or peer P1. As in cases 1 and 3 shown in Fig. 5, the fragment number (or fragment identifier) corresponding to the "time information-forced delay" may not be included in the buffer map time table information of the peer P2.

<case 1>

If the FD is large, the buffer map of the peer P2 is small, or if the desired section of P1 in the buffer map of the peer P2 has already passed the "time information-forced delay", the peer P1 responds to the "time information- (Or fragment identifier) can not be found in the buffer map timetable information of peer P2. In this case, the peer P1 can infer a piece number (or piece identifier) corresponding to "time information-forced delay ". In one example, peer P1 may use an average of deviations of time stamps 520 to infer a piece number (or piece identifier) corresponding to a "time information-forced delay ". Peer P1 can determine the inferred fragment number as its own SP value. Since there is no piece to be received from the peer P2, the peer P1 terminates the connection with the peer P2 and connects with the other peer.

<case 3>

If the FD is small or the peer P2 does not retain the latest fragments, the peer P1 can not find the fragment number (or fragment identifier) corresponding to "time information-forced delay" in the buffer map timetable information of peer P2. In this case, the peer P1 may derive a piece number (or fragment identifier) corresponding to "time information-forced delay ". In one example, peer P1 may use an average of the deviations of time stamps 520 to infer the slice number (or slice identifier) corresponding to "time information-forced delay ". And, peer P1 requests fragments received by the currently connected peer. Peer P1 can also fill its buffer map in conjunction with other peers.

<case 2>

As in case 2, a piece number (or piece identifier) corresponding to "time information-forced delay" may be in the buffer map time table information of the peer P2. In the example shown in Fig. 5, the peer P1 can find the piece number 7 corresponding to "time information-forced delay" in the buffer map time table information of the peer 2. In this case, the peer P1 can determine the fragment number 7 as its own SP value. Peer P1 can ask P2 to peer a piece of piece 7. This will be described with reference to FIG.

6 is a diagram for explaining that a peer according to an embodiment requests a piece and receives a piece.

Referring to FIG. 6, the peer P1 transmits a GET message to the peer P2 (610). Step 610 corresponds to peer P1 requesting a piece to peer P2. The GET message contains the index number (or slice number) of the fragment requested by the peer P1.

Peer P2 transmits a data message to peer P1 (620). The data message may include the fragment requested by the peer P1, the index number (or fragment number) of the fragment, the size of the fragment, the generation time information of the fragment, and the like.

FIG. 7 is a diagram for explaining that a peer according to an embodiment determines a starting point value of a buffer map using buffer map time table information of a peer of a peer.

The peer described with reference to FIG. 7 corresponds to the peer P1, and the peer described with reference to FIG. 7 corresponds to the peer P2.

Peers use timetable information that is exchanged during buffer map negotiation when providing synchronized distribution. Since the source peer embeds the NTP timestamp in the DATA message when generating the fragment, the peer can grasp the approximate presentation timing. Further, the peer can grasp the buffer map time table information of the peer using the above-described HELLO message or a GETBTT message to be described later. However, unlike the server-client streaming model, P2P-based streaming has some limitations in providing live streaming. Therefore, a forced delay needs to be provided, and this delay will be selected by the service provider or the peer. If the peer has buffer map timetable information of the first peer to which it has contacted, then depending on which of the three cases it is possible to initialize the SP for synchronization between multiple peers, Can be calculated.

Case 1: If the buffer map of the peer exceeds the SP value of the peer, the initial SP value is selected using the average of the time deviations of the fragmentation time included in the buffer map timetable information of the peer peer, and "curNTPtime () Quot; FD "corresponding to the fragment number is inferred (if the buffer map of the peer already passes the selected SP value of the peer, the initial SP value is chosen using the average time of the fragmentation time included in the BTT and the fragment number corresponding to curNTPtime () - FD is inferred). Here, "curNTPtime ()" represents time information of the NTP time stamp format. In other words, if the peer's desired interval in the peer's buffer map of the peer has already passed "curNTPtime () - FD", the peer will see the time difference of the fragmentation time contained in the "curNTPtime Quot; curNTPtime () - FD "by using at least one of the average of &quot; curNTPtime () - FD &quot; In case 1, the peer has no data to receive from its peer, so it terminates the connection with the peer and connects with another peer to receive the data. The description of the case 1 described with reference to FIG. 5 can be applied, and thus a detailed description will be omitted.

case 2: If there is a fragment selected as the SP value of the peer, the peer begins to request a fragment from the peer beginning with the corresponding SP value. In other words, the peer can use the buffer map timetable information of the peer to check if the fragment having the same fragmentation time information as "curNTPtime () - FD" is in the buffer map of the peer. Here, if there is a corresponding fragment, the fragment number of the fragment, that is, the fragment number corresponding to "curNTPtime () - FD" can be determined as its SP value, and a fragment corresponding to the corresponding SP value can be requested to the peer . The description of the case 2 described with reference to FIG. 5 can be applied, and thus a detailed description thereof will be omitted.

Case 3: The peer uses an average of the time deviations of the fragmentation time included in the buffer map timetable information of the peer to derive the fragment number corresponding to "curNTPtime () - FD " (It uses the average of the fragmentation time deviations included in the BTT to derive the fragment number corresponding to curNTPtime () - FD and requests the fragments received by the currently connected peer). The peer sets the derived fragment number to its own SP value. However, since the peer does not have a fragment corresponding to the SP value, the peer can request the peer to receive the fragment from the other peers. A peer can also associate with other peers to fill its buffer map. The description of the case 3 described with reference to FIG. 5 may be applied, and thus a detailed description thereof will be omitted.

8 is a view for explaining a GETBTT message and a BTT message according to an embodiment.

Prior to the description with reference to FIG. 8, a GETBTT message and a BTT message will be described.

The GETBTT message is used to separately request buffer map timetable information of the peer peer. Table 4 below shows an example of the syntax of the GETBTT message.

overlay-id, req-btt, and req-btt-span have been described above, so a detailed description will be omitted. The BTT message is used to provide buffer map timetable information to the requesting peer when the peer receives a GETBTT message. Table 5 below shows an example of the syntax of the BTT message.

Since the overlay-id, peer-id, and btt have been described above, a detailed description will be omitted.

Referring to FIG. 8, the peer P1 transmits a GETBTT message to the peer P2 (810). The GETBTT message may be based on the syntax of Table 4.

The peer P2 transmits a BTT message to the peer P1 (820). The BTT message may be based on the syntax of Table 5.

As described with reference to FIG. 2, the communication between the peer P1 and the peer P2 includes a negotiation phase and a streaming phase. The HELLO message illustrated in FIG. 4 is used during the negotiation phase, and the GETBTT message and the BTT message are used in the streaming phase. In other words, the peer P1 can request the peer P2's buffer map time table information using the GETBTT message in the streaming phase. The peer P2 can transmit its buffer map time table information to the peer P1 in the streaming phase using the BTT message.

9 is a flowchart illustrating a method of operating a peer according to an embodiment.

Each of the peer and counterpart peer described with reference to FIG. 9 corresponds to each of the above-mentioned peer P1 and P2.

Referring to FIG. 9, a peer receives buffer map time table information associated with a buffer map of a peer from a peer (910). The received buffer map time table information may include fragmentation time information of each piece corresponding to a time interval that the peer desires (or set).

The peer confirms whether the difference value between the time information and the forced delay matches the received buffer map time table information (920). For example, the peer can check whether the fragmentation time information equal to the difference value is in the received buffer map time table information.

If the difference value matches the received buffer map time table information, the peer requests a piece of the piece number corresponding to the difference value to the peer (930). Step 930 corresponds to case 2 described with reference to FIG. 5 or FIG.

If the difference value does not match the received buffer map time table information, the peer derives a slice number corresponding to the difference value based on the received buffer map time table information (940). The peer can determine the derived fragment number as its own SP value. Step 940 corresponds to case 3 described with reference to FIG. 5 or FIG.

1 through 8 can be applied to the matters described with reference to FIG. 9, so that a detailed description will be omitted.

10 is a block diagram illustrating a peer according to an embodiment.

10, a peer 1000 includes a communication interface 1010 and a processor 1020. [

Processor 1020 receives buffer map time table information associated with the buffer map of the peer from the peer via communication interface 1010.

The processor 1020 determines whether the difference value between the time information of the peer 1000 and the forced delay matches the received buffer map time table information.

Processor 1020 requests a relative peer for a piece of piece number corresponding to the difference value if the corresponding difference value matches the received buffer map time table information.

If the difference value does not match the received buffer map time table information, the processor 1020 derives a piece number corresponding to the difference value based on the received buffer map time table information.

1 through 9 can be applied to the matters described with reference to FIG. 10, so that a detailed description thereof will be omitted.

The method according to an embodiment may be implemented in the form of a program command that can be executed through various computer means and recorded in a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, and the like, alone or in combination. The program instructions to be recorded on the medium may be those specially designed and configured for the embodiments or may be available to those skilled in the art of computer software. Examples of computer-readable media include magnetic media such as hard disks, floppy disks and magnetic tape; optical media such as CD-ROMs and DVDs; magnetic media such as floppy disks; Magneto-optical media, and hardware devices specifically configured to store and execute program instructions such as ROM, RAM, flash memory, and the like. Examples of program instructions include machine language code such as those produced by a compiler, as well as high-level language code that can be executed by a computer using an interpreter or the like. The hardware devices described above may be configured to operate as one or more software modules to perform the operations of the embodiments, and vice versa.

The software may include a computer program, code, instructions, or a combination of one or more of the foregoing, and may be configured to configure the processing device to operate as desired or to process it collectively or collectively Device can be commanded. The software and / or data may be in the form of any type of machine, component, physical device, virtual equipment, computer storage media, or device , Or may be permanently or temporarily embodied in a transmitted signal wave. The software may be distributed over a networked computer system and stored or executed in a distributed manner. The software and data may be stored on one or more computer readable recording media.

Although the embodiments have been described with reference to the drawings, various technical modifications and variations may be applied to those skilled in the art. For example, it is to be understood that the techniques described may be performed in a different order than the described methods, and / or that components of the described systems, structures, devices, circuits, Lt; / RTI &gt; or equivalents, even if it is replaced or replaced.

Therefore, other implementations, other embodiments, and equivalents to the claims are also within the scope of the following claims.

Claims (18)

In a method of operating a peer,
Receiving buffer map time table (BTT) information associated with a buffer map of a peer from the peer;
Confirming whether the difference value between the time information of the peer and the forced delay corresponds to the received buffer map time table information;
Requesting, by the peer, a piece of fragment number corresponding to the difference value, if the fragment number matches the fragment number; And
Deriving the fragment number based on the received buffer map time table information, if not,
/ RTI &gt;
How the peer works.
The method according to claim 1,
Wherein the received buffer map time table information includes fragmentation time information of each piece corresponding to a time span set by the peer,
How the peer works.
3. The method of claim 2,
Wherein deriving the piece number comprises:
Deriving the slice number using an average of deviations of the fragmentation time information of each of the fragments
/ RTI &gt;
How the peer works.
3. The method of claim 2,
Wherein the fragmentation time information of each of the fragments indicates a generation time of each of the fragments,
How the peer works.
The method according to claim 1,
If the fragment number is derived in the derivation step, requesting the peer to receive a piece corresponding to the derived fragment number
&Lt; / RTI &gt;
How the peer works.
The method according to claim 1,
Wherein the step of receiving the buffer map time table information from the counterpart peer comprises:
Transmitting a HELLO message or a GETBTT message to the peer; And
Receiving, in response to the HELLO message or the GETBTT message, a HELLO message including the buffer map time table information or a BTT message including the buffer map time table information from the counterpart peer
/ RTI &gt;
How the peer works.
The method according to claim 6,
The HELLO message corresponds to a message used by the peer to form a neighborship with the peer,
Wherein the GETBTT message corresponds to a message used by the peer to separately request the buffer map timetable information from the peer,
How the peer works.
The method according to claim 6,
Wherein the HELLO message and the GETBTT message of the peer include information on a time span set by the peer,
How the peer works.
The method according to claim 1,
Wherein the forced delay is selected by a service provider or the peer,
How the peer works.
In the peer,
Communication interface; And
Receiving a buffer map time table (BTT) information associated with a buffer map of a peer from the peer via the communication interface, and determining whether a difference value between the time information of the peer and a forced delay And if so, requests a piece of fragment number corresponding to the difference value to the counterpart peer, and if it does not match the received buffer map time table information, A processor for deriving a fragment number corresponding to the difference value based on the buffer map time table information,
/ RTI &gt;
Peer.
11. The method of claim 10,
Wherein the received buffer map time table information includes fragmentation time information of each piece corresponding to a time span set by the peer,
Peer.
12. The method of claim 11,
Wherein the processor derives the slice number using an average of deviations of the fragmentation time information of each of the slices,
Peer.
12. The method of claim 11,
Wherein the fragmentation time information of each of the fragments indicates a generation time of each of the fragments,
Peer.
11. The method of claim 10,
Wherein the processor requests the peer through the communication interface to receive a fragment corresponding to the derived fragment number if the fragment number is derived,
Peer.
11. The method of claim 10,
Wherein the processor transmits a HELLO message or a GETBTT message to the peer via the communication interface, and transmits, in response to the HELLO message or the GETBTT message, a HELLO message including the buffer map time table information, Receiving via the communication interface a BTT message including buffer map timetable information,
Peer.
16. The method of claim 15,
The HELLO message corresponds to a message used by the peer to form a neighborship with the peer,
Wherein the GETBTT message corresponds to a message used by the peer to separately request the buffer map timetable information from the peer,
Peer.
16. The method of claim 15,
Wherein the HELLO message and the GETBTT message of the peer include information on a time span set by the peer,
Peer.
11. The method of claim 10,
Wherein the forced delay is selected by a service provider or the peer,
Peer.

Images