Method and apparatus for encoding or decoding image, and medium

Abstract

The invention provides a method, a device and a medium for encoding or decoding an image. The method includes receiving a bitstream including a picture and a picture parameter set; identifying structure data about a structure of the picture based on the picture parameter set; and reconstructing at least a portion of the picture based on the structure data.

Description

[0001] This divisional application is a divisional application with application date of December 4, 2019, application number 201980088764.1, and invention name “Block Group Division”.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims the benefit of U.S. Provisional Application No. 62 / 781,749, filed on December 19, 2018, entitled “Tile Group Partition,” and U.S. Provisional Application No. 62 / 775,130, filed on December 4, 2018, entitled “Tile Group Partition,” the contents of both of which are incorporated herein by reference in their entirety. Background Art

[0004] In video data compression, a structure may be defined that facilitates referencing and processing portions of a picture. For example, picture pixels covering a portion of a picture may be grouped into units referred to as coding tree units (CTUs). Larger portions of the picture may be referred to as tiles, which may be defined based on CTUs. Multiple tiles may be referred to as tile groups and referenced together as tile groups. The defined structure allows for specific references to portions of a picture in a video stream for the purpose of storing and transmitting video. Summary of the invention

[0005] Systems and implementations for defining rectangular picture regions in a video data stream and rendering corresponding pictures are described herein. A computing system, which may be, for example, a wireless transmit and receive unit (WTRU), may be programmed to receive a video bitstream including a picture having a picture header. The received video bitstream may be, for example, Versatile Video Coding (VVC) formatted data. The computing system may identify a picture parameter set (PPS) including data specifying a structure of the picture based on a picture parameter set identifier in the picture header.

[0006] The computing system may determine, based on the data specifying the structure of the picture, an identifier corresponding to the defined rectangular area in the picture and a tile index of the upper left tile in the defined rectangular area. For example, the computing system may parse the data specifying the structure of the picture for the identifier corresponding to the defined rectangular area and for the tile index of the upper left tile. The computing system may determine, based on the identifier corresponding to the defined rectangular area and the tile index of the upper left tile in the defined rectangular area, one or more tiles included in the defined rectangular area.

[0007] The computing system may reconstruct a picture including a sub-picture based on an identifier corresponding to the defined rectangular area, the sub-picture including the defined rectangular area. The computing system may render the sub-picture in the defined rectangular area.

[0008] The computing system may parse the picture header to identify an identifier associated with the sub-picture. The computing system may then match the identifier associated with the sub-picture based on the identifier corresponding to the defined rectangular area to identify a sub-bitstream associated with the sub-picture. The computing system may then reconstruct the sub-picture based on the sub-bitstream.

[0009] A motion constrained tile set (MCTS) may allow other tiles excluded from the tile set to be decoded (e.g., independently decoded). The computing system may identify an indication that the defined rectangular area is associated with a motion constrained tile set based on the received data and the identifier corresponding to the defined rectangular area.

[0010] This summary is provided to introduce in a simplified form some concepts that are further described herein in the detailed description. This summary is not intended to limit the scope of the claimed subject matter. Other features are described herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] A more detailed understanding may be obtained from the following description given by way of example in conjunction with the accompanying drawings, in which:

[0012] Figure 1 An example of picture partitioning is shown.

[0013] Figure 2 An example of a motion constraint tile set (MCTS) is shown.

[0014] Figure 3 An example of merging MCTS-based regional tracks is shown.

[0015] Figure 4 An example of combining extractor tracks of MCTS from bitstreams of different resolutions is shown.

[0016] Figure 5 An example cube mapping frame is shown.

[0017] Figure 6 An example tile group partition is shown.

[0018] Figure 7 An example tile group grid and tile grid divisions are shown.

[0019] Figure 8An example resolution process for a middlebox and / or a client is shown.

[0020] Fig. 9 An example of a tile group scanning order is shown.

[0021] Fig. 10A , 10B 10C show an example of a CTB scan implementation.

[0022] Figure 1 1A, 11B, and 11C illustrate example tile raster scan and tile group scan implementations.

[0023] Fig. 12A , 12B and 12C show examples of CTB raster and tile group scanning.

[0024] Fig.13 An example of MCTS-based merging of sub-picture tile groups is shown.

[0025] Fig.14 An exemplary extraction and relocalization of sub-picture tile groups based on MCTS is shown.

[0026] Fig.15A is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented.

[0027] Fig. 15B is a diagram showing the Fig.15A A system diagram of an example wireless transmit / receive unit (WTRU) for use within a communication system is shown in FIG.

[0028] Fig. 15C is a diagram showing the Fig.15A System diagram of an example radio access network (RAN) and an example core network (CN) used within the communication system shown in .

[0029] Fig.15D is a diagram showing the Fig.15A System diagram of another example RAN and another example CN used within the communication system shown in . DETAILED DESCRIPTION

[0030] Techniques for identifying a defined rectangular picture area in a video stream and rendering a video corresponding to the defined rectangular picture area are described. A system may be programmed to receive a video bitstream including a picture with a header. The system may also receive data specifying the structure of the picture. The system may parse the data specifying the structure of the picture for an identifier corresponding to the defined rectangular area in a first picture and for a tile index of an upper left tile in the defined rectangular area. The system may determine one or more tiles included in the defined rectangular area based on the identifier corresponding to the defined rectangular area and the tile index of the upper left tile in the defined rectangular area. The system may reconstruct a picture including a sub-picture based on the identifier corresponding to the defined rectangular area, the sub-picture including the defined rectangular area. The computing system may render the sub-picture in the defined rectangular area.

[0031] A picture may be divided into one or more tile columns and rows. Tile syntax and / or decoding processing may eliminate one or more picture prediction dependencies and / or entropy decoding dependencies across tile boundaries within the same picture. The tile syntax and / or decoding process may allow the tile to have an independent relationship with respect to other tiles within a reference picture used for inter-picture prediction. If more than one tile is included in a slice, the entry point byte offset of (e.g., each) tile other than the first tile in the slice may be signaled in the slice header.

[0032] A tile group may be or may include a slice. A tile group may be or may include a string of tiles, for example, starting in raster order. A tile group header may indicate the number of tiles in the tile group and / or an entry point pointing to the start of (eg, each) tile. Figure 1 An example of picture partitioning is shown. Figure 1 As shown in , a picture with an 18x12 coding tree unit (CTU) (eg, luma CTU) may be partitioned into 12 tiles and 3 tile groups.

[0033] An example syntax for a picture tile grid may be as shown in Table 1. Table 1 shows an example picture parameter set syntax. The picture tile grid shown in Table 1 may be specified by tile columns and tile rows.

[0034] Table 1 - Example Picture Parameter Set Syntax

[0035]

[0036] Table 2 shows an example tile group header syntax. If there is more than one tile in the picture, the syntax element tile_group_address may specify the index of the first tile in the tile group. The syntax element num_tiles_in_tile_group_minus1 plus 1 may specify the number of tiles in the tile group. The syntax element entry_point_offset_minus1[i]plus 1 may specify the i-th tile entry point offset in bytes.

[0037] The first and last bytes of the kth tile after the tile group header within the tile group data may be derived by using equation (1) and / or equation (2):

[0038]

[0039] lastByte[k]=firstByte[k]+entry_point_offset_minus1[k] (2)

[0040] Table 2 - Example tile group header syntax

[0041]

[0042] The set of tiles covering the picture area may be decoded as a motion constrained tile set (MCTS). For MCTS, motion vectors may be restricted. For example, the motion vectors of the MCTS may be restricted, and for example, instead of and / or in addition to decoding one or more (e.g., all) bits of the entire picture, the decoder may decode a subset of the bitstream including the MCTS. One or more (e.g., three) MCTS-related supplemental enhancement information (SEI) messages may include a temporal MCTS SEI message, an MCTS extraction information set SEI message, and an MCTS extraction information nested SEI message. The SEI message may indicate the MCTS position and / or properties, and may enable extraction of a subset of motion constrained tiles (MCTS) from a bitstream. The SEI message may indicate the relocation of the subset of the MCT to another bitstream.

[0043] Table 3 shows an exemplary temporal MCTS SEI message. For example, the syntax element mcts_id[i] may specify the identification number of the i-th MCTS. The syntax element top_left_tile_idx[i][j] and the syntax element bottom_right_tile_idx[i][j] from Table 3 may specify the tile position of the top left tile and the tile position of the bottom right tile of the i-th rectangular region of tiles in the i-th MCTS, respectively. The MCTS may have a non-rectangular shape. Figure 2An example MCTS is shown. Figure 2 As shown, the MCTS may include multiple rectangular tiles, for example, tile 1 and tile 2, which together give the MCTS a non-rectangular shape.

[0044] Table 3 - Example Temporal Motion Constraint Tile Set SEI Message

[0045]

[0046] The MCTS extraction information set SEI message may provide information (e.g., supplementary information) for MCTS sub-bitstream extraction. For example, the MCTS extraction information set SEI message may generate a conforming bitstream for MCTS. The information may include, for example, the number of extraction information sets to be used during the MCTS sub-bitstream extraction process (e.g., num_info_sets_minus1), the number of MCTS sets (e.g., num_mcts_sets_minus1[i]), and / or replacement video parameter sets (VPS), sequence parameter sets (SPS), and picture parameter sets (PPS). The syntax element output_slice_segment_address may specify the output slice segment address of the jth slice segment. The value of the output_slice_segment_address syntax element may be in the range of 0 to PicSizeInCtbsY-1, including endpoints. MCTS may be used for region of interest and / or viewport-related omnidirectional video processing.

[0047] Omnidirectional video processing may be viewport dependent. The Omnidirectional Media Format (OMAF) may define a media format and may enable omnidirectional media, such as 360-degree video, images, audio, and / or associated timed text.

[0048] A viewport-dependent scheme based on equal-resolution MCTS may transcode the same omni-directional video content into one or more bitstreams (e.g., HEVC bitstreams) at different picture qualities and / or bitrates. (e.g., each) MCTS may be included in a region track, and an extractor track may be created. An OMAF player may select the quality of receiving (e.g., each) sub-picture track, for example, based on the viewing orientation. Figure 3 An example of merging MCTS-based regional tracks (e.g., HEVC MCTS-based regional tracks) of the same resolution is shown. Figure 3As shown in , an OMAF player may receive MCTS tracks 1, 2, 5, and 6 of a certain quality (e.g., quality 1), and may receive region tracks 3, 4, 7, and 8 of another quality (e.g., quality 2). The extractor track may be used to reconstruct a bitstream decodable with a decoder (e.g., an HEVC decoder). Tiles of a reconstructed bitstream (e.g., an HEVC bitstream) with MCTS at different qualities may be signaled via tile syntax (e.g., HEVC tile syntax).

[0049] MCTS-based viewport-dependent video processing can decode the same omnidirectional video source content into one or more (e.g., multiple) spatial resolutions. Based on the viewing direction, the extractor can select tiles that match the viewing direction. For example, the extractor can select high-resolution tiles that match the viewing direction and other tiles at low resolution. The bitstream parsed from the extractor track can be decoded by a (e.g., single) decoder.

[0050] Figure 4 An example of combining extractor tracks of MCTS from bitstreams of different resolutions is shown. For example, Figure 4 A scheme for achieving 5K Effective Rectangular Projection (ERP) resolution with viewport-dependent video profiles is shown. Content can be decoded at two spatial resolutions, such as 5120×2560 and 2560×1280, and with 4×2 and 2×2 tile grids, respectively. MCTS can be decoded for (e.g., each) tile position. Two different sets of low-resolution content can be decoded and can be distinguished by a 90 degree yaw difference in rotation angle. Four MCTSs for the high-resolution bitstream and two MCTSs for the low-resolution bitstream can be selected to form a viewport adaptive extractor track.

[0051] A picture partitioning structure may be provided. For example, the picture partitioning structure may address one or more emerging video applications, such as 360-degree video. The tile groups described herein may replace a slice structure and / or may implement a transcoding operation (e.g., a simple transcoding operation). For example, a region of interest (ROI) may be decoded (e.g., independently decoded), or a sub-picture may be extracted from a coded video sequence having a large picture size, and the result may be converted into a coded video sequence. For example, by modifying high-level syntax and / or fully decoding and recoding low-level data (e.g., CTU-level and below data), the result may be converted into a coded video sequence for a smaller picture size. Tile groups may form regions of arbitrary shapes that may be flexible but may not support sub-picture-based partitioning. Rectangular tile groups may support region-based video applications. For example, rectangular tile groups may be applied to specific regions and / or faces in an omnidirectional video that is an equirectangular and / or cubemap projection format, etc. Figure 5An example cubemap frame is shown. Figure 5 As shown, an example cubemap frame may be a 3×2 cubemap picture. Rectangular tile groups may be applied to faces or sub-pictures for independent decoding and rendering and / or sub-bitstream extraction to form extractor tracks.

[0052] Systems and implementations for defining rectangular picture regions in a video data stream and rendering corresponding pictures are described herein. A computing system, which may be, for example, a wireless transmit and receive unit (WTRU), may be programmed to receive a video bitstream including a picture having a picture header. The received video bitstream may be, for example, Versatile Video Coding (VVC) formatted data. The computing system may identify a picture parameter set (PPS) including data specifying a structure of the picture based on a picture parameter set identifier in the picture header.

[0053] The computing system may determine an identifier corresponding to a defined rectangular area in the picture and a tile index of an upper left tile in the defined rectangular area based on the data specifying the structure of the picture. For example, the computing system may parse the data specifying the structure of the picture for the identifier corresponding to the defined rectangular area and for the tile index of the upper left tile. The computing system may determine one or more tiles included in the defined rectangular area based on the identifier corresponding to the defined rectangular area and the tile index of the upper left tile in the defined rectangular area.

[0054] The computing system may reconstruct a picture including a sub-picture based on an identifier corresponding to the defined rectangular area, the sub-picture including the defined rectangular area. The computing system may render the sub-picture in the defined rectangular area.

[0055] The rectangular tile group structure can be used to enable video applications based on regions of interest and / or sub-pictures. Bottom-to-top tile group partitioning and top-to-bottom tile group partitioning can be used. MCTS can be enabled for tile groups to support ROI and / or sub-picture extraction and repositioning.

[0056] The tile group partitioning from bottom to top may partition a picture into tiles and may group one or more (e.g., multiple) tiles into a tile group. The tile group partitioning from top to bottom may partition a picture into one or more tile groups and the one or more tile groups into one or more tiles. A rectangular tile group syntax structure may be established using one or more syntax elements of the tile group. The syntax elements of the tile group may include tile_group_id, tile_group_start_address, tile_group_end_address, num_tiles_in_tile_group_minus1, and / or the like. Syntax elements may be signaled at various levels. For example, the syntax elements of the tile group may be signaled in a parameter set (e.g., such as a picture parameter set (PPS), a sequence parameter set (SPS), a video parameter set (VPS), and / or the like) or in a picture header. Those skilled in the art will recognize that one or more parameters carried in the parameter set described herein may include, but are not limited to, PPS, SPS, VPS, and / or similar parameter sets.

[0057] A bottom-to-top tile group partitioning may be employed to provide a rectangular tile group structure. A tile group may be a sequence of tiles in a tile raster scan of a picture. A tile may be a sequence of CTUs covering an area of ​​a picture (e.g., a rectangular area of ​​a picture). A tile group may be a set of tiles covering an area of ​​a picture (e.g., a rectangular area of ​​a picture). In an example, a boundary of a tile group may span the picture. In an example, a boundary of a tile group may be within a picture (e.g., not spanning a picture). The bottom-to-top tile group partitioning may divide a picture into tiles and may group one or more (e.g., multiple) tiles into a tile group.

[0058] Syntax and semantics for rectangular tile groups may be provided. Table 4 shows an example tile group header syntax that may be used for rectangular tile groups.

[0059] Table 4 - Example Tile Group Header Syntax

[0060]

[0061] The tile_group_id syntax element may specify the identification number of the associated tile group. The tile_group_id syntax element may have a value from 0 to 2. 32 The profile and / or level may specify a maximum number of tile groups.

[0062] The syntax element tile_group_start_address and the syntax element tile_group_end_address may specify the location of the first tile (e.g., or the top left tile) and the location of the last tile (e.g., or the bottom right tile) in the rectangular area of ​​the associated tile group. The address value may be, for example, the address of the associated tile in a tile raster scan of a picture.

[0063] If the picture contains tiles (e.g., a single tile) or the picture contains tile groups (e.g., a single tile group), signaling about the tile group start address may be skipped. If the tile group contains a single tile, signaling about the tile group end address may be skipped. If the tile group start address and / or tile group end address are not present, the value of the tile_group_start_address syntax element may be inferred (e.g., equal to 0), and the value of the tile_group_end_address syntax element may be inferred (e.g., equal to the value of the tile_group_start_address syntax element).

[0064] Figure 6 An example of tile group partitioning is shown. Figure 6 As shown, a picture can be divided into 6×4 CTBs and 3×2 tiles, where a tile can cover 2×2 CTBs. A tile group can cover an integer number of tiles. The position and / or shape of the tile group can be specified. For example, the position and / or shape of the tile group can be specified by the address of the first and / or last tile in the tile raster scan of the picture. For example, Figure 6 The position and shape of the upper right tile group shown in (a) can be signaled by tile #3 as the starting address. Figure 6 The position and shape of the right tile group shown in (b) may be signaled by tile #3 as the start address and tile #6 as the end address.

[0065] One or more syntax elements for a (e.g., each) tile group may be signaled (e.g., explicitly signaled), such as tile_group_id, tile_group_start_address, tile_group_end_address, num_tiles_in_tile_group_minus1, and / or the like. For example, the syntax elements for the tile group may be signaled in a parameter set (e.g., PPS, SPS, VPS, and / or the like) or a picture header, e.g., to indicate a tile group grid for sub-picture extraction. The sub-picture may be coded as a tile group sub-bitstream. A middlebox, extractor, and / or client may determine the tile group grid by parsing the parameter set (e.g., PPS) or the picture header (e.g., directly). In an example, the middlebox, extractor, and / or client may extract the corresponding sub-picture bitstream by searching for the associated syntax element tile_group_id from the tile group header. In an example, the middlebox, extractor, and / or client may extract (e.g., directly extract) a sub-bitstream via a sub-bitstream byte offset indication. Signaling a tile group address (e.g., in a tile group header) may configure the middlebox and / or client to parse the tile group header. Parsing of the tile group header may be performed to understand the tile group distribution in a picture and / or to determine which tile group data may be extracted.

[0066] Figure 7 An example tile group partitioning grid and tile partitioning grid are shown. Figure 7 An example of tile group partitioning is shown. A picture may be divided into a 4×4 tile grid. The first tile column may be grouped into tile group #1; the second and third tile columns may be grouped into tile group #2; and the last tile column may be grouped into tile group #3. Tile group #1 may include a 1×4 tile grid; tile group #2 may include a 2×4 tile grid; and tile group #3 may include a 1×4 tile grid. The bitstream may be constructed as a sequence of tile group sub-bitstreams. The tile group sub-bitstream may include a sequence of tile sub-bitstreams. The tile grid within the tile group (e.g., a local tile grid) may be signaled (e.g., independently signaled). The local tile grid may be consistent before and after extraction, and the picture level of the entire tile grid may change before and after extraction. The consistency of the local tile grid may help the sub-picture extraction and repositioning process.

[0067] If a middlebox or client plans to extract Figure 7If the ROI at tile #8 and / or tile #12 is circled in the figure, the middlebox and / or client may parse the parameter set (e.g., parse the parameter set, such as PPS priority) to figure out the tile partitioning structure, and may determine whether the ROI is at tile #8 and / or at tile #12. The middlebox and / or client may parse one or more (e.g., all three) headers of the tile group, for example, to determine whether tile #8 and / or tile #12 are included in tile group #3. The tile group grid may be signaled (e.g., using a parameter set (e.g., PPS) or a picture header). Based on the tile group grid (e.g., at a parameter set (e.g., PPS) or a picture header), the middlebox and / or client may identify that the ROI is covered by tile group #3 after (e.g., directly after) parsing the parameter set (e.g., PPS) and / or the picture header. Based on the tile group grid (e.g., at a parameter set (e.g., PPS) or the picture header), the middlebox and / or the client may extract the tile group #3 sub-bitstream with the tile group entry point indicator and may, e.g., based on the tile entry point indicator, extract (e.g., further extract) tile #8 and / or tile #12.

[0068] Table 5 - Example tile group structure in PPS or picture header

[0069]

[0070] Table 5 shows an example tile group partitioning structure in a PPS and / or picture header as described herein. The extractor may identify a tile group grid from the structure in the PPS and / or picture header. The extractor may extract the associated sub-picture or tile group sub-bitstream. For example, if (e.g., each) sub-picture is coded into a tile group, the extractor may extract the associated sub-picture or tile group sub-bitstream based on the syntax element tile_group_id or the tile group entry point. If an extractor track (e.g., a new extractor track) is formed, the middlebox and / or the extractor may update the tile group grid structure at the parameter set (e.g., PPS) or picture header level (e.g., without directly modifying the tile group sub-bitstream). By referencing the tile group grid structure at the parameter set (e.g., PPS) or picture header, the client may compose and / or render the sub-pictures together.

[0071] In an example, the number of tile groups indicated in a parameter set (e.g., PPS) or a picture header may specify a region of interest (e.g., a rectangular region of interest) and / or a sub-picture within a picture. The area of ​​the picture may not be covered by a signaled tile group (e.g., an explicitly signaled tile group as described herein). The area not covered by a signaled tile group (e.g., an explicitly signaled tile group) may form a tile group, and the tile group may be non-rectangular in shape.

[0072] The syntax element tile_group_offset_len_minus1 plus 1 may specify the length (eg, in bits) of the tile_group_entry_point_offset_minus1[i] syntax element. The value of the offset_len_minus1 syntax element may be in the range of 0 to 31, inclusive.

[0073] The syntax element tile_group_entry_point_offset_minus1[i]plus 1 may specify the i-th tile group entry point offset (e.g., in bytes) and may be represented by the syntax element tile_group_offset_len_minus1plus1 bits. The first byte of the tile group header may be considered as byte 0. If the first byte is present, the emulation prevention bytes present in the tile group header and tile group data portions of the coded tile group network abstraction layer (NAL) unit may be counted. For example, the emulation prevention bytes may be counted as part of the tile group header and / or tile group data (e.g., for subset identification). Subset 0 may include byte 0 up to the syntax element tile_group_entry_point_offset_minus1[0], including the coded tile group header. The tile group data such as subset k (e.g., k in the range of 1 to num_tile_group_minus1-1, inclusive) may include bytes firstByte[k] to lastByte[k], inclusive, in the coded tile group header and associated tile group data (with firstByte[k] and lastByte[k]). firstByte[k] and lastByte[k] may be one or more (e.g., all) byte offsets. firstByte[k] and lastByte[k] may be as shown in equations (3) and (4), respectively.

[0074]

[0075] lastByte[k]=firstByte[k]+tile_group_entry_point_offset_minus1[k] (4)

[0076] The syntax element tile_group_offset_len_minus1 and / or the syntax element tile_group_entry_point_offset_minus1 may be signaled. For example, the syntax element tile_group_offset_len_minus1 and / or the syntax element tile_group_entry_point_offset_minus1 may be signaled in a picture header, since the values ​​may vary between pictures.

[0077] Table 6 - Example tile group header syntax

[0078]

[0079] In an example, the local tile grid for a tile group may be derived from a picture tile grid (e.g., signaled in a parameter set such as a PPS or picture header). The derived local tile grid structure may be carried in a tile group header, e.g., to form a self-contained tile group sub-bitstream for sub-picture extraction and repositioning. Figure 7 As shown, a local tile grid for (e.g., each) tile group (e.g., 1x4 and / or 2x4) may be derived from a picture tile grid (e.g., 4x4) and / or a tile group grid (e.g., 3x1). Table 6 shows an example tile group header syntax. The syntax element tile_partitioning structure may indicate a local tile grid within a tile group. The syntax element tile_partitioning structure may include parameters such as tile width and height, tile group width and height, and / or tile grid. The middlebox and / or client may request and / or extract a sub-picture based on a tile group grid signaled in a parameter set such as a PPS or a picture header, for example. The middlebox and / or client may decode and / or render a particular tile based on a local tile grid and an entry point offset signaled in a tile group header, for example. Figure 8 An example parsing process for a middlebox and / or client as described herein is shown.

[0080] In an example, if the boundaries of tile groups are constrained to span the entire picture, a tile partitioning syntax structure (e.g., a similar tile partitioning syntax structure described in HEVC) may be used to indicate the tile group partitioning structure in a parameter set (e.g., PPS) and / or a picture header. The tile group partitioning structure may be specified by tile group columns and rows. A picture may be partitioned (e.g., evenly partitioned) into tile group columns and rows, or the width of (e.g., each) tile group column and the height of (e.g., each) tile group row may be signaled (e.g., explicitly signaled).

[0081] Table 7 shows an example tile group grid syntax (e.g., for a PPS or picture header). The syntax element num_tile_group_columns_minus1 plus 1 may specify the number of tile group columns in a picture. The syntax element num_tile_group_rows_minus1 plus 1 may specify the number of tile group rows in a picture. If tile groups are not evenly distributed in a picture, the width and height of (e.g., each) tile group column and row may be specified (e.g., explicitly specified) by the syntax element tile_group_column_width_minus1 and / or the syntax element tile_group_row_height_minus 1.

[0082] The syntax element motion_constrain_enabled_flag equal to 1 may indicate that motion constraints may or may not be applied to the tile group. The syntax element tile_group_motion_constrain_enabled_flag equal to 1 may indicate that the associated tile group is motion constrained.

[0083] Table 7 - Exemplary tile group grid syntax for PPS or picture header

[0084]

[0085] The tile group id and / or index may be specified. For example, the tile group id and / or index may be specified in the order of the top left tile raster scan address of the tile group of the picture. Fig. 9 An exemplary tile group scan order is shown, for example based on tile raster scan addresses. Fig. 9 An example is shown where the tile group index may be arranged in the order of the address of the first tile (eg, labeled X) of the tile group in the raster scan order of the picture.

[0086] The tile group partitioning from bottom to top may include coding tree block CTB raster and tile scan processing. A tile group may be or may include a sequence of tiles in a tile raster scan of a picture. CTB raster and tile scan conversion may be applied. Tiles may not be grouped (e.g., not grouped sequentially) into tile groups. CTB raster and tile scan conversion may support rectangular tile groups. Fig. 10A , 10B and 10C illustrate an exemplary raster and tile scanning process. Fig. 10A An example CTB raster scan of a picture is shown. Fig. 10B An example CTB tile scan of a tile group of a sequence of tiles in a tile raster scan of a picture is shown. Fig. 10C An example CTB tile scan using the rectangular block groups described herein is shown.

[0087] Syntax elements such as PicSizeInCtbsY, PicWidthInCtbsY, ctbAddrRs, colWidth, rowHeight, colBd and / or rowBd may be used in the conversion process described herein.

[0088] The list tileGroupWidthInCTBs[i] and the list tileGroupHeightInCTBs[i] for i may range from 0 to num_tile_groups_minus1, inclusive. The list tileGroupWidthInCTBs[i] and the list tileGroupHeightInCTBs[i] for i may specify the width and height of the i-th tile group in CTB units and may be derived as follows:

[0089]

[0090] The list tgLeft[i] for i may range from 0 to num_tile_groups_minus1, inclusive. The syntax element tile_group may be or may contain tile_group or tileGroup. The list tgLeft[i] for i may specify the position of the left boundary of the i-th tile group in units of CTBs and may be derived as follows:

[0091]

[0092] The list tgRight[i] for i can range from 0 to num_tile_groups_minus1, including the endpoints. The list tgRight[i] for i can specify the position of the right border of the i-th tile group in units of CTB, and can be derived as follows:

[0093]

[0094] The list tgTop[i] for i can range from 0 to num_tile_groups_minus1, including the endpoints. The list tgTop[i] for i can specify the position of the top boundary of the i-th tile group in units of CTB, and can be derived as follows:

[0095]

[0096] The list tgBot[i] for i can range from 0 to num_tile_groups_minus1, including the endpoints. The list tgBot[i] for i can specify the position of the right border of the i-th tile group in units of CTB, and can be derived as follows:

[0097]

[0098] The list CtbAddrRsToTs[ctbAddrRs] for ctbAddrRs may be in the range of 0 to PicSizeInCtbsY-1, inclusive. The list CtbAddrRsToTs[ctbAddrRs] for ctbAddrRs may specify a conversion from a CTB address in a CTB raster scan of a picture to a CTB address in a tile scan, and may be derived as follows. The syntax element tgIdx may be or may include tileGroupIdx.

[0099]

[0100] The tile group partitioning from bottom to top may involve tile raster and tile group scan conversion processing. Tile group scan may be the ordering of tiles that partition a picture (e.g., sequential ordering of tiles), where the tiles are ordered (e.g., sequentially ordered) in a tile raster scan in a tile group. Tile scan of a picture's tile raster and tile group conversion may support rectangular tile groups. Fig.11A , 11B 11C illustrate an exemplary tile scanning process. Fig.11A An exemplary tile raster scan of a picture is shown. Fig. 11B An exemplary tile group scan of sequential tiles in a raster scan of a picture is shown. Fig. 11C An example tile group scan of a rectangular tile group as described herein is shown.

[0101] The list of tileAddrRs TileAddrRsToTGs[tileAddrRs] may range from 0 to NumTilesInPic-1, inclusive. The list of tileAddrRs TileAddrRsToTGs[tileAddrRs] may specify the conversion of tile addresses in a tile raster scan of a picture to tile addresses in a tile group scan, and may be derived as follows. The syntax element NumTilesInPic may be the total number of tiles of the picture.

[0102]

[0103] The list of tileAddrTGs TileAddrTGsToRs[tileAddrTGs] for tileAddrTGs may range from 0 to NumTilesInPic-1, inclusive. The list of tileAddrTGs TileAddrTGsToRs[tileAddrTGs] for tileAddrTGs may specify the conversion from tile addresses in a tile group scan to tile addresses in a raster scan of a picture, and may be derived as follows:

[0104]

[0105] The tile group partitioning from bottom to top may use derived tile IDs. The list TileId[ctbAddrTs] for ctbAddrTs may be in the range of 0 to PicSizeInCtbsY-1, inclusive. The list TileId[ctbAddrTs] for ctbAddrTs may specify the conversion from CTB addresses in a tile scan to tile IDs and may be derived as follows:

[0106]

[0107] The tile group partitioning may adopt the tile group data structure as described herein. For example, based on the conversion from CTB raster scan to tile scan and the conversion from CTB addresses in tile scan, the tile group address may not be included in the tile group header and / or the tile group data structure, as shown in Table 8.

[0108] Table 8 - Example tile group data structure

[0109]

[0110] A rectangular tile group structure may be provided using top-to-bottom tile group partitioning. Top-to-bottom group tile partitioning may partition a picture into one or more tile groups. The tile group may include an integer number of CTBs (e.g., to cover a rectangular area). The tile group may be partitioned into one or more (e.g., multiple) tiles. A tile group grid may be signaled in a parameter set (e.g., PPS) and / or a picture header. A local tile grid (e.g., a default tile grid) within (e.g., each) tile group may be signaled in a parameter set (e.g., PPS), a picture header, a tile group header, and / or the like. A different local tile grid may be signaled in a tile group header to override a default tile grid signaled in a parameter set (e.g., PPS) or a picture header.

[0111] (e.g., each) tile group in the top-to-bottom method described herein may be a self-contained entity. For example, a tile group in the top-to-bottom method described herein may be an independent entity with a local tile partitioning grid, and the grid (e.g., the local tile partitioning grid) may be independent of the tile grids of other tile groups. For some video applications, the middlebox and / or the client may splice one or more tile groups from different bitstreams, and may combine one or more tile groups from different bitstreams to form a bitstream (e.g., a new bitstream). The picture tile grid of the bitstream (e.g., the new bitstream) may use different tile column and tile row structures and / or may be signaled using different tile column and tile row structures, and the types of combinations of different tile groups may be limited. The top-to-bottom tile group method may skip the picture tile grid signaling and may simplify the bitstream splicing process. The top-to-bottom tile group method described herein may allow more types of tile group-based sub-bitstream extraction, repositioning, and / or combination.

[0112] The tile group grid structure may be signaled (e.g., in a parameter set (e.g., PPS) and / or in a picture header). Table 9 provides an exemplary tile group structure. The tile group position may be specified using a syntax element tile_group_start_address and / or a syntax element tile_group_end_address. The syntax element tile_group_start_address and / or the syntax element tile_group_end_address may specify the address of the first CTB in a CTB raster scan of a picture (e.g., or the top left CTB) and the address of the last CTB in a CTB raster scan of a picture (e.g., or the bottom right CTB), respectively. A tile partitioning structure (e.g., specified in HEVC) or a flexible tile partitioning structure may be signaled in a syntax element tile_partitioning structure to indicate a default tile partitioning that may be applicable to (e.g., each) tile group.

[0113] Table 9 - Example tile group structure

[0114]

[0115] In an example, a list of tile partitioning structures may be signaled in a parameter set (e.g., PPS) or a picture header. An index may be assigned to (e.g., each) tile partitioning grid (e.g., a default tile partitioning grid). A tile group may refer to a specific list index to indicate the tile partitioning structure. A tile partitioning override indication (e.g., an override flag) may be signaled in a tile group header. If the tile partitioning override indication (e.g., an override flag) is equal to 1, the tile group may specify a tile partitioning structure that may have been excluded from the tile partitioning list (e.g., a new tile partitioning structure).

[0116] Table 10 shows an example tile partition list syntax structure. The syntax element tile_grid_override_enabled_flag equal to 1 may indicate that the tile group may or may not use the new tile grid (eg, it is not included in the tile partition list).

[0117] Table 10 - Example tile partition list

[0118]

[0119] Table 11 shows an example tile partition reference field in the tile group header. Table 11 shows that the tile group may refer to the partition structure signaled in the partition list or may use a new tile partition grid.

[0120] If the syntax element tile_partitioning_override_enabled_flag is not set or the syntax element tile_grid_is_overrided is equal to 0, the tile group may refer to the tile partitioning signaled in the PPS or picture header. If the syntax element tile_grid_is_overrided is equal to 1, a new tile partitioning structure may be signaled at the tile group header. If the tile_grid_is_overrided syntax element is not present, the value of the tile_grid_is_overrided syntax element may be inferred to be 0.

[0121] Table 11 - Example tile partition reference fields at the tile group header

[0122]

[0123] The boundaries of a tile group may be constrained to span the entire picture. Region-based signaling for flexible tiles may be used in the PPS or picture header. (Eg) Each grid region may be a tile group.

[0124] The tiles may be divided within (eg, each) tile group. When one or more tiles are divided within (eg, each) tile group, the CTB raster and tile group scanning process may be specified as follows.

[0125] The top-to-bottom tile group partitioning may employ CTB raster and tile scan conversion processing. The list TileGroupWidthInCtbsY[i] and the list TileGroupHeightInCtbsY[i] for i may range from 0 to num_tile_groups_minus1, inclusive. The list TileGroupWidthInCtbsY[i] and the list TileGroupHeightInCtbsY[i] for i may specify the width and height of the i-th tile group unit of the CTB and may be derived as follows:

[0126]

[0127] The list tgLeft[i] for i can range from 0 to num_tile_groups_minus1, including the endpoints. The list tgLeft[i] for i can specify the position of the left edge of the i-th tile group in units of CTB, and can be derived as follows:

[0128]

[0129] The list tgRight[i] for i can range from 0 to num_tile_groups_minus1, including the endpoints. The list tgRight[i] for i can specify the position of the right border of the i-th tile group in units of CTB, and can be derived as follows:

[0130]

[0131] The list tgTop[i] for i ranges from 0 to num_tile_groups_minus1, including the endpoints. The list tgTop[i] for i can specify the position of the top boundary of the i-th tile group in units of CTB, and can be derived as follows:

[0132]

[0133] The list tgBot[i] for i can range from 0 to num_tile_groups_minus1, including the endpoints. The list tgBot[i] for i can specify the position of the right border of the i-th tile group in units of CTB, and can be derived as follows:

[0134]

[0135] The list colwidth[i][j] for j may range from 0 to num_tile_columns_minus1[i], inclusive. The list colWidth[i][j] for j may specify the width of the jth tile column of the i-th tile group in CTBs and may be derived as follows:

[0136]

[0137] The list rowHeight[j] for j can range from 0 to num_tile_rows_minus1, including the endpoints. The list rowHeight[j] for j can specify the height of the j-th tile row in units of CTB and can be derived as follows:

[0138]

[0139] The list colBd[i][j] for i may range from 0 to num_tile_columns_minus1[i]+1, inclusive. The list colBd[i][j] for i may specify the position of the jth tile column boundary of the i-th tile group in units of CTBs and may be derived as follows:

[0140]

[0141] The list rowBd[i][j] for j may range from 0 to num_tile_rows_minus1[i]+1, inclusive. The list rowBd[i][j] for j may specify the position of the jth tile row boundary of the i-th tile group in CTB units and may be derived as follows:

[0142]

[0143] The list CtbAddrRsToTs[ctbAddrRs] for ctbAddrRs may be in the range of 0 to PicSizeInCtbsY-1, inclusive. The list CtbAddrRsToTs[ctbAddrRs] for ctbAddrRs may specify the conversion of CTB addresses in a CTB raster scan of a picture to CTB addresses in a tile scan, and may be derived as follows:

[0144]

[0145] The list CtbAddrTsToRs[ctbAddrTs] for ctbAddrTs may range from 0 to PicSizeInCtbsY-1, inclusive. The list CtbAddrTsToRs[ctbAddrTs] for ctbAddrTs may specify a conversion from a CTB address in a tile scan of a picture to a CTB address in a CTB raster scan, and may be derived as follows:

[0146]

[0147] Fig. 12A , 12B 12C show examples of CTB raster and tile group scanning. For example, a picture may be divided into 8×4 CTBs and 3 tile groups (e.g., Fig. 12A -C). The first and third tile groups may include tiles. The second tile group may include 3×1 tiles. The CTB raster scan of the picture may be as shown in FIG. Fig. 12A The tile group division can be as follows Fig. 12B As shown in . CTB tile scanning can be Fig. 12C as shown in .

[0148] The tile ID may be derived. The list TileId[ctbAddrTs] for ctbAddrTs may be in the range of 0 to PicSizeInCtbsY-1, inclusive. The list TileId[ctbAddrTs] for ctbAddrTs may specify the conversion from CTB addresses in the picture scan to tile IDs and may be derived as follows:

[0149]

[0150] MCTS may be supported in tile groups (e.g., or at the tile group level). MCTS may allow other tiles excluded from a tile set to be decoded (e.g., independently decoded) the tile set. MCTS sub-bitstreams may be extracted and / or may be repositioned. In an example, an MCTS sub-bitstream may be extracted and / or may be repositioned with other MCTS sub-bitstreams to form a conforming bitstream to be decoded and rendered. In an example, an MCTS sub-bitstream may be extracted and / or repositioned to form a conforming bitstream to be decoded and rendered without other MCTS sub-bitstreams. An indicator may be signaled for (e.g., each) tile group to specify that the entire tile group may be a motion constrained tile set, or that (e.g., each) tile within the tile group may be a motion constrained tile set. A syntax structure (eg, similar to a temporal MCTS SEI message) may be signaled at a parameter set (eg, PPS), a picture header, or a tile group header to indicate one or more (eg, multiple) MCTSs within a tile group.

[0151] Table 12 shows example motion constrained tile group (MCTG) signaling for a tile group. The signaling may be carried in a parameter set (e.g., PPS), a picture header, and / or a tile group header. For example, the signaling may be carried in a parameter set (e.g., PPS), a picture header, and / or a tile group header to specify whether a tile group is motion constrained.

[0152] The syntax element tile_group_one_tile_set_flag[i] may indicate that the i-th tile group or the tile group with ID equal to i is MCTS.

[0153] One or more indications (e.g., additional flags) may be signaled outside the tile group loop to specify whether (e.g., each) tile group within a picture is MCTS and whether (e.g., each) tile within a picture is MCTS. If (e.g., each) tile within a picture is MCTS or (e.g., each) tile group is motion constrained, MCTG signaling may be skipped.

[0154] Table 12 - Temporal Motion Constraint Tile Group (MCTG) Signaling

[0155]

[0156] Tile group signaling can support viewport-dependent schemes based on equal resolution MCTS (e.g., Figure 3 ). If a tile group id is present in the tile group header, the id (eg, tile group id) may assign (eg, be updated to assign) a unique id to (eg, each) tile group.

[0157] Fig.13 An example of merging MCTS-based sub-image tile groups of the same resolution is shown. For example, Fig.13 It is shown that high-quality and low-quality tile groups can be extracted and these tile groups can be merged together to form a viewport-dependent bitstream, for example, without rewriting the low-level bitstream. Fig.13 As shown, tile group sub-bitstreams associated with high-quality sub-pictures #2, #3, #6, and #7 can be extracted from a bitstream with quality 2, and tile group sub-bitstreams associated with low-quality sub-pictures #1, #5, #4, and #8 can be extracted from a bitstream with quality 1. The extracted sub-pictures can be merged to form a viewport-dependent bitstream (e.g., without rewriting the low-level bitstream). (Eg., each) sub-picture can include one or more (e.g., multiple) tiles. In an example, the local tile grids within a (e.g., each) tile group may be the same. In an example, the local tile grids between different tile groups may be different. The picture-level tile grids between a quality 1 bitstream and a quality 2 bitstream may be different.

[0158] The tile group grid may be signaled in a parameter set (e.g., PPS) and / or a picture header. When the tile group grid is signaled in a parameter set (e.g., PPS) or a picture header, the middlebox and / or the client may identify the corresponding high-quality and / or low-quality tile groups after parsing the parameter set (e.g., PPS) and / or the picture header, and may skip parsing the (e.g., individual) tile group header. After extracting (e.g., each) sub-bitstream based on the tile group entry point, the middlebox and / or the client may merge the sub-bitstreams together, e.g., without modifying the tile group header or tile group data, because the (e.g., each) tile group sub-bitstream is self-contained with the local tile grid signaled in the tile group header. The middlebox and / or the client may generate a new parameter set or picture header, e.g., by copying a similar tile group grid from a parameter set (e.g., PPS) or a picture header of a source bitstream.

[0159] Fig.14 An example extraction and relocalization of MCTS-based sub-image tile groups of different resolutions is shown. For a multi-resolution MCTS-based viewport-dependent scheme (e.g., Fig.14 As shown in FIG. 1 , the tile groups described herein may simplify the sub-bitstream extraction and relocation. For example, the tile group grid at the PPS and the tile group entry at the picture header may be updated, and the corresponding MCTS-based sub-picture tile groups may be merged together, for example, without rewriting the low-level bitstream. Fig.14An example may be shown in which the tile group grid may be changed in a merged bitstream (e.g., a new merged bitstream), while the low-level tile group headers and data may be intact during extraction and merging. After parsing the parameter set (e.g., PPS), the middlebox and / or client may identify tile group sub-bitstreams #2, #3, #6, and #7 from the first stream, and tile group sub-bitstreams #14 and #16 from the third bitstream. The middlebox and / or client may extract the corresponding tile group sub-bitstream, for example, based on the tile group entry point, and may relocate the tile group sub-bitstream into the new stream. The middlebox and / or client may generate a new VPS, SPS, and / or PPS with an updated tile group partitioning structure, such as Fig.14 Since the local tile grid remains the same for (e.g., each) tile group before and after extraction and repositioning, and since the local tile grid is signaled within the (e.g., each) tile group sub-bitstream, the extraction and repositioning process may skip rewriting the tile group sub-bitstream.

[0160] Fig.15A 1 is a diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content by sharing system resources including wireless bandwidth. For example, the communication system 100 may use one or more channel access methods such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero tail unique word DFT-spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, and filter bank multi-carrier (FBMC), etc.

[0161] like Fig.15AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, Internet 110, and other networks 112, although it should be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network components. Each WTRU 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, any of the WTRUs 102a, 102b, 102c, 102d may be referred to as a “station” and / or “STA”, which may be configured to transmit and / or receive wireless signals, and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices working in an industrial and / or automated process chain environment), consumer electronic devices, and devices working on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, 102d may be interchangeably referred to as a UE.

[0162] The communication system 100 may also include a base station 114a and / or a base station 114b. Each base station 114a, 114b may be any type of device configured to facilitate access to one or more communication networks (e.g., CN 106 / 115, Internet 110, and / or other networks 112) by wirelessly interfacing with at least one of the WTRUs 102a, 102b, 102c, 102d. For example, the base stations 114a, 114b may be base transceiver stations (BTS), node Bs, e-node Bs, home node Bs, home e-node Bs, gNBs, NR node Bs, site controllers, access points (APs), wireless routers, and the like. Although each base station 114a, 114b is described as a single component, it should be understood that the base stations 114a, 114b may include any number of interconnected base stations and / or network components.

[0163] The base station 114a may be part of the RAN 104 / 113, and the RAN may also include other base stations and / or network components (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, and the like. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies called cells (not shown). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage for a specific geographic area that is relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, a cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, that is, each transceiver corresponds to a sector of the cell. In an embodiment, the base station 114a may use multiple-input multiple-output (MIMO) technology and may use multiple transceivers for each sector of the cell. For example, by using beamforming, signals may be transmitted and / or received in a desired spatial direction.

[0164] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0165] More specifically, as described above, the communication system 100 may be a multiple access system and may use one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA, among others. For example, the base station 114a in the RAN 104 / 113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 115 / 116 / 117. WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High Speed ​​UL Packet Access (HSUPA).

[0166] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro).

[0167] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR radio access, which may establish the air interface 116 using new radio (NR).

[0168] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may jointly implement LTE radio access and NR radio access (e.g., using dual connectivity (DC) principles). Thus, the air interface used by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., eNBs and gNBs).

[0169] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE), and GSM EDGE (GERAN), among others.

[0170] Fig.15AThe base station 114b in the example may be a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may use any appropriate RAT to facilitate wireless connectivity in a local area, such as a business location, a residence, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may establish a wireless local area network (WLAN) by implementing a radio technology such as IEEE 802.11. In an embodiment, the base station 114b and the WTRUs 102c, 102d may establish a wireless personal area network (WPAN) by implementing a radio technology such as IEEE 802.15. In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may establish a picocell or a femtocell by using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, and the like). Fig.15A As shown, the base station 114b may be directly connected to the Internet 110. Thus, the base station 114b does not need to access the Internet 110 via the CN 106 / 115.

[0171] The RAN 104 / 113 may be in communication with the CN 106 / 115, which may be any type of network configured to provide voice, data, applications and / or Voice over Internet Protocol (VoIP) services to one or more WTRUs 102a, 102b, 102c, 102d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calls, Internet connectivity, video distribution, etc., and / or may perform advanced security functions such as user authentication. Although in Fig.15A Although not shown, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT or a different RAT as the RAN 104 / 113. For example, in addition to being connected to the RAN 104 / 113 employing NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) employing GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0172] The CN 106 / 115 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer network devices that use common communication protocols (e.g., the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and / or the Internet Protocol (IP) in the TCP / IP Internet Protocol Suite). The networks 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the other networks 112 may include another CN connected to one or more RANs, wherein the one or more RANs may use the same RAT or a different RAT as the RAN 104 / 113.

[0173] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links). Fig.15A The illustrated WTRU 102c may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0174] Fig. 15B is a system diagram showing an example WTRU 102. Fig. 15B As shown, the WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keyboard 126, a display / touchpad 128, a non-removable memory 130, a removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It should be appreciated that the WTRU 102 may include any sub-combination of the foregoing components while remaining consistent with an embodiment.

[0175] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal decoding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Fig. 15B The processor 118 and the transceiver 120 are depicted as separate components, however it should be appreciated that the processor 118 and the transceiver 120 may also be integrated into one electronic component or chip.

[0176] The transmit / receive component 122 may be configured to transmit or receive signals to or from a base station (e.g., base station 114a) via the air interface 116. For example, in one embodiment, the transmit / receive component 122 may be an antenna configured to transmit and / or receive RF signals. As an example, in an embodiment, the transmit / receive component 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals. In an embodiment, the transmit / receive component 122 may be configured to transmit and / or receive RF and light signals. It should be appreciated that the transmit / receive component 122 may be configured to transmit and / or receive any combination of wireless signals.

[0177] Although in Fig. 15B 102 as a single component, but the WTRU 102 may include any number of transmit / receive components 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in an embodiment, the WTRU 102 may include two or more transmit / receive components 122 (e.g., multiple antennas) for transmitting and receiving radio signals over the air interface 116.

[0178] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive component 122 and to demodulate signals received by the transmit / receive component 122. As described above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers that allow the WTRU 102 to communicate via multiple RATs (e.g., NR and IEEE 802.11).

[0179] The processor 118 of the WTRU 102 may be coupled to the speaker / microphone 124, the keyboard 126, and / or the display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit), and may receive user input data from these components. The processor 118 may also output user data to the speaker / microphone 124, the keyboard 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from and store information in any suitable memory such as the non-removable memory 130 and / or the removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from and store data in memories that are not physically located in the WTRU 102, such as, for example, a server or a home computer (not shown).

[0180] The processor 118 may receive power from the power source 134, and may be configured to distribute and / or control power for use by other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (Ni-Cd), nickel-zinc (Ni-Zn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0181] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) related to the current location of the WTRU 102. In addition to or in lieu of the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) via the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be appreciated that the WTRU 102 may acquire location information via any suitable positioning method while remaining consistent with an embodiment.

[0182] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripheral devices 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, Modules, frequency modulation (FM) radio units, digital music players, media players, video game console modules, Internet browsers, virtual reality and / or augmented reality (VR / AR) devices, and activity trackers, etc. The peripherals 138 may include one or more sensors, which may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors, geolocation sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors.

[0183] The WTRU 102 may include a full-duplex radio in which reception or transmission of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous for the radio. A full-duplex radio may include an interference management unit that reduces and / or substantially eliminates self-interference by means of hardware (e.g., chokes) or by signal processing by a processor (e.g., a separate processor (not shown) or by the processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio that transmits and receives some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) or downlink (e.g., for reception)).

[0184] Fig. 15C 1 is a system diagram showing the RAN 104 and the CN 106 according to an embodiment. As described above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c using an E-UTRA radio technology over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0185] The RAN 104 may include eNode-Bs 160a, 160b, 160c, however it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. Each of the eNode-Bs 160a, 160b, 160c may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, for example, the eNode-B 160a may use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a.

[0186] Each eNodeB 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, etc. Fig. 15C As shown, the eNode-Bs 160a, 160b, 160c may communicate with each other via an X2 interface.

[0187] Fig. 15C The illustrated CN 106 may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. Although each of the foregoing components is described as being part of the CN 106, it should be appreciated that any of these components may be owned and / or operated by an entity other than the CN operator.

[0188] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, performing bearer activation / deactivation processing, and selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0189] The SGW 164 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 may also perform other functions, such as anchoring the user plane during inter-eNB handovers, triggering paging processing when DL data is available for the WTRUs 102a, 102b, 102c, and managing and storing the contexts of the WTRUs 102a, 102b, 102c, and the like.

[0190] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0191] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include or communicate with an IP gateway, such as an IP Multimedia Subsystem (IMS) server, and the IP gateway may serve as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers.

[0192] Although in Figures 15A-15D While the WTRU is described as a wireless terminal, it should be appreciated that in certain typical embodiments, such a terminal may use a (eg, temporary or permanent) wired communication interface with a communication network.

[0193] In a typical embodiment, the other network 112 may be a WLAN.

[0194] A WLAN using an infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may access or be connected to a distributed system (DS) or other types of wired / wireless networks that send services into and / or out of the BSS. Services originating from outside the BSS and destined for the STA may be reached by the AP and delivered to the STA. Services originating from the STA and destined for a destination outside the BSS may be sent to the AP for delivery to the corresponding destination. Services between STAs within the BSS may be sent through the AP, for example, the source STA may send services to the AP and the AP may deliver services to the destination STA. Services between STAs within the BSS may be considered and / or referred to as point-to-point services. The point-to-point services may be sent using a direct link establishment (DLS) between the source and destination STAs (e.g., directly therebetween). In certain typical embodiments, the DLS may use 802.11e DLS or 802.11z channelized DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs (eg, all STAs) within or using the IBSS may communicate directly with each other. Here, the IBSS communication mode may sometimes be referred to as an "ad hoc" communication mode.

[0195] When using the 802.11ac infrastructure mode of operation or a similar mode of operation, the AP may transmit a beacon on a fixed channel (e.g., a primary channel). The primary channel may have a fixed width (e.g., a bandwidth of 20 MHz) or a width that is dynamically set with the aid of signaling. The primary channel may be a working channel of the BSS and may be used by STAs to establish a connection with the AP. In certain typical embodiments, carrier sense multiple access (CSMA / CA) with collision avoidance (e.g., in an 802.11 system) may be implemented. For CSMA / CA, STAs (e.g., each STA) including the AP may sense the primary channel. If a particular STA senses / detects and / or determines that the primary channel is busy, the particular STA may back off. In a specified BSS, one STA (e.g., only one station) may transmit at any given time.

[0196] A high throughput (HT) STA may communicate using a 40 MHz wide channel (eg, by combining a 20 MHz wide primary channel with a 20 MHz wide adjacent or non-adjacent channel to form a 40 MHz wide channel).

[0197] Very high throughput (VHT) STA can support channels with widths of 20MHz, 40MHz, 80MHz and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining continuous 20MHz channels. A 160MHz channel can be formed by combining 8 continuous 20MHz channels or by combining two discontinuous 80MHz channels (this combination can be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, the data can be transmitted and passed through a segment parser, which can separate the data into two streams. Inverse fast Fourier transform (IFFT) processing and time domain processing can be performed separately on each stream. The stream can be mapped on two 80MHz channels, and the data can be transmitted by the STA performing the transmission. At the receiver of the STA performing the reception, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the medium access control (MAC).

[0198] 802.11af and 802.11ah support working modes below 1 GHz. Compared with 802.11n and 802.11ac, the channel working bandwidth and carrier used in 802.11af and 802.11ah are reduced. 802.11af supports 5MHz, 10MHz and 20MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz and 16MHz bandwidths using non-TVWS spectrum. According to certain typical embodiments, 802.11ah can support instrument type control / machine type communication, such as MTC devices in macro coverage areas. MTC can have certain capabilities, such as limited capabilities including support (e.g., only support) certain and / or limited bandwidths. MTC devices can include a battery, and the battery life of the battery is higher than a threshold (e.g., for maintaining a very long battery life).

[0199] For WLAN systems that can support multiple channels and channel bandwidths (e.g., 802.11n, 802.11ac, 802.11af, and 802.11ah), the WLAN system includes a channel that can be designated as a primary channel. The bandwidth of the primary channel can be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by a certain STA, where the STA originates from all STAs operating in the BSS that supports the minimum bandwidth operating mode. In the example of 802.11ah, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz and / or other channel bandwidth operating modes, for STAs (e.g., MTC-type devices) that support (e.g., only support) 1MHz mode, the width of the primary channel can be 1MHz. Carrier sensing and / or network allocation vector (NAV) settings can depend on the state of the primary channel. If the primary channel is busy (eg, because a STA (which only supports 1 MHz operating mode) is transmitting to the AP), the entire available band may be considered busy even though most of the band remains idle and available for use.

[0200] In the United States, the available frequency band for 802.11ah is 902MHz to 928MHz. In South Korea, the available frequency band is 917.5MHz to 923.5MHz. In Japan, the available frequency band is 916.5MHz to 927.5MHz. Depending on the country code, the total bandwidth available for 802.11ah is 6MHz to 26MHz.

[0201] Fig.15D 1 is a system diagram showing the RAN 113 and the CN 115 according to an embodiment. As described above, the RAN 113 may communicate with the WTRUs 102a, 102b, 102c using NR radio technology over the air interface 116. The RAN 113 may also communicate with the CN 115.

[0202] The RAN 113 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with the embodiments. Each gNB 180a, 180b, 180c may include one or more transceivers to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, the gNBs 180a, 180b may use beamforming processing to transmit and / or receive signals to and / or from the gNBs 180a, 180b, 180c. Thus, for example, the gNB 180a may use multiple antennas to transmit wireless signals to the WTRU 102a and / or receive wireless signals from the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit a plurality of component carriers (not shown) to the WTRU 102a. A subset of these component carriers may be on an unlicensed spectrum while the remaining component carriers may be on a licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c may implement coordinated multi-point (CoMP) technology. For example, the WTRU 102a may receive coordinated transmissions from the gNB 180a and gNB 180b (and / or gNB 180c).

[0203] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may be different for different transmissions, different cells, and / or different portions of the radio transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of different or scalable lengths (e.g., containing different numbers of OFDM symbols and / or varying absolute time lengths).

[0204] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without accessing other RANs (e.g., the eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchors. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRU 102a, 102b, 102c may communicate / connect to the gNB 180a, 180b, 180c while communicating / connecting to another RAN (e.g., the eNode-B 160a, 160b, 160c). For example, the WTRU 102a, 102b, 102c may communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c in a substantially simultaneous manner by implementing the DC principle. In a non-standalone configuration, the eNode-B 160a, 160b, 160c may act as a mobility anchor for the WTRU 102a, 102b, 102c, and the gNB 180a, 180b, 180c may provide additional coverage and / or throughput to serve the WTRU 102a, 102b, 102c.

[0205] Each gNB 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, support network slicing, implement dual connectivity, implement interworking between NR and E-UTRA, route user plane data to user plane functions (UPFs) 184a, 184b, and route control plane information to access and mobility management functions (AMFs) 182a, 182b, and the like. Fig.15D As shown, gNBs 180a, 180b, and 180c can communicate with each other through the Xn interface.

[0206] Fig.15DThe CN 115 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and may include a data network (DN) 185a, 185b. Although each of the aforementioned components is described as part of the CN 115, it should be understood that any of these components may be owned and / or operated by entities other than the CN operator.

[0207] The AMF 182a, 182b may be connected to one or more gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting a specific SMF 183a, 183b, managing registration areas, terminating NAS signaling, and mobility management, etc. The AMF 182a, 182b may use network slicing processing to customize the CN support provided to the WTRU 102a, 102b, 102c based on the type of service used by the WTRU 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, and / or services for machine type communication (MTC) access, etc. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) using other radio technologies (e.g., LTE, LTE-A, LTE-APro, and / or non-3GPP access technologies such as WiFi).

[0208] The SMF 183a, 183b may be connected to the AMF 182a, 182b in the CN 115 via the N11 interface. The SMF 183a, 183b may also be connected to the UPF 184a, 184b in the CN 115 via the N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b, and may configure traffic routing through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions such as managing and allocating WTRU / UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0209] The UPF 184a, 184b can be connected to one or more gNBs 180a, 180b, 180c in the RAN 113 via the N3 interface, which can provide the WTRUs 102a, 102b, 102c with access to packet-switched networks (e.g., the Internet 110) to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b can perform other functions such as routing and forwarding packets, implementing user plane policies, supporting multi-host PDU sessions, processing user plane QoS, buffering downlink packets, and providing mobility anchor processing, etc.

[0210] The CN 115 may facilitate communications with other networks. For example, the CN 115 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 115 and the PSTN 108. In addition, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to local DNs 185a, 185b via an N3 interface connected to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the data networks (DNs) 185a, 185b and through the UPFs 184a, 184b.

[0211] In view of Fig.15A --15D and about Figures 15A-15D , one or more or all of the functions described herein with reference to one or more of the following may be performed by one or more simulation devices (not shown): WTRU 102a-d, base station 114a-b, eNodeB 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device(s) described herein. These simulation devices may be one or more devices configured to simulate one or more or all of the functions herein. For example, these simulation devices may be used to test other devices and / or simulate network and / or WTRU functions.

[0212] The simulation device can be designed to implement one or more tests about other devices in a laboratory environment and / or an operator network environment. For example, the one or more simulation devices can perform one or more or all functions while being implemented and / or deployed as a part of a wired and / or wireless communication network in whole or in part to test other devices inside the communication network. The one or more simulation devices can perform one or more or all functions while being temporarily implemented / deployed as a part of a wired and / or wireless communication network. The simulation device can be directly coupled to other equipment to perform the test, and / or can use over-the-air wireless communication to perform the test.

[0213] The one or more simulation devices can perform one or more functions, including all functions, while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test lab and / or a test scenario of a wired and / or wireless communication network that is not deployed (e.g., tested) to implement tests on one or more components. The one or more simulation devices can be test devices. The simulation device can transmit and / or receive data using direct RF coupling and / or wireless communication with the aid of RF circuits (as an example, the circuits can include one or more antennas).

[0214] Thus, systems and implementations for defining rectangular picture regions in a video data stream and rendering corresponding pictures are described herein. A computing system, which may be, for example, a wireless transmit and receive unit (WTRU), may be programmed to receive a video bitstream including a picture having a picture header. The received video bitstream may be, for example, Versatile Video Coding (VVC) formatted data. The computing system may identify a picture parameter set (PPS) including data specifying a structure of the picture based on a picture parameter set identifier in the picture header.

[0215] The computing system may determine, based on the data specifying the structure of the picture, an identifier corresponding to the defined rectangular area in the picture and a tile index of the upper left tile in the defined rectangular area. For example, the computing system may parse the data specifying the structure of the picture for the identifier corresponding to the defined rectangular area and for the tile index of the upper left tile. The computing system may determine, based on the identifier corresponding to the defined rectangular area and the tile index of the upper left tile in the defined rectangular area, one or more tiles included in the defined rectangular area.

[0216] The computing system may reconstruct the picture including a sub-picture including the defined rectangular area based on the identifier corresponding to the defined rectangular area. The computing system may render the sub-picture in the defined rectangular area.

[0217] It should be understood that although illustrative implementations have been disclosed, the scope of potential implementations is not limited to those explicitly set forth. For example, although the system has been described with reference to specific terms such as CTU, tile, tile group, etc., the contemplated embodiments extend beyond implementations using the specific terms described herein. Although features and elements are described herein in particular combinations, each feature or element may be used alone without the other features and elements, and / or in various combinations with or without the other features and elements.

[0218] It should be understood that the entity performing the processes described herein may be a logical entity that can be implemented in the form of software (i.e., computer executable instructions) stored in the memory of a mobile device, network node, or computer system and executed on its processor. That is, the method (one or more) may be implemented in the form of software (i.e., computer executable instructions) stored in the memory of a mobile device and / or a network node (such as a node or computer system), which when executed by the processor of the node performs the process in question. It should also be understood that any sending and receiving processes shown in the figure may be performed by the communication circuitry of the node under the control of the processor of the node and the computer executable instructions (e.g., software) executed by it.

[0219] The various techniques described herein can be implemented in combination with hardware or software or in combination with a combination of the two in appropriate circumstances. Therefore, the methods and devices of the subject matter described herein or some aspects or parts thereof can take the form of program code (i.e., instructions) contained in tangible media such as flash drives, CD-ROMs, hard disk drives, or any other machine-readable storage media, wherein when the program code is loaded into a machine such as a computer and executed by it, the machine becomes a device for implementing the subject matter described herein. In the case where the program code is stored on a medium, it may be a case where the program code in question is stored on one or more media that jointly perform the action in question, that is, one or more media adopted together contain codes for performing the action, but in the case where there is more than one single medium, it is not required that any particular part of the code is stored on any particular medium. In the case where the program code is executed on a programmable device, the computing device generally includes a processor, a storage medium readable by the processor (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device. One or more programs, which can be implemented or utilized in conjunction with the process described in the subject matter described herein, for example, by using an API, or a reusable control, etc. Such a program can be implemented with a high-level process or an object-oriented programming language to communicate with a computer system. However, if desired, the program(s) may be implemented in assembly language or machine language. In any case, the language may be a compiled or interpreted language and combined with hardware implementation.

[0220] Although example embodiments may involve utilizing aspects of the subject matter described herein in the context of one or more independent computing systems, the subject matter described herein is not limited thereto, but may be implemented in conjunction with any computing environment such as a network or distributed computing environment. In addition, aspects of the subject matter described herein may be implemented in or across multiple processing chips or devices, and storage may similarly be implemented across multiple devices. Such devices may include personal computers, network servers, handheld devices, supercomputers, or computers integrated into other systems such as automobiles and aircraft.

[0221] In describing the illustrative implementations of the subject matter of the present disclosure, as shown in the accompanying drawings, specific terminology is employed for the sake of clarity. However, the claimed subject matter is not intended to be limited to the specific terminology so selected, and it is understood that each specific element includes all technical equivalents that operate in a similar manner to achieve similar purposes. The details described here are exemplary and do not limit the scope of the application.

[0222] Although the features and elements are described above in specific combinations, it will be understood by those skilled in the art that each feature element may be used alone or in any combination with other features and elements. In addition, the processes described herein may be implemented in a computer program, software, and / or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, buffer memory, semiconductor memory devices, magnetic media (e.g., internal hard disks and removable disks), magneto-optical media, and optical media (e.g., CD-ROM disks and digital versatile disks (DVDs)). A processor associated with software may be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method for decoding an image, the method comprising: receiving a bitstream including a picture and a picture parameter set; identifying structure data regarding a structure of the picture based on the picture parameter set; as well as Based on the structure data, at least a portion of the picture is reconstructed.

2. A method for encoding an image, the method comprising: determining a picture parameter set, the picture parameter set comprising structure data regarding a structure of the picture; encoding the picture based on the structure data; as well as A bitstream including the picture and the picture parameter set is generated.

3. An apparatus for decoding an image, the apparatus comprising one or more processors, the one or more processors being configured to perform: receiving a bitstream including a picture and a picture parameter set; identifying structure data regarding a structure of the picture based on the picture parameter set; as well as Based on the structure of the picture, at least a portion of the picture is reconstructed.

4. An apparatus for encoding an image, the apparatus comprising one or more processors, the one or more processors being configured to perform: determining a picture parameter set, the picture parameter set comprising structure data regarding a structure of the picture; encoding the picture based on the structure data; as well as A bitstream including the picture and the picture parameter set is generated.

5. A computer readable medium comprising software code instructions for performing the method according to any one of claims 1 or 2 when the software code instructions are executed by one or more processors.

Images