Packet format of network abstraction layer unit, and algorithm and apparatus for video encoding and decoding using the format, QoS control algorithm and apparatus for IPv6 label switching using the format

Abstract

The construction method of NALU (Network Abstraction Layer Unit) for IPv6 label switching and its using algorithms of video encoding, QoS control, and decoding are provided. According to an embodiment of the present invention, the NALU format is composed of the NALH (Network Abstraction Layer Header) including the label and the NAL (Network Abstraction Layer) payload. Here, the label is determined based on layer information which is combination of a spatial scalable level, a temporal scalable level, and a quality scalable level of the encoded data. The decoder uses the label to decide which one of multiple decoding modules is used to decode the current NAL payload. Moreover, the label can be included in the packet header so that the MANE (Media Aware Network Element) can use the label to decide whether to forward the packet or drop it. For example, the label in the packet header can be used for QoS control of video service by using the flow label field in IPv6 packet header. The IPv6 router can identify priority of the video packet by using the 20 bit long flow label, into which the label in NALH can be inserted. According to the embodiment, the MANE assumed in the MPEG and JVT (Joint Video Team) can be implemented effectively.

Claims

1. A method for delivering a packet by a packet generation apparatus, comprising the steps of: generating the packet including an identification information identifying a flow; signaling a mapping information between the identification information and at least one variable that characterizes the flow to a receiver or network intermediate node when a session starts or changes session information; and delivering the generated packet to the receiver or the network intermediate node, wherein the at least one variable indicates a scalable layer of one or more scalable layers to which the flow is related, each scalable layer of the one or more scalable layers being associated with a corresponding spatial level, a corresponding quality level, and a corresponding view number, and wherein any packets associated with a particular value of the variable are associated with a corresponding particular scalable layer and include pictures having a view, size, and quality corresponding to the particular scalable layer.

2. The method of claim 1, wherein the identification information is included in a packet header.

3. The method of claim 1, wherein the identification information is included in a flow label of a packet header.

4. The method of claim 1, wherein the mapping information is information made by mapping a combination of several variables characterizing one flow to an arbitrary number by each combination, in order to facilitate identification of the flow.

5. The method of claim 1, wherein the identification information includes information indicating significance of the flow.

6. The method of claim 5, wherein the network intermediate node determines whether or not to forward the packet according to significance information included in the identification information.

7. The method of claim 6, wherein the network intermediate node has a different priority related to discarding a packet corresponding to at least one condition of network-related condition including channel condition, terminal-related condition and user-related condition according to the significance information included in the identification information.

8. The method of claim 6, wherein the network intermediate node determines whether or not to forward using a extraction map, and the extraction map includes information indicating whether or not to forward the packet under a predetermined condition according to the extracted label.

9. The method of claim 5, wherein the network intermediate node performs QoS (Quality of Service) control using the significance information included in the identification information.

10. The method of claim 1, wherein the identification information includes information indicating whether the packet is included in a flow to which resources are allocated when the session starts.

11. The method of claim 1, wherein the packet includes a layer information.

12. The method of claim 11, wherein the layer information includes at least one of a spatial scalable level, a temporal scalable level, and a quality scalable level of the packet.

13. The method of claim 1, wherein the mapping information is exchanged when a session starts or changes session information, such that the network intermediate node or the receiver processes the packet by the flow.

14. The method of claim 1, wherein the packet includes a view identification information.

15. A method for receiving a packet by a packet reception apparatus, comprising the steps of: receiving a mapping information between an identification information identifying a flow and at least one variable that characterizes the flow, from a transmitter or a network intermediate node when session starts or changes session information; receiving the packet including the identification information; and decoding the packet according to the identification information, wherein the at least one variable indicates a scalable layer of one or more scalable layers to which the flow is related, each scalable layer of the one or more scalable layers being associated with a corresponding spatial level, a corresponding quality level, and a corresponding view number, and wherein any packets associated with a particular value of the variable are associated with a corresponding particular scalable layer and include pictures having a view, size, and quality corresponding to the particular scalable layer.

16. The method of claim 15, wherein the decoding includes processing the packet by the flow using the identification information.

17. The method of claim 16, wherein the decoding includes designating a decoder module or a buffer by the flow, and decoding the packet through the decoder module or the buffer designated for the flow, according to the identification information.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) FIG. 1 is a conceptual diagram of relationship between VCL (Video Coding Layer) and NAL (Network Abstraction Layer) as in the H.264/AVC standard.

(2) FIG. 2 is a block diagram to show the NALU format proposed in the current SVC standard.

(3) FIG. 3 is a block diagram to show the conventional procedures to decide whether to forward a NALU (or a packet of a bitstream) in the MANE.

(4) FIG. 4 is a block diagram for NALU format as the first embodiment of the present invention.

(5) FIG. 5 is a block diagram for NALU format as the second embodiment of the present invention.

(6) FIG. 6 is a block diagram for the SVC decoder structure as an embodiment of the present invention.

(7) FIG. 7 is a block diagram for the MANE as an embodiment of the present invention. The MANE decides whether to forward a NALU (or a packet of a bitstream).

(8) FIG. 8 is a block diagram for the procedures which are procedures for the MANE to decide whether to forward a NALU (or a packet of a bitstream) in the MANE as an embodiment of the present invention.

(9) FIG. 9 is a flow chart for the decoder to parse NALU's of the format defined in FIG. 4 or 5.

(10) FIG. 10 shows an example to map 14 NALU types in the H.264/AVC standard into 14 labels.

(11) FIG. 11 shows a pseudo-code to decode according to labels parsed out of the format defined in FIG. 4 or 5.

(12) FIG. 12 shows how to multicast video stream in heterogeneous network.

(13) FIG. 13 shows how much data should be read for packet switching by using IPv6 protocol.

(14) FIG. 14 shows how much data should be read for label switching according to an embodiment of the present invention.

(15) FIG. 15 shows an example of the flow label in IPv6 header as an embodiment of the present invention.

BEST MODE FOR CARRYING OUT THE INVENTION

(16) An embodiment of the present invention is explained in detail by using attached figures as follows.

(17) FIG. 4 is a block diagram for NALU format as the first embodiment of the present invention. In FIG. 4, upper part shows the conventional NAL format while the lower part shows NALU format as the first embodiment of the present invention.

(18) According to FIG. 4, the NALU format as an embodiment of the present invention includes SNALH (label type NALH) and NAL payload. Among them, NAL payload is the same as that in the conventional format. Therefore, as an embodiment of the present invention, the conventional NALH in a NALU is replaced by SNALH by using a certain size of label. This SNALH can be one byte long in which case number of possible labels is 28=256 or so.

(19) In more detail, as an embodiment of the present invention, a combination of NAL type, Priority_id for priority, Dependency_id for spatial scalable level, Temporal_level for temporal scalable level, and Quality_level for quality scalable level which the conventional NALH includes, represents a set among NALH sets of limited number, and is converted into a label to discern the sets. That is, as an embodiment of the present invention, a set of NALH's with the same combination is mapped into a label one by one basis. Therefore, one unique label is assigned to any combination of NAL type, Priority_id for priority, Dependency_id for spatial scalable level, Temporal_level for temporal scalable level, and Quality_level for quality scalable level.

(20) Like this, as an embodiment of the present invention, SNALH in NALU includes a label corresponding to various values in the conventional NALH. This embodiment of the present invention is based on the fact that finite number of NALH sets exists during a video session or stored video sequence, and the same number of labels is used in the SNALH. For example, if number of NALH sets is less than 250, the conventional NALH can be replaced by 1 byte long SNALH.

(21) FIG. 5 is a block diagram for NALU format as the second embodiment of the present invention. In FIG. 5, upper part shows the conventional NAL format while the lower part shows NALU format as the second embodiment of the present invention.

(22) According to FIG. 5, the NALU format as an embodiment of the present invention includes NALU type, SNALH (label type NALH) and NAL payload. Among them, NAL payload is the same as that in the conventional format. Therefore, as an embodiment of the present invention, the conventional NALH in a NALU is replaced by SNALH by using a certain size of label. This SNALH can be one byte long in which case number of possible labels is 28=256 or so.

(23) In more detail, as an embodiment of the present invention, at first, NALU type field in the conventional NALU format is unchanged. And, a combination of NAL type, Priority_id for priority, Dependency_id for spatial scalable level, Temporal_level for temporal scalable level, and Quality_level for quality scalable level which the conventional NALH includes, represents a set among NALH sets of limited number, and is converted into a label to discern the sets. That is, as an embodiment of the present invention, a set of NALH's with the same combination is mapped into a label one by one basis. Therefore, one unique label is assigned to any combination of NAL type, Priority_id for priority, Dependency_id for spatial scalable level, Temporal_level for temporal scalable level, and Quality_level for quality scalable level.

(24) Like this, as an embodiment of the present invention, SNALH in NALU includes a label corresponding to various values (P, D, T, Q) in the conventional NALH. This embodiment of the present invention is based on the fact that finite number of NALH sets exists during a video session or stored video sequence, and the same number of labels is used in the SNALH. For example, if number of NALH sets is less than 250, the conventional NALH can be replaced by 1 byte long SNALH.

(25) And according to the format in FIG. 4 or 5, one-to-one mapping of a label of SNALH and a NALH set which is a combination of P, D, T, and Q values can be defined in a mapping table. The decoder and encoder have the same mapping table. There is no constraint how to have the same mapping table. For example, the encoder may send the mapping table with encoded video data to the decoder, or the encoder may send only information about the mapping table to the decoder. In the latter case, the encoder and decoder are expected to have several mapping tables already, and the encoder sends an identifier to identify a table, and the decoder retrieves the mapping table identified by the identifier among the mapping tables.

(26) The method for the encoder and decoder to use the mapping table is as follows. For example, by using the mapping table, the encoder generates a NALU with a label, as in the format mentioned in the first or second embodiment of the present invention. Then, the decoder identifies scalable layer of a NALU by using the mapping table and the label in the NALH. The remained payload is sent to the decoder module appropriate to the layer identified by the label.

(27) FIG. 6 is a block diagram for the SVC decoder structure as an embodiment of the present invention. In the following, although the present invention is explained by using the case of the SVC standard, it is obvious for person in the art that the embodiment of the invention can be applied to the other type of encoder (for example, MVC encoder).

(28) In FIG. 6, the SVC encoder 100 includes the video encoding module 110 and the NALU generator 120. Even though the video encoding module 110 and the NALU generator 120 are depicted as separate modules in FIG. 6, they are separated logically according to their functions, but they could be implemented either separately or in one body. And, even though only the video encoding module and the NALU generator are included in FIG. 6, the other modules in the SVC encoder are omitted because they are irrelevant to the explanation.

(29) The video encoding module is used to perform encoding processes (transformation and quantization, etc.) to generate encoded data from original image, satisfying the SVC standard. The SVC encoding module includes the base layer encoding module, and multiple enhanced layer encoding modules. As result of encoding, the video encoding module, also, generates information representing NAL type, Dependency_id (D) for spatial scalable level, Temporal_level (T) for temporal scalable level, and Quality_level (Q) for quality scalable level.

(30) The NALU generator is a module to generate NALU by using information about NALU type, D, T, and Q given by the video encoding module. At this time, priority of NALU can be defined. More than one priority can be defined for a combination of D, T, and Q. The NALU generator 120 can generate NALU in the format depicted in FIG. 4 or 5. For this, the NALU generator includes NALU generator 120, mapping module 122, and NALU composer 124.

(31) The mapping module 122 is used to decide a label for SNALH according to P, D, T, and Q values. In order to decide a label, the mapping module 122 uses a stored mapping table or that produced conditionally for a video sequence or a video session. And, the NALU composer 124 composes a NALU by using encoded data provided by the video encoding module 110 and label given by the mapping module 122 as depicted in FIG. 4 or 5. Generated NALU is sent or stored in storage with or without the mapping table (or information to identify a mapping table).

(32) FIG. 7 is a block diagram for the MANE (media aware network element) as an embodiment of the present invention. The MANE includes the NALU extractor (packet extractor or bitstream extractor) which decides whether to forward a NALU (or a packet of a bitstream). The NALU extractor mentioned above is located in the middle of network. And the NALU extractor extracts and forwards NALU's which satisfy a certain condition (among all layers in an SVC, certain layers requested by the receiver). In FIG. 7, the NALU extractor 200 as an embodiment of the present invention includes the label parser 210 and the forwarding decision module 220.

(33) The label parser 210 parses a label from a NALU (with the format in FIG. 4 or 5) received from the encoder. Therefore, as an embodiment of the present invention, the label parser 210 does not need to parse information of NAL type, Dependency_id(D) for spatial scalable level, Temporal_level(T) for temporal scalable level, and Quality_level(Q) for quality scalable level.

(34) The forwarding decision module 220 decides whether to forward each NALU or not based on its extraction table and the label parsed by the label parser 210. The extraction table is a table of labels with which bitstreams (NALU's) are allowed to be forwarded. Therefore, the extractor which is an embodiment of the present invention, does not need to parse P, D, T, and Q values of each NALU, but, by using only a label and the extraction table, can decide whether to forward corresponding NALU or not. For each label, information about forwarding or not can be indicated by a bit.

(35) The extraction table can be received from the server or can be constructed in the NALU extractors (for example, MANE). Labels in the extraction table may correspond to those in the mapping table in the encoder. According to various conditions of network, the terminal, and/or the user, more than one extraction table may be used. Moreover, for a multicast session, different NALU extractors can be used in different branches in the network.

(36) FIG. 8 is a block diagram for the procedures in the MANE as an embodiment of the present invention. They are procedures for the MANE to decide whether to forward a NALU (or a packet of a bitstream). As in FIG. 8, the NALU extractor parses a label from each received or retrieved NALU. And, it sees if the extraction indicator for the parsed label value is ‘1’ in the extraction table (S22). Here, if the extraction indicator is ‘1’, the corresponding NALU is forwarded while if the extraction indicator is ‘0’, the corresponding NALU is discarded. Therefore, as an embodiment of the invention, the corresponding NALU is discarded in Step S23, while in Step S24 the corresponding NALU is forwarded to the following network entity for the decoder.

(37) FIGS. 7 and 8 show the apparatus and method of NALU extraction in the entities in the middle of network. Normally, however, media data is transmitted over certain wired and wireless networks as stream of packets, or just bitstream differently from stream of NALU's. In this case, the above mentioned labels can be included in packet headers or in bitstream. And, the network entities such as the MANE's parse labels out of packet headers or bitstream to decide whether to forward or not.

(38) FIG. 9 is a flow chart for the decoder to parse NALU's of the format defined in FIG. 4 or 5. In FIG. 9, the decoder parses (S31) a label from each NALU received from transmission network or retrieved from stored contents. For example, the decoder reads label values by parsing SNALH in NALU. And, the decoder sees (S32) D, T, and Q values corresponding to the parsed label value by using the mapping table mentioned above. The mapping table can be received with NALU's or can be already stored in the decoder. And, the decoder forwards NAL payload to a video decoding module corresponding to the D, T, and Q values. Each video decoding module decodes (S33) incoming encoded data, that is, the NAL payload.

(39) As another embodiment of the present invention, the decoder may have another NALU extractor explained in FIG. 7 in addition to decoding modules. In this case, the decoder decodes only NALU's allowed by the NALU extractor.

(40) Hereinafter, above-described embodiments of the present invention are explained in various view points.

(41) <NALH Compression Method>

(42) During a video session temporarily, or when a video sequence is stored, each 3-5 byte long NALH as in the JVT standard is mapped and replaced by a SNALH (Shortened NALH). The same mapping table is used in the encoder and the decoder. When an encoded video sequence is stored, the mapping table is, also, to be stored.

(43) As an embodiment of the present invention, in order to control QoS adaptively, the MANE should have the extraction table for extracting dependently on labels of NALU's. The extraction table can be received from the server or the client, or can be constructed in the MANE by itself. If the MANE by itself constructs an extraction table, it should have the above-mentioned mapping table. In the NALU format according to an embodiment of the present invention, a set of P, D, T, and Q values are replaced by a label if a video session or a stored video sequence is composed of finite NALU sets of the same P, D, T, and Q values. For example, the number of sets is less than 250, the indicator for each set can be compressed into 8 bits.

(44) For example, suppose that a video sequence is encoded with 3 spatial scalable layers, each of which is scaled into 2 temporal scalable layers, each of which is scaled into 4 quality layers. Then, there are 24 (3×2×4) different layers, which can be identified by 24 different labels.

(45) If a layer is composed of two streams of NALUS with different priority_ID's, the layer needs 2 different labels. Here, ‘a stream of the same layer’ means stream of NALU's with the same dependency_ID, temporal_level, and quality_level (DTQ in short). To the contrary, if a P value is used for different DTQ sets, each set should have its own label.

(46) The encoder and the decoder should have the mapping table between labels and DTQ sets. Even though labels can be constructed arbitrarily, if possible, it is better to make labels to indicate DTQ values of the H.264/AVC standard without the mapping table.

(47) 1 byte long SNALH

(48) During a video session temporarily, or when a video sequence is stored, if number of layers (or sets of NALH's) is finite, the same number of labels is determined and used as SNALH's. According to an embodiment, under assumption that the number is less than 250, NALH can be compressed into 8 bits. An embodiment of 1 byte long SNALH is shown in FIG. 4.

(49) 2 byte long SNALH

(50) In order to keep compatibility to the H.264/AVC standard, the first byte is the same as that in the standard at the moment of January 2006. The remained NALH bytes are compressed into a byte long label. An embodiment of 2 byte long SNALH is shown in FIG. 5.

(51) Extended usage of SNALH

(52) ‘Extended usage of SNALH’ means to use SNALH in various purposes differently from above-mentioned embodiment of the present invention. There are ‘NALH extension,’ ‘scalable methodology extension,’ ‘media extension,’ and ‘protocol extension.’

(53) ‘NALH extension’ method keeps the conventional NALH format and adds the SNALH. That is, in FIGS. 4 and 5, label is attached in the front of the conventional NALU with full NALH. According to this method, even though NALH becomes larger by adding SNALH, one can enjoy merits of SNALH in reduction of complexity in the decoder and the MANE.

(54) ‘Scalable methodology extension’ means to allow more combinations of DTQ than those of the conventional standard. Since D, T, and Q are represented by 3, 3, and 2 bits in the conventional standard, numbers of possible layers are 8, 8, and 4, respectively. According to an embodiment of the current invention, since labels are defined by the mapping table, number of layers can be freely extended if the entities engaged in a service agree together.

(55) ‘Media extension’ means to apply the labels proposed by an embodiment of the current invention to media streams other than video streams such as audio stream. In an MVC (Multi-View Video Coding) session, labels can be assigned to views. In addition, labels can be assigned to streams of FEC (Forward Erasure Correction) packets for individual views or layers. If network is packet-lossy, parity packet streams are forwarded, while they are discarded in loss-free network.

(56) ‘Protocol extension’ means to apply the above-mentioned labels to other protocols with or without slight modification. As an embodiment, SNALH in FIG. 4 or 5 can be copied into 20 bit long flow label in IPv6 header as well as into label field in MPLS.

(57) Method to Guarantee Compatibility to H.264/AVC

(58) The SNALH in FIG. 5 is compatible to the H.264/AVC standard. The SNALH in FIG. 4 becomes compatible to the H.264/AVC standard, if only 14 labels are used as shown in FIG. 10. If NRI and F values are fixed for 14 NAL types related to H.264/AVC, 14 labels are determined. Therefore, labels other than above-mentioned 14 labels should be used for streams other than SVC streams.

(59) Compatibility to SEI Messages

(60) Scalability_info and layer_ID delivered by using SEI (Supplemental Enhancement Information) message can be used as labels. In this case, the encoder and the decoder do not need another labels.

(61) <Implementation of the Encoder>

(62) The decoder should be informed of the information that the encoder uses the SNALH. The information can be informed by using SPS(Sequence Parameter Set). In case of storing the encoded sequence, this information that the SNALH is used should be stored.

(63) Storing and Transmitting the Label Mapping Table

(64) Labels are assigned as many as number of streams (sets of NALU's) discerned in a video sequence. Relationship to map streams to labels is constructed as the mapping table. The mapping table is constructed to assign all or partial sets of NALH's to labels. As an embodiment, this information can be delivered to the decoder by using control data such as SPS or PPS (Picture Parameter Set). As an embodiment, labels can be serial number for layers of SVC or views of MVC.

(65) Generation of NALU

(66) In every NALU, the conventional long NALH is replaced by the SNALH.

(67) <Implementation of the Decoder>

(68) The decoder should be informed of the information that the encoder uses the SNALH. The information can be informed by using SPS. In case of playing the encoded sequence, this information that the SNALH is used should be read and properly parsed.

(69) Constructing the Label Mapping Table

(70) During decoder initialization period, the mapping given by the encoder is read. The decoder initializes the video decoding modules as many as number of streams to be decoded, and sets up relationship to labels respectively. At this moment, referencing relationship between SVC layers and MVC views, is also established.

(71) NALU Processing

(72) Upon receiving a NALU, the decoder parses the SNALH as in FIG. 4 or 5, and stores the payload of the NALU is stored in the buffer of the corresponding decoding module. In the conventional standard, since decision of decoding module becomes possible after parsing and evaluating D, T, and Q values, it is much more complex than that of the present invention. The algorithm for the decision is depicted in FIG. 11. FIG. 11 shows that the decoder can deliver the payload to the proper decoding module just by evaluating a single label in the SNALH, but not by using multiple values such as D, T, and Q of the conventional NALH.

(73) <Implementation of the MANE (Media Aware Network Element)>

(74) According to an embodiment of the present invention, when the MANE decides which streams it forwards, it depends on its extraction table. Therefore, according to an embodiment of the present invention, the MANE does not need to evaluate P, D, T, and Q values, but it decides whether to discard or not by using 1 bit information for every label in the extraction table. This extraction table is received from the server or the client, or is generated in the MANE. The MANE may have more than one extraction table as many as differentiable conditions of network, terminals, and users. For a multicast session, different extraction tables are placed in the network branches as shown in FIG. 12. FIG. 12 shows that 3 MANE's have 3 different extraction tables, respectively. It is an example. For simplicity, labels are denoted as 4 bit long values and there are 4 different streams. For example, in MANE3, NALU's with Label 0101 are discarded while NALU's with Labels 1101, 0111, and 0001 are forwarded.

(75) Construction of the Extraction Table

(76) The MANE receives information that the server uses the SNALH during initialization period of a video session. In order to construct an extraction table, the MANE may receive it from the server or the client, or may generate the extraction table by itself by using control information received from intelligent routers or the base station of wireless network. Types and range of layers or views to be forwarded are determined by the user's preference, terminal capability, and network condition. The terminal capability includes display resolution and allowable channel bandwidth. Even during a service session, the extraction policy in the extraction table can be modified adaptively to time varying user's preference, terminal capability, and network condition. It is desirable that this decision policy is received from the server. The server may send a modified extraction table to the NAME.

(77) As an example in FIG. 12, in case that there are 4 labels for 4 different layers, the server sends 1111 to MANE1 on the way to HDTV terminals so that NALU's of all labels are forwarded, while the server sends 0001 to MANE2 on the way to mobile phones so that only NALU's with Label 0001 corresponding to the lowest layer, that is, Base layer are forwarded. At the same time, the server sends 0111 to MANE3 on the way to laptop computers so that NALU's of 3 lowest labels are forwarded. According to an embodiment of the present invention, bit ‘0’ or ‘1’ value of the most significant bit indicates whether NALU's with the highest label is forwarded or not, and so on.

(78) It is desirable that the server sends a modified extraction table if the client requests to change service level during the service session. It is desirable that the MANE modifies the extraction table if channel (or network) condition is changed to certain amount. However, if the MANE is not intelligent enough to perform modification, the server or the client monitoring channel condition (available bitrate, packet loss ratio) sends a modified extraction table to the MANE.

(79) Extraction Procedure

(80) If the SNALH is used, the MANE decides extraction based on labels in the SNALH. However, this approach causes L3 (network layer) routers burden that they deal with application layer such as video data, and hurts the principle of independency between protocol layers. Therefore, it is desirable to insert the above-mentioned label into the flow label in the IPv6 header so that the routers only evaluate IP headers for decision of extraction.

(81) FIGS. 3 and 8 compare extraction decision procedures between the conventional method and an embodiment of the present invention. As shown in FIGS. 3 and 8, conventionally NALU extraction is decided based on 4 values, while it is decided based on only a label in the present invention.

(82) In more detail, for SVC if the conventional method is used as shown in FIG. 3, 4 values (P, D, T, and Q) are parsed and used for 4 steps of extraction decision, while if the method of the present invention is used as shown in FIG. 8, regardless of meaning of value, the MANE mechanically decides extraction based on one value, that is, the label of every NALU. In FIG. 8, Step S22 is an example to use the function B=map[label 1] to decide extraction, so that if the value ‘B’ is 1, the NALU's with Label 1 are forwarded, while the value ‘B’ is 0, the NALU's with Label 1 are discarded

(83) QoS Control for IPv6 Label Switching

(84) When we transmit video data encoded by using MPEG-2 or H.264, significance of video packets is different from each other. In order to control quality of video service effectively, one should discern difference of significance of video packets. The IPv6 routers discern the difference in two different modalities such as packet switching modality and label switching modality. As for packet switching case, the routers should read 5 turples such as destination address, source address, destination port number, source port number, and protocol in order to select pre-defined service policy of corresponding packet. 5 turples are shown as shaded region in FIG. 13. It makes the processing time of every packet long, and hurts the independency principle between network protocol layers. For port numbers are issues of the transport layer.

(85) According to an embodiment of the present invention, label switching is used to eliminate the problem. During initialization period of a session, temporary labels are assigned, and they are used only for the session. The label is inserted in the flow label which is shaded region in FIG. 14. According to the method, IPv6 is able to tell the session that every packet is included in and significance of every packet by evaluating only the flow label in the IPv6 header. This method resembles the packet routing (or switching) method of ATM (Asynchronous Transfer Mode) or MPLS (Multiple Protocol Label Switching).

(86) Label in label switching includes both path information and resource information for every packet stream. After call setup, path and significance of every packet is identified by using the label. The conventional packet switching requires the router to read about 600 bits (including IPv6 header and video layer header) while according to an embodiment of the present invention, it is possible the router to identify path and significance by evaluating 20 bit long flow label.

(87) FIG. 15 shows an example of the flow label in IPv6 header as an embodiment of the present invention. According to FIG. 15, 8 bit long path identifier is inserted from the 5th bit in 20 bits while 8 bit long resource identifier (SNALH) is inserted from the 13th bit in 20 bits. The resource identifier can be replaced by SNALH. If a video session includes multiple streams of packets of different significance, path identifiers are all the same while resource (or significance) identifiers are assigned differently from each other streams.

(88) Label Swapping

(89) In the architecture including many MANE's along transmission path, the labels used in each MANE could be different. In this case, the precedent MANE may swap its labels to those used by following MANE. The swapping could be performed in the server before transmission after parsing every NALU.

(90) The present invention has been explained with reference to the embodiments which are merely exemplary. It will be apparent to those skilled in the art that various modifications and variations can be made in the present invention without departing from the spirit or scope of the invention. Thus, it is intended that the present invention cover modifications and variations of this invention provided they come within the scope of the appended claims and their equivalents.

INDUSTRIAL APPLICABILITY

(91) The present invention is useful in image processing industry which includes video encoding and decoding. And, it, also, can be used for transmission of encoded video over telecommunication networks and or so, especially it is useful for packet switched networks.