Tile group partitioning

Abstract

To provide a system for defining a rectangular picture area in a video data stream and rendering a corresponding picture.SOLUTION: A system may identify a defined rectangular picture area and render video corresponding to the defined rectangular picture area. The system may receive a video bitstream comprising a picture having a header and may receive data specifying a structure of the picture. The system may parse the data specifying the structure of the picture for an identifier corresponding to a defined rectangular area in a first picture and for a tile index of a top left tile in the defined rectangular area. The system may determine one or more tiles comprised in the defined rectangular area based on the identifier corresponding to the defined rectangular area and the tile index of the top left tile.SELECTED DRAWING: Figure 7

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 62 / 781,749, filed December 19, 2018, entitled "Tile Group Partitioning," and U.S. Provisional Patent Application No. 62 / 775,130, filed December 4, 2018, entitled "Tile Group Partitioning," the contents of both of which are incorporated herein by reference in their entireties. [Background technology]

[0002] 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 called coding tree units (CTUs). Larger portions of a picture may be referred to as tiles, and tiles may be defined based on CTUs. Multiple tiles may be referred to as a tile group and may be referenced together as a tile group. The defined structure allows portions of a picture within a video stream to be specifically referenced for purposes of storing and communicating the video. Summary of the Invention

[0003] Described herein are systems and implementations for defining rectangular picture areas in a video data stream and rendering corresponding pictures. The computing system may be, for example, a wireless transmit / receive unit (WTRU) and may be programmed to receive a video bitstream including pictures with picture headers. The received video bitstream may be, for example, Versatile Video Coding (VVC) formatted data. The computing system may identify a picture parameter set (PPS) containing data defining the structure of the picture based on a picture parameter set identifier in the picture header.

[0004] The computing system may determine, based on the data defining the structure of the picture, an identifier corresponding to a defined rectangular area within the picture, and may determine, based on the data defining the structure of the picture, a tile index of a top-left tile within the determined rectangular area. For example, the computing system may parse the data defining the structure of the picture for the identifier corresponding to the defined rectangular area and the tile index of the top-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 top-left tile within the defined rectangular area.

[0005] The computing system may reconstruct the picture including the sub-picture that includes the defined rectangular area based on the identifier corresponding to the defined rectangular area. The computing system may render the sub-picture within the defined rectangular area.

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

[0007] The motion-constrained tile set may enable the tile set to be decoded (e.g., decoded independently) from other tiles that are excluded from the set. 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 an identifier corresponding to the defined rectangular area.

[0008] This Summary is provided to introduce a selection of concepts in a simplified form that are further described in the Detailed Description. This Summary is not intended to limit the scope of the claimed subject matter. Other features are also described herein.

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

[0010] [Figure 1] 1 shows an example of picture partitioning. [Figure 2] 1 shows an example of a motion-constrained tile set (MCTS). [Figure 3] An example of merging MCTS-based region tracks is shown. [Figure 4] An example of an extractor track that combines MCTS from bitstreams of different resolutions is shown. [Figure 5] 1 shows an example of a cube mapping frame. [Figure 6] 1 shows an example of tile group partitioning. [Figure 7] 1 shows examples of tile group grids and tile grid partitioning. [Figure 8] 10 illustrates an example of a parsing process for a middlebox and / or a client. [Figure 9] 10 shows an example of a tile group scanning order. [Figure 10A] 10 shows an example of an implementation of CTB scanning. [Figure 10B] 10 shows an example of an implementation of CTB scanning. [Figure 10C] 10 shows an example of an implementation of CTB scanning. [Figure 11A] 10 shows examples of implementations of tile raster scanning and tile group scanning. [Figure 11B] 10 shows examples of implementations of tile raster scanning and tile group scanning. [Figure 11C] 10 shows examples of implementations of tile raster scanning and tile group scanning. [Figure 12A] Examples of CTB raster scanning and tile group scanning are shown. [Figure 12B] Examples of CTB raster scanning and tile group scanning are shown. [Figure 12C] Examples of CTB raster scanning and tile group scanning are shown. [Figure 13] 10 shows an example of merging sub-picture tile groups based on MCTS. [Figure 14] 10 shows an example of MCTS-based subpicture tile group extraction and repositioning. [Figure 15A] 1 is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 15B]15B is a system diagram illustrating an example of a wireless transmit / receive unit (WTRU) that may be used within the communications system shown in FIG. 15A, according to an embodiment. [Figure 15C] 15B is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system illustrated in FIG. 15A, according to an embodiment. [Figure 15D] 15B is a system diagram illustrating a further example of a RAN and a further example of a CN that can be used within the communication system illustrated in FIG. 15A, according to an embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0011] Techniques are described for identifying a defined rectangular picture area in a video stream and rendering video corresponding to the defined rectangular picture area. A system may be programmed to receive a video bitstream including a picture having a header. The system may also receive data defining a structure of the picture. The system may parse the data defining the structure of the picture for an identifier corresponding to the defined rectangular area in a first picture and a tile index of a top left tile within 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 top left tile within the defined rectangular area. The system may reconstruct a picture including a sub-picture that includes the defined rectangular area based on the identifier corresponding to the defined rectangular area. The computing system may render the sub-picture within the defined rectangular area.

[0012] A picture may be partitioned into one or more tile columns and tile rows. The tile syntax and / or decoding process may remove 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 enable tiles to have independent relationships to other tiles in a reference picture for inter-picture prediction. If more than one tile is included in a slice, an entry point byte offset for (e.g., each) tile other than the first tile in the slice may be signaled in the slice header.

[0013] A tile group may be or contain a slice. A tile group may be or contain 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 to the beginning of (e.g., each) tile. Figure 1 shows an example of picture partitioning. As shown in Figure 1, a picture with 18x12 coding tree units (CTUs), e.g., luma CTUs, may be partitioned into 12 tiles and 3 tile groups.

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

[0015] [Table 1]

[0016] Table 2 shows an example of tile group header syntax. The syntax element tile_group_address can specify the index of the first tile in the tile group if there is more than one tile in the picture. The syntax element num_tiles_in_tile_group_minus1 plus 1 can specify the number of tiles in the tile group. The syntax element entry_point_offset_minus1[i] plus 1 can specify the ith tile entry point offset in bytes.

[0017] The first byte and last byte of the kth tile in the tile group data following the tile group header may be derived by using equation (1) and / or equation (2).

[0018]

number

[0019]

number

[0020] [Table 2]

[0021] A set of tiles covering a picture region may be coded as a motion constrained tile set (MCTS). Motion vectors may be constrained to the MCTS. For example, motion vectors may be constrained to the MCTS, and a decoder may decode a subset of the bitstream including the MCTS, e.g., instead of and / or in addition to decoding one or more (e.g., all) bits for the entire picture. 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 nesting SEI message. The SEI message may indicate the MCTS position and / or characteristics and enable extraction of a subset of the motion constrained tile (MCT) from the bitstream. The SEI message may indicate repositioning of the subset of the MCT to another bitstream.

[0022] Table 3 shows an example of a temporal MCTS SEI message. For example, the syntax element mcts_id[i] may specify the identification number of the ith 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 positions of the top-left tile and the bottom-right tile of the jth rectangular region of tiles in the ith MCTS, respectively. An MCTS may have a non-rectangular shape. Figure 2 shows an example of an MCTS. As shown in Figure 2, an MCTS may include several rectangular tile regions, e.g., tile region 1 and tile region 2, where tile region 1 and tile region 2 together give the MCTS a non-rectangular shape.

[0023] [Table 3]

[0024] The MCTS Extraction Information Set SEI message can provide information (e.g., auxiliary information) about MCTS sub-bitstream extraction. For example, the MCTS Extraction Information Set SEI message can generate a conforming bitstream for the MCTS. The information may include, for example, several extraction information sets (e.g., num_info_sets_minus1), several 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) to be used during the MCTS sub-bitstream extraction process. The syntax element output_slice_segment_address can 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, inclusive. The MCTS may be used in region-of-interest dependent omnidirectional video processing and / or viewport dependent omnidirectional video processing.

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

[0026] A viewport-dependent scheme based on equal-resolution MCTSs may code the same omnidirectional video content into one or more bitstreams (e.g., HEVC bitstreams) at different picture qualities and / or bitrates. Each MCTS (e.g., each) may be included in a region track, and an extractor track may be generated. An OMAF player may select the quality at which each subpicture track (e.g., each) is received, for example, based on the viewing orientation. Figure 3 shows an example of merging region tracks based on equal-resolution MCTSs (e.g., region tracks based on HEVC MCTSs). For example, as shown in Figure 3, an OMAF player may receive MCTS tracks 1, 2, 5, and 6 at a particular quality (e.g., quality 1) and region tracks 3, 4, 7, and 8 at another quality (e.g., quality 2). The extractor tracks may be used to reconstruct a bitstream that can be decoded by a decoder (e.g., an HEVC decoder). Tiles of a reconstructed bitstream (eg, an HEVC bitstream) with MCTS at different qualities may be signaled by a tile syntax (eg, an HEVC tile syntax).

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

[0028] FIG. 4 shows an example of an extractor track that combines MCTSs from bitstreams of different resolutions. For example, FIG. 4 shows a scheme for achieving 5K effective equirectangular projection (ERP) resolution with a viewport-dependent video profile. Content may be coded at two spatial resolutions, such as 5120×2560 and 2560×1280, and with 4×2 and 2×2 tile grids, respectively. An MCTS may be coded for (e.g., each) tile position. Two different sets of low-resolution content may be coded, distinguished by a 90-degree yaw difference in rotation angle. Four MCTSs from the high-resolution bitstream and two MCTSs from the low-resolution bitstream may be selected to form a viewport-adaptive extractor track.

[0029] 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 enable transcoding operations (e.g., simple transcoding operations). For example, a region of interest (ROI) may be decoded (e.g., decoded independently) or a sub-picture from a coded video sequence having a large picture size may be extracted, and the result converted into a coded video sequence. The result may be converted into a video sequence coded for a smaller picture size, for example, by modifying high-level syntax and / or fully decoding and recoding low-level data (e.g., data at the CTU level or below). Tile groups can form regions of any shape, which can be flexible, but may not support sub-picture-based partitioning. Rectangular tile groups can support region-based video applications. For example, rectangular tile groups may be applied to specific regions and / or planes within omnidirectional video, such as in equirectangular and / or cube-map projection formats. Figure 5 shows an example of a cube-mapped frame. As shown in Figure 5, an example of a cube-mapped frame may be a 3x2 cube-mapped picture. Rectangular tile groups may be applied to surfaces or sub-pictures for independent decoding and rendering and / or sub-bitstream extraction to form extractor tracks.

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

[0031] The computing system may determine, based on the data defining the structure of the picture, an identifier corresponding to a defined rectangular area within the picture and a tile index of a top-left tile within the defined rectangular area. For example, the computing system may parse the data defining the structure of the picture for the identifier corresponding to the defined rectangular area and the tile index of the top-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 top-left tile within the defined rectangular area.

[0032] The computing system may reconstruct the picture including the sub-picture that includes the defined rectangular area based on the identifier corresponding to the defined rectangular area. The computing system may render the sub-picture within the defined rectangular area.

[0033] A rectangular tile group structure may be used to enable region-of-interest and / or sub-picture based video applications. Bottom-to-top and top-to-bottom tile group partitioning may be used. MCTS may be enabled for tile groups to support ROI and / or sub-picture extraction and repositioning.

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

[0035] Bottom-to-top tile group partitioning may be employed to provide a rectangular tile group structure. A tile group may be a series of tiles in a tile raster scan of a picture. A tile may be a series of CTUs that cover an area of ​​the picture (e.g., a rectangular area of ​​the picture). A tile group may be a set of tiles that cover a picture area (e.g., a rectangular picture area). In an embodiment, the boundary of a tile group may span the picture. In an embodiment, the boundary of a tile group may be within the picture (e.g., not span the picture). Bottom-to-top tile group partitioning may divide a picture into tiles and group one or more (e.g., multiple) tiles into a tile group.

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

[0037] [Table 4]

[0038] The syntax element tile_group_id can specify the identification number of the associated tile group. The value of the tile_group_id syntax element can be between 0 and 2, inclusive. 32 It may range from -2. A profile and / or level may define a maximum number of tile groups.

[0039] The syntax elements tile_group_start_address and tile_group_end_address can specify the location of the first tile (e.g., or the top-left tile) and the last tile (e.g., or the bottom-right tile) within the rectangular area of ​​the associated tile group. The address values ​​may, for example, be the addresses of the associated tiles in a tile raster scan of the picture.

[0040] If a picture contains a tile (e.g., a single tile) or if a picture contains a tile group (e.g., a single tile group), signaling of the tile group start address may be skipped. If the tile group contains a single tile, signaling of 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).

[0041] FIG. 6 shows an example of tile group partitioning. As shown in FIG. 6, a picture may be partitioned into 6×4 CTBs or 3×2 tiles, where a tile can cover a 2×2 CTB. A tile group can cover an integer number of tiles. The location and / or shape of a tile group may be specified. For example, the location and / or shape of a tile group may be specified by the address of the first tile and / or the last tile in a tile raster scan of a picture. For example, the location and shape of the top right tile group shown in FIG. 6(a) may be signaled by Tile #3 as the starting address. The location and shape of the right tile group shown in FIG. 6(b) may be signaled by Tile #3 as the starting address and Tile #6 as the ending address.

[0042] One or more syntax elements, such as tile_group_id, tile_group_start_address, tile_group_end_address, and / or num_tiles_in_tile_group_minus1, for (e.g., each) tile group may be signaled (e.g., explicitly signaled). For example, the tile group syntax elements may be signaled in a parameter set (e.g., PPS, SPS, and / or VPS, etc.) or a picture header to indicate, for example, the tile group grid for sub-picture extraction. Sub-pictures may be coded as tile group sub-bitstreams. A middlebox, extractor, and / or client may determine the tile group grid by parsing (e.g., directly) the parameter set (e.g., PPS) or picture header. In an embodiment, 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 embodiment, the middlebox, extractor, and / or client may extract the sub-bitstream via the sub-bitstream byte offset indication (e.g., extract directly). Signaling the tile group address (e.g., in the tile group header) may configure the middlebox and / or client to parse the tile group header. Parsing the tile group header may be performed to understand the tile group distribution within the picture and / or determine which tile group data can be extracted.

[0043] FIG. 7 shows an example of a tile group partitioning grid and a tile partitioning grid. FIG. 7 shows an example of tile group partitioning. A picture may be partitioned into a 4x4 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 group of 1x4 tile grids, tile group #2 may include a group of 2x4 tile grids, and tile group #3 may include a group of 1x4 tile grids. A bitstream may be structured into a series of tile group sub-bitstreams. A tile group sub-bitstream may include a series of tile sub-bitstreams. A tile grid within a tile group (e.g., a local tile grid) may be signaled (e.g., signaled independently). 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 can aid the subpicture extraction and repositioning process.

[0044] If a middlebox or client plans to extract an ROI located in tile #8 and / or tile #12, which are circled in FIG. 7, the middlebox and / or client may parse the parameter set to understand the tile partitioning structure (e.g., first parsing a parameter set such as a PPS) and may determine whether the ROI is in tile #8 and / or tile #12. The middlebox and / or client may parse one or more (e.g., all three) headers of the tile group to determine, for example, 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 such as a PPS or a picture header). Based on the tile group grid (e.g., in a parameter set such as a PPS or a picture header), the middlebox and / or client can identify the ROI as being covered by tile group #3 after parsing the parameter set (e.g., PPS) and / or the picture header (e.g., immediately after). Based on the tile group grid (e.g., in the PPS parameter set or picture header), the middlebox and / or client may extract the sub-bitstream of tile group #3 according to the tile group entry point indicator, and may, for example, extract (e.g., further extract) tile #8 and / or tile #12 based on the tile entry point indicator.

[0045] [Table 5]

[0046] Table 5 shows an example of a tile group partitioning structure in a PPS and / or picture header as described herein. The extractor can identify the tile group grid from the structure in the PPS and / or picture header. The extractor may extract the associated subpictures or tile group sub-bitstreams. For example, the extractor may extract the associated subpictures or tile group sub-bitstreams based on the syntax element tile_group_id or the tile group entry point if (e.g., each) subpicture is coded in a tile group. When an extractor track (e.g., a new extractor track) is formed, the middlebox and / or 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-bitstreams). The client may compose and / or render subpictures together by inferring the tile group grid structure in the parameter set (e.g., PPS) or picture header.

[0047] In an embodiment, the number of tile groups indicated in a parameter set (e.g., a PPS) or a picture header may define a region of interest within a picture (e.g., a rectangular region of interest) and / or a sub-picture within a picture. Areas of a picture may not be covered by signaled tile groups (e.g., explicitly signaled tile groups as described herein). Areas not covered by signaled tile groups (e.g., explicitly signaled tile groups) may form tile groups, and the tile groups may be in non-rectangular shapes.

[0048] The syntax element tile_group_offset_len_minus1 plus 1 may specify the length (e.g., 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.

[0049] The syntax element tile_group_entry_point_offset_minus1[i] plus 1 may specify the ith tile group entry point offset (e.g., in bytes) and may be represented by the syntax element tile_group_offset_len_minus1 plus 1 bit. The first byte of the tile group header may be considered byte 0. If the first byte is present, an emulation prevention byte appearing in the tile group header portion and tile group data portion of the coded tile group network abstraction layer (NAL) unit may be counted. For example, the emulation prevention byte may be counted as part of the tile group header and / or tile group data (e.g., for the subset identifier). Subset 0 may include bytes 0 of the coded tile group header through the syntax element tile_group_entry_point_offset_minus1[0], inclusive. The tile group data for such subset k (e.g., k in the range of 1 to num_tile_group_minus1-1, inclusive) may include bytes firstByte[k] through lastByte[k], inclusive, of the coded tile group header and associated tile group data, having 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 set forth in equations (3) and (4), respectively.

[0050]

number

[0051]

number

[0052] The syntax element tile_group_offset_len_minus1 and / or the syntax element tile_group_entry_point_offset_minus1 may be signaled, for example, in a picture header as the values ​​change from picture to picture.

[0053] [Table 6]

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

[0055] In an embodiment, if the boundaries of a tile group 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 picture header. The tile group partitioning structure may be defined by tile group columns and tile group rows. A picture may be divided (e.g., uniformly) into tile group columns and tile group 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).

[0056] Table 7 shows an example of tile group grid syntax (e.g., for a PPS or picture header). The syntax element num_tile_group_columns_minus1 plus 1 can specify the number of tile group columns in a picture. The syntax element num_tile_group_rows_minus1 plus 1 can specify the number of tile group rows in a picture. If the tile groups are not uniformly distributed in the picture, the width and height of (e.g., each) tile group column and tile group 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_minus1.

[0057] The syntax element motion_constrain_enabled_flag equal to 1 may indicate that motion constraints may be applied to the tile group, or that motion constraints 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.

[0058] [Table 7]

[0059] A tile group ID and / or index may be defined. For example, the tile group ID and / or index may be defined in the order of the top-left tile raster scan address of the tile group of a picture. Figure 9 shows an example of a tile group scanning order based on, for example, the tile raster scan address. Figure 9 shows an example in which the tile group index may be set in the order of the address of the first tile (e.g., marked as X) of the tile group in the raster scan order of the picture.

[0060] The bottom-to-top tile group partitioning may include a coding tree block (CTB) raster scanning process and a CTB tile scanning process. A tile group may be or include a series of tiles in a tile raster scan of a picture. A CTB raster scanning transform and a CTB tile scanning transform may be applied. Tiles may not be grouped into tile groups (e.g., not grouped serially). The CTB raster scanning transform and the CTB tile scanning transform can support rectangular tile groups. Figures 10A, 10B, and 10C show examples of raster scanning and tile scanning processes. Figure 10A shows an example of a CTB raster scan of a picture. Figure 10B shows an example of a CTB tile scan for a tile group of a series of tiles in a tile raster scan of a picture. Figure 10C shows an example of a CTB tile scan using rectangular tile groups as described herein.

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

[0062] The lists tileGroupWidthInCTBs[i] and tileGroupHeightInCTBs[i] for i may range from 0 to num_tile_groups_minus1, inclusive. The lists tileGroupWidthInCTBs[i] and tileGroupHeightInCTBs[i] for i may specify the width and height of the ith tile group in units of CTBs and may be derived as follows:

[0063] [Table 8]

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

[0065] [Table 9]

[0066] The list tgRight[i] for i may range from 0 to num_tile_groups_minus1, inclusive. The list tgRight[i] for i may specify the position of the right boundary of the i-th tile group in units of CTBs, and may be derived as follows:

[0067] [Table 10]

[0068] The list tgTop[i] for i may range from 0 to num_tile_groups_minus1, inclusive. The list tgTop[i] for i may specify the position of the top boundary of the i-th tile group in units of CTBs and may be derived as follows:

[0069] [Table 11]

[0070] The list tgBot[i] for i may range from 0 to num_tile_groups_minus1, inclusive. The list tgBot[i] for i may specify the position of the right boundary of the i-th tile group in units of CTBs, and may be derived as follows:

[0071] [Table 12]

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

[0073] [Table 13]

[0074] Bottom-to-top tile group partitioning may involve a tile raster scanning transformation process and a tile group scanning transformation process. Tile group scanning may be a tile ordering that partitions a picture (e.g., a serial ordering of tiles) in which tiles are ordered (e.g., sequentially ordered) in a tile raster scan in a tile group. Tile raster scanning of a picture and tile scanning of a tile group transformation can support rectangular tile groups. Figures 11A, 11B, and 11C show examples of tile scanning processes. Figure 11A shows an example of a tile raster scan of a picture. Figure 11B shows an example of a tile group scan for serial tiles in a raster scan of a picture. Figure 11C shows an example of a tile group scan for rectangular tile groups described herein.

[0075] The list TileAddrRsToTGs[tileAddrRs] for tileAddrRs may range from 0 to NumTilesInPic-1, inclusive. The list TileAddrRsToTGs[tileAddrRs] for tileAddrRs may specify a conversion from 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 in the picture.

[0076] [Table 14]

[0077] The list TileAddrTGsToRs[tileAddrTGs] for tileAddrTGs may range from 0 to NumTilesInPic-1, inclusive. The list TileAddrTGsToRs[tileAddrTGs] for tileAddrTGs may specify a 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:

[0078] [Table 15]

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

[0080] [Table 16]

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

[0082] [Table 17]

[0083] Top-to-bottom tile group partitioning may be employed to provide a rectangular tile group structure. Top-to-bottom group tile partitioning may divide a picture into one or more tile groups. A tile group may include an integer number of CTBs (e.g., to cover a rectangular area). A tile group may be divided into one or more (e.g., multiple) tiles. The 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, and / or a tile group header. A different local tile grid may be signaled in a tile group header to override the default tile grid signaled in a parameter set (e.g., PPS) or a picture header.

[0084] (e.g., each) tile group in the top-down approach described herein may be a self-contained entity. For example, a tile group in the top-down approach described herein may be a self-contained 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 certain video applications, the middlebox and / or client may stitch one or more tile groups from different bitstreams and combine one or more tile groups from different bitstreams to form a bitstream (e.g., a new bitstream). The picture tile grid of a bitstream (e.g., a 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-down tile group approach may skip picture tile grid signaling, which may simplify the bitstream stitching process. The top-down tile group approach described herein may enable more types of tile group based sub-bitstream extraction, repositioning, and / or combinations thereof.

[0085] The tile group grid structure may be signaled (e.g., in a parameter set (e.g., PPS) and / or picture header). Table 9 shows an example of a tile group structure. The tile group position may be specified by the syntax element tile_group_start_address and / or the 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 (e.g., or the top-left CTB) in the CTB raster scan of the picture and the address of the last CTB (e.g., or the bottom-right CTB) in the CTB raster scan of the picture, respectively. A tile partitioning structure (e.g., specified in HEVC) or a flexible tile partitioning structure may be signaled in the syntax element tile_partitioning structure to indicate a default tile partitioning that may be applicable to (e.g., each) tile group.

[0086] [Table 18]

[0087] In an embodiment, the tile partitioning structure list 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 reference a particular list index to indicate a 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 can define a tile partitioning structure (e.g., a new tile partitioning structure) that is excluded from the tile partitioning list.

[0088] Table 10 shows an example of a tile partitioning list syntax structure. The syntax element tile_grid_override_enabled_flag equal to 1 can indicate that the tile group may or may not use a new tile grid (e.g., not included in the tile partitioning list).

[0089] [Table 19]

[0090] Table 11 shows an example of a tile partitioning reference field in a tile group header. Table 11 shows that a tile group can reference a partitioning structure signaled in a partitioning list or can use a new tile partitioning grid.

[0091] 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 in the tile group header. If the syntax element tile_grid_is_overrided is not present, the value of the tile_grid_is_overrided syntax element may be inferred to be 0.

[0092] [Table 20]

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

[0094] The tiles may be partitioned within (e.g., each) tile group. As one or more tiles are partitioned within (e.g., each) tile group, the CTB raster scanning process and the tile group scanning process may be defined as follows:

[0095] The top-to-bottom tile group partitioning may employ a CTB raster scanning transformation process and a tile scanning transformation process. The lists TileGroupWidthInCtbsY[i] and TileGroupHeightInCtbsY[i] for i may range from 0 to num_tile_groups_minus1, inclusive. The lists TileGroupWidthInCtbsY[i] and TileGroupHeightInCtbsY[i] for i may specify the width and height of the ith tile group unit of the CTB, and may be derived as follows:

[0096] [Table 21]

[0097] The list tgLeft[i] for i may range from 0 to num_tile_groups_minus1, inclusive. 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:

[0098] [Table 22]

[0099] The list tgRight[i] for i may range from 0 to num_tile_groups_minus1, inclusive. The list tgRight[i] for i may specify the position of the right boundary of the i-th tile group in units of CTBs, and may be derived as follows:

[0100] [Table 23]

[0101] The list tgTop[i] for i may range from 0 to num_tile_groups_minus1, inclusive. The list tgTop[i] for i may specify the position of the top boundary of the i-th tile group in units of CTBs and may be derived as follows:

[0102] [Table 24]

[0103] The list tgBot[i] for i may range from 0 to num_tile_groups_minus1, inclusive. The list tgBot[i] for i may specify the position of the right boundary of the i-th tile group in units of CTBs, and may be derived as follows:

[0104] [Table 25]

[0105] 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 ith tile group in units of CTBs, and may be derived as follows:

[0106] [Table 26]

[0107] The list rowHeight[j] for j may range from 0 to num_tile_rows_minus1, inclusive. The list rowHeight[j] for j may specify the height of the jth tile row in units of CTB, and may be derived as follows:

[0108] [Table 27]

[0109] 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 location of the boundary of the jth tile column of the ith tile group in units of CTBs, and may be derived as follows:

[0110] [Table 28]

[0111] 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 location of the boundary of the jth tile row of the ith tile group in units of CTBs, and may be derived as follows:

[0112] [Table 29]

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

[0114] [Table 30]

[0115] 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 CTB addresses in a tile scan to CTB addresses in a CTB raster scan of a picture, and may be derived as follows:

[0116] [Table 31]

[0117] 12A, 12B, and 12C show examples of CTB raster scanning and CTB tile group scanning. For example, a picture may be partitioned into an 8x4 CTB and three tile groups (e.g., as shown in FIGS. 12A-C). The first and third tile groups may contain tiles. The second tile group may contain 3x1 tiles. CTB raster scanning of a picture may be shown in FIG. 12A. Tile group partitioning may be shown in FIG. 12B. CTB tile scanning may be shown in FIG. 12C.

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

[0119] [Table 32]

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

[0121] Table 12 shows an example of 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, signaling may be carried in a parameter set (e.g., PPS), a picture header, and / or a tile group header to specify whether the tile group is motion constrained or not.

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

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

[0124] [Table 33]

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

[0126] Figure 13 shows an example of merging subpicture tile groups based on MCTSs of the same resolution. For example, Figure 13 shows that high-quality tile groups and low-quality tile groups may be extracted and the tile groups may be merged together to form a viewport-dependent bitstream, e.g., without rewriting the lower-level bitstreams. As shown in Figure 13, tile group sub-bitstreams associated with high-quality subpictures #2, #3, #6, and #7 from a bitstream having quality 2 may be extracted, and tile group sub-bitstreams associated with low-quality subpictures #1, #5, #4, and #8 from a bitstream having quality 1 may be extracted. The extracted subpictures may be merged to form a viewport-dependent bitstream (e.g., without rewriting the lower-level bitstreams). (E.g., each) subpicture may include subpictures of one or more (e.g., multiple) tiles. In an embodiment, the local tile grid within (e.g., each) tile group may be identical. In an embodiment, the local tile grid between different tile groups may not be identical. The picture level tile grid between the bitstream at quality 1 and the bitstream at quality 2 may be different.

[0127] The tile group grid may be signaled in a parameter set (e.g., PPS) and / or a picture header. Such that the tile group grid is signaled in a parameter set (e.g., PPS) or a picture header, the middlebox and / or client can identify the corresponding high-quality tile group and / or low-quality tile group after parsing the parameter set (e.g., PPS) and / or picture header, and can skip parsing the (e.g., individual) tile group headers. After extracting the (e.g., each) sub-bitstream based on the tile group entry points, the middlebox and / or client can merge the sub-bitstreams together without, for example, modifying the tile group header or tile group data, since the (e.g., each) tile group sub-bitstream is self-contained due to the local tile grid signaled in the tile group header. The middlebox and / or client may generate a new parameter set or picture header, for example, by replicating a similar tile group grid from the parameter set (e.g., PPS) or picture header of the source bitstream.

[0128] Figure 14 shows an example of extraction and repositioning of sub-picture tile groups based on MCTSs of different resolutions. For a viewport-dependent scheme based on MCTSs of multiple resolutions (e.g., as shown in Figure 14), the tile groups described herein can simplify sub-bitstream extraction and repositioning. For example, without rewriting the low-level bitstreams, the tile group grid in the PPS and the tile group entries in the picture header may be updated, and corresponding MCTS-based sub-picture tile groups may be merged together. Figure 14 shows an example in which the tile group grid can be changed in the merged bitstream (e.g., the new merged bitstream) while the low-level tile group headers and data can remain intact during extraction and merging. After parsing the parameter set (e.g., the PPS), the middlebox and / or client can 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-bitstreams based on, for example, the tile group entry points and may reposition the tile-group sub-bitstreams into new streams. The middlebox and / or client may generate a new VPS, SPS, and / or PPS according to the updated tile group partitioning structure shown in Figure 14. Because the local tile grid remains the same for (e.g., each) tile group before and after the extraction and repositioning, and the local tile grid is signaled within (e.g., each) tile group sub-bitstream, the extraction and repositioning process can skip rewriting the tile group sub-bitstreams.

[0129] 15A illustrates an exemplary 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 the multiple wireless users to access such content through sharing of system resources, including wireless bandwidth. For example, the communication system 100 may utilize 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-tailed unique word discrete Fourier transform spread OFDM (ZT UW DTS-S-OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, and filter bank multicarrier (FBMC).

[0130] 15A, communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106, public switched telephone network (PSTN) 108, Internet 110, and other networks 112, although it will be recognized that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a “station” and / or “STA,” may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspot or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain situations), consumer electronics devices, and devices operating on commercial and / or industrial wireless networks. Any of the WTRUs 102a, 102b, 102c, 102d may be referred to interchangeably as a UE.

[0131] The communications system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communications networks, such as the CN 106, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a NodeB, an eNodeB, a Home NodeB, a Home eNodeB, a gNB, an NR NodeB, a site controller, an access point (AP), a wireless router, etc. While the base stations 114a, 114b are each depicted as a single element, it will be understood that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0132] The base station 114a may be part of the RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and / or base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in the licensed spectrum, the unlicensed spectrum, or a combination of the licensed and unlicensed spectrum. A cell may provide coverage for wireless services in a particular geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the 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, one for each sector of the cell. In an embodiment, the base station 114a may utilize multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in desired spatial directions.

[0133] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over the 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).

[0134] More specifically, as described above, the communication system 100 may be a multiple-access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA. For example, the base station 114a and the WTRUs 102a, 102b, and 102c in the RAN 104 / 113 may establish the air interface 116 using Wideband CDMA (WCDMA) or may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA). 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 ​​Uplink (UL) Packet Access (HSUPA).

[0135] 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 LTE Advanced (LTE-A), and / or LTE Advanced Pro (LTE-A Pro).

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

[0137] 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 implement both LTE radio access and NR radio access, e.g., using a dual connectivity (DC) principle. Thus, the air interface utilized 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).

[0138] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a wireless technology such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-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).

[0139] 15A may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point and may utilize any suitable RAT to facilitate wireless connectivity in a localized area, such as a business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., used by drones), and a roadway. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. 15A, the base station 114b may have a direct connection to the Internet 110. Therefore, the base station 114b may not need to access the Internet 110 via the CN 106 / 115.

[0140] The RAN 104 / 113 may communicate with the CN 106 / 115, which may be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have various quality of service (QoS) requirements, such as different throughput, delay, error resilience, reliability, data throughput, and mobility requirements. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not shown in FIG. 15A , it will be understood that the RAN 104 / 113 and / or the CN 106 / 115 may communicate directly or indirectly with other RANs that utilize the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, the CN 106 / 115 may also communicate with another RAN (not shown) that utilizes GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0141] The CN 106 / 115 may also serve 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 providing plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) in the TCP / IP Internet protocol suite. The network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the network 112 may include another CN connected to one or more RANs that may utilize the same RAT as the RAN 104 / 113 or a different RAT.

[0142] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications 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.) For example, the WTRU 102c shown in FIG. 15A may be configured to communicate with a base station 114a, which may employ a cellular-based wireless technology, and with a base station 114b, which may utilize IEEE 802.11 wireless technology.

[0143] 15B is a system diagram illustrating an example WTRU 102. As shown in FIG. 15B, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be understood that the WTRU 102 may include any sub-combination of the above elements while remaining consistent with an embodiment.

[0144] The processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors in conjunction 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, etc. The processor 118 may perform signal coding, 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. While FIG. 15B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0145] The transmit / receive element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) over the air interface 116. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In an embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF and light signals. It will be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0146] 15B, the transmit / receive element 122 is depicted as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may utilize MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0147] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and demodulate signals received by the transmit / receive element 122. As mentioned above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as, for example, NR and IEEE 802.11.

[0148] The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit). The processor 118 may output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. Additionally, the processor 118 may obtain information from and store data in any type of suitable memory, such as non-removable memory 130 and / or removable memory 132. The non-removable memory 130 may include random access memory (RAM), 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, etc. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as located on a server or home computer (not shown).

[0149] The processor 118 may receive power from the power source 134 and may be configured to distribute and / or control the power to other components within 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 batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0150] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or instead of, information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 116 from base stations (e.g., base stations 114a, 114b) and / or may determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may obtain location information using any suitable location-determination method while remaining consistent with an embodiment.

[0151] The processor 118 may further be coupled to other peripherals 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 peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth module, a frequency modulation (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, and the like. The peripheral device 138 may include one or more sensors, which may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0152] The WTRU 102 may include a full-duplex radio where transmission and reception of some or all of the signals associated with a particular subframe (e.g., for both the UL (e.g., for transmission) and the downlink (e.g., for reception)) may be parallel and / or simultaneous. The full-duplex radio may include an interference management unit 139 to reduce and / or substantially eliminate self-interference via hardware (e.g., a choke) or via signal processing via a processor (e.g., a separate processor (not shown) or the processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio for transmission and reception of some or all of the signals (e.g., associated with a particular subframe for either the UL (e.g., for transmission) or the downlink (e.g., for reception)).

[0153] 15C is a system diagram showing the RAN 104 and the CN 106. As described above, the RAN 104 may employ E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also communicate with the CN 106.

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

[0155] Each of the eNodeBs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, etc. As shown in FIG. 15C, the eNodeBs 160a, 160b, 160c may communicate with each other over an X2 interface.

[0156] 15C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the above elements is depicted as part of the CN 106, it will be understood that any of these elements may be owned and / or operated by an entity different from the CN operator.

[0157] The MME 162 may be connected to each of the eNodeBs 160a, 160b, 160c in the RAN 104 via an S1 interface and may act as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during initial attach of the WTRUs 102a, 102b, 102c, etc. The MME 162 may 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.

[0158] The SGW 164 may be connected to each of the eNodeBs 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 perform other functions, such as anchoring the user plane during inter-eNodeB handover, triggering paging when DL data is available to the WTRUs 102a, 102b, 102c, and managing and storing the context of the WTRUs 102a, 102b, 102c.

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

[0160] 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 landline communication devices. For example, the CN 106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves 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 owned and / or operated by other service providers.

[0161] Although in Figures 15A-15D the WTRU is described as a wireless terminal, it is contemplated that in certain representative embodiments such a terminal may use a wired communication interface (e.g., temporary or permanent) with the communication network.

[0162] In an exemplary embodiment, the other network 112 may be a WLAN.

[0163] A WLAN in 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 have access to or interface with a distribution system (DS) or another type of wired / wireless network that carries traffic within and / or outside the BSS. Traffic originating from outside the BSS to a STA may arrive through the AP and be delivered to the STA. Traffic originating from a STA to a destination outside the BSS may be sent to the AP for delivery to the respective destination. Traffic between STAs within the BSS may be sent through the AP; for example, a source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent (e.g., directly) between a source STA and a destination STA using direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and STAs within or using an IBSS (e.g., all of the STAs) may communicate directly with each other. IBSS mode communication may sometimes be referred to herein as "ad hoc" mode communication.

[0164] When using the 802.11ac infrastructure mode of operation or a similar mode of operation, an AP may transmit beacons on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., a 20 MHz wide bandwidth) or a width dynamically set via signaling. The primary channel may be the operating channel of the BSS and may be used by STAs to establish a connection with the AP. In one representative embodiment, for example, in an 802.11 system, carrier sense multiple access with collision avoidance (CSMA / CA) may be implemented. With CSMA / CA, STAs (e.g., every STA), including the AP, may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. Within a given BSS, one STA (e.g., only one station) may transmit at any given time.

[0165] A high-throughput (HT) STA may use a 40-megahertz-wide channel for communication, for example, by combining a primary 20-megahertz channel with an adjacent or non-adjacent 20-megahertz channel to form a 40-megahertz-wide channel.

[0166] A very high throughput (VHT) STA may support channels that are 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide. A 40 MHz and / or 80 MHz channel may be formed by combining contiguous 20 MHz channels. A 160 MHz channel may be formed by combining eight contiguous 20 MHz channels or two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration. In the 80+80 configuration, after channel encoding, the data may be passed through a segment parser that may split the data into two streams. Inverse fast Fourier transform (IFFT) processing and time-domain processing may be performed separately on each stream. The streams may be mapped onto two 80 MHz channels, and the data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration may be reversed and the combined data may be sent to the media access control (MAC).

[0167] Sub-1 GHz mode operation is supported by 802.11af and 802.11ah. The channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to an embodiment, 802.11ah can support meter-type control / machine-type communication, such as MTC devices in macro coverage areas. MTC devices may have limited functionality, including, for example, support for certain bandwidths and / or limited bandwidths (e.g., only support for them). The MTC device may include a battery with a battery life above a threshold (eg, to maintain a very long battery life).

[0168] WLAN systems capable of supporting multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that may be designated as a primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in a BSS. The bandwidth of the primary channel may be set and / or limited by a STA that supports the smallest bandwidth operating mode among all STAs operating in the BSS. In the example of 802.11ah, for a STA (e.g., an MTC-type device) that supports (e.g., only supports) 1 MHz mode, the primary channel may be 1 MHz wide, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) setting may depend on the status of the primary channel. For example, if the primary channel is busy because a STA (that only supports a 1 MHz operating mode) is transmitting to the AP, the entire available frequency band may be considered busy, even though most of the frequency band may remain idle and available for use.

[0169] In the United States, the available frequency bands that can be used by 802.11ah are 902 MHz to 928 MHz. In South Korea, the available frequency bands are 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are 916.5 MHz to 927.5 MHz. The total available bandwidth for 802.11ah is 6 MHz to 26 MHz, depending on country regulations.

[0170] 15D is a system diagram illustrating an example RAN 113 and CN 115. As described above, the RAN 113 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using NR radio technology. The RAN 113 may also communicate with the CN 115.

[0171] The RAN 113 may include gNBs 180a, 180b, and 180c, although it will be understood that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, and 180c may implement MIMO technology. For example, the gNB 180a, 180b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, and 180c. Thus, the gNB 180a may transmit wireless signals to and / or receive wireless signals from the WTRU 102a using, for example, multiple antennas. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). 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 multipoint (CoMP) technology. For example, the WTRU 102a may receive coordinated transmissions from the gNBs 180a and 180b (and / or 180c).

[0172] 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 vary for different transmissions, different cells, and / or different portions of the wireless 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., including different numbers of OFDM symbols and / or lasting for different lengths of absolute time).

[0173] 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 another RAN (e.g., eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in unlicensed bands. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate with / connect to a gNB 180a, 180b, 180c while also communicating with / connecting to another RAN, such as an eNodeB 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more eNodeBs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNodeBs 160a, 160b, 160c may act as mobility anchors for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0174] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support for network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data to User Plane Functions (UPFs) 184a, 184b and routing of control plane information to Access and Mobility Management Functions (AMFs) 182a, 182b, etc. As shown in FIG. 15D, the gNBs 180a, 180b, 180c may communicate with each other over the Xn interface.

[0175] The CN 115 shown in Figure 16D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While each of the above elements is depicted as part of the CN 115, it will be understood that any of these elements may be owned and / or operated by an entity different from the CN operator.

[0176] The AMF 182a, 182b may be connected to one or more of the 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 WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, managing registration areas, terminating NAS signaling, and mobility management, etc. Network slicing may be used by the AMF 182a, 182b to customize CN support for the WTRUs 102a, 102b, 102c based on the type of service utilized by the WTRUs 102a, 102b, 102c. Different network slices may be established for different use cases, such as services relying on Ultra-Reliable Low-Latency (URLLC) access, services relying on 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) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0177] The SMFs 183a and 183b may be connected to the AMFs 182a and 182b in the CN 115 via an N11 interface. The SMFs 183a and 183b may also be connected to the UPFs 184a and 184b in the CN 115 via an N4 interface. The SMFs 183a and 183b may select and control the UPFs 184a and 184b and configure the routing of traffic through the UPFs 184a and 184b. The SMFs 183a and 183b may perform other functions, such as managing and assigning UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notification. PDU session types may be IP-based, non-IP-based, Ethernet-based, etc.

[0178] The UPFs 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, 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. The UPFs 184a, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multihoming PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

[0179] The CN 115 may facilitate communication with other networks. For example, the CN 115 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves 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 data networks (DNs) 185a, 185b through the UPFs 184a, 184b via an N3 interface to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.

[0180] 15A-15D and the corresponding description thereof, one or more or all of the functions described herein with respect to one or more of the WTRUs 102a-d, base stations 114a-b, eNodeBs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other devices described herein may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

[0181] The emulation device may be designed to perform one or more tests of other devices in a laboratory environment and / or in an operator network environment. For example, one or more emulation devices may perform one or more or all functions while fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices in the communication network. One or more emulation devices may perform one or more or all functions while temporarily implemented / deployed as part of a wired and / or wireless communication network. The emulation device may be directly coupled to another device for testing purposes and / or may perform tests using over-the-air wireless communication.

[0182] The one or more emulation devices may perform one or more functions, including all functions, without being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in a test lab and / or in a test scenario in an undeployed (e.g., test) wired and / or wireless communication network to perform tests of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (which may include, for example, one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0183] Thus, systems and implementations have been described herein for defining rectangular picture areas in a video data stream and rendering corresponding pictures. The computing system may be, for example, a wireless transmit / receive unit (WTRU) programmed to receive a video bitstream including pictures with picture headers. The received video bitstream may be, for example, Versatile Video Coding (VVC) formatted data. The computing system may identify a picture parameter set (PPS) containing data defining the structure of the picture based on a picture parameter set identifier in the picture header.

[0184] The computing system may determine, based on the data defining the structure of the picture, an identifier corresponding to a defined rectangular area within the picture and a tile index of a top-left tile within the defined rectangular area. For example, the computing system may parse the data defining the structure of the picture for the identifier corresponding to the defined rectangular area and the tile index of the top-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 top-left tile within the defined rectangular area.

[0185] The computing system may reconstruct the picture including the sub-picture that includes the defined rectangular area based on the identifier corresponding to the defined rectangular area. The computing system may render the sub-picture within the defined rectangular area.

[0186] While example implementations have been disclosed, it will be recognized that the scope of potential implementations is not limited to those explicitly designed. For example, while systems have been described with reference to specific terms such as CTUs, tiles, and tile groups, contemplated embodiments extend beyond implementations using the specific terms described herein. Although features and elements have been described herein in particular combinations, each feature or element may be used alone without other features and elements and / or in various combinations with or without other features and elements.

[0187] It will be understood that the entities performing the processes described herein may be logical entities that can be implemented in the form of software (i.e., computer-executable instructions) stored in memory and executed on a processor of a mobile device, network node, or computer system. That is, the method(s) may be implemented in the form of software (i.e., computer-executable instructions) stored in memory of a mobile device and / or network node, such as a node or computer system, which computer-executable instructions, when executed by a processor of the node, perform the discussed processes. It will also be understood that any transmit and receive processes shown in the figures may be performed by communication circuitry of the node under control of the node's processor and the computer-executable instructions (e.g., software) it executes.

[0188] The various techniques described herein may be implemented in connection with hardware or software, or, where appropriate, a combination of both. Thus, the subject methods and apparatus described herein, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in a tangible medium, such as a flash drive, a CD-ROM, a hard drive, or any other machine-readable storage medium, which, when loaded into a machine, such as a computer, and executed by the machine, causes the machine to become an apparatus for implementing the subject matter described herein. In cases where program code is stored on a medium, it may be the case that the subject program code is stored on one or more media that collectively perform the subject actions, i.e., one or more media that together contain code to perform the actions; however, in cases where more than one single medium is present, there is no requirement that any particular portion of the code be stored on any particular medium. In the case of program code execution on a programmable device, the computing device generally includes a processor, a storage medium readable by the processor (including volatile and nonvolatile memory, and / or storage elements), at least one input device, and at least one output device. For example, one or more programs may implement or utilize the processes described in connection with the subject matter described herein, such as through the use of an API or reusable controls. Such programs may be implemented in a high-level procedural or object-oriented programming language to communicate with a computer system. However, the program(s) may also be implemented in assembly or machine language, if desired. In either case, the language may be a compiled or interpreted language, and combined with hardware implementations.

[0189] While example embodiments may refer to utilizing aspects of the subject matter described herein in the context of one or more stand-alone computing systems, the subject matter described herein is not so limited and, rather, may be implemented in connection with any computing environment, such as a network or distributed computing environment. Furthermore, aspects of the subject matter described herein may be implemented in or across multiple processing chips or devices, and storage devices may similarly be affected across multiple devices. Such devices may include personal computers, network servers, handheld devices, supercomputers, or computers integrated into other systems such as automobiles and airplanes.

[0190] In describing exemplary implementations of the subject matter of the present disclosure, as illustrated in the figures, specific terminology is employed for the sake of clarity. However, it will be understood that the claimed subject matter is not intended to be limited to the specific terminology so selected, and that each specific element includes all technical equivalents that operate in a similar manner to achieve a similar purpose. The details described herein are intended to be exemplary and are not intended to limit the scope of the application in any way.

[0191] Although features and elements have been described above in particular combinations, those skilled in the art will recognize that each feature or element may be used alone or in any combination with the other features and elements. Additionally, the methods described herein may be implemented in a computer program, software, or firmware embodied in a computer-readable medium for execution by a computer or processor. Examples of non-transitory computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WRTU, UE, terminal, base station, RNC, or any host computer.

Claims

1. 1. A method of video coding, comprising: receiving a video bitstream including pictures having picture headers; identifying a picture parameter set containing data regarding the structure of the picture based on a picture parameter set identifier in the picture header; determining an identifier corresponding to a defined rectangular area and a tile index of a top-left tile within the defined rectangular area based on data relating to the structure of the picture; determining one or more tiles included in the defined rectangular area associated with the identifier based on the identifier corresponding to the defined rectangular area and a tile index of a top-left tile within the defined rectangular area; reconstructing the picture having a sub-picture that includes the defined rectangular area based on the identifier corresponding to the defined rectangular area; A method comprising:

2. 2. The method of claim 1, further comprising the step of rendering the subpicture within the defined rectangular area.

3. extracting from the video bitstream a sub-bitstream associated with the sub-picture based on the identifier corresponding to the defined rectangular area; reconstructing the sub-picture based on the sub-bitstream; 10. The method of claim 1, further comprising:

4. parsing the picture header to identify an identifier associated with the sub-picture; identifying a sub-bitstream associated with the sub-picture based on the identifier corresponding to the defined rectangular area that matches the identifier associated with the sub-picture; reconstructing the sub-picture based on the sub-bitstream; 10. The method of claim 1, further comprising:

5. the picture includes a plurality of sub-pictures, the sub-picture is a first sub-picture, and the method includes: determining a second identifier corresponding to a second defined rectangular area in the data relating to the structure of the picture in the picture parameter set; identifying a second sub-bitstream associated with the second sub-picture based on the second identifier corresponding to the second defined rectangular area; reconstructing the second sub-picture based on the second sub-bitstream, wherein the picture is reconstructed having the first sub-picture including the first defined rectangular area and the second sub-picture including the second defined rectangular area; 10. The method of claim 1, further comprising:

6. 2. The method of claim 1 , wherein determining, in the data regarding the structure of the picture, an identifier corresponding to a defined rectangular area and a tile index of a top-left tile within the defined rectangular area comprises parsing the data regarding the structure of the picture in the picture parameter set for data associated with the identifier corresponding to the defined rectangular area.

7. 10. The method of claim 1, wherein the bitstream comprises Versatile Video Coding (VVC) formatted data.

8. The method of claim 1 , wherein the rectangular area is a region of interest.

9. 10. The method of claim 1, wherein the bitstream includes omnidirectional video data.

10. 1. A computing system comprising: a computing processor; a computing memory communicatively coupled to the computing processor, the computing memory including executable instructions, the executable instructions providing the computing system with: receiving a video bitstream including pictures having picture headers; identifying a picture parameter set containing data regarding the structure of the picture based on a picture parameter set identifier in the picture header; determining an identifier corresponding to a defined rectangular area and a tile index of a top-left tile within the defined rectangular area based on data relating to the structure of the picture; determining one or more tiles included in the defined rectangular area associated with the identifier based on the identifier corresponding to the defined rectangular area and a tile index of a top-left tile within the defined rectangular area; reconstructing the picture having a sub-picture that includes the defined rectangular area based on the identifier corresponding to the defined rectangular area; A computing system characterized by causing the system to perform operations including:

11. 11. The computing system of claim 10, wherein the computing memory includes executable instructions that cause the computing system to perform operations further including rendering the subpicture within the defined rectangular area.

12. The computing memory is configured to include: extracting from the video bitstream a sub-bitstream associated with the sub-picture based on the identifier corresponding to the defined rectangular area; reconstructing the sub-picture based on the sub-bitstream; 11. The computing system of claim 10, further comprising executable instructions to cause the system to perform operations further comprising:

13. The computing memory is configured to include: parsing the picture header to identify an identifier associated with the sub-picture; identifying a sub-bitstream associated with the sub-picture based on the identifier corresponding to the defined rectangular area that matches the identifier associated with the sub-picture; reconstructing the sub-picture based on the sub-bitstream; 11. The computing system of claim 10, further comprising executable instructions to cause the system to perform operations further comprising:

14. the picture includes a plurality of sub-pictures, the sub-picture is a first sub-picture, and the computing memory provides the computing system with: determining a second identifier corresponding to a second defined rectangular area in the data relating to the structure of the picture in the picture parameter set; identifying a second sub-bitstream associated with the second sub-picture based on the second identifier corresponding to the second defined rectangular area; reconstructing the second sub-picture based on the second sub-bitstream, wherein the picture is reconstructed having the first sub-picture including the first defined rectangular area and the second sub-picture including the second defined rectangular area; 11. The computing system of claim 10, further comprising executable instructions to cause the system to perform operations further comprising:

15. 11. The computing system of claim 10, wherein determining, in the data regarding the structure of the picture, an identifier corresponding to a defined rectangular area and a tile index of a top-left tile within the defined rectangular area comprises parsing the data regarding the structure of the picture in the picture parameter set for data associated with the identifier corresponding to the defined rectangular area.

16. 11. The computing system of claim 10, wherein the computing memory includes executable instructions that cause the computing system to perform operations further including extracting the sub-picture based on the identifier corresponding to the defined rectangular area.

17. 11. The computing system of claim 10, wherein the bitstream comprises Versatile Video Coding (VVC) formatted data.

18. The computing system of claim 10 , wherein the rectangular area is a region of interest.

19. 11. The computing system of claim 10, wherein the bitstream includes omnidirectional video data.

20. The computing system of claim 10 , wherein the computing system is a wireless transmit / receive unit (WTRU).

Images